検出と評価フェーズを完了し、基盤設計を設定したら、ワークロードを移行ウェーブに分類して移行の計画を開始できます。
このドキュメントでは、適切な成功を計画し、関連するリスクを最小限に抑える方法について説明します。
始める前に
移行計画を始める前に、ワークロードの調査と評価を完了し、次のタスクで構成される全体の移行方針を作成します。
- 移行対象として特定したワークロード（アプリケーション、サービス、データベースなど）をカタログ化する。
- ワークロードをインフラストラクチャのコンポーネントにマッピングする。
- 依存関係をマッピングする。
- 大まかな移行とモダナイゼーションの工程（再ホスト、プラットフォームの再構築、リファクタリング、再設計、置き換え、使用停止）を特定する。
次に、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 スループットの要件に基づいた高レベルのサイズ設定など）の改善と最適化を目的とする計画をまとめる役に立ちます。
さらに、検出および評価の取り組みと並行して移行のリスク評価を実行します。その目的は、移行に関連するワークロード固有のリスクを調整、詳細に把握し、適切な緩和アクションを開始することです。以下に、そのようなリスクの例をいくつか示します。
次の図では、移行プロセス全体の概要を示します。
次のステップ
- 移行リスクを評価、軽減する方法を確認する。
- 移行ウェーブを計画する方法を確認する。