Google ACE: コンテナ、アプリケーションホスティング、サーバーレスプラットフォーム — 学習ガイド

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

こちらの一部です： Google Associate Cloud Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudは、フルマネージドのサーバーレスから設定可能なKubernetesクラスタまで、コンテナやアプリケーションを実行するための一連のプラットフォームを提供しています。適切なプラットフォームを選択し運用するには、コントロールプレーン、スケーリングモデル、リリースメカニズム、ネットワーキング、セキュリティを理解する必要があります。このセクションでは、Google Kubernetes Engine (GKE)、Artifact Registry、Cloud Run、App Engine、Cloud Functionsの運用ガイダンスを、シークレット管理、安全なロールアウト、診断のパターンとともに集約して解説します。

Kubernetes Engine: クラスタ、ワークロード、ネットワーキング

GKEクラスタは、マネージドKubernetesコントロールプレーンと、サイズ設定やセキュリティ確保を行うノードプールを提供します。運用のオーバーヘッドを最小限に抑え、規範的なデフォルト設定を利用する場合はAutopilotを、ノード、ネットワーキング、アドオンをきめ細かく制御する場合はStandardを選択します。予測可能で安全なアップグレードのために、リリースチャネルとノードの自動アップグレードを使用し、ノードの自動修復を有効にします。特定のパッケージがUbuntuを必要としない限り、強化されたノードにはContainer-Optimized OSを選択することが推奨されます。

• ノードプールとスケジューリング

  • ワークロードクラス（例: 一般、GPU、スポット）ごとにノードプールを分離し、taintとtolerationを使用してPodを誘導します。
  • クラスタオートスケーラーを有効にし、プールごとに最小/最大サイズを設定します。PodDisruptionBudgetとリソースリクエストがスケールインを妨げたり、リクエストが利用可能なノードシェイプを超えた場合にPodがpending状態のままになったりする可能性があることに注意してください。
  • Spot/プリエンプティブルノードはコストを削減しますが、エビクション（排除）のリスクが伴います。回復性のために、DeploymentのサージバジェットとPodトポロジー制約と組み合わせて使用します。

• Namespaceとマルチテナンシー

  • Namespaceを使用して、クォータ、ポリシー、RBACを分割します。NetworkPolicyを適用して東西トラフィックを制限します。特権付きワークロードを避けるため、NamespaceスコープでPod Security標準を強制します。

• ワークロード

  • Deploymentは、ローリングアップデート、サージ/利用不可バジェット、迅速なロールバックを用いてステートレスなPodを管理します。readinessプローブでトラフィックを制御し、liveness/startupプローブで自動修復を行います。readinessプローブの設定を誤るとトラフィックがブラックホール化する可能性があるため、本番環境投入前にテストしてください。
  • StatefulSetは、データベースやクォーラムベースのシステムに安定したIDと順序付けられたスケーリングを提供します。ヘッドレスServiceと動的プロビジョニングをサポートするStorageClassを使用し、ゾーンごとのPVの局所性を計画します。
  • DaemonSetは、ノードごとに1つのPodをスケジュールします（例: ロギング/モニタリングエージェント）。オートスケーリングやドレインイベントを尊重し、ノード全体のテレメトリに最適です。

• ServiceとIngress

  • ClusterIPは、クラスタ内DNSとロードバランシングを公開します。NodePortは主にトラブルシューティング用です。LoadBalancerは、Google Cloudの外部または内部TCP/UDPロードバランサーをプロビジョニングします。プライベートサービスには内部ロードバランサーを使用します。
  • GKE Ingressは、マネージド証明書、URLマップ、Cloud Armorを備えたグローバルHTTP(S)ロードバランシングを設定します。最新のトラフィック管理には、Podごとのヘルスチェックとより高速な収束を実現するコンテナネイティブのロードバランシング（NEG）が推奨されます。readinessエンドポイントが実際のアプリの健全性を反映するようにしてください。そうしないと、バックエンドが非健全になり、502エラーが発生します。

• オートスケーリング

  • Horizontal Pod Autoscaler (HPA)は、CPUなどのメトリクスやCloud Monitoring経由のカスタムメトリクスに基づいてレプリカをスケーリングします。Metrics Serverが正常であることを確認してください。Vertical Pod Autoscaler (VPA)はリクエストを適正なサイズに調整できます。HPAで管理されるワークロードにはVPAを「recommendation」モードで使用するか、HPA+VPA互換モードを慎重に使用して、HPAとの競合を避けてください。
  • クラスタオートスケーラーは、Podを収容するためにノードを追加/削除します。Podがどのノードシェイプよりも多くのリソースをリクエストした場合、それらは決してスケジュールされません。リクエスト/リミットをノードプールのシェイプに合わせてください。

