ウェーブプランニング

基本的に、ウェーブプランは移行スケジュールであり、他のプロジェクト計画アクティビティと似ています。管理可能なグループを作成し、リスクを軽減し、それらのグループを中心にアクティビティを整理する手段として、移行ウェーブを使用することをお勧めします。

効果的で信頼性の高い移行ウェーブプランを作成するには、アプリケーションポートフォリオ、関連するインフラストラクチャ (コンピューティング、ストレージ、ネットワーク）、依存関係マッピング、移行戦略の全体像を把握する必要があります。

ソフトウェアとインフラストラクチャコンポーネントのコレクションをグループ化する形式のビジネスアプリケーションに加えて、他のグループレベルを使用できます。ウェーブは最も高いグループレベルです。ウェーブ内で、依存関係グループを作成できます。このタイプのサブグループには、複数のアプリケーションを含めることができます。たとえば、低レイテンシーなどの技術的な依存関係のために同時に移行する必要がある 2 つ以上のアプリケーションなどです。次に、その依存関係グループ全体が管理されます。複数の依存関係グループをウェーブに割り当てることができます。次に、ウェーブ全体またはウェーブ内の個々の依存関係グループに移行日を割り当てることができます。移行日は、そのグループが現在の場所で停止され、アクティブになる日時です AWS。

移行ウェーブには複数のアクティビティがあります。ウェーブをフェーズごとに整理し、フェーズごとに予想される期間を設定することをお勧めします。以下のフェーズが例として役立ちます。

移行ウェーブには事前定義された期間はなく、労力と複雑さのレベルによって異なります。移行ウェーブは 6～10 週間以内に維持することをお勧めします。アプリケーションコンポーネントを完全に書き換えるなど、より多くの時間が必要な場合、通常、移行ウェーブの外でより適切に処理されます。

成功を測定し、進捗状況を追跡するには、ウェーブを成果とビジネスドライバーに合わせる必要があります。これは、ウェーブ期間とウェーブに含まれる依存関係グループにも影響します。ウェーブの完了には、測定可能なアチーブメントを反映する必要があります。

移行ウェーブを整理する方法は複数あります。次の表に、最も一般的なウェーブ組織オプションを示します。これらは通常結合されます。

 アプリケーションポートフォリオのベースラインの確立に関するセクションでは、技術的な依存関係の 4 つのカテゴリについて説明しました。これらの依存関係は、移行ウェーブの作成と依存関係グループの定義に役立ちます。依存関係グループは、依存関係の重要度によって決まります。さらに、非技術的な依存関係も考慮する必要があります。例えば、アプリケーションのリリーススケジュール、メンテナンスウィンドウ、主要な営業日 (月末や四半期末の処理など) は、ウェーブプランに影響を与える可能性があります。

依存関係がソフトかハードかを判断します。ソフト依存関係は、2 つ以上のアセット間の関係、またはアセットから制約への関係であり、コンポーネントの場所には依存しません。たとえば、同じローカルネットワーク (または同じインフラストラクチャ) で動作する 2 つのシステムを分割するには、一方のシステムをクラウドに移動し、もう一方をオンプレミスのままにします。ハード依存関係は、2 つ以上のアセット間の関係、またはアセットから制約への関係であり、場所によって異なります。例えば、同じローカルネットワークで動作し、アプリケーションサーバーとデータベースサーバー間の通信の低レイテンシーに大きく依存する 2 つのシステムには、強い依存関係があります。これらのシステムの 1 つだけをクラウドに移動すると、機能またはパフォーマンスの問題が発生し、解決できません。同様に、リソースの可用性 (移行を実行するチームなど) や運用上の制約 (2 つのシステムを特定の期間にのみ移行できるメンテナンスウィンドウなど) などの非技術的な理由によって、これらのアセットに厳しい依存関係が生じる可能性があります。

移行ウェーブプランを作成するには、依存関係を分析して依存関係グループを決定します。理想的には、特殊な検出ツールなどの信頼性の高いデータソースから決定します。この情報とアプリケーションの優先順位付け基準および運用状況を組み合わせてください。

技術的な依存関係の特定は困難です。複数のデータポイントが必要であり、すべてを含むデータソースはありません。例えば、検出ツールからprocess-to-process通信情報を取得することはできますが、ソフト依存関係とハード依存関係に分類するのは困難です。レイテンシー耐性は、ネットワークデータのみから判断することも困難です。

以下の手法は、実際の依存関係を決定する曖昧さに対処するのに役立ちます。

AWS Transform は、依存関係を分析し、ウェーブプランニングを実行するのに役立ちます。

ウェーブプランの作成

アプリケーションのウェーブを移行するための前提条件は、アプリケーションポートフォリオデータと、ウェーブで移行されるアプリケーションのグループの詳細なアプリケーション評価です。詳細な評価には、ウェーブ内のアプリケーションのリスト、関連するインフラストラクチャの詳細、ターゲット設計、各アプリケーションの移行戦略を含める必要があります。 

ウェーブの所有権とガバナンスを確立することは、ウェーブ作業、プログラムの依存関係、変更管理、問題、リスクを管理および追跡するために重要です。計画を管理するためのガバナンスフレームワークが整っていることを確認します。

ウェーブプランの概要を表示するには、デフォルトのウェーブコンストラクトから始めます。ウェーブ内で何が起こりますか? 初期入力が定義されたら、ウェーブを開始できます。通常、アクティビティは次のようになります。 

これらの各アクティビティにかかる時間は、スコープの複雑さ、波の容量、関係者、および固有の状況によって決まります。可能な限り、遅延や移行ブロッカーの影響を軽減するため、ウェーブを小さくすることをお勧めします。チームで、ウェーブのデフォルト期間を決定します。

次に、日付を分析して、空のウェーブの初期高レベル構造を作成します (まだアプリケーションが割り当てられていません）。以下の質問を検討してください。

これらの考慮事項を考慮して、ウェーブを計画にプロットします。移行プロセスを高速化するには、可能な限り波を重ねることをお勧めします。波が重複する鍵は、波内で何が起こるかを定義して検討することです。通常、デプロイアクティビティ、ターゲットインフラストラクチャの検証、データ同期はウェーブの前半に行われます。後半では、実際の移行、テスト、運用の引き渡しに焦点を当てます。つまり、プロセスの半分ごとに異なるチームが関係し、ある程度の効率を得ることができます。例えば、ターゲットインフラストラクチャの準備に関与したチームが作業を完了するとすぐに、次のウェーブの要件に取り組むことができます。一般的に、移行に対するファクトリのようなアプローチを容易にするために、ほとんどの波の長さと構造が似ていることをお勧めします。ただし、ウェーブプランニングプロセスでは、特定のウェーブのサイズを拡張して、依存関係や運用要件を満たすことができます。 

次に、特定された依存関係グループに基づいて、含めることができる依存関係グループの数の観点からウェーブの最大サイズを決定します。波のサイズは通常、リスク選好度 (許容できる並列変更の量など) とリソースの可用性 (使用可能なリソース、スキル、予算で実行できる並列変更の量など) によって決まります。ただし、早期計画中は、リソースの要件と可用性によって制限しないでください。複数の依存関係グループを含むウェーブは、将来の反復で小さなウェーブに分解できます。

特定のウェーブの依存関係グループを確認したら、ウェーブを移行するためのリソース要件を確認します。リソース要件に基づいてウェーブサイズ (含まれる依存関係グループの数) を調整することを検討してください。これにより、波が小さくなったり大きくなったりする可能性があります。必要に応じて、すべてのウェーブが定義されるまでウェーブプランを繰り返します。プロセス全体でサポートするスペシャリストを提供できる AWS プロフェッショナルサービスまたは AWS 移行コンピテンシーパートナーと連携することを検討してください。

変更の管理

アプリケーションと関連するインフラストラクチャのポートフォリオは、移行プログラムのライフサイクル中に変更されます。長時間実行される移行プログラムは、通常のビジネスの進化と変化と共存します。アプリケーションは、移行を待つにつれて進化し続けます。サーバーは追加または削除され、新しいインフラストラクチャはオンプレミスにデプロイされます。ウェーブグループまたは依存関係グループの範囲を変更する必要があります。特に、移行日が近づいた場合、以前に不明な依存関係が特定された場合、または新しいサーバーがインベントリに含まれている場合は、変更が必要です。これは、移行自体中に発生することがあります。

スコープの変更は、依存関係グループとウェーブに影響します。変更を処理し、影響を最小限に抑えるには、スコープ制御メカニズムを確立することが重要です。スコープ変更管理メカニズムには、スコープの単一の信頼できるソースの定義が必要です。これは、移行プログラムのガバナンスで定義されているように、スコープを管理するためのツール、または .csv ファイル、スプレッドシート、またはデータベースである場合があります。関係者がアクションを実行できるように、変更を特定し、影響を分析し、変更を関係者に伝える必要があります。ウェーブプランは結果として反復されます。