AEM as a Cloud Service 移行ジャーニーのこの段階では、AEM as a Cloud Service について理解し、導入された主な変更点を確認し、クラウドへの移行を成功に導くためのプランに必要な事項を理解します。
前のドキュメント AEM as a Cloud Service への移行の手引き では、AEM as a Cloud Service に移行するために必要な段階のリストと、その利点について説明しました。
このドキュメントでは、AEM インストールをクラウドに移動する準備ができていることを確かめるために考慮が必要な点を確認します。
AEM as a Cloud Service は、AEM プロジェクトを管理するための様々な新機能と可能性を提供します。
これらの改善に伴い、AEM as a Cloud Service と比較して、AEM のオンプレミスインストールと Adobe Managed Services の間にいくつかの違いが導入されました。
次の表の項目リストは、AEM as a Cloud Service への移行に大きく関わる変更点を集めたものです。主な変更点の完全なリストについては、 こちら を参照してください。
変更点 | 参照 | 重要な留意点 |
---|---|---|
可変フィルターと不変フィルターを対応するパッケージに分割する | AEM as a Cloud Service の主な変更点 AEM as a Cloud Service の AEM プロジェクト構造 |
AEM as a Cloud Service にデプロイできる単一のパッケージには、サブパッケージを含めることができます。主に、独自のパッケージに分けられた可変コンテンツと不変コンテンツを含めるために使用します。 |
Repo Init | Apache Sling RepoInit ドキュメント | Repoinit スクリプトは、最初のノード構造、ユーザー、グループ、またはサービスユーザーを作成するためのベストプラクティスです。これらのスクリプトは、実行モードによってターゲット設定され、コードパッケージのデプロイメントによって管理可能なので、リポジトリの初期化タスクを柔軟に実行できます。 |
カスタム実行モードは許可されていません | AEM as a Cloud Service で標準で提供されている実行モードのみがサポートされます。 さらに開発環境が追加されると、すべての環境が「開発」実行モードに結び付けられます。 |
|
Cloud Manager パイプラインの実行は、デプロイする唯一の方法です | AEM as a Cloud Service では、/system/console へのアクセスは許可されていません。したがって、すべての OSGi 設定はコードの一部である必要があり、コードとしてデプロイする必要があります。 OSGi 設定は読み取り専用モードで使用でき、Cloud Manager を通じて開発者コンソールで表示できます |
|
レプリケーションエージェントは Sling コンテンツ配信で置き換えられます | レプリケーションエージェントの概念は Sling コンテンツ配信で置き換えられます。レプリケーションエージェントを利用したカスタマイズがある場合は、再設計する必要があります。 リバースレプリケーションはサポートされていません |
|
CRX/DE とパッケージマネージャー | CRX/DE は開発環境でのみ使用できます。 パッケージマネージャーにはすべてのオーサーインスタンスでアクセスできますが、デプロイされるパッケージには可変コンテンツのみを含める必要があります(例:/content または /conf) |
|
組み込み CDN と独自の CDN の取得 | AEM as a Cloud Service には、ほとんどの使用例に最適化されたすべての環境用の CDN が含まれています。 独自の CDN を設定する場合、アドビサポートにリクエストを送信して承認を得る必要があります。 承認されると、CDN は Fastly を指し、どの環境の AEM インスタンスも指しません。 |
|
長時間実行されているジョブ | コンテナで実行されている AEM インスタンスはいつでも出入りする可能性があるため、Sling スケジューラーや Cron ジョブなどの長時間実行されるジョブは実行しないでください。 これらの機能を再考して、Adobe I/O にオフロードします。 |
|
非同期操作に切り替え | 非同期操作の設定 | 環境の全体的なパフォーマンスを向上させるために、特定の操作が非同期モードで実行されます。システムリソースが使用可能になると、非同期ジョブはキューに入れられ、実行されます。 |
トークンベースの認証と統合戦略 | サーバーサイド API 用のアクセストークンの生成 トークンベースの認証に関するチュートリアル |
AEM 外のシステムが AEM 内で HTTP 操作を実行しようとするのは一般的です。 推奨されるアプローチは、AEM でのパスワードを使用したローカルユーザー名の作成に依存するのではなく、ここで説明する戦略を実装することです。 |
ファイル I/O とディスク使用量 | 割り当てられるディスク容量は保証されておらず、コンテナ内のインスタンスの入れ替えが発生するので、AEM インスタンスに接続されたディスクに書き込んだり読み取ったりする際に、ファイル I/O 操作を使用することはお勧めしません。 | |
DAM アセットの更新ワークフロー | Asset Compute サービス | DAM アセットの更新ワークフローに含まれるメディア処理ステップが、Asset Compute サービスに置き換えられました |
AEM as a Cloud Service でのアセットのアップロード方法とサポートしているワークフロープロセスの手順 | API 比較のアップロードとサポートされる WF プロセスステップ | AEM as a Cloud Service では、アセットのアップロード中またはダウンロード中に、アセットがバイナリストレージに直接ストリーミングするか、バイナリストレージから直接ストリーミングします。AEMaaCS では、すべてのワークフロープロセスの手順がサポートされているわけではありません。 |
ワークフローランチャー | OOTB、またはカスタム DAM アセットの更新ワークフローのいずれかをトリガーしているワークフローランチャーをコードから削除します。AEM as a Cloud Service にアップロードされたアセットはすべて、アセット処理サービスによって処理されます。カスタム手順については、後処理ワークフローで後処理ワークフローのセットアップおよび設定方法を参照してください。 | |
カスタムレンディション手順 | 処理プロファイル | カスタムレンディション生成、画像変換、ビデオエンコーディングは、対応する処理プロファイルを作成して、アセット処理サービスにオフロードする必要があります。 |
コンテンツの検索とインデックス作成 | コンテンツの検索とインデックス作成の変更 | インデックス作成の基になる処理と、インデックス作成が開始されるタイミングに大きな変更があります。 デプロイするコードで Oak インデックスを管理する前に、Oak インデックスを完全に理解し、リファクタリングします。 |
すべてのメンテナンスタスクが設定可能とは限りません | AEM as a Cloud Service メンテナンスタスク | AEM as a Cloud Service では、特定のメンテナンスタスクのみを設定できます。 |
公開リポジトリに対する変更 | /home の下にあるものを除き、公開リポジトリを直接変更することは許可されていません。作成者を変更して配布することを常にお勧めします。すべてのコードと設定の変更は、対応する Cloud Manager パイプラインを通じてデプロイする必要があります。 | |
Dispatcher の設定とキャッシュ | クラウド内の Dispatcher キャッシュ管理 |
Dispatcher の設定は、特定の構造に従う必要があります。 設定は、コードの一部として管理され、Cloud Manager パイプラインを通じてデプロイする必要があります。 |
バックアップと復元 | AEM as a Cloud Service のバックアップと復元 | |
認証の変更 | AEM as a Cloud Service の IMS サポート | Cloud Service に移行する前に、オーサーとパブリッシュの両方で SAML 2.0 統合を使用していた場合、主な変更点は、AEM as a Cloud Service オーサーが Adobe IMS のみと統合される点です。ただし、AEM as a Cloud Service パブリッシュ層では、SAML や他の認証統合を引き続き利用できます。AEM as a Cloud Service では、作成者、管理者および開発者ユーザーに対してのみ IMS 認証をサポートしています。IMS 認証では、サイト訪問者など、顧客サイトの外部エンドユーザーに対してはサポートしていません。 |
アドビでは、製品の機能を絶えず評価して、常に後方互換性を慎重に考慮しながら、古い機能を作成し直したり、より近代的な機能に置き換えて、お客様にとっての全体的な価値を向上させています。
非推奨(廃止予定)の機能 を参照して、Experience Manager as Cloud Service で非推奨(廃止予定)としてマークされている機能を確認し、ご利用の AEM のデプロイメントにどのような影響があるかを確かめることをお勧めします。
AEM as a Cloud Service で導入された変更を把握したら、既存のインストールをレビューする計画に取りかかり、クラウドに移行するために必要な変更のレベルを見定めます。
レビュー段階で必要になる主なステップを次の図に示します。
次に、これらの各手順の意味を詳しく説明します。
最初のステップは、既存の AEM バージョンから Cloud Service に移行する準備ができているかどうかを評価し、AEM as a Cloud Service に対応するためにリファクタリングが必要な領域を判断することです。
移行ジャーニーで予想される作業レベルを決定するには、現在ご利用の AEM ソースコードを、主要な変更点および非推奨(廃止予定)の機能に照らして包括的に評価する必要があります。
評価結果の数は、タイムラインおよびプロジェクト全体の成功に直接影響します。そのため、配信を計画したり、AEM as a Cloud Service のベストプラクティスに沿って必要なカスタマイズを再設計するための会話を開始したりするために、できるだけ多くの評価結果を明らかにすることをお勧めします。
ベストプラクティスアナライザー
現在の AEM バージョンでベストプラクティスアナライザーを実行すると、評価を高速化できます。その仕組みを十分に理解することが、評価計画を迅速に立ち上げるための鍵となります。
その仕組みについては、 ベストプラクティスアナライザー のドキュメントを参照してください。
クラウド対応準備状況アセスメントレポートの作成
次のステップでは、これまでに得られたすべての知識に基づいてレポートを作成します。これを行うには、ステージインスタンスと実稼動インスタンスからベストプラクティスアナライザーのレポートを生成し、 次にそのレポートを Cloud Acceleration Manager にアップロードして、 実行可能なアイテムのわかりやすいレポートを生成します。
典型的なレポートには、次の入力情報が含まれます。
レポートをソーシャル化
ベストプラクティスアナライザーレポートが完了したら、関連するチームと共有して評価結果を確認し、次のステップのプランを立てます。必要に応じて、 印刷プレビュー を使用してレポートの印刷バージョンを配布することもできます。
Cloud Service への移行に必要な労力のレベルを見定めたら、リソースを特定してチームを編成し、移行プロセスに必要な役割と責任を定める必要があります。
主要業績評価指標(KPI)をまだ設定していない場合は、最も重要なことにチームが専念できるように、AEM の実装に関する KPI を設定することをお勧めします。
ビジネス目標に合った適切な KPI を選択する方法については、 KPI の開発 を参照してください。
AEM as a Cloud Service に移行するために必要な変更の範囲を確認したら、実際に移行を実行する前に、コードとコンテンツをクラウド対応にします。