Deep Dive: Migration & Hybrid

📚 参照する公式ドキュメント

本資料は以下の Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・制限・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。

1移行全体像 — Assess → Plan → Deploy → Optimize

Google Cloud の公式移行フレームワークは 4 つの Phase で構成されます。各 Phase は順序通りに進めるのではなく、イテレーションで繰り返すことを前提に設計されています。

"Google Cloud structures migrations into a sequential journey with four distinct phases: Assess, Plan, Deploy, Optimize."
— Migration to Google Cloud: getting started

1.1 各 Phase の成果物（Deliverables）

📝 試験での出題パターン

• Q パターン：「数百 VM のオンプレ環境を移行する計画。最初のステップは？」 → A: Assess Phase で Migration Center による Discovery。Deploy 系（M4VM, DMS）の選択肢は誤答
• Q パターン：「コスト比較が必要」 → A: Migration Center の TCO レポート。Calculator 単独では依存・台帳がなく不十分

26R 戦略 完全解説

各ワークロードに対して 「どの R を選ぶか」 を Assess Phase で決定します。Google の公式ドキュメントでは Rehost / Replatform / Refactor / Repurchase / Retain / Retire（さらに Re-architect / Rebuild も併記）の 6R（拡張 7R）で整理されます。

2.1 6R カード一覧

2.2 6R 比較表（期間・コスト・リスク・ROI）

2.3 6R 決定ツリー

2.4 ハイブリッド戦略 — 段階的アプローチ

多くの企業は 「短期 Rehost で塩漬けを脱出 → 後で Replatform/Refactor」のハイブリッドを採用します。これは "Move first, optimize later" 戦略と呼ばれます。

📝 試験での出題パターン

• Q: 「Mainframe で動く COBOL アプリ、規制で移行不可」 → A: Retain + Hybrid Connectivity
• Q: 「Exchange Server 自前運用が高コスト」 → A: Repurchase = Google Workspace
• Q: 「3 ヶ月以内にデータセンター契約終了、200VM 残存」 → A: Rehost (M4VM)。Refactor は時間的に不可能
• Q: 「自前 MySQL の運用コスト削減」 → A: Replatform = Cloud SQL + DMS

3Migration Center 完全解剖

Migration Center（旧 StratoZone / CloudPhysics 系の後継）は、Assess Phase のオールインワン基盤です。Discovery（資産発見）、Assessment（評価）、TCO（コスト見積り）、Recommendation（推奨）、Migration Plan（計画）を 1 つのコンソールで提供します。

"Migration Center offers cost estimation, asset discovery, infrastructure assessment, migration planning and execution. Automated scanning of servers, SQL Server, MySQL, and PostgreSQL databases."
— Migration Center overview

3.1 Migration Center の構成

3.2 mCollector — オンプレ Discovery の中核

形態

VMware OVA / Linux VM / Docker / Windows MSI で配布

収集対象

CPU・メモリ・ディスク IO・ネットワーク IO（30 日間推奨）、インストールソフト一覧、ネットワークフロー、DB 自動検出

対応 Source

VMware vSphere（vCenter API 経由）、Hyper-V、物理 Linux/Windows、AWS（IAM Role）、Azure（Service Principal）

権限

vSphere: System.View, VirtualMachine.Provisioning.ReadOnly 程度の読取専用ロールが必要

収集期間

性能ピーク把握のため 最低 30 日、推奨 90 日。短期間だと夜間バッチや月次ジョブが拾えない

料金

Migration Center 自体は 無料（Assess Phase 全機能）。実行先 GCP サービスは通常課金

3.3 機能フロー詳細