簡単な例:

• 壊れたリリースをロールバックする:
  • kubectl rollout undo deployment/web
• 別のコンテキストを素早く確認する:
  • kubectl config use-context CONTEXT && kubectl config view

アーティファクト管理、サプライチェーンセキュリティ、安全なリリース

Artifact Registryは、VPC Service Controlsをサポートし、リージョンごとにコンテナイメージをホストします。環境ごとにリポジトリ（またはプレフィックス）を分け、イミュータブル（不変）なタグを強制します。ダイジェストでデプロイして曖昧さを排除します。Cloud Buildまたはお使いのCIを統合して、来歴メタデータと共にビルドとプッシュを行います。

• 脆弱性管理

  • Artifact Analysisを有効にして、イメージのOSおよび言語のCVEをスキャンします。重大度の高い検出結果があった場合にビルドを失敗させるか、プロモーションをブロックします。これをBinary Authorizationと組み合わせ、GKEへのアドミッション（受付）前に署名/証明（例: 脆弱性ポリシーの合格、SLSA来歴）を要求します。

• イメージのプロモーション

  • devリポジトリからstaging/prodリポジトリにイメージダイジェストをコピーするか、プロモーション用リポジトリでリタグすることでプロモートします。可変の「latest」タグは避けてください。テストとスキャン結果を条件とするCloud Buildトリガーで自動化します。

• シークレットと設定

  • 最小権限アクセスを持つSecret Managerの使用が推奨されます。GKEでは、Secret Manager CSIドライバをWorkload Identityと共に使用し、ノードが長期間有効なシークレットにアクセスしないようにします。KRM設定については、ConfigMap（非シークレット）とSecret（機密）を分離し、読み取り専用でマウントします。
  • サーバーレスの場合、Secret Managerへの直接バインディングを介してシークレットをマウントします。厳密に必要な場合を除き、環境変数にシークレットを埋め込むことは避けてください。

• ロールバックとリリースのパターン

  • Kubernetes: ダウンタイムなしのためのmaxUnavailable=0と、キャパシティに合わせて調整されたmaxSurgeを持つローリングアップデートを使用します。1つのServiceの背後にある2つのDeploymentによるカナリア、またはServiceメッシュによる段階的な割合での移行を行います。PodDisruptionBudgetとminReadySecondsで重要なワークロードを保護します。
  • Cloud RunとApp Engine: リビジョン/バージョンとトラフィックスプリッティングを使用して、カナリアおよびブルー/グリーンデプロイを行います。以前のリビジョンをウォーム状態に保ち、ロールバックのレイテンシを削減します。
  • 障害モード: 可変タグのドリフト（ずれ）、スキャン時間のギャップ、不適切に指定されたreadinessプローブは、停止の一般的な原因です。イメージダイジェスト、デプロイ前チェック、合成ヘルスプローブを使用してください。

サーバーレスアプリケーションプラットフォーム

Cloud Runは、コンテナネイティブでリクエスト駆動のコンピューティングを提供し、自動的なスケールトゥゼロとリクエストごとのID適用を特徴とします。

• Cloud Runのサービスとジョブ

  • サービスはHTTPを処理します。同時実行数（concurrency）はインスタンスあたりの同時リクエスト数を制御します（レイテンシと効率のバランスを調整）。ジョブは非HTTPのバッチ/cronを処理し、並列化が可能です。
  • リビジョンは不変のスナップショットです。トラフィックスプリッティングにより、パーセンテージでのカナリアリリースが可能です。最小インスタンス数を設定してコールドスタートを削減します。バックグラウンド処理が必要な場合は、アイドル中のCPU割り当てを使用します。
  • ID: サービス/リビジョンごとに専用のサービスアカウントを最小権限で割り当てます。IAM（Cloud Run 起動元ロール）を介して呼び出しを制限するか、必要に応じて公開します。エンドユーザー認証には、署名付きIAPトークンまたはIdentity Platformと連携したCloud Runの組み込み認証を使用します。

