Section 1: アーキ設計と計画 — 📘 基礎編
対象: 実務 1-2 年・GCP 初学者 / クラウドアーキテクチャの考え方を初めて学ぶ人。 目標: 6 柱の Well-Architected を理解し、主要サービスの役割と選定軸を把握する。
1. クラウドソリューションアーキテクチャとは何か
アーキテクチャ設計の役割
クラウドアーキテクトは、ビジネス課題 を 技術ソリューション に翻訳する人です。例えば：
| ビジネス課題 | 技術ソリューション例 |
|---|---|
| 「夜間バッチが朝までに終わらない」 | Dataflow に並列化、または BigQuery に移行 |
| 「グローバル展開で 100ms 以内に応答したい」 | Spanner + Global LB + Cloud CDN |
| 「コストを 30% 削減したい」 | Spot VMs + Committed Use Discounts + Right-sizing |
| 「監査要件で全アクセスログを 7 年保存」 | Cloud Audit Logs + Cloud Storage Archive |
設計プロセスの 5 ステップ
1. 要件定義 → 2. 設計 → 3. 検証 → 4. 移行/構築 → 5. 運用・改善
↓ ↓ ↓ ↓ ↓
ヒアリング アーキ図 PoC 段階移行 継続改善
KPI/ROI サービス選定 テスト 本番リリース コスト最適化
2. Google Cloud Well-Architected Framework
GCP のアーキテクチャ判断は、必ずこの 6 本の柱 を判断軸として使います。
6 本の柱
| 柱 | 観点 | 代表的な判断例 |
|---|---|---|
| Operational Excellence（運用上の卓越性） | 自動化・観測可能性・継続的改善 | Cloud Monitoring SLO、Cloud Logging、IaC |
| Security（セキュリティ） | IAM・暗号化・コンプライアンス | IAM 最小権限、CMEK、VPC SC |
| Reliability（信頼性） | SLO・冗長化・DR | マルチリージョン、HA VPN、PITR |
| Performance Optimization（性能最適化） | レイテンシ・スループット | Premium Tier、Cloud CDN、近接性 |
| Cost Optimization（コスト最適化） | TCO、コミットメント | Committed Use、Spot、Autoclass |
| Sustainability（持続可能性） | カーボンフットプリント | リージョン選定、効率化 |
トレードオフの考え方
6 柱は 互いに競合する ことがあります。例：
| トレードオフ | 例 |
|---|---|
| 信頼性 vs コスト | マルチリージョン化（コスト 2-3 倍）⇔ 単一リージョン |
| 性能 vs セキュリティ | 全リクエスト DLP 検査（遅延増）⇔ サンプリング検査 |
| 運用容易性 vs 柔軟性 | Cloud Run（簡単）⇔ GKE（柔軟だが運用負担） |
設計判断には常にトレードオフがある ことを意識し、ビジネス価値を最大化 する選択をします。
3. 要件定義（ビジネス要件 vs 技術要件）
ビジネス要件（Business Requirements）
何を達成したいか を表す要件。
例：
- 売上を 20% 増やしたい
- カスタマーサポートコストを 30% 削減
- 規制対応（HIPAA/GDPR）を必達
- 99.9% の可用性を維持
技術要件（Technical Requirements）
どう実現するか を制約する要件。
例：
- 1,000 RPS のスループット
- 平均応答時間 200ms 以下
- データはアジア圏内に保存（データ主権）
- 既存のオンプレ AD と統合
機能要件 vs 非機能要件
| 種類 | 内容 | 例 |
|---|---|---|
| 機能要件 | システムが「何を」するか | ユーザー登録、注文処理 |
| 非機能要件 (NFR) | システムが「どのように」するか | 性能、可用性、セキュリティ、保守性 |
試験で頻出: NFR を必ず特定 して、それに応じたサービス選定をする。
4. ネットワーク設計の基礎
VPC（Virtual Private Cloud）
GCP のネットワーク基盤。プロジェクト横断のグローバルリソース で、リージョン間を内部通信できます。
プロジェクト
└─ VPC ネットワーク（グローバル）
├─ サブネット（リージョン A: 10.0.1.0/24）
├─ サブネット（リージョン B: 10.0.2.0/24）
├─ ファイアウォール ルール
└─ ルート
ネットワーク接続方式
| 方式 | 用途 | 帯域・SLA |
|---|---|---|
| Dedicated Interconnect | 大規模・高速接続 | 10 Gbps / 100 Gbps、SLA 99.99% |
| Partner Interconnect | 中規模・パートナー経由 | 50 Mbps – 50 Gbps |
| Cloud VPN (HA VPN) | 中小規模・暗号化 | 最大 3 Gbps/トンネル、SLA 99.99% |
| Cloud VPN (Classic VPN) | レガシー | SLA 99.9%（HA VPN を推奨） |
Shared VPC vs VPC Peering vs Private Service Connect
| 方式 | 用途 | 特徴 |
|---|---|---|
| Shared VPC | 組織内の複数プロジェクトでネットワーク共有 | ホストプロジェクト + サービスプロジェクトの集中管理 |
| VPC Peering | 異なる VPC 間の接続 | 1:1 接続、推移性なし |
| Private Service Connect (PSC) | サービス側エンドポイント公開 | プライベート IP でマネージドサービスにアクセス |
5. ストレージ設計の基礎
ストレージ選定マトリクス
あなたのデータは？
├── オブジェクト（ファイル、画像、動画、バックアップ）
│ └── Cloud Storage
│ ├── Standard（頻繁アクセス）
│ ├── Nearline（30日以上アクセスなし、月1回程度）
│ ├── Coldline（90日以上、四半期に1回）
│ └── Archive（365日以上、年1回）
│
├── 共有ファイルシステム（NFS/SMB）
│ └── Filestore
│
├── ブロックストレージ（VM 用ディスク）
│ └── Persistent Disk / Hyperdisk
│
├── リレーショナル
│ ├── 単一リージョン
│ │ └── Cloud SQL (MySQL/PostgreSQL/SQL Server)
│ └── グローバル、強整合性
│ └── Spanner
│
├── ドキュメント / モバイル同期
│ └── Firestore
│
├── ワイドカラム / 時系列・IoT
│ └── Bigtable
│
├── キャッシュ
│ └── Memorystore (Redis/Memcached)
│
└── 分析 / DWH
└── BigQuery
Cloud Storage のストレージクラス
| クラス | アクセス頻度 | 最低保持期間 | 取り出し料金 |
|---|---|---|---|
| Standard | 頻繁 | なし | 無料 |
| Nearline | 月 1 回 | 30 日 | あり |
| Coldline | 四半期 1 回 | 90 日 | あり |
| Archive | 年 1 回 | 365 日 | 高い |
Autoclass を有効化すると、アクセスパターンに応じて GCS が自動でクラス変更してくれます（手動管理不要）。
6. コンピュート設計の基礎
コンピュート選定フローチャート
ステートフル（VM 状態を保持） or 自由な OS が必要？
YES → Compute Engine（IaaS）
NO ↓
Kubernetes が必要？
YES → GKE（コンテナオーケストレーション）
├── Autopilot: 完全マネージド、Pod 単位課金
└── Standard: ノード管理あり、柔軟
NO ↓
ステートレス HTTP・イベント駆動？
YES → Cloud Run / Cloud Run functions
├── Cloud Run: コンテナベース、HTTP / イベント駆動
└── Cloud Run functions: 関数ベース、軽量（旧 Cloud Functions）
NO ↓
Web/モバイルアプリで、Google プラットフォーム標準でOK？
YES → App Engine（PaaS）
コンピュート選定マトリクス
| サービス | 抽象度 | スケーリング | 課金 | 用途 |
|---|---|---|---|---|
| Compute Engine | IaaS | 手動/Auto | VM 単位（秒課金） | レガシー移行、特殊 OS、GPU/TPU |
| GKE | コンテナ K8s | Pod/Node | Pod 単位（Autopilot）/ Node 単位 | マイクロサービス、複雑なオーケストレーション |
| Cloud Run | コンテナ Serverless | 0〜1000+ | リクエスト課金 | ステートレス HTTP、API、Web |
| Cloud Run functions | 関数 Serverless | 0〜N | 呼出回数 + 実行時間 | イベント駆動、軽量処理 |
| App Engine | PaaS | 0〜N | インスタンス時間 | レガシー Python/Java Web |
Spot VM vs Standard VM
| 項目 | Spot VM | Standard VM |
|---|---|---|
| 価格 | 最大 91% 割引 | 通常 |
| 中断 | 24 時間以内に終了の可能性 | 中断なし |
| 用途 | バッチ、CI/CD、Spark、ML 学習 | 本番アプリ、DB |
| 再起動 | 自動再起動なし | あり |
7. データ移行の基礎
移行方法（データ量別）
| データ量 | 方法 | 期間 |
|---|---|---|
| < 1 TB | gcloud / gsutil で直接アップロード | 数時間 |
| 1-10 TB | Storage Transfer Service（オンライン） | 数日 |
| 10-100 TB | Storage Transfer Service（オンライン）+ 専用線 | 1-2 週 |
| > 100 TB | Transfer Appliance（物理デバイス郵送） | 数週間 |
Database Migration Service
オンプレ・他クラウドの DB を Cloud SQL / Spanner に 最小ダウンタイムで移行 するサービス。
サポート対象:
- MySQL → Cloud SQL for MySQL
- PostgreSQL → Cloud SQL for PostgreSQL
- SQL Server → Cloud SQL for SQL Server
- Oracle → AlloyDB / PostgreSQL（最近追加）
8. AI/ML 統合の基礎
Vertex AI
GCP の ML プラットフォーム。データ準備 → 学習 → デプロイ → 監視 を統合管理。
Vertex AI の主要機能
├── AutoML（コードなしで学習）
├── Custom Training（独自モデル学習）
├── Pipelines（ML ワークフローオーケストレーション）
├── Feature Store（特徴量管理）
├── Workbench（Jupyter 環境）
├── Model Registry（モデル管理）
└── Model Garden（事前学習モデルのカタログ）
Gemini と Model Garden
- Gemini: Google の最新 LLM（Pro/Flash/Nano）
- Model Garden: Gemini に加え、PaLM、Llama、Claude、Mistral など多モデルを統一インターフェースで使える
AI Hypercomputer（最新追加）
大規模 AI 学習・推論のためのスーパーコンピュータ製品。
構成要素：
- TPU / GPU クラスタ (Trillium TPU, H100/A100 GPU)
- Jupiter NW（高速ネットワーク）
- GCS + Hyperdisk（高速ストレージ）
- JAX / PyTorch / TensorFlow 統合
- Pathways 分散学習フレームワーク
Gemini Cloud Assist（最新追加）
GCP コンソール内に組み込まれた AI アシスタント。
- アーキテクチャ設計の支援
- トラブルシューティング
- コード生成
- ドキュメント検索
9. コスト最適化の基礎
コスト最適化の 5 つの観点
- Right-sizing: VM サイズ・スペックを実需に合わせる（Recommender が提案）
- コミットメント: 1-3 年契約で 30-55% 割引（Committed Use Discounts）
- Spot 活用: 中断許容可能なワークロードを Spot に
- 自動スケール: アイドル時にスケールダウン（GKE Autopilot / Cloud Run / Autoscaling MIG）
- ストレージ階層化: GCS Autoclass、BigQuery のパーティション/クラスタリング
コスト見える化のツール
- Cloud Billing: 課金状況確認
- Billing Budgets: 予算アラート
- Recommender: コスト最適化提案（VM Right-sizing 等）
- Active Assist: AI ベースの最適化提案
10. まとめ — 設計の判断フロー
1. ビジネス要件をヒアリング
↓
2. 機能要件 + 非機能要件 (NFR) を整理
↓
3. Well-Architected の 6 柱で各要件を分類
↓
4. 各レイヤーでサービス選定
- ネットワーク (VPC / Interconnect / LB)
- コンピュート (GCE / GKE / Cloud Run / functions)
- ストレージ (GCS / Cloud SQL / Spanner / BigQuery / Bigtable / Firestore)
- AI/ML (Vertex AI / Gemini / Model Garden)
↓
5. トレードオフを言語化（コスト vs 信頼性 vs 性能 vs 運用容易性）
↓
6. ROI/KPI で成功基準を定義
↓
7. 移行/構築計画（6R: Rehost/Replatform/Refactor/Repurchase/Retain/Retire）
↓
8. 運用・改善計画（Operational Excellence の柱）
次のステップ
- 中堅レベルへ進む方:
02_応用.mdで サービス選定マトリクス・トレードオフ分析・移行戦略 6R を学ぶ - 試験準備中の方:
03_要点と暗記.mdで要点を整理 - 演習を始める方:
../../03_問題集/section1_問題集.md