1. Discovery: mCollector を Source 環境にインストール → 30〜90 日間データ収集 → Migration Center に自動アップロード
2. Assessment: Group 単位（DC / アプリ単位）に資産を集約 → 依存マップ自動生成 → "Fit for migration" スコア算出
3. TCO Report: On-prem 現行コスト（電気・ラック・ライセンス含む）vs GCP 推奨先のコストを比較。3 年間の累積 TCO グラフ出力
4. Recommendation: VM ごとに「GCE → e2-standard-4」「DB → Cloud SQL HA」等を自動推奨。Sole-tenant や Spot 候補も提案
5. Migration Plan: Wave に依存関係を含めて自動配置。出力は CSV / API。Pivotal Tracker / Jira 連携も可

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

# Source を作成（VMware の例）
gcloud migration-center sources create vmware-prod \
  --location=us-central1 \
  --display-name="VMware Production vCenter"

# mCollector OVA を vSphere にデプロイ
# (vCenter UI から OVF Template として import)
# 接続情報は Migration Center が払い出すワンタイムトークンを使用

# 収集結果を Group に集約
gcloud migration-center groups create prod-tier1 \
  --location=us-central1 \
  --description="Tier-1 production apps"

# Assessment 実行
gcloud migration-center reports create q4-assessment \
  --location=us-central1 \
  --group=prod-tier1 \
  --preference-set=PERFORMANCE_OPTIMIZED

📝 試験での出題パターン

• Q: 「VMware 500VM の現状把握と GCP TCO 比較」 → A: Migration Center + mCollector
• Q: 「AWS から GCP 移行検討の最初のステップ」 → A: Migration Center で AWS IAM Role 経由 Discovery
• Q: 「依存マップが必要」 → A: mCollector のネットワークフロー収集（RVTools のみでは不足）

4Migrate to Virtual Machines (M4VM)

Migrate to Virtual Machines（M4VM、旧 Migrate for Compute Engine / M4CE）は、VMware / AWS / Azure / 物理 Linux/Windows の VM を Compute Engine へ移行するためのマネージドサービスです。Stream-based migrationにより、最小ダウンタイムでカットオーバーが可能です。

4.1 M4VM の移行フロー

4.2 移行ステップ詳細

1. Source 接続: VMware は vCenter API、AWS は IAM Role + Snapshot、Azure は Service Principal + Disk Export を使用
2. Replication 開始: 初回フルディスクコピー（数時間〜数日、ディスクサイズと帯域による）→ 以降は CBT (Changed Block Tracking) 等で差分のみ転送
3. Test Clone: 本番に影響を与えずに テストクローンを起動。アプリ動作確認、TCO 検証、性能ベンチマーク
4. Cutover Window: Source を停止 → 最終差分同期 → GCE インスタンスとして起動 → DNS / Load Balancer 切替
5. Cutover 後: Replication 停止、Source 削除、運用引き継ぎ

4.3 ダウンタイム実績

4.4 ロールバック設計

📝 試験での出題パターン

• Q: 「VMware から GCP への低ダウンタイム VM 移行」 → A: M4VM の Stream-based Migration + Test Clone
• Q: 「EC2 を GCE に Lift & Shift」 → A: M4VM AWS Source（Snapshot Import は ad-hoc 用）
• Q: 「Cutover 前にアプリ検証したい」 → A: Test Clone（本番に影響なし）

5Migrate to Containers (M2C)

Migrate to Containers（M2C、旧 Migrate for Anthos）は、レガシー VM ワークロードを自動的にコンテナイメージへ変換し、GKE / Cloud Run / Anthos で動作させるためのツールです。アプリ書き換えなしで Refactor 的効果を得る、いわば "Replatform の自動化" です。

5.1 対応ワークロード

5.2 変換プロセス

1. Discovery (m2c CLI): VM やソースツリーを解析し、フレームワーク・依存ライブラリ・設定ファイルを自動検出
2. Plan 生成: 検出結果から plan.yaml（ベースイメージ・コピーするパス・環境変数）を出力
3. Plan のレビュー＆編集: 静的ファイルパスや認証情報などを人手で調整
4. Build & Push: Plan に従い Dockerfile / Skaffold / K8s YAML を生成、Container Registry / Artifact Registry へ push
5. Deploy: 生成された YAML で GKE / Cloud Run / Anthos に展開

