運用開始 go-live
ジャーニーのこのステップでは、コードとコンテンツの両方を AEM as a Cloud Service に移行する準備ができた後で移行を計画して実行する方法を説明します。また、移行を実行する際のベストプラクティスと既知の制限事項についても説明します。
これまでの説明内容 story-so-far
ジャーニーのこれまでのフェーズでは、
目的 objective
このドキュメントでは、ジャーニーのこれまでのステップをよく理解した後で AEM as a Cloud Service への移行を実行する方法を説明します。実稼動環境の初期移行を実行する方法と、AEM as a Cloud Service への移行時に従うべきベストプラクティスについて説明します。
初期の実稼動環境移行 initial-migration
実稼動環境の移行を実行する前に、実装フェーズの「コンテンツ移行の戦略とタイムライン」セクションに従って移行手順の準備と検証を行ってください。
-
クローンで実行された AEM as a Cloud Service ステージ移行時に得た経験に基づいて、実稼働環境からの移行を開始します。
- オーサー - オーサー
- パブリッシュ - パブリッシュ
-
AEM as a Cloud Service のオーサー層とパブリッシュ層の両方に取り込まれたコンテンツを検証します。
-
取り込みが完了するまでソースと移行先の両方のコンテンツが移動しないようにコンテンツオーサリングチームに指示します。
-
新しいコンテンツの追加、編集、削除はできますが、移動は避けてください。これは、ソースと移行先の両方に適用されます。
-
完全な抽出と取り込みに 要した時間 を記録して、将来の追加移行のタイムラインを見積もります。
-
オーサーとパブリッシュの両方に対して 移行プランナー を作成します。
増分追加 top-up
実稼働環境からの最初の移行を行ったら、クラウドインスタンス上でコンテンツを最新の状態にするために、増分追加を実行する必要があります。このため、次のベストプラクティスに従うことをお勧めします。
- コンテンツの量に関するデータを収集します。例：1 週間ごと、2 週間ごと、1 か月ごと。
- 48 時間を超えるコンテンツ抽出および取り込みを避けるように、追加を計画します。この方法は、コンテンツ追加が週末の時間枠に収まるようにするために推奨されます。
- 必要な追加数を計画し、それらの見積もりを使用して開始日を計画します。
移行にともなうコードおよびコンテンツの凍結タイムラインの特定 code-content-freeze
前述のように、コードとコンテンツの凍結期間をスケジュールする必要があります。凍結期間の計画に役立てるため、次の質問を使用します。
- コンテンツのオーサリングアクティビティを凍結する必要がある期間はどのくらいですか？
- 配信チームに新機能の追加を停止するように依頼する必要がある期間はどのくらいですか？
最初の質問に答えるには、実稼動環境以外での試験的実行に要した時間を考慮してください。2 つ目の質問に答えるには、新しい機能を追加するチームと、コードをリファクタリングするチームとの緊密なコラボレーションが必要です。目標は、既存のデプロイメントに追加されているすべてのコードが、クラウドサービス分岐にも追加、テスト、デプロイされるようにすることです。一般に、コードフリーズの量が少なくなることを意味します。
また、最終的なコンテンツ追加がスケジュールされたときに、コンテンツの凍結を計画する必要があります。
ベストプラクティス best-practices
移行を計画または実行する際は、次のガイドラインを考慮してください。
-
オーサーからオーサーへの移行とパブリッシュからパブリッシュへの移行
-
次の用途に使用できる実稼働クローンをリクエストします。
- リポジトリー統計のキャプチャ
- 移行アクティビティの検証
- 移行計画の準備
- コンテンツ凍結要件の特定
- 実稼動環境から移行する際に、実稼動環境でのアップサイズのニーズを特定する
コンテンツ転送ツールのベストプラクティス
運用を開始する際は、クローンではなく実稼動環境でコンテンツ移行を実行するようにしてください。最初の移行に AZCopy を使用してから、追加抽出を頻繁に（毎日でも）実行して、より小さなチャンクを抽出し、ソース AEM への長期的な負荷を避けるのが良いアプローチです。
実稼動環境の移行を実行する場合は、次の理由により、コンテンツ転送ツールをクローンから実行しないでください。
- 顧客が追加移行時にコンテンツバージョンを移行する必要がある場合、クローンからコンテンツ転送ツールを実行しても、バージョンは移行されません。クローンがライブ作成者から頻繁に再作成された場合でも、クローンが作成されるたびに、差分の計算にコンテンツ転送ツールで使用されるチェックポイントがリセットされます。
- クローン全体を更新することはできないので、ACL クエリパッケージを使用して、追加または編集するコンテンツをパッケージ化して実稼動環境からクローンにインストールする必要があります。このアプローチの問題は、ソースインスタンス上の削除されたコンテンツは、ソースとクローンの両方から手動で削除しない限り、クローンに到達しないことです。これにより、実稼動環境で削除されたコンテンツがクローンや AEM as a Cloud Service で削除されない可能性が生じます。
コンテンツ移行中の AEM ソースの負荷の最適化
抽出段階では、AEM ソースの負荷が大きくなることに注意してください。以下の点に注意してください。
- コンテンツ転送ツールは、4 GB の JVM ヒープを使用する外部 Java プロセスです
- 非 AzCopy バージョンのバイナリはダウンロードされ、ソース AEM 作成者上の一時的な領域に保存され、ディスク I/O を消費した後、ネットワーク帯域幅を消費する Azure コンテナーにアップロードされます
- AzCopy は、BLOB を BLOB ストアから Azure コンテナーに直接転送します。このコンテナーは、ディスク I/O とネットワーク帯域幅を節約します。AzCopy バージョンでは、引き続きディスクとネットワーク帯域幅を使用して、セグメントストアから Azure コンテナーにデータを抽出してアップロードします
- コンテンツ転送ツールプロセスは、取り込みログをストリーミングするだけで、ディスク I/O やネットワーク帯域幅に関してはソースインスタンスに大きな負荷がかからないので、取り込み段階ではシステムリソースの方が軽くなります
既知の制限事項 known-limitations
抽出された移行セットの一部として以下の制限が見つかった場合、取り込み全体が失敗することを考慮してください。
- 名前が 150 文字を超える JCR ノード
- 16 MB を超える JCR ノード
- 抽出されて取り込まれたアセットが、次の移行処理の前に、ソースまたは宛先で別のパスに移動する場合
アセットの正常性 asset-health
上記の節と比較すると、以下のアセットの問題が原因で取り込みが失敗することは ありません。ただし、次のシナリオでは、適切な手順を実行することを強くお勧めします。
- 元のレンディションがないアセット
jcr:contentノードが欠落しているフォルダー。
上記の両方の項目が識別され、ベストプラクティスアナライザーレポートで報告されます。
公開チェックリスト Go-Live-Checklist
詳しくは、公開チェックリストのドキュメントを参照してください。
次の手順 what-is-next
AEM as a Cloud Service への移行の実行方法を理解したら、運用開始後ページを開いて、インスタンスのスムーズな実行を維持できます。