📚 GCP PCA 学習: 2026-04-18

セクション: 1.1 ビジネス要件を満たすソリューションインフラの設計 前回からの繋がり: 学習スタート。PCA 試験の出発点となる「なぜそのアーキテクチャを選ぶのか」の判断軸を習得する。

① 一言サマリー

ビジネス要件を満たすアーキテクチャ設計とは、一言でいうと「ビジネスの約束（SLA）を守るために、どの GCP サービスをどう組み合わせるかを決める設計判断」です。

② たとえ話

レストランの厨房設計に例えると：

• ビジネス要件 = 「ランチ 200 人を 60 分以内に提供する」「食中毒ゼロ」という経営者との約束
• SLA（稼働率） = 「厨房が止まる時間はランチ時間の 0.1% 以内」
• RPO（データ損失許容） = 「注文票（データ）を最大 5 分分なくしても再注文できる」
• RTO（復旧時間） = 「厨房が壊れても 30 分以内に代替ラインで再開できる」

この 3 つが決まれば、「冷蔵庫を 2 台置くか」「調理台を二重化するか」などの設備設計（アーキテクチャ）が自動的に導かれる。

③ 図解

graph LR
    A[ビジネス要件] --> B[SLA / RPO / RTO]
    B --> C{冗長性レベル}
    C -->|99.9% HA| D[単一リージョン
複数ゾーン]
    C -->|99.99% FT| E[マルチリージョン
自動フェイルオーバー]
    D --> F[Compute Engine MIG
Cloud SQL HA]
    E --> G[Cloud Spanner
Cloud Run グローバル]
    B --> H[コスト制約]
    H -->|最小コスト| D
    H -->|コスト > ダウンタイム損失| E

④ 仕組みの深掘り

SLA とは

一言でいうと、「サービスが正常に稼働している時間の割合についての保証」です。 たとえると、「電気会社が『1年間のうち停電時間は 8.76 時間以内』と約束するもの」です。

RPO とは

一言でいうと、「障害発生時に失ってもよいデータの最大時間幅」です。 たとえると、「バックアップを毎時間取っていれば RPO は 60 分（最大 60 分分のデータを失う可能性がある）」です。

RTO とは

一言でいうと、「障害発生からサービス復旧までに許容される最大時間」です。 たとえると、「レストランで調理器具が壊れた場合、30 分以内に代替方法で料理を再開するという目標」です。

PCA 試験の鍵: RPO と RTO は独立した指標。RPO が短い（データを失えない）場合は同期レプリケーション、RTO が短い（すぐ復旧が必要）場合はホット スタンバイが必要になる。

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

ビジネス要件から GCP サービスを選ぶフローチャート：

graph LR
    Q1{SLA 要件} -->|99.9%| Q2{ステートフル?}
    Q1 -->|99.99%+| A[Cloud Spanner
Cloud Run Global]
    Q2 -->|Yes VM 必要| B[Compute Engine
+ MIG + HA]
    Q2 -->|No コンテナ| C[GKE Regional
Cloud Run]
    Q2 -->|No サーバーレス| D[Cloud Functions
Cloud Run]
    B --> E{DB 要件}
    C --> E
    E -->|ACID 必要| F[Cloud SQL HA]
    E -->|水平スケール| G[Bigtable / Spanner]

⑥ 実務への応用

Cloud Run 本番運用との結びつき: Cloud Run は 99.95% の SLA を提供（Google の保証）。RPO/RTO が緩い（数分許容）Web API であれば Cloud Run + Cloud SQL HA の構成がコストと可用性のバランスが最も良い。RTO が 1 分以内の要件がある場合は Cloud Run のリージョン冗長化を検討する。

Web 系スタートアップ・受託開発での活用: 初期はシングルリージョン・99.9% SLA で設計し、ユーザー増加・契約 SLA の厳格化に合わせてマルチリージョン化するのが現実的。設計書にはビジネス要件（SLA/RPO/RTO の数値）を明記し、アーキテクチャ選択の根拠として残すことで、後工程のトレードオフ判断がスムーズになる。

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

誤解1: 「SLA = 99.99% なら Cloud Spanner 一択」 → SLA はシステム全体で最も弱いリンクで決まる。フロントの Cloud Run が 99.95% なら、バックエンドをいくら強化しても全体 SLA は 99.95% 以下になる。システム全体での SLA 計算が必要。

誤解2: 「RPO=0 はリアルタイムバックアップで実現できる」 → RPO=0 は「1 バイトも失わない」という意味で、実質的には同期レプリケーション（Cloud Spanner など）が必要。コストが非常に高いため、本当に RPO=0 が必要かをビジネス側と合意することが先決。

落とし穴: コスト要件を後回しにする → PCA 試験では「コスト最適化」が必ず問われる。SLA/RPO/RTO を満たしながら最もコストが低い選択肢を選べることが求められる。「高可用性 = 高コスト」ではなく、要件に必要な最低限の冗長構成を選ぶことが正解になる。

⑧ 理解度チェック

ECサイトの注文管理システムを設計しています。要件は「注文データは絶対に失えない（RPO=0 に近い）」「深夜メンテナンスで 30 分停止可（RTO=30 分）」「月間コストを最小化したい」。どの GCP データベースサービスと冗長構成を選びますか？理由も含めて答えてください。

⑨ 深掘り補足（PCA 試験範囲外・オプション）

SLO と SLA の違い SLA（Service Level Agreement）は外部との契約上の約束。SLO（Service Level Objective）は内部目標で、通常は SLA より厳しく設定する（例: SLA 99.9% に対して内部 SLO 99.95%）。余裕分を「エラーバジェット」と呼び、この概念は Section 4.3 の SRE プラクティスで深掘りする。

Well-Architected Framework との対応 Google Cloud の設計原則は AWS Well-Architected Framework に対応する「Google Cloud Architecture Framework」として公開されている（5 柱: 運用優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化）。PCA 試験の選択肢の根拠として参照価値が高い。

次回: 1.2 技術要件を満たすソリューションインフラの設計（高可用性・フォルトトレランス・スケーリング）