# Discovery
m2c analyze --source ./my-tomcat-app --output ./out

# Plan 確認（Tomcat 自動検出、WAR を /usr/local/tomcat/webapps へ）
cat ./out/plan.yaml
# Migration Plan を編集（環境変数、Secrets、Resource 等）

# 変換実行（Dockerfile + K8s manifests を生成）
m2c migrate --plan ./out/plan.yaml --output ./k8s

# Build & Deploy
docker build -t gcr.io/proj/my-tomcat-app:v1 ./k8s
docker push gcr.io/proj/my-tomcat-app:v1
kubectl apply -f ./k8s/deployment.yaml

📝 試験での出題パターン

• Q: 「レガシー Tomcat アプリ 30 個をコード変更なしでコンテナ化」 → A: M2C
• Q: 「.NET Framework アプリのコンテナ化」 → A: M2C + Windows Node Pool
• Q: 「DB やステートフルアプリのコンテナ化」 → A: M2C 非対応 → M4VM か Cloud SQL へ Replatform

6Database Migration Service 完全解剖

Database Migration Service（DMS）は 同種・異種 DB のマネージド移行を提供します。MySQL/PG/SQL Server/Oracle を Source とし、Cloud SQL または AlloyDB for PostgreSQL を Destination とします。Continuous Migration（CDC ベース最小ダウンタイム）と One-time Migration（スナップショット）の 2 モードを提供します。

"Continuous Migration: A continuous flow of changes from your source to your destination that follows an initial full dump and load." / "Database Migration Service doesn't support a dual-write scenario."
— Database Migration Service overview

6.1 対応マトリクス

6.2 Continuous Migration アーキテクチャ

6.3 Source DB の前提条件（重要・試験頻出）

6.4 移行ワークフロー

1. Source 設定: binlog/WAL/Archive log 有効化、レプリ用ユーザー作成
2. Connectivity 確立: VPN / Interconnect / Public IP + IP Allowlist / Cloud SQL Auth Proxy / Reverse-SSH Tunnel のいずれか
3. Connection Profile 作成: Source / Destination の接続情報を DMS に登録
4. Migration Job 作成: One-time or Continuous を選択。Continuous なら Initial Dump → CDC Apply 開始
5. Lag 監視: replication_lag メトリクスを Cloud Monitoring で監視。0 秒前後を維持
6. Cutover: Source の書込停止 → Lag = 0 確認 → Promote（Destination を Primary 化、Replication 終了）
7. 切替後: アプリの接続先変更、Source は読み取り専用化して 7 日間保持

6.5 DMS 制限事項（必須暗記）

6.6 DB 移行手段の選定ツリー

📝 試験での出題パターン

• Q: 「自前 MySQL を Cloud SQL に低ダウンタイムで移行」 → A: DMS Continuous Migration
• Q: 「Oracle を PG / AlloyDB に異種移行」 → A: DMS heterogeneous（LogMiner ベース）
• Q: 「移行中に Source PG のディスクが急増」 → A: Replication Slot 滞留を疑う、停止中スロット削除
• Q: 「Promote 後にアプリで問題発生、Source に戻したい」 → A: Source は 7 日間保持、Cutover Window のデータ差分を手動同期

7Datastream

Datastream は サーバレス CDC レプリケーションサービスです。Oracle / MySQL / PostgreSQL / SQL Server / MongoDB / Salesforce / Spanner を Source とし、BigQuery / Cloud Storage / Apache Iceberg に低遅延で同期します。DMS が「移行用」なのに対し、Datastream は 「継続的 CDC + 分析基盤統合」用途です。

"Datastream is a serverless and easy-to-use change data capture (CDC) and replication service that lets you synchronize data reliably, and with minimal latency."
— Datastream overview

