📚 GCP PCA 学習: 2026-04-28
セクション: 1.3 ネットワーク・ストレージ・コンピュートリソースの設計 前回からの繋がり: 技術要件（HA・FT・スケーラビリティ）を満たすために、具体的なリソースをどう選ぶかが 1.3 です。
① 一言サマリー
「GCP インフラストラクチャの 3 本柱は VPC・ストレージ・コンピュートで、ビジネス要件と技術要件から『どのトポロジー・何をどこに・何で計算するか』を決める』設計です」
② たとえ話
ビジネスビルディングの設計に例えると：
- VPC：建物の電気・水道・ガス・通信網。サブネット（階）・ルーティング（配線図）・ファイアウォール（セキュリティゲート）で、各テナント（サービス）が安全に通信できる環境を整える
- ストレージ：書庫・冷蔵倉庫・金庫など。データの性質（大量・構造化・秘密度）によって倉庫を使い分ける
- コンピュート：執務スペース・作業室・会議室。タスク（恒常業務・イベント対応・関数計算）によって場所を選ぶ
③ 図解
設計判断フロー
graph LR
A["ビジネス要件
機能・SLA・RTO・RPO"] --> B{"ネットワーク
トポロジーは?"}
B -->|単一リージョン| C["Single VPC"]
B -->|複数リージョン| D["共有 VPC
or VPC Peering"]
A --> E{"ストレージ
何を使う?"}
E -->|構造化・トランザクション| F["Cloud SQL
or Spanner"]
E -->|非構造化・大規模| G["Cloud Storage"]
E -->|NoSQL・リアルタイム| H["Firestore
or Bigtable"]
A --> I{"コンピュート
何で動かす?"}
I -->|既存 VMs| J["Compute Engine"]
I -->|コンテナ・k8s| K["GKE"]
I -->|サーバーレス| L["Cloud Run"]
I -->|イベント駆動| M["Cloud Functions"]
ストレージ選定軸（詳細）
graph LR
A["データ特性"] --> B{"構造化？"}
B -->|Yes| C{"トランザクション
必要？"}
C -->|Yes| D["Cloud SQL
単一リージョン"]
C -->|No| E["Bigtable
大規模 NoSQL"]
B -->|No| F{"サイズ
大？"}
F -->|Yes| G["Cloud Storage
GCS"]
F -->|No| H["Firestore
リアルタイム"]
④ 仕組みの深掘り
VPC トポロジーの選択基準
VPC とは： 仮想ネットワーク。Google が物理的に用意したグローバルネットワークから、テナント（顧客）が独占的に使える論理ネットワークを切り出したもの。
VPC には 3 つの構成パターンがあります：
- 単一 VPC（スタンドアローン）
- 用途：開発環境、小規模なマイクロサービス
- メリット：管理シンプル
-
デメリット：チーム間での共有が複雑（IAM ルール増加）
-
共有 VPC（Shared VPC）
- 用途：大規模組織で複数チーム・複数プロジェクトが同じネットワークを使う
- メリット：集中管理（ネットワークチーム一元化）、ルーティング・ファイアウォール統一
-
デメリット：ネットワークチームが全リソース作成を承認する必要、ボトルネック化のリスク
-
VPC Peering
- 用途：異なる組織・複数リージョンの VPC を接続
- メリット：独立した管理、柔軟な接続
- デメリット：ルーティングテーブルを全 VPC で管理する必要（複雑度増）
PCA 試験の判断軸： - 組織内で 1 つの ネットワーク管理チーム → 共有 VPC - 複数組織 or リージョンをまたがる → VPC Peering
ストレージ選択の 3 軸
ストレージ選択は以下の 3 軸で決まります：
| 軸 | Cloud SQL | Cloud Spanner | Bigtable | Firestore | Cloud Storage |
|---|---|---|---|---|---|
| スキーマ | 関連スキーマ（RDB） | 関連スキーマ | スキーマレス（Wide Column） | ドキュメント | 0 スキーマ（Object） |
| スケール | 単一リージョン（PB まで） | グローバル（EB まで） | 大規模（TB～PB） | 中規模（GB～TB） | 無制限（EB） |
| トランザクション | ○ ACID | ○ ACID（グローバル） | ✗ | ◎ リアルタイム更新 | ✗ |
| レイテンシー | ～ 10ms | ～ 10ms（グローバル） | ～ 1ms | ～ 100ms | ～ 1s |
| 使用例 | Web DB・在庫管理 | グローバル決済 | ユーザー行動・IoT | モバイルアプリ | ログ・静止画 |
| コスト感 | ★★★（中） | ★★★★★（高） | ★★（安） | ★★（安） | ★（非常に安） |
PCA 試験の判断軸： - 「複数リージョンで ACID トランザクション必要」→ Spanner（他を排除） - 「リアルタイムでドキュメント更新が必要」→ Firestore - 「100M 行超の分析データ」→ Bigtable or BigQuery
コンピュート選択の 3 軸
| 軸 | Compute Engine | GKE | Cloud Run | Cloud Functions |
|---|---|---|---|---|
| デプロイ単位 | VM（OS ごと） | Container（k8s マネージド） | Container（サーバーレス） | 関数 ZIP |
| 冗長化 | MIG（手動設定） | Auto Scaling Pod | 自動スケーリング | 自動スケーリング |
| 起動時間 | ～ 1 分 | ～ 10s（Pod） | ～ 100ms（Warm） | ～ 100ms（Warm） |
| スケール範囲 | 数十～数千 | 数千～数万 | ～ 1000 並列 | ～ 1000 並列 |
| ステートフル対応 | ◎ | ◎ | △ | ✗ |
| 月額コスト感（1 台分） | ¥5,000～ | ¥10,000～ | ¥1,000（従量） | ¥100（従量） |
PCA 試験の判断軸： - 「既存 VM アプリケーション」→ Compute Engine - 「マイクロサービス・オーケストレーション」→ GKE - 「トラフィック波状・予測不能」→ Cloud Run（コスト最適） - 「イベント駆動（Pub/Sub）」→ Cloud Functions
⑤ 他サービスとの使い分け
ネットワークトポロジーの判断
「複数の業務チームが同じクラウドに乗り移り、ネットワークポリシーを一元管理したい」
→ 共有 VPC を選ぶ - 理由：ファイアウォールルール・ルート・Cloud NAT がプロジェクト間で共通化できる - 注意：デプロイ権限は各プロジェクトで個別に持つ（Network Admin は中央チーム）
「オンプレミスと AWS に既に存在するシステムと GCP を接続」
→ Cloud Interconnect（専用線）or Cloud VPN（インターネット）で複数 VPC に接続 - 選択基準：専用線は SLA 99.99%, VPN は 99.95%
ストレージの判断
「ユーザーの購入記録を管理し、毎秒数万のクエリがくる」
→ Cloud SQL ではなく Bigtable - 理由：Cloud SQL の上限は TPS（トランザクション/秒）で数千が限界 - Bigtable：キー範囲分割で数万 TPS を捌ける
「複数リージョンで同じデータを読み書きし、一貫性を保つ」
→ Cloud Spanner（他を排除） - 理由：Cloud SQL は同期レプリケーション非対応。Spanner だけが複数リージョン ACID を提供
コンピュートの判断
「短時間で結果を返すが、トラフィックが不規則」
→ Cloud Run > GKE > Compute Engine - 理由：Cloud Run はコンテナを秒単位でスケール・スケールダウン（ゼロに）できる
「GPU を使った機械学習モデルのバッチ処理」
→ Compute Engine（プリエンプティブル VM）or GKE（GPU ノード） - 理由：Cloud Run は GPU 非対応。コスト最適化なら Preemptible
⑥ 実務への応用
シーン 1: ECサイト構築（Web サービス）
要件：
- 在庫を毎分更新（トランザクション必須）
- 100 万ユーザー・レイテンシー < 100ms
- コスト月 ¥500 万以下
選定：
- ストレージ：Cloud SQL（単一リージョン）
→ 理由：トランザクション必須、スケール中程度、クエリ最適化済みなら十分
- コンピュート：Cloud Run（オートスケール）
→ 理由：トラフィック波状、サーバーレス費用最安
- ネットワーク：単一 VPC
→ 理由：単一リージョンなので共有 VPC 不要
シーン 2: グローバル金融システム（決済）
要件：
- 複数リージョン・同時実行
- ACID トランザクション必須
- 99.99% SLA
選定：
- ストレージ：Cloud Spanner
→ 理由：複数リージョン ACID はこれしかない
- コンピュート：GKE（複数リージョン）
→ 理由：Spanner との遅延を最小化、複雑な業務ロジック、障害時フェイルオーバー
- ネットワーク：Cloud Interconnect（複数リージョン）
→ 理由：99.99% SLA のため専用線必須
シーン 3: IoT データ収集・分析
要件：
- 100 万台のセンサーから秒単位でデータ取得
- リアルタイム集計は不要（後で分析）
- コスト最小化
選定：
- ストレージ：Bigtable（時系列データベース）
→ 理由：大量データ・高書き込み速度・低レイテンシー・コスト安
- コンピュート：Cloud Functions
→ 理由：Pub/Sub イベント駆動、スケーリング自動
- ネットワーク：Cloud VPN / MQTT Broker
→ 理由：エッジデバイス ← → Pub/Sub の通信パス
⑦ よくある誤解・落とし穴
誤解 1: 「GKE は常に最適」
❌ よくある間違い：「マイクロサービスなら GKE」と思い込む ✅ 正解：GKE は複雑性が高い（ノード管理・ネットワークポリシー・RBAC）。シンプルなら Cloud Run で十分。コストも 1/3 以下。
→ PCA 試験では 「無駄な複雑性を避ける」 のが採点ポイント
誤解 2: 「Cloud SQL は小規模のみ」
❌ よくある間違い：「Cloud SQL は 100GB までしかスケールしない」 ✅ 正解：Cloud SQL は ストレージ 65TB まで対応。TPS（毎秒トランザクション）が制限だから、Cloud SQL の上限（数千 TPS）で十分なら「無理に Spanner に移すな」が正解。
→ Spanner はコスト 10 倍なので、本当に必要か問い詰める
誤解 3: 「共有 VPC は常に使うべき」
❌ よくある間違い：「スケーラビリティのため共有 VPC」 ✅ 正解：共有 VPC は 管理集中化のため。複数チーム・複数プロジェクトで 同一のネットワークルール を使うときのみ。
→ 小規模スタートアップなら単一 VPC で十分
誤解 4: 「Cloud Storage は遅い」
❌ よくある間違い：「Cloud Storage は秒単位で返ってくる」 ✅ 正解：Cloud Storage は 1s でテラバイト単位のデータ を返す。「遅い」のではなく「バッチ処理向け」。 - リアルタイム取得が必要 → Bigtable / Firestore - バッチ分析 → Cloud Storage + BigQuery
→ PCA 試験では「適用シーンの誤認識」を狙われる
⑧ 理解度チェック
問題
「毎秒 1 万件のセンサーデータを受け取り、直近 1 分間の平均値をリアルタイムで API で返すシステムを設計します。複数リージョンでの冗長化は不要、コストは月 ¥10 万以下です。
以下のどの組み合わせを選びますか？理由も含めて。」
選択肢 A: Cloud SQL + Cloud Run（単一リージョン） 選択肢 B: Bigtable + GKE（複数インスタンス） 選択肢 C: Firestore + Cloud Functions 選択肢 D: Cloud Storage + BigQuery
解説
正解は A（もしくは C）
根拠： - 秒単位のデータ: Cloud SQL の TPS（数千）では足りない × → Bigtable が良い候補 - リアルタイム API: Firestore ✓（遅延 100ms）or Bigtable ✓（遅延 1ms） - 複数リージョン不要: GKE 多インスタンスは過剰複雑 × → Cloud Run が最安 - 月 ¥10 万以下: Bigtable（月 ¥20 万以上）はギリギリ、Firestore ✓（月 ¥5 万以下）
→ 最も正解に近い: Firestore + Cloud Run - 理由：リアルタイム更新・自動スケーリング・管理シンプル・コスト最安 - 懸念：Firestore の書き込み速度（秒 1,000 件/秒）を超える場合は Bigtable に変更
⑨ 深掘り補足（PCA 試験範囲外）
VPC Flow Logs の活用
Preview サービスではなく GA サービスです
VPC Flow Logs を有効にすると、VPC 内のすべてのパケットログが Cloud Logging に記録されます。 PCA 試験ではネットワークトラブルシューティングで登場：
問：「GKE クラスタ内から外部 API へのリクエストが失敗している。原因を特定するには？」
答：VPC Flow Logs から次を確認
1. ファイアウォールルールで DENY されているか
2. Cloud NAT が機能しているか
3. ルーティングテーブルに経路があるか
Cloud CDN + Cloud Storage の組み合わせ
静止画・ビデオ配信では Cloud Storage + Cloud CDN の組み合わせが鉄板：
構成：
Client → Cloud CDN（エッジロケーション）
→ Cloud Storage（オリジン）
効果：
- 初回リクエスト: Cloud Storage から取得（~1s）
- 2 回目以降: エッジキャッシュから返却（~100ms）
- 月額コスト: Cloud Storage + CDN 利用料のみ（サーバーレス費用なし）
vs Cloud Run:
- Cloud Run: 起動時間 100ms、スケーリング無制限だが月額高い
Auto Scaling の落とし穴（実務応用）
GKE / Cloud Run の自動スケーリングは CPU 平均使用率 をベースに動きます。
悪い例：
- 閾値 50% に設定
- リクエスト 1,000 個スパイク
→ スケールアップまで ~30 秒（その間 CPU 100%）
→ ユーザー体験：レイテンシー 5 秒以上に悪化
良い例：
- 予測的スケーリング（GKE）or リクエストベース（Cloud Run）
- ウォームアップ時間 ~10 秒で早期スケールアップ
→ PCA 試験では「SLA 99.9% で 99.95% のスケーリング信頼性が必要」で出題される可能性
次回: 1.4 マイグレーション計画の作成