リビジョンクリーンアップ

TarMK の永続性形式が AEM 6.5 で変更されます。これらの変更には、事前の移行手順は必要ありません。既存のリポジトリは、周期的な移行を実行します。これはユーザーに対して透過的です。AEM 6.5（または関連ツール）がリポジトリに初めてアクセスすると、移行プロセスが開始されます。

AEM 6.5永続性形式への移行が開始されると、リポジトリを以前のAEM 6.3永続性形式に戻すことはできません。

AEM 6.3では、特にオンラインでのリビジョンクリーンアップのパフォーマンスと有効性を向上させるために、ストレージ形式の変更が必要でした。 この変更には後方互換性がないので、古い Oak セグメント（AEM 6.2 以前）で作成されたリポジトリを移行する必要があります。

ストレージ形式の変更には、他にも次のような利点があります。

• スケーラビリティの向上（セグメントサイズの最適化）
• データストアのガベージコレクションの高速化
  
• 将来の機能拡張に備えた基盤整備

オフラインでのリビジョンクリーンアップでは最新の世代だけを残して他をすべて再利用しますが、オンラインでのリビジョンクリーンアップでは最新の 2 つの世代を残します。新しいリポジトリの場合、オフラインでのリビジョンクリーンアップの実行後に初めてオンラインでのリビジョンクリーンアップが実行されるときには、再利用できる古い世代が存在しないので、領域は再利用されません。

この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。

オンラインでのリビジョンクリーンアップは、AEM 6.3以降のリリースでのみ使用できます。 また、古いバージョンの AEM を使用している場合は、新しい Oak Segment Tar に移行する必要があります。

• リポジトリのサイズ
• システムの負荷（要求数/分、特に書き込み操作）
• アクティビティのパターン（読み取りと書き込み）
• ハードウェアの仕様（CPU の性能、メモリ、IOPS）

オンラインでのリビジョンクリーンアップ中、ディスク領域は継続的に監視されます。使用可能なディスク領域が臨界値を下回ると、プロセスがキャンセルされます。臨界値はリポジトリの現在のディスクフットプリントの 25 ％で、設定はできません。

最初に予測したリポジトリサイズよりも少なくとも 2 倍または 3 倍大きなディスクサイズにすることをお勧めします。

クリーンアッププロセス中、空きヒープ領域が継続的に監視されます。空きヒープ領域が臨界値を下回ると、プロセスがキャンセルされます。重要な値は、org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLDを使用して設定されます。 デフォルト値は 15％です。

推奨されるコンパクションヒープの最小サイズは、AEM のメモリサイズの推奨値と関係があります。原則として、AEM インスタンスのサイズが使用例およびそこで予想されるペイロードに対処するために十分なサイズであれば、クリーンアッププロセスで十分なメモリが確保されます。

• クリーンアップが毎日実行されていることを確認してください。
  
• 操作ダッシュボードでメンテナンスウィンドウを設定し、最小限のリポジトリアクティビティの間に実行されることを確認します。
• システムリソース（CPU、メモリ、I/O）を拡張してください。

リビジョンクリーンアップでは、まず見積もりフェーズによって、クリーンアップが必要なガベージが累積しているかどうかが判断されます。見積もりでは、最後のコンパクション後のリポジトリサイズと現在のサイズを比較します。このサイズが設定されている差分を超えている場合、クリーンアップが実行されます。サイズデルタは1 GBに設定されます。 つまり、前回のクリーンアップ実行以降にリポジトリのサイズが1 GB増加しなかった場合、新しいリビジョンクリーンアップの反復がスキップされます。

見積もりフェーズに関連するログエントリは以下のとおりです。

• リビジョンGCが実行されます：サイズデルタはN%またはN/N （N/Nバイト）なので、コンパクションを実行します
• リビジョンGCは実行されません：サイズデルタはN%またはN/N （N/Nバイト）なので、現時点では圧縮をスキップします

同時書き込みが可能なシステムでは、コンパクションサイクルの終了時に変更をコミットできるように、オンラインでのリビジョンクリーンアップで排他書き込みアクセスが必要になる場合があります。oakのドキュメントで詳しく説明されているように、システムはforceCompactモードに移行します。 強制コンパクション中は、同時書き込みによる干渉を受けることなく最終的に変更をコミットするために、排他書き込みロックが取得されます。応答時間に対する影響を制限するために、タイムアウト値を定義できます。デフォルトでは、この値は 1 分に設定されています。これは、1 分以内に強制コンパクションが完了しない場合、同時コミットが優先されてコンパクションプロセスが中止されることを意味します。

強制コンパクトの時間は、次の要因によって異なります。

• ハードウェア（具体的には IOPS）：IOPS が増えると実行時間が短縮されます。
• セグメントストアサイズ：実行時間はセグメントストアのサイズに伴って増大します。

スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップはどのように実行されますか。

コールドスタンバイセットアップでは、オンラインでのリビジョンクリーンアップの実行を設定する必要があるのは、プライマリインスタンスのみです。スタンバイインスタンスでは、オンラインでのリビジョンクリーンアップを特別にスケジュールする必要はありません。

