Google Cloud Assosiate Cloud Engineer 第3章　コンピューティングサービス

Google Cloud Assosiate Cloud Engineer
第3章　コンピューティングサービス

3.1 Compute Engine

3.1.1 Compute Engine の役割と全体像

Compute Engine は、Google Cloud が提供する IaaS 型の仮想マシン（VM）サービスで、
任意の OS とミドルウェアを載せて「普通のサーバ」として使える土台となる。

特徴を整理すると、だいたい次のイメージになる。

  • 汎用 VM から GPU・大容量メモリ・コンピュート最適化など、用途別のマシンタイプを選べる
  • ブートディスクやデータディスクを組み合わせてストレージを構成できる
  • リージョン / ゾーンを指定して、可用性とレイテンシをコントロールできる
  • インスタンステンプレートとマネージドインスタンスグループ（MIG）を使うと、自動スケール・自動復旧・ローリングアップデートまで自動化できる

ACE 試験では、
「単体の VM の作り方」よりも
『テンプレート＋MIG でどうやってスケーラブルな構成にするか』 がよく問われる。

3.1.2 VM インスタンスの基本要素

Compute Engine の VM インスタンスには、主に次の要素がある。

  • マシンタイプ（vCPU / メモリの組み合わせ）
  • ブートディスク（OS が入ったディスク）
  • 追加ディスク（データディスク）
  • イメージ / スナップショット / マシンイメージ
  • ネットワークインターフェース（VPC のサブネット・IP など）
  • サービスアカウントと IAM ロール
  • メタデータ / スタートアップスクリプト
  • ラベル（任意のキー / バリューペア）

ACE では、このあたりの要素がシナリオ問題に紐づいて出てくるので、
「VM を定義するときに何を決めているのか」をイメージできることが大事。

3.1.3 マシンタイプとディスクの基本

マシンタイプ

マシンタイプは、VM に割り当てる vCPU 数とメモリ容量の組み合わせで、
汎用系・メモリ最適化・コンピュート最適化など、用途別のシリーズが用意されている。

  • 例: e2-standard-4, n2-highmem-8, c3-highcpu-22 など
  • カスタムマシンタイプを作成して、vCPU / メモリ量を細かく調整することもできる

ACE レベルでは、「ワークロードが CPU / メモリのどちら寄りかを見てシリーズを選ぶ」程度の理解で十分だが、
過剰スペックを選ぶとコストが跳ね上がることは意識しておきたい。

ディスクとイメージ

Compute Engine のブロックストレージは「ディスク」と呼ばれ、
ブートディスクにもデータディスクにも使われる。

代表的なディスク種別:

  • バランス永続ディスク（Balanced PD）
  • SSD 永続ディスク（Performance 重視）
  • HDD 永続ディスク（スループット重視・低コスト）

ディスクは通常、イメージから作成する。公式のイメージには Linux / Windows の OS イメージや、
コンテナ最適化 OS などが含まれている。

バックアップや複製には次のような仕組みがある。

  • スナップショット: 単一ディスクのポイントインタイムコピー
  • マシンイメージ: 1 台の VM に紐づく複数ディスクやメタデータ、構成を一括でバックアップできるリソース

ACE 試験では、「スナップショットかマシンイメージか」「どのディスク種別が適切か」の選択が問われることがある。

3.1.4 リージョンとゾーン・可用性

Compute Engine のリソースは、世界中のリージョンとゾーンに配置される。

  • リージョン: 地理的なエリア（例: asia-northeast1）
  • ゾーン: リージョン内の実データセンタ（例: asia-northeast1-b）

基本ルール:

  • VM インスタンスは ゾナルリソース（特定ゾーンに属する）
  • 複数ゾーンに分散配置することで、ゾーン障害に対する耐性を上げられる
  • リージョン / ゾーンを選ぶ際は、レイテンシ・可用性・料金を総合的に見る

ACE 的には、「単一ゾーンに VM を置いただけでは、ゾーン障害で全部落ちる」という感覚を持っておくことが重要。
ここから、後で出てくる リージョナル MIG につながっていく。

3.1.5 メタデータとスタートアップスクリプト

VM には「メタデータ」というキー / バリューペアを設定でき、
その一種として スタートアップスクリプト を登録できる。

  • メタデータはプロジェクトレベル・インスタンスレベルの両方に設定可能
  • Linux VM の場合、startup-script メタデータキーなどを使ってシェルスクリプトを渡すと、
    起動時にスクリプトが実行される

公式ドキュメントでは、次のような例が紹介されている。

gcloud compute instances add-metadata VM_NAME \
  --zone=ZONE \
  --metadata-from-file startup-script=./startup-script.sh

スタートアップスクリプトの典型的な用途:

  • Web サーバのインストールと起動
  • アプリケーションコードの取得（Storage / Git など）
  • ログエージェントや監視エージェントのセットアップ

ACE 試験では、
「インスタンス作成時に自動でアプリケーションを導入したい」「構成管理ツールを使わずに簡単にセットアップしたい」
といったシナリオで、スタートアップスクリプト + メタデータ が正解候補になる。

3.1.6 ラベルと運用管理

Compute Engine の VM やディスク、スナップショットなどには ラベル を付けられる。

  • env=prod, team=analytics, app=web のようなキー / バリューでタグ付け
  • フィルタ検索、課金レポートの集計、運用自動化の条件指定などに利用

公式ドキュメントでは、gcloud compute instances create や ... update に --labels を指定する例が載っている。

ACE レベルでは、「課金や運用の単位としてラベルを付ける」「ラベルは IAM とは別物」というあたりが押さえどころ。

