Adobe Experience Manager リポジトリをキレイに保つ方法 - バージョンパージ編

#はじめに
Adobe Experience Manager (以下、AEM)には、標準機能としてAEMのリポジトリ（データ領域）をキレイにする仕組みを備えていますが、デフォルトの設定のままではお客様の要件を満たしていないことがあります。

この記事では、AEMを使ったサイトを運用している方々を対象に、AEMのリポジトリをキレイに保つためにメンテナンス設定の考慮すべき点と具体的な設定手順を紹介していきます。

また、現在アドビでは、AEMの導入形態として以下の3種類を提供しています。

|導入形態|概要|
|---|---|
|Adobe Experience Manager On-premise Software|AEMはソフトウェアとして提供され、お客様はお客様自信が所有しているインフラ上にAEMを構築する
|Adobe Experience Manager Managed Services|お客様向けに構成されたAEM環境をアドビにて運用するサービス(PaaS)|
|Adobe Experience Manager as a Cloud Service|AEMの各種機能をクラウドサービスとして提供(SaaS)|
いずれの形態においても、システムの運用・メンテナンス作業はアドビ提供のサービス内で実施されますが、実施の頻度、スケジュールはお客様のサイト更新頻度などの業務形態に即して、カスタマイズすることが可能です。

>本記事は投稿時点の情報に基づいて掲載しています。その後の機能アップデート等によっては内容が変更となっている場合がありますのでご了承ください。

##メンテナンス設定の見直しの必要性について
AEMに限らずデータベースやサーバは、使い込んでいくうちに不要なデータが溜まっていって、それがディスクを圧迫したり、パフォーマンスを落としたりする原因となったりします。

そのような不要なデータ群を掃除するために、AEMでは多様なメンテナンス機能が標準で備わっており、基本的には普段はそれらの機能を意識することなく運用することが出来ます。

しかしながら、実際に運用を続けていった時に、導入当時の設定やデフォルトの設定のままだと、実際の現状にマッチしていない設定となっている可能性もあります。

そのため、メンテナンスの設定値を定期的に見直すことは、より確実にシステムを安定化させることにつながります。

###AEM メンテナンス機能一覧
|メンテナンス項目|メンテナンス対象|データの種類|デフォルトのスケジュール（環境によって異なることがあります)|
|---|---|---|---|
|リビジョンクリーンナップ|ノードストア上で不要になったノード情報の削除|物理的なデータ（OS上のノードストア、データストアのファイル）|日次|
|データストアGC|データストア上で参照がなくなったバイナリファイルの削除|同上|週次|
|Luceneバイナリクリーンナップ|不要になったLucene バイナリの削除|同上|日次|
|バージョンパージ|不要になったバージョンの削除|論理的なデータ　|なし|
|ワークフローパージ|完了したワークフローの削除|同上|週次|
|監査ログパージ|不要になった監査ログの削除|同上|週次|
|プロジェクトパージ|不要になったプロジェクトの削除|同上|なし|
|アドボックタスクパージ|不要になったアドホックタスクの削除|同上|なし|
|DAM Event Purge Service|不要になったアセットアクティビティの記録の削除|同上|なし|
|ローンチ削除|不要になったローンチの削除|同上|なし|
*※上記のリストには、「Adobe Experiece Manager as a Cloud Service」 で、2021年9月現在ユーザー側で設定変更が出来ない機能が含まれています*

今回は、この中から<strong>バージョンパージ</strong>にフォーカスを当てて説明したいと思います。
##バージョンとは

ここで言う<strong>バージョン</strong>とは何でしょうか。

バージョンはAEMのソフトウェアのバージョンや、カスタマイズしたパッケージのバージョンを指すものではありません。
ここでは<strong>ページもしくはアセットのバージョン</strong>のことを指しています。

