このドキュメントでは、移行ウェーブの計画方法について説明します。
移行の候補は、移行ウェーブにグループ化できます。グループ化は、調査フェーズと評価フェーズで収集した情報に基づいて、上位レベル（カテゴリベース）または詳細レベル（アプリケーション、ロケーション、コンポーネント）で行えます。
アプリケーション カタログを作成する
計画を開始するため、アプリケーション カタログを作成します。アプリケーションは、アプリケーション アーキテクチャ、ビジネス上の考慮事項、IT 運用に基づいて各カテゴリに分類します。これにより、クラウドへの移行に伴う、ビジネス上の重要性、複雑さ、リスクに応じて、サービスの優先度が決めることが容易になります。こうした要素の組み合わせと優先順位は、現在のアーキテクチャと将来の Google Cloud アーキテクチャの両方で、組織、ビジネス上の必須事項、およびワークロードに対するこれらの課題のマッピングによって変わります。
次のリストでは、3 つの主なカテゴリと、各カテゴリ内で考慮すべき要素を示します。
アプリケーション アーキテクチャ
- 技術的な制約
- 依存関係の数
- 階層の数
- ステートフルとステートレス
- パフォーマンス要件
- 地理的な依存関係
ビジネス上の考慮事項
- コンプライアンス要件
- ビジネス上の重要度
- ビジネス上の変更の可能性
- ユーザー数
- ユーザーの種類（内部、外部）
- TCO
IT 運用担当者
- 運用環境
- サービスレベル契約
- 可用性
- バックアップ
マッピングと優先順位
アプリケーション カタログから、複雑さとターゲットの移行方法に基づいてアプリケーションを計画します。移行の方法は、予想されるビジネス成果、移行作業、関連するリスク要因（移行中と移行後の両方）に基づいている必要があります。
次に、ビジネス価値と移行に必要な労力に基づき、優先度に従って移行候補をランク付けします。移行の準備をするため、最初に移行される可能性がある機能を持つアプリを特定します。1 つだけ選ぶことも、最初のウェーブに多数のアプリを設定することもできます。最初のウェーブのアプリにより、チームはアプリの複雑さではなく移行に焦点を合わせ、クラウド環境でデプロイをテストできます。
スタンドアロン アプリから始めると、初期のリスクを軽減できます。これは、後でチームの新しい知識を、複雑で多数の依存関係を持つアプリケーションに適用できるためです。
通常、最初のウェーブのアプリは、ビジネス クリティカルではなく、システム間およびネットワーク間の依存関係が少ないものです。また、リファクタリングも少なく、通常はデータ グラビティが小さく、特定のコンプライアンス上の課題がなく、カットオーバー期間に余裕を持てます。詳細については、最初に移行するアプリを選択するをご覧ください。
ウェーブ内のアプリケーションをグループ化する
アプリケーションを、各ウェーブに関連付けられたタイムラインで複数のウェーブにグループ化し、各ウェーブからのフィードバックに基づいて計画を修正する時間を含めます。
- ウェーブ 1: ビジネス価値が高く、実装にかかる労力が少ない。
- これらのアプリケーションは、早期の移行や概念実証に最適です。
- ウェーブ 2: ビジネス価値は高いが、実装にかかる労力が多い。
- 次に優先されるアプリケーション群。
- ウェーブ 3: ビジネス価値が低く、実装にかかる労力が少ない。
- 次に優先されるアプリケーション群。
- ウェーブ 4: ビジネス価値が低く、実装にかかる労力が多い。
- 優先度が最も低いアプリケーション群。
移行ウェーブを定義したら、プロジェクト計画に整理できます。
ベスト プラクティスに従う
移行計画を改善するには、移行計画の検証に関するベスト プラクティスに従います。そこに記載されているコンセプトに従っても、成功が保証されるわけではありません。しかし、次のように移行を計画する際に見落としがちなポイントが説明されています。
- 移行計画のステップごとにロールバック方法を確保する。
- このドキュメントの前で説明した段階的なロールアウトとデプロイの計画。
- ワークロードの移行を担当するすべての開発チームと運用チームにアラートを送る。
- 概念実証リソースとテストをターゲットの本番環境から削除する。
- 移行元の環境を安全に利用停止するための基準を定義する。
- 移行ウェーブごとに移行リスクの評価を実施し、特定されたリスクを軽減する。
次のステップ
- 移行を実行する方法を確認する。