現在表示中:

AEM プロジェクトの概要

AEM は、何百万人ものユーザーにサービスを提供するような、影響の大きいデプロイメントで使用されることがよくあります。ほとんどのケースでは、AEM インスタンス上にカスタムアプリケーションがデプロイされ、さらに複雑な構成になっています。このようなデプロイメントをアップグレードするときには、入念な計画が必要です。

ここでは、アップグレードの計画で明確な目標、フェーズ、成果物を定める際に役立つ情報を示します。全体的なプロジェクトの実行とガイドラインに重点を置き、実際のアップグレード手順を詳しく説明しますが、入手可能な技術リソースを参照するよう指示する場合もあります。このドキュメントの解説と、入手可能な技術リソースを併せてお読みください。

AEM アップグレードプロセスでは、プランニング、分析および実行のフェーズと、各フェーズで定義される主要成果物を慎重に扱う必要があります。

前提

このガイドの主なテーマは 5.6.x から 6.2 へのアップグレードですが、Oak ベースのリポジトリへの移行についても取り上げます。ただし、AEM バージョン 5.4 から 6.2 に直接アップグレードすることも可能です。5.3 以下のバージョンを実行しているユーザーは、まず、バージョン 5.4 以上にアップグレードする必要があります。

このガイドでは、次のようなソーストポロジとターゲットトポロジを想定しています。

5.6.x 以降の変更点

アップグレードを計画する際に考慮すべき、AEM 5.6.1 から 6.2 までの主な変更点を以下に示します。

  • AEM 6.0 で、新しい Jackrabbit Oak リポジトリが導入されました。Persistence Manager は、マイクロカーネルで置き換えられました。バージョン 6.1 から CRX2 がサポートされなくなりました。リポジトリを 5.6.1 のインスタンスから移行するには、crx2oak という移行ツールを実行する必要があります。詳しくは、CRX2OAK 移行ツールの使用を参照してください。
  • リビジョンの定期的ガベージコレクションと、データストアのガベージコレクションは、一定期間ごとに実行する必要がある定期メンテナンスタスクです。これらのタスクの設定方法については、リポジトリの保守を参照してください。
  • インデックスは、自動的には作成されません。使用するクエリに対して、カスタムインデックスを手動で作成する必要があります。
  • 作成者と公開者が共有するデータストアは完全にサポートされています。

 

6.2 での変更点について詳しくは、こちらの詳細なリリースノートを参照してください。

アップグレードの範囲と要件

一般的な AEM アップグレードプロジェクトで影響を受ける領域の一覧を以下に示します。

コンポーネント 影響 説明
オペレーティングシステム

不明確だが影響はわずか

AEM をアップグレードするときに、オペレーティングシステムもアップグレードすべき場合があり、多少の影響が考えられます。

Java Runtime

AEM 6.2 には JRE 1.7.x(64 ビット)以降が必要です。

コンテンツリポジトリ(CRX または Oak)

AEM 6.2 では CRX2 をサポートしていないので、Oak(CRX3)への移行が必要です。移行には crx2oak ツールを使用します。

AEM コンポーネント/コンテンツ

/libs/apps はアップグレードで容易に処理できますが、/etc には追加の作業が必要です。

AEM サービス

ほとんどの AEM コアサービスは、アップグレードのテスト済みです。これは影響の小さい領域です。

カスタムアプリケーションサービス

小~大

アプリケーションとカスタマイズの内容によっては、JVM や、オペレーティングシステムのバージョン、インデックス関連の変更に影響がある可能性があります。Oak ではインデックスが自動的に生成されないからです。

カスタムアプリケーションコンテンツ

小~大

アップグレードで処理されないコンテンツは、アップグレードの実行前にバックアップしておき、リポジトリに戻すことができます。大部分のコンテンツは、移行ツールを使用して処理できます。

注意:

ほとんどの AEM のアップグレードはインプレースアップグレードとして実行されるので、アップグレードにはオーサー層とパブリッシュ層のダウンタイムが必要になります。

