Google Cloud Assosiate Cloud Engineer　第6章　運用・監視・自動化

Google Cloud Assosiate Cloud Engineer
第6章　運用・監視・自動化

6.1 Cloud Monitoring の全体像

まず現実を直視すると、Monitoring をちゃんと設計していないシステムは、だいたい「壊れていることに気づくのが遅い」です。
Cloud Monitoring は、Google Cloud 上のリソースやアプリの

  • メトリクス
  • 稼働時間（uptime）
  • ダッシュボード
  • アラート

を一元管理するサービスです。

ACE レベルで押さえるべきキーワードは、次の 4 つです。

  • metrics（メトリクス）: CPU 使用率やリクエスト数など、数値として観測できるデータ
  • uptime checks（稼働時間チェック）: 外形監視
  • alerting policies（アラートポリシー）: 閾値超えなどを検知して通知
  • dashboards / Metrics Explorer: メトリクス可視化の UI

ここを押さえておけば、Monitoring 関連の ACE 問題はかなり楽になります。

6.1.1 メトリクスの基本

メトリクスはどこから来るか

Cloud Monitoring で扱うメトリクスには、ざっくり次の種類があります。

  • Google Cloud サービスのメトリクス
    • 例: Compute Engine, Cloud Storage, Cloud SQL, GKE など
    • サービスごとに compute.googleapis.com/… のようなメトリクスタイプが定義されている
  • Kubernetes / Istio メトリクス
    • GKE 用の kubernetes.io/… 系
  • エージェントやサードパーティ、カスタムメトリクス
    • Ops エージェント / OpenTelemetry / 独自アプリから送信するメトリクス

ACE では、「Cloud Monitoring は GCE / GCS / Cloud SQL / GKE などのリソースのメトリクスを集約する」というレベルで理解しておけば十分です。

Metric kind と value type

Cloud Monitoring のメトリクスは、metric kind と value type で分類されています。
試験で数字暗記までは要りませんが、「どんな種類があるか」程度は知っておきましょう。

  • Metric kind
    • GAUGE
      • ある瞬間の値（例: CPU 使用率、現在の接続数）
    • DELTA
      • 一定期間内の変化量（例: その期間に処理したリクエスト数）
    • CUMULATIVE
      • 開始時点からの累積値（例: サービス開始からの総リクエスト数）
  • Value type
    • DOUBLE, INT64, BOOL, DISTRIBUTION など
    • ほとんどのインフラ系メトリクスは DOUBLE or INT64

ACE でここまで細かく聞かれることは少ないですが、
「CPU 使用率は GAUGE」「リクエスト数は DELTA が多い」くらいの感覚を持っておくと、ドキュメントの記述を読んだときに迷わなくなります。

6.1.2 Metrics Explorer とダッシュボード

Cloud Monitoring では、収集されたメトリクスを

  • Metrics Explorer
  • ダッシュボード（カスタム / システム）

で可視化できます。

典型的な流れはこうです。

  1. Metrics Explorer でメトリクスを確認
    • 時系列チャートで CPU / メモリ / リクエスト数 / エラー率などを見る
    • リソースタイプとメトリクスタイプを選び、フィルタやグルーピングを設定
  2. よく見るグラフはダッシュボード化
    • チャートをダッシュボードに保存し、運用メンバー全員で共有
    • Cloud SQL や GKE などは、最初から「事前定義ダッシュボード」が用意されていることも多い

ACE では、「Cloud Monitoring のダッシュボードでリソースの健康状態を可視化できる」「メトリクスを元にアラートを作成できる」という理解があれば十分です。

6.1.3 Uptime checks（稼働時間チェック）

Uptime checks とは

Uptime checks は、Cloud Monitoring における「外形監視」です。

  • 世界中の複数ロケーションから、
    • HTTP(S) リクエスト
    • TCP / gRPC リクエスト
      を定期的に送信し、対象が応答しているかを監視する
  • 監視対象:
    • 任意の URL
    • VM インスタンス
    • Cloud Run / GKE Service / App Engine
    • 他クラウド（例: AWS EC2）なども指定可能