3.1.7 単体 VM とコスト最適化（Spot VM を含む）

単体 VM を運用する場合でも、コストと可用性のトレードオフ を意識する必要がある。

標準 VM

  • 常時利用を前提にした通常料金
  • 自動ライブマイグレーションなどにより、ホストメンテナンス時にも可能な限り稼働を継続

Spot VM / Preemptible VM

公式ドキュメントでは、Spot VM が Preemptible VM の最新版として位置づけられている。

  • Spot VM は、余剰リソースを低価格で提供するプロビジョニングモデル
  • 標準 VM と比べて大幅に安価（最大 90% 程度のコスト削減と紹介されることもある）
  • ただし Compute Engine 側の都合でいつでもプリエンプト（強制終了）され得る

Preemptible VM はレガシーな形態として残っているが、
Spot VM の利用が推奨されている点は押さえておきたい。

ACE 試験では、「バッチ処理やフォールトトレラントなワークロードのコストを下げたい」
というシナリオで Spot VM / Preemptible VM が選択肢として登場することがある。

3.1.8 インスタンステンプレート

インスタンステンプレート（Instance Template） は、
VM インスタンスの構成（マシンタイプ、ディスク、ラベル、スタートアップスクリプトなど）を
ひとまとめに保存しておくためのリソースである。

公式ドキュメントでは、インスタンステンプレートの用途として次が挙げられている。

  • 個別 VM の作成
  • マネージドインスタンスグループ（MIG）の作成
  • リザベーション（予約インスタンス）の作成

ポイント:

  • テンプレート自体には「状態（データ）」は含まれず、「構成」が記録される
  • 新しいテンプレートを作成して MIG に適用することで、ローリングアップデートが可能になる

ACE 試験的には、
「スケーリング対象の VM を毎回手動で作る」のではなく、
『インスタンステンプレート → MIG』 という流れで構成するのが標準パターンだと理解しておけばよい。

3.1.9 マネージドインスタンスグループ（MIG）

MIG の基本

マネージドインスタンスグループ（Managed Instance Group, MIG） は、
同一のインスタンステンプレートから作られた「同一構成の VM 群」を、
1 つの論理的なグループとして扱う仕組みである。

MIG を使うと、以下の機能を自動で利用できる。

  • オートスケーリング（負荷に応じた VM 数の自動増減）
  • オートヒーリング（ヘルスチェック異常時の自動再作成）
  • ローリングアップデート（テンプレート変更時の段階的な更新）
  • 複数ゾーンへの自動分散（リージョナル MIG）
  • ロードバランサのバックエンドとしての連携

その一方で、MIG の VM は基本的に 「ステートレス」 として扱うのが前提で、
個々の VM にだけ存在する状態（ローカルディスクのデータなど）には依存しない設計が求められる。

ゾーナル MIG とリージョナル MIG

MIG には 2 種類ある。

  • ゾーナル MIG
    • 1 つのゾーン内で VM 群を管理
    • ゾーン障害には弱いが、構成がシンプル
  • リージョナル MIG
    • 同じリージョン内の複数ゾーンに VM を分散配置
    • ゾーン障害が起きても、他ゾーンでサービスを継続しやすい
    • オートスケーラーがゾーンごとの VM 数をバランスよく増減させる

ACE では、
「高可用性が重要な本番 Web サービス → リージョナル MIG」
「単純なバッチ処理 → ゾーナル MIG」
といった使い分けを選ばせる問題が出てくることがある。

オートスケーリングとオートヒーリング

  • オートスケーリング
    • CPU 使用率・HTTP 負荷・カスタムメトリクスなどをトリガに、
      MIG 内の VM 数を自動で増減させる
  • オートヒーリング
    • ヘルスチェックが NG になった VM を自動的に削除し、
      テンプレートから新規 VM を作り直す

これらを組み合わせることで、
「負荷が増えたら自動でスケールアウトし、故障した VM は自動で入れ替える」
というクラウドらしい運用が実現できる。

ロードバランサとの連携

HTTP(S) ロードバランサやリージョン内ロードバランサのバックエンドとして、
MIG を直接ぶら下げることができる。

  • ロードバランサのバックエンドサービスに MIG を登録
  • ヘルスチェックの結果に応じてトラフィックを振り分け
  • MIG のオートスケールと連携して、アクセス増に自動対応

ACE 試験では、
「スケーラブルな Web アプリ構成を作りたい →
HTTP(S) ロードバランサ + リージョナル MIG」
という組み合わせが定番パターンとしてよく登場する。

3.1.10 ACE 試験で押さえるべき Compute Engine のポイント

この節の内容から、ACE 向けに特に重要なポイントをまとめる。

  1. VM の構成要素を説明できること
    • マシンタイプ / ディスク / イメージ / ネットワーク / SA / メタデータ / ラベル
  2. リージョン / ゾーンと可用性の関係を理解していること
    • ゾナルリソース / リージョナルリソースの違い
    • ゾーン障害を考慮した構成（リージョナル MIG など）
  3. Spot VM / Preemptible VM の位置づけ
    • コストは安いが、いつでもプリエンプトされ得る。
    • バッチやフォールトトレラントなワークロード向け。
  4. インスタンステンプレートと MIG の関係
    • テンプレートに構成を定義し、それをもとに MIG が VM 群を管理する。
  5. MIG の機能セット
    • オートスケール / オートヒール / ローリングアップデート / LB 連携を組み合わせて、
      スケーラブルで高可用なアプリケーション基盤を構築できる。