アップグレードのベストプラクティス

  • バージョン 5.4 以降を使用している場合は、AEM 6.2 に直接アップグレードできます。バージョン 5.3 を使用している場合は、まず AEM 6.0 にアップグレードしてから、6.2 にアップグレードする必要があります。
  • すべてのアプリケーションとカスタムコードが引き続き希望どおりに動作することを確認するには、正確な実稼動環境を複製し、アップグレード後にその環境でテストを実行する必要があります。すべてのカスタマイズを元に戻し、パフォーマンス負荷およびセキュリティのテストを実行する必要があります。
  • 使用している AEM バージョンのアドビサポートの適用範囲を確認する
  • 新機能を活用する機会を探す
  • リリースノートの廃止および削除された機能の一覧を確認する
  • JCR API の前のバージョンとの違いを確認する
  • アップグレードプロジェクトには、実装、回帰、包括的テスト、ダウンタイム、立ち上げおよび実稼動環境での運用の計画を含める必要があります。
  • テストで得られた見解に基づいて、様々な方法でカスタムコードを最適化できます。リポジトリを走査するコードのリファクタリング、カスタムインデックス作成、JCR での順序なしノードの使用などの最適化が含まれます。
  • CRX2 から Oak への移行に要するコンテンツ移行時間を評価する
  • アップグレードテストに基づく TarMK の追加スペース要件を考慮する

AEM 6.2 の技術要件

詳しくは、AEM 6.2 の技術要件ページを参照してください。

AEM 6.2 のテスト要件

アップグレードをテストするための包括的なテスト計画を作成し、以下を含める必要があります。

  • AEM 実装とすべての関連カスタムコードのテスト
  • 他の Marketing Cloud ソリューションとの統合
  • サードパーティシステムとの統合
  • ページ読み込み時間を含むパフォーマンステスト
  • AEM アプリケーションとカスタマイズのコア機能テストに加え、テスト計画で扱ういくつかの重要項目
  • カスタムインデックスとカスタムクエリのテスト
  • カスタムクエリの検索パフォーマンス
  • コンテンツの作成とオーサリング
  • タッチ操作向け UI の機能
  • インスタンス監視の設定
  • メンテナンスアクティビティ
  • バックアッププロセス
  • 障害回復計画

AEM アップグレードプロジェクトのフェーズ

AEM アップグレードプロジェクトは、いくつかの主要なフェーズに分けることができます。

フェーズ 重要なアクティビティ

評価およびプランニング

  • 必要なプロジェクト範囲を識別する
  • カスタマイズと影響を識別する
  • スケジュールと日付を考慮してアップグレード計画を作成する
  • AEM 実装、他の Marketing Cloud ソリューションとの統合、サードパーティシステムおよびパフォーマンスをテストするためのテスト計画を作成する

アップグレードの準備

  • 実稼動以外の環境でテストアップグレードを実行する
  • パフォーマンステストを含む、アップグレードテスト計画を実行するカスタムアプリケーションと統合をテストする 

アップグレードの実行

  • AEM の実稼動インスタンス上で実行する実際のアップグレード手順と立ち上げイベント

アップグレード後のアクティビティ

  • アップグレード後のスモークテスト、監視およびメンテナンスタスク

評価およびプランニング

フェーズの前提条件

アップグレードの範囲と要件を確認する

フェーズの成果物

影響評価レポート、アップグレードスケジュール、アップグレードテスト計画、AEM 6.2 開発計画

  • 評価およびプランニング段階では、アップグレードの影響と範囲を定義し、アップグレードタスク用のチームを明確にします。カスタムコードのアップグレードや新しいカスタムインデックスの作成などのタスクの影響と労力を正確に評価するための最適な方法は、開発環境のクローンを作成してアップグレードし、事前にテストを実行することです。
  • AEM 実装を移行するための開発作業を評価し、開発者が作業する重要な領域を識別します。
  • 実稼動環境をアップグレードする前に、ステージング環境でのアップグレードをテストするためのテスト計画ドキュメントを作成します。

評価およびプランニングのチェックリスト

ID

タスクの説明

評価

1

AEM のアップグレードに関連するビジネス要件と技術要件を確認する

2

