Section 2: インフラ管理とプロビジョニング — 🔧 応用編

対象: 実務 3-5 年・GCP 経験あり / トレードオフ・運用判断・最新サービス を体系化したい人。 目標: 試験で問われる「運用に耐える正しい選択」を高精度で出せるようになる。

1. ネットワークトポロジーの応用

1.1 VPC 設計パターン（4 種）

Shared VPC               Hub-and-Spoke (NCC)
┌─────────────┐         ┌──── NCC Hub ────┐
│ Host        │         │                  │
│  ├─ VPC     │      ┌──┴── Spoke VPC 1 ──┐
│  └─ Subnet  │      │      Spoke VPC 2   │
└──┬─────┬────┘      │      Spoke VPC 3   │
   │     │           │      AWS VPC       │
 Svc1   Svc2         │      On-prem VPN   │
 (IAM)  (IAM)        └────────────────────┘

Shared VPC は組織内、Peering は組織を跨ぐ場合。AWS では Transit Gateway が NCC に相当。

1.2 Firewall 設計の階層

階層的に評価される順（上が優先）:
1. Hierarchical Firewall Policy（組織/フォルダ）
2. Global Network Firewall Policy（VPC グローバル）
3. Regional Network Firewall Policy（VPC リージョン）
4. VPC Firewall Rules（旧来のルール）
5. Implied rules（implied allow egress / deny ingress）

運用ベストプラクティス：

• 組織レベル: 必ず deny したい通信（不正サイトへの egress 等）を Hierarchical で強制
• VPC レベル: ワークロード固有のルールは Network Firewall Policy で管理
• タグ: 旧 Network Tags ではなく Secure Tags（IAM 管理されたタグ） を使用

1.3 Cloud Armor の設計

Internet → Cloud Armor (Edge) → Global LB → Backend
              ↓
        ・OWASP ルール
        ・Adaptive Protection
        ・Geo/IP/Rate Limiting

1.4 Private Service Connect (PSC) のパターン

   コンシューマー VPC                プロデューサー VPC
  ┌────────────────┐               ┌────────────────┐
  │ アプリ VM     │               │ サービス VM   │
  │   ↓           │               │   ↑           │
  │ PSC Endpoint  │ ─── PSC ───→  │ Service       │
  │ (10.0.0.5)    │               │ Attachment    │
  └────────────────┘               └────────────────┘

1.5 Cloud NAT vs Cloud VPN vs Cloud Router

ハイブリッド構成では Cloud Router + HA VPN または Interconnect が標準。

1.6 ロードバランサ詳細選定

公開 or 内部？
  公開 →
    L7 (HTTP/HTTPS)？
      グローバル → Global External Application LB（最も推奨）
      リージョン固定 → Regional External Application LB
      Classic（旧） → Global External Application LB (Classic)
    L4 TCP/UDP？
      Anycast IP・プロキシ → Global External Proxy NLB
      直接通信・IP 保持 → Regional External Passthrough NLB
  内部 →
    L7 → Internal Application LB
    L7 + マルチリージョン → Cross-region Internal Application LB
    L4 → Internal Passthrough NLB

LB のバックエンド種別

1.7 マルチクラウド/ハイブリッド設計の判断軸

2. ストレージ詳細運用

2.1 Cloud Storage のクラス選定（コスト最適化）

Autoclass

アクセスパターンに応じ 自動でクラス変更。手動ライフサイクル不要。新規バケットで有効化推奨。

2.2 オブジェクトロックの使い分け

2.3 Cloud Storage のアクセス制御

2.4 データ転送方式の選定

Storage Transfer Service の主なソース

• 他クラウド: AWS S3 / Azure Blob
• オンプレ: HTTP/HTTPS、POSIX ファイルシステム（エージェント経由）
• GCS 間

2.5 ブロックストレージ詳細

Persistent Disk vs Hyperdisk

Local SSD の特徴

• VM に 直結された NVMe SSD
• 超低レイテンシ・高 IOPS
• 永続化されない（VM 停止で消える）
• スクラッチ用途（一時データ、SAP HANA データキャッシュ）

2.6 データベース運用の応用

Cloud SQL の HA 設計

Spanner の運用

• Configurations: Regional / Multi-region（強整合性 + 99.999% SLA） / Custom
• Backup: Full / Incremental、リテンション最大 1 年
• Database Operations: スプリット最適化、Index/Schema 変更はオンラインで実施可能
• Spanner Vertex AI Integration: SQL から直接 Vertex AI モデルを呼べる

BigQuery の運用

• Reservations (Editions): Standard / Enterprise / Enterprise Plus
• Autoscaler: スロット数の自動増減
• Partition / Cluster: コスト・性能最適化
• Time Travel: 過去 7 日間のスナップショット
• Fail-safe: Time Travel 終了後さらに 7 日リカバリ可能

2.7 Backup and DR Service 詳細

試験頻出: 「統合バックアップ + DR」 → Backup and DR Service。

3. コンピュート詳細運用

3.1 マシンファミリーの選定

3.2 Spot vs Standard の判断

Spot VM 設計のコツ

• 冗長性: 複数ゾーン/リージョンで分散
• チェックポイント: 中断シグナルで状態を保存
• MIG + Spot: MIG が中断後に自動再作成
• 混在: Standard でベースライン、Spot でピーク吸収

3.3 MIG の運用パターン

3.4 OS Config / VM Manager 運用

パッチ管理ライフサイクル:
1. OS Inventory       … インストール済みパッケージ把握
2. Vulnerability Reports  … 既知脆弱性レポート
3. OS Policy Assignments  … 構成管理（パッケージ・ファイル）
4. OS Patch Jobs / Deployments … パッチ適用ジョブ
5. Patch Compliance       … パッチ適用状況の可視化

設定例：

# パッチデプロイ
gcloud compute os-config patch-deployments create monthly-patch \
  --file=patch-config.yaml

試験頻出: 「VM 全体に統合パッチ管理」 → VM Manager (OS Patch Management)。

3.5 GKE 詳細運用

Workload Identity（推奨パターン）

Kubernetes Service Account (KSA)
        ↓ Workload Identity Binding
Google Service Account (GSA)
        ↓
GCP リソースへのアクセス

• ノードに広く GSA を付ける旧来パターンは非推奨
• Pod 単位で最小権限を実現

GKE のスケーリング

GKE Enterprise（旧 Anthos）

• Fleet 管理: 複数クラスタを統合管理
• Multi-cluster Ingress / Services: クラスタ跨ぎサービス公開
• Config Sync: GitOps でクラスタ設定同期
• Policy Controller: OPA Gatekeeper による Policy
• Service Mesh: マネージド Istio
• Connect Gateway: オンプレ/他クラウド K8s を統合操作

3.6 サーバーレスの応用

Cloud Run の主要機能

Cloud Run functions の特徴（旧 Cloud Functions Gen2）

• Cloud Run 上に構築されたので、Cloud Run の機能を継承
• イベントトリガー: GCS / Pub/Sub / Firestore / Eventarc 経由のすべて
• 最大実行時間: HTTP 60 分 / Event 9 分

Workflows と Eventarc

3.7 VMware Engine (GCVE) の運用判断

GCVE が選ばれるケース

GCVE の構成

プライベートクラウド (Private Cloud)
└─ クラスタ (3-32 ノードのベアメタル)
   ├─ vCenter Server
   ├─ NSX-T Manager / Edge
   ├─ vSAN
   ├─ HCX Manager
   └─ ESXi ホスト

GCVE と GCP サービスの統合

4. Vertex AI のエンドツーエンド ML

4.1 Vertex AI Pipelines の設計パターン

標準的なパイプライン構成

Ingestion → Preprocessing → Training → Evaluation → Validation → Deployment → Monitoring
   ↓             ↓             ↓           ↓            ↓              ↓               ↓
BigQuery     Dataflow     Custom/AutoML  Eval Metrics  Model Card   Endpoints     Model Monitoring
GCS         Beam               TPU/GPU                                              Drift Detection

再利用性のテクニック

• コンポーネント: 再利用可能な小単位（Container Component / Python Component）
• パラメータ: パイプライン入力（データセットパス、ハイパーパラメータ）
• キャッシュ: 同一入力なら再実行不要
• Conditional / ParallelFor: 条件分岐・並列実行

4.2 Vertex AI Feature Store

オンライン推論用の 低レイテンシ特徴量ストア。

試験で問われる典型: 「学習と推論で同じ特徴量定義を使う」 → Feature Store。

4.3 学習リソースの選定

4.4 デプロイパターン

4.5 Model Monitoring

4.6 AI Hypercomputer の運用

構成判断

Pathways の役割

• マルチホスト分散 を抽象化（数千チップ）
• JAX/PyTorch から透過的 に利用
• データパラレル / モデルパラレル / パイプラインパラレル統合

コスト最適化

5. プリビルト AI と API 統合

5.1 Gemini Enterprise の構成判断

5.2 NotebookLM の活用

• 複数のソース（PDF / Google Docs / Web / GCS）を 同時に AI に読ませる
• 質問に 引用元付き で回答（ハルシネーション低減）
• 業務マニュアル / 法令 / 設計書 のサーベイに最適

試験頻出: 「社内ナレッジ Q&A」「引用必須」 → NotebookLM。

5.3 Model Garden の選定軸

5.4 Google AI API の使い分け

5.5 統合アーキテクチャ例（Gemini Enterprise + Vertex AI + AI API）

┌─────────────────────────────────────────────┐
│ User Channel: Web / Slack / Teams / 電話    │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│ Gemini Enterprise Agentspace                 │
│  ├─ Conversational Agents (対話制御)        │
│  ├─ NotebookLM (ナレッジ参照)               │
│  └─ Custom Agent (業務ロジック)             │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│ Vertex AI                                    │
│  ├─ Model Garden (Gemini / Claude / Llama)  │
│  ├─ Custom Models (自社ファインチューン)    │
│  ├─ Feature Store                           │
│  └─ Endpoints (オンライン推論)              │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│ Data & API Layer                             │
│  ├─ BigQuery / Cloud SQL / Spanner          │
│  ├─ Document AI (帳票OCR)                   │
│  ├─ Translation / Speech / Vision API       │
│  └─ Apigee (バックエンド API 集約)          │
└─────────────────────────────────────────────┘

6. AWS / Azure との比較（中堅以上）

試験では基本「GCP のベストプラクティス」を選ぶ。他クラウドからの移行話で「そのまま使いたい」場合は VMware Engine が登場。

7. 設計判断のトレードオフ例

ケース 1: 既存 VMware 環境 1000 VM の移行

要件: 6 ヶ月で完了、ハイパーバイザーは VMware 維持、最小ダウンタイム

B を選ぶ が正解。

ケース 2: AI 学習で TPU と GPU を混在させたい

要件: 大規模 LLM 学習、ハードウェアを柔軟に切り替え

C を選ぶ が正解。

ケース 3: 社内ドキュメント 10 万件を AI で検索したい

要件: 引用元必須、ハルシネーション最小化、IT 部門で短期構築

B を選ぶ が正解。

ケース 4: マルチリージョン GKE の Pod 増加で IP 枯渇

要件: 既存サブネットを変更せず Pod を増やしたい

B を選ぶ が正解（GKE は Discontiguous な複数セカンダリ範囲をサポート）。

8. 運用ベストプラクティス

8.1 IaC とプロビジョニング

8.2 タグとラベル

8.3 監視と可観測性

• Cloud Monitoring: メトリクス + ダッシュボード + アラート
• Cloud Logging: ログ集約 + Log-based Metrics + ログ分析
• Cloud Trace: 分散トレーシング
• Cloud Profiler: 本番 CPU/メモリプロファイリング
• Cloud Debugger（廃止予定）: 本番デバッグ

8.4 オーガナイゼーションポリシー

9. 章末まとめ

必ず覚える「運用判断パターン」

次のステップ

• 直前確認: 03_要点と暗記.md
• 演習: ../../03_問題集/section2_問題集.md
• 関連セクション: Section 3 (セキュリティ)、Section 5 (実装管理)