コンテンツにスキップ

📚 GCP PCA 学習: 2026-04-27

セクション: 1.2 技術要件を満たすソリューションインフラの設計 前回からの繋がり: 1.1 ではビジネス要件から SLA・RPO・RTO を引き出したが、1.2 ではそれを「どのように実装するか」という技術設計へ具体化する。SLA が 99.99% なら FT 設計が必須、99.9% なら HA で十分、という判断軸が決まる。

① 一言サマリー

「技術要件を満たす設計とは、ビジネス要件の稼働率・復旧戦略を実装するために、どの構成を選ぶかという判断です。高可用性・フォルトトレランス・スケーラビリティの 3 つの技術軸が独立しており、それぞれの組み合わせでアーキテクチャが決まります。」

② たとえ話

料理人の厨房運営で考える

  • 高可用性（HA）: 料理人が 1 人で調理していて、トイレに行く間は別の料理人に交代する。交代時間は短いが、一瞬サービスが止まる可能性がある。複数の料理人がいて、一人がダウンしても即座に次の人が引き継げるイメージ。

  • フォルトトレランス（FT）: 複数の料理人が全く同じ調理をしていて、1 人が包丁を落としても他の人が継続する。サービスが完全に途絶えない。コスト（料理人の人数）が倍以上かかる。

  • 弾力性・スケーラビリティ: ランチタイム前に料理人の数を 3 人に増やし、閉店後は 1 人に減らす。「需要に応じて資源を自動調整」するイメージ。

③ 図解

