AEM as a Cloud Serviceへの移行 - レプリケーションエージェントの再考

Adobe Experience Manager as a Cloud Serviceへの移行を評価するジャーニーの過程においては、現在のAEMの実装を調べて、非互換性やリファクタリングを必要とする領域がないか確認することが求められます。これらの作業にはドキュメントやコードの確認やBest Practices Analyzer（BPA）ツールの実行が含まれるでしょう。そして確認作業において焦点があたるであろう領域の1つにレプリケーションエージェントがあります。

クラウドサービスより以前の提供形態では、レプリケーションエージェントが様々な場面で使用されていました。今回の投稿ですべてを網羅することはできないと思いますが、こちらのページをご覧いただくと、より多くの利用背景を確認することができます。AEM as a Cloud Serviceとその新しいアーキテクチャではこの領域のルールが変更されています。この記事をご覧になり移行計画の参考にしてください。

オーサーからパブリッシュ

標準的なコンテンツ公開や、オーサー環境からパブリッシュ環境へのコンテンツコピーについては、AEM as a Cloud Serviceの標準実装で処理されます。カスタムエージェントは必要ありません。詳細はこちらのページをご覧ください。

パブリッシュからオーサー

パブリッシュ環境からオーサー環境へのコンテンツレプリケーションを、リバースレプリケーションと言います。こちらの開発ガイドラインを参照すると、AEM as a Cloud Serviceではこの機能がサポートされていないことがわかります。以前の提供形態では、主に、次のいずれかの用途でリバースレプリケーションが使用されています。

最初の用途はUGC（ユーザー生成コンテンツ）のサポートです。AEM as a Cloud Serviceでの代替策としてはUGCをAEMの外部で管理します。AEMはコンテンツの配信のみをコントロールし、UGCは外部システムに保存して、そのシステムとAEMを統合します。

もう一つの用途は、パブリッシュインスタンス間におけるユーザーアカウントの一貫性の確保するためです。例えばサイトで認証が必要な場合は、SAMLを介してユーザーのプロファイルを表すノードとプロパティが、ユーザーが参照しているパブリッシュインスタンスのコンテンツリポジトリに作成されます。その後のセッションで、ユーザーが別のパブリッシュインスタンスにアクセスした場合でも、一貫性を確保するためにプロファイル情報をオーサー環境へリバースレプリケーションし、さらに同じサイト上でサービスを提供する他のパブリッシュインスタンスにレプリケーションします。

こちらのページで説明されている様に、AEM as a Cloud Serviceではこのリバースレプリケーションのスキームを使用していません。/homeフォルダー配下をパブリッシュ層のすべてのノード間で迅速に同期することで、パブリッシュインスタンス間におけるユーザーアカウントの一貫性を実現しています。

Dispatcher フラッシュエージェント

AEM as a Cloud Serviceでは、コンテンツが公開されるとデフォルトでDispatcherのキャッシュから削除される様になっています。カスタムエージェントは必要ありません。詳細な仕様についてはこちらのページをご覧ください。

オーサーから外部システム

他のアプリケーションから利用できるように、静的エージェントを使用してコンテンツをファイルシステムにコピーしている場合、移行前にこれらの再設計が必要です。このユースケースの再設計には主にふたつの選択肢があります：

（1）PushモデルからPullモデルへの変換

外部システムは、AEM as a Cloud Serviceのパブリッシュ層から最新のコンテンツをスケジュール実行や、オンデマンドで取得することができます。

利点：AEMのカスタムコードが不要になり、TTLとキャッシュの設計に基づいて、外部システムがCDNから最新のコンテンツを取得できるようになります。このアプローチはスケーラブルでパフォーマンスが高く、いずれの外部システムとの結合も必要ありません。

（2）I/O イベント統合

外部システム側の制限によりプッシュが唯一の選択肢である場合は、こちら（英語）のページ説明されている様にAdobe I/Oイベント統合を設定して、コンテンツが公開されたときにイベントを送信します。ペイロードは小さいですが、AEMにリクエストを返し、コンテンツを取り出して思い通りに操作するのに十分な情報が含まれています。イベント処理には2つの方法があります。

• Webhook：Webhook (Push モデル) を作成してApp Builder (旧 Project Firefly) のアクションを実行するか、外部システムを直接トリガーすることができます。
• Journal：ジャーナル。外部システムが I/O イベントジャーナル（Pull モデル）からイベントを取得して、イベントを適宜処理します。

複数の外部システムとその要件に基づいて、両方を同時に使用することも可能です。

利点：AEMを外部システムから切り離すことができるため、複数の外部システムが同じイベントを使用することができます。また、非同期型でありPushとPullの両方のモデルをサポートします。

Adobe I/OはCloud Managerでのログのテール（tail）やCommerce Integration Framework（CIF）などで使用されおり、他のシステム統合にも拡張できるので、今回のテーマであるレプリケーションの代替ユースケース以外でも学ぶ価値があるでしょう。

この記事は2021年11月に公開された、Reimagining Replication Agents on AEM as a Cloud Serviceを抄訳したものです。