移行を実行する

移行を計画したら、実行フェーズに進むことができます。このドキュメント以降では、移行の実行に使用できる方法とツールの組み合わせについて説明します。

始める前に

最初の移行準備

クラウド移行プロジェクトは、ワークロードの Google Cloud への移行を推進する大きな組織的取り組みです。

各移行プロジェクトは、ウェーブ に分けられます。ウェーブとは、ワークロードの調査と評価によって特定される、共通の特性や相互依存関係を共有するアプリケーションのグループです。通常、スタンドアロン アプリケーションとデータベースは、外部依存度が低いため、最初の移行ウェーブに適した候補です。一方、相互依存性が高いワークロードは、さらに計画が必要な複雑な移行ウェーブになります。この場合、移行計画を調整して、相互依存によるビジネスへの影響を確認し、移行を妨げる可能性のある要因を取り除く必要があります。

移行ウェーブ内のワークロードは、移行グループに分けられ、スプリントで Google Cloud に移行されます。移行グループは、一緒に移行する必要があるインフラストラクチャ リソースとワークロードのグループです。これらは、同じアプリケーションか相互に依存するアプリケーション グループの一部になります。

すべてのスプリントでは、次の作業を行う必要があります。

  • 移行に必要なツールを準備して統合する。
  • スプリント計画を作成する。
  • スプリント計画を実行する。

移行のプロセスと手法

スプリント計画とハンドブック

スプリント計画で、スプリントごとに分類された移行ウェーブを実行する方法を定義します。以下に挙げる構成要素を考慮してハンドブックを作成します。

# 項目 説明
0 移行ツールのアーキテクチャ 移行ファクトリーを構成するツールのアーキテクチャ（継続的な評価、ウェーブ計画の改良、ワークロード固有の移行、ビルド、テスト、デプロイ、モニタリング用のツール）
1 移行チェックリスト 移行スプリントの前、および移行スプリント中に使用するチェックリスト
2 在庫 Google Cloud に移行するワークロードのリスト
3 スプリント ランブック 各ワークロードの移行の実行ガイドライン
4 移行プラン 移行スプリントで実行する段階的な移行計画（プロセス）
5 ネットワークとセキュリティのルール Google Cloud の上り（内向き）と下り（外向き）のファイアウォール ルールの一覧
Google Cloud への移行時における DNS の変更
6 リスクと軽減 移行スプリント中に生じうるリスクとその軽減策
7 テストと検証 機能要件と非機能要件を検証するテストプラン
8 ロールバック プラン ワークロード別のロールバック手順
9 チーム構成 チーム構成と名簿（連絡先情報を含む）
10 ガバナンス 移行実行チームの RACI マトリックス、ケイデンスとレポート、エスカレーション解決メカニズム

移行の実施

移行の計画と準備フェーズが完了しましたので、このセクションでは、Google Cloud への繰り返し実施できる移行と検証の方法について説明します。

移行実行サイクル

評価

評価の最初の作業は、移行計画フェーズで発生し、ワークロードとインフラストラクチャ コンポーネントの依存関係に関するデータが生成されます。次に挙げる観点で関連するデータを再調整し拡充するには、クラウド移行プロジェクト全体にわたって調査と評価を継続する必要があります。

  • アプリケーションとデータベースのマッピングからインフラストラクチャのマッピングへ（ビジネス ワークロードのすべてのインフラストラクチャとプラットフォーム コンポーネントを特定）
  • インフラストラクチャからアプリケーション、データベース、サービスへのマッピング（インフラストラクチャまたはプラットフォーム コンポーネントに接続されているすべてのビジネス ワークロードを特定）
  • ビジネス ワークロード間の依存関係
  • ワークロード別のリソース使用量
  • 最初の評価フェーズで検出されなかったワークロードの特定
  • 最初の評価フェーズで特定されていなかった、新しいまたは変更されたランディング ゾーン要件の特定
  • 移行を妨げる可能性のあるブロッキング問題の特定

移行グループの調整と絞り込みの継続、リスクの特定と軽減、移行ウェーブ計画の改良と最適化には、継続的な評価が不可欠です。

プラン

移行ウェーブにおける計画フェーズは、ウェーブ内のスプリントの最終スコープを定義し、コンポーネント固有の移行計画を 1 つのプランに統合することを目的としています。このフェーズの出力は、次のとおりです。

  • 現在のスプリントの範囲内でグループを移動する
  • 移行スプリントのチェックリスト
  • ブロッキング問題を改善するための軽減策
  • 移行、ビルド、テスト、デプロイ計画
  • ロールバック プラン
  • 実施のスケジューリング

詳細な下位レベルの計画は、その後のデプロイの成功に不可欠です。

導入

デプロイ フェーズでは、移行チームが移行計画を実行し、重大な問題をすべて排除します。定期的な進捗会議を設定して実行計画を追跡することをおすすめします。ただし、この進捗会議を問題のトラブルシューティングには使用しないでください。トラブルシューティングには、各技術エキスパートと個別の打ち合わせを設定します。

デプロイ フェーズの出力は、次のとおりです。

  • 移行計画の更新情報（各ステップのステータス、注意事項）
  • 移行課題の追跡に関する更新情報
  • 移行後のテスト結果
  • CMDB の更新情報（該当する場合）
  • 関係者への移行結果の連絡

デプロイが失敗した場合（移行計画が失敗した場合、テストが失敗するか、設定した移行期間内に修正できない場合など）は、ロールバック計画を実行する必要があります。ロールバック後にアプリケーション テストを実行し、移行計画の一部であった外部変更（アップストリーム システムとダウンストリーム システムの構成など）もロールバックされていることを確認することをおすすめします。

最適化

最適化フェーズでは、デプロイ フェーズを完了した後にプロジェクト チームが再編成し、学んだことを文書化して次のウェーブとスプリントの改善を行います。すでに移行されているスコープでは、最適化フェーズを使用して、移行後の重大でない問題を解決できます。

このフェーズは、プロジェクトのタイムライン全体で継続的な改善を可能にするため重要です。

このフェーズの出力は、次のとおりです。

  • 移行課題の追跡に関する更新情報
  • プロジェクトのナレッジベースの更新（該当する場合）

移行ツール

自動化ツールは、移行ライフサイクルにおいて重要な役割を果たします。移行の実行フェーズでは、いくつかの要因（移行するワークロードのタイプ、地理的分散とロールアウト戦略、およびセキュリティ要件など）に基づいて自動化ツールのアーキテクチャを作成する必要があります。

次のドキュメントでは、それぞれの機能に対応する複数の自動化ツールが説明されています。

次のステップ