Section 5: 実装管理 — 🔧 応用編

対象: 実務 3-5 年 / GCP 経験あり / デプロイ戦略・Apigee 詳細・Terraform 設計・移行ツールの選定 を深掘りしたい人。 目標: 試験で問われる「正しいツール選定」と「実装の意思決定」を高精度で出せるようになる。

1. Cloud Build を実務で使いこなす

Cloud Build の選定軸

マルチステージビルドの実践

steps:
  # 1. テスト
  - name: 'gcr.io/cloud-builders/go'
    args: ['test', './...']
    id: 'test'

  # 2. コンテナビルド（test 完了待ち）
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', '${_IMAGE}:${SHORT_SHA}', '.']
    waitFor: ['test']
    id: 'build'

  # 3. 脆弱性スキャン（並列）
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['artifacts', 'docker', 'images', 'scan', '${_IMAGE}:${SHORT_SHA}']
    waitFor: ['build']

  # 4. Cloud Deploy へ受渡し
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    args: ['gcloud', 'deploy', 'releases', 'create', 'rel-${SHORT_SHA}',
           '--delivery-pipeline=app-pipeline',
           '--region=asia-northeast1']

substitutions:
  _IMAGE: 'asia-docker.pkg.dev/PROJECT/repo/app'

options:
  logging: CLOUD_LOGGING_ONLY
  machineType: 'E2_HIGHCPU_8'

Cloud Build のセキュリティ強化

• カスタムサービスアカウント を使う（デフォルト SA は強権限）
• Binary Authorization で署名付きイメージのみデプロイ
• Private Pool でオンプレ依存ビルド
• Workload Identity Federation で外部 CI から鍵なし認証
• Provenance（来歴） を SLSA 準拠で取得

2. Cloud Deploy の進行管理

主要オブジェクト

Delivery Pipeline ──┬── Target: dev
                    ├── Target: staging
                    └── Target: prod

Release ─── 各ターゲットへの Rollout を順次実行

delivery-pipeline.yaml の例

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: app-pipeline
serialPipeline:
  stages:
    - targetId: dev
      profiles: [dev]
    - targetId: staging
      profiles: [staging]
      strategy:
        canary:
          runtimeConfig:
            cloudRun:
              automaticTrafficControl: true
          canaryDeployment:
            percentages: [10, 50]
            verify: true
    - targetId: prod
      profiles: [prod]
      strategy:
        canary:
          canaryDeployment:
            percentages: [5, 25, 50]
            verify: true

Cloud Deploy で使えるデプロイ戦略

Promotion と Rollback

• Promotion: gcloud deploy releases promote --release=REL --to-target=prod
• Rollback: gcloud deploy rollbacks create --release=REL で前バージョンへ即時切戻し
• Approval: 本番手前に承認ステップを挿入可能

試験頻出: 「コンプライアンス上、本番デプロイに承認が必要」→ Cloud Deploy の Approval。

3. Artifact Registry の高度な使い方

Binary Authorization の流れ

1. イメージビルド (Cloud Build)
2. 脆弱性スキャン (Container Analysis)
3. 検証ポリシー通過 → Attestor が署名
4. Cloud Deploy / GKE / Cloud Run が署名検証
5. 検証 OK のみデプロイを許可

「サプライチェーン攻撃対策」「未署名イメージのデプロイを防ぐ」→ Binary Authorization。

4. デプロイ戦略の詳細

Blue-Green の実装パターン

Canary の実装パターン

Feature Flag

コードはデプロイ済みだが、機能を 動的に on/off する仕組み。

試験では「機能切替を即座にコード変更なしで」→ Feature Flag 系を想起。

A/B テストとの違い

5. Apigee 詳細

Apigee のエディション

Apigee の主要コンセプト

代表的なポリシー

Apigee の典型的なユースケース

1. B2B / B2C API のマネタイズ: 利用量に応じた課金
2. 既存レガシー SOAP/REST のラッピング: モダン化
3. マルチクラウド API 統合: GCP / AWS / Azure の API を統一ゲートウェイ経由
4. マイクロサービス公開: 外部公開用の API ゲートウェイ層

Apigee vs API Gateway vs Cloud Endpoints の選定（応用）

6. テストフレームワークと負荷テスト

負荷テストツールの比較

GCP 上で負荷テストする選択肢

モバイル/UI テスト

• Firebase Test Lab: 実機・仮想デバイスでモバイルアプリ自動テスト
• Cloud Build + Selenium/Cypress: Web UI テスト
• Playwright + Cloud Run for Jobs: 並列 E2E

7. Cloud Emulators の運用

各エミュレータの起動と接続

# Pub/Sub
gcloud emulators pubsub start --host-port=localhost:8085
export PUBSUB_EMULATOR_HOST=localhost:8085
export PUBSUB_PROJECT_ID=test-project

# Firestore
gcloud emulators firestore start --host-port=localhost:8080
export FIRESTORE_EMULATOR_HOST=localhost:8080

# Bigtable
gcloud emulators bigtable start --host-port=localhost:8086
export BIGTABLE_EMULATOR_HOST=localhost:8086

# Spanner
gcloud emulators spanner start --host-port=localhost:9010
export SPANNER_EMULATOR_HOST=localhost:9010

Emulator の制約と注意点

CI での使い方

