移行・DR・コスト最適化

第 16 章まででゼロから作る設計は一通り揃いました。しかし実務のクラウド案件の多くは「すでに動いているシステムを運ぶ」ところから始まります。この章では既存システムの移行、被災時にも事業を止めない DR（ディザスタリカバリ）、そして運び終えたあとのコスト最適化を扱います。PCA 試験では、この 3 つが「6 ヶ月でデータセンターを退去したい」「RPO 15 分を最小コストで」のようなシナリオ問題として頻出します。数字（RTO / RPO・データ量・期限・予算）を設計に翻訳する練習をしましょう。

移行の進め方 — 4 フェーズと移行パターン

Google Cloud のアーキテクチャセンターは、移行を一発の引っ越しではなく 評価（Assess）→ 計画（Plan）→ 移行（Deploy）→ 最適化（Optimize）の 4 フェーズの反復として定義しています。全ワークロードを一度に運ぶのではなく、優先度をつけた「波」ごとにこのサイクルを回します。

評価フェーズを担う Migration Center

Migration Center は、オンプレミスや他クラウドから Google Cloud への移行を支援する統合プラットフォームです。評価フェーズで必要な作業がひととおり揃っています。

• 資産の検出 — discovery client を環境に置いて継続収集するか、CLI で一回限りのエクスポートを行います。AWS からの自動インポートや、RVTools データ・手動アップロードによる取り込みにも対応します。対象はサーバーに加えて SQL Server・MySQL・PostgreSQL データベースです
• コスト見積もりと TCO レポート — 現在のリソース構成から Google Cloud 移行後のコストを推定します
• 技術適合性の評価 — 検出した資産に対して、適した Google Cloud プロダクトの推奨とアプリ・ネットワークの依存関係の特定を行います

移行パターン — どこまで作り替えるか

公式ガイドは移行タイプを次の 6 つに整理しています。右へ行くほど改修コストが増える代わりに、クラウドの利点を多く得られます。

評価フェーズの棚卸しでは、この 6 つに入る前にもうひとつの選択肢を必ず検討します。そもそも使われていないアプリは移行せず廃止（リタイア）することです。移行対象が 1 つ減ることが最大のコスト削減になります。

ランディングゾーン — 着地点を先に設計する

計画フェーズの主要な成果物がランディングゾーン（クラウド基盤とも呼ばれます）です。ワークロードを受け入れる前に整えておく組織共通の土台で、公式ドキュメントは次の 4 要素を必須としています。本書でここまでに学んだ内容の総集編でもあります。

• ID プロビジョニング — Cloud Identity とオンプレ ID 基盤の連携、IAM によるアクセス制御（第 2 章）
• リソース階層 — 組織 / フォルダ / プロジェクトの構造と組織ポリシー（第 2 章）
• ネットワーク — 共有 VPC、Cloud Interconnect / Cloud VPN によるハイブリッド接続、Cloud DNS（第 3 章・第 12 章）
• セキュリティ制御 — VPC Service Controls、ファイアウォール、監査ログ（第 13 章・第 14 章）

構築は手作業ではなく Terraform などの IaC + CI/CD で行うことが推奨されています（第 16 章）。Google はサンプル実装として Terraform example foundation を提供しています。

移行ツールとデータ転送 — 何をどう運ぶか

運ぶ対象ごとのツール対応表

データ量 × 回線帯域の計算 — オンラインか、物理輸送か

転送手段の分かれ目は計算で決まります。転送時間 ≒ データ量 × 8 ÷ 実効帯域です。帯域を 100% 占有できたと仮定した理論値でも、次の表のようになります。

実際の回線は業務トラフィックと共有するため、実効速度はさらに落ちます。公式ドキュメントの例では、300 TB は 100 Mbps 回線で約 9 ヶ月かかるのに対し、Transfer Appliance なら約 25 日で取り込めます（2026-08 時点）。試験でも「数百 TB を数週間で」「拠点の回線が細い」という条件が出たら Transfer Appliance が答えです。装置内のデータは AES-256 で暗号化され、Cloud KMS の顧客管理鍵も使えます。

ソフトウェアライセンスのマッピング

VM 移行で見落としやすいのが OS・ミドルウェアのライセンスです。持ち込み方は 3 通りあります。

DR 設計 — RTO・RPO とスタンバイの温度

RTO と RPO — 要件を 2 つの数字にする

DR 設計は 2 つの数字を決めるところから始まります。

• RTO（Recovery Time Objective） — サービスが停止していられる最大時間。「何分（何時間）で復旧するか」
• RPO（Recovery Point Objective） — 失ってもよいデータの最大期間。「最後のバックアップ（レプリケーション）から何分ぶんのデータ損失を許容するか」