ここまで理解しておくと、
第 3 章の残りの節（ロードバランシングや GKE / Cloud Run との比較）を読むときにも、
「どのケースで Compute Engine + MIG を選ぶのが妥当か」を判断しやすくなる。

3.2 負荷分散と MIG の連携

3.2.1 なぜ「LB + MIG」が標準パターンなのか

Compute Engine でスケーラブルな Web / API を構成する場合、
もっとも典型的な構成は Cloud Load Balancing ＋ マネージドインスタンスグループ（MIG） である。

  • フロント: Cloud Load Balancing（Application Load Balancer / Network Load Balancer）
  • バックエンド: インスタンステンプレートから作られた MIG（同一構成 VM のグループ）

この組み合わせで、次の要件をまとめて満たせる。

  • クライアントは単一の IP / DNS 名にアクセスするだけ
  • バックエンド VM は自動スケール・自動復旧（オートスケール / オートヒール）
  • 複数ゾーン / 複数リージョンへの分散による高可用性
  • ヘルスチェックにより、健康な VM のみをトラフィック対象にする

ACE 試験では、「スケーラブルな Web アプリの推奨構成はどれか」「ゾーン障害時にも継続したいときの改善案は何か」といったシナリオで、この組み合わせを正しく選択できるかどうかが多く問われる。

3.2.2 Cloud Load Balancing の種類と MIG の位置づけ

Cloud Load Balancing は、用途に応じて複数のロードバランサを提供している。

代表的なものを整理すると次の通り。

  • Application Load Balancer（L7, HTTP(S)）
    • HTTP / HTTPS / gRPC などアプリケーション層トラフィック
    • グローバル外部 / リージョン外部 / 内部用がある
  • Network Load Balancer（L4, TCP/UDP）
    • TCP / UDP トラフィック
    • グローバル / リージョン / 内部用のバリエーション

どの種類でも、バックエンドとしてインスタンスグループ（MIG / 非管理）や Network Endpoint Group（NEG）を指定できる。

ACE 向けの典型的な対応は、次のように押さえておくとよい。

  • インターネット向けの HTTP/HTTPS Web サイトを、世界中からアクセスさせたい
    → Global external Application Load Balancer ＋ リージョナル MIG（複数ゾーン）
  • 社内向け HTTP アプリを、同一リージョンの VPC 内クライアントだけに公開したい
    → Internal Application Load Balancer ＋ MIG
  • TCP/UDP ベースの独自プロトコル（HTTP ではない）を負荷分散したい
    → Network Load Balancer（proxy / passthrough）＋ MIG

「トラフィック種別（HTTP/HTTPS か TCP/UDP か）」「外部 / 内部」「グローバル / リージョナル」を判断軸にするのがポイントである。

3.2.3 LB と MIG をつなぐ構成要素

Application Load Balancer と MIG の連携では、
主に次のリソースが関係する。

  1. フロントエンド（転送ルール / IP / ポート / プロトコル）
    • クライアントがアクセスする IP アドレスとポート（例: グローバル IPv4, TCP 443）
  2. ターゲット HTTP(S) プロキシ & URL マップ
    • リクエストのホスト名やパスに応じて、どのバックエンドサービスに転送するかを決める
  3. バックエンドサービス
    • バックエンドとしてどの MIG / NEG を使うか
    • ロードバランシングモード（RATE / UTILIZATION 等）や最大キャパシティなどを保持する
  4. バックエンドとしての MIG
    • インスタンスグループをバックエンドサービスに紐付ける
    • MIG 側には http:80 のような named port を設定し、バックエンドサービスと整合させる必要がある
  5. ヘルスチェック
    • HTTP / HTTPS / TCP / SSL / gRPC などのヘルスチェックを作成し、
      正常なインスタンスだけがトラフィックを受けられるようにする

試験で特に重要なポイントは以下。

  • named port を設定していないなどの理由で、ヘルスチェックが適切なポートを参照していないと、全インスタンスが UNHEALTHY 扱いになる
  • ヘルスチェックのプロトコル・ポートは、実際のアプリケーションが待ち受けているものと一致させる必要がある（HTTP なのに TCP ヘルスチェックを使うと挙動が変わるなど）

3.2.4 MIG のオートスケーリングと LB の連動

MIG は、Cloud Load Balancing と組み合わせることで真価を発揮する。

Compute Engine のオートスケーリングは、次の条件をトリガとして VM 数を増減できる。

  • MIG 全体の CPU 使用率
  • Cloud Monitoring のメトリクス（QPS、レイテンシなど）
  • 時刻ベースのスケジュール（ピーク時間帯に事前スケール）
  • Load Balancing の Serving capacity（バックエンドサービス経由の負荷）

特に HTTP(S) Application Load Balancer と組み合わせた場合、
バックエンドサービス側に「1 インスタンスあたりのリクエスト数」や「ターゲットレスポンス時間」などを設定し、
それを元にオートスケーラが MIG のインスタンス数を自動調整することができる。

ACE 試験では、次のようなシナリオが典型的である。

  • 「Web トラフィックの急増に対して、自動でバックエンド VM 数を増やしたい」
    → Application Load Balancer のバックエンドとして MIG を紐付け、
    オートスケーラを Load Balancing メトリクスに基づいて設定する。

3.2.5 高可用性構成：リージョナル MIG + ロードバランサ

高可用な Compute Engine ベースの Web アプリ構成として、
リージョナル MIG + Application Load Balancer は定番パターンである。

  • リージョナル MIG は、1 つのリージョン内の複数ゾーンに VM を分散配置する
  • 均等分散モードでは、maxNumReplicas をゾーン数で割った数が、ゾーンごとの上限となる
    • 例: ゾーン数 3、maxNumReplicas = 15 → 各ゾーン最大 5 台ずつ配置
  • 1 つのゾーンが障害を起こしても、残りのゾーンでサービスを継続できる