稼働時間チェックには主に 2 種類あります。

  • パブリック uptime check
    • インターネット側から到達できるエンドポイントを監視
  • プライベート uptime check
    • Private Service Connect などを使い、VPC 内のプライベートエンドポイントを監視

チェック内容は、単なる「HTTP 200 なら OK」だけでなく、レスポンス文字列の検証なども可能です。

Uptime checks とヘルスチェックの違い

ACE の典型トラップがここです。

  • Uptime checks
    • Cloud Monitoring の機能
    • エンドユーザー視点で「サービスが応答するか」をチェックする外形監視
  • Load Balancer のヘルスチェック
    • Cloud Load Balancing の機能
    • バックエンド VM / コンテナがトラフィックを受けられる状態かを確認する

問題文に「世界中の複数ロケーションから、HTTP で死活監視したい」と書かれていたら、それは uptime check です。
「LB が不健康なバックエンドを外したい」はヘルスチェック側の話です。

6.1.4 Alerting（アラートポリシー）

アラートポリシーの概要

Cloud Monitoring の alerting は、「条件を満たしたら通知する」仕組みを提供します。

アラートポリシーは、ざっくり次の要素で構成されます。

  • 条件（Condition）
    • メトリクスベース（metric-threshold）
    • uptime check ベース
    • （ACE では詳細不要だが）ログベースなども存在
  • 通知チャネル（Notification channel）
    • Email, SMS, Slack 的なチャットツール, Webhook, PagerDuty など
    • 通知チャネルは Monitoring 設定で事前に登録しておく
  • ドキュメント / ランブックリンク
    • アラートに説明文やトラブルシュート手順を添付可能

アラートポリシーが条件を満たすと「インシデント（incident）」が作成され、
解除条件を満たすまでオープン状態が続きます。

Metric-threshold alerting の代表例

メトリクスを元にしたアラートの典型例は次のようなものです。

  • CPU 使用率が 80% を 5 分以上継続
  • HTTP 5xx エラー率が 5 分間で 5% を超えた
  • ディスク使用率が 90% を超えた

ポリシー作成時には以下を設定します。

  • 監視対象メトリクス（例: compute.googleapis.com/instance/cpu/utilization）
  • 条件（大なり / 小なり、しきい値）
  • 再評価期間（例: 5 分間連続でしきい値を超えたら発火）
  • 通知チャネル & ドキュメント
Uptime check ベースのアラート

Uptime check は単体では「チェック結果をメトリクスとして記録する」だけです。
実際に通知を飛ばすには、その結果に対してアラートポリシーを作る必要があります。

よくあるルール:

  • 「全ロケーションで 1 分以上連続して失敗したらアラート」
  • 「特定リージョンの uptime check が 3 回連続で失敗したらアラート」

この「uptime check + alerting policy」のセットは、ACE のシナリオ問題でもよく出てきます。

6.1.5 Monitoring / Logging / Tracing の役割分担（ACE 的に）

ACE 試験では、Cloud Monitoring 単体というより、Cloud Logging / Error Reporting / Trace / Profiler などとの使い分けを問われることもあります。公式の観点で整理するとこんな感じです。

  • Cloud Monitoring
    • 数値データ（メトリクス）
    • 稼働時間チェック
    • ダッシュボード
    • アラート
  • Cloud Logging
    • ログイベント
    • Log-based メトリクス / Log-based アラート
  • Cloud Trace / Profiler など
    • アプリケーションパフォーマンス、レイテンシ分析

ACE の選択肢で迷ったときは、

  • 数値やグラフ → Monitoring / metrics
  • 文字列ログ → Logging
  • 外形監視 → uptime checks
  • 条件通知 → alerting policy

と機械的にマッピングできれば勝ちです。