• ネットワーキング

  • プライベートVPCリソースにアクセスするには、サーバーレスVPCコネクタを使用します。下り（egress）を選択します：すべてのトラフィックをコネクタ経由にするか、プライベートなRFC1918範囲のみにするか。コネクタのスループットクォータに注意し、コネクタのサイズをスケールさせ、サービスとリージョンを合わせます。プライベートIPのみのリソースからのアウトバウンドインターネット通信には、Cloud NATと組み合わせます。
  • Private Service Connectは、プロデューサーサービスをプライベートに利用したり、内部エンドポイントを公開したりできます。外部HTTP(S)経由での上り（ingest）には、サーバーレスNEGを使用してCloud Load Balancingを利用します。

App Engineは2つの環境を提供します：

• スタンダード
  • サンドボックス化されており、迅速にスケールし、自動、基本、または手動スケーリングをサポートします。min_idle_instancesを使用した自動スケーリングは、事前にウォームアップされたキャパシティを提供します。コールドスタートが速く、デプロイモデルがシンプルです。OSレベルのカスタマイズは限定的で、ランタイムセットは固定です。
• フレキシブル
  • Compute Engine VM上でDockerを実行し、システムライブラリやネットワーキングに対する制御性が高まります。インスタンスのライフサイクルは遅く、ベースラインコストは高くなります。カスタムランタイムやネイティブライブラリが必要な場合に適しています。
• サービスとバージョン
  • バージョンごとにトラフィックを分割します（ランダム、Cookie、またはIP）。各サービスは独立してスケールできます。段階的なロールアウトを使用し、即時ロールバックのために以前のバージョンを維持します。

Cloud Functionsは、イベント駆動の単一目的の関数を提供します。

• トリガー: Pub/Sub, Cloud Storage, HTTP, 多くのソースに対応するEventarc。ハンドラはべき等（idempotent）にします。一部のトリガーは失敗時にリトライするため、重複処理につながる可能性があります。
• ランタイム構成: 環境変数, Secret Managerとの連携, 最大インスタンス数, メモリ/CPU。HTTP関数の同時実行数を制御して、レイテンシとコストのバランスを取ります。
• よくある落とし穴: 制限のない同時実行数やべき等でない副作用は、データの重複を引き起こします。Pub/SubにはDLQを確保します。適切なタイムアウトを設定します。

プラットフォームの選定、ネットワーキング、および運用のオーナーシップ

必要なコントロール、スケーリング特性、可搬性のニーズ、および運用予算に基づいてプラットフォームを選択します。

• コントロールとオーバーヘッドの比較

  • 最も高いコントロール: GKE Standard（ノード OS、ネットワーキング、セキュリティアドオン）。それに伴い運用オーバーヘッドも高くなります。
  • バランス型: GKE Autopilot（ノード管理不要、規範的なセキュリティ）。
  • 最も低いオーバーヘッド: Cloud Run, App Engine, Cloud Functions（ノードなし、マネージドスケーリング）。ただし、ランタイムとリクエストモデルによる制約があります。

• スケーリングとワークロードへの適合性

  • リクエストが急増するワークロード: Cloud Run/App Engine Standard が優れています。イベント駆動のハンドラには Functions が適しています。
  • ステートフルまたはカスタムネットワーキング: StatefulSets と CNI 機能を備えた GKE。
  • 可搬性: GKE/Cloud Run 上のコンテナ。Functions は FaaS モデルのため可搬性が低くなります。

• サーバーレスネットワーキング、下り（egress）、プライベートサービス

  • プライベートアクセスには VPC コネクタを使用し、スロットリングを避けるためにコネクタの使用率を監視します。下り（egress）は必要な場合にのみ「all」に設定し、それ以外はコストとリスクを削減するためにプライベート範囲に限定します。
  • プライベートな上り（ingress）には、サーバーレス NEG または Private Service Connect を使用した内部 HTTP(S) ロードバランシングを検討します。
  • データ漏洩対策として、サポートされている場合は VPC Service Controls と組み合わせ、ファイアウォールと Cloud NAT を介して下り（egress）ルートを制限します。

• 診断と運用のオーナーシップ

  • Cloud Logging で構造化ログ（JSON）と、サービス間の相関付けのためのトレース/スパン ID を標準化します。Cloud Monitoring のダッシュボード、稼働時間チェック、SLO、およびアラートポリシーを使用します。
  • GKE の場合: Cloud Ops for GKE を有効にし、Prometheus または Cloud Monitoring を介してアプリのメトリクスを収集し、ノードレベルのテレメトリには DaemonSets を使用します。
  • サーバーレスの場合: 組み込みのリクエストログ、Error Reporting、Trace、Profiler を活用します。サービスごとにレイテンシ、エラー率、飽和度（同時実行数、インスタンス CPU）に関する SLO とアラートを設定します。
  • オーナーシップモデル: ランタイムパラメータ（スケーリング、同時実行数）、IAM、およびリリースパイプラインを誰が所有するかを定義します。ロールバックと障害シナリオを定期的にテストします。