7.1 Datastream vs DMS

7.2 Datastream の構成要素

Connection Profile

Source / Destination の接続情報・認証

Stream

CDC と Backfill を組み合わせた転送ジョブ

Private Connectivity

VPC Peering / Reverse Proxy / IP Allowlist で Source へ接続

Backfill

既存データを最初に Snapshot コピー

CDC Stream

binlog / WAL / LogMiner を継続読取

📝 試験での出題パターン

• Q: 「OLTP DB をリアルタイム BigQuery で分析」 → A: Datastream
• Q: 「DMS と Datastream の違い」 → A: DMS は移行 Cutover 用、Datastream は継続 CDC
• Q: 「Oracle → BigQuery 連携」 → A: Datastream Oracle Source + BigQuery Destination

8Storage Transfer Service (STS)

Storage Transfer Service（STS）は オンライン大容量データ転送のためのマネージドサービスです。S3 / Azure Blob / HTTP/HTTPS / HDFS / オンプレ FS から GCS への転送に対応。スケジュール・帯域制御・差分転送・整合性検証を提供します。

"Storage Transfer Service does not provide an SLA, including for transfer performance or latency. Optimized for transfers exceeding 1 TiB."
— Storage Transfer Service overview

8.1 転送方式の比較

8.2 主要機能

• スケジュール：1 回限り / 定期（日次・週次）/ Event-driven（S3 / GCS の変更通知）
• 帯域制御：Agent 単位で --bandwidth-limit。業務時間外のみ帯域フルなど時間帯別運用も可能
• 整合性：MD5/CRC32C による自動検証、欠損は自動リトライ
• 差分転送：Source / Destination のメタデータを比較し変更のみ転送
• Filter：prefix / age / size / regex で対象絞り込み

📝 試験での出題パターン

• Q: 「S3 から GCS に毎日 5TB 転送」 → A: STS Agentless
• Q: 「オンプレから 50TB を専用線経由」 → A: STS Agent-based + 帯域制限
• Q: 「Source / Destination のメタデータ比較で差分のみ」 → A: STS の自動差分転送

9Transfer Appliance (TA40 / TA300)

Transfer Appliance は 物理筐体（ハードディスクアレイ）を Google から発送してもらい、オンプレで直接データを書き込んだ後 Google に返送するオフライン転送サービスです。ネットワーク帯域が不足する大容量（>10TB）転送向け。AES-256 暗号化と物理セキュリティで安全に転送できます。

"With typical 100 Mbps bandwidth, transferring 300TB normally takes ~9 months. Transfer Appliance reduces this to under 25 days for data capture, plus approximately 10 business days for Cloud Storage upload."
— Transfer Appliance overview

9.1 モデル比較

9.2 オーダー〜返却フロー

9.3 暗号化とセキュリティ

• AES-256 暗号化：書込時にハードウェア暗号化、鍵は Cloud KMS (CMEK) 管理
• 顧客鍵管理：Google からの返送中も鍵がなければ復号不能
• Tamper-Evident Seal：物理輸送時の改ざん検知
• Data Wipe：アップロード完了後、Google が NIST SP 800-88 準拠でワイプ

9.4 利用判断基準

📝 試験での出題パターン

• Q: 「100TB を 1 ヶ月で GCS へ、専用線 100Mbps」 → A: Transfer Appliance TA300（オンラインだと 3 ヶ月）
• Q: 「40TB 以下、ブランチオフィス」 → A: TA40
• Q: 「暗号化必須」 → A: AES-256 + CMEK

10Anthos / GKE Enterprise 完全解剖

Anthos（現名称 GKE Enterprise）は、マルチクラウド・ハイブリッド環境の Kubernetes クラスタを統一管理するプラットフォームです。GKE on GCP / Anthos on VMware / Anthos on Bare Metal / Anthos on AWS / Anthos on Azure を Fleet として束ね、ポリシー・セキュリティ・モニタリング・サービスメッシュを一元化します。

