Section 1: アーキ設計と計画 — 🔧 応用編

対象: 実務 3-5 年・GCP 経験あり / 設計判断・トレードオフ・サービス選定マトリクス・移行戦略 を体系化したい人。 目標: 試験で問われる「正しい選択」を高精度で出せるようになる。

1. ビジネス要件 → 技術要件 → サービス選定の翻訳

翻訳テクニック

ビジネス要件 → 技術要件 → サービス選定 の 3 段階の翻訳 を、典型パターンで暗記しておくと試験で即答できます。

2. KPI・ROI・成功指標の設計

設計判断を支える指標

試験での頻出パターン

「ROI を最大化するアーキは？」→ コスト削減 + 売上増 の両立 を見せる選択肢を選ぶ 「TCO を低減したい」→ マネージドサービス + コミットメント + 自動化 の組合せ

3. Workload Disposition 戦略（4 つの判断）

新規システムや既存システムの扱いを決める判断。

試験での頻出

「既存のオンプレ ERP は今後 1 年で運用予定」→ Retain または Modify（クラウド移行は急がない） 「メール送信サービス自前運用」→ Buy（SendGrid 等の SaaS に切り替え）

4. 移行戦略 6R（重要・頻出）

オンプレ・他クラウドからの移行を計画する際の 6 つの選択肢。

6R 判断フローチャート

このシステムは将来も必要？
  NO → Retire（廃止）

既存の SaaS で代替可能？
  YES → Repurchase（置換）

クラウド化のメリットがある？
  NO → Retain（維持）
  YES ↓

  クラウドネイティブに作り直す価値ある？
    YES → Refactor（再構築）
    NO ↓

    マネージドサービスを一部使う？
      YES → Replatform（部分マネージド化）
      NO → Rehost（そのまま移行）

Migration Center（2024年以降の最新サービス）

旧 Stratozone を統合した 移行アセスメント・計画・実行プラットフォーム。

主要機能：

• Discovery: オンプレ環境を自動スキャン（mCollector / vSphere / Hyper-V）
• Assessment: ワークロードを評価（適合度、推奨サービス、コスト試算）
• Recommendation: 6R 戦略の推奨
• Migration Plan: 移行ウェーブと依存関係の可視化
• Migration Execution: M4CE / Database Migration Service と連携

試験頻出: 「オンプレからの移行アセスメント」が問われたら Migration Center が正解。

5. 高可用性とフェイルオーバー設計

可用性のレイヤー

サービス別の冗長化方式

フェイルオーバー戦略

6. ネットワーク設計の応用

LB 選定マトリクス

Private Service Connect（PSC）

サービスプロデューサーとコンシューマーを VPC を超えてプライベート接続 する仕組み。

3 つのバリエーション：

• PSC for Google APIs: googleapis.com にプライベート IP でアクセス
• PSC for Published Services: 自社サービスをエンドポイント経由で公開
• PSC for Managed Services: マネージドサービス（Cloud SQL, Memorystore 等）にプライベート接続

ハイブリッド/マルチクラウド接続

Network Connectivity Center (NCC)

ハブ&スポーク型のネットワーク管理。複数の VPN/Interconnect/SD-WAN を一元管理。

オンプレ DC1 ─┐
オンプレ DC2 ─┼─ NCC Hub ─┬─ GCP VPC A
AWS VPC ────┘            ├─ GCP VPC B
                          └─ GCP VPC C

7. ストレージ詳細選定

Cloud SQL vs AlloyDB vs Spanner

BigQuery vs Bigtable

Firestore のモード

• Firestore (Native): モバイル・Web 向け、リアルタイム同期
• Firestore in Datastore mode: 旧 Datastore 互換、サーバーアプリ向け

新規プロジェクトは Native を推奨。

8. コンピュート詳細選定

GKE Autopilot vs Standard

Cloud Run vs Cloud Run functions

Compute Engine の最適化

• Custom Machine Type: vCPU / メモリを任意に指定可能（既製サイズに縛られない）
• Sole Tenant Node: 物理ノード占有（規制対応・BYOL）
• Confidential VM: メモリ暗号化（AMD SEV / Intel TDX）
• Spot VM: 最大 91% 割引、24 時間以内に中断の可能性
• GPU/TPU: AI/ML 用、Spot 適用可能