スタンバイインスタンスでの対応する操作は、自動クリーンアップです。これは、オンラインでのリビジョンクリーンアップのクリーンアップフェーズに対応します。 プライマリインスタンスでオンラインでのリビジョンクリーンアップが実行された後に、スタンバイインスタンスで自動クリーンアップが実行されます。

見積もりフェーズとコンパクションフェーズはスタンバイインスタンスでは実行されません。

オフラインでのリビジョンクリーンアップでは古いリビジョンをすぐに削除できますが、オンラインでのリビジョンクリーンアップでは、古いリビジョンが引き続きアプリケーションスタックによって参照されていることを考慮する必要があります。そのため、オフラインのほうがオンラインよりも積極的にガベージを削除できますが、ガベージコレクションサイクルを数回経ると、この効果は薄れます。

この章の「オフラインでのリビジョンクリーンアップの実行後にオンラインでのリビジョンクリーンアップを実行した場合」の節も参照してください。

• Windows環境では、通常のファイルアクセスが常に適用されるので、メモリマップアクセスは使用されません。一般的なアドバイスとして、使用可能なすべてのRAMをヒープに割り当て、segmentCacheのサイズを増やす必要があります。 segmentCacheを増やすには、 org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.configにsegmentCache.sizeオプションを追加します(例：segmentCache.size=20480)。 オペレーティングシステムや他のプロセスのために、必ずRAMを空にしてください。
• Windows 以外の環境では、物理メモリのサイズを大きくすることで、リポジトリのメモリマップの効率性を向上できます。

• オンラインでのリビジョンクリーンアップが有効な場合は、ディスク領域を監視する必要があります。 ディスク領域が不十分な場合、クリーンアップは実行されないか、早期に終了します。
• オンラインでのリビジョンクリーンアップの完了時間をログで確認します。 これは 2 時間以下である必要があります。
• チェックポイントの数。 コンパクションの実行時にチェックポイントが 4 つ以上ある場合は、チェックポイントをクリーンアップすることをお勧めします。

オンラインでのリビジョンクリーンアップが正常に完了したかどうかを確認するには、ログを確認します。

例えば、「TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles」は、コンパクションステップが正常に完了したことを意味します。前に「TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles」というメッセージが付いていない場合は、同時負荷が多すぎます。

同様に、クリーンアップ手順が正常に完了したことを示すメッセージ「TarMK GC #{}: cleanup completed in {} ({} ms」が表示されます。

ステータス、進行状況および統計は、JMX(SegmentRevisionGarbageCollection MBean)を介して公開されます。 SegmentRevisionGarbageCollection MBeanの詳細については、後の段落を参照してください。

進行状況は、EstimatedRevisionGCCompletion SegmentRevisionGarbageCollection MBean.

MBeanの参照は、ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”を使用して取得できます。

統計は、最後のシステム起動以降にのみ表示されます。 外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部の監視ツールの例として、Nagiosへのヘルスチェックの接続に関するAEMのドキュメントを参照してください。

• オンラインでのリビジョンクリーンアップが開始/停止しました
  • オンラインでのリビジョンクリーンアップは、次の3つのフェーズで構成されます。推定、コンパクション、クリーンアップ。 リポジトリに十分な量のガベージが含まれていない場合は、見積もりによってコンパクションとクリーンアップがスキップされることがあります。AEMの最新バージョンでは、「TarMK GC #{}: estimation started」というメッセージは推定の開始を示し、「TarMK GC #{}: compaction started, strategy={}」は圧縮の開始を示し、「TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes」はクリーンアップの開始を示します。
• リビジョンクリーンアップで得られたディスク領域
  • 領域は、クリーンアップフェーズが完了した場合にのみ再利用されます。 クリーンアップフェーズの完了は、ログメッセージ「TarMK GC #{}: cleanup completed in {} ({} ms」でマークされます。 クリーンアップ後のサイズは {}（{} バイト）で、再利用された領域は {}（{} バイト）です。コンパクションマップの重み付け／深さは {}／{}（{} バイト／{}）です。
• リビジョンのクリーンアップ中に問題が発生しました
  • 多くのエラー状態があり、すべてのエラーが「TarMK GC」で始まるWARNまたはERRORログメッセージでマークされます。

以下のエラーメッセージに基づくトラブルシューティングの節も参照してください。

オンラインでのリビジョンクリーンアップの後は、リポジトリの整合性チェックは必要ありません。

ただし、クリーンアップ後にリポジトリのステータスを確認するには、次の操作を実行できます。

• リポジトリトラバーサルチェック
• クリーンアッププロセスが完了したら、oak-runツールを使用して不整合を確認します。 この方法について詳しくは、Apacheのドキュメントを参照してください。 ツールを実行するためにAEMをシャットダウンする必要はありません。

リビジョンクリーンアップヘルスチェックは、操作ダッシュボード.
の一部です。

オンラインでのリビジョンクリーンアップメンテナンスタスクの最後の実行が正常に完了した場合、ステータスはGREENになります。

