Adobe Experience Manager as a Cloud Service のアーキテクチャの概要

Adobe Experience Manager (AEM) as a Cloud Service は、アーキテクチャが変更されました。

スケーリング

AEM as a Cloud Service には次の機能が追加されました。

  • AEM イメージの数が可変の動的なアーキテクチャ。

動的なアーキテクチャ

このアーキテクチャには次の特長があります。

  • 実際の​トラフィックと​実際の​アクティビティに基づいて、規模が拡大/縮小されます。

  • 必要な場合にのみ個々のインスタンスが実行されます。

  • モジュール型アプリケーションを使用します。

  • デフォルトでオーサークラスターがあるので、メンテナンスタスクのダウンタイムを避けることができます。

これにより、様々な使用パターンに応じた自動スケーリングが可能になります。

様々な使用パターンに応じた自動スケーリング

これを実現するために、AEM as a Cloud Service のインスタンスはすべて同等に作成され、ノード数、割り当てメモリ量、割り当てる処理能力に関して、それぞれ同じデフォルトのサイズ特性を持ちます。

AEM as a Cloud Service では、次の特長を備えたオーケストレーションエンジンを基盤として使用しています。

  • サービスの状態を絶えず監視します。

  • 各サービスインスタンスの規模を、実際のニーズに応じて動的に拡大/縮小します。

このスケーリングは:

  • ノード数と、各ノードに割り当てるメモリ量および CPU 処理能力に適用されます。

  • AEM as a Cloud Service がトラフィックパターンの変更に対応できるようになります。

テナントごとのサービスインスタンスのスケーリングは、次の 2 つの軸に基づいて自動または手動でおこなうことができます。

  • 垂直:一定数のノードに対して、割り当てるメモリ量と CPU 処理能力を増減できます。

  • 水平:指定されたサービスのノード数を増減できます。

環境

メモ

詳しくは、デプロイ - 実行モードを参照してください。

AEM as a Cloud Service は個々のインスタンスとして使用でき、各インスタンスは完全な AEM 環境を表します。

AEMでは、Cloud Serviceとして3種類の環境を使用できます。

  • 実稼動環境:実務担当者向けのアプリケーションをホストします。

  • ステージ環境:単一の実稼動環境に常に 1 対 1 に結び付いています。ステージ環境は、アプリケーションに対する変更が実稼動環境に反映される前に、パフォーマンスや品質に関する様々なテストに使用されます。

  • 開発環境:ステージ環境および実稼動環境と同じランタイム条件で開発者が AEM アプリケーションを実装できます。

    詳しくは、環境の管理を参照してください。

プログラム

新しい AEM プロジェクトは常に 1 つの特定のコードベースに関連付けられ、プロジェクトの設定とカスタムコードをそこに保存できます。この情報はコードリポジトリに保存されています。通常の Git クライアントを通じてアクセスでき、プログラムの新規作成時に提供されます。

AEM プログラムは、次のものを含んだコンテナです。

プログラム要素
コードリポジトリ(Git) 1
ベースラインイメージ(Sites または Assets) 1
ステージ環境と実稼動環境のセット(1 対 1 対応) 0 または 1
非実稼動環境(開発またはデモ) 0~N
各環境のパイプライン 0 または 1

AEM as a Cloud Service では、次の 2 種類のプログラムが最初から使用可能です。

  • AEM Sites as a Cloud Service

  • AEM Assets as a Cloud Service

どちらでも様々な機能を利用できます。オーサー層には、すべてのプログラムのあらゆる Sites 機能および Assets 機能が含まれていますが、Assets プログラムには、デフォルトではパブリッシュ層がありません。

ランタイムアーキテクチャ

この新しいアーキテクチャには、次のような様々な主要コンポーネントがあります。