9. データ処理の選定

Dataflow vs Dataproc vs BigQuery

Composer vs Workflows

10. AI/ML 統合の応用

Vertex AI の使い分け

データ準備
  └── BigQuery / Cloud Storage / Vertex AI Feature Store

学習
  ├── AutoML（GUI ベース、コード不要）
  ├── Custom Training（独自モデル、Container/Script）
  └── Pre-trained API（Vision, NL, Translation API など、即利用可）

デプロイ・推論
  ├── Vertex AI Endpoints（オンライン推論）
  ├── Vertex AI Batch Prediction（バッチ）
  └── Model Garden（事前学習モデル選択）

オーケストレーション
  ├── Vertex AI Pipelines（Kubeflow ベース）
  └── Vertex AI Workbench（Jupyter 環境）

Gemini Enterprise Agent Platform（最新）

旧 Vertex AI Agent Builder からリブランド。LLM 駆動のエージェント を構築するプラットフォーム。

構成要素：

• Agents: 業務特化 AI エージェント（カスタマーサポート、検索 など）
• Data Stores: ナレッジソース（Web/構造化データ/非構造化データ）
• NotebookLM: AI ノートブック（複数ソースから引用付き回答）
• Discovery AI（旧 Vertex AI Search）: エンタープライズ検索

AI Hypercomputer（大規模 AI 学習）

巨大モデル学習のための 統合スーパーコンピュータ製品。

ハードウェア層
├── TPU v5e/v5p/Trillium（学習用）
├── GPU H100 / A100 / L4
└── Jupiter Optical Circuit Switching ネットワーク

ストレージ層
├── Cloud Storage（Anywhere Cache、Hierarchical Namespace）
├── Hyperdisk
└── Parallel File System (Lustre)

ソフトウェア層
├── JAX / PyTorch / TensorFlow
├── Pathways（マルチホスト分散）
└── Kubernetes / Slurm

「自前 ML vs マネージド AI API」の選定

11. Gemini Cloud Assist（最新追加）

GCP コンソール内で動作する AI アシスタント。設計・トラブルシュート・コード生成を支援。

主な活用シーン：

• アーキ設計の壁打ち（「100 RPS のチャットボットを設計したい」）
• 障害時のログ解析支援
• gcloud CLI コマンド生成
• Terraform/IaC コードのレビュー
• ドキュメント検索（自然言語）

12. 将来構想（クラウドファースト設計）

クラウドファーストの原則

進化を見越したアーキ

• 疎結合: Pub/Sub でサービス間を非同期化
• マルチリージョン対応: 単一リージョン構成でもマルチリージョン化を見越したデータ設計
• マイクロサービス志向: モノリスでもサービス境界を明確に
• 拡張ポイント: API ゲートウェイ（Apigee）で将来の機能追加を容易に

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

ケース 1: コスト vs 信頼性

要件: 月 99.95% 可用性 + 月 $5,000 以内 → マルチリージョン構成だと月 $15,000 ↑

選択肢：

• A: シングルリージョン Cloud SQL HA + GKE Regional（コスト低、99.95% 達成可能）
• B: マルチリージョン Spanner + GKE Multi-cluster（コスト高、99.999% 達成）

A を選ぶ が正解（要件を満たす最小コスト構成）

ケース 2: 開発速度 vs 柔軟性

要件: 3 ヶ月で MVP リリース、その後拡張予定 → 自前 K8s だと 1 ヶ月インフラ構築で消える

選択肢：

• A: Cloud Run（開発速度最優先）
• B: GKE（柔軟性最優先）

A を選ぶ が正解（MVP は速度優先、拡張時に GKE 移行も可能）

ケース 3: グローバル展開 vs シンプルさ

要件: 全世界のユーザーに 200ms 以内 → シングルリージョンだと太平洋越え 300ms+

選択肢：

• A: Spanner Multi-region + Global LB + Cloud CDN
• B: 各リージョンに独立した Cloud SQL + アプリ

A を選ぶ が正解（強整合性が必要なら Spanner 一択）

14. 章末まとめ

必ず覚える「翻訳パターン」

次のステップ

• 直前確認: 03_要点と暗記.md
• 演習: ../../03_問題集/section1_問題集.md
• 関連セクション: Section 2 (インフラ管理), Section 3 (セキュリティ)