6.1.6 ACE 試験での典型シナリオ

最後に、ACE でよくあるパターンをいくつかまとめます。

シナリオ A: Web サイトがダウンしたらメール通知したい

要件:

  • 外部公開している HTTP サービス
  • 世界の複数拠点から監視
  • 応答しなければメール通知

構成

  • Uptime check（public）を作成し、HTTP(s) で監視
  • その uptime check の失敗を条件とするアラートポリシーを作成し、通知チャネルにメールを指定
シナリオ B: CPU が高負荷になったら通知したい

要件:

  • Compute Engine の CPU 利用率が一定以上続いたらアラート

構成

  • メトリクス compute.googleapis.com/instance/cpu/utilization を条件とする metric-threshold アラートポリシーを作成
  • 「80% 以上が 5 分続いたら通知」のように設定
シナリオ C: プライベートな API を死活監視したい

要件:

  • VPC 内だけで公開している HTTP API
  • 外部 IP はないが、死活監視してアラートを飛ばしたい

構成

  • Private uptime check を作成し、VPC 内からのチェックを行う
  • 失敗時に通知するアラートポリシーを設定
シナリオ D: ダッシュボードで全体監視 & アラートを連動させたい

要件:

  • Cloud SQL / GCE / GKE などの状態を 1 画面で見たい
  • アラートとグラフを同じ場所で確認したい

構成

  • Cloud Monitoring のダッシュボードに各メトリクスのチャートを配置
  • 関連するアラートポリシーをダッシュボードに表示（alerting overview でも推奨されている使い方）

ここまで理解していれば、

  • metrics / uptime / alert / dashboard の役割
  • Monitoring と他サービスの境界
  • 典型シナリオで何を選ぶか

を ACE レベルで十分押さえた状態です。
あとは、実際にコンソールで 2〜3 個アラートポリシーと uptime check を作ってみれば、試験問題がほとんど「見たことある画面の話」にしか見えなくなります。人間の記憶力に優しいやり方です。

6.2 Cloud Logging の基本とログ構造・フィルタ

Cloud Logging は、Google Cloud とその他の環境から集めたログを「保存・検索・分析・監視・アラート」まで一括で扱えるマネージドなログ管理サービスです。

ACE レベルで押さえるべきポイントは、次の 3 つです。

  1. ログエントリの構造（LogEntry）
  2. 構造化ログ（jsonPayload）とテキストログ（textPayload）
  3. Logging Query Language を使ったフィルタの書き方

順番に整理していきます。

6.2.1 Cloud Logging とは何か

公式には、Cloud Logging は次のようなサービスとして説明されています。

  • Google Cloud の各サービス（GCE, GKE, Cloud Run, Cloud SQL など）のログを自動収集
  • アプリケーションやオンプレミス / 他クラウドのログも API / エージェント経由で取り込み可能
  • Logs Explorer で検索・可視化
  • Log-based metrics やアラート（Cloud Monitoring と連携）を作成可能
  • Logs Router を使い、BigQuery や Pub/Sub、他プロジェクトのログバケットへルーティング可能

ACE 的には、

  • 「ログの保管場所 + 検索ツール（Logs Explorer）」
  • 「フィルタを使って、必要なログだけを抽出・エクスポート・メトリクス化」

というイメージで押さえておけば十分です。

6.2.2 ログエントリの構造（LogEntry）

Cloud Logging では、すべてのログが共通の LogEntry という構造で表現されます。

ざっくり言うと、

  • メタデータ（どこから・いつ・どのレベルで出たか）
  • ペイロード（ログの中身）

の 2 層構造です。

主なメタデータフィールド