オンラインでのリビジョンクリーンアップのメンテナンスタスクが1回キャンセルされると、YELLOWになります。

オンラインでのリビジョンクリーンアップのメンテナンスタスクが3回連続でキャンセルされた場合は、REDになります。 この場合、手動での操作が必要で す。また、オンラインでのリビジョンのクリーンアップは再び失敗する可能性が高くなります。詳しくは、以下のトラブルシューティングの節を参照してください。

また、システムを再起動した後にヘルスチェックのステータスがリセットされることに注意してください。 そのため、新たに再起動されたインスタンスでは、リビジョンクリーンアップヘルスチェックで緑色のステータスが示されます。外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。外部の監視ツールの例として、Nagiosへのヘルスチェックの接続に関するAEMのドキュメントを参照してください。

スタンバイインスタンスで自動クリーンアップを監視する方法

SegmentRevisionGarbageCollection MBeanを使用して、ステータス、進行状況および統計をJMX経由で公開します。 次のOakのドキュメントも参照してください。

MBeanの参照は、ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”を使用して取得できます。

統計は、前回のシステム起動以降にのみ表示されます。 外部の監視ツールを利用すると、AEM の稼動時間外もデータを監視できます。また、外部の監視ツールの例として、Nagiosへのヘルスチェックの接続については、AEMのドキュメントを参照してください。

ログファイルを使用して、自動クリーンアップのステータス、進行状況、統計を確認することもできます。

スタンバイインスタンスでの自動クリーンアップ中に監視する必要があるのは何ですか。

• 自動クリーンアップを実行する場合は、ディスク領域を監視する必要があります。
• （ログを介して）完了時間が経過し、2時間を超えないようにします。
• 自動クリーンアップの実行後のセグメントストアのサイズ。 スタンバイインスタンスでのセグメントストアのサイズは、プライマリインスタンスでのサイズとほぼ同じである必要があります。

• まず、ログエントリを確認します。
  
• ログの情報に基づいて、適切な操作を実行します。
  • ログに5回のミスコンパクトサイクルとforceCompactサイクルのタイムアウトが表示される場合は、リポジトリの書き込み量が少ないときに、メンテナンスウィンドウを静かな時間にスケジュールします。 https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.htmlにあるリポジトリ指標監視ツールで、リポジトリの書き込みを確認できます。
  • メンテナンスウィンドウの終わりにクリーンアップが停止した場合は、メンテナンスタスクのユーザーインターフェイスで、メンテナンスウィンドウの長さの設定が十分であることを確認してください。
  • 使用可能なヒープメモリが不足している場合は、インスタンスに十分なメモリがあることを確認してください。
  • 応答が遅い場合は、セグメントストアが大きくなりすぎて、メンテナンスウィンドウを長くしてもオンラインでのリビジョンクリーンアップを完了できない可能性があります。例えば、先週、オンラインでのリビジョンクリーンアップが一度も正常に完了してない場合は、セグメントストアを対処可能なサイズに戻すために、オフラインでのメンテナンスを計画し、オフラインでのリビジョンクリーンアップを実行することをお勧めします。

SegmentNotFoundExceptionは、TarMKが見つからないストレージユニット（セグメント）にアクセスしようとすると、TarMKによってログに記録されます。 次の 3 つのシナリオで、この問題が発生する可能性があります。

1. アプリケーションが、推奨されるアクセス方法（Sling や JCR API など）を使用せずに、下位レベルの API／SPI を使用してリポジトリにアクセスし、セグメントの保持時間を超えている場合。つまり、アプリケーションがオンラインでのリビジョンクリーンアップで許可される保持時間（デフォルトは 24 時間）よりも長くエンティティへの参照を保持している場合です。この状況は一時的で、データの破損にはつながりません。回復するには、oak-runツールを使用して、例外の一時的な特性を確認する必要があります（oak-runチェックではエラーは報告されません）。 これをおこなうには、インスタンスをオフラインにし、後で再起動する必要があります。
2. 外部イベントによってディスクのデータが破損している場合。これは、ディスクの障害、ディスク領域の不足または必要なデータファイルが誤って変更されたことが原因である可能性があります。この場合は、インスタンスをオフラインにして、oak-run チェックを使用して修復する必要があります。oak-runチェックの実行方法の詳細については、次のApacheドキュメントを参照してください。
3. その他すべての問題は、Adobeカスタマーケアを通じて対処する必要があります。

クリーンアップの実行時間は、リポジトリサイズとクリーンアップする必要があるリビジョンの数によって決まります。

• Oakリビジョン： Oakは、ノードとプロパティで構成される大きなツリー階層ですべてのコンテンツを整理します。このコンテンツツリーの各スナップショットまたはリビジョンは不変で、ツリーに対する変更は一連の新しいリビジョンとして表されます。通常は、コンテンツが変更されるたびに新しいリビジョンがトリガーされます。リンク先も参照してください。
• ページバージョン： バージョン管理では、特定の時点でのページの「スナップショット」が作成されます。通常は、ページがアクティベートされたときに新しいバージョンが作成されます。詳しくは、ページバージョンの使用を参照してください。