AEM プラットフォームへのオンボーディングのために計画されたプロジェクトのロードマップを確認する

3

現在および将来のアーキテクチャ、ハードウェア、インフラストラクチャ、サーバー環境を確認する

4

適切なアップグレードオプションを選択するためにダウンタイムの許容範囲を評価する

5

分類、タグ付け、テンプレート、コンポーネント、ページ、コンテンツの標準を確認する

6

現在の AEM ワークフローモデルとカスタムプロセスを分析する

7

アップグレードがコンテンツ構造に与える影響を評価する

8

テンプレート、コンポーネント、サービスおよびアドオンと新しい AEM バージョンの上位互換性を検証する

8b

移行ツールを使用してスムーズに移行できるリポジトリの部分を判断するためにリポジトリクローン分析を実行する

8c

開発者環境の迅速なアップグレードと、コードやインデックスの最適化に必要な作業レベルを知るための基本的なスモークテストを実行する(強く推奨)

9

アップグレード戦略、実行計画、潜在的なリスク領域、ギャップとそれを埋めるための緩和計画に関する推奨事項を提示する

9b

  • 6.2 でリリースされる機能を確認する
  • コミュニケーションおよびトレーニング要件を決定する。フォローアップを実行し、レビューに基づいてドキュメントを更新する

10

計画されたアップグレードタイムラインを守ることを含め、アップグレードの成功基準を定義する

プランニング

11

カスタマー IT 部門と業務部門のリーダーが、アップグレードに関する以下のマイルストーンの日付を決定する
  • 開発計画とテスト計画の準備完了
  • 開発環境のアップグレード
  • AEM 6.2 のコード変更の完了
  • QA テストおよび修正サイクル
  • QA による認定
  • ステージング環境のアップグレード
  • 統合、パフォーマンスおよび負荷テスト
  • ステージング環境の認定

12

アップグレードの成功基準を満たさない場合のロールバック戦略を定義する

13

ロールバック戦略の確認を含む、開発計画およびテスト計画を作成する

14

詳細なアップグレード手順と、アップグレードの評価およびプランニング手順の出力に基づいて、プロジェクト固有のアップグレードランブックを作成する

アップグレードプロジェクトの準備

フェーズの前提条件

テスト計画、6.2 開発計画

フェーズの成果物

6.2 に対応したアプリケーションコード、QA/開発/ステージング環境のアップグレードの認定

アップグレードプロジェクトの準備は、主として開発、QA およびステージング環境のアップグレードと、これらのインスタンスでのテスト計画の実行に関するものです。アップグレードの実行方法について詳しくは、アップグレード手順に関するドキュメントを参照してください。

ID

タスク名

開発環境のアップグレード

1.      

実稼動用のコードを使用して 5.6.1 環境をセットアップする

2.      

アップグレード手順に従って、環境内のインスタンスをアップグレードする

3.      

開発計画に従って、コードとインフラストラクチャを環境に合わせて 6.2 に対応させる。この作業は、AEM 実装への影響によって数週間から数ヶ月かかる場合がある

4.      

開発フェーズ後に AEM 実装でユーザー受け入れテストを実行し、発生したすべてのバグを申告および修正する

5.      

ソース管理に対して 6.2 環境実装用の開発フェーズでの変更をコミットする。現在のバージョンに対してアクティブな開発作業がある場合は、必要に応じて個別のソース管理ブランチを使用する

マイルストーン:6.2 向けの開発の完了

QA による認定

6.      

実稼動環境の最新コンテンツで QA 環境のクローンを作成する

7.      

QA 環境を 6.2 の最新コードにアップグレードする

8.      

すべての主なアップグレード手順の期間と全体の期間を測定する

9.      

ロールバック戦略を含むテスト計画に基づいて、テストと修正サイクルを進める。関連する問題があれば、アドビに報告する

10.   

QA サイクル - 環境を認定する

11.   

開発/アドビ QA サポート

マイルストーン:QA によって認定された開発環境

ステージング環境のアップグレード

12.   

実稼動環境の最新コンテンツでステージング環境のクローンを作成する

13.   

ステージング環境を 6.2 の最新コードにアップグレードする

14.   