10.1 Anthos スタック構成

10.2 主要コンポーネント詳細

10.3 IAM 統合 — Workload Identity

Anthos の Fleet では Workload Identity Federation により、各クラスタの K8s ServiceAccount を GCP IAM にマッピングできます。AWS / Azure / オンプレで動くクラスタでも、Pod が GCP API を Service Account Key なしで呼出可能になります（セキュリティ・運用負荷ともに改善）。

📝 試験での出題パターン

• Q: 「オンプレ + GCP + AWS のクラスタを一元管理」 → A: Anthos + Fleet
• Q: 「Git 経由で全クラスタにポリシー配信」 → A: Config Sync
• Q: 「mTLS + Traffic Splitting」 → A: Cloud Service Mesh
• Q: 「VPN/Bastion なしで kubectl」 → A: Connect Gateway

11Anthos on VMware / Bare Metal

オンプレ K8s 環境を「GKE 同等の体験」で提供するソリューションです。Anthos on VMware は vSphere 上に GKE クラスタを構築、Anthos on Bare Metal は Hypervisor 不要で物理サーバ直接動作（仮想化レイヤを排除し性能・コスト最適）。

11.1 Anthos on VMware アーキテクチャ

必要環境

vSphere 7.0+（vCenter / ESXi）、vSAN または共有 Datastore、F5 BIG-IP または MetalLB

Admin Cluster

User Cluster のライフサイクル管理（3 ノード制御プレーン推奨）

User Cluster

実際にワークロードを動かす。複数 User Cluster を Admin 1 つで管理可

LB 選択肢

F5 BIG-IP（商用）/ MetalLB（OSS バンドル）/ Manual LB

Connect Agent

Fleet 登録、GCP Console 統合のため必須

11.2 Anthos on Bare Metal アーキテクチャ

対応 OS

RHEL 8/9、Ubuntu 20.04/22.04、CentOS 8（EOL 注意）

Deployment Model

Standalone / Hybrid（Admin + User 兼任）/ Multi-cluster

LB 選択肢

Bundled (MetalLB)、BGP-based、Manual

HW 要件

各 Control Plane Node: 4 vCPU / 16GB / 128GB Disk 以上

ストレージ

Local PV、Portworx、Ondat 等の CSI Driver

11.3 Anthos on VMware vs Bare Metal 選定

📝 試験での出題パターン

• Q: 「VMware 既存資産活用＋ K8s モダナイゼーション」 → A: Anthos on VMware
• Q: 「エッジ拠点で GPU 推論」 → A: Anthos on Bare Metal + GPU
• Q: 「オンプレ GKE のロードバランサ」 → A: MetalLB (Bundled) or F5 BIG-IP

12Google Cloud VMware Engine (GCVE)

GCVE は VMware Cloud Foundation スタック（vSphere/vSAN/NSX-T）をマネージドで提供するサービスです。既存 VMware 環境を 無変更で GCP に移行できます。HCX vMotionでゼロダウンタイム移行が可能。

12.1 GCVE のノードタイプ

最小構成は 3 ノード（VSAN/NSX 要件）。Private Cloud（環境）単位で課金。

12.2 HCX vMotion フロー

12.3 移行モード比較

📝 試験での出題パターン

• Q: 「VMware 環境を無変更で GCP へ」 → A: GCVE + HCX vMotion
• Q: 「データセンター撤退、500VM、3 ヶ月以内」 → A: GCVE（最速移行＋既存運用継続）
• Q: 「GCVE のライセンス含有」 → A: vSphere/vSAN/NSX は Google が提供、Windows/SQL は BYOL

13ハイブリッド接続 再考