ページ・アセットのバージョンとは、ページ・アセットの”ある時点”でのスナップショットです。
このバージョンを残しておくことで何が嬉しいかというと、下記のようなことが可能です。
- 以前のバージョンに戻す（リストア）
- 現在のバージョンと以前のバージョンの比較

バージョンはいつ作られるかと言うと、下記の場合です。
- 手動でバージョン作成を実行する
- （ページの場合）公開する
- （アセットの場合のみ）すでにあるアセットと同じ名前のファイルをアップロードする
- （アセットの場合のみ）画像編集やメタデータの編集をする

※ページのバージョンの詳細は下記リンクに記載があります。
https://experienceleague.adobe.com/docs/experience-manager-65/authoring/siteandpage/working-with-page-versions.html?lang=ja
※アセットのバージョンの詳細は下記リンクに記載があります。
https://experienceleague.adobe.com/docs/experience-manager-65/assets/managing/manage-assets.html?lang=ja
##バージョンのデータの保存のされ方
バージョンのデータというのはどのように保存されているかというと、変更された差分だけを保存しているわけではなく、ページ全体のデータを保存しています。
つまり1ページ（または1アセット）に対して、バージョンの数だけディスク容量を使用している、ということになります。
##バージョンパージとは
実際の運用では、意識的に手動でバージョンを増やしていくというよりは、ページを繰り返し更新・公開した結果、バージョンが増えていくという状況が多いと思います。
つまり無意識のうちに必要以上にディスクを使ってしまっているということがあり得るということになります。
そこで、バージョンパージというメンテナンス機能を使って、古いバージョンを掃除する必要があるわけです。
##設定方法について
バージョンパージの設定は下記の手順で行います。
###ルールの設定
バージョンパージのルールはシステムコンソールの下記の項目で設定します。
*http://[server]:[port]/system/console/configMgr/com.day.cq.wcm.core.impl.VersionPurgeTask*
![VersionPurgeTask.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/b26b2aca-69bb-21d5-7486-84a6c77a3cb8.png)
バージョンパージの設計を見直す場合には、下記の項目について検討することをオススメします。

|項目|意味|
|---|---|
|Purge paths|バージョンパージの対象とするパスです|
|Maximum number of versions|保存するバージョンの世代数です（これを超える世代のバージョンが削除の対象となります）|
|Maximum version age|保存するバージョンの日数です（これより古い日にちのバージョンが削除の対象となります）|

メンテナンスが行われるタイミングで、上記のルールに適合したページバージョンが自動的に削除されるという動作となります。
###有効化する方法
日次もしくは週次のメンテナンスウィンドウの中に追加することで有効化されます。
```ツール > 運営 > メンテナンス > 日別メンテナンスウィンドウ もしくは 週別メンテナンスウィンドウ```
に移動し「新規タスクを追加」で「バージョンのパージ」を選んで「保存」します。
![メンテナンスウィンドウ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/ec155c26-9b3a-d344-ce12-a2bf5fe653c9.png)
一度設定したら、次回はどのタイミングでバージョンパージが実行されるかが確認できるようになります。
![nextPurge.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/3fabc3f7-89ca-e909-b1db-b6772a831a74.png)
###設定変更時の注意点1 大量のバージョンを消すときは計画的に
例えば、数年間の間バージョンの保存期間を無制限としていた環境がある仮定しまして、
この環境でバージョンパージの設定を「無制限」から「30日以内」という設定に変更したいと考えたとします。
この場合、AEMは次回のメンテナンススケジュールで数年間溜まったバージョン群を一気に削除することになります。
しかしながら、あまりに多くの量を削除しようとした場合、AEMに対する負荷が大きくなり、完了するまでに非常に時間がかかったり、想定したスケジュールの中で削除が完了しないといったことが起こるかもしれません。

ですので、最終的には30日以内のバージョンだけを残すことがゴールだとしても、まずは3年前→2年前→1年前といったように、メンテナンスが行われるごとにゴールに近づくように徐々に設定を変更していくことがオススメです。

