AEM as a Cloud Service のメンテナンスタスク maintenance-tasks-in-aem-as-a-cloud-service
メンテナンスタスクとは、リポジトリを最適化するためにスケジュールに従って実行されるプロセスです。AEM as a Cloud Service を使用すると、顧客がメンテナンスタスクの運用プロパティを設定する必要が最小限になります。顧客は、インフラストラクチャの運用をアドビに任せて、リソースをアプリケーションレベルの懸念事項に集中させることができます。
メンテナンスタスクの設定 maintenance-tasks-configuring
以前のバージョンの AEM では、メンテナンスカード（ツール／操作／メンテナンス）を使用してメンテナンスタスクを設定できました。AEM as a Cloud Service を使用する場合、メンテナンスカードは使用できなくなったので、Cloud Manager を使用して設定をソース管理にコミットし、デプロイする必要があります。顧客側で行えない設定を含むメンテナンスタスク（データストアのガベージコレクションなど）はアドビが管理します。その他のメンテナンスタスクは顧客側で設定できます（下表を参照）。
次の表に、使用可能なメンテナンスタスクを示します。
ロケーション:
- 日単位 - /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」オブジェクトと、この設定が有効な環境タイプ（開発、ステージ、実稼動）のコンマ区切りリスト。メタデータオブジェクトが宣言されていない場合、設定はすべての環境タイプに対して有効です。 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 を使用すると、設定ファイル（例：yq mt.yaml）の YAML 形式をローカルで検証できます。3 - 実稼動以外の設定パイプラインと実稼動設定パイプラインを設定します。
迅速な開発環境（RDE）では、パージはサポートされていません。実稼動（非サンドボックス）プログラムの他の環境タイプの場合は、Cloud Manager でターゲットデプロイメント設定パイプラインを作成します。
詳しくは、実稼動パイプラインの設定および実稼動以外のパイプラインの設定を参照してください。
バージョンのパージ version-purge
バージョンパージのデフォルト version-purge-defaults
現在、デフォルトではパージが有効になっていませんが、今後変更される予定です。
デフォルトのパージが有効になった後に作成した環境には、次のデフォルト値が設定されます。
- 30 日より古いバージョンは削除されます。
- 過去 30 日間で最新 5 つのバージョンが保持されます。
- 上記のルールに関係なく、（現在のファイルに加えて）最新バージョンが保持されます。
デフォルトのパージが有効になる前に作成した環境には、以下に示すデフォルト値が設定されますが、パフォーマンスを最適化するために、これらの値を小さくすることをお勧めします。
- 7 年より古いバージョンは削除されます。
- 過去 7 年間のすべてのバージョンが保持されます。
- 7 年後、最新バージョン以外のバージョン（現在のファイルに加えて）が削除されます。
バージョンパージのプロパティ version-purge-properties
許可されるプロパティを以下に示します。
デフォルト を示す列は、デフォルトが適用される今後のデフォルト値を示します。未定 は、まだ決定されていない環境 ID を反映します。
プロパティのインタラクション
次の例は、プロパティを組み合わせた場合の操作を示しています。
例：
maximumAgeDays = 30
maximumVersions = 10
minimumVersions = 2
23 日目に 11 個のバージョンがある場合、maximumVersions プロパティが 10 に設定されているので、次にパージメンテナンスタスクを実行する際には最も古いバージョンがパージされます。
31 日目に 5 個のバージョンがある場合、minimumVersions プロパティが 2 に設定されているので、パージされるのは 3 個だけです。
例：
maximumAgeDays = 30
maximumVersions = 0
minimumVersions = 1
maximumVersions プロパティが 0 に設定されているので、30 日より新しいバージョンはパージされません。
30 日より古いバージョンが 1 つ保持されます。
監査ログのパージ audit-purge
監査ログのパージのデフォルト audit-purge-defaults
現在、デフォルトではパージが有効になっていませんが、今後変更される予定です。
デフォルトのパージが有効になった後に作成した環境には、次のデフォルト値が設定されます。
- 7 日より古いレプリケーション、DAM、ページの監査ログは削除されます。
- 考えられるすべてのイベントがログに記録されます。
デフォルトのパージが有効になる前に作成した環境には、以下に示すデフォルト値が設定されますが、パフォーマンスを最適化するために、これらの値を小さくすることをお勧めします。
- 7 年より古いレプリケーション、DAM 、ページの監査ログは削除されます。
- 考えられるすべてのイベントがログに記録されます。
監査ログのパージのプロパティ audit-purge-properties
許可されるプロパティを以下に示します。
デフォルト を示す列は、デフォルトが適用される今後のデフォルト値を示します。未定 は、まだ決定されていない環境 ID を反映します。