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