公式の DR 計画ガイドが強調するのは、RTO / RPO を小さくするほど実装コストと運用負担が増えるというトレードオフです。RPO はデータ同期方式（同期 / 非同期 / 定期バックアップ）を、RTO はフェイルオーバー自動化の必要性を、それぞれ直接決定します。だからこそ数字はエンジニアが勝手に決めるのではなく、ビジネスインパクト分析から導きます。アーキテクチャセンターの例では、アプリを重要度で 3 層に分け、最重要層はゾーン / リージョン障害ともほぼゼロの RTO / RPO、中間層は 15 分〜1 時間、通常層は 1〜12 時間という目標を置いています。

DR パターン — コールド / ウォーム / ホット

DR パターンは公式ガイドがタイヤに例えるとおり 3 段階です。スペアタイヤを持たない（コールド）、スペアタイヤを積んでおく（ウォーム）、パンクしても走り続けられるランフラットタイヤ（ホット）。待機系が「温かい」ほど RTO / RPO は縮み、平時のコストは増えます。

Google Cloud で各パターンを組み立てる建材は、すでに各章で学んだものです。ディスクのスナップショットはグローバルリソースなので別リージョンへの復元にそのまま使えます。バックアップの保管先は Cloud Storage のストレージクラスで選び、月 1 回以下のアクセスなら Nearline、長期保管の最安は Archive です（第 8 章）。リージョン永続ディスクは 2 ゾーンに同期書き込みし、ゾーン障害に耐えます。フェイルオーバーの経路切り替えは Cloud Load Balancing のヘルスチェックや Cloud DNS の API 操作で自動化し（第 5 章）、復旧手順そのものは Terraform 等の IaC にしておきます（第 16 章）。DR 先の VM 容量を確実に確保したい場合は予約（reservation）が使えます。データベース層は Cloud SQL のリージョナル構成やクロスリージョン リードレプリカ、Spanner のマルチリージョン構成が土台になります（第 9 章）。

Backup and DR Service — バックアップを一元管理する

個別にスナップショットを仕込む代わりに、Backup and DR Service でバックアップを一元管理できます。対応ワークロードは Compute Engine の VM とディスク、Cloud SQL / AlloyDB、Google Cloud VMware Engine、VM 上の自己管理 Oracle / SQL Server、NFS / SMB ファイルシステムなどです。中核となるバックアップボールト（backup vault）は、保存したバックアップを変更も削除もできない不変ストレージで、ランサムウェア対策として保持期間を強制できます。Google Cloud コンソール経由の運用では最小 RPO 4 時間、アプライアンス管理コンソール経由では最小 RPO 15 分まで縮められます（2026-08 時点）。

gcloud compute disks create dr-source-disk \
    --size=10GB --type=pd-balanced \
    --zone=asia-northeast1-b

gcloud compute resource-policies create snapshot-schedule daily-backup \
    --region=asia-northeast1 \
    --daily-schedule \
    --start-time=17:00 \
    --max-retention-days=7 \
    --on-source-disk-delete=apply-retention-policy

gcloud compute disks add-resource-policies dr-source-disk \
    --resource-policies=daily-backup \
    --zone=asia-northeast1-b

gcloud compute resource-policies describe daily-backup \
    --region=asia-northeast1

gcloud compute snapshots create dr-manual-snap \
    --source-disk=dr-source-disk \
    --source-disk-zone=asia-northeast1-b

gcloud compute snapshots list

gcloud compute disks create dr-restored-disk \
    --source-snapshot=dr-manual-snap \
    --type=pd-balanced \
    --zone=asia-northeast2-b

gcloud compute disks describe dr-restored-disk \
    --zone=asia-northeast2-b \
    --format="value(name,sizeGb,status)"

gcloud compute disks delete dr-restored-disk --zone=asia-northeast2-b --quiet
gcloud compute snapshots delete dr-manual-snap --quiet
gcloud compute disks remove-resource-policies dr-source-disk \
    --resource-policies=daily-backup --zone=asia-northeast1-b
gcloud compute disks delete dr-source-disk --zone=asia-northeast1-b --quiet
gcloud compute resource-policies delete daily-backup \
    --region=asia-northeast1 --quiet

gcloud compute disks list
gcloud compute snapshots list

コスト最適化 — 割引・ライトサイジング・可視化

クラウド移行はコストの性質を変えます。オンプレはサーバー購入という先行投資（CAPEX）と減価償却の世界、クラウドは使った分を払う運用費（OPEX）の世界です。OPEX は俊敏ですが、放置すると膨らみます。Google Cloud のコスト最適化は「割引を効かせる」「サイズを適正化する」「見える化する」の 3 本柱で考えます。

3 つの割引 — SUD・CUD・Spot

