セクション 5：ソリューションのデプロイと実装

📘 ① CI/CD パイプライン全体像

GCP の CI/CD は マネージドサービス 3 つの組合せが定番。役割を混同しないことが試験対策の最初の壁。

Cloud Build（CI 担当）

YAML（cloudbuild.yaml）で ビルドステップ を定義する、フルマネージドの CI サービス。

• ステップごとにコンテナを動かす（任意のツールを実行可能）
• ソースは Cloud Source Repositories / GitHub / GitLab / Bitbucket
• Cloud Build トリガーで Push / PR / タグで自動起動
• Private Pool でプライベートネットワーク内ビルド
• Secret Manager 連携、Workload Identity Federation 認証

# cloudbuild.yaml の例
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'us-docker.pkg.dev/$PROJECT_ID/repo/app:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'us-docker.pkg.dev/$PROJECT_ID/repo/app:$SHORT_SHA']
images:
  - 'us-docker.pkg.dev/$PROJECT_ID/repo/app:$SHORT_SHA'

Artifact Registry（成果物リポジトリ）

コンテナイメージ / OS パッケージ / 言語パッケージ（Maven / npm / Python / Go）を保管する 次世代リポジトリ。

Cloud Deploy（CD 担当）

GitOps スタイルの 進行制御マネージドサービス。delivery-pipeline.yaml で dev → staging → prod の進行を宣言。

• Promotion（環境間昇進）と Rollback（即時切戻し）
• Cloud Run / GKE / Anthos / Run for Anthos に対応
• Canary / Standard / Custom デプロイ戦略
• Verification ステップでヘルスチェック組込み
• Approval で本番手前の承認ゲート
• 監査履歴を自動保存

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

Binary Authorization の流れ

📘 ② デプロイ戦略

4 つの主要戦略を 用途とリスクで使い分け。試験頻出は「即時切戻し → Blue-Green」「段階リリース → Canary」。

プラットフォーム別の Blue-Green 実装

プラットフォーム別の Canary 実装

Feature Flag — 「コード変更なしの機能切替」

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

📘 ③ Apigee と API 管理

API を多数公開すると、認証 / レート制限 / バージョニング / 課金 / 監視 を一元管理しないと運用が破綻します。これを担うのが API Management。

Apigee のエディション

Apigee の主要コンセプト

代表的なポリシー

Apigee の典型ユースケース

📘 ④ テストと Cloud Emulators

Cloud Emulators — 課金回避のローカルテスト

Bigtable / Spanner / Pub/Sub / Firestore はローカル実行できるエミュレータを提供。

gcloud emulators bigtable start    --host-port=localhost:8086
gcloud emulators spanner start     --host-port=localhost:9010
gcloud emulators pubsub start      --host-port=localhost:8085
gcloud emulators firestore start   --host-port=localhost:8080

📘 ⑤ データ・システム移行ツール

「ソースとターゲットの組合せ」でツールが決まる。試験頻出。

Database Migration Service（DMS）の流れ

Datastream（CDC ストリーミング）

• 用途: 既存 DB の変更を リアルタイム に BigQuery / Cloud Storage に流す
• ソース: Oracle, MySQL, PostgreSQL, SQL Server, AlloyDB
• 用途例: 分析パイプライン、データレイク構築、移行中の同期維持

Migration Center（移行統合プラットフォーム）

📘 ⑥ Infrastructure as Code（IaC）

「インフラをコードとして管理」する考え方。GCP では Terraform が標準、K8s ネイティブなら Config Connector。

GCP の IaC 選択肢

Terraform の基本

# main.tf
provider "google" {
  project = "my-project"
  region  = "asia-northeast1"
}

resource "google_storage_bucket" "logs" {
  name     = "my-project-logs"
  location = "ASIA-NORTHEAST1"
  uniform_bucket_level_access = true
}

resource "google_cloud_run_v2_service" "app" {
  name     = "my-app"
  location = "asia-northeast1"
  template {
    containers {
      image = "us-docker.pkg.dev/my-project/repo/app:v1"
    }
  }
}

terraform init   → プロバイダ・モジュール初期化
terraform plan   → 差分プレビュー
terraform apply  → 実行
terraform destroy → 破棄

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

📘 ① Cloud Shell / Cloud Code / Cloud Workstations

Cloud Shell — ブラウザの即席開発環境

ブラウザから即起動できる マネージド開発環境。gcloud / gsutil / bq / kubectl / terraform などがプリインストール。

Cloud Code — ローカル IDE 拡張

ローカル IDE（VS Code / IntelliJ）の拡張機能。

• GKE / Cloud Run 用テンプレートとデプロイ
• Skaffold / Kustomize / Helm 統合
• Cloud APIs スニペット
• Cloud Run 用ローカル実行
• リモートデバッグ
• Gemini Code Assist 統合

Cloud Workstations — マネージド開発環境

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

📘 ② gcloud / gsutil / bq の役割

よく使う代表コマンド

# gcloud
gcloud auth login                              # 認証
gcloud config set project PROJECT_ID           # プロジェクト切替
gcloud compute instances list                  # VM 一覧
gcloud run deploy my-app --image=IMAGE         # Cloud Run デプロイ
gcloud iam service-accounts list               # SA 一覧

# gsutil / gcloud storage
gsutil cp file.txt gs://bucket/                # アップロード（旧）
gcloud storage cp file.txt gs://bucket/        # 新コマンド（推奨）
gcloud storage ls gs://bucket/

# bq
bq query --use_legacy_sql=false 'SELECT 1'
bq mk --dataset mydataset
bq load --source_format=CSV ds.table file.csv

# kubectl (GKE)
gcloud container clusters get-credentials CLUSTER --region=REGION
kubectl get pods
kubectl apply -f manifest.yaml

# Cloud Deploy
gcloud deploy releases create rel-$(date +%s) \
  --delivery-pipeline=app-pipeline \
  --region=asia-northeast1

# Cloud Build
gcloud builds submit --config=cloudbuild.yaml .

📘 ③ Google API クライアントライブラリ

GCP の操作は REST API が本体。クライアントライブラリ を使うとリトライ・認証・ページング等を自動化できる。

認証の基本（重要）

# Python の例
from google.cloud import storage
client = storage.Client()  # ADC で自動認証
bucket = client.bucket("my-bucket")

ベストプラクティス

1. ADC を使う（環境別に自動切替）
2. 指数バックオフ でリトライ（クライアントライブラリは内蔵）
3. Idempotency を意識（重複呼出に対する冪等性）
4. Quotas を意識（429 エラー → バックオフ）
5. 同時並列度 を制限（多数の API を叩きすぎない）
6. Service Account のキー直書きは避ける

📘 ④ Gemini Code Assist と Gemini Cloud Assist

Gemini Cloud Assist の対応場面