AEM as a Cloud Service - ランタイムアーキテクチャ

  • AEM Sites as a Cloud Service の場合:

    • 環境ごとに(概要レベルで)オーサー層とパブリッシュ層の概念が引き続き存在します。

    • オーサー層は、1 つのオーサークラスター内の 2 つ以上のノードで構成されます。オーサリングアクティビティに応じて、規模が自動的に拡大/縮小されます。

      • コンテンツ作成者/クリエーターは、AEM オーサー層にログインして、コンテンツの作成、編集、管理をおこないます。

      • オーサー層へのログインは、Adobe IMS(Identity Management System)で管理されます。

      • Assets の統合と処理には、専用のアセットコンピューティングサービスが使用されます。

    • パブリッシュ層は、1 つのパブリッシュファーム内の 2 つ以上のノードで構成されます。ノードは互いに独立して動作できます。各ノードは、AEM パブリッシャーと、AEM Dispatcher モジュールを備えた Web サーバーで構成されます。サイトトラフィックのニーズに合わせて、規模が自動的に拡大/縮小されます。

      • エンドユーザーつまりサイト訪問者は、AEM パブリッシュサービスを通じて Web サイトにアクセスします。
  • AEM Assets as a Cloud Service の場合:

    • アーキテクチャにはオーサリング環境のみ含まれます。
  • オーサー層とパブリッシュ層の両方が、コンテンツリポジトリサービスに対してコンテンツの読み取りと保存をおこないます。

    • パブリッシュ層は、永続性レイヤーからのコンテンツの読み取りのみおこないます。

    • オーサー層は、永続性レイヤーに対するコンテンツの読み取りと書き込みをおこないます。

    • BLOB ストレージは、パブリッシュ層とオーサー層で共有されます。ファイルは​移動されません

    • コンテンツがオーサー層で承認されると、コンテンツをアクティベートできることになるので、コンテンツがパブリッシュ層の永続性レイヤーにプッシュされます。これは、ミドルウェアパイプラインであるレプリケーションサービスを通じておこなわれます。このパイプラインが新しいコンテンツを受け取り、パイプラインにプッシュされたコンテンツを個々のパブリッシュサービスノードでサブスクライブします。

      メモ

      詳しくは、レプリケーションを参照してください。

    • 開発者と管理者は、Cloud Manager を通じて提供される継続的統合/継続的配信(CI/CD)サービスを使用して、AEM as a Cloud Service プリケーションを管理します。これには、Cloud Manager の CI/CD パイプラインを使用したコードおよび設定のデプロイメントが含まれます。監視、メンテナンス、トラブルシューティング(ログファイルなど)に関連するすべての情報が Cloud Manager 内でユーザーに公開されます。

    • オーサー層とパブリッシュ層へのアクセスは、常にロードバランサーを通じておこなわれます。ロードバランサーは、各層のアクティブなノードを常に把握しています。

    • パブリッシュ層では、継続的配信ネットワーク(CDN)サービスも最初のエントリポイントとして使用できます。

  • AEM as a Cloud Service のデモインスタンスの場合、アーキテクチャは簡略化されてオーサーノードが 1 つだけになります。したがって、これは、標準的な開発環境、ステージ環境または実稼動環境のすべての特性を示しているわけではありません。つまり、ダウンタイムが多少発生する可能性があり、バックアップ/復元操作がサポートされていないということでもあります。

デプロイメントアーキテクチャ

AEM as a Cloud Service のインスタンスに対する更新はすべて Cloud Manager で管理されます。これは顧客アプリケーションの作成、テスト、デプロイをおこなう唯一の方法なので、オーサー層とパブリッシュ層の両方に不可欠です。インスタンスの更新は、新しいバージョンの AEM as a Cloud Service の用意ができたときにアドビ側でトリガーできます。また、新しいバージョンの顧客アプリケーションの用意ができたときに顧客側でトリガーできます。