Global external Application Load Balancer を組み合わせると、
世界中のユーザーからの HTTP(S) リクエストを 1 つのグローバル IP で受け付けつつ、
裏側ではリージョン内の複数ゾーンに分散された MIG によって処理できる。

ACE の問題では、例えば次のような問われ方をする。

  • 「単一ゾーンに配置した HTTP VM がゾーン障害で落ちた。どう改善すべきか」
    → リージョナル MIG に変更し、Application Load Balancer のバックエンドにする
  • 「世界中のユーザー向けの Web アプリのレイテンシを最小化したい」
    → Global external Application Load Balancer と複数リージョンの MIG を組み合わせる

3.2.6 ACE 試験で押さえるべき判断ポイント

負荷分散と MIG まわりのシナリオ問題では、次の観点で選択肢を評価すると判断しやすい。

  1. どの LB の種類を選ぶべきか
    • HTTP / HTTPS / gRPC → Application Load Balancer
    • TCP / UDP → Network Load Balancer
    • インターネット向けか、VPC 内の内部向けか（external / internal）
    • リージョン単位で良いのか、グローバル配信が必要なのか
  2. バックエンドとして MIG を使う理由
    • 同一構成 VM のまとめ管理（テンプレート + MIG）
    • オートスケール / オートヒールの活用
    • リージョナル MIG による多ゾーン分散
  3. ヘルスチェックと named port の整合性
    • MIG に http:80 等の named port を設定しているか
    • ヘルスチェックのプロトコル / ポートが実サービスと一致しているか
  4. スケーリング戦略
    • CPU ベース、LB メトリクスベース、スケジュールベースなど、
      どのトリガが要件に合うかを判断できるか
  5. 可用性要件に対する構成
    • 単一ゾーンでよいのか、リージョン内の複数ゾーンへ分散すべきか
    • グローバルサービスなら、複数リージョン＋ Global external Application Load Balancer が必要か

この節の内容は、後の「ネットワーク」「Cloud Run / GKE との比較」でも頻繁に登場する。
ACE の本番で「LB + MIG」関連の問題を落とさないためには、
「どの LB」「どの MIG（ゾナル / リージョナル）」「どのヘルスチェック・スケーリング」 を
セットで考えられるようにしておくことが重要である。

3.3 Google Kubernetes Engine（GKE）

この節では、「ACE で必要な最小限の GKE 知識」にきっちり絞って整理します。
Kubernetes 自体の深いチューニングや、マルチクラスタ／サービスメッシュのような高度な話は ACE では出題範囲外と考えてよく、ここでは以下を押さえれば十分です。

  • どんなときに GKE を選ぶべきか（Compute Engine／Cloud Run との比較）
  • GKE クラスタの基本構造（コントロール プレーン／ノード／Pod など）
  • Autopilot / Standard モードの違い
  • ゾーン クラスタとリージョン クラスタ、プライベート クラスタの特徴
  • kubectl と基本オブジェクト（Deployment / Service / StatefulSet）のイメージ
  • Artifact Registry との連携と、autoscaling のイメージ

3.3.1 ACE 試験における GKE の位置づけ

公式の試験ガイドでは、GKE は次のような観点で扱われます。

  • 「適切なコンピューティング プロダクトの選択」において、Compute Engine / GKE / Cloud Run などからの選択肢の一つとして登場する
  • GKE クラスタを、Autopilot・リージョン クラスタ・プライベート クラスタなど、異なる構成でデプロイできること
  • kubectl をインストール・設定し、クラスタに対してコマンドを実行できること
  • GKE にコンテナ化されたアプリケーションをデプロイできること
  • 実行中のクラスタのインベントリ（ノード／Pod／Service など）を確認できること
  • ノードプールの操作、Pod の水平／垂直オートスケーリングの設定を理解していること

逆にいうと、ACE レベルでは以下は「やり込まなくてよい」領域です。

  • Helm チャートや高度な CI/CD パイプライン設計
  • マルチクラスタ管理（Fleet, Multi-cluster Orchestrator 等）
  • サービスメッシュ（Cloud Service Mesh）の詳細
  • Kubernetes API 廃止バージョン毎の細かい変更

本書では、試験ガイドに沿って「GKE が出てきたときに正しい選択肢を選べる」「基本操作の説明を読んで理解できる」レベルをゴールとします。

3.3.2 GKE の基本アーキテクチャ

GKE とは何か

Google Kubernetes Engine（GKE）は、Google Cloud が提供するマネージド Kubernetes サービスです。クラスタのコントロール プレーンのライフサイクル（作成から削除まで）を Google が管理し、オートスケーリングやアップグレード、ログ／メトリクス連携なども統合された形で提供されます。

ACE では、Kubernetes の用語をすべて暗記する必要はありませんが、以下の単位をイメージできることが重要です。