実践的な問題シナリオ

Acme Retail 社は、社内サービスをモダナイズしながら、新しいチェックアウト API を公開する計画です。要件は、カナリアロールアウトを伴う低レイテンシの公開 API、VPC 内の社内在庫データベースへのプライベートアクセス、サプライチェーンの強制、そして最小限の運用オーバーヘッドで明確なロールバックが可能であることです。

1. 公開 API には Cloud Run を、社内在庫サービスには GKE Autopilot を選択する。

• 理由: Cloud Run はステートレス HTTP の運用オーバーヘッドを最小限に抑え、リビジョンとトラフィック分割をサポートします。GKE Autopilot は、ノード管理なしでステートフル/内部サービス向けの Kubernetes 機能を提供します。

2. 出自（provenance）と共にイメージをビルド、スキャンし、Artifact Registry に保存する。

• 理由: Cloud Build はコンテナイメージを生成し、Artifact Analysis は CVE をスキャンします。ダイジェストと出自を保存することで、Binary Authorization がスキャンおよび署名されたイメージのみが実行されるように強制できます。

3. アドミッションポリシーを強制する。

• 理由: GKE クラスタで Binary Authorization を有効にし、署名とポリシーアテステーションを要求します。Cloud Run については、脆弱性ポリシーに合格することを昇格の条件とするようにデプロイ自動化を構成します。

4. Serverless VPC コネクタと Cloud NAT を使用してネットワーキングを構成する。

• 理由: Cloud Run API は、在庫サービスと Cloud SQL にプライベートにアクセスする必要があります。VPC コネクタはプライベートな RFC1918 の下り（egress）を許可し、Cloud NAT はプライベートリソースに外部 IP を持たせることなく、依存関係のダウンロードのためにアウトバウンドインターネットアクセスを提供します。コネクタとサービスは同じリージョンに配置し、スループットを適正なサイズにします。

5. ID と権限を保護する。

• 理由: Cloud Run サービスに専用のサービスアカウントを割り当て、最小権限（例: Cloud SQL クライアント、必要に応じて内部エンドポイントへの invoke 権限）を付与します。GKE では、Workload Identity を使用して、Pod がノードレベルの認証情報なしでサービスアカウントを引き受けられるようにします。

6. 安全なリリースとロールバックを実装する。

• 理由: API を新しい Cloud Run リビジョンにデプロイし、カナリアとして 5% のトラフィックを分割します。レイテンシ、エラー率、飽和度を監視し、その後 100% まで段階的に引き上げるか、トラフィックを前のリビジョンに戻して即座にロールバックします。GKE では、readiness probe を使用した Deployment のローリングアップデートと、同じ Service の背後にある小規模なカナリア Deployment を使用して、完全なロールアウトの前に検証します。

7. オブザーバビリティと SLO を設定する。

• 理由: 両方のプラットフォームからトレース ID を含む構造化 JSON ログを Cloud Logging に出力します。p95 レイテンシと 5xx エラー率に関する SLO を作成し、アラートポリシーをアタッチします。根本原因分析には Error Reporting と Trace を使用します。GKE では、ノードメトリクス用に DaemonSet をデプロイし、Cloud Ops for GKE を有効にします。

8. 障害モードとキャパシティを検証する。

• 理由: 負荷テストを実施して、VPC コネクタのスループット、Cloud Run の同時実行数、GKE HPA の動作を検証します。ブラックホール化を防ぐために readiness probe の正確性を確認します。サプライチェーン強制下での回復可能性を確保するために、Binary Authorization の拒否パスとダイジェストによるイメージのロールバックをテストします。

このアプローチは、運用負荷が低く、セキュアな公開 API、管理された内部サービス、プライベートネットワーキング、強制力のあるサプライチェーンセキュリティ、そして迅速なロールバックを実現し、Google Cloud の運用上のベストプラクティスに沿ったものです。

← Compute Engine と仮想マシンオペレーション · すべてのドメイン · VPC ネットワーキング、接続性、トラフィック管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →