Migration Center

解決する課題

大規模な移行では「いま何があるのか」「移行先で何が必要か」「いくらかかるのか」を把握できないまま進めてしまい、見積もりのブレや手戻りが起きがちです。Migration Center は、発見から評価、計画、実行までを一つの場所に集約し、移行の全体像を可視化します。

• 移行対象の資産がどれだけあるか分からない → オンプレや他クラウドのサーバ・データベースなどを発見してインベントリ化
• 移行後の構成やサイズが読めない → 資産の利用状況を分析し、移行先のサイジングや形態を推奨
• いくらかかるか説得材料がない → TCO（総保有コスト）を試算し、現行とクラウド移行後を比較
• 移行ツールが乱立して全体像が見えない → 各種移行ツールへの入口として進捗を一元管理

AWS でいえば、複数の移行ツールを束ねて移行の発見・計画・追跡を一元化する AWS Migration Hub に近いサービスと考えると理解しやすいです。

主要概念と用語

• アセット（資産）: 移行検討の対象となる1単位。物理サーバ、仮想マシン、データベースなどが該当し、構成や利用状況のメタデータを保持する
• インベントリ（資産台帳）: 発見されたアセットの一覧。移行計画の起点となる基礎情報
• ディスカバリ（発見）: オンプレや他クラウドの資産情報を集める工程。クライアントツールでの収集、構成ファイルのインポート、手動登録など複数の方法がある
• アセスメント（評価）: 集めた情報を分析し、移行先のサイジング推奨やコスト試算、移行の適性を導く工程
• グループ: アプリ単位や移行波（ウェーブ）単位でアセットをまとめる箱。まとまりごとに評価・計画する
• TCO（総保有コスト）: 現行環境とクラウド移行後の費用を比較する試算。意思決定の根拠になる
• サイジング推奨: 実測の利用状況をもとに、移行先で適切なマシンタイプや容量を提案する機能（過剰・過小割り当てを避ける）

仕様・制限・クォータ

• 発見方法は複数。専用のディスカバリクライアントによる収集、既存ツールやファイルからのインポート、手動登録などを組み合わせて資産台帳を作る
• 評価は「現状の利用実績」を前提にする。一定期間の稼働メトリクスが集まるほど、サイジングや TCO の精度が上がる
• Migration Center 自体は計画・評価の中心であり、実際のデータ移動は連携する移行ツール（VM 移行やデータベース移行などのサービス）が担う
• グループ単位で評価・計画するのが基本。アプリや移行波ごとにまとめると進捗管理がしやすい
• 収集できるアセット種別、対応するソース環境、レポートの細目は随時拡張される。対応範囲やクォータの具体値は変動するため、最新は公式ドキュメントで確認する

内部の仕組み

Migration Center は「集める・評価する・計画する・引き渡す」という流れで移行の上流を回します。

1. 発見（ディスカバリ）: ディスカバリクライアントやインポートで、オンプレ・他クラウドのサーバやデータベースの構成と利用状況を収集し、インベントリ化する
2. 評価（アセスメント）: 集めた利用実績を分析し、移行先のサイジング推奨、移行適性、現行とクラウド移行後の TCO 比較を算出する
3. グルーピングと計画: アセットをアプリや移行波ごとにグループ化し、まとまりごとに評価レポートと移行方針を作る
4. 実行への引き渡し: 計画が固まったら、VM 移行やデータベース移行といった実行系の移行ツールへ橋渡しし、進捗を一元的に追う

設計パターン / ベストプラクティス

• 十分な期間の実測を取る: 評価の精度は利用実績の量に依存する。繁忙期も含めた期間で収集し、サイジングと TCO の確度を上げる
• アプリ単位・移行波単位でグループ化: 依存関係のあるアセットをまとめ、波ごとに計画・実行することで影響範囲を制御する
• TCO は前提を揃えて比較する: 現行とクラウド移行後を同じ条件で並べ、意思決定者に説明できる根拠として使う
• サイジング推奨を鵜呑みにしすぎない: 推奨を出発点にしつつ、ピーク特性や将来の伸びを加味して最終的なマシンタイプを決める
• 実行ツールとの分担を明確に: 計画と進捗管理は Migration Center、実データの移動は VM・データベース移行ツールに任せる

運用・監視

• 進捗を一元的に追う: グループや移行波ごとに、発見・評価・実行の状態を一か所で把握し、滞りを早期に見つける
• 評価レポートを定期更新する: 環境は移行途中も変化するため、収集と評価を更新して計画とのズレを補正する
• 収集の継続性を確保する: ディスカバリクライアントの稼働や認証情報が切れると実績が欠ける。収集が止まっていないか点検する
• 移行波の完了基準を決める: 各波のカットオーバー条件と検証項目を明確にし、完了と次波着手の判断を仕組み化する

コスト

Migration Center による発見・評価・計画といった移行準備の機能は、多くのケースで追加料金を意識せず利用できます。コストの中心になるのは、計画後の実際の移行を担う各ツールの利用料や、移行先で稼働させるCompute・ストレージなどの実行リソースの費用です。また、評価で算出する TCO はあくまで試算であり、実際の請求は移行先の構成・稼働時間・割引適用によって変わります。具体的な課金単位や金額は変動するため、最新は公式の料金ページで確認してください。

セキュリティ

• 収集する資産情報が機微: 構成や利用状況は環境の地図そのもの。閲覧・編集の権限を IAM で最小化する
• ディスカバリの認証情報を保護する: 収集元へアクセスするための認証情報は厳重に管理し、収集後は不要な権限を残さない
• 記録は構成・メトリクス中心: アプリ内部の実データそのものを移すのは実行系の移行ツールの役割であり、データ保護は移行先側の暗号化やアクセス制御で担保する
• 責任分界を意識する: 評価のためのメタデータ収集と、実データ移行時の保護は別の管理対象として整理する

Well-Architected の観点

• 運用: 発見・評価・計画・進捗管理を一元化することで、移行という一過性かつ大規模なプロジェクトの全体像を可視化し、手戻りや見積もりブレを抑える。グループや移行波での管理により、段階的で制御された移行運用を支える
• コスト最適化: 実測ベースのサイジング推奨と TCO 試算により、過剰割り当てを避けて移行先のリソースを適正化し、移行の費用対効果を意思決定者に説明できる根拠を提供する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# API を有効化
gcloud services enable migrationcenter.googleapis.com

# 既定のロケーションを設定（評価やインポートのスコープ）
gcloud config set migrationcenter/location us-central1

# 発見した資産（アセット）の一覧を確認
gcloud migration-center assets list \
  --project=my-project \
  --location=us-central1

# アプリや移行波ごとにアセットをまとめるグループを作成
gcloud migration-center groups create my-app-wave1 \
  --project=my-project \
  --location=us-central1 \
  --display-name="App Wave 1"

# 既存のインポートジョブ（収集・取り込み）の状況を一覧
gcloud migration-center import-jobs list \
  --project=my-project \
  --location=us-central1