主要なコンポーネント

  • クラスタ（Cluster）
    • Kubernetes 全体の単位。
    • コントロール プレーンと、複数のノードから構成される。
  • コントロール プレーン（Control Plane）
    • Kubernetes API サーバ、スケジューラなどを含む管理側コンポーネント。
    • GKE では Google 管理のインフラ上で動作し、ユーザーは直接 VM を意識しない。
  • ノード（Node）
    • 実際にコンテナが動くワーカーマシン。実体は Compute Engine VM。
    • Standard モードではユーザーがノードプールとして管理し、Autopilot モードでは Google が管理する。
  • Pod
    • Kubernetes の最小デプロイ単位。1 つ以上のコンテナとボリュームなどのリソースをまとめたもの。
    • GKE では、オートスケーリングやリソース制御の対象は基本的に Pod 単位。
  • Deployment
    • 同一仕様の Pod を複数レプリカとして管理するオブジェクト。
    • 指定した数の Pod が常に動作するようにし、ローリングアップデートも担当する。
  • Service
    • Pod 群に対する安定したエンドポイント（仮想 IP / DNS 名）を提供するオブジェクト。
    • GKE では、type: LoadBalancer の Service を使うことで、Cloud Load Balancing と連携し外部公開が行われる。
  • StatefulSet
    • 状態を持つアプリケーション（DB など）のためのオブジェクト。
    • 各 Pod に安定した名前とストレージを割り当てる。
    • ACE では名前と「ステートフル用途」という役割が分かれば十分です。

ざっくり図にすると、次のようなイメージです。

[ GKE Cluster ]
  ├─ Control Plane（Google 管理）
  │    ├─ API Server / Scheduler / etcd ...（詳細は不要）
  └─ Node（Compute Engine VM）× 複数
         └─ Pod × 複数
              └─ コンテナ

ACE では、この構造を踏まえて「どこを誰が管理しているか（Google / 利用者）」を選択肢から判断できれば合格ラインです。

3.3.3 クラスタ モード：Autopilot と Standard

GKE で最初に問われる「構成判断ポイント」が、このモード選択です。

公式ドキュメントでは、GKE はクラスタのコントロール プレーンを常に Google が管理し、Autopilot モードではノード管理も含めて基盤部分をほぼ全面的に Google に任せられる一方、Standard モードではノードプールやマシンタイプをユーザーが管理する、と説明されています。

モード比較（ACE 用に簡略化）

観点AutopilotStandard
ノードの作成・管理Google が自動管理ユーザーがノードプールを管理
課金の基本単位Pod のリソース要求（CPU / メモリなど）ノード（Compute Engine VM）
スケーリングPod / ノード共に自動最適化が前提クラスタオートスケーラを自分で設定
デフォルトのクラスタ種別リージョン クラスタ（後述）ゾーン / リージョン を選択
柔軟性制約がある代わりに運用が楽より自由度が高いが運用負荷も高い

Autopilot では、Pod のリソース要求に応じて基盤を自動調整することが前提となっており、「クラスタサイズやノードタイプを細かく調整したくない」「Kubernetes の運用負荷を最小化したい」ケースで適しています。

一方 Standard モードでは、ノードプールごとにマシンタイプやスケーリングポリシーを設定し、自分でクラスタオートスケーラを構成していく形になります。

ACE 的な解き方の目安

  • 選択肢に「Autopilot クラスタ」が含まれており、
    • 運用負荷の削減
    • Pod 単位での課金最適化
    • 一般的な Web / API ワークロード
      がキーワードに入っていたら、Autopilot を優先して考える
  • 「特殊なノード設定」「特権的なワークロード」「専用 GPU ノードを細かく制御したい」など、基盤側の細かい制御が強調されている場合は Standard を検討、というイメージで十分です。

3.3.4 クラスタ種別：ゾーン / リージョン、プライベート クラスタ

ゾーン クラスタとリージョン クラスタ

GKE のクラスタは、「どの範囲にまたがってリソースを配置するか」によって、主に次の 2 種類があります。

  • ゾーン クラスタ（Zonal Cluster）
    • 1 つのゾーンにコントロール プレーンとノードを配置。
    • コストは抑えられるが、そのゾーン障害の影響を直接受ける。
  • リージョン クラスタ（Regional Cluster）
    • 同一リージョン内の複数ゾーンにコントロール プレーンとノードを複製し、高可用性を実現する。
    • インフラ障害時に、別ゾーン側でワークロードを継続させることができる。

ACE の問題では、多くの場合次のように整理すれば十分です。

  • 開発・検証用で低コスト重視 → ゾーン クラスタ
  • 本番系・ミッションクリティカルで高可用性重視 → リージョン クラスタ

特に Autopilot クラスタは常にリージョン クラスタとして動作するため、「Autopilot + 高可用性 = リージョン クラスタ」というセットで覚えておくと選択肢を絞りやすくなります。

プライベート クラスタ（Private Cluster）

プライベート クラスタは、ノードに内部 IP のみを付与し、ワークロードをインターネットから隔離するための構成です。

特徴を ACE レベルでまとめると、次の通りです。

  • ノードは内部 IP のみを持ち、デフォルトではインターネットから直接アクセスできない
  • コントロール プレーンへのアクセスも、プライベート エンドポイント（VPC 内）に制限可能
  • 外向き通信（コンテナイメージ取得や外部 API へのアクセス）が必要な場合は、Cloud NAT などを併用する
  • セキュリティ・コンプライアンス要件が強いシステムで選択肢になりやすい

試験問題の読み方としては、次のようなフレーズがあればプライベート クラスタを疑ってください。

  • 「ノードにパブリック IP を付けたくない」
  • 「インターネットから直接到達できない Kubernetes クラスタ」
  • 「VPC 内に閉じたワークロード」

3.3.5 GKE を選ぶべきケース：Compute Engine / Cloud Run との比較

試験ガイドでは、「与えられたワークロードに対して適切なコンピューティング プロダクトを選択する」ことが明示的に求められています。

ACE で頻出のパターンを、ざっくりマトリクスにしておきます。