LogEntry で特に重要なフィールドを整理します。

  • logName
    • 「どのログストリームか」を表す名前
    • 例: projects/PROJECT_ID/logs/compute.googleapis.com%2Factivity_log
    • gcloud などの CLI では LOG_ID 部分だけ指定することもできる
  • resource
    • ログを出したリソースの種類とラベル
    • 例: resource.type="gce_instance", resource.labels.instance_id="1234567890" など
  • timestamp / receiveTimestamp
    • timestamp: イベントが発生した時刻
    • receiveTimestamp: Cloud Logging がログを受信した時刻
    • RFC 3339 形式で記録される
  • severity
    • 重大度レベル（DEBUG, INFO, WARNING, ERROR, CRITICAL など）
    • 数値としても比較でき、severity >= ERROR のようなクエリが可能
  • labels
    • 任意の key-value で付けられるメタデータ
    • プロジェクトやアプリ固有の識別子をタグ付けするのに便利
  • trace / spanId
    • Cloud Trace と連携する際のトレース ID / スパン ID
    • 分散トレーシングと紐付けたいときに利用
  • insertId
    • ログエントリの重複排除に使われる ID

ACE 試験では、ここまで細かく暗記する必要はありませんが、

  • resource.type と logName がフィルタの起点
  • severity でエラーだけ絞り込める

という 2 点は Logs Explorer のフィルタでもよく使うので、覚えておきましょう。

ペイロード（ログの中身）

ログの「本文」は、次のどれか 1 つのフィールドに入ります。

  • textPayload
    • プレーンテキストのログ
    • 例: アプリの print("something") のような出力
  • jsonPayload
    • JSON オブジェクトとして構造化されたログ
    • 例:{ "user_id": "123", "action": "purchase", "amount": 5000 }
    • 「構造化ログ」と呼ばれる
  • protoPayload
    • 主に Cloud Audit Logs などが使う、protobuf 形式のペイロード
    • IAM 変更などの管理操作ログがここに入る

構造化ログ（jsonPayload） にしておくと、後から

  • jsonPayload.user_id="123"
  • jsonPayload.action="purchase"

のようにフィールド単位でフィルタできるため、トラブルシューティングや分析で圧倒的に扱いやすくなります。

6.2.3 構造化ログと特別な JSON フィールド

Cloud Logging では、JSON でログを書き込むと、そのオブジェクトは jsonPayload に格納されます。これが 構造化ログ です。

さらに、JSON 内の特定のキーには「特別な意味」があり、LogEntry のトップレベルフィールドにマッピングされます。

例として、次のような JSON を出力するとします。

{
  "severity": "ERROR",
  "message": "failed to process order",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "/orders/123",
    "status": 500
  },
  "labels": {
    "service": "payment-api",
    "env": "prod"
  }
}

このとき:

  • severity → LogEntry の severity フィールドに反映
  • httpRequest → HTTP リクエスト情報として専用フィールドに反映
  • labels → LogEntry の labels として反映

といった形で、Cloud Logging 側が JSON を解釈してくれます。

ACE 試験でここまで細かい実装は問われませんが、

  • 「jsonPayload を使うと後からフィルタしやすい」
  • 「severity / labels / httpRequest などは特別扱いされる」

という感覚は持っておくと、Monitoring / Logging 周りの設計問題で判断しやすくなります。

6.2.4 Logs Explorer とフィルタの基本

Cloud Logging の UI である Logs Explorer では、次の 4 つを使ってログを絞り込みます。

  1. スコープ（プロジェクト / フォルダ / 組織 / ログバケット）
  2. 時間範囲
  3. ログフィールド（resource.type / logName など）の UI フィルタ
  4. Logging Query Language によるクエリ

ACE の学習では、3 + 4（フィルタ + クエリ） の理解が特に重要です。

6.2.5 Logging Query Language（ログクエリ言語）

Cloud Logging の検索・フィルタには、共通の Logging query language が使われます。

  • Logs Explorer のクエリエディタ
  • Logs Router の sink / exclusion フィルタ
  • Log-based metrics のフィルタ

で、同じ書式のクエリを使います。

基本構文

クエリは、「Bool 式で書く WHERE 句」のようなイメージです。

代表的なフィールド:

  • resource.type
  • logName
  • severity
  • textPayload / jsonPayload.field / protoPayload.field
  • labels.<key>
  • resource.labels.<key>

基本的な記法:

  • 等価比較
    • resource.type = "gce_instance"
  • 部分一致（文字列）
    • textPayload:"error"（: は部分一致検索）
  • 数値比較
    • severity >= ERROR
  • 論理演算
    • A AND B / A OR B / NOT A
例 1: GCE インスタンスの ERROR ログ
resource.type = "gce_instance"
AND severity >= ERROR
例 2: Cloud Run サービス「orders-api」のログから、500 エラーだけ抽出
resource.type = "cloud_run_revision"
AND resource.labels.service_name = "orders-api"
AND jsonPayload.httpRequest.status = 500
例 3: Cloud Audit Logs で IAM 変更を検索
resource.type = "project"
AND logName = "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
AND protoPayload.methodName = "SetIamPolicy"

Cloud Logging では、resource.type と logName はインデックスされており、これらを条件に含めるとクエリ性能が高くなると公式ブログでも推奨されています。

正規表現と高度な絞り込み

Logging query language は正規表現もサポートしており、複雑な文字列パターンで絞り込みができます。

例:

resource.type = "gce_instance"
AND textPayload =~ "timeout .* user_id=[0-9]+"

=~ が正規表現マッチを表します。

ACE 試験では、正規表現の詳細までは問われにくいですが、

  • クエリ言語で AND / OR / NOT を使って複雑な条件を指定できる
  • severity >= WARNING のような比較ができる

くらいは把握しておくと、問題文の「適切なフィルタ」を選びやすくなります。

6.2.6 フィルタの用途：検索だけでなく、ルーティングやメトリクスにも

Logging query language は、Logs Explorer の検索だけでなく、次の用途でもそのまま使われます。

  1. Logs Router の sinks
    • 例: 「severity>=ERROR のログだけを BigQuery にエクスポート」
    • エクスポート対象を inclusion / exclusion フィルタで指定
  2. Log-based metrics
    • 例: 「jsonPayload.status=500 のログの件数をカウントして、Cloud Monitoring のメトリクスにする」
  3. ログの除外（exclusion filters）
    • 例: 「health check の INFO ログは保存しない」

ACE のシナリオ問題では、

コスト削減のため、INFO レベルのアプリケーションログは保存せず、WARNING 以上のみ保持したい。
どこでどう設定するか？

のような形で問われることがあります。
この場合、Logs Router で exclusion filter を設定 し、Logging query language を使って条件を指定するのが正解方向になります。

6.2.7 Cloud Audit Logs と Cloud Logging の関係（ACE 向けに簡単に）

Cloud Audit Logs は、管理操作やデータアクセスを記録する監査ログで、Cloud Logging の一種です。

主な種類:

  • Admin Activity（管理操作）
  • Data Access（データアクセス）
  • System Event（システムイベント）
  • Policy Denied（ポリシーで拒否された操作）

