翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タスク 5: ウェーブプランニングプロセスの定義
ウェーブプランニングは、大規模な移行における重要なマイルストーンです。ウェーブプランでは、インフラストラクチャとアプリケーションの依存関係 (共有データベースなど）、アプリケーションの優先度、アプリケーションアーキテクチャの類似性、ビジネス機能を考慮して、同様のアプリケーションをグループ化します。次に、アプリケーションチームおよびインフラストラクチャチームとともにウェーブプランを確認し、指定された移行およびカットオーバー期間中の可用性を確認します。
さまざまな AWS お客様の実際のデプロイに基づいて、ウェーブプランニングのベストプラクティスを以下に示します。
+ 少なくとも 4～5 波の移行ウェーブを計画します。これにより、移行ワークストリームに常に十分なサーバーを確保できます。
+ フェイルファスト。いくつかの低複雑さのアプリケーションから始めて、学習内容を後の波に適用する必要があります。
+ 早期ウェーブ (ウェーブ 1～5) では、少数のサーバー (10 未満）、低複雑さのアプリケーション、および開発環境やテスト環境などの低頻度の環境のアプリケーションを選択します。進行するにつれて、段階的に複雑になり、より多くのサーバーがウェーブに導入されます。
+ ウェーブプランニングは継続的なプロセスであり、1 回限りのタスクではありません。すべてのウェーブを一度に計画しないでください。
+ ポートフォリオ検出ツールを使用していて、複雑なスコアリング機能がある場合は、ウェーブプランニングで使用します。複雑さが最も低いアプリケーションを最初に移行します。
このタスクは、次のステップで構成されます。
+ [ステップ 1: 移動グループプロセスを定義する](#wave-planning-1)
+ [ステップ 2: ウェーブプランニングの選択基準を定義する](#wave-planning-2)
+ [ステップ 3: ウェーブプランニングプロセスを完了する](#wave-planning-3)
## ステップ 1: 移動グループプロセスを定義する
このステップでは、application-to-server依存関係を特定し、移動グループとして一緒に移動するサーバーを決定するために使用されるルールを定義します。*移動グループは*、グループ内で一緒に移動する必要があるサーバーまたはアプリケーションのブロックです。これは移行ウェーブの構成要素であり、各ウェーブは各移動グループのサーバー数に応じて 1 つ以上の移動グループで構成されます。
### アプリケーションの依存関係を特定する
移動グループに相互依存するアプリケーションをグループ化する際の重要な考慮事項を次に示します。
+ 次のようなインフラストラクチャの依存関係を考慮します。
+ アプリケーションには複数のデータベースがあり、それらのデータベースは他のアプリケーションと共有できます。
+ アプリケーションは別のアプリケーションに依存している可能性があります。
+ サーバーは、複数のアプリケーションのデータベースをホストする場合があります。
+ 次のようなビジネスおよび運用上の依存関係を考慮します。
+ ビジネスへの影響や運用スケジュール (バックアップやパッチ適用など) により、アプリケーションは特定の期間にのみ移行できます。
+ アプリケーション所有者は 1 つの移行カットオーバーウィンドウにのみ使用できるため、所有者のすべてのアプリケーションが同じ移動グループに存在する必要があります。
アプリケーションワークショッププロセスまたはターゲット状態を定義したときに、インフラストラクチャの依存関係を特定しました。自動プロセスまたは手動プロセスを使用して、インフラストラクチャの依存関係を特定できます。インフラストラクチャの依存関係の識別を自動化するには、Flexera One Cloud Migration and Modernization や TDS TransitionManager などの検出ツールを使用できます。手動プロセスの場合は、アプリケーションチームとインフラストラクチャチームで CMDB 情報を検証します。
アプリケーションワークショッププロセスでビジネスと運用の依存関係を特定しました。
独自のウェーブプランニングランブックを構築するための出発点として、ポートフォリオプレイ*ブックテンプレートに含まれているウェーブプランニング (Microsoft Word 形式) に Runbook* テンプレートを使用することをお勧めします。 [samples/portfolio-playbook-templates.zip](samples/portfolio-playbook-templates.zip)移行の依存関係を次のように文書化します。
1. ウェーブプランニングランブックを開きます。
1. *アプリケーションの依存関係* セクションで、依存関係を記録します。タイプ (インフラストラクチャ、ビジネス、または運用）、依存関係、依存関係の簡単な説明を特定します。
1. ウェーブプランニングランブックを保存します。
1. ウェーブプランニングランブックの依存関係を維持します。進行するにつれて、新しい依存関係を特定できます。
次の表は、依存関係の例を示しています。
****
| タイプ | 依存関係 | 説明 |
| --- | --- | --- |
| インフラストラクチャ | データベース | データベースが他のアプリケーションと共有されている |
| インフラストラクチャ | ファイルストア | アプリケーションは、デカップリングできる中央ファイルストアを使用するか、関連するすべてのアプリケーションを一緒に移行する必要があります。 |
| インフラストラクチャ | アプリケーション | アプリケーションは、抽出、変換、ロード (ETL) ジョブなど、機能する他の 1 つ以上のアプリケーションに依存します。 |
| ビジネス | ビジネスの停止 | アプリケーションの特定の承認済み停止ウィンドウ |
| 運用中 | パッチウィンドウ | 移行カットオーバーに影響を与える可能性のあるパッチ適用などのスケジュールされた運用タスク |
### 移動グループルールを定義する
ウェーブプランニングランブックに依存関係を記録したら、それらの依存関係に基づいて移動グループルールを構築する必要があります。これらのルールは、サーバーを移動グループにグループ化する方法を制御します。ルールを構築するには、次の手順に従います。
1. 前のセクションで定義した依存関係を確認します。
1. アプリケーションを移動グループ内で一緒に移動する必要があるかどうかに影響する依存関係を選択します。すべての依存関係でアプリケーションを一緒に移行する必要があるわけではありません。たとえば、Microsoft Active Directory へのインフラストラクチャの依存関係は、すべてのアプリケーションに共通する依存関係であるため、移動グループを定義するときに考慮しないでください。アプリケーションを移行する前に、クラウドにドメインコントローラーを構築する必要があります。
1. アプリケーションを一緒に移動する必要がある依存関係を移動グループルールに変換します。
アプリケーションがいずれかのルールに一致する場合、関連付けられたすべてのサーバーを同じ移動グループに配置して、一緒に移行する必要があります。
移行の移動グループルールを次のように文書化します。
1. ウェーブプランニングランブックを開きます。
1. *グループルールの移動*セクションで、移動グループルールを優先度順に記録します。
1. ウェーブプランニングランブックを保存します。
1. ウェーブプランニングランブックのルールを維持します。進行するにつれて、新しいルールを特定できます。
次の表は、移動グループルールの例を示しています。
****
| ルール | グループルールの移動 |
| --- | --- |
| 1 | 共有データベースを持つアプリケーションは一緒に移行する必要があります。 |
| 2 | 同じアプリケーション所有者を持つアプリケーションは、一緒に移行する必要があります。 |
| 3 | 同じパッチウィンドウを持つアプリケーションは一緒に移行する必要があります。 |
## ステップ 2: ウェーブプランニングの選択基準を定義する
移動グループを確立したら、移行ウェーブを形成するために、同様の移動グループをまとめて収集する必要があります。このステップでは、各ウェーブに対して 1 つ以上の移動グループを選択するために使用する基準を定義します。
ウェーブプランニングを成功させるには、各移動グループのサイズを理解することが不可欠です。目標は、移行が俊敏性を維持し、サーバーの正常なパイプラインを維持するために、各ウェーブのサイズを調整することです。大きすぎるウェーブは移行計画の変更に適応するのが難しく、小さすぎるウェーブは、必要な移行速度を実現するのに十分なサーバーを提供しない可能性があります。
ウェーブのサイズを設定するときは、次の基準を考慮することをお勧めします。
+ **小さな最初の波** – 初期波は 10 台未満のサーバーで小さくする必要があります。その後、各波のサーバー数を徐々に増やすことができます。これにより、迅速に失敗し、学習した教訓に基づいて構築できます。たとえば、20 台のサーバーでアプリケーションを移行する前に、3 台のサーバーでアプリケーションを移行します。
+ **リソース** – 移行チームが 1 つのウェーブで移行できるサーバーの数を特定します。標準的な対策は、4 人のアーキテクトの移行チームが、リホストパターンのために 1 週間に最大 50 台のサーバーを移行できることです。移動グループを組み合わせて、移行チームのキャパシティを超えない移行ウェーブを形成します。
+ **** 俊敏性 – ウェーブは移行計画の変更に適応する必要があります。サーバーを再スケジュールする必要がある場合は、影響を受けるサーバーの移動グループ全体を再スケジュールできます。
+ **ストレージサイズ** – 小さいアプリケーションを最初に移行します。たとえば、2 TB のアプリケーションの前に 100 GB のアプリケーションを移行します。
+ **アプリケーション環境** – 開発環境やテスト環境などの下位環境のアプリケーションを、本番環境のアプリケーションに移行する前に移行します。
+ **アプリケーションの複雑さ** – 外部依存関係が少なく、複雑さの少ないアプリケーションを最初に移行します。
+ **アプリケーションの重要度** – ミッションクリティカルなアプリケーションの前に、重要でないアプリケーションを移行します。
+ **ユーザーベース** – ユーザーベースが小さいアプリケーションを最初に移行します。たとえば、10,000 人のユーザーを持つアプリケーションの前に、10 人のユーザーを持つアプリケーションを移行します。
+ **ネットワーク帯域幅** – ウェーブのサイズはネットワーク帯域幅を超えることはできません。詳細については、[AWS 「大規模な移行のための Foundation プレイブック」の指示に従って定義した移行](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/)原則を参照してください。
ウェーブプランニングの選択基準を次のように文書化します。
1. ウェーブプランニングランブックを開きます。
1. *「Wave planning selection criteria*」セクションで、移行に使用する基準を記録します。
1. ウェーブプランニングランブックを保存します。
1. ウェーブプランニングランブックの基準を維持します。進行するにつれて、条件を調整するか、新しい条件を追加する必要がある場合があります。
次の表は、ウェーブプランニング選択基準の例を示しています。
****
| 条件 | 説明 |
| --- | --- |
| 最も複雑でないアプリケーションを特定する | 移動グループの複雑さスコアが高いアプリケーションを特定します。 |
| まず環境を低くする | 開発環境やテスト環境など、下位環境内の重要でないアプリケーションは、最初に移行する必要があります。収益を生み出すアプリケーションなど、本番環境内の重要なアプリケーションは、最後に移行する必要があります。 |
| フェイルファスト | 10 台未満のサーバーで初期ウェーブを形成します。 |
| 移行チームの強み | 各移行チームがカットオーバーできるサーバーの数を特定します。 |
| 同様の移動グループを組み合わせる | 共通性に基づいて移動グループを結合します。たとえば、移動グループは、同じアプリケーション所有者、ソースデータセンター、またはターゲット AWS アカウントを共有する場合があります。 |
| 波のサイズ | ウェーブの合計は 50 サーバーを超えることはできません。 |
### ステップ終了基準
+ ユースケースのウェーブプランニング基準を特定し、ウェーブプランニングランブックに文書化しました。
## ステップ 3: ウェーブプランニングプロセスを完了する
移動グループの作成方法を定義し、移動グループを移行ウェーブに結合するために使用する基準を確立したので、ウェーブを計画するプロセスを定義する必要があります。このステップでは、ウェーブプランニングランブックを更新してウェーブプランニングプロセス全体を記録し、チームがウェーブ情報の記録に使用できるダッシュボードツールがあることを確認します。
このステップでは、提供された *Dashboard テンプレートをウェーブプランニングと移行に使用する*ことをお勧めします。このテンプレートは、[ポートフォリオプレイブックテンプレート](samples/portfolio-playbook-templates.zip)で入手できます。このテンプレートは、ポートフォリオチームを支援するように設計されており、データを照合するための出発点として機能し、アプリケーションポートフォリオの分析、application-to-server依存関係の特定、最終的には移行ウェーブの計画に役立ちます。このテンプレートは、環境に応じて変更できます。
ウェーブプランニングプロセスを次のように文書化します。
1. *ウェーブ計画と移行用の Dashboard テンプレート*を開きます。
1. ユースケースに応じてダッシュボードを変更します。たとえば、サーバーインベントリを抽出するためのワークシートを追加したり、新しいピボットテーブルやグラフを追加したり、 `VLOOKUP`関数を使用してソース情報をインポートしたりできます。
1. ダッシュボードテンプレートを保存します。
1. ウェーブプランニングランブックを開きます。
1. *ステージ 2: ウェーブプランニングを実行する*セクションで、ユースケースのニーズに合わせて提供される標準プロセスを変更します。
1. ウェーブプランニングランブックを保存します。
1. ウェーブプランニングランブックをチームと共有してレビューします。
1. ウェーブプランニングランブックでプロセスを維持します。このプロセスは、大規模な移行のウェーブを計画するための標準的な運用手順として機能します。
## タスク終了条件
+ ウェーブプランニングランブックに以下を文書化しました。
+ アプリケーション依存関係
+ 優先度順にリストされたアプリケーション移動グループルール
+ ウェーブプランニングの選択基準
+ ウェーブプランニングプロセス