調査と評価フェーズを完了し、基盤の設計を設定したら、ワークロードを移行ウェーブに分類することで、移行計画を開始できます。
このページでは、正常な移行を計画する方法について説明します。
始める前に
移行計画を始める前に、ワークロードの調査と評価を完了し、次のタスクを含む全体的な移行戦略を作成します。
- 移行するワークロード（アプリケーション、サービス、データベースなど）のカタログを作成します。
- ワークロードをインフラストラクチャのコンポーネントにマッピングします。
- 依存関係をマッピングします。
- 大まかな移行とモダナイゼーションの工程（再ホスト、プラットフォームの再構築、リファクタリング、再設計、置き換え、使用停止）を特定します。
次に、Cloud Foundation Toolkit を使用して Google Cloud に基盤を構築します。
Cloud Foundation Toolkit には、新しいクラウド インフラストラクチャにおける以下の側面の開始に役立つリソースが含まれています。
- Identity and Access Management
- リソース管理
- ネットワーキング
- データ マネジメント
- Infrastructure as code
- ロギング、モニタリング、課金
- セキュリティ基盤
- GKE 基盤
移行のコンセプト
クラウド移行プロジェクトは、アプリケーションを Google Cloud に移行するために、組織が従うプロセス全体を表します。
各クラウド移行プロジェクトは、ウェーブに分割されます。ウェーブとは、ワークロードの調査と評価によって特定される、共通の特性や相互依存関係を共有するアプリケーションのグループです。通常、スタンドアロン アプリケーションとデータベースは、外部依存度が低いため、最初の移行ウェーブに適した候補です。一方、依存関係が多いアプリケーションは、さらに計画が必要な複雑な移行ウェーブになります。
移行ウェーブ内のアプリケーションは、移行グループに分けられ、スプリントで Google Cloud に移行されます。移行グループは、一緒に移行する必要があるインフラストラクチャ リソースとワークロードのグループです。これらのリソースとワークロードは、同じアプリケーションまたは相互依存するアプリケーション グループの一部になります。
ビジネス機能は、移行グループを決定する最も重要な側面の 1 つです。たとえば、小売でのサプライ チェーン管理と在庫管理、銀行での不正行為のモニタリング、保険の請求処理など、それぞれのドメインのビジネス機能領域を表します。ビジネス機能を検討し、移行中および移行後にビジネス サービスのパフォーマンスと利用可能性を乱さないようにするか、それを最小限に抑えることが重要です。
ビジネス機能領域内では、さまざまな環境に応じて移行を行う必要があります。通常、研究開発（R&D）環境を最初に移行します。これにより、移行の妨げになる、または移行速度が低下する可能性のある阻害要因を特定して軽減できます。そうして、研究開発、本番前環境、本番環境への移行を進めながら、ベスト プラクティスと軽減作業を行います。
継続的なプロセスとして検出と評価を実行する必要があります。また、データ収集の精度は時間の経過とともに向上していきます。これによって、ワークロード固有のデータの精度を常に改善でき、クラウド移行に関連するワークロード固有のリスクを特定できます。
調査と評価の最初のウェーブでは、インフラストラクチャ コンポーネントとワークロード間の依存関係のハイレベルなマップを作成できます。これにより、最初のウェーブでターゲットの Google Cloud アーキテクチャの要素、たとえば、VM タイプ、ストレージ クラス、ランディング ゾーンの設計、計算量に基づく大まかな容量サイズと、 I/O スループットの要件などを計画し、最適化できます。
また、検出および評価と並行して移行のリスク評価を実行する必要があります。その目的は、移行に関連するワークロード固有のリスクを特定して測定し、適切な緩和策を開始することです。
次の図では、移行プロセス全体の概要を示します。
次のステップ
- 移行リスクを評価、軽減する方法を確認する。
- 移行ウェーブを計画する方法を確認する。