AEM as a Cloud Service에서의 유지 관리 작업 maintenance-tasks-in-aem-as-a-cloud-service
유지 관리 작업은 저장소 최적화를 위해 일정에 따라 실행되는 프로세스입니다. AEM as a Cloud Service를 사용하면 고객이 유지 관리 작업의 운영 속성을 구성할 필요성이 최소화됩니다. 고객은 인프라 운영을 Adobe에게 맡긴 채 애플리케이션 수준의 우려사항에 자원을 집중시킬 수 있습니다.
유지 관리 작업 구성 maintenance-tasks-configuring
이전의 AEM 버전에서는 유지 관리 카드(도구 > 운영 > 유지 관리)를 사용해 유지 관리 작업을 구성할 수 있었습니다. AEM as a Cloud Service의 경우 유지 관리 카드가 더 이상 이용 가능하지 않기 때문에 Cloud Manager를 사용해 소스 제어에 구성을 커밋하고 배포해야 합니다. Adobe은 고객이 구성할 수 없는 설정(예: 데이터스토어 가비지 수집)이 있는 유지 관리 작업을 관리합니다. 기타 유지 관리 작업은 아래 표에 설명한 대로 고객이 구성할 수 있습니다.
다음 표는 사용 가능한 유지 관리 작업을 보여 줍니다.
위치:
- 일별 - /apps/settings/granite/operations/maintenance/granite_daily
- 주별 - /apps/settings/granite/operations/maintenance/granite_weekly
- 월별 - /apps/settings/granite/operations/maintenance/granite_monthly
코드 샘플:
코드 샘플 1 (일별)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowSchedule="daily"
windowStartTime="03:00"
windowEndTime="05:00"
/>
코드 샘플 2 (주별)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="weekly"
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
코드 샘플 3 (월별)
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:Folder"
sling:configCollectionInherit="true"
sling:configPropertyInherit="true"
windowEndTime="15:30"
windowSchedule="monthly"
windowFirstLastStartDay=0
windowScheduleWeekdays="[5,5]"
windowStartTime="14:30"/>
버전 삭제 및 감사 로그 삭제 유지 관리 작업 purge-tasks
버전 및 감사 로그를 지우면 저장소 크기가 줄어들고 일부 시나리오에서는 성능이 향상될 수 있습니다.
기본값 defaults
현재는 기본적으로 제거가 활성화되어 있지 않지만 향후 변경될 예정입니다. 기본 제거가 활성화되기 전에 생성된 환경은 제거가 예기치 않게 발생하지 않도록 보다 보수적인 임계값을 갖습니다. 기본 삭제 정책에 대한 자세한 내용은 아래의 버전 삭제 및 감사 로그 삭제 섹션을 참조하십시오.
아래 설명된 대로 구성 파일을 선언하고 배포하여 기본 제거 값을 재정의할 수 있습니다.
구성 적용 configure-purge
다음 단계에 설명된 대로 구성 파일을 선언하고 배포합니다.
1 - Git에서 프로젝트의 최상위 폴더에 다음 폴더 및 파일 구조를 만듭니다.
config/
mt.yaml
2 - 다음을 포함하는 구성 파일의 속성을 선언합니다.
- 값이 "MaintenanceTasks"인 "kind" 속성.
- "version" 속성(현재 버전 1)입니다.
- 속성이
envTypes인 선택적 "metadata" 개체로, 이 구성이 유효한 환경 유형(dev, stage, prod)의 쉼표로 구분된 목록입니다. 메타데이터 개체가 선언되지 않으면 모든 환경 유형에 대해 구성이 유효합니다. versionPurge및auditLogPurge개체가 모두 있는 데이터 개체입니다.
아래 versionPurge 및 auditLogPurge 개체의 정의 및 구문을 참조하십시오.
다음 예제와 유사하게 구성을 구성해야 합니다.
kind: "MaintenanceTasks"
version: "1"
metadata:
envTypes: ["dev"]
data:
versionPurge:
maximumVersions: 15
maximumAgeDays: 20
paths: ["/content"]
minimumVersions: 1
retainLabelledVersions: false
auditLogPurge:
rules:
- replication:
maximumAgeDays: 15
contentPath: "/content"
types: ["Activate", "Deactivate", "Delete", "Test", "Reverse", "Internal Poll"]
- pages:
maximumAgeDays: 15
contentPath: "/content"
types: ["PageCreated", "PageModified", "PageMoved", "PageDeleted", "VersionCreated", "PageRestored", "PageValid", "PageInvalid"]
- dam:
maximumAgeDays: 15
contentPath: "/content"
types: ["ASSET_EXPIRING", "METADATA_UPDATED", "ASSET_EXPIRED", "ASSET_REMOVED", "RESTORED", "ASSET_MOVED", "ASSET_VIEWED", "PROJECT_VIEWED", "PUBLISHED_EXTERNAL", "COLLECTION_VIEWED", "VERSIONED", "ADDED_COMMENT", "RENDITION_UPDATED", "ACCEPTED", "DOWNLOADED", "SUBASSET_UPDATED", "SUBASSET_REMOVED", "ASSET_CREATED", "ASSET_SHARED", "RENDITION_REMOVED", "ASSET_PUBLISHED", "ORIGINAL_UPDATED", "RENDITION_DOWNLOADED", "REJECTED"]
구성이 유효하려면 다음 사항에 유의하십시오.
- 모든 속성을 정의해야 합니다. 상속된 기본값은 없습니다.
- 아래 속성 표의 유형(정수, 문자열, 부울 등)은 준수해야 합니다.
yq을(를) 사용하여 구성 파일의 YAML 형식을 로컬로 확인할 수 있습니다(예: yq mt.yaml).3 - 비프로덕션 및 프로덕션 구성 파이프라인을 구성합니다.
RDE(신속한 개발 환경)는 제거를 지원하지 않습니다. 프로덕션(샌드박스가 아닌) 프로그램의 다른 환경 유형의 경우 Cloud Manager에서 타깃팅된 배포 구성 파이프라인을 만듭니다.
자세한 내용은 프로덕션 파이프라인 구성 및 비프로덕션 파이프라인 구성을 참조하십시오.
버전 삭제 version-purge
버전 삭제 기본값 version-purge-defaults
현재는 기본적으로 제거가 활성화되어 있지 않지만 향후 변경될 예정입니다.
기본 제거가 활성화된 후에 생성된 환경에는 다음 기본값이 사용됩니다.
- 30일 이전 버전은 제거됩니다.
- 최근 30일 동안의 최신 5개 버전이 유지됩니다.
- 위의 규칙과 관계없이 최신 버전(현재 파일 포함)은 유지됩니다.
기본 지우기가 활성화되기 전에 생성된 환경에는 아래 나열된 기본값이 있지만 성능을 최적화하기 위해 해당 값을 낮추는 것이 좋습니다.
- 7년 이전의 버전은 제거됩니다.
- 지난 7년 동안의 모든 버전이 유지됩니다.
- 7년 후에는 (현재 파일 외에) 최신 버전 이외의 버전이 제거됩니다.
버전 삭제 속성 version-purge-properties
허용되는 속성은 다음과 같습니다.
default 을(를) 나타내는 열은 기본값이 적용될 때 미래의 기본값을 나타냅니다. TBD 은(는) 아직 결정되지 않은 환경 ID를 반영합니다.
속성 상호 작용
다음 예제는 속성이 결합될 때 상호 작용하는 방법을 보여 줍니다.
예:
maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2
maximumVersions 속성이 10으로 설정되어 있으므로 23일에 11개의 버전이 있는 경우 다음 번에 제거 유지 관리 작업이 실행될 때 가장 오래된 버전이 삭제됩니다.
31일에 5개의 버전이 있는 경우 minimumVersions 속성이 2로 설정되어 있으므로 3개만 삭제됩니다.
예:
maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1
maximumVersions 속성이 0으로 설정되어 30일 이상 버전이 삭제되지 않습니다.
30일 넘는 이전 버전 하나가 유지됩니다.
감사 로그 삭제 audit-purge
감사 로그 삭제 기본값 audit-purge-defaults
현재는 기본적으로 제거가 활성화되어 있지 않지만 향후 변경될 예정입니다.
기본 제거가 활성화된 후에 생성된 환경에는 다음 기본값이 사용됩니다.
- 7일 넘는 복제, DAM 및 페이지 감사 로그는 제거됩니다.
- 가능한 모든 이벤트가 기록됩니다.
기본 지우기가 활성화되기 전에 생성된 환경에는 아래 나열된 기본값이 있지만 성능을 최적화하기 위해 해당 값을 낮추는 것이 좋습니다.
- 7년 이상 된 복제, DAM 및 페이지 감사 로그는 제거됩니다.
- 가능한 모든 이벤트가 기록됩니다.
감사 로그 삭제 속성 audit-purge-properties
허용되는 속성은 다음과 같습니다.
default 을(를) 나타내는 열은 기본값이 적용될 때 미래의 기본값을 나타냅니다. TBD 은(는) 아직 결정되지 않은 환경 ID를 반영합니다.