###設定変更時の注意点2 ディスク削除の効果が確認できるタイミング
バージョンパージが行われた後、OSのコマンドでディスクの使用量を確認しても、使用量が変わらないように見えることがあります。
これは、バージョンパージは論理的な削除のみをおこなっているため、OSから見た場合はまだデータが残っているとみなされることが原因です。
OSから見た場合のディスク使用量が実際に減る（物理削除が行われる）のは、バージョンパージとは別のメンテナンス機能であるリビジョンクリーンナップ（デフォルトでは1週間に1回自動実行）とデータストアGC（デフォルトでは1日に1回自動実行）が行われたタイミングとなります。
##「バージョンパージ」以外でバージョンを削除する方法
###ページやアセットに対する操作に応じて、バージョンを削除する方法
バージョンを削除する方法としては、バージョンパージとは別に<strong>バージョンマネージャー</strong>という機能が存在します。

バージョンパージは定期メンテナンスとして事前に設定したメンテナンスのタイミングで実施されますが、バージョンマネージャーはページ公開などのアクション時に一定のルールに従ってバージョンを削除する機能となります。

このバージョンマネージャーはバージョンパージと併用して使うことも可能で、例えば
<strong>ページは頻繁に更新が発生するので履歴世代数を多く保持しなければならないけど、アセットの更新頻度はそれほど高くない</strong>
という使われ方をしている場合に
<strong>バージョンパージでは、コンテンツ全体は5世代分を残す設定にし、</strong>
<strong>バージョンマネージャーでは、アセットだけ3世代分のみ残す設定にする</strong>
というように、状況に合わせた使い分けをすることもできます。

※バージョンマネージャーの詳細は下記リンクに記載があります。
https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/version-purging.html?lang=ja
###手動でバージョンを削除する方法
例えば急激にディスク使用率が高くなってしまって、緊急でバージョンパージを行いたいときはどうすれば良いでしょうか。

こういった場合には、バージョンパージ用のツールを使用することで、任意のタイミングで任意のバージョンを消すことが可能です。

ツールのパスは以下になります。
*http://[server]:[port]/etc/versioning/purge.html*

このツールは、実際にバージョンを削除するために使うだけでなく「Dry Run」を行うことでパージされる対象バージョンを洗い出すことに使用できたりもします。
![DryRun.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/8c234b60-239c-2e3e-3573-6b56b9563c6d.png)
大量にバージョンを削除する場合には、一度に溜まったバージョンを削除するのではなく段階的に削除した方がよいということを**設定変更時の注意点1　大量のバージョンを消すときは計画的に**の項目で言及しましたが、この「Dry Run」を活用することで、削除計画が立てやすくなるかと思います。

※手動バージョンパージの詳細は下記リンクに記載があります。
https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/monitoring-and-maintaining.html?lang=ja#version-purging
##まとめ
以上、バージョンパージについて紹介いたしました。

最近の実例として「運用が始まって数年経っているあるシステムで、ディスク使用量が高くなってきたため、不要なページ・アセットなどを削除するなどの対処を行ったのに、思っていたよりディスク削減効果が出ず困っていた。そこで、バージョンパージの設定を見直したところ、全体の10〜15%ほどのディスクの使用量を削減できた」という事例がありました。

このように、1つのメンテナンス項目を見直すだけでも、システムの安定性を高めることが出来ることがあります。

実際のAEM運用の現場では、コンテンツを作成する方とAEMシステムの運用をする方が別々の組織であることが少なくなく、今回紹介した「バージョン」が蓄積していても、AEMシステム運用者側としてはあまり意識されていない状況がしばしば見られますが、今後、運用について見直す機会があれば、今回ご紹介したバージョンパージの設定も参考にしていただけると嬉しいです。
※他のメンテナンス項目についても、今後Qiitaで紹介していく予定です。

以上、AEMをご利用いただいている皆様の一助になれば幸いです。