準備段階

AEMas 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 as a Cloud Service Architecture の主な変更点の確認

AEM as a Cloud Service は、AEM プロジェクトを管理するための様々な新機能と可能性を提供します。

これらの改善に加えて、AEM as a Cloud Serviceと比較して、AEMのオンプレミスインストールと Adobe Managed Services の間にいくつかの違いが導入されました。

次の表に示す項目のリストは、AEM as a Cloud Serviceへの移行に最も関連する変更のサブセットです。 主要な変更点の完全なリストは、こちらをご覧ください ここ.

変更点? 参照 重要な留意点
可変フィルターと不変フィルターを対応するパッケージに分割する AEMas a Cloud Serviceの主な変更点
AEM AEM as a Cloud Serviceのプロジェクト構造
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 コンテンツ配布で置き換えられます レプリケーションエージェントの概念は、「コンテンツ配布を使用」に置き換えられます。 レプリケーションエージェントを利用したカスタマイズがある場合は、再設計する必要があります。
リバースレプリケーションはサポートされていません
CRX/DE とパッケージマネージャー CRX/DE は開発環境でのみ使用できます。
パッケージマネージャーにはすべてのオーサーインスタンスでアクセスできますが、デプロイされるパッケージには可変コンテンツのみを含める必要があります ( 例:/content または/conf)
組み込み CDN と独自の CDN の取得 AEM as a Cloud Serviceには、ほとんどの使用例に最適化されたすべての環境の CDN が含まれます。
独自の CDN を設定したい場合、承認を得るには、Adobeサポートにリクエストを送信する必要があります。
承認されると、CDN は Fastly を指し、どの環境のAEMインスタンスを指すのではなくなります。
長時間実行されているジョブ コンテナで実行するAEMインスタンスがいつ来ても移動できるので、Sling スケジューラーや Cron ジョブなどの長時間実行されるジョブは実行しないでください。
これらの機能を再考して、Adobe I/Oにオフロードします。
非同期操作に切り替え 非同期操作の設定 環境の全体的なパフォーマンスを向上させるために、特定の操作が非同期モードで実行されます。 システムリソースが使用可能になると、非同期ジョブはキューに入れられ、実行されます。
トークンベースの認証と統合戦略 サーバー側 API 用のアクセストークンの生成
トークンベースの認証に関するチュートリアル
AEM外のシステムがAEM内で HTTP 操作を実行しようとするのは一般的です。
推奨されるアプローチは、AEMでのパスワードを使用したローカルユーザー名の作成に依存するのではなく、ここで説明する戦略を実装することです。
ファイル I/O/ディスク使用量 割り当てられるディスク容量と、コンテナ内のインスタンスの入れ替えが保証されないので、AEMインスタンスに接続されたディスクに書き込んだり読み取ったりする際に、ファイル I/O 操作を使用することはお勧めしません。
DAM アセットの更新ワークフロー Asset Compute Service DAM アセットの更新ワークフローに含まれるメディア処理ステップが、Asset computeサービスに置き換えられました
AEM as a Cloud Serviceでのアセットのアップロード方法とサポートされるワークフロープロセスステップ API 比較のアップロードとサポートされる WF プロセスステップ AEM as a Cloud Serviceでは、アセットのアップロード中またはダウンロード中に、アセットがバイナリストレージに直接ストリーミングするか、バイナリストレージから直接ストリーミングします。
AEMaaCS では、一部のワークフロープロセスステップがサポートされていません。
ワークフローランチャー コードから、OOTB またはカスタム DAM アセットの更新ワークフローのいずれかをトリガーしているワークフローランチャーをすべて削除します。
AEM as a Cloud Serviceにアップロードされたアセットはすべて、アセット処理サービスによって処理されます。 ワークフロー後処理の OSGi 設定があり、追加のカスタム処理手順のトリガーに使用できます。
カスタムレンディション手順 処理プロファイル カスタムレンディション生成、画像変換、ビデオエンコーディングは、対応する処理プロファイルを作成して、アセット処理サービスにオフロードする必要があります。
コンテンツの検索とインデックス作成 コンテンツの検索とインデックス作成の変更 インデックスの基になる処理と、インデックスが開始されるタイミングに大きな変更があります。
デプロイするコードで Oak インデックスを管理する前に、Oak インデックスを完全に理解し、リファクタリングします。
すべてのメンテナンスタスクが設定可能とは限りません AEMas a Cloud Serviceメンテナンスタスク AEM as a Cloud Serviceでは、特定のメンテナンスタスクのみを設定できます。
発行リポジトリに対する変更 /home 以下のものを除き、パブリッシュリポジトリに直接変更することはできません。 作成者に変更を加え、配布することを常にお勧めします。 すべてのコードと設定の変更は、対応する Cloud Manager パイプラインを通じてデプロイする必要があります。
Dispatcher の設定とキャッシュ クラウド内の Dispatcher
キャッシュ管理
Dispatcher の設定は、特定の構造に従う必要があります。
設定は、コードの一部として管理され、Cloud Manager パイプラインを通じてデプロイする必要があります。
バックアップと復元 AEMas a Cloud Serviceバックアップと復元