移行とハイブリッド運用には オンプレ⇔GCP の安定接続が不可欠です。Dedicated Interconnect / Partner Interconnect / HA VPN / Cross-Cloud Interconnect の 4 種類を、SLA・調達期間・コストで使い分けます。

13.1 接続方式 完全比較

"Dedicated Interconnect: 99.99% uptime SLA for Critical Production." / "Partner Interconnect: SLA doesn't include the connectivity between your network and the service provider's network."
— Dedicated Interconnect / Partner Interconnect

13.2 HA VPN 99.99% 達成構成

"Both HA VPN gateways must be in the same region to provide 99.99% availability SLA. Configuring only one tunnel on one interface for each HA VPN gateway doesn't provide 99.99% availability SLA."
— HA VPN topologies

13.3 Cross-Cloud Interconnect (CCI)

用途

AWS / Azure / OCI / Alibaba との 直結回線。Egress コスト削減・低遅延

SLA

99.9% (single metro) / 99.99% (multi-metro)

帯域

10 / 100 / 400 Gbps（AWS/OCI）、10 / 100 Gbps（Azure/Alibaba）

調達期間

1–4 週間（Dedicated Interconnect より高速）

料金

Local / Remote の固定 Port 課金 + Egress 削減効果

13.4 接続方式 決定ツリー

📝 試験での出題パターン

• Q: 「明日中にオンプレ接続が必要」 → A: HA VPN（Interconnect は数週間）
• Q: 「99.99% SLA 必須・100Gbps」 → A: Dedicated Interconnect 2 ファシリティ
• Q: 「AWS との直結」 → A: Cross-Cloud Interconnect
• Q: 「HA VPN を BGP で構成、99.99% SLA」 → A: 2 Peer Gateway + 同リージョン 2 IF + 4 トンネル

14移行リハーサル＆カットオーバー戦略

移行成功の鍵は 「事前リハーサル」「ウェーブ設計」「ロールバック計画」の 3 点に尽きます。本章では運用観点の深掘りを行います。

14.1 移行ウェーブ計画

数百〜数千 VM を 段階的に小グループ単位（Wave）で移行することで、リスクを限定します。Migration Center の依存マップを元に、依存関係のないグループから先に移行します。

14.2 リハーサル (Dry Run)

• テストクローン: M4VM の Test Clone で本番影響なく検証
• ステージング検証: 完全コピーで E2E テスト・性能テスト・障害テスト
• ロールバック演習: 失敗ケースを意図的に発生させ、復旧手順を訓練
• カットオーバー Runbook: 分単位のステップ、責任者、Go/No-Go 判定基準
• コミュニケーション訓練: ステークホルダー通知のドライラン

14.3 カットオーバー戦略 比較

14.4 カットオーバー戦略 決定ツリー

14.5 ロールバック計画（R 戦略別）

14.6 移行モニタリング

• Source 側: CPU / Mem / IO / Replication Slot サイズ / binlog 残量
• Destination 側: Replication Lag / 書込スループット / エラー率
• Network: 帯域使用率 / RTT / Packet Loss / BGP セッション
• アプリ: SLO / レイテンシ / エラー率 / 4xx/5xx
• データ整合性: 行数 / チェックサム / トランザクション数の Source-Destination 比較

14.7 コミュニケーション計画

T-7 日

ステークホルダー全員にメンテ通知、影響範囲確認

T-3 日

カットオーバー Runbook 最終レビュー、Go/No-Go 会議

T-1 日

関係者待機表、エスカレーション体制確認

T=0 (Cutover)

War Room 設置、5 分毎ステータス報告

T+24h

事後レビュー、Lessons Learned 共有

14.8 並行運用期間のコスト管理

14.9 ハイブリッド運用の継続課題

• パッチ管理：オンプレ＋ GCP の OS パッチ統合（Cloud OS Configuration Management）
• モニタリング統合：オンプレ Prometheus → GMP（Google Managed Prometheus）連携
• IAM/Identity 同期：AD → Cloud Identity Federation、AD Connector 経由
• SLO 統一：オンプレ⇔ GCP で同一 SLO 基準
• DR 計画：オンプレ → GCP DR、GCP → オンプレ DR、両方向設計

