📚 GCP PCA 学習: 2026-04-13

セクション: 1.2 技術要件を満たすソリューションインフラの設計 前回からの繋がり: 1.1でビジネス要件を技術選択に翻訳する方法を学んだ。今回はその技術要件を実際のインフラ設計（HA・スケーリング・マイグレーション）に落とし込む方法を掘り下げる。

① 一言サマリー

「技術要件を満たすインフラ設計とは、一言でいうと "壊れない・伸び縮みする・移せる" の3つを同時に設計する作業 です」

PCA 試験では「どのサービスを使えば HA になるか」だけでなく、「なぜその構成が選ばれるのか・どこにトレードオフがあるのか」を問います。

② たとえ話

高速道路を想像してください。

高可用性（HA）: 車線が複数あるので1車線が工事中でも渋滞しない（= ゾーン冗長）
フォルトトレランス: 橋が落ちても迂回路が自動で開通する（= フェールオーバー）
弾力性: 朝の通勤ラッシュには車線を増やし、深夜は減らす（= オートスケール）
マイグレーション: 古い道路を壊さずに横に新しい道路を作って徐々に切り替える（= 段階移行）

GCP でのインフラ設計も同じ考え方です。「常に動く」「需要に追従する」「安全に移せる」を同時に実現します。

③ 図解

graph LR
    subgraph 技術要件の分類
        A[技術要件] --> B[高可用性 / HA]
        A --> C[フォルトトレランス]
        A --> D[弾力性 / スケーラビリティ]
        A --> E[マイグレーション]
    end

    subgraph HA 設計パターン
        B --> B1[マルチゾーン配置]
        B --> B2[ロードバランサー]
        B1 --> B3[Cloud SQL HA
GKE Multi-zone
MIG Regional]
    end

    subgraph フォルトトレランス設計
        C --> C1[マルチリージョン]
        C --> C2[フェールオーバー自動化]
        C1 --> C3[Cloud Spanner
Global LB
Multi-region GCS]
    end

    subgraph スケーリング設計
        D --> D1[水平スケーリング]
        D --> D2[垂直スケーリング]
        D1 --> D3[MIG Autoscaler
GKE HPA
Cloud Run]
        D2 --> D4[Machine Type
変更 / Committed Use]
    end

    subgraph マイグレーション設計
        E --> E1[Lift & Shift]
        E --> E2[段階移行]
        E1 --> E3[Migrate to VMs]
        E2 --> E4[Traffic Splitting
Blue/Green Deploy]
    end

    style A fill:#4285F4,color:#fff
    style B3 fill:#34A853,color:#fff
    style C3 fill:#34A853,color:#fff
    style D3 fill:#34A853,color:#fff
    style E4 fill:#34A853,color:#fff

技術要件は4つの軸に分類され、それぞれに対応する GCP の設計パターンがあります。PCA 試験ではこの マッピングを即座に引き出せるか が問われます。

④ 仕組みの深掘り

高可用性（High Availability）とフォルトトレランスの違い

HA とフォルトトレランスとは

一言でいうと、HA は「障害を最小化する設計」、フォルトトレランスは「障害が起きても継続する設計」 です。たとえると、HA は「事故を起こしにくい車（安全装備が充実）」、フォルトトレランスは「タイヤが4本パンクしても走れる戦車」のようなものです。

設計	目標	GCP の実装例	コスト
HA	99.9〜99.99% SLA	Cloud SQL HA / MIG マルチゾーン	中
フォルトトレランス	99.999%+ / RPO=0	Cloud Spanner / グローバル LB	高

PCA 試験のポイント: 「ダウンタイムを許容できない」= HA。「データ消失を1秒も許容できない」= フォルトトレランス（Spanner）。

弾力性とスケーラビリティの設計

水平スケーリング vs 垂直スケーリング

スケーリングとは

一言でいうと、水平スケーリングは「レジを増やす」、垂直スケーリングは「レジを高性能化する」 です。

方式	GCP の実装	特徴
水平（スケールアウト）	MIG Autoscaler / GKE HPA / Cloud Run	無停止で追加・削除可能、コスト効率良
垂直（スケールアップ）	GCE Machine Type 変更	再起動が必要、上限あり

MIG オートスケーラーのトリガー

MIG Autoscaler とは

一言でいうと、「CPU 使用率などの指標を見て VM を自動で増減させる仕組み」 です。

CPU 使用率: 閾値（例: 60%）を超えたら VM 追加
カスタムメトリクス: Cloud Monitoring のメトリクスでスケール（例: キューの深さ）
Cloud Load Balancing のリクエスト数: 1VM あたりのリクエスト数でスケール
スケジュール: 定時（例: 毎朝 8:00）に最小インスタンス数を増やす

PCA 試験でよく出る判断基準: - 「バースト的なトラフィック」→ Cloud Run（0→N の高速スケール、コールドスタートに注意） - 「定常的なワークロード + スパイク」→ MIG + Committed Use Discount の組み合わせ

マイグレーション要件への対応

ライブマイグレーション vs カットオーバー

ライブマイグレーションとは

一言でいうと、「新幹線を走らせたまま線路を交換する技術」 です。ユーザーに影響を与えずにシステムを切り替えます。

GCP での実現方法:

1. Strangler Fig パターン（徐々に機能を新システムへ移行）
   旧システム → LB → 新システム（一部トラフィック）
                  ↘ 旧システム（残りのトラフィック）
   ↓ トラフィックを段階的に切り替え
   → 最終的に旧システムを廃止