graph LR
    A["ビジネス要件
SLA/RPO/RTO"] --> B["技術要件を分類"]
    B --> C["可用性設計
HA vs FT"]
    B --> D["スケーラビリティ設計
動的スケーリング"]
    B --> E["マイグレーション設計
ライセンス考慮"]

    C --> C1["High Availability
99.9%まで"]
    C --> C2["Fault Tolerance
99.99%以上"]

    D --> D1["Vertical Scaling
マシン大きくする"]
    D --> D2["Horizontal Scaling
台数増やす"]

    C1 --> C1a["1つ壊れたら
フェイルオーバー"]
    C2 --> C2a["複数同時運用
一つが壊れても
続行"]

    D2 --> D2a["MIG
自動スケール"]
    D2 --> D2b["GKE
自動スケール"]
    D2 --> D2c["Cloud Run
自動スケール"]

用語注釈

  • 高可用性（HA）とは: ダウンタイムを最小化する設計。複数のインスタンス・リージョンを用意して、片方が落ちたら即座に他方へ切り替える。一瞬の遅延・接続ロスが生じる可能性。

  • たとえると：銀行の窓口が 2 つあって、片方の窓口の店員が休憩したら、客は別の窓口に並び直す。

  • フォルトトレランス（FT）とは: ダウンタイムを完全にゼロにする設計。複数のシステムが並列実行し、一つが故障しても利用者は気づかない。

  • たとえると：飛行機のエンジンが 4 つあって、1 つが停止しても他 3 つで飛行継続。

  • スケーラビリティとは: 負荷増加に対して柔軟に対応する能力。手動または自動で資源を増減する。

④ 仕組みの深掘り

4-1. HA と FT の技術的根拠

HA（99.9% SLA の場合）

具体例: Cloud SQL （Regional）+ 読み取りレプリカ

Primary DB       Replica DB
   (us-central1)  (us-central1)
        |              |
     (同期中)
        |              |
  フェイルオーバー時：
  Primary が死ぬ → Replica を Primary に昇格
  → 数秒から数十秒のダウンタイム
  • フェイルオーバー時間: 検知 + 昇格で通常 30 秒〜1 分
  • データ整合性: ほぼ保証されるが、フェイルオーバー直前のコミット分は失われる可能性
  • コスト: インスタンス 2 台分（Compute + Storage）
  • 運用: 手動または Cloud SQL の自動フェイルオーバー設定

HA が活躍する場面: - Web サービス（ステートレス）: 一瞬のダウンタイムは許容 - API サービス: 接続池があるため、クライアント側でリトライす可能 - データ分析ワークロード: バッチ処理のため多少の遅延は無視可能

FT（99.99% SLA 以上の場合）

具体例: Cloud Spanner（複数リージョン構成）

リージョン A      リージョン B      リージョン C
Primary replica   Replica           Replica
  (write)      (read)            (read)
     |             |                |
  Paxos コンセンサスで同期
     |             |                |
  リージョン A が完全に壊れても
  → B / C から即座に Primary を選出
  → ユーザーは全く気づかない
  • 復旧時間: ほぼ 0 秒（自動フェイルオーバー）
  • データ整合性: 強一貫性（ACID）を常に保証
  • コスト: インスタンス 3+ 台分（リージョン毎）→ 数倍高コスト
  • 運用: ほぼ自動（管理者の介入最小化）

FT が活躍する場面: - 金融システム（決済）: 99.99% 以上の可用性が法的要件 - 証券取引所・リアルタイムシステム: 1 ミリ秒の遅延も許されない - ミッションクリティカルなバックアップシステム

4-2. スケーラビリティの 2 つの軸

垂直スケーリング（Vertical Scaling）

  • 方法: マシンのスペック（vCPU・メモリ）を上げる
  • 例: n1-standard-4 → n1-standard-8
  • メリット: 再起動一度で済む、アプリケーション変更不要
  • デメリット: リソース上限がある（GCP Compute Engine では最大 161 vCPU）、スケール完了までに分単位の時間
  • どんな時に使うか: データベース（CPU/メモリ集約的）・分析ワークロード（単一マシンの高スペック化で十分）

水平スケーリング（Horizontal Scaling）

  • 方法: マシンの台数を増やす
  • 例: 2 台 → 4 台
  • メリット: 理論上限がない（台数を増やし続ければよい）、スケール完了が高速（分単位）、障害時の局所化
  • デメリット: アプリケーションがステートレスである必要がある、ロードバランサーの管理、セッション管理が必要
  • どんな時に使うか: Web サーバー・API・マイクロサービス（トラフィック変動が激しい）

4-3. 動的スケーリングの仕組み

監視 → 判定 → スケール の 3 ステップで自動化

  1. 監視: Cloud Monitoring でメトリクス収集

  2. CPU 使用率、メモリ使用率、リクエスト数、カスタムメトリクス など

  3. 判定: オートスケーラーが設定に基づき判定

  4. 閾値超過時：スケール UP

  5. 閾値以下時：スケール DOWN（クールダウン有り）

  6. スケール: インスタンス起動 or シャットダウン

  7. 起動時間（ウォームアップ）を考慮した先読み

例：MIG（Managed Instance Group）の設定 

目標 CPU 使用率: 70%
最小インスタンス数: 2
最大インスタンス数: 10
スケールアップ時間: 2 分
スケールダウン時間: 10 分（冷却期間）

トラフィック急増 → CPU が 75% に → スケール UP 開始 → 30 秒で新インスタンス起動 → CPU が 72% に低下 → 安定

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

スケーラビリティ要件に基づく PCA 判断軸

要件 HA 設計 FT 設計
SLA 目標 99.9% 99.99% 以上
許容ダウンタイム 数秒〜1 分 / 月 完全ゼロに近い
コスト / 複雑度 低い 高い
適用対象 Web / API サービス 金融・医療・重要インフラ
フェイルオーバー 手動 or 自動（秒単位） 自動（ミリ秒単位）
データ整合性 最終的一貫性 強一貫性

動的スケーリング対応サービス比較

graph LR
    A["スケーリング要件"] --> B["自動スケーリング戦略"]

    B --> B1["Compute Engine
MIG"]
    B --> B2["GKE
Cluster Auto Scaling"]
    B --> B3["Cloud Run
自動スケール"]

    B1 --> B1a["特徴"]
    B1 --> B1b["最小 2分"]
    B1 --> B1c["グループの概念"]
    B1 --> B1d["IaC 推奨"]

    B2 --> B2a["特徴"]
    B2 --> B2b["最小 1分"]
    B2 --> B2c["Pod + Node 両層"]
    B2 --> B2d["マネージド"]

    B3 --> B3a["特徴"]
    B3 --> B3b["最小数秒"]
    B3 --> B3c["自動マネージド"]
    B3 --> B3d["サーバーレス"]

詳細比較

1. Compute Engine + MIG（Managed Instance Group）

使い分けの判定条件: - アプリケーションがIaaS（OS レベルの細かい制御が必要） - 例）Java アプリケーション・カスタムミドルウェア・GPU・TPU - 負荷パターンが定期的（朝 9 時に増加、夜中に減少など）

スケーリング戦略: - Metrics-based: CPU / メモリ / カスタムメトリクス - Scheduled: 時刻に基づく事前スケーリング

復旧戦略: - 不健全なインスタンスを自動置換（Health Check に基づく） - マイグレーション中のインスタンスは自動削除・再起動

コスト最適化: - Preemptible VM / Spot VM で非本番運用のコスト削減

2. GKE（Google Kubernetes Engine）

使い分けの判定条件: - コンテナ化されたマイクロサービス - Pod 単位で細かい制御が必要 - 複数の異なるアプリケーションが同一クラスタで共存

スケーリング戦略: - Pod Autoscaling（HPA: Horizontal Pod Autoscaler） - Deployment / StatefulSet 単位で Pod 数を増減 - CPU / メモリ / カスタムメトリクス

  • Node Autoscaling（Cluster Autoscaler）
  • Pod が起動できる Node がなくなったら、Node を追加
  • 逆に Node が不要なら削除

復旧戦略: - Pod が壊れたら自動再起動 - Node が壊れたら Pod を別 Node に移行

運用コスト: Terraform + Google Cloud Deploy で GitOps 化

3. Cloud Run

使い分けの判定条件: - サーバーレス 希望（インフラ管理ゼロ） - API / Webhook / バッチ処理（15 分以内の短時間実行） - 言語：Python / Go / Node.js / Java など（コンテナ互換）

スケーリング戦略: - 自動・完全マネージド - 受け取ったリクエスト数に応じて自動スケール（秒単位） - コンテナは使い終わったら即座に削除

復旧戦略: - デプロイ自体がステートレス - リビジョン管理で即座にロールバック可能

コスト: - 使わない時間は完全に無料 - 実行時間（100ms 単位）のみ課金

⑥ 実務への応用

ユースケース 1: Web スタートアップの初期構成（HA 設計）

要件: - ユーザー数が急増する可能性 - スケーラビリティ重視、高可用性も欲しい - インフラ管理はなるべく手をかけたくない

推奨アーキテクチャ: 

ユーザー
   ↓
Cloud Load Balancer（ロードバランシング）
   ↓
Cloud Run / GKE（自動スケーリング）
   ↓
Cloud SQL（Regional + 自動バックアップ）
   ↓
Cloud Storage（マルチリージョンレプリケーション）

判定軸: - Cloud Run 選択理由: デプロイが簡単、スケーリング自動、従量課金で初期コスト低い - Cloud SQL Regional: SLA 99.95%、復旧が自動、バックアップ世代管理あり - HA 設計で十分: スタートアップは初期段階で FT は不要（コスト 3 倍以上）

実務での工夫: - パフォーマンス監視を Cloud Monitoring で早期に構築 - SLO を最初から定義（例: 99.5% / P99 レイテンシ 500ms） - キャッシュ戦略（Cloud CDN + Cloud Memorystore for Redis）

ユースケース 2: 金融系の本番システム（FT 設計）

要件: - SLA 99.99% 以上が法的要件 - データの一貫性が必須（金銭的損害につながる） - ダウンタイムゼロで本番リリース可能

推奨アーキテクチャ: 

リージョン A          リージョン B
（米国中部）           （欧州）
   ↓                   ↓
Cloud Spanner（マルチリージョン、強一貫性）
   ↓
Cloud Spanner（自動レプリケーション、リージョン間）
   ↓
Cloud Storage + Cloud CDN（リージョン別ダッシュボード）

判定軸: - Cloud Spanner: ACID 保証、複数リージョン自動同期、99.99% SLA - FT 構成: リージョンが 3 つ以上、任意の 1 リージョン喪失でも継続動作 - 高コスト許容: コスト / 複雑度は二次的（稼働率要件が優先）

実務での工夫: - 定期的な Disaster Recovery ドリル（別リージョンへのフェイルオーバー試験） - Cloud Audit Logs で全 SQL を記録 - エラーバジェット管理（毎月の許容ダウンタイム 43 秒以内）

ユースケース 3: メディア配信サービス（Horizontal Scaling + キャッシング）

要件: - トラフィックが時間帯で大きく変動 - ビデオ配信で低遅延・高帯域幅 - グローバル対応

推奨アーキテクチャ: 

グローバルユーザー
   ↓
Cloud CDN（エッジキャッシング）
   ↓
Cloud Load Balancer（ロードバランシング）
   ↓
GKE Autopilot（水平スケーリング）
   ↓
Cloud Storage（マルチリージョン・ライフサイクル管理）
   ↓
Firestore / Bigtable（メタデータ・ユーザー履歴）

判定軸: - Cloud CDN: キャッシュヒット率 90%+ で帯域幅コスト 10 分の 1 以下に - GKE Autopilot: Node 管理がマネージド、Pod オートスケーラーが自動 - Bigtable: 時系列データ（再生ログ）の高速フィルタリング（P99 < 10ms）

実務での工夫: - キャッシュキー戦略（動的コンテンツはキャッシュしない、静的コンテンツは 24h） - エッジロケーション設定（視聴者が多い地域に優先的にキャッシュ配置） - 秒単位のオートスケーリング設定（トラフィック予測 + 実際の負荷に基づく）

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

誤解 1: 「HA = Fault Tolerance」

よくある間違い: - HA 構成なら完全に故障しないと思い込む - レプリカを用意すれば 99.99% SLA が達成できると勘違い

実際: - HA は「フェイルオーバーが早い」だけで、フェイルオーバー中は数秒のダウンタイムが発生 - FT は「複数の本体が並列実行」するため、1 つ壊れても利用者に影響なし

PCA 試験での判定: - 問題文で「99.95% SLA」→ HA で十分 - 問題文で「99.99% 以上 / ダウンタイムゼロ」→ FT（複数リージョン）必須

誤解 2: 「CPU が 70% なら常にスケール UP」

よくある間違い: - 閾値 70% を設定したら、ずっと 70% で上下するサイクルが続く（スケール UP / DOWN が繰り返される） - 新しいインスタンスが起動している間、トラフィックはどこに行くのか曖昧

実際: - Cooldown Period（冷却期間）が必要：スケール UP した後、10 分間は DOWN しない - ウォームアップ期間：新インスタンスが起動して初回リクエストを捌くまで 30〜60 秒かかる - キャパシティの余裕：閾値 70% は「これ以上はヤバい」という警告信号で、平時は 40〜50% が目安

PCA 試験での判定: - 「トラフィック急増時に素早く対応」→ Cooldown を短く、最大インスタンス数を多く - 「コスト削減」→ Cooldown を長く、最小インスタンス数を少なく - 「安定性重視」→ ターゲット CPU を 50% に、スケール DOWN は無効化

誤解 3: 「GKE なら何でも自動スケール」

よくある間違い: - GKE Cluster Autoscaler が有効なら、Pod がすぐに起動すると思い込む - Pod が Pending 状態のまま放置される理由を理解していない

実際: 

リクエスト発生
   ↓
HPA が新 Pod を起動しようとする
   ↓
利用可能な Node がない
   ↓
Cluster Autoscaler が新 Node を追加（2〜3 分かかる）
   ↓
新 Pod が起動

スケーリング速度の階層: 1. Pod Autoscaler：最速（秒単位） 2. Node Autoscaler：中速（1〜3 分） 3. リージョン間フェイルオーバー：遅い（分単位）

PCA 試験での判定: - 「秒単位で対応」→ Cloud Run or Pod の事前起動 - 「分単位で対応」→ GKE Cluster Autoscaler - 「時間単位で OK」→ MIG + Scheduled Scaling

誤解 4: 「マイグレーション = 物理移動」

よくある間違い: - オンプレから GCP へのマイグレーション = VM イメージをそのまま移す（Rehost）だけが解だと思い込む - ライセンス移行の複雑さを無視

実際: 

マイグレーション戦略 5R
├── Rehost（リホスト）: そのまま移動
│   └── オンプレ VM → Compute Engine VM
│   └── ライセンス: 既存ライセンス活用可能
│
├── Refactor（リファクタ）: クラウド機能を活用
│   └── オンプレ DB → Cloud SQL / Cloud Spanner
│   └── ライセンス: 新規購入or サブスク
│
├── Rearchitect（アーキテクト）: 再設計
│   └── オンプレ Java App → GKE / Cloud Run
│   └── ライセンス: 新しい価格体系
│
├── Rebuild（リビルド）: スクラッチ開発
│   └── Firebase / BigQuery 活用
│
└── Replace（リプレイス）: SaaS 利用
    └── Salesforce / Workday など

PCA 試験での判定: - 「現在のシステムをそのまま移す」→ Rehost（最速・最小改変） - 「クラウドの利点を最大化したい」→ Rearchitect（時間・コスト大） - 「ライセンスコストを削減」→ Rearchitect / Replace を検討

⑧ 理解度チェック

問題 1: SLA と技術設計の結びつき

シナリオ: あなたは SaaS 企業の Cloud Architect です。新しいバックエンド API サービスをリリースします。 - 顧客との SLA は 99.95% - 現在のトラフィック：100 req/s - ピーク時トラフィック（予測）：1000 req/s - 負荷は夜間に大幅に減少する

Q1: このサービスには HA 設計と FT 設計のどちらが適切ですか？理由も含めて。

A1 案: - HA 設計が適切 - 理由：SLA が 99.95% という月間ダウンタイム許容が約 22 分なので、数秒のフェイルオーバー時間は許容範囲内。FT 設計にするとコスト 2.5 倍以上（リージョン複数化）になり、投資対効果が悪い。

問題 2: スケーリング戦略の選択

前問の続き

Q2: ピーク時の 1000 req/s に対応するため、以下のどれを採用しますか？ 1. Compute Engine + MIG + Vertical Scaling 2. GKE + Pod Autoscaler 3. Cloud Run

それぞれのメリット・デメリットと、最適選択理由を述べてください。

A2 案: - 最適選択: Cloud Run - 理由： - 従量課金：夜間に完全スケールダウン → コスト削減 - デプロイが簡単：CI/CD パイプラインが最小構成 - スケーリングが秒単位で自動

  • 他の選択肢の評価：
  • MIG：ノード管理のオーバーヘッド、スケーリング遅い（2〜3 分）→ ×
  • GKE：Kubernetes 管理のオーバーヘッド、夜間のコストが無駄 → △

問題 3: マイグレーションとライセンス

シナリオ: オンプレミスで Oracle Database を運用している銀行です。 - 15 年運用、ビジネスロジックが深く統合 - ライセンスコスト：年間 $500k - リスク最小化が最優先

Q3: 以下のマイグレーション戦略の中で、最も適切なのは？ライセンスコストと復旧時間を観点に理由を述べてください。

  1. Oracle VM → Compute Engine VM（Rehost）
  2. Oracle → Cloud SQL for Oracle
  3. Oracle → BigQuery（Rearchitect）

A3 案: - 最適選択: 1. Rehost - 理由： - ライセンス：既存ライセンス（Oracle on-prem）を Compute Engine VM での実行に流用可能（Oracle ULA: Unlimited License Agreement がある場合） - リスク：ビジネスロジック変更ゼロ、復旧計画（バックアップ・リストア）がそのまま流用可能 - コスト：初期投資は最小（VM 移動のみ）、ライセンス削減は段階的

  • 他の選択肢の評価：
  • Cloud SQL for Oracle：ライセンス新規購入が必須（年間 $300k+ 追加）→ △
  • BigQuery：15 年のビジネスロジック完全リビルド必要 → ×

⑨ 深掘り補足

Compute Engine の最新 GA 機能：Fractional GPU

2026 年 4 月に GA となった G4 GPU シリーズの Fractional GPU は、スケーラビリティ設計に新しい選択肢をもたらしました。

従来の課題: - GPU（例: NVIDIA A100）は高額（$1000+ / 月） - アプリケーションが GPU を 100% 活用していない場合、コストが無駄 - スケーリングは「GPU 台数の整数」のみ（1 台 or 2 台）

Fractional GPU の仕組み: 

従来: 1 GPU (full) → 1 仮想マシン専有
新機能: 1/2, 1/4, 1/8 GPU → 複数 VM で共有

例）G4 GPU で ML 推論
    - 8 個の推論サーバーが 1/8 GPU ずつ使用
    - コスト：1 GPU の 1/8
    - レイテンシ：通常 < 100ms

PCA 試験での位置づけ: - スケーラビリティ設計で「GPU ワークロードをコスト最適化」する場合の選択肢 - Vertical Scaling（GPU スペック UP）との比較： - Fractional GPU：複数 VM で分散（Horizontal） - 従来：1 VM で GPU UP（Vertical）

実務での活用: - ML 推論サーバー：複数ユーザーのリクエストを共有 GPU で処理 - 非リアルタイム処理：バッチ推論を Fractional GPU で時間制約なく実行

HA / FT 設計の決定フローチャート

sequenceDiagram
    participant ビジネス要件分析
    participant SLA確認
    participant 設計判定
    participant 実装

    ビジネス要件分析 ->> SLA確認: RTO / RPO / 稼働率要件を確認

    SLA確認 ->> 設計判定: SLA ≤ 99.95% ?

    alt 99.95% 以下（HA で十分）
        設計判定 ->> 実装: Cloud SQL Regional / GKE / Cloud Run + LB
        実装 ->> 実装: フェイルオーバー秒単位
    else 99.95% 超（FT 検討）
        設計判定 ->> 設計判定: ダウンタイムゼロが法的要件 ?

        alt Yes（金融・医療）
            設計判定 ->> 実装: Cloud Spanner / Firestore Multi-region
            実装 ->> 実装: 複数リージョン, 自動フェイルオーバー
        else No（コスト優先）
            設計判定 ->> 実装: HA + バックアップ / DR ドリル
        end
    end

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