AEM オーサーの不安定性と、不十分なEBS ストレージパフォーマンス（AMS）によって引き起こされる深刻な遅延
この記事では、Adobe Managed Services（AMS）でホストされているAEM オーサーインスタンスで、EBS ボリュームタイプがAEMのTarMK リポジトリのI/O要件を満たさない、繰り返し発生するパフォーマンスの低下と不安定性について説明します。
説明 description
環境
Amazon EBS ストレージでサポートされているAdobe Managed Services（AMS）のTarMK リポジトリを使用したAdobe Experience Managerのデプロイメント。
問題/症状
AEM オーサーインスタンスでは、通常のオーサリングワークロード（以下の1つ以上を含む）で繰り返し不安定になります。
- オーサーUIの応答時間は大幅に遅くなり、標準エディター、シェル、およびCSRF トークン要求の応答時間は1分以上になります。
- 504のゲートウェイタイムアウトと404のエラーが作成者によって報告されました。
- パブリッシュ操作が失敗したか、大幅に遅れました。
- リモート DAMのイベント処理が遅れ、ブロックされる。
次の警告とエラーは、デグレード期間中またはデグレード後にerror.logに表示される場合があります。
*WARN* [ sling-oak-N-org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate-async]
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler
Failed to create checkpoint <uuid> in 10 seconds.
*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnReadDirectory
Couldn't compute safe timestamp to delete files from NIOFSDirectory@/mnt/crx/.../index/.../data
*WARN* [ oak-lucene-N]
org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier
File <segment> doesn't exist in /mnt/crx/.../repository/index/.../data
*WARN* [ sling-default-N-Registered Service.NNNNN]
com.adobe.cq.remotedam.internal.lifecycle.event.consumer.impl.LifecycleEventConsumerImpl
This sites instance is lagging far too behind Remote DAM. Pulling events is blocked
これらの期間にrequest.logを関連付けると、通常、ヘルスチェック、エディター、パルス、およびCSRF トークンのエンドポイントを同時に30秒から数分後に完了するリクエストのクラスターが表示されます。 このパターンは、単一の低速リクエストではなく、JVM全体のストールを示します。
原因
/mnt/crxに格納されているAEMのTarMK リポジトリは、セグメントストアの書き込み、チェックポイントの作成、Lucene インデックスの更新、およびコンパクションに対して、頻繁にシーケンシャルおよびランダムなI/O操作を実行します。 これらのリポジトリワークロードには、一貫したストレージ遅延と十分なIOPSが必要です。
標準的な磁気EBS ボリュームでは、これらのワークロードに対して十分なパフォーマンス特性が得られない場合があります。 ストレージ・スループットが制限されると、オペレーティング・システムはI/O待機を持続させることができ、複数のJVM スレッド・プールが同時に停止し、無関係なリクエストでアプリケーション遅延が広がります。
この問題は、gp3 EBS ボリュームが標準のリポジトリストレージオプションになる前に、もともと磁気EBS ボリュームでプロビジョニングされていた実稼動以外のAMS環境で最も一般的に発生します。 実稼動環境は、gp3 ストレージ上でプロビジョニングされたか、後でgp3 ストレージに移行されたため、多くの場合、影響を受けません。
解決策 resolution
繰り返し発生するAEM オーサーの不安定性、重大な遅延、リポジトリパフォーマンスの問題を特定して解決するには、次の手順に従います。
- 影響を受けるオーサーインスタンスで
/mnt/crxをバックアップするAmazon EBS ボリュームタイプを確認します。 カスタマーサクセスエンジニア（CSE）に連絡して、ボリューム設定を確認し、リポジトリがgp3 EBS ボリュームでホストされているかどうかを判断してください。 - リポジトリが標準の磁気ストレージでホストされている場合は、gp3 EBS ボリュームへの移行を評価します。 AMS契約に基づいて、CSEでサービスやコストの考慮事項を確認します。
- CSEを介したストレージの移行をリクエストします。 AMS インフラストラクチャチームと調整して移行計画を作成し、リポジトリサイズとワークロード要件に基づいてターゲット IOPSとスループット設定を確認します。
- リポジトリーボリュームをgp3 EBS ボリュームに移行します。 AMS インフラストラクチャチームは通常、このプロセスを実行します。AEM インスタンスを停止し、既存のボリュームのスナップショットを作成し、ストレージを移行し、インスタンスを再起動します。
- 同じストレージ設定を使用する場合は、影響を受けるパブリッシャーインスタンスを移行計画に含めます。
- 移行後のシステムパフォーマンスを測定します。 一般的なオーサリングアクティビティ中に、I/O待機、スワップ使用率、および読み込み平均が減少したことを確認します。
request.logを確認し、エディターとユーティリティ エンドポイントに複数秒または1分の応答時間が表示されなくなったことを確認します。error.logを確認し、チェックポイントの失敗メッセージとLucene インデックスの警告が再発しないことを確認します。- オーサーページエディターが正常に読み込まれ、公開操作が正常に完了し、非同期インデックスが最新のままであり、リモート DAM イベントが遅延なく処理されることを検証します。
- 繰り返し発生するパフォーマンスの低下を、大規模なレプリケーションバースト、MSM ロールアウト、パッケージのデプロイ、大規模なアセット取り込みなど、リポジトリを多用するアクティビティと関連付けます。移行後も不安定な状態が続く場合は、これを行います。
- リポジトリの需要がピークに達してもパフォーマンスに影響が続く場合は、影響の大きいワークロードのスケジュールまたはスロットリングを調整します。