これらは cloudaudit.googleapis.com/* という logName を持つログとして Cloud Logging に保存されます。

ACE 試験では、

  • 「IAM がいつ誰に変更されたか知りたい」
  • 「特定のユーザーの操作履歴を確認したい」

といった問題が Cloud Audit Logs + Logs Explorer に結びついていることが多いです。

6.2.8 まとめ：Cloud Logging で押さえるべきポイント

この節のポイントを整理すると、ACE レベルでは次が押さえられていれば十分です。

  • Cloud Logging 全体像
    • Google Cloud / 他クラウド / オンプレのログを集約・検索・分析するマネージドサービス
  • ログ構造（LogEntry）
    • logName, resource, timestamp, severity, labels などのメタデータ
    • 本文は textPayload / jsonPayload / protoPayload のいずれかに入る
  • 構造化ログ
    • JSON を jsonPayload に入れることで、フィールド単位での検索がしやすくなる
    • severity / labels / httpRequest などの特別な JSON フィールドは LogEntry にマッピングされる
  • Logging query language
    • resource.type, logName, severity, jsonPayload.xxx などを条件に、AND / OR / NOT で組み合わせる
    • 同じクエリ構文を Logs Explorer / Logs Router / Log-based metrics で共通利用する
  • Cloud Audit Logs
    • 管理操作やデータアクセスの監査ログも Cloud Logging に保存され、クエリで検索できる

ここまで理解できていれば、「どのログがどんな形で Cloud Logging に入ってくるか」「どんなクエリでほしいログだけを抽出するか」を ACE レベルで十分説明できる状態です。

6.3 IaC / CI/CD

この節では、ACE 試験で押さえておきたい以下 4 つを整理します。

  • Deployment Manager（DM）
  • Terraform（＋ Infrastructure Manager）
  • Cloud Build
  • Cloud Deploy

キーワードは次の 3 つです。

  • IaC（Infrastructure as Code）: インフラ構成をコードで宣言し、再現性と自動化を高める
  • CI（継続的インテグレーション）: コード変更を自動でビルド・テスト
  • CD（継続的デリバリー / デプロイ）: ビルド成果物を、複数の環境へ安全に自動展開

6.3.1 IaC の考え方と Google Cloud での選択肢

IaC の目的

IaC の目的は、インフラ構成を

  • 宣言的にコードで表現し
  • バージョン管理し
  • 同じ手順で何度でも再現できる

ようにすることです。

メリットは以下の通りです。

  • 手作業によるヒューマンエラー削減
  • 再現性と環境間の一貫性（dev / staging / prod）
  • コードレビューや GitOps による変更管理

Google Cloud では、主に次の選択肢があります。

  • Deployment Manager（DM）
    • Google Cloud ネイティブの IaC サービス
    • ただし、2026 年 3 月 31 日でサポート終了予定
  • Terraform（＋ Google Cloud Infrastructure Manager）
    • オープンソースの IaC ツール。複数クラウド対応
    • Google Cloud は Terraform の利用を前提としたチュートリアルやマネージド実行環境（Infrastructure Manager） を提供

ACE 試験では、

  • 「IaC で Google Cloud のリソースを定義・デプロイ」
  • 「複数環境で同一構成を再利用」

といった要件に対し、Deployment Manager / Terraform / Infrastructure Manager をどう選ぶかが問われる可能性があります。

6.3.2 Deployment Manager（DM）の位置づけ

Deployment Manager とは

公式ドキュメントでは、Deployment Manager は次のように説明されています。

  • Google Cloud のインフラリソース（Compute Engine, Cloud Storage, Cloud SQL など）を
  • テンプレートと設定ファイル（YAML）で宣言的に記述し
  • それに基づいてリソースの作成・更新・削除を自動化するサービス

特徴:

  • YAML の構成ファイルでデプロイメントを定義
  • Jinja / Python テンプレートで再利用可能な構成を記述
  • デプロイメント単位で複数リソースを一括管理

重要な点: DM はサポート終了予定

Deployment Manager は、2026 年 3 月 31 日にサポート終了が公式にアナウンスされています。

  • それ以降、Deployment Manager の API や機能は利用不可
  • Google は、Terraform や Kubernetes Resource Model（KRM）への移行を推奨しており、
    dm convert などの DM から Terraform / KRM への変換ツールも提供しています

ACE の観点：

  • 「Google Cloud ネイティブの IaC ツールとして DM が存在する」
  • 「ただし今後は Terraform / KRM に移行する流れである」

というレベルで押さえておけば十分です。

6.3.3 Terraform と Infrastructure Manager

Terraform の基本

Terraform は、HashiCorp が提供するオープンソースの IaC ツールです。

  • HCL（HashiCorp Configuration Language）でインフラ構成を宣言
  • terraform plan / terraform apply で差分を計画・適用
  • state ファイルで実環境との対応を管理
  • Google Cloud 含む複数クラウドや SaaS を一元管理可能

Google Cloud 向けには、google / google-beta プロバイダが提供されており、
Compute Engine / VPC / Cloud Storage / BigQuery / GKE などほぼ全サービスを Terraform から扱えます。

Google Cloud 公式でも、「Terraform で Google Cloud リソースを管理する」ことを前提としたハンズオンクエストや Marketplace 連携が用意されています。

Infrastructure Manager（Infra Manager）

Infrastructure Manager は、Terraform を Google Cloud のマネージド環境で実行するサービスです。

公式の説明を整理すると:

  • Terraform 構成ファイルを元に Google Cloud リソースをデプロイ・管理するマネージドサービス
  • Terraform の実行、state の管理、ログ、構成のバージョン管理などを Google Cloud 側で行う
  • 内部的には Cloud Build / Cloud Storage 等を組み合わせて実現されている

ポイント:

  • Terraform をローカルや自前の CI で動かさずに、「Terraform as a Service」 の形で利用可能
  • roles/config.admin などの IAM ロールを持つユーザーが、Infra Manager のデプロイメントを管理

ACE 試験で細かい API 名やパラメータが出る可能性は低いですが、

  • 「Terraform ベースの IaC を Google Cloud 側でマネージド実行したい → Infrastructure Manager」

という対応関係を覚えておくと、選択肢を絞りやすくなります。

DM / Terraform / Infrastructure Manager の比較（ACE レベル）

観点Deployment ManagerTerraformInfrastructure Manager
提供元Google CloudHashiCorp（OSS）Google Cloud
対応範囲Google Cloud のみ複数クラウド・SaaSTerraform で定義した Google Cloud リソース
構成言語YAML + Jinja / PythonHCLTerraform（HCL）
状態管理DM が内部管理state ファイルをユーザーが管理（GCS など）Infra Manager が state 管理
今後の方向性2026/3/31 でサポート終了利用推奨Terraform 実行のマネージド化

ACE 的には、新規構成は Terraform（＋必要に応じて Infra Manager） を選ぶ前提で考えておけばよいでしょう。

6.3.4 Cloud Build：ビルド / CI の要点

Cloud Build の概要

Cloud Build は、Google Cloud 上でビルド処理を実行するフルマネージドのサービスです。

公式ドキュメントの要点:

  • 各種ソースリポジトリ（Cloud Source Repositories, GitHub, GitLab, Bitbucket, Cloud Storage など）からソースコードを取り込み
  • 指定した手順（build steps）でビルド・テストを実行
  • Docker イメージや JAR などのアーティファクトを生成し、Artifact Registry / Container Registry / Cloud Storage に保存

特徴:

  • 完全マネージド・サーバレス
    • ビルド用のインスタンス管理やスケール設計は不要
  • ビルドステップはコンテナ単位
    • cloudbuild.yaml で、使用するコンテナイメージとコマンドを定義
  • トリガー連携
    • Git push / PR 作成 / タグ付けなどのイベントで自動ビルドが可能

さらに、Cloud Build には次のような機能があります。

  • default pool / private pool
    • default pool: Google 管理のビルド環境（インターネットアクセス前提）
    • private pool: VPC 内のプライベートリソースにアクセスできる専用ビルド環境
  • 他サービスとの統合
    • Container イメージをビルドして GKE / Cloud Run / App Engine にデプロイ
    • Terraform 実行やセキュリティスキャンなどもビルドステップとして組み込み可能

ACE 試験では、

  • 「CI パイプラインを Google Cloud ネイティブで構成する」
  • 「ソースコードの変更をトリガーに、イメージビルド＆テスト」

といった要件に対し、Cloud Build を答えられることが重要です。

6.3.5 Cloud Deploy：CD（継続的デリバリー）の要点

Cloud Deploy の概要

Cloud Deploy は、GKE / Cloud Run / Anthos 向けの継続的デリバリーに特化したマネージドサービスです。

公式ドキュメントの要点を整理すると:

  • アプリケーションを、あらかじめ定義した ターゲット環境のシーケンス（dev → staging → prod など） に対して自動デリバリー
  • delivery pipeline と target という概念でパイプラインとデプロイ先を定義
  • デプロイしたいタイミングで release を作成し、そのライフサイクルが Cloud Deploy によって管理される

特徴:

  • サポート対象:
    • Google Kubernetes Engine（GKE）
    • Cloud Run
    • Anthos / カスタムターゲットにも対応
  • Skaffold ベースの設定でビルド結果からマニフェストまでを一元管理
  • canary / 並列デプロイ / 自動ロールバック / 承認ステップ など、CD に必要な機能を提供
  • Cloud Build や既存の CI ツール（GitHub Actions など）と統合しやすい設計

ACE レベルでは、

  • Cloud Build = ビルド / テスト（CI）
  • Cloud Deploy = マルチ環境へのデリバリー（CD）

という役割分担を正しく選べることが大切です。

6.3.6 ACE 試験での典型パターン

最後に、ACE 試験で出題されそうなシナリオを、IaC / CI / CD の観点で整理します。

パターン 1：インフラをコードで定義し、再現可能にしたい

要件例：

  • 同じ VPC / サブネット / VM 構成を複数プロジェクトや環境で使い回したい
  • 手作業ではなく、宣言的に定義してレビューしたい

回答の方向性

  • 新規構成であれば Terraform を使用
  • Terraform を Google Cloud 側でマネージド実行したい場合は Infrastructure Manager を検討
  • DM は「レガシーの IaC としては存在するが、サポート終了予定」という認識

パターン 2：コード変更をトリガーにビルドとテストを自動化したい

要件例：

  • GitHub への push / PR 作成をトリガーに、自動でユニットテストとコンテナビルドを実行
  • 成果物は Artifact Registry に保存

回答の方向性

  • Cloud Build のビルドトリガーを利用
  • cloudbuild.yaml でビルドステップを定義し、テスト → イメージビルド → Artifact Registry への push まで自動化

パターン 3：dev → staging → prod の順に安全にデプロイしたい

要件例：

  • GKE / Cloud Run を使ったアプリケーション
  • 開発 → ステージング → 本番の順に、承認付きでプロモーションしたい
  • ロールアウト状況や指標も可視化したい

回答の方向性

  • CI 部分は Cloud Build や既存の CI ツールで担当
  • Cloud Deploy の delivery pipeline を定義し、
    • dev / staging / prod をターゲットとして登録
    • リリースを作成して順次プロモーション
  • 必要に応じてカナリアリリースやロールバックを構成

パターン 4：Terraform を使った GitOps 的運用

要件例：

  • Terraform 構成を Git で管理
  • main ブランチにマージされたら、自動でインフラを更新したい

回答の方向性

  • ソースリポジトリに Terraform コードを保存
  • Cloud Build（もしくは他 CI ツール）で
    • terraform plan → terraform apply を実行
  • Terraform 自体も Google Cloud マネージドで実行したい場合は、Infrastructure Manager + Cloud Build を利用するパターンもある

この節の内容をまとめると、ACE レベルでは次が選べれば十分です。

  • IaC
    • 既存の DM は 2026/3/31 にサポート終了予定
    • 新規構成は Terraform（＋必要に応じて Infrastructure Manager）で管理
  • CI
    • ビルド / テスト / コンテナイメージ作成は Cloud Build
  • CD
    • GKE / Cloud Run / Anthos へのマルチ環境デプロイは Cloud Deploy

問題文の要件を「インフラ構成か」「ビルドか」「デプロイか」に切り分けて、それぞれに対応するサービス名を即答できるようにしておくと、IaC / CI/CD まわりの問題はかなり取りやすくなります。