2. Blue/Green デプロイ（Cloud Run / GKE で実現）
   Blue（現行）: 100% トラフィック
   ↓ 新バージョン（Green）をデプロイ
   Green: 段階的にトラフィックを増やす（10% → 50% → 100%）
   ↓ 問題なければ Blue を廃止

マイグレーションツールの選定

移行対象	ツール	特徴
オンプレ VM → GCE	Migrate to Virtual Machines	エージェントレス移行
オンプレコンテナ	Migrate to Containers	VM → コンテナ自動変換
大容量データ	Transfer Appliance	ネットワーク帯域が足りない場合（100TB+）
オンライン DB 移行	Database Migration Service	最小ダウンタイムの CDC（変更データキャプチャ）

PCA 試験のポイント: 「ネットワーク帯域が不十分」→ Transfer Appliance。「DB の最小ダウンタイム移行」→ Database Migration Service（CDC）。

⑤ 他サービスとの使い分け

HA / フォルトトレランスのサービス選定フロー

SLA 要件は？
│
├─ 99% 以下 → シングルゾーン構成でも許容
│
├─ 99.9%（年8.76時間まで）
│   └─ マルチゾーン構成
│       ├─ DB: Cloud SQL HA（ゾーン内フェールオーバー）
│       └─ 計算: MIG（マルチゾーン）/ GKE（マルチゾーンクラスタ）
│
├─ 99.99%（年52.6分まで）
│   └─ マルチリージョン構成
│       ├─ DB: Cloud Spanner（グローバル）/ Cloud SQL クロスリージョンレプリカ
│       └─ 計算: グローバル LB + マルチリージョン MIG
│
└─ 99.999%（RPO/RTO ≒ 0）
    └─ Cloud Spanner（True Time による同期レプリケーション）
        + グローバル外部 LB

⑥ 実務への応用

Web 系スタートアップのスケーリング設計

シナリオ: 月100万 PV のサービスが EC サイトへ拡大。セール時に10倍トラフィックを想定。

推奨構成（スケーラビリティ重視）:
├─ フロントエンド: Cloud CDN（静的アセット配信）
├─ API サーバー: Cloud Run（0→N の自動スケール）
├─ DB: Cloud SQL（PostgreSQL）
│   ├─ Primary: 書き込み
│   └─ Read Replica × 2: 読み取り分散
└─ キャッシュ: Memorystore（Redis）でDB負荷軽減

セール時の追加対策:
└─ Cloud Run の最小インスタンス数を事前に増やす
   （コールドスタートによるレイテンシスパイクを防ぐ）

レガシーシステムのマイグレーション戦略

シナリオ: オンプレの Java アプリ（VM 10台）を段階移行したい。

Phase 1（Rehost, 0〜3ヶ月）:
└─ Migrate to VMs でオンプレ VM を GCE に移行
   リスク最小・ダウンタイム最小

Phase 2（Refactor, 3〜6ヶ月）:
└─ Cloud SQL への DB 移行（Database Migration Service）
   アプリ変更なしで DB だけクラウド移行

Phase 3（Rearchitect, 6ヶ月以降）:
└─ Migrate to Containers でコンテナ化
   GKE / Cloud Run へ段階移行
   Blue/Green でトラフィックを徐々に切り替え

⑦ よくある誤解・落とし穴

落とし穴 1: Cloud SQL HA = フォルトトレランスという誤解

誤解: Cloud SQL の HA 構成はフェールオーバー時に無停止。正解: Cloud SQL HA は ゾーン障害時に30〜60秒のフェールオーバーが発生する。RPO=0・RTO=0 が必要なら Cloud Spanner 一択。

落とし穴 2: オートスケーリングは即時に反応するという思い込み

誤解: トラフィックが急増したらすぐに VM が追加される。正解: MIG のスケールアウトには2〜3分かかる（VM 起動時間 + ヘルスチェック）。スパイクに備えるなら: - Cloud Run: コンテナの起動が速い（秒単位） - 事前スケール: スケジューラーで最小インスタンス数を事前に増やす - ウォームプール: インスタンスを事前に起動しておく

落とし穴 3: マイグレーション = 一括移行という思い込み

誤解: システムを全部一気にクラウドに移せば良い。正解: 一括移行は最もリスクが高い。PCA 試験では Strangler Fig パターン（徐々に移行）や Blue/Green を選ぶ選択肢が正解になることが多い。

落とし穴 4: 垂直スケーリングを忘れる

誤解: スケーリング = 水平スケーリング（VM 追加）だけ。正解: ステートフルな DB（Cloud SQL）は水平スケーリングが難しいため、垂直スケーリング（Machine Type アップグレード） が現実的な選択肢になる。Read Replica との組み合わせが定石。

⑧ 理解度チェック

以下のシナリオを読んで、GCP アーキテクチャを考えてください:

シナリオ A:

決済システムを GCP に移行したい。要件: - トランザクション中のダウンタイムは一切許容しない（RTO=0） - 過去のトランザクションデータは失えない（RPO=0） - 決済件数はセール時に平常の50倍になる

考えてみてください: どのDBサービスを選びますか？計算レイヤーはどう設計しますか？

シナリオ B:

10年前に作ったオンプレの社内基幹システム（Java + Oracle DB、VM 20台）を GCP に移行したい。ビジネス要件: 「移行中も業務を止めたくない」「まずリスクを最小化したい」

考えてみてください: どの移行戦略（Rehost / Refactor / Rearchitect）から始めますか？どのツールを使いますか？

次回: 1.3 ネットワーク・ストレージ・コンピュートリソースの設計（VPC・ストレージ選定・コンピュート設計）