📝 試験での出題パターン

• Q: 「移行リスク最小化」 → A: Wave 分割 + Test Clone + ロールバック計画
• Q: 「金融系で並行稼働必須」 → A: Parallel Run + データ整合性チェック
• Q: 「ECサイトで瞬時切替」 → A: Blue-Green / Canary + DNS/LB

15ライセンス＆BYOL

クラウド移行でしばしば見落とされる落とし穴が ライセンスです。OS / DB / 商用ソフトのライセンス契約を クラウド環境でも継続利用可能かを必ず確認します。

15.1 主要ソフトのライセンス扱い

15.2 Sole-tenant Node — BYOL の要

用途

Windows Server / SQL Server の BYOL、規制対応、テナント分離

料金

物理ホスト時間課金（VM 数に依存しない）

BYOL 条件

Microsoft Software Assurance + License Mobility 契約必須

運用

Live Migration 対応、メンテナンスポリシー指定可

📝 試験での出題パターン

• Q: 「Windows Server の既存ライセンスを GCP で使いたい」 → A: Sole-tenant Node + BYOL（SA 必須）
• Q: 「Oracle DB を GCE で動かす」 → A: BYOL + Sole-tenant Node
• Q: 「GCVE の VMware ライセンス」 → A: Google 提供のため BYOL 不要・不可

16試験頻出パターン（ケーススタディ）

PCA 試験では 4 つの公式ケーススタディ（EHR Healthcare / Helicopter Racing League / Mountkirk Games / TerramEarth）と、新版で Cymbal Retail / Altostrat Media なども登場します。本章では移行系シナリオの典型解答パターンを整理します。

16.1 EHR Healthcare（医療レコード移行）

• VM 移行：M4VM で Lift & Shift、Cloud HSM + CMEK で暗号化
• DB 移行：DMS で Cloud SQL HA 構成（同期 RPD）、ロケーション制約は Data Residency 設定
• 接続：Dedicated Interconnect 2 ファシリティ + HA VPN バックアップ
• コンプラ：BAA（Business Associate Agreement）、Cloud Audit Logs、VPC SC で データ漏洩防止
• DR：別リージョン Cross-region Replica、PITR、Backup Vault

16.2 Helicopter Racing League（メディア配信）

• ML：Vertex AI へ移行、Custom Training + Online Prediction
• 動画：Cloud CDN + Media CDN、Cloud Storage + Lifecycle
• データ収集：Pub/Sub + Dataflow（リアルタイム）、BigQuery（蓄積・分析）
• 移行ツール：STS で過去動画 200TB を Coldline へ

16.3 Mountkirk Games（ゲーム）

• 移行：オンプレ → GKE + Spanner（グローバル）
• ユーザ DB：DMS で MySQL → Spanner（インターリーブテーブル設計）
• 分析：BigQuery + Looker、Pub/Sub からのイベントストリーム
• マッチメイク：Memorystore Redis

16.4 TerramEarth（IoT / 建機）

• 移行：オンプレデータレイク → BigQuery + GCS
• データ転送：Transfer Appliance で過去 500TB をオフライン転送、現在系は Pub/Sub + Dataflow
• 分析：BigQuery ML、Looker Studio
• 接続：Dedicated Interconnect for 工場、各車両は LTE / 5G

16.5 Cymbal Retail / Altostrat Media（新版）

• Cymbal Retail: マルチクラウド構成（既存 AWS + GCP 新規）→ Anthos + CCI
• Altostrat Media: VMware 環境のクラウド化 → GCVE + HCX vMotion

17アンチパターン集

18クォータと制限の一覧

📘 次のステップ

📚 公式ドキュメント参照リンク（再掲）