• 継続利用割引（SUD） — 請求月の 25% を超えて稼働したリソースに自動でかかる割引です。フル稼働の月で最大 30%（N1・M1・M2 など）または最大 20%（N2・N2D・C2 など）。E2 は対象外で、CUD を適用した使用分にも重複しません。申し込み不要なので「何もしなくても効いている」割引です
• 確約利用割引（CUD） — 1 年または 3 年の利用を確約する代わりに受ける割引で、2 種類あります。リソースベース CUD は特定リージョンの vCPU・メモリ・GPU・ローカル SSD などの量にコミットし、割引率は最大 55%（メモリ最適化は最大 70%）。フレキシブル CUD は支出額にコミットし、Compute Engine（主要マシンシリーズ）・GKE・Cloud Run を横断して、単一のプロジェクト・リージョン・マシン構成に縛られず適用されます。割引率はマシンシリーズやサービスで幅があり、標準的な構成は 1 年 28% / 3 年 46%、メモリ最適化（M1〜M4）は 1 年契約では割引なし・3 年で 63% です（いずれも 2026-08 時点）。どちらも使わなかった月も請求され、キャンセルできません
• Spot VM — 中断されうる代わりに大幅割引を受ける余剰キャパシティです（第 4 章）。バッチ・CI・耐障害設計済みワークロード向け

ライトサイジング — Recommender の推奨事項を適用する

割引の前にやるべきなのがサイズの適正化です。Active Assist の一機能として、Compute Engine は過去 8 日間の CPU / メモリ使用率（60 秒間隔の計測）からマシンタイプ推奨事項を自動生成します。コンソールの VM 一覧に電球アイコンで表示されるほか、Recommender API・gcloud からも取得でき、適用するとインスタンスは停止 → マシンタイプ変更 → 再起動という流れで置き換わります（MIG には別途、グループ向けの適用手順があります）。「4 vCPU で作ったが平均使用率 5%」のような VM は、推奨に従って縮めるだけで恒久的にコストが下がります。

可視化 — 予算アラートと請求データの BigQuery エクスポート

最適化は測れないと始まりません。土台は第 1 章で設定した予算アラートです。それより一歩進んだ分析にはCloud Billing データの BigQuery エクスポートを使います。種類は 4 つあります（2026-08 時点）。

• 標準の使用料金 — サービス・SKU・プロジェクト・ラベル・クレジットなどのコスト明細。まず有効化すべき基本形
• 詳細な使用料金 — 標準に加えて VM 単位などリソースレベルの明細
• 料金 — SKU ごとの単価表
• FOCUS 形式（プレビュー）— FinOps 標準仕様に正規化されたデータ

重要な性質がひとつあります。エクスポートは有効化した時点からのデータしか蓄積されません（データセットが US / EU マルチリージョンの場合に前月分まで遡って入るのが唯一の例外）。あとから 1 年前のコストを分析したくなっても取り戻せないので、プロジェクトを作ったら早めに有効化するのが定石です。リソースにラベルを付けておけば、エクスポートしたデータをチーム別・環境別に集計するコスト配賦も SQL だけでできます。

bq --location=asia-northeast1 mk --dataset billing_export

bq query --use_legacy_sql=false '
SELECT
  service.description AS service,
  ROUND(SUM(cost), 2) AS total_cost,
  currency
FROM `billing_export.gcp_billing_export_v1_XXXXXX`
GROUP BY service, currency
ORDER BY total_cost DESC'

bq rm -r -f -d billing_export

つまずきポイント

理解度チェック

まとめと次章へ

• 移行は評価 → 計画 → 移行 → 最適化の反復。評価は Migration Center、計画の成果物はランディングゾーン（ID・リソース階層・ネットワーク・セキュリティの 4 要素）
• 移行パターンは「どこまで作り替えるか」の選択。期限と予算が厳しければリホスト、使っていないものは廃止が最速のコスト削減
• 運ぶ対象でツールが決まる: VM は Migrate to Virtual Machines、DB は Database Migration Service、データは量と帯域の計算で gcloud storage / Storage Transfer Service / Transfer Appliance を選ぶ
• DR は RTO / RPO から逆算し、要件を満たす最も冷たい（安い）パターンを選ぶ。バックアップボールトは変更・削除不可でランサムウェア対策になる
• コストは「割引（SUD 自動 / CUD 確約 / Spot）」「ライトサイジング（8 日間のメトリクスからの推奨事項）」「可視化（予算アラート + BigQuery エクスポート）」の 3 本柱。CUD はキャンセル不可、エクスポートは遡及なし

次の第 18 章はいよいよ総仕上げです。本章までに学んだ道具立てを、PCA 試験の公式ケーススタディ 4 本（EHR Healthcare / Helicopter Racing League / Mountkirk Games / TerramEarth）に当てはめ、要件をアーキテクチャへ翻訳する練習と試験本番のテクニックを扱います。

参考リンク:

• Migrate to Google Cloud: Get started（移行の 4 フェーズと移行タイプ）
• Migration Center overview
• Database Migration Service documentation
• Disaster recovery planning guide
• Landing zone design in Google Cloud
• Backup and DR Service overview
• Committed use discounts overview
• Export Cloud Billing data to BigQuery