Adobe Experience Manager リポジトリをキレイに保つ方法 - リビジョンクリーンナップ編

# はじめに
前回の記事[『Adobe Experience Manager リポジトリをキレイに保つ方法 - バージョンパージ編』](https://qiita.com/iwayak/items/0961896c818620e822f9 "Adobe Experience Manager リポジトリをキレイに保つ方法 - バージョンパージ編")では、AEMにおけるメンテナンス設定の見直しの必要性と、メンテナンスの一例としてバージョンパージについて説明しました。

今回は、もうひとつの例としてリビジョンクリーンアップと呼ばれるメンテナンスタスクを紹介しつつ、AEMのメンテナンスにおける重要な考え方である物理的なデータ、論理的なデータの違いについて説明させて頂きます。

## メンテナンス機能の一覧
まずは、[前回の記事](https://qiita.com/iwayak/items/0961896c818620e822f9)でも紹介しましたメンテナンス項目一覧を振り返ってみたいと思います。

こちらを見ていただくと、表の中に「データの種類」という項目がありますね。
この項目を見てみると、前回紹介した[バージョンパージ](https://qiita.com/iwayak/items/0961896c818620e822f9)でメンテナンスされる対象のデータは、「論理的なデータ」になっていることがわかると思います。
しかし、今回ご紹介するリビジョンクリーンアップについては、対象が「物理的なデータ」になっています。

この違いは何なのか、が今回の記事の重要なポイントとなります。

### AEM メンテナンス機能一覧
|メンテナンス項目|メンテナンス対象|データの種類|デフォルトのスケジュール（環境によって異なることがあります)|
|---|---|---|---|
|リビジョンクリーンアップ <font color="Orange">本記事の対象はこちら</font>|ノードストア上で不要になったノード情報の削除|物理的なデータ（OS上のノードストア、データストアのファイル）|日次|
|データストアGC|データストア上で参照がなくなったバイナリファイルの削除|同上|週次|
|Luceneバイナリクリーンアップ|不要になったLucene バイナリの削除|同上|日次|
|バージョンパージ　[参考記事](https://qiita.com/iwayak/items/0961896c818620e822f9)|不要になったバージョンの削除|論理的なデータ　|なし|
|ワークフローパージ|完了したワークフローの削除|同上|週次|
|監査ログパージ|不要になった監査ログの削除|同上|週次|
|プロジェクトパージ|不要になったプロジェクトの削除|同上|なし|
|アドボックタスクパージ|不要になったアドホックタスクの削除|同上|なし|
|DAM Event Purge Service|不要になったアセットアクティビティの記録の削除|同上|なし|
|ローンチ削除|不要になったローンチの削除|同上|なし|

*※ 上記のリストには、「Adobe Experiece Manager as a Cloud Service」 で、2022年3月現在ユーザー側で設定変更が出来ない機能が含まれています*

## 論理的なデータと物理的なデータの違いとそのメンテナンスについて
### 不要なデータを消したのに、ディスク使用量が削減されない？
『AEMが稼働しているサーバでディスク使用量が大きくなったので、AEM上でメンテナンスタスクを実行したり不要なデータを消したりしてみた。でも、なぜかディスク使用量が削減されなかった』といった経験はありませんか？

こういった場合、論理的なデータは削除したけど、物理的なデータは削除していない、といった状況になっているかもしれません。
これがどういう状況なのかについて、論理的なデータと物理的なデータの違いとあわせて説明します。

### AEMはどうやってデータを取り扱っているのか？ - MVCCの話
論理的なデータと物理的なデータの違いの前に、まずAEMがどのようにデータを制御しているかを説明します。

AEMでは **Apache Jackrabbit Oak** と呼ばれるリポジトリ（※）システムを利用されています。
※リポジトリは「データを保管しておく場所」です。

この **Apache Jackrabbit Oak** は　**MVCC(Multi-Version Concurrency Control) モデル** でデータを制御しています。
AEMでも当然この**MVCCモデル**を継承しています。

MVCCモデルの何が嬉しいかと言うと「複数のユーザが同時に同じデータを参照や更新をしていたとしても、それぞれのユーザーから見ているデータの一貫性が保たれる」という点です。

例えば、とあるページをAさんとBさんが同時に編集しようとしているとします。
そして、Aさんはそのページに画像を貼る作業をしたい、Bさんはテキストコンポーネントに文章を書く作業をしたい、と思っているとします。

こういった場合、MVCCモデル以外の場合では、
- AさんとBさんが同時に作業をして、Aさんが先に作業を終え、そのあとBさんが作業を終えてデータを保存したところ、Aさんの作業した分が消えてしまった（同時アクセスによるデータ不整合）
- Aさんの作業中にはそもそもBさんは作業できない（ロック型＝排他制御によって作業を制限される）
といったことが起こりえます。

しかし、MVCCモデルでは、AさんBさんのお互いの作業の影響を受けずに、かつ同時に作業を行うことが出来ます。

MVCCモデルがこれをどうやって実現しているかと言うと、元のデータに対して、Aさんが作業した分、Bさんが作業した分、それぞれの差分を保存したスナップショットを作成して、AさんはAさんのスナップショット、BさんはBさんのスナップショットの上で作業をします。
そのため、AさんBさんはお互いの作業の影響を受けることなく、同時に作業することが出来るのです。

### リビジョンクリーンアップとは？
先程の例で、AさんとBさんの作業の差分をスナップショットしたデータが存在することを示しました。
この差分データのことをリビジョンと言います。

平行性と一貫性が保たれる一方で、この差分のデータ＝リビジョンは放っておくとどんどん貯まっていくことになります。
これはMVCCモデルのデメリットとなります。

リポジトリが更新されるたびに新たなリビジョンが作られ、放っておくと残り続ける動作が繰り返されるので、その結果リポジトリのサイズがどんどん大きくなってしまうのです。

この溜まってしまった古いリビジョンをクリーンアップするメンテナンスタスクがあります。
それが**リビジョンクリーンアップ**です。
### 物理データを削除するのが、リビジョンクリーンアップ
AEMが行う削除には、論理削除と物理削除の2種類があります。
その名の通り、論理削除は論理データを削除すること、物理削除は物理データを削除することです。

AEMのユーザインタフェースにて画像などを削除した場合や、前回の記事で紹介した[バージョンパージ](https://qiita.com/iwayak/items/0961896c818620e822f9)は論理削除になります。
論理削除をしたデータは、データとしては無効になっているものの、実はAEMのリポジトリ内にはデータが存在している状態なのです。
ですので、論理削除の場合はディスク使用量の削減につながらないのです。

一方で、データをディスク上から完全に消し去るために実施するのが物理削除です。


そして、リビジョンクリーンアップは物理データを削除するメンテナンスタスクですので、実施後はデータがリポジトリから完全に削除されます。
この場合は、論理削除と違ってディスク使用量も削減されることになります。
※データストアGCも物理削除のメンテナンスタスクになりますが、別の記事で解説したいと思います。

**削除方式とデータ状態**

| 削除方式 | データの状態 |
| --- | --- |
| 論理削除 | AEMの画面操作での削除やバージョンパージなどのメンテナンスタスクによる論理削除を実行することによって、「リポジトリ内に存在しているが無効化されている状態」のデータになります |
| 物理削除 | 物理削除のメンテナンス処理を実行することで、「リポジトリ内に存在しているが無効化されている状態」のデータはリポジトリからも削除されます |

## リビジョンクリーンアップのやりかた
それではこのリビジョンクリーンアップについて具体的な操作方法をご紹介します。

まず、AEMのAuthorにログインした後、左端のメニューにある ツール を選択してください。
![aem_maintenance_operation1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/9dcea896-df9a-fe02-af9e-1b03124294ba.png)
次に、ツール＞運営＞メンテナンス　を選択してください。
![aem_maintenance_operation2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/1bea8c87-b9bd-f3b4-b561-1948ab87abc0.png)
メンテナンスをクリックすると下記のように 週別メンテナンスウィンドウ と 日別メンテナンスウィンドウ に分かれます。AEMでは、「日次」「週次」「月次」でメンテナンス処理を行うことができ、標準では日別と週別が設定できるようになっています。
![aem_maintenance_operation3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/1db05d58-eb18-62c7-8faa-09d740c84fff.png)
手動によるメンテナンス処理の実行
まずは分かりやすくメンテナンス処理実行を理解いただく為に一度手動でメンテナンス処理を実行してみたいと思います。

日別メンテナンスウィンドウをクリックします。
まだ一度もメンテナンス処理が行われていない場合、下記のようにステータスは表示されず灰色で表示されています。
![aem_maintenance_operation4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/f0b637d1-2164-e48f-dbd5-40bec8682f68.png)
今回は物理削除方式である リビジョンクリーンアップ のメンテナンス処理を実行を行います。リビジョンクリーンアップにマウスオーバするといくつかメニューが表示されるため、真ん中に表示される実行をクリックします。
![aem_maintenance_operation5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/345ce0a7-4534-1409-51e5-2b76bdfc7df5.png)

それぞれステータスが変化しますので、その一例を下記に示します。
最終的にはステータスが成功になっていることでメンテナンス処理は問題なく完了できていることを示しています。

実行中
![aem_maintenance_run.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/51373f71-3c52-b97c-fdb5-156c85f15cd1.png)
成功
![aem_maintenance_success.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/6bce5cf2-0775-cfdb-2cfb-3c88e61eb5e6.png)
失敗
![aem_maintenance_Faild.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/d05131ba-1be1-bf90-0248-84549d134bc6.png)

### スケジュールによるメンテナンス処理の実行
上記では手動での実行のやりかたを記載しましたが、日々の運用では手動でメンテナンス処理を行うことはほとんどなく、それぞれのメンテナンスウィンドウで定義されているスケジュールに基づいて行われます。

標準では下記のように設定されています。

|メンテンスウインド|標準実行時間|
|---|---|
|日別|毎日 2:00〜5:00|
|週別|毎週土曜日 1:00〜2:00|

標準のスケジュールでは上記時間で定義していますが、運用環境によっては変更することも可能です。
変更する場合には該当メンテナンスウィンドウにマウスオーバーし「メンテナンスウィンドウを設定」から開始・終了時間を変更することができます。

ただし、リビジョンクリーンアップは、他の処理が行われていない方が高速かつ効率的になりますので、実行時間は負荷が低い時間帯にスケジュールすることをお勧めします。

![aem_maintenance_operation7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61030/f5ff3690-d404-9c7b-bd94-571964ea6943.png)

## まとめ
以前、メンテナンスタスクを定期的に動かしているお客様の環境でディスク使用量が増大し続けており、詳細を調査したところ、長期間に渡ってリビジョンクリーンアップを止めたままにしていたといった事例がありました。
経緯はわからなかったのですがリビジョンクリーンアップは不要だ、と判断して意図的に止めていたようです。

このように、メンテナンスを怠ってしまうと、システムの安定に対してリスクを生んでしまうことがあります。
日々の運用にあたっては、定期的にメンテナンスタスクの見直しなども含めていただくことをオススメします。
※他のメンテナンス項目についても、今後Qiitaで紹介していく予定です。

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

##参考リンク
- [リビジョンクリーンアップ](https://experienceleague.adobe.com/docs/experience-manager-65/deploying/deploying/revision-cleanup.html?lang=ja)
- [(MVCC) Understanding the node state model](https://jackrabbit.apache.org/oak/docs/architecture/nodestate.html)