非推奨(廃止予定)の機能

アドビでは、製品の機能を絶えず評価して、常に後方互換性を慎重に考慮しながら、古い機能を作成し直したり、より近代的な機能に置き換えて、お客様にとっての全体的な価値を向上させています。

アドビでは、 廃止された機能 を参照して、AEMas a Cloud ServiceExperience Managerで非推奨とマークされている機能について確認し、デプロイメントへの影響を確認してください。

AEMのインストールのレビューの計画

AEM as a Cloud Serviceで導入された変更に慣れたら、既存のインストールのレビューを計画し、クラウドに移行するために必要な変更のレベルを測定するために、今度は既存のインストールのレビューを計画します。

次の図は、レビューフェーズで必要となる主な手順を示しています。

画像

次に、これらの各手順の意味を詳しく説明します。

Cloud Service への対応準備状況の評価

最初の手順は、既存のAEMバージョンからCloud Serviceに移行する準備ができているかを評価し、AEM as a Cloud Serviceとの互換性を保つためにリファクタリングが必要な領域を決定することです。

移行プロセスで予想される作業レベルを決定するには、主な変更点および廃止される機能に照らした現在のAEMソースコードの包括的な評価を実施する必要があります。

結果の数は、タイムラインおよびプロジェクト全体の成功に直接影響します。 したがって、配信を計画したり、AEMのas a Cloud Service的なベストプラクティスに沿ってカスタマイズを行うために必要なデザインを変更するために必要な会話を開始したりする際に、可能な限り明確にすることをお勧めします。

ベストプラクティスアナライザー

現在のAEMバージョンに対してベストプラクティスアナライザーを実行すると、評価を高速化できます。 その仕組みを十分に理解することが、評価計画を迅速に立ち上げるための鍵となります。

その仕組みについては、 ベストプラクティスアナライザー ドキュメント。

Cloud Readiness Assessment レポートの作成

次のステップでは、これまでに得られたすべての知識に基づいてレポートを作成します。 これをおこなうには、ステージインスタンスと実稼動インスタンスからベストプラクティスアナライザーレポートを生成します。 次に、Cloud Acceleration Manager にアップロードします 可能性の高い項目に関する消化可能なレポートを

典型的なレポートには、次の入力情報が含まれます。

  • 特定のAEMインストールの機能セットの詳細を説明するドキュメント
  • AEMカスタム設定およびコードの詳細
  • 実稼動 Dispatcher の設定
  • CDN 設定(存在する場合)

レポートをソーシャル化

ベストプラクティスアナライザーレポートが完了したら、関連するチームと共有して、結果を確認し、次の手順の計画を立てます。 好みに応じて、 印刷プレビュー.

リソース計画のレビュー

Cloud Serviceへの移行に必要な作業レベルを推定したら、リソースを特定し、チームを作成し、移行プロセスに関する役割と責務をマッピングする必要があります。

KPI の設定

主要業績評価指標 (KPI) をまだ設定していない場合は、AEMの実装に関する KPI を設定して、最も重要な項目にチームが専念できるようにすることをお勧めします。

詳しくは、 KPI の開発 ビジネス目標に合った適切な KPI を選択する方法を学ぶ

次の手順

AEM as a Cloud Serviceへの移行に必要な変更の範囲を理解したら、次の手順に従います。 コードとコンテンツクラウドの準備 実際に移行を実行する前に。

その他のリソース

このページ