すべての主なアップグレード手順の期間と全体の期間を測定する

15.   

テストを実行し、ロールバック戦略を含む統合、パフォーマンス、負荷テストの修正サイクルを開始する

16.   

ソース管理に対して 6.2 環境用の修正または変更をコミットする

17.   

QA から認定を得る

18.   

開発/アドビ QA サポート

19.   

QA およびステージングのアップグレードに基づいて、予測されるアップグレード期間とタイムラインを定義する。タイムラインと得られた教訓でランブックを更新する

マイルストーン:認定されたステージング環境

アップグレードプロジェクトの実行

フェーズの前提条件

完全なパフォーマンステストと負荷テストによるステージング環境アップグレードの認定

フェーズの成果物

6.2 の実稼動環境

アップグレードプロジェクトの実行とは、実稼動環境のアップグレードおよび立ち上げを指します。このフェーズの前提条件は、ステージング環境(実稼動環境の正確なコピーであることが必要)が同じアップグレードを経て、すべてのテストが実行され、報告されたすべてのバグが修正されていることです。

ID

タスク名

実稼動環境のアップグレード

1.      

計画されたアップグレード期間に基づいて特定された日時で実稼動環境のカットオーバー/詳細なプランニングをおこなう

2.      

オーサリングアクティビティを停止し、以下のようなアップグレード手順に従って実稼動環境のアップグレードのセットアップを開始する
  • 動作中のインスタンス(オーサーまたはパブリッシュ)のイメージをコピーまたは作成する(これらのイメージは後でバックアップに使用)
  • レプリケーションキューとカスタムログインモジュールを無効化する
  • メンテナンスタスクを実行する
  • ターゲットオーサーおよびパブリッシュインスタンス上のコンテンツの自動移行を実行する
  • レプリケーションキューおよびカスタムログインモジュールの再有効化と、推奨されるホットフィックスのインストールを含む、実際のアップグレード手順を実行する

3.      

スモークテストを実施する

4

実稼動インスタンスを認定する

アップグレード後のアクティビティ

フェーズの前提条件

実稼動環境のクリーンアップグレードの成功

フェーズの成果物

パフォーマンステストと実稼動環境の検証、定期的なメンテナンスタスク

ID

タスク名

期間

所有者:顧客 | AGS | パートナー | 管理サービス

役割:ビジネス | 開発者 | 運用

実稼動後の手順

1

カットオーバー後:実稼動環境の検証

 

 

2

リビジョンのクリーンアップ(コンパクション)とデータストアのガベージコレクションをおこなう定期的メンテナンスをスケジュールする

 

 

3

アップグレード後にステージング環境で実行したときと同じように、パフォーマンステストを再度実施し、インデックス作成戦略を再考する必要があるかどうかを確認する

 

 

4

デコミッションアクティビティ

 

 

アップグレード手順

このトポロジをもう少し詳しく見てみましょう。オーサーインスタンスのコンテンツが、レプリケーションによってパブリッシュインスタンスにコピーされます。

アップグレードを実行すると、トポロジ上で以下のシーケンスがおこなわれます。

  1. 新しいコンテンツのオーサリングを停止する
  2. レプリケーションを停止する
  3. ライブラリまたはコアコンポーネントに対するすべてのカスタマイズは移行時に上書きされるので、すべてのインスタンスリポジトリをバックアップする
  4. Oak の移行を含め、オーサーインスタンスを 6.2 にアップグレードし、起動する
  5. Oak の移行を含め、パブリッシュインスタンス 1 を 6.2 にアップグレードし、起動する
  6. Oak の移行を含め、パブリッシュインスタンス 2 を 6.2 にアップグレードし、起動する
  7. 必要に応じて、Web サーバー上の Dispatcher モジュールをアップグレードする
  8. レプリケーションキューを有効にする

アップグレード手順の要約

アップグレード手順は次のように要約できます。

注意:

* 規制に関する懸念事項がない限り、ワークフローをパージすることを強くお勧めします。

** オーサーインスタンスとパブリッシュインスタンスをすべてアップグレードしたら、レプリケーションエージェントを有効にします。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー