セクション3：デプロイ用クラウドネイティブアプリの構成

公式試験ガイド 042426版 — Section 3: Configuring cloud-native applications for deployment

3.1 Cloud Run へのデプロイ

Cloud Run の 3形態

Cloud Run リビジョン詳細

リビジョンとは

Cloud Run Service へのデプロイ・設定変更のたびに、イミュータブル（変更不可）なリビジョンが生成される。トラフィックを複数リビジョン間で分割できるため、canary / blue-green / A/B が標準機能で実現可能。

traffic split のシナリオ別コマンド

# Step 1: 新リビジョンを 0% でデプロイ + canary タグ
gcloud run deploy my-api \
  --image=us-central1-docker.pkg.dev/PROJECT/repo/app:v2 \
  --no-traffic --tag=canary --region=us-central1

# Step 2: 10% に振る
gcloud run services update-traffic my-api \
  --to-tags=canary=10 --region=us-central1

# 監視 (Cloud Monitoring) で問題なければ拡大
gcloud run services update-traffic my-api --to-tags=canary=25 --region=us-central1
gcloud run services update-traffic my-api --to-tags=canary=50 --region=us-central1
gcloud run services update-traffic my-api --to-tags=canary=100 --region=us-central1
# canary=100 になると古いリビジョンは 0%、実質「全展開」完了

# 異常検知 → 即座に旧リビジョンに 100% 戻す
gcloud run services update-traffic my-api \
  --to-revisions=my-api-00001-abc=100 \
  --region=us-central1

# または LATEST タグで「直前」に戻す
gcloud run services update-traffic my-api \
  --to-revisions=LATEST=0 \
  --region=us-central1

# 任意の % 配分（複数リビジョン同時）
gcloud run services update-traffic my-api \
  --to-revisions=my-api-00001-abc=50,my-api-00002-def=30,my-api-00003-ghi=20 \
  --region=us-central1

# タグを付けると、固定 URL で特定リビジョンにアクセス可
gcloud run services update-traffic my-api \
  --set-tags=canary=my-api-00003-ghi,prod=my-api-00002-def \
  --region=us-central1

# 結果:
# - https://canary---my-api-xxx.a.run.app  → リビジョン v3
# - https://prod---my-api-xxx.a.run.app    → リビジョン v2
# トラフィック % とは独立した URL なので、A/B テスト用クライアントから明示的にどちらかにアクセス可能

Eventarc / Pub/Sub Push トリガ

Eventarc から Cloud Run を起動

gcloud eventarc triggers create my-trigger \
  --location=us-central1 \
  --destination-run-service=my-service \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-bucket" \
  --service-account=eventarc-trigger-sa@PROJECT.iam.gserviceaccount.com

主要なイベントタイプ

Pub/Sub Push Subscription での起動

# 1. Cloud Run Service（認証必須）をデプロイ
gcloud run deploy my-handler --image=... --no-allow-unauthenticated --region=us-central1

# 2. Pub/Sub 用 SA 作成 + Cloud Run 呼び出し権限
gcloud iam service-accounts create cloud-run-pubsub-invoker
gcloud run services add-iam-policy-binding my-handler \
  --member=serviceAccount:cloud-run-pubsub-invoker@PROJECT.iam.gserviceaccount.com \
  --role=roles/run.invoker --region=us-central1