技術的には、これは、デプロイメントパイプラインの概念に基づいて実装され、プログラム内の各環境に関連付けられます。Cloud Manager パイプラインが実行されると、オーサー層とパブリッシュ層の両方に対応する、新しいバージョンの顧客アプリケーションが作成されます。これは、最新の顧客パッケージとアドビの最新ベースラインイメージを組み合わせて実現されます。新しいイメージが正常に作成およびテストされると、Cloud Manager は、ローリング更新パターンを使用してすべてのサービスノードを更新することで、最新バージョンのイメージへのカットオーバーを完全に自動化します。その結果、オーサーサービスまたはパブリッシュサービスのダウンタイムが発生しなくなります。

AEM as a Cloud Service - デプロイメントアーキテクチャ

コンテンツの配布

Adobe Experience Manager as a Cloud Service では、コンテンツの公開の仕組みが変更されました。AEM as a Cloud Service では、以前のバージョンの AEM で使用されていたレプリケーションフレームワークがページの公開(オーサーインスタンスからパブリッシュインスタンスへの変更内容の移動)に使用されなくなりました。

代わりに、AEM as a Cloud Service は、Sling コンテンツ配布機能を使用して、適切なコンテンツを移動するようになりました。これは、AEM ランタイムの外部にある Adobe I/O で実行されるパイプラインサービスを使用します。

実行時にパブリッシュノードが追加、削除またはリサイクルされた場合の自動的なセルフサービス設定など、セットアップは自動化されています。

1 回の公開または非公開リクエストに複数のリソースを含めることができますが、その場合は、すべてのリソースに適用される単一のステータスが返されます。つまり、AEM パブリッシュサービスですべてのリソースについてリクエストが成功するか、すべてのリソースについて失敗するか、のどちらかです。これにより、AEM パブリッシュサービス内でリソースの一貫性が必ず保たれるようになります。

コンテンツ配布アーキテクチャの概要図

コンテンツ配布アーキテクチャの概要図

主な技術発展

AEM as a Cloud Service の新しいアーキテクチャでは、以前の世代と比べて、以下に示す根本的な変更と革新が導入されています。

  • すべてのファイル(BLOB)は、クラウドデータストアに直接アップロードされ、クラウドデータストアから直接提供されます。関連するビットストリームは、AEM オーサーサービスおよびパブリッシュサービスの JVM を経由しません。その結果、AEM オーサーサービスおよびパブリッシュサービスのノードのサイズを小さくすることができ、迅速な自動スケーリングの期待に応えることができるようになります。実務担当者にとっては、これにより、画像やビデオなどをアップロードおよびダウンロードする際の操作性が向上します。

  • コンテンツの公開で構成されるすべての操作に、サブスクリプションパターンに従ったパイプラインが含まれるようになりました。公開済みコンテンツは、パイプライン内の様々なキューにプッシュされ、パブリッシュサービスのすべてのノードがそれらのキューをサブスクライブします。その結果、パブリッシュサービスのノード数をオーサー層が把握している必要はなくなり、パブリッシュ層の迅速な自動スケーリングが可能になります。

  • パブリッシュノードのライフサイクルを自動化するために、ゴールデンマスターの概念が導入されました。ゴールデンマスターは特別なパブリッシュノードで、エンドユーザーからはアクセスされません。パブリッシュサービスのすべてのノードがゴールデンマスターから作成されます。圧縮などのメンテナンス操作は、ゴールデンマスターに関連付けられているコンテンツリポジトリに対して実行されます。パブリッシュノードは毎日リサイクルされ、定期メンテナンスは必要ありません。以前は、特にオーサーインスタンスの場合、このようなメンテナンスには多少のダウンタイムが必要でした。

  • アーキテクチャでは、アプリケーションのコンテンツをアプリケーションのコードと設定から完全に切り離しています。すべてのコードと設定は実質的に不変で、オーサーサービスとパブリッシュサービスの様々なノードの作成に使用されるベースラインイメージに組み込まれています。その結果、各ノードが同一であることが完全に保証され、コードと設定の変更は Cloud Manager パイプラインの実行によってのみグローバルにおこなえます。

このページ