# cloudbuild.yaml の例
steps:
  - name: 'google/cloud-sdk:emulators'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        gcloud emulators firestore start --host-port=localhost:8080 &
        export FIRESTORE_EMULATOR_HOST=localhost:8080
        npm test

試験頻出: 「テスト時の課金回避」「ローカル開発」→ Cloud Emulators。

8. Terraform 実践（応用）

Terraform の構造化

terraform/
├── modules/
│   ├── network/        # VPC モジュール
│   ├── gke/            # GKE モジュール
│   └── monitoring/
├── envs/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
└── shared/
    └── iam.tf

State 管理

terraform {
  backend "gcs" {
    bucket  = "my-tfstate-bucket"
    prefix  = "envs/prod"
  }
}

IAM での Terraform の安全運用

• Service Account に最小権限: roles/owner は避け、必要な API ごとに付与
• CI 内でのみ apply: 個人 PC で apply しない
• terraform plan の差分を必ず PR レビュー
• Sensitive 変数は Secret Manager から取得

Config Connector との使い分け

「GitOps 徹底で K8s ネイティブ管理」→ Config Connector、「汎用・他クラウド併用」→ Terraform。

Terraformer / Import

既存リソースを Terraform 化:

• terraform import で 1 個ずつ
• Terraformer で一括エクスポート（GCP リソース → HCL）

9. データベース移行の設計

Database Migration Service の詳細設計

Datastream の活用シナリオ

1. 既存 OLTP → BigQuery 分析

   Oracle (オンプレ) → Datastream → BigQuery
   

2. マイクロサービス間の DB 同期

   PostgreSQL → Datastream → Cloud Storage / Pub/Sub
   

3. 移行期間中の継続同期

   旧 DB ─ Datastream ─→ 新 Spanner (両方ライブ)
   

移行戦略と DMS/Datastream

10. システム移行と移行プログラム管理

Migration Center

旧 Stratozone を統合。移行アセスメント・計画・実行 の中核。

[Phase 1] Discovery       → mCollector で資産棚卸し
[Phase 2] Assessment      → 適合度評価、コスト試算
[Phase 3] Recommendation  → 6R 戦略の推奨
[Phase 4] Plan            → 移行ウェーブ計画
[Phase 5] Execution       → M4CE / DMS / M2C との連携

Migrate to Containers (M2C)

VM を解析して Dockerfile / K8s マニフェスト を自動生成。GKE / Cloud Run へモダナイゼーション。

対応ソース:

• Linux VM（オンプレ VMware、GCE、AWS、Azure）
• Windows VM（IIS 中心）

Migration Center の他サービスとの連携

11. Cloud Shell Editor と Cloud Code の使い分け

Cloud Shell Editor

Cloud Code（ローカル IDE 拡張）

Cloud Workstations（補足）

ブラウザでアクセスできる マネージド開発環境。Cloud Shell より高性能で、専用ネットワーク内に配置可能。

12. Google API 呼び出しのベストプラクティス

認証戦略

リトライ戦略

1 回目 失敗 → 1 秒待機
2 回目 失敗 → 2 秒待機
3 回目 失敗 → 4 秒待機
...（指数バックオフ + ジッター）

• クライアントライブラリは 指数バックオフ + ジッター を内蔵
• リトライ対象: 5xx、429（Too Many Requests）、一部 408
• リトライ不可: 4xx 系（認証エラー、Bad Request など）

冪等性（Idempotency）

クォータと制限

• クォータ超過: 429 が返る → 指数バックオフ
• API Quotas ページで上限確認
• 必要に応じて クォータ増加申請
• VPC SC 経由 で外部漏えい防止

バッチング・ページング

13. クライアントライブラリと REST API の使い分け

REST API の基本

# アクセストークン取得
TOKEN=$(gcloud auth print-access-token)

# Compute Engine 一覧
curl -H "Authorization: Bearer $TOKEN" \
  https://compute.googleapis.com/compute/v1/projects/PROJECT/aggregated/instances

gRPC との使い分け

• gRPC: 高性能、ストリーミング、Spanner / Bigtable / Pub/Sub などは内部 gRPC
• REST: 互換性重視、ブラウザから直接呼び出し可能

14. Gemini Code Assist と Gemini Cloud Assist の使い分け

試験で問われやすい組合せ

15. 実装管理のトレードオフ例

ケース 1: モノリス vs マイクロサービス CI/CD

要件: 月 100 デプロイ、3 チーム並走

• A: モノリス + Cloud Build 1 パイプライン → 待ちが発生
• B: マイクロサービス + チームごとの Cloud Build トリガー → 並行可能、運用は複雑

→ B を採用（並行性 > 運用シンプル）

ケース 2: Terraform vs Config Connector

要件: GKE 中心、GitOps 徹底、運用チームは K8s に慣れている

• A: Terraform CI で apply
• B: Config Connector + Argo CD

→ B を採用（K8s ネイティブで GitOps）

ケース 3: Apigee vs API Gateway

要件: 社内マイクロサービス公開、認証は IAM、軽量に始めたい

• A: Apigee → オーバースペック
• B: API Gateway + Cloud Run → 軽量、Cloud IAM 連携

→ B を採用

→ ただし外部開発者向けポータルが必要なら Apigee に切替。

16. 章末まとめ

必ず覚える「実装管理の翻訳パターン」

次のステップ

• 直前確認: 03_要点と暗記.md
• 関連セクション: Section 1（設計）、Section 6（運用卓越性）