# 3. Pub/Sub サービスエージェントに Token 発行権限
PROJECT_NUMBER=$(gcloud projects describe PROJECT --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT \
  --member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com \
  --role=roles/iam.serviceAccountTokenCreator

# 4. Push Subscription 作成
SERVICE_URL=$(gcloud run services describe my-handler --region=us-central1 --format='value(status.url)')
gcloud pubsub subscriptions create my-sub \
  --topic=my-topic \
  --push-endpoint=${SERVICE_URL}/push \
  --push-auth-service-account=cloud-run-pubsub-invoker@PROJECT.iam.gserviceaccount.com

Cloud Run Jobs（バッチ処理）

HTTP リクエスト不要、最大 24時間、並列実行可能なバッチ実行環境。Cloud Run Service と同じ基盤だが用途が異なる。

# ジョブ定義
gcloud run jobs deploy my-batch \
  --image=us-central1-docker.pkg.dev/PROJECT/repo/batch:v1 \
  --region=us-central1 \
  --task-count=100 \              # 100 並列タスク
  --parallelism=10 \              # 同時実行は 10
  --max-retries=3 \               # 失敗時のリトライ
  --task-timeout=30m \            # 1タスクの最大時間
  --service-account=batch-sa@PROJECT.iam.gserviceaccount.com

# 実行
gcloud run jobs execute my-batch --region=us-central1 --wait

# 実行履歴
gcloud run jobs executions list --job=my-batch --region=us-central1

タスク並列化（CLOUD_RUN_TASK_INDEX）

# 各タスクが受け取る環境変数
import os

task_index = int(os.environ["CLOUD_RUN_TASK_INDEX"])     # 0, 1, 2, ... task_count-1
task_count = int(os.environ["CLOUD_RUN_TASK_COUNT"])     # 全タスク数
attempt = int(os.environ["CLOUD_RUN_TASK_ATTEMPT"])      # リトライ回数

# 例: 1000件のファイルを 100タスクに分散
files = list_files()
chunk_size = len(files) // task_count
my_files = files[task_index * chunk_size : (task_index + 1) * chunk_size]
for f in my_files:
    process(f)

Cloud Scheduler で定時起動

# 毎日深夜 2時に Cloud Run Job を起動
gcloud scheduler jobs create http my-nightly-batch \
  --schedule='0 2 * * *' \
  --time-zone='Asia/Tokyo' \
  --uri="https://us-central1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/PROJECT/jobs/my-batch:run" \
  --http-method=POST \
  --oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com \
  --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform

Apigee による API 管理

Cloud Run / GKE の前段に置く、エンタープライズ API 管理プラットフォーム。

3.2 GKE へのデプロイ

GKE Autopilot vs Standard 完全比較

選択フローチャート

Deployment / Service / Ingress / HPA の組合せ

# Deployment + Service + Ingress 一式
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels: { app: my-app }
  template:
    metadata:
      labels: { app: my-app }
    spec:
      serviceAccountName: my-ksa     # Workload Identity 用
      containers:
        - name: app
          image: us-central1-docker.pkg.dev/PROJECT/repo/app:v1
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "256Mi" }
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet: { path: /ready, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5
          startupProbe:
            httpGet: { path: /healthz, port: 8080 }
            failureThreshold: 30
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: ClusterIP
  selector: { app: my-app }
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service: { name: my-app, port: { number: 80 } }

ヘルスプローブ 3種 — 役割と挙動

Horizontal Pod Autoscaler 深掘り

HPA のメトリクスタイプ

Pub/Sub backlog で HPA（External Metric）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: External
      external:
        metric:
          name: pubsub.googleapis.com|subscription|num_undelivered_messages
          selector:
            matchLabels:
              resource.labels.subscription_id: my-subscription
        target:
          type: AverageValue
          averageValue: "100"   # 1 Pod につき backlog 100 を目安
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300  # 5分間 idle 確認してから縮小

複数メトリクスの挙動

GKE Workload Identity

GKE Pod から GCP API を呼ぶ標準パターン。Service Account Key の配布を不要にする。

設定手順（必須3ステップ）

# 1. クラスタで Workload Identity を有効化
gcloud container clusters update my-cluster \
  --workload-pool=PROJECT_ID.svc.id.goog --region=us-central1

# 2. GCP SA 作成 + 権限付与
gcloud iam service-accounts create my-gsa
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:my-gsa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

# 3. KSA 作成 + annotation + GSA 借用許可
kubectl create serviceaccount my-ksa
kubectl annotate serviceaccount my-ksa \
  iam.gke.io/gcp-service-account=my-gsa@PROJECT_ID.iam.gserviceaccount.com

gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[default/my-ksa]"

Workload Identity vs Workload Identity Federation

🚨 事故ケース集（postmortem 形式）

セクション3 試験戦略まとめ