クラウドソリューションの計画と実装 — 初学者でもわかる詳細解説とベストプラクティス
クラウドソリューションの計画と実装 — 4つのサブドメインと17章の体系的学習ガイド
GCE・Spot VM・GKE・Cloud Run・Cloud Functions — どのサービスをいつ使うかを判断するフレームワーク
「どのコンピューティングサービスを使うか？」を判断するフローチャート
アプリケーションをどのように動かしたい？
│
├── VM（仮想マシン）が必要？
│ ├── 普通の VM → Compute Engine (GCE)
│ └── コスト削減OK・停止されても大丈夫 → Spot VM + MIG
│
├── コンテナを使う？
│ ├── Kubernetes でオーケストレーション → GKE
│ │ ├── 運用を Google に任せたい → GKE Autopilot（推奨）
│ │ └── カーネル設定など細かい制御が必要 → GKE Standard
│ └── HTTP リクエストで動くステートレスなアプリ → Cloud Run
│
└── 関数（コードの断片）を実行したい？
└── イベント駆動の軽量処理 → Cloud Functionsアーキテクチャ計画段階でのコスト見積もりと制御メカニズムを理解することが、クラウド破産を防ぐ鍵です。
BigQuery で LIMIT 句を使っても、列指向ストレージの特性上スキャンされるデータ量（課金対象バイト数）は一切減少しません。必ずテーブルプレビュー機能を使い、クエリ前に推定コストを確認してください。
マシンファミリー・ディスク種類・OS Login・ネットワーク設定 — IaaS の完全ガイド
Compute Engine は Google Cloud の IaaS（Infrastructure as a Service）です。Linux や Windows の仮想マシン（VM）を自由に作成・管理できます。
【Compute Engine でできること】 ・OS の完全な制御（カーネルパラメータの変更など） ・カスタム VM サイズの設定 ・GPU/TPU の接続 ・静的 IP アドレスの割り当て ・OS レベルのソフトウェアインストール ・特定のライセンス（Windows Server, SQL Server 等）の利用
マシンファミリーの選択基準
汎用（General Purpose）: N2, N2D, E2, T2D
→ 通常の Web サーバー、開発環境、中程度のワークロード
→ E2 が最もコスト効率が高い（コスト重視ならまずE2）
コンピューティング最適化（Compute Optimized）: C2, C2D
→ CPU 性能が最優先（ゲーム、HPC、高スループット計算）
メモリ最適化（Memory Optimized）: M2, M3
→ 大容量 RAM が必要（SAP HANA、大型インメモリDB）
→ 最大 12TB のメモリ
アクセラレーター最適化（Accelerator Optimized）: A2, A3, G2
→ GPU/TPU が必要（ML トレーニング、推論、3D レンダリング）マシンタイプの命名規則
例: n2-standard-4
│ │ └── vCPU 数（4コア）
│ └── シリーズ（standard = バランス型）
└── ファミリー（n2 = 第2世代汎用）
シリーズの種類:
standard = vCPU と メモリのバランス型（vCPU : メモリ = 1:4）
highmem = メモリ多め（vCPU : メモリ = 1:8）
highcpu = CPU 多め（vCPU : メモリ = 1:1）
micro/small = 最小構成（共有 vCPU）Local SSD のデータは VM が停止・削除されると消えます。永続化が必要なデータには使用しないこと。
❌ アンチパターン: 静的 SSH 鍵の使用
【問題のある旧来の方法】
VM のメタデータに SSH 公開鍵を登録
↓
退職した社員の鍵が残り続ける
↓
不正アクセスのリスクが継続
↓
鍵の棚卸し作業が膨大✅ 推奨: OS Login
OS Login は IAM を通じて SSH アクセスを管理します。
【OS Login の仕組み】
1. IAM で roles/compute.osLogin（一般ユーザー）
または roles/compute.osAdminLogin（sudo権限）を付与
2. 社員が SSH 接続しようとする
↓
3. OS Login が IAM をリアルタイムに照会
↓
4. IAM でロールを持っていれば接続OK
IAM でロールを削除（退職処理）→ 即時アクセス不可
【メリット】
✓ IAM とライフサイクルを統合（退職 = アクセス消滅）
✓ 個別の SSH キーをローテーションする必要なし
✓ Linux アカウントを自動生成・管理
✓ 詳細な監査ログが自動記録OS Login の設定方法
# プロジェクト全体に OS Login を有効化 gcloud compute project-info add-metadata \ --metadata enable-oslogin=TRUE # 特定の VM にのみ OS Login を有効化 gcloud compute instances add-metadata VM_NAME \ --metadata enable-oslogin=TRUE # 本番環境では 2FA を追加（強く推奨） gcloud compute project-info add-metadata \ --metadata enable-oslogin-2fa=TRUE # ユーザーに OS Login ロールを付与 gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/compute.osLogin" # sudo 権限が必要な場合は osAdminLogin を使用 gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/compute.osAdminLogin"
JIT（Just-In-Time）アクセス
本番環境での一時的な特権アクセスには JIT を採用します。
【JIT アクセスの流れ】
1. エンジニアが緊急作業の必要性を検知
2. JIT リクエストを送信（理由を記述）
3. 承認者がリクエストを承認
4. 一時的に sudo ロールを付与（例: 2時間）
5. 作業完了後、自動的に権限が剥奪
6. 全操作が監査ログに記録
【なぜ重要か】
常時 admin 権限を持つアカウントが侵害されると
→ 取り返しのつかない被害
JIT では権限は作業時間だけに限定される
→ 被害を最小化できる外部 IP アドレスの管理
【一時的な外部 IP (Ephemeral)】 VM の起動時に自動割り当て VM 停止時に解放される（再起動すると変わる） コスト: 無料（使用中） 【静的な外部 IP (Static)】 明示的に予約する VM が停止しても保持される コスト: 予約中は有料（VM に割り当て中は無料） 【外部 IP なし（推奨: セキュリティ）】 プライベートネットワーク内のリソースだけからアクセス Cloud NAT でインターネットへのアウトバウンドは可能 セキュリティ上のリスクを最小化
ファイアウォールルール
# HTTP/HTTPS を許可するファイアウォールルール作成 gcloud compute firewall-rules create allow-http-https \ --network=my-vpc \ --action=ALLOW \ --rules=tcp:80,tcp:443 \ --target-tags=web-server \ --source-ranges=0.0.0.0/0 # SSH を特定の IP からのみ許可 gcloud compute firewall-rules create allow-ssh-bastion \ --network=my-vpc \ --action=ALLOW \ --rules=tcp:22 \ --target-tags=bastion \ --source-ranges=203.0.113.0/24
最大91%割引の余剰リソース活用 — チェックポイント設計とプリエンプション対応の完全ガイド
Google のデータセンターには、常に余剰の計算リソースがあります。Spot VM はその余剰リソースを格安で提供する仕組みです。
【通常の VM】 ・確実に稼働し続ける ・通常料金（例: n2-standard-4 = 約$0.19/時間） 【Spot VM】 ・余剰リソースを利用するため最大 91% 割引 ・Google がリソースを必要としたら 30秒前通知で強制停止される ・例: n2-standard-4 = 約$0.02/時間（約90%割引）
Spot VM はいつでも停止される可能性があります。ステートフルなアプリや停止が許されないサービスには使用禁止！
✅ 向いているワークロード: ├── バッチ処理（夜間の大量データ処理） ├── ML/AI モデルのトレーニング ├── 3D レンダリング、動画エンコード ├── ゲノム解析などのサイエンティフィック計算 └── 継続的インテグレーション（CI）のビルド/テスト ❌ 向いていないワークロード: ├── Web サーバー（ユーザーへの影響大） ├── データベース（データの整合性が壊れる可能性） ├── ステートフルなアプリ（状態が失われる） └── 停止が許されないミッションクリティカルなサービス
① 終了アクションの設定
# Spot VM 作成時に終了アクションを設定 gcloud compute instances create my-spot-vm \ --machine-type=n2-standard-4 \ --provisioning-model=SPOT \ --instance-termination-action=STOP # STOP または DELETE # STOP: VM を停止状態にする（ローカルディスクのデータ保持） # → キャパシティが戻った時に再起動可能 # DELETE: VM を削除する（最小コスト・ローカルデータ消失）
② シャットダウンスクリプトの設定
# 停止前に状態を Cloud Storage に保存するスクリプト
#!/bin/bash
# /etc/google-cloud/metadata/shutdown-scripts
echo "Spot VM preemption detected. Saving checkpoint..."
# 処理の進捗を Cloud Storage に保存
gsutil cp /var/app/checkpoint.dat gs://my-batch-bucket/checkpoints/job-${JOB_ID}.dat
# 処理ログを保存
gsutil cp /var/log/app.log gs://my-batch-bucket/logs/job-${JOB_ID}.log
echo "Checkpoint saved. Shutting down."gcloud compute instances add-metadata VM_NAME \ --metadata-from-file shutdown-script=shutdown.sh
③ チェックポイントの実装パターン
# バッチ処理でのチェックポイント実装例（Python）
import signal
import json
from google.cloud import storage
checkpoint_file = "gs://my-bucket/checkpoints/job.json"
is_preempted = False
def handle_sigterm(signum, frame):
"""SIGTERM を受け取ったら（プリエンプション通知）"""
global is_preempted
is_preempted = True
save_checkpoint(current_progress)
print("Checkpoint saved, shutting down gracefully")
signal.signal(signal.SIGTERM, handle_sigterm)
def save_checkpoint(progress):
"""進捗を GCS に保存"""
client = storage.Client()
# ... チェックポイントをGCSに書き込み
def load_checkpoint():
"""前回の進捗を GCS から読み込み"""
# ... GCS からチェックポイントを読み込み
pass
# メイン処理（チェックポイントから再開）
last_checkpoint = load_checkpoint()
for i in range(last_checkpoint, total_items):
if is_preempted:
break
process_item(i)
current_progress = i通常の ML トレーニングジョブ:
A2 Ultra（8x A100 GPU） 通常料金: $32.77/時間
Spot VM 割引（約70%）: $9.83/時間
10時間のトレーニング:
通常: $327.70
Spot: $98.30
節約: $229.40（約70%節約）！自動ヒーリング・オートスケーリング・ローリングアップデート — 高可用性VM管理の完全ガイド
MIG（Managed Instance Group）は、インスタンステンプレート から同一設定の VM を複数自動管理する機能です。
インスタンステンプレート（設計図）
├── マシンタイプ: n2-standard-4
├── OS イメージ: debian-11
├── ディスクサイズ: 100GB
└── スタートアップスクリプト: install_app.sh
↓ MIG が自動的に複数の VM を作成・管理
VM1（asia-northeast1-a）
VM2（asia-northeast1-b）
VM3（asia-northeast1-c）機能① 自動ヒーリング（Auto Healing）
ヘルスチェックで VM の異常を検知
↓
異常な VM を自動的に削除
↓
新しい VM を自動作成
→ 人間が介入しなくてもサービスを維持！ヘルスチェックの設定
# ヘルスチェックを作成 gcloud compute health-checks create http my-health-check \ --port=80 \ --request-path=/health \ --check-interval=30s \ --timeout=10s \ --healthy-threshold=1 \ --unhealthy-threshold=3 # MIG にヘルスチェックを設定 gcloud compute instance-groups managed set-autohealing my-mig \ --health-check=my-health-check \ --initial-delay=300 # 起動後300秒は異常判定しない
機能② 自動スケーリング（Autoscaling）
負荷が増加 → VM を自動追加（スケールアウト） 負荷が減少 → VM を自動削除（スケールイン） スケーリングの指標: ├── CPU 使用率（最もシンプル） ├── HTTP リクエスト数（LB と連携） ├── Cloud Monitoring カスタムメトリクス └── Pub/Sub キューの深さ（バッチ処理に有効）
# CPU 使用率 60% を目標にオートスケールを設定 gcloud compute instance-groups managed set-autoscaling my-mig \ --max-num-replicas=10 \ --min-num-replicas=2 \ --target-cpu-utilization=0.6 \ --cool-down-period=90
機能③ ローリングアップデート（Rolling Update）
旧バージョンのインスタンステンプレート
↓ ローリングアップデート
新バージョンのインスタンステンプレート
・1台ずつ順番に更新（サービスを止めない）
・問題が発生したらロールバック可能# ローリングアップデートを実行 gcloud compute instance-groups managed rolling-action start-update my-mig \ --version=template=new-template \ --max-surge=1 \ --max-unavailable=0 # 同時に停止できるVM数（0=サービス継続）
# リージョン MIG の作成（本番環境推奨） gcloud compute instance-groups managed create my-regional-mig \ --template=my-template \ --size=6 \ --region=asia-northeast1 # ゾーンではなくリージョンを指定
--provisioning-model=SPOT）max-num-replicas に上限を設ける（コスト暴走防止）max-unavailable=0 を設定してゼロダウンタイム更新Autopilot vs Standard・Workload Identity・Binary Authorization・オートスケーリングの完全ガイド
【Kubernetes の主要オブジェクト】
Pod（ポッド）
└── 1つ以上のコンテナをまとめた最小デプロイ単位
例: nginx コンテナ + ログ収集サイドカー
Deployment（デプロイメント）
└── Pod の望ましい状態を定義・管理
例: 「このアプリを3つのレプリカで動かす」
Service（サービス）
└── Pod へのネットワークアクセスを提供
例: 「このラベルを持つPodに負荷分散する」
Node（ノード）
└── Pod が実際に動く仮想マシン（VM）
GKE では Compute Engine VM が Node になる
Namespace（ネームスペース）
└── クラスタを論理的に分割する仮想境界
例: namespace: frontend, backend, monitoringモード選択のフローチャート
特権コンテナが必要？ → YES → Standard モード
カーネルパラメータの変更が必要？ → YES → Standard モード
DaemonSet でのエージェント配置が必要？ → YES → Standard モード
既存のノード管理チームがある？ → YES → Standard モード
↓
それ以外の場合
↓
Autopilot モード（推奨）🚀 GKE Autopilot モード
【Autopilot でGoogle が自動管理するもの】
インフラ管理:
├── ノードのプロビジョニング（VM の作成）
├── ノードのスケーリング（増減）
├── ノードのアップグレード（Kubernetes バージョン更新）
└── ノードの修復（障害ノードの自動交換）
セキュリティ:
├── Kubernetes Baseline セキュリティ標準の強制適用
├── 特権コンテナのブロック
├── ホスト名前空間へのアクセス制限
└── Workload Identity の自動有効化
【Autopilot の課金モデル】
❌ ノード（VM）単位の課金 ではなく
✅ Pod が要求する vCPU / メモリ / エフェメラルストレージ の課金
例: Pod が requests: cpu=0.5, memory=1Gi を設定
→ その Pod が動いている時間だけ課金
→ アイドルノードへの課金なし！⚙️ GKE Standard モード
【Standard でユーザーが管理するもの】 ・ノードプールの作成・削除 ・マシンタイプの選択 ・ノードのアップグレード（手動またはスケジュール設定） ・ノード上の DaemonSet の管理 【Standard が必要な場面】 ├── 特権コンテナの実行（一部のセキュリティツールなど） ├── カーネルパラメータ（sysctl）の変更 ├── GPU / TPU ノードプールの設定 ├── カスタムロギング/監視エージェント（DaemonSet） └── Bare Metal/特殊ハードウェアの要件
Autopilot クラスタの作成
# Autopilot クラスタを作成（推奨設定） gcloud container clusters create-auto my-autopilot-cluster \ --region=asia-northeast1 \ --network=my-vpc \ --subnetwork=my-subnet \ --enable-private-nodes \ --master-ipv4-cidr=172.16.0.0/28 # クラスタへの認証情報を取得（kubectl で操作できるようにする） gcloud container clusters get-credentials my-autopilot-cluster \ --region=asia-northeast1
Standard クラスタの作成
# Standard クラスタを作成 gcloud container clusters create my-standard-cluster \ --machine-type=n2-standard-4 \ --num-nodes=3 \ --region=asia-northeast1 \ --node-locations=asia-northeast1-a,asia-northeast1-b,asia-northeast1-c \ --enable-autoscaling \ --min-nodes=1 \ --max-nodes=10 \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-private-nodes \ --master-ipv4-cidr=172.16.0.0/28
Workload Identity Federation（最重要）
【❌ 危険なアンチパターン】
サービスアカウントの JSON キーを
Kubernetes Secret に保存して Pod から参照
↓
キーが漏洩するリスク / キーの定期ローテーションの手間
【✅ 正しい方法: Workload Identity】
Kubernetes Service Account (KSA)
↓ bind（紐付け）
Google Cloud IAM Service Account (GSA)
↓
Pod は KSA を使って Google Cloud API に直接アクセス
（JSON キー不要！）# 1. Google Cloud IAM サービスアカウントを作成 gcloud iam service-accounts create my-app-sa \ --display-name="My Application SA" # 2. 必要な IAM ロールを付与（例: Cloud Storage の読み取り） gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # 3. KSA と GSA を紐付け gcloud iam service-accounts add-iam-policy-binding \ my-app-sa@PROJECT_ID.iam.gserviceaccount.com \ --role="roles/iam.workloadIdentityUser" \ --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
# Kubernetes Service Account に GSA を紐付けるアノテーション
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-ksa
namespace: my-app
annotations:
iam.gke.io/gcp-service-account: my-app-sa@PROJECT_ID.iam.gserviceaccount.com
---
# Pod で KSA を使用
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-ksa
containers:
- name: my-container
image: my-imageBinary Authorization（コンテナの完全性保証）
【Binary Authorization の仕組み】
CI パイプライン:
コードビルド → テスト通過 → イメージに署名
GKE デプロイ時:
Binary Authorization が署名を検証
├── 有効な署名あり → デプロイ許可 ✅
└── 署名なし・無効 → デプロイ拒否 ❌
【防げる攻撃】
├── 承認されていないイメージの誤デプロイ
├── サプライチェーン攻撃（パッケージへの悪意のあるコード挿入）
└── 本番環境への未テストイメージのデプロイセキュリティポスチャダッシュボード
GKE Console → セキュリティポスチャ 自動スキャン項目: ├── Pod の設定上の懸念事項 │ 例: 「root として実行している」「特権コンテナ」 ├── コンテナイメージの脆弱性（CVE） │ 例: 「コンテナの libssl に高リスクのCVEあり」 └── 推奨される修正アクション（自動提示）
# HPA の設定例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60 # CPU 60% を目標に Pod 数を調整【ルートベース vs VPC ネイティブ クラスター】
ルートベース クラスター（旧）:
Pod の IP ルーティングを VPC の静的ルートに依存
→ ノード数増加でルート割り当て上限（クォータ）に到達
→ スケーラビリティのボトルネックとなる
→ 一度作成したら VPC ネイティブに移行不可！
VPC ネイティブ クラスター（現在のデフォルト・推奨）:
エイリアスIP（Alias IPs）で Pod に直接 IP を割り当て
→ VPC ルーティングテーブルを消費しない
→ 無限に近いスケーラビリティを実現
VPC ネイティブが有効にする追加機能:
├── コンテナネイティブ負荷分散（NEG: Network Endpoint Group）
│ → LB が Pod に直接ルーティング（VMを経由しない高効率）
└── Google API へのプライベートアクセス（VPC SC との連携）
計画段階での重要な教訓:
→ 新規クラスターは必ず VPC ネイティブを選択
→ ルートベースから VPC ネイティブへの移行は不可能
（クラスターを作り直す必要がある）サーバーレスコンテナ — ゼロスケール・Direct VPC Egress・カナリアデプロイの完全ガイド
Cloud Run はコンテナイメージを渡すだけで動くフルマネージドのサーバーレスプラットフォームです。
【Cloud Run の特徴】 デプロイは 3ステップだけ: 1. コンテナイメージをビルド（Artifact Registry へ push） 2. Cloud Run にデプロイ 3. HTTPS エンドポイントが自動生成されて完了！ スケーリング: リクエストが来たら → 自動でスケールアウト リクエストがなければ → ゼロにスケールダウン（コストゼロ） 料金: リクエスト処理中のみ課金 アイドル時間は無料（最小インスタンス=0の場合）
# 第2世代で Cloud Run をデプロイ（推奨） gcloud run deploy my-service \ --image=gcr.io/PROJECT_ID/my-app:latest \ --region=asia-northeast1 \ --platform=managed \ --execution-environment=gen2 \ --vpc-egress=all-traffic \ --network=my-vpc \ --subnet=my-subnet
Direct VPC Egress（第2世代・推奨）
Cloud Run コンテナ
↓ Direct VPC Egress（高速・低レイテンシ）
VPC ネットワーク
├── Cloud SQL（プライベート IP）
├── Memorystore（Redis）
├── GCE VM（内部 IP）
└── GKE サービス# Direct VPC Egress で VPC 内リソースにアクセス gcloud run deploy my-service \ --image=CONTAINER_IMAGE \ --vpc-egress=private-ranges-only \ --network=my-vpc \ --subnet=my-subnet
旧: Serverless VPC Access コネクタ（第1世代）
# Serverless VPC Access コネクタを作成（旧方式） gcloud compute networks vpc-access connectors create my-connector \ --network=my-vpc \ --region=asia-northeast1 \ --range=10.8.0.0/28 # Cloud Run にコネクタを設定 gcloud run deploy my-service \ --vpc-connector=my-connector
Cloud Run はトラフィックを複数のリビジョン（バージョン）に分割できます。
【カナリアデプロイの例】
v1（安定版） ─────── 90% のトラフィック
v2（新バージョン） ── 10% のトラフィック
↓
問題なければ 100% に切り替え
問題あればすぐ v1 に戻す# v2 に 10% のトラフィックを向ける gcloud run services update-traffic my-service \ --to-revisions=v1=90,v2=10 # 問題なければ v2 に 100% 切り替え gcloud run services update-traffic my-service \ --to-latest
【外部からのアクセス制御】
インターネット公開（認証不要）:
gcloud run deploy my-service --allow-unauthenticated
認証必須（IAM で制御）:
gcloud run deploy my-service --no-allow-unauthenticated
→ アクセスには roles/run.invoker ロールが必要
サービス間認証:
Cloud Run サービス A → Cloud Run サービス B
サービス A のサービスアカウントに
サービス B の roles/run.invoker を付与イベント駆動サーバーレス — HTTP/GCS/Pub/Sub トリガーと Gen2 の完全ガイド
【Cloud Functions の特徴】 サーバー管理不要: コードだけ書けばOK 実行環境・スケーリングはGoogle が管理 イベントドリブン: ├── HTTP リクエスト ├── Cloud Storage へのファイルアップロード ├── Pub/Sub メッセージ ├── Cloud Scheduler（定期実行） └── Firestore の変更 料金: 関数の呼び出し回数 + 実行時間の課金 月 200 万回まで無料
例1: HTTP トリガー（API エンドポイント）
import functions_framework
from flask import jsonify
@functions_framework.http
def hello_world(request):
name = request.args.get('name', 'World')
return jsonify({'message': f'Hello, {name}!'})例2: Cloud Storage トリガー（画像アップロード時に処理）
import functions_framework
from google.cloud import storage, vision
@functions_framework.cloud_event
def process_image(cloud_event):
data = cloud_event.data
bucket_name = data["bucket"]
file_name = data["name"]
# Cloud Vision API で画像分析
client = vision.ImageAnnotatorClient()
image = vision.Image()
image.source.image_uri = f"gs://{bucket_name}/{file_name}"
response = client.label_detection(image=image)
print(f"Labels: {[l.description for l in response.label_annotations]}")例3: Pub/Sub トリガー（予算アラートへの対応）
import base64
import json
import googleapiclient.discovery
def stop_billing(event, context):
"""予算超過アラートを受けてリソースを停止"""
pubsub_data = base64.b64decode(event['data']).decode('utf-8')
data = json.loads(pubsub_data)
if data['costAmount'] >= data['budgetAmount']:
compute = googleapiclient.discovery.build('compute', 'v1')
# VM を停止
compute.instances().stop(
project='PROJECT_ID',
zone='asia-northeast1-a',
instance='my-vm'
).execute()【Cloud Functions を選ぶとき】 ├── 単純なイベント処理（数行〜数十行のコード） ├── 各種 Google Cloud サービスのイベントに反応 ├── 定期バッチ（Cloud Scheduler + Functions） └── プロトタイプ・PoC の素早い実装 【Cloud Run を選ぶとき】 ├── 複数のエンドポイントを持つ REST API ├── 既存のコンテナ化されたアプリ ├── カスタムランタイム（Go・Rust など） ├── 長時間実行が必要（60分以上） └── 複雑なミドルウェアが必要なアプリ
4ストレージクラス・OLM・署名付きURL・データ保護 — 非構造化データ管理の完全ガイド
【Cloud Storage の特徴】 ├── 容量無制限（バケット単位で管理） ├── 高い耐久性（99.999999999% = イレブンナイン） ├── グローバルなアクセス ├── バケット ─ オブジェクト の 2 層構造 └── HTTP/HTTPS でアクセス可能
アクセス頻度
高い ←──────────────────────────────────→ 低い
Standard → Nearline → Coldline → Archive
↑費用/GB ↑費用/GB ↑費用/GB ↑費用/GB
高め 中 低め 最安値
↑取り出し料金
無料 有料(安) 有料(中) 有料(高)最小保存期間より前に削除しても、最小保存期間分の料金が発生します！
【Single Region（単一リージョン）】 例: asia-northeast1（東京） → 最もコストが低い → リージョン障害でデータにアクセス不可 → 同一リージョン内でのデータ転送が最速 【Dual Region（デュアルリージョン）】 例: asia1（東京 + 大阪） → 2リージョン間で自動レプリケーション → 地理的冗長性あり → コストは Multi-Region と同程度 【Multi Region（マルチリージョン）】 例: asia（アジア全体）、us（米国全体）、eu（EU） → 最高の可用性と地理分散 → コストは最も高い → グローバルなコンテンツ配信に最適
# バケットの作成 gcloud storage buckets create gs://my-app-bucket \ --location=asia-northeast1 \ --storage-class=STANDARD \ --uniform-bucket-level-access
オブジェクト作成（Standard）
│
├── 30日後 → Nearline に自動移行
│
├── 90日後 → Coldline に自動移行
│
├── 365日後 → Archive に自動移行
│
└── 730日後 → 自動削除
→ このルールを設定するだけでコスト最適化が自動化！{
"lifecycle": {
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 90}
},
{
"action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
"condition": {"age": 365}
},
{
"action": {"type": "Delete"},
"condition": {"age": 730}
}
]
}
}# OLM ポリシーをバケットに適用 gcloud storage buckets update gs://my-bucket \ --lifecycle-file=lifecycle.json
【バケット名のルール】
├── グローバルに一意（全世界で重複不可）
├── 3〜63文字
├── 小文字・数字・ハイフン・アンダースコアのみ
├── 「goog」で始まる名前は予約済みで使用不可
├── 「google」のスペルミス（googel など）も使用不可
└── バケット名は URL に含まれる！
【バケット名の設計原則】
❌ 悪い例: my-company-production-database-backups-tokyo
→ 会社名・環境・内容が丸わかり
✅ 良い例: bkt-a7f2k9-prod-bak
→ 意味を推測しにくいランダムなサフィックス付き
→ 個人情報・機密情報を一切含まない【アクセス制御の 2 つのモデル】 【1. ACL（Access Control List）】 ← 旧モデル・非推奨 オブジェクトごとに個別のアクセス制御が可能 管理が複雑になりがち 【2. 統一バケットレベルアクセス（Uniform Bucket-Level Access）】 ← 推奨 バケット全体に IAM ポリシーを適用 オブジェクト個別の ACL は無効化 管理がシンプル・一貫性あり
Google アカウントを持たないユーザーに一時的なアクセスを付与する仕組みです。
【ユースケース】
├── 外部パートナーへのデータ共有
├── 顧客へのダウンロードリンク提供
└── 一時的なアップロード用 URL の生成
【署名付き URL の構造】
https://storage.googleapis.com/BUCKET/OBJECT
?X-Goog-Algorithm=GOOG4-RSA-SHA256
&X-Goog-Credential=...
&X-Goog-Date=20240101T000000Z
&X-Goog-Expires=3600 ← 有効期間（秒）
&X-Goog-Signature=...# 1時間有効な署名付き URL を生成 gcloud storage sign-url gs://my-bucket/my-file.pdf \ --duration=1h \ --service-account=my-sa@PROJECT.iam.gserviceaccount.com # 最大有効期間は 7日間（604800秒）
論理削除（Soft Delete）
デフォルト設定: 有効（7日間保持）
オブジェクト削除 → 7日間はリカバリ可能
→ 8日目以降は完全削除（コストも発生）
保持期間のカスタマイズ（0〜90日）:
gcloud storage buckets update gs://my-bucket \
--soft-delete-duration=30dバケットを削除後 10 分以内に同名バケットを作成しようとすると 404 エラーが発生します。
バケットロック（Bucket Lock）と保持ポリシー
【用途】コンプライアンス・法規制対応 保持ポリシー: バケット内のすべてのオブジェクトを 指定期間（例: 7年間）削除・上書き不可にする バケットロック: 保持ポリシー自体を変更・削除不可にする （取り消しができない操作！） gcloud storage buckets update gs://my-compliance-bucket \ --retention-period=7y # 7年間保持 gcloud storage buckets lock gs://my-compliance-bucket # ロック（不可逆！）
オブジェクトバージョニング
# バージョニングを有効化 gcloud storage buckets update gs://my-bucket --versioning # 非最新バージョンを確認 gcloud storage objects list gs://my-bucket --all-versions # 特定バージョンを復元 gsutil cp gs://my-bucket/file.txt#1234567890 gs://my-bucket/file.txt
Persistent Disk・リージョナルPD・Filestore — VM ストレージの完全ガイド
VM に接続するブロックストレージです。
Persistent Disk の特徴: ├── VM とは独立して存在（VM を削除してもディスクは残る設定可能） ├── 複数のVMから読み取り専用で共有可能（マルチリーダー） ├── 1つのVMへの読み書きと1つのVMへの共有（マルチライター）※Extreme除く └── ゾーンPD と リージョンPD の2種類 【ゾーン PD】 1つのゾーン内に存在 → そのゾーン障害でアクセス不可 【リージョン PD（高可用性）】 2つのゾーンに同期レプリケーション → 1ゾーン障害でも他ゾーンでアクセス継続 → 約2倍のコスト
# リージョン Persistent Disk の作成（高可用性） gcloud compute disks create my-regional-disk \ --type=pd-balanced \ --size=100GB \ --region=asia-northeast1 \ --replica-zones=asia-northeast1-a,asia-northeast1-b
複数の VM から同時にアクセスできるNFSファイルシステムです。
【Filestore の用途】 ├── 複数の VM でファイルを共有（共有ホームディレクトリなど） ├── レガシーアプリの NFS 依存を維持したまま移行 └── CMS（WordPress など）の共有ストレージ 【Filestore 階層】 Basic HDD → Basic SSD → High Scale SSD → Enterprise （コスト低←──────────────────────────→パフォーマンス高）
Cloud SQL / Spanner / AlloyDB / Firestore / Bigtable / Memorystore / BigQuery — 最適なDBを選ぶフレームワーク
どんなデータを扱う？ │ ├── 構造化データ（スキーマが決まっている） │ │ │ └── SQL が必要？ │ ├── YES → どんな規模・要件？ │ │ ├── 標準的なWebアプリ → Cloud SQL │ │ ├── グローバル分散・99.999% → Cloud Spanner │ │ └── PostgreSQL 高性能（4倍）→ AlloyDB │ │ │ └── NO（NoSQL）→ どんな特性が必要？ │ ├── リアルタイム同期・モバイル → Firestore │ ├── 超大規模・低レイテンシ・時系列 → Cloud Bigtable │ └── マイクロ秒・キャッシュ → Memorystore │ ├── 分析・DWH → BigQuery │ └── Oracle を移行したい → Bare Metal Solution
MySQL、PostgreSQL、SQL Server のフルマネージドサービスです。
【Cloud SQL が管理してくれるもの】 ├── OS パッチ適用 ├── データベースマイナーバージョンアップ ├── 自動バックアップ（日次） ├── フェイルオーバーレプリカ（HA構成） └── SSL/TLS 暗号化
アーキテクチャパターン
【シングルインスタンス（開発環境）】
プライマリ DB ←── 読み書き
コスト: 安い、可用性: 低い
【高可用性（HA）構成（本番環境）】
プライマリ DB（ゾーンA）
↓ 同期レプリケーション
スタンバイ DB（ゾーンB）
プライマリ障害 → 自動フェイルオーバー（数十秒）
コスト: 2倍程度
【リードレプリカ（読み取りスケール）】
プライマリ DB（書き込み）
↓ 非同期レプリケーション
リードレプリカ 1（読み取り）
リードレプリカ 2（読み取り）
読み取り負荷を複数レプリカに分散Cloud SQL への安全な接続
【3つの接続方法】 方法1: Cloud SQL Auth Proxy（推奨） アプリ → Cloud SQL Auth Proxy（ローカル）→ Cloud SQL → SSL/TLS を自動処理、IAM で認証 → DB のパスワードが不要 使用例: # Auth Proxy を起動 ./cloud-sql-proxy PROJECT:REGION:INSTANCE_NAME 方法2: プライベート IP（VPC 内から） VPC 内のアプリ → プライベート IP → Cloud SQL → インターネットを経由しない最も安全な方法 → Private Service Connect を使用 方法3: 公開 IP（外部から） 外部アプリ → Cloud SQL（公開 IP） → 許可された IP アドレスのみアクセス可能（許可リスト） → 原則避けるべき
# Cloud SQL インスタンス作成（HA 構成） gcloud sql instances create my-postgres \ --database-version=POSTGRES_15 \ --tier=db-n1-standard-4 \ --region=asia-northeast1 \ --availability-type=REGIONAL \ --backup-start-time=03:00 \ --no-assign-ip \ --network=my-vpc
Cloud Spanner = リレーショナル × グローバル分散 × 水平スケール
【何が特別か】
通常の DB: スケールアップ（大きなマシンに変える）で対応
Cloud Spanner: ノードを追加するだけで水平スケール
SQL/ACIDトランザクションを維持したまま！
【SLA: 99.999%（ファイブナイン）】
年間ダウンタイム: 約 5.26 分
他の DB は通常 99.9%（年間 8.76 時間）
【ユースケース】
├── グローバルな金融システム（証券、決済）
├── 大規模インベントリ管理
└── グローバルゲームのリーダーボード・状態管理AlloyDB = PostgreSQL 完全互換 + Google AI 最適化
【性能】
標準 PostgreSQL の 4倍のトランザクション性能
分析クエリは 100倍速い（列指向ストレージを内部使用）
【Cloud SQL PostgreSQL vs AlloyDB の使い分け】
Cloud SQL PostgreSQL:
→ 標準的な Web アプリ・既存 PG アプリの移行
→ 中規模まで
AlloyDB:
→ OLTP と分析（HTAP）を同一 DB で処理したい
→ 高性能が必要・AI/ML との統合が必要
→ pgvector を使ったベクトル検索（AI 機能）【Firestore の特徴】
ドキュメント指向 NoSQL:
データ構造: コレクション → ドキュメント → フィールド
users（コレクション）
└── alice（ドキュメント）
├── name: "Alice"
├── age: 30
└── orders（サブコレクション）
└── order-001
├── item: "laptop"
└── price: 150000
リアルタイム同期:
データが変更されると全クライアントに即時反映
→ モバイルアプリ・チャット・コラボツールに最適
サーバーレス:
キャパシティプランニング不要・自動的にスケール【Cloud Bigtable の特徴】
ワイドカラム型 NoSQL:
数十億行 × 数百万列 のデータを処理
ミリ秒未満のレイテンシを維持
行キー（Row Key）でアクセス最適化:
例: "sensor_001#2024010112000000"（センサーID + タイムスタンプ）
→ 時系列データの範囲スキャンが超高速
HBase 互換:
Hadoop エコシステムとの統合が容易
【ユースケース】
├── IoT センサーデータ（秒間数百万レコード）
├── 広告配信ログ
├── 金融の取引履歴
└── ML フィーチャーストア【Memorystore の特徴】
Redis / Memcached のフルマネージドサービス
→ 自分で Redis を EC2 や GCE に立てる必要なし
マイクロ秒レベルのレスポンス:
通常の DB（ミリ秒）の 1/1000 の速さ
【用途】
├── セッション管理（ユーザーのログイン状態）
├── キャッシュ（頻繁にアクセスされるDBクエリ結果）
├── リーダーボード（ゲームのランキング）
├── レート制限（API の呼び出し回数制限）
└── Pub/Sub パターン（Redis の Pub/Sub 機能）
【Memcached vs Redis の選択】
Memcached: シンプルなキャッシュ・マルチスレッド
Redis: データ永続化・複雑なデータ構造（Set, SortedSet など）
→ ほとんどのケースで Redis を推奨【BigQuery の特徴】 サーバーレス・フルマネージドのデータウェアハウス → インフラ管理不要 → 数秒で数TB のデータを分析 ストレージとコンピューティングの分離: ストレージ: 安価（$0.02/GB/月） クエリ: 処理したデータ量に課金（$5/TB） → 必要な時だけクエリを実行（コスト効率高い） SQL で機械学習（BigQuery ML）: CREATE MODEL でモデルをトレーニング → データサイエンティストが Python 不要で ML を実施 【ACE 試験での BigQuery の位置づけ】 ├── Cloud Billing データのエクスポート先（監査・分析） ├── Cloud Logging のエクスポート先（長期ログ分析） └── データウェアハウス・BI の基盤
グローバルVPC・カスタムモードサブネット・タグベースFWルール — ネットワーク基盤の設計ガイド
【他のクラウドとの違い】
他社クラウド（一般的）: Google Cloud VPC:
リージョンごとに VPC 1つの VPC がグローバルに存在
asia-northeast1 VPC
us-central1 VPC → グローバル VPC
├── サブネット（東京）
├── サブネット（米国）
└── サブネット（欧州）
→ マルチリージョン展開でもVPCを1つで管理できる！
→ リージョン間の通信はGoogle のプライベートネットワーク（高速・低コスト）【自動モード VPC】 → サブネットが各リージョンに自動作成（10.128.0.0/9） → お試し・開発用途に便利 → 本番環境には不推奨（IP 範囲が固定） 【カスタムモード VPC（本番環境推奨）】 → 自分でサブネットとIPレンジを定義 → 将来の VPC Peering で重複しないよう計画的に設計
サブネットの IP 範囲設計例
【企業全体の IP 設計例】 10.0.0.0/8 を会社全体に割り当て ├── 10.1.0.0/16 → 東京リージョン（asia-northeast1） │ ├── 10.1.1.0/24 → 東京 Web 層（asia-northeast1-a） │ ├── 10.1.2.0/24 → 東京 App 層（asia-northeast1-b） │ └── 10.1.3.0/24 → 東京 DB 層（asia-northeast1-c） │ ├── 10.2.0.0/16 → 大阪リージョン（asia-northeast2） │ └── ... │ └── 10.3.0.0/16 → オンプレミス（VPN/Interconnect で接続）
ファイアウォールルールは VPC レベルで管理（ハードウェアでなくソフトウェア） 方向: ├── INGRESS（入ってくるトラフィック） └── EGRESS（出ていくトラフィック） 対象の指定方法: ├── ネットワークタグ（例: tag=web-server）← 推奨 ├── サービスアカウント └── IP レンジ（例: 0.0.0.0/0 = すべて） 優先度（Priority）: 数値が小さいほど優先（0〜65534） デフォルト拒否ルール: Priority=65535（最低優先度）
ベストプラクティス: タグベースのファイアウォール
# Web サーバータグを持つ VM に HTTP/HTTPS を許可 gcloud compute firewall-rules create allow-web \ --network=my-vpc \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80,tcp:443 \ --target-tags=web-server \ --source-ranges=0.0.0.0/0 # App サーバーはロードバランサからのみアクセスを許可 gcloud compute firewall-rules create allow-app-from-lb \ --network=my-vpc \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:8080 \ --target-tags=app-server \ --source-tags=load-balancer
ホストプロジェクト・サービスプロジェクト・推移的接続の制約 — マルチプロジェクトネットワーク設計
【Shared VPC がない場合の問題】
各チームが独自の VPC を持つ:
Project A（フロントエンドチーム）: 10.0.0.0/16
Project B（バックエンドチーム）: 10.1.0.0/16
Project C（DBチーム）: 10.2.0.0/16
問題: 各チームが自分でネットワークを管理 → 設定のばらつき
セキュリティポリシーの一貫性がない
ネットワーク管理の責任が分散
【Shared VPC による解決】
ホストプロジェクト（ネットワーク管理チームが所有）
└── VPC（統一されたサブネット・ファイアウォール）
サービスプロジェクト A（フロントエンドチーム）
└── アプリ → ホストプロジェクトの VPC のサブネットを利用
サービスプロジェクト B（バックエンドチーム）
└── アプリ → ホストプロジェクトの VPC のサブネットを利用
メリット:
✓ ネットワーク設定を一元管理（セキュリティポリシーの統一）
✓ ネットワーク管理とアプリ開発の職務分掌
✓ 各チームのコストは独立したプロジェクトで管理Shared VPC の設定
# ホストプロジェクトを指定 gcloud compute shared-vpc enable HOST_PROJECT_ID # サービスプロジェクトをホストに紐付け gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID \ --host-project=HOST_PROJECT_ID # Network User ロールをサービスプロジェクトのチームに付与 # （サブネットの使用権限のみ、VPC の設定変更は不可） gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member="group:backend-team@example.com" \ --role="roles/compute.networkUser" \ --condition="resource.name == projects/HOST_PROJECT_ID/regions/asia-northeast1/subnetworks/backend-subnet"
VPC A（Project 1） ← Peering → VPC B（Project 2） ・内部 IP でプライベートに通信 ・Google のプライベートネットワークを使用（高速） ・インターネットを経由しない ・トラフィックが GCP を出ない 使用場面: ├── 異なるプロジェクト間の内部通信 └── 異なる組織の VPC 間の接続
⚠️ VPC Peering の重要な制約
【制約 1: 推移的（Transitive）ではない】 VPC A ── Peering ── VPC B ── Peering ── VPC C A と B は通信できる ✅ B と C は通信できる ✅ A と C は通信できない ❌ ← これが最重要！ → A と C を通信させるには、A-C 間の Peering を別途作成する必要あり 【制約 2: IP アドレスの重複不可】 VPC A: 10.0.0.0/16 VPC B: 10.0.0.0/16 ← 重複！Peering 不可！ → Peering する VPC 間は IP 範囲が重複してはいけない → カスタムモード VPC でIP を計画的に設計することが重要
外部IP不要のアウトバウンド接続・ハイブリッドDNS解決 — セキュアなネットワーク出口設計
【なぜ Cloud NAT が必要か？】
セキュリティのベストプラクティス:
VM に外部 IP を割り当てない
→ でも VM からインターネット（パッケージDL等）へのアクセスが必要
解決策: Cloud NAT
外部IP なし の VM
↓
Cloud NAT（送信元 IP を変換）
↓
インターネット（apt-get install, etc.）
VM の外部 IP = Cloud NAT の IP（共有）
→ 個々の VM の IP が外部に直接露出しないCloud NAT の設定
# Cloud Router を作成（Cloud NAT の前提条件） gcloud compute routers create my-router \ --network=my-vpc \ --region=asia-northeast1 # Cloud NAT を作成 gcloud compute routers nats create my-nat \ --router=my-router \ --region=asia-northeast1 \ --nat-all-subnet-ip-ranges \ --auto-allocate-nat-external-ips
Cloud NAT のポート枯渇問題
【ポート枯渇とは？】 Cloud NAT は送信元 IP:ポート でセッションを識別 各 VM に割り当てられるポート数には上限がある VM が同時接続数の上限を超えると: → 新しい接続が確立できない → "Connection refused" エラー 【監視コマンド（MQL クエリ）】 fetch nat_gateway | metric 'compute.googleapis.com/nat/port_usage' | align mean_aligner() | every 1m 【対策】 ├── ポート数を手動増加（--min-ports-per-vm） ├── 静的 NAT IP を追加 └── コネクションプールの最適化（アプリ側）
ハイブリッド環境でのDNS解決
【シナリオ: オンプレミス + Google Cloud のハイブリッド構成】 問題: 2つの環境でのDNS名前解決を統合したい Cloud DNS のプライベートゾーン: gcp.internal → GCPリソースの名前解決 オンプレミスの DNS サーバー: corp.internal → オンプレミスリソースの名前解決 【解決策】 ① オンプレ → GCP のプライベートゾーンを解決: Cloud DNS にインバウンドフォワーダーを設定 オンプレの DNS が 169.254.169.254 に転送 ② GCP → オンプレのDNSを解決: Cloud DNS に転送ゾーン（Forwarding Zone）を設定 gcp で corp.internal クエリ → オンプレ DNS サーバーに転送
# 転送ゾーンを作成（GCP → オンプレの DNS を解決） gcloud dns managed-zones create on-prem-forwarding \ --dns-name=corp.internal. \ --description="Forward to on-premises DNS" \ --visibility=private \ --networks=my-vpc \ --forwarding-targets=10.0.0.53 # インバウンドポリシーを作成（オンプレ → GCP を解決） gcloud dns policies create inbound-policy \ --description="Inbound DNS forwarding" \ --networks=my-vpc \ --enable-inbound-forwarding
ALB/NLB・URL マップ・Cloud Armor・コンプライアンス要件 — トラフィック分散の完全ガイド
どんなトラフィック？
├── HTTP/HTTPS
│ └── Application Load Balancer (L7)
│ ├── グローバル配信が必要 → Global External ALB (Premium Tier)
│ ├── リージョン内に限定 → Regional External ALB
│ └── VPC 内部のみ → Internal ALB
│
└── TCP/UDP/その他
└── Network Load Balancer (L4)
├── SSL オフロード必要 → Proxy Network LB
└── 送信元 IP 保持・UDP が必要 → Passthrough Network LB
└── 内部通信のみ → Internal Passthrough NLBGlobal External ALB（グローバル外部 ALB）
特徴: ├── Anycast IP（1つのIPで全世界にサービス提供） ├── ユーザーに最も近いエッジ PoP で SSL 終端 ├── URL ベースのルーティング（/api/* → API バックエンド） ├── ヘッダーベースのルーティング ├── Cloud Armor（DDoS 防御）と統合 └── Premium Tier ネットワーク使用（Google のバックボーン） 主なユースケース: ├── グローバルな Web サービス ├── 複数リージョンにバックエンドを分散 └── セキュリティ要件の高い Web アプリ
URL マップによるルーティング
URL マップの例: / （デフォルト）→ フロントエンド MIG /api/* → API Cloud Run サービス /static/* → Cloud Storage バケット（静的コンテンツ） /admin/* → 管理者用バックエンド（特定 IP のみ Cloud Armor で制限）
# URL マップを作成 gcloud compute url-maps create my-url-map \ --default-service=frontend-backend-service # パスマッチャーを追加 gcloud compute url-maps add-path-matcher my-url-map \ --path-matcher-name=api-matcher \ --default-service=frontend-backend-service \ --backend-service-path-rules=/api/*=api-backend-service,/static/*=storage-backend
Proxy Network LB（プロキシ型）:
クライアント ─── 接続終端 ─── Cloud LB ─── 新しい接続 ─── バックエンド
・LB でTCP接続を終端
・SSL オフロードが可能
・クライアントの送信元IPが失われる（X-Forwarded-For ヘッダーで補完）
Passthrough Network LB（パススルー型）:
クライアント ──────────────── バックエンド（直接）
↑ パケットをそのまま転送
・クライアントの送信元IPをそのままバックエンドに転送
・TCP/UDP/ESP/GRE/ICMP に対応
・バックエンドが直接クライアントに応答（DSR: Direct Server Return）
使い分け:
送信元IP が必要（ログ記録・地域制限など）→ Passthrough
SSL オフロードが必要 → Proxyデータ主権・コンプライアンス要件がある場合
【コンプライアンス要件がある場合】 「すべてのトラフィックを日本国内に留める必要がある」 「SSL/TLS 終端は必ず東京リージョンで行わなければならない」 → グローバルスコープの ALB は使えない！ グローバル ALB はエッジで SSL 終端するため 海外の PoP でも処理される可能性がある → 必ず「リージョナル」ロードバランサを選択 Regional External ALB または Regional Internal ALB
【Cloud Armor の主な機能】 DDoS 防御: → アプリケーション層（L7）の攻撃を自動軽減 WAF（Web Application Firewall）: → SQLインジェクション・XSS などを検出・ブロック カスタムルール: → 特定 IP からのブロック → 地理情報ベースのアクセス制御 レート制限: → 1つの IP から大量リクエストをブロック
# Cloud Armor ポリシーを作成して ALB に適用 gcloud compute security-policies create my-security-policy \ --description="WAF and DDoS protection" # 日本以外からのアクセスをブロック gcloud compute security-policies rules create 1000 \ --security-policy=my-security-policy \ --expression="origin.region_code != 'JP'" \ --action=deny-403 # ALB バックエンドサービスにポリシーを適用 gcloud compute backend-services update my-backend-service \ --security-policy=my-security-policy \ --global
State管理・リモートバックエンド・CI/CD統合・GitOps — IaC の完全ガイド
【手動でコンソール操作する問題】 ├── 再現性がない（「あの設定どうやったっけ？」） ├── 環境間の差異（dev と prod の設定が微妙に違う） ├── 監査ができない（「誰がいつ何を変えたか？」） └── ヒューマンエラー（クリック間違い） 【Terraform（IaC）による解決】 ├── コードとして定義 → 完全に再現可能 ├── Git で管理 → 変更履歴が完全に記録される ├── PR レビュー → 本番適用前に人間がチェック └── plan → apply の 2 ステップで安全に適用
# main.tf - リソースの定義
resource "google_compute_instance" "web_server" {
name = "web-server-prod"
machine_type = "n2-standard-4"
zone = "asia-northeast1-a"
boot_disk {
initialize_params {
image = "debian-cloud/debian-11"
size = 50
}
}
network_interface {
network = "my-vpc"
subnetwork = "web-subnet"
# access_config なし = 外部IP なし（推奨）
}
metadata = {
enable-oslogin = "TRUE"
}
tags = ["web-server"]
}
# variables.tf - 変数の定義
variable "project_id" {
description = "Google Cloud プロジェクト ID"
type = string
}
variable "region" {
description = "デプロイするリージョン"
type = string
default = "asia-northeast1"
}
# outputs.tf - 出力値の定義
output "instance_internal_ip" {
description = "VM の内部 IP"
value = google_compute_instance.web_server.network_interface[0].network_ip
}Terraform は「terraform.tfstate」というファイルで「コードと実際のGCPリソースの対応関係」を管理します。
terraform.tfstate の中身（例）:
{
"resources": [
{
"type": "google_compute_instance",
"name": "web_server",
"instances": [
{
"attributes": {
"id": "projects/my-proj/zones/asia-northeast1-a/instances/web-server-prod",
"machine_type": "n2-standard-4",
...
}
}
]
}
]
}
もしこのファイルが壊れると:
Terraform がリソースを「存在しない」と思い込み
→ 既存リソースを削除して再作成しようとする！
→ 本番環境への大規模障害！terraform.tfstate を手動で編集してはいけません！
ローカル State の問題点
【ローカル State の問題】 開発者 A が terraform apply → ローカルの tfstate が更新 開発者 B が同時に terraform apply（古い tfstate を持っている） → State の競合！ → リソースが重複作成 or 意図しない削除！ → チーム開発でのローカル State は使用禁止
リモートバックエンドの設定（Cloud Storage）
# backend.tf
terraform {
backend "gcs" {
bucket = "my-terraform-state-bucket"
prefix = "terraform/state"
}
}# State 用の Cloud Storage バケットを作成 gcloud storage buckets create gs://my-terraform-state-bucket \ --location=asia-northeast1 \ --uniform-bucket-level-access # バージョニングを有効化（State の変更履歴を保存） gcloud storage buckets update gs://my-terraform-state-bucket \ --versioning # State ロックは GCS バックエンドで自動的に有効化される # → 並行 apply を自動防止！
【標準的なデプロイフロー】 Step 1: コードを変更してコミット ↓ Step 2: terraform plan でプレビュー $ terraform plan -out=tfplan 出力例: Plan: 1 to add, 2 to change, 0 to destroy. + google_compute_instance.new_vm ← 追加される ~ google_compute_instance.web_server ← 変更される → 変更内容を確認してレビュー Step 3: プランファイルを使って適用 $ terraform apply tfplan → plan 時と同じ内容のみ適用（サプライズなし！） 【重要】プランファイルの注意点: プランファイルは実行環境（パスなど）に依存するため 環境間を移動して使うことはできない
従来の方法（Terraform < 1.5）
# Console で手動作成した VM を Terraform 管理下に置く terraform import google_compute_instance.my_vm \ projects/PROJECT/zones/asia-northeast1-a/instances/my-vm
モダンな方法（Terraform >= 1.5 推奨）
# main.tf に import ブロックを追加
import {
to = google_compute_instance.my_vm
id = "projects/PROJECT/zones/asia-northeast1-a/instances/my-vm"
}
resource "google_compute_instance" "my_vm" {
name = "my-vm"
# ... リソースの設定
}# import を含む plan を実行 terraform plan # import ブロックを検出して取り込み計画を表示 # 問題なければ apply terraform apply
リポジトリ構造:
my-infra/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── terraform.tfvars
│ │
│ └── prod/
│ ├── main.tf
│ ├── variables.tf
│ └── terraform.tfvars
│
└── modules/
├── vpc/
├── gke/
└── cloud-sql/
【ブランチ戦略】
feature/xxx → dev ブランチへの PR
↓ マージ
dev ブランチ → dev 環境に自動 apply
↓ 承認
main ブランチへの PR → レビュー
↓ マージ
main ブランチ → prod 環境に自動 applyCloud Build による CI/CD
# cloudbuild.yaml
steps:
# Terraform の初期化
- name: 'hashicorp/terraform:1.5'
entrypoint: 'terraform'
args: ['init', '-backend-config=bucket=my-state-bucket']
dir: 'environments/${_ENV}'
# プランの実行
- name: 'hashicorp/terraform:1.5'
entrypoint: 'terraform'
args: ['plan', '-out=tfplan']
dir: 'environments/${_ENV}'
# 適用（main ブランチのみ）
- name: 'hashicorp/terraform:1.5'
entrypoint: 'terraform'
args: ['apply', '-auto-approve', 'tfplan']
dir: 'environments/${_ENV}'
substitutions:
_ENV: 'dev'
# Cloud Build のサービスアカウントで実行（JSON キー不要！）
serviceAccount: 'projects/PROJECT/serviceAccounts/terraform-sa@PROJECT.iam.gserviceaccount.com'【AlloyDB の革新的アーキテクチャ】 従来の PostgreSQL: プライマリ DB が WAL（Write-Ahead Logging）を処理しながら ページをディスクに書き込む → I/O 負荷が高い 「Torn Pages（不完全なページ書き込み）」問題のリスクあり AlloyDB のコンピュート/ストレージ分離: WAL レコードのみをインテリジェントな分散ストレージ層 （Log Processing Service: LPS）に送信 LPS が担当: ├── WAL の解析・適用 ├── ページの更新（コンピュート層に代わって） └── ネットワーク効率の最大化 → プライマリ DB は I/O の重い作業から解放 → Torn Pages 問題を根本から解決 → リードレプリカを極めて低遅延でスケールアウト可能
【Hyperdisk（次世代ブロックストレージ）との使い分け】 Persistent Disk（従来）: 容量・スループット・IOPS が連動して決まる Hyperdisk（新世代）: 容量 と スループット/IOPS を完全に独立してプロビジョニング → データ分析: 大容量・高スループット を低コストで実現 → 高I/O DB: 大容量 は不要だが高IOPSが必要、という場合に最適 → 動的な変更が可能（再起動不要） 用途別推奨: ├── 一般的な VM ワークロード → Balanced Persistent Disk ├── 高I/O データベース → Hyperdisk Extreme ├── データ分析・高スループット → Hyperdisk Throughput └── キャッシュ・一時データ → Local SSD（VM停止でデータ消滅）
頻出パターン・重要用語チェックリスト・推奨リソース — ACE Domain 2 完全攻略ガイド
パターン①: コンピューティングサービスの選択
【問題文の例】 「画像処理のバッチジョブを実行したい。 コストを最小化しつつ、停止されても問題ない。 どのサービスを使うべきか？」 正解: Spot VM + MIG 理由: ・バッチジョブ → 停止されても問題ない ・コスト最小化 → Spot VM（最大91%割引） ・停止後の自動再作成 → MIG と組み合わせ 【問題文の例】 「HTTP API を提供したい。 アイドル時間はコストゼロにしたい。 どのサービスを使うべきか？」 正解: Cloud Run 理由: ・HTTP API → Cloud Run ・アイドル時コストゼロ → ゼロスケール可能
パターン②: データベースの選択
【問題文の例】 「グローバルに展開する金融システムで 強い整合性が必要。99.999% の可用性が必要。 どのDBを使うべきか？」 正解: Cloud Spanner 理由: ・グローバル分散 → Spanner ・強整合性 → Spanner（ACID） ・99.999% SLA → Spanner のみが提供 【問題文の例】 「IoT デバイスから毎秒100万件のデータが来る。 低レイテンシでの書き込みが必要。 どのDBを使うべきか？」 正解: Cloud Bigtable 理由: ・超大規模・高スループット → Bigtable ・時系列データ → Bigtable のユースケース
パターン③: ネットワーク設計
【問題文の例】 「複数のチームが同じ VPC ネットワークを使いたい。 ネットワーク管理は1チームが担当し、 各チームはアプリのみ管理したい。」 正解: Shared VPC 理由: ・ネットワーク管理の集中化 → ホストプロジェクト ・各チームがアプリを管理 → サービスプロジェクト 【問題文の例】 「VPC A が VPC B と Peering。 VPC B が VPC C と Peering。 A から C に直接通信できるか？」 正解: できない（Peering は推移的でない）
コンピューティング
ストレージ・データベース
ネットワーク
Terraform
terraform plan -out=tfplan → terraform apply tfplan の順番import ブロックで既存リソースを取り込みDomain 2 は ACE 試験の中で最大配点（≈21%）です。以下の点を徹底的に習得してください。
このドメインの学習にあたって参考にした公式ドキュメントおよび技術リソース