代表シナリオ向いているサービスGKE を選ぶか？
単一コンテナの HTTP ベース Web / API、イベント駆動Cloud Run通常は不要
既存の VM ベースアプリ、OS に強く依存Compute Engine通常は不要
マイクロサービス構成、複数コンテナ、内部通信が多いGKE本命
Kubernetes 機能（DaemonSet, StatefulSet 等）が必須GKE本命
将来のマルチクラウド／マルチクラスタ運用も視野GKE本命

GKE を選ぶキーワードの例

  • 「マイクロサービス」「多数のサービス」「複数コンテナ」
  • 「Kubernetes を既に利用している」「Kubernetes ベースの標準化」
  • 「ポートが HTTP 以外」「長時間接続」
  • 「高度なスケジューリング」「ノードレベルの制御」

逆に、「単一コンテナ」「HTTP ベース」「スケールアウト主体」「運用を極力減らしたい」であれば Cloud Run が候補になりますし、「既存の OS やエージェントをそのまま動かしたい」なら Compute Engine が自然な選択です。

3.3.6 GKE の最小オブジェクトと基本操作フロー

ここでは、ACE 合格に必要な「最小限の Kubernetes オブジェクトと操作フロー」に絞って整理します。

1. kubectl とクラスタ接続

公式ドキュメントでは、GKE の管理には kubectl を用い、そのために kubectl のインストールとクラスタへのアクセス設定を行うことが説明されています。

典型的な流れ（概念レベルで理解すれば十分）

  1. Cloud Console または gcloud CLI で GKE クラスタを作成
  2. Cloud Shell などから
    • gcloud components install kubectl（必要なら）
    • gcloud container clusters get-credentials CLUSTER_NAME --region REGION
      で、kubectl から対象クラスタにアクセスできるようにする
  3. kubectl get nodes / kubectl get pods / kubectl get svc でインベントリを確認

試験ガイドでも、「実行中のクラスタのインベントリ（ノード、Pod、Service）」を確認できることが求められています。

2. Artifact Registry との連携

GKE にデプロイするコンテナイメージは、Artifact Registry（または旧 Container Registry）に保存するのが標準パターンです。

公式ガイドでは、GKE から Artifact Registry のイメージを pull するために、ノードのサービスアカウントに roles/artifactregistry.reader を付与するなどのアクセス制御を行うことが説明されています。

ACE では、次のポイントだけ押さえておけば十分です。

  • コンテナイメージは Artifact Registry に push する
  • GKE ノード（または Workload Identity など）が Artifact Registry を読む権限を持っている必要がある
  • プライベート クラスタ + VPC Service Controls のような構成では、Registry へのアクセスに専用の経路（restricted VIP）を用いる場合がある
3. Deployment / Service / StatefulSet の最小理解

ACE の範囲では、以下の程度の理解で充分です。

  • Deployment
    • 同じ仕様の Pod を指定数だけ動かし続けるためのオブジェクト
    • ローリングアップデートやロールバックの単位
  • Service
    • Pod 群に対する安定した入口
    • type が ClusterIP（クラスタ内のみ）、LoadBalancer（外部公開、Cloud Load Balancing と連携）など
  • StatefulSet
    • データベースのように、各インスタンスごとに識別子とストレージを持つ必要がある場合に使用
    • PersistentVolume と組み合わせて、Pod の再作成後もデータを保持

問題文で「ステートレスな Web アプリ」「データを持たないアプリケーション」とあれば Deployment、「ステートフル」「データベース」「ノードごとに固有の ID」がキーワードなら StatefulSet を連想できれば合格ラインです。

4. オートスケーリングのイメージ

GKE では、以下の 2 層でオートスケーリングが用意されています。

  • インフラ側のスケーリング
    • クラスタオートスケーラがノード数を増減させる（Standard モード）
    • Autopilot では、Pod のリソース要求に応じて基盤側が自動で最適化
  • ワークロード側のスケーリング
    • Horizontal Pod Autoscaler（HPA）：CPU 使用率やカスタムメトリクスに応じて Pod 数を増減
    • Vertical Pod Autoscaler（VPA）：Pod のリソース要求（CPU/メモリ）を自動調整

ACE では、「CPU 使用率に応じて Pod 数を自動で増やしたい → Horizontal Pod Autoscaler」「ノード数も自動で増減してほしい → クラスタオートスケーラ／Autopilot」のように、キーワードから対応する仕組みを選べることが重要です。

3.3.7 ACE 向け GKE 学習のチェックリスト

最後に、ACE 受験者が GKE で押さえるべきポイントをまとめます。

  1. GKE を選ぶべきかどうかを判断できること
    • マイクロサービスや Kubernetes 前提のワークロードか？
    • Cloud Run／Compute Engine では要件を満たせない何か（複数コンテナ、StatefulSet、ポート要件など）があるか？
  2. Autopilot / Standard の違いを説明できること
    • 誰がノードを管理するか
    • 課金モデルの違い（Pod ベース vs ノードベース）
    • 自由度と運用負荷のトレードオフ
  3. ゾーン クラスタとリージョン クラスタの違いがわかること
    • 可用性重視ならリージョン、本番環境ではリージョン推奨
    • 開発・検証や低重要度のワークロードならゾーンも選択肢
  4. プライベート クラスタの目的を説明できること
    • ノードに外部 IP を持たせず、VPC 内に閉じたセキュアなクラスタ構成であること
  5. kubectl を用いた基本操作のイメージが持てること
    • クラスタへの接続 (get-credentials)
    • kubectl get でノード／Pod／Service を一覧する
    • Deployment / Service / StatefulSet といったオブジェクトの役割を説明できること
  6. Artifact Registry からのイメージ pull の前提を理解していること
    • ノードのサービスアカウントに Artifact Registry Reader ロールを付与するケースがあること

このチェックリストを満たしていれば、「ACE で必要な GKE の最小知識」はクリアできていると考えてよいでしょう。

3.4 サーバーレス（Cloud Run / App Engine）

この節では、ACE 試験で頻出の「サーバーレス系コンピュート」のうち、Cloud Run と App Engine に絞って整理します。
どちらもインフラ管理を極力隠蔽してくれるマネージドサービスですが、実行モデルやスケーリング方式、適したユースケースが異なります。

3.4.1 サーバーレスの位置づけと ACE での問われ方

ACE 試験ガイドでは、「アプリケーションのデプロイ」や「適切なコンピューティングオプションの選択」の文脈で、Compute Engine / GKE / Cloud Run / App Engine などから最適なサービスを選ぶ能力が求められています。

特にサーバーレス領域では、次のような観点が問われやすいです。

  • Cloud Run と App Engine の違い
    • コンテナ必須かどうか
    • 対応するランタイムや制約
    • スケーリング／課金モデルの違い
  • Cloud Run / App Engine を選ぶべきシナリオ
    • シンプルな HTTP コンテナアプリ
    • 既存 App Engine アプリの延命・移行
    • ランタイム制約の有無、運用負荷と柔軟性のトレードオフ

以降は、ACE 合格に必要な範囲に絞って両者を比較していきます。

3.4.2 Cloud Run の特徴

Cloud Run は、「HTTP リクエストまたはイベントで呼び出されるコンテナ」を実行するフルマネージドなアプリケーションプラットフォームです。

主な特徴は次のとおりです。

  • コンテナ実行が前提
    • 任意の言語・ランタイムで作成したコンテナイメージを実行
    • HTTP エンドポイントを持つコンテナであれば基本的に動かせる
  • サーバーレス / フルマネージド
    • インフラ（VM、クラスタ）の管理は不要
    • リクエストに応じて自動スケールし、アイドル状態ではインスタンス数 0 にまでスケールダウン可能
  • ステートレス前提
    • 各リビジョンはステートレスな HTTP コンテナとして扱われ、ローカルディスクやメモリ上の状態には依存しない設計が推奨される
  • 料金モデル
    • vCPU・メモリ・リクエスト数に応じて、「使用した分だけ」を 100 ミリ秒単位で課金
    • アイドル時にスケールゼロになる場合、その間の課金は発生しない
  • スケーリングと同時処理数（concurrency）
    • 1 インスタンスで同時に処理する最大リクエスト数（concurrency）を設定できる
    • concurrency を増やすと、少ないインスタンス数で多くのリクエストをさばける一方、処理の孤立性は下がる

ACE の観点では、「コンテナベースの HTTP / イベント駆動サーバーレス」であり、「完全にインフラを意識せず、使った分だけ課金」というイメージが持てていれば十分です。

3.4.3 App Engine の特徴

App Engine は、Google Cloud が提供する PaaS 型アプリケーションプラットフォームで、アプリケーションコードをデプロイすれば、スケーリングやパッチ適用などのインフラ管理をかなりの程度まで任せられます。

App Engine には 2 つの環境があります。

App Engine Standard 環境
  • サンドボックス環境での実行
    • 軽量なサンドボックス上でアプリが実行され、ファイルシステム等に一部制約がある
  • 対応ランタイム
    • Java / Python / Node.js / Go / PHP / Ruby など、公式サポートされたランタイムで動作（バージョンはドキュメントで指定）
  • 自動スケーリング
    • インスタンス数はトラフィックに応じて自動的に増減
    • インスタンス起動時間は数秒オーダーで、柔軟なスケーリングが可能と紹介されている
  • 課金モデル
    • 使用したインスタンス時間や各種リソース（API、ストレージなど）に基づいて課金

ACE の範囲では、「サポートされたランタイムにコードをデプロイするだけで動作し、インスタンス管理はほぼ不要」という PaaS イメージがあればよいです。

App Engine Flexible 環境
  • Compute Engine ベースのコンテナ実行
    • App Engine Flexible は Compute Engine の VM 上のコンテナとしてアプリケーションを実行する
  • ランタイムの柔軟性
    • 標準的なランタイムに加え、カスタム Docker イメージを使って任意のライブラリやフレームワークを利用可能
  • スケーリング特性
    • 自動スケールは可能だが、インスタンスの起動やデプロイに Standard より時間がかかる（数分オーダー）
  • より「VM 寄り」の PaaS
    • OS レベルの制約が少ない反面、Standard よりも重く、コストも高くなる傾向

ACE 試験では、「Standard はより制約があるが軽量でスケールが速い / Flexible はより自由だが重い」という方向性が理解できていれば十分です。

3.4.4 Cloud Run と App Engine の比較

ACE に必要な範囲に絞って、Cloud Run と App Engine の違いを整理します。

実行モデルとデプロイ単位
  • Cloud Run
    • デプロイ単位: コンテナイメージ
    • HTTP リクエストまたはイベントで起動されるステートレスなコンテナ
  • App Engine
    • デプロイ単位: アプリケーションコード（app.yaml などの設定とランタイム）
    • Standard はランタイム指定 + コード、Flexible はコンテナ相当のランタイム環境
ランタイムと自由度
  • Cloud Run
    • コンテナであれば基本的に言語・フレームワーク自由
    • ただしステートレス HTTP（もしくはイベント）アプリ向き
  • App Engine Standard
    • サポートされた公式ランタイムに制約される
    • 一部の OS レベル操作やライブラリ利用に制約あり
  • App Engine Flexible
    • カスタムランタイムも可能で柔軟だが、VM ベースで重い
スケーリングと課金モデル
  • Cloud Run
    • 完全サーバーレス。リクエスト・イベントに応じて自動スケール
    • インスタンス数 0 までスケールダウン
    • vCPU / メモリ / リクエスト数に応じて、実行時間ベースで課金（100ms 単位）
  • App Engine Standard / Flexible
    • インスタンス数をトラフィックに応じて自動スケール（Standard の方が起動が速い）
    • 課金は「インスタンス時間」＋各種使用リソースに基づく
    • インスタンスが常駐している時間分のコストがかかる構造になりやすい
ネットワーク・VPC 連携（ACE での最小理解）
  • Cloud Run（フルマネージド）
    • Serverless VPC Access を利用して、VPC 内リソースにアクセス可能（詳細はネットワーク章で扱う）
  • App Engine
    • VPC への接続や Cloud SQL などのマネージドサービスへの接続機能が用意されている（Standard / Flexible で若干仕様が異なる）

ACE レベルでは、「どちらも VPC や他のマネージドサービスと統合できるが、Cloud Run はコンテナ＋サーバーレス、App Engine は PaaS のアプリケーションプラットフォーム」として大枠を押さえておけば十分です。

3.4.5 代表的シナリオと選択パターン（ACE 的な見かた）

ここでは、試験シナリオでほぼそのまま出てきてもおかしくないレベルに絞って、両者の選択パターンを整理します。

ケース 1: 単一コンテナの HTTP API / Web アプリ

要件:

  • コンテナイメージあり（または用意できる）
  • HTTP ベースのリクエスト処理
  • アクセス量は日によってばらつきが大きい
  • インフラ運用を最小化したい

→ Cloud Run が第一候補

理由:

  • コンテナさえ作れば、インフラ管理なしでデプロイ可能
  • アクセスが少ない時間帯はスケールゼロで課金も抑えられる
ケース 2: 既存 App Engine Standard アプリの運用継続

要件:

  • 既に App Engine Standard（例: Python / Java / Go）で動いているアプリ
  • ランタイムが公式サポートされており、App Engine 特有の機能（タスクキュー、cron 等）を利用している
  • 大規模なリファクタリングは避けたい

→ App Engine Standard を継続利用

理由:

  • コードと設定（app.yaml）を調整するだけでデプロイが継続できる
  • 既存の App Engine 統合機能をそのまま利用可能

試験では、「既存の App Engine アプリケーションを最小限の変更で運用継続したい」という表現があれば、Cloud Run に移行するより App Engine 継続の方が自然な選択になることが多いです。

ケース 3: ランタイム制約付きだが、より自由度が必要

要件:

  • App Engine Standard では使用できないネイティブライブラリや OS 機能を利用したい
  • ただし、いきなり GKE で自前クラスタ運用はしたくない

→ App Engine Flexible または Cloud Run

  • App Engine Flexible: VM ベースなので OS 制約が少なく、App Engine のデプロイモデルを維持したまま柔軟性を上げられる
  • Cloud Run: コンテナ化できるのであれば、Cloud Run に載せる方がよりサーバーレスでシンプルになることも多い

ACE 的には、このケースでは「App Engine Flexible か Cloud Run、どちらも候補」になり得るため、問題文のニュアンス（既存 App Engine との親和性を重視しているか、コンテナ指向か）を読み取ることが重要です。

ケース 4: バックグラウンド処理・イベント駆動

要件:

  • Pub/Sub メッセージや Storage へのオブジェクトアップロード等、イベントをトリガとして処理したい
  • 処理時間は短めで、負荷の変動も大きい

→ Cloud Run（イベントトリガ連携） が有力候補

理由:

  • Cloud Run は HTTP / イベント経由での呼び出しを前提としており、Cloud Pub/Sub や Eventarc などと連携してイベント駆動のコンテナを実行できる

3.4.6 ACE 試験向けチェックポイント

最後に、ACE 受験時に Cloud Run / App Engine 周りで押さえておきたいポイントを整理します。

  1. Cloud Run の基本イメージ
    • コンテナベースのフルマネージドサーバーレス
    • HTTP / イベント駆動でステートレス
    • 使った分だけ 100ms 単位で課金、スケールゼロ可能
  2. App Engine Standard / Flexible の違い
    • Standard: ランタイム制約あり・軽量・スケールが速いサンドボックス環境
    • Flexible: Compute Engine ベースのコンテナ実行で自由度が高いが重い
  3. 選択問題での典型パターン
    • 単一コンテナ HTTP サービス・イベント駆動 → Cloud Run
    • 既存の App Engine アプリ、App Engine の機能に依存 → App Engine Standard 継続
    • ランタイム制約を避けつつ PaaS モデル維持 → App Engine Flexible or Cloud Run
  4. 「運用負荷 vs 自由度」の軸で考える
    • Cloud Run: 最も運用負荷が低いが、ステートレス HTTP/イベント前提
    • App Engine Standard: ランタイム制約はあるがアプリ寄り PaaS
    • App Engine Flexible: さらに自由だが VM 寄りでやや重い
  5. 試験ガイドとの対応づけ
    • 「アプリケーションのデプロイ」「適切なコンピュートサービスの選択」という出題領域で、
      Cloud Run / App Engine / Compute Engine / GKE の違いを説明できること

この節の内容を押さえておくと、サーバーレス周りの設問で「なんとなくそれっぽい選択肢」を選ぶのではなく、
要件 → 実行モデル → サービス選択という流れで論理的に判断できるようになります。