Section 5: 実装管理 — 📘 基礎編
対象: 実務 1-2 年・GCP 初学者 / クラウド実装の標準ツールを初めて学ぶ人。 目標: CI/CD、IaC、API 管理、Cloud Shell / gcloud の基本を把握し、それぞれの役割を即答できる。
1. アプリ／インフラのデプロイとは
CI/CD パイプラインの全体像
コード変更 (git push)
↓
Cloud Build (ビルド・テスト・コンテナ化)
↓
Artifact Registry (イメージ保管)
↓
Cloud Deploy (環境ごとに進行: dev → staging → prod)
↓
GKE / Cloud Run / Compute Engine (実行)
↓
Cloud Monitoring / Logging (観測)
CI と CD の違い
| 用語 | 意味 | 代表サービス |
|---|---|---|
| CI（継続的インテグレーション） | コード変更を自動ビルド・テスト | Cloud Build、GitHub Actions、GitLab CI |
| CD（継続的デリバリ） | 検証済みアーティファクトを各環境に配布 | Cloud Deploy、Argo CD、Spinnaker |
| デプロイ | 実行環境に配置 | Cloud Run / GKE / GCE |
CI で「動くこと」を保証し、CD で「安全に届ける」フェーズを分けて考えるのが基本。
2. Cloud Build / Artifact Registry / Cloud Deploy
Cloud Build（CI 担当）
YAML（cloudbuild.yaml）で ビルドステップ を定義する、フルマネージドの CI サービス。
主な特徴:
- ステップごとにコンテナを動かす（任意のツールを実行可能）
- ソースは Cloud Source Repositories / GitHub / GitLab / Bitbucket
- Cloud Build トリガーで Push / PR / タグで自動起動
- Private Pool でプライベートネットワーク内ビルド
# 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）を保管する 次世代リポジトリ。
| 項目 | 内容 |
|---|---|
| 旧 | Container Registry（gcr.io） |
| 新 | Artifact Registry（*-docker.pkg.dev） |
| サポート形式 | Docker / OCI / Maven / npm / Python / Go / Apt / Yum |
| 利点 | リージョナル、IAM 統合、脆弱性スキャン、リモートリポ、仮想リポ |
新規はすべて Artifact Registry を使う。Container Registry は廃止予定。
Cloud Deploy（CD 担当）
GitOps スタイルの 進行制御マネージドサービス。delivery-pipeline.yaml で dev → staging → prod の進行を宣言。
主な機能:
- Promotion（環境間昇進）と Rollback（即時切戻し）
- Cloud Run / GKE / Anthos / Run for Anthos に対応
- Canary / Standard / Custom デプロイ戦略を選択可能
- Verification ステップでヘルスチェックを組込み
- 監査履歴を自動保存
3. デプロイ戦略の基礎
主要なデプロイ戦略
| 戦略 | 内容 | リスク | 適用例 |
|---|---|---|---|
| Rolling Update | 順次置換 | 中 | 一般的な Web アプリ |
| Blue-Green | 旧（Blue）と新（Green）を並走、切替 | 低 | 厳密な切戻しが必要 |
| Canary | 一部トラフィックだけ新版に流す | 低 | ユーザー影響を早期検知 |
| Recreate | 全停止 → 新版起動 | 高 | ステートフル少数 |
[Rolling]
旧旧旧旧旧 → 旧旧旧旧新 → 旧旧旧新新 → 旧旧新新新 → 旧新新新新 → 新新新新新
[Blue-Green]
Blue: 旧旧旧旧旧 (active) Blue: 旧旧旧旧旧 (idle)
Green: ----- (待機) → Green: 新新新新新 (active)
LB を Blue → Green に切替
[Canary]
旧旧旧旧旧 (95%) + 新 (5%) → 旧旧旧旧 (80%) + 新新 (20%) → 新新新新新 (100%)
試験頻出: 「即時切戻しが必要」→ Blue-Green、「段階リリース」→ Canary と即答できるように。
4. API 管理（Apigee と API Gateway）
なぜ API 管理が必要か
API を多数公開すると、認証 / レート制限 / バージョニング / 課金 / 監視 を一元管理しないと運用が破綻する。これを担うのが API Management。
Apigee / API Gateway / Cloud Endpoints の使い分け
| サービス | 用途 | 特徴 |
|---|---|---|
| Apigee | フルライフサイクル API 管理 | エンタープライズ向け、開発者ポータル、マネタイズ、複雑なポリシー |
| API Gateway | サーバーレス API ゲートウェイ | 軽量、Cloud Run/Functions と統合、サーバーレス向け |
| Cloud Endpoints | gRPC/OpenAPI ベースの API 管理 | 軽量、GKE/GCE/App Engine と統合（やや古い） |
シンプル ←───────────────→ 高機能
Cloud Endpoints API Gateway Apigee
- gRPC - サーバーレス - 開発者ポータル
- 軽量 - Cloud Run - 課金 / マネタイズ
- Cloud Functions - 詳細ポリシー
- フルライフサイクル
Apigee の主要機能（概観）
- API プロキシ: バックエンドの前段でリクエスト/レスポンスを処理
- ポリシー: 認証、JWT 検証、レート制限、変換、キャッシュ、ロギング
- 開発者ポータル: 外部開発者が API ドキュメントとキーを取得
- Apigee Analytics: API 利用状況の分析
- マネタイズ: 利用量ベース課金プラン
「API のフルライフサイクル管理」「外部開発者向けポータル」「マネタイズ」→ Apigee と即答。
5. テストの基礎
テストの階層（テスティングピラミッド）
△
/ \
/ E2E \ ← 少数・遅い・本物に近い
/------\
/ Integ. \ ← 中程度
/----------\
/ 単体テスト \ ← 多数・速い・モック中心
/---------------\
テスト種別と用途
| 種別 | 内容 | 代表ツール |
|---|---|---|
| 単体テスト（Unit Test） | 関数・クラス単位 | JUnit、pytest、Jest、Go test |
| 統合テスト（Integration Test） | 複数コンポーネント連携 | Testcontainers、Cloud Emulators |
| E2E テスト | 本番に近い環境で全体動作 | Cypress、Playwright、Selenium |
| 負荷テスト（Load Test） | 想定負荷で性能確認 | Locust、JMeter、k6、Gatling |
| ストレステスト | 限界を超えた負荷で耐性確認 | 同上 |
| カオス試験 | 故障注入で回復力確認 | Chaos Toolkit、Litmus |
Cloud Emulators
Bigtable / Spanner / Pub/Sub / Firestore はローカル実行できる エミュレータ が提供されている。
gcloud emulators bigtable start
gcloud emulators spanner start
gcloud emulators pubsub start
gcloud emulators firestore start
利点:
- 課金されない
- CI 内で隔離テストできる
- オフライン開発可能
試験頻出: 「テスト用にローカル実行したい」→ Cloud Emulators。
6. データ・システム移行ツール
主要な移行サービス
| サービス | 用途 |
|---|---|
| Database Migration Service (DMS) | DB 移行（オンプレ→Cloud SQL/AlloyDB/Spanner、最小ダウン） |
| Datastream | CDC（変更データキャプチャ）でリアルタイム同期 |
| Migrate to Containers (M2C) | VM ワークロードをコンテナ化して GKE/Cloud Run へ |
| Migrate for Compute Engine (M4CE) | VMware/AWS/Azure VM を Compute Engine へ |
| Storage Transfer Service | GCS 間 / S3 / Azure Blob / HTTP からデータ転送 |
| Transfer Appliance | 物理デバイス郵送による大量データ移行（>100TB） |
| BigQuery Data Transfer Service | SaaS / 他 DWH から BigQuery にデータ取込 |
| Migration Center | 移行アセスメント・計画統合プラットフォーム（旧 Stratozone） |
Database Migration Service（DMS）の流れ
1. ソース DB を登録（オンプレ / 他クラウド / 別 GCP）
2. 接続プロファイル作成（IP/Interconnect/VPN/Reverse SSH Tunnel）
3. 移行ジョブ起動（フルロード + CDC レプリケーション）
4. 検証（データ整合性、ラグ）
5. カットオーバー（読み書きを Cloud SQL に切替）
サポート対象（試験頻出）:
- MySQL → Cloud SQL for MySQL
- PostgreSQL → Cloud SQL for PostgreSQL / AlloyDB
- SQL Server → Cloud SQL for SQL Server
- Oracle → AlloyDB / Cloud SQL for PostgreSQL
Datastream（CDC ストリーミング）
| 観点 | 内容 |
|---|---|
| 用途 | 既存 DB の変更を リアルタイム に BigQuery / Cloud Storage に流す |
| ソース | Oracle, MySQL, PostgreSQL, SQL Server, AlloyDB |
| 用途例 | 分析パイプライン、データレイク構築、移行中の同期維持 |
「移行中も書き込みを止めず、最後にカットオーバー」→ DMS、「継続的にレプリケーション」→ Datastream。
7. Gemini Cloud Assist（最新）
GCP コンソールに組み込まれた AI アシスタント。設計・実装・運用の各場面で支援する。
| 場面 | 支援内容 |
|---|---|
| 設計 | アーキ提案、ベストプラクティス参照 |
| 実装 | gcloud コマンド生成、Terraform スニペット生成、コードレビュー |
| 運用 | ログ解析支援、エラー原因推定、修復手順提案 |
| トラブルシュート | 障害時の関連リソース横断検索 |
| ドキュメント | 自然言語検索、要約 |
類似サービスとの違い
| サービス | 役割 |
|---|---|
| Gemini Cloud Assist | GCP 運用全般 の AI 支援（コンソール内） |
| Gemini Code Assist | IDE 内のコード補完（VS Code / IntelliJ / Cloud Shell Editor） |
| Vertex AI Gemini API | 開発者向け LLM API |
8. Cloud Shell と Cloud Code
Cloud Shell
ブラウザから即起動できる マネージド開発環境。gcloud / gsutil / bq / kubectl / terraform などがプリインストール。
| 構成要素 | 内容 |
|---|---|
| Cloud Shell Terminal | ブラウザの bash シェル、5GB の永続 $HOME、無料 |
| Cloud Shell Editor | ブラウザ版 VS Code（Theia ベース）、シンタックスハイライト、デバッガ |
| Boost Mode | 一時的に高速化（4 コア／8GB） |
用途:
- 一時的なオペレーション（gcloud コマンドを今すぐ実行）
- インフラ初期構築（Terraform）
- 学習・検証
Cloud Code
ローカル IDE（VS Code / IntelliJ）の拡張機能。
主な機能:
- GKE / Cloud Run 用テンプレートとデプロイ
- Skaffold / Kustomize / Helm 統合
- Cloud APIs スニペット
- Cloud Run 用ローカル実行
- リモートデバッグ
- Gemini Code Assist 統合
「ローカル IDE で K8s/Cloud Run 開発」→ Cloud Code、「ブラウザで gcloud 実行」→ Cloud Shell と即答。
9. gcloud / gsutil / bq の役割
| CLI | 担当 |
|---|---|
| gcloud | GCP リソース全般（プロジェクト、Compute、GKE、IAM 等） |
| gsutil | Cloud Storage 専用（旧、現在は gcloud storage に置き換え推奨） |
| bq | BigQuery 専用 |
| kubectl | Kubernetes 操作（GKE） |
| terraform | IaC（GCP プロバイダ） |
よく使う基本コマンド
# 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
新コマンド:
gsutilの機能はgcloud storageに統合されつつある。CI/CD ではgcloud storageを推奨。
10. Infrastructure as Code（IaC）の基礎
IaC のメリット
| メリット | 説明 |
|---|---|
| 再現性 | 環境を同じ構成で再構築できる |
| バージョン管理 | Git で変更履歴を追跡 |
| レビュー可能 | PR でインフラ変更をレビュー |
| 自動化 | CI/CD でデプロイ |
| ドキュメント性 | コードが「現在の構成」のドキュメントになる |
GCP の IaC 選択肢
| ツール | 概要 |
|---|---|
| Terraform | HashiCorp 製、最も普及、マルチクラウド対応 |
| Config Connector | Kubernetes CRD で GCP リソース管理（GitOps と相性） |
| Pulumi | 一般言語（TS/Python/Go）で IaC |
| Deployment Manager | GCP 純正（レガシー、新規は非推奨） |
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 → 破棄
試験頻出: 「IaC（GCP）」→ Terraform。Deployment Manager は古い（出題は減）。
11. Google API クライアントライブラリの基礎
GCP の操作は REST API が本体。クライアントライブラリ を使うとリトライ・認証・ページング等を自動化できる。
| 言語 | ライブラリ |
|---|---|
| Python | google-cloud-*（google-cloud-storage 等） |
| Java | com.google.cloud:google-cloud-* |
| Go | cloud.google.com/go/* |
| Node.js | @google-cloud/* |
| .NET | Google.Cloud.* |
| PHP / Ruby | 同様 |
認証の基本
| 認証方式 | 用途 |
|---|---|
| ADC（Application Default Credentials） | デフォルト推奨。実行環境の認証を自動取得 |
| Service Account Key (JSON) | 旧式、漏えいリスクあり、極力避ける |
| Workload Identity | GKE 内 Pod を SA に紐付け（鍵不要） |
| Workload Identity Federation | オンプレ / 他クラウドから OIDC で GCP 認証（鍵不要） |
# Python の例
from google.cloud import storage
client = storage.Client() # ADC で自動認証
bucket = client.bucket("my-bucket")
ベストプラクティス（基本）
- ADC を使う（環境別に自動切替）
- 指数バックオフ でリトライ（クライアントライブラリは内蔵）
- Idempotency を意識（重複呼出に対する冪等性）
- Quotas を意識（429 エラー → バックオフ）
- 同時並列度 を制限（多数の API を叩きすぎない）
- Service Account のキー直書きは避ける
12. まとめ — 実装管理の判断フロー
1. アプリ/インフラのデプロイ方法を決める
- CI: Cloud Build / GitHub Actions
- 成果物: Artifact Registry
- CD: Cloud Deploy（GitOps）
- 戦略: Rolling / Blue-Green / Canary
↓
2. API を公開するなら API 管理を選定
- フルライフサイクル → Apigee
- サーバーレス軽量 → API Gateway
↓
3. テスト戦略
- 単体 → 言語標準
- 統合 → Cloud Emulators
- 負荷 → Locust / JMeter / k6
↓
4. 移行ツール
- DB → Database Migration Service / Datastream
- VM → Migrate for Compute Engine
- VM→Container → Migrate to Containers
- 大量データ → Transfer Appliance
↓
5. プログラマブル操作
- 一時オペ → Cloud Shell
- IDE 開発 → Cloud Code + Gemini Code Assist
- インフラ → Terraform / Config Connector
- 認証 → ADC + Workload Identity（Federation）
次のステップ
- 中堅レベルへ進む方:
02_応用.mdで デプロイ戦略の詳細、Apigee 詳細、Terraform 実践 を学ぶ - 試験準備中の方:
03_要点と暗記.mdで要点を整理 - 関連セクション: Section 1（設計）、Section 6（運用卓越性）