Google ACE: デプロイ、構成、自動化 — 学習ガイド

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

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

コマンドライン操作と環境管理

Cloud Shell と gcloud の設定:

• Cloud Shell は、事前認証済みの gcloud と永続的なホームディレクトリを備えた、マネージドな管理環境を提供します。
• 名前付き設定を使用すると、アカウント、プロジェクト、リージョンをすばやく切り替えることができます: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
• アクティブな設定は gcloud config list で確認します。GKE の場合は、認証情報を取得します: gcloud container clusters get-credentials my-cluster –region us-central1

Compute のコマンドパターン:

• 予約済みの内部 IP を持つ VM を作成する: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
• カスタム VPC、サブネット、ファイアウォールルールを作成する: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

IAM のパターン:

• プロジェクトスコープでロールを付与する: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
• プロジェクト間でカスタムロールをコピーする: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Storage のパターン:

• バケットを作成し、オブジェクトをアップロードする: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
• ファイル経由でライフサイクルを設定し、gcloud storage buckets update --lifecycle-file=policy.json で適用する

API の有効化と確認:

• アプリのために Pub/Sub を有効化する: gcloud services enable pubsub.googleapis.com
• 有効化されているサービスを一覧表示する: gcloud services list –enabled

ガバナンス、ドリフト、自動化

構成ドリフトとポリシーの強制：

• スケジュールに基づいて terraform plan を実行してドリフトを検出。予期しない変更があった場合はビルドを失敗させる。
• 組織のポリシー制約（例：外部 IP の制限）を強制し、適用前に Policy-as-Code を使用してリソース構成を検証する。
• Kubernetes の場合、Config Sync と Policy Controller を使用して、継続的に調整し、非準拠の変更をゲートする。
• 監査可能性：Admin Activity ログと Data Access ログに依存し、分析のために BigQuery にルーティングする。Cloud Asset Inventory を使用して、特定時点（point-in-time）およびタイムトラベルでの状態クエリを実行する。

割り当てと上限：

• リージョンごと、プロジェクトごとの割り当てを検査し、オートスケーリングとロールアウトのためのヘッドルームを計画する： gcloud compute regions describe us-central1 --format="yaml(quotas)"
• 計画的な成長や大規模なロールアウトに先立って、割り当ての増加をリクエストする。

運用タスクの自動化：

• Cloud Scheduler は、cron スケジュールで HTTP エンドポイント、Pub/Sub トピック、または Workflows をトリガーする。ハンドラがべき等であることを確認し、リトライとデッドレター トピックを設定する。
• Workflows は、リトライ、並列ステップ、補償ロジックを備えた Google API を横断するマルチステップの自動化をオーケストレーションする。
• Cloud Run jobs は、オンデマンドまたは Scheduler 経由で、コンテナ化されたバッチタスクや管理タスクを実行する。一度きりまたは反復的なワークロードには jobs を優先し、ジョブのサービスアカウントには最小限の権限を使用する。

ロールアウトの安全性と可観測性：

• ヘルスチェックと readiness probe をサービスに組み込む。起動が遅い MIGs の場合、早すぎるスケーリングアクションを防ぐために初期遅延を長くする。
• デプロイメントのメトリクスとエラーバジェットを収集し、SLO が低下した場合はロールアウトを一時停止または自動的に中止する。

実践的な問題シナリオ

Altostrat Media は、GKE ベースのサービスのマルチ環境デプロイを標準化し、構成ドリフトを排除し、迅速なロールバックを保証する必要がある。また、アプリケーションを再構成することなく、レガシーなライセンスサーバーのために固定の内部 IP を予約しなければならない。

1. 基礎となる Terraform モジュールとリモートステートの作成

• VPC、サブネット、GKE、サービスアカウント、ファイアウォールルール用のモジュールを実装する。ステートバケットには、バージョニングとリテンションポリシーを設定した Cloud Storage バックエンドを構成する。
• 理由：モジュール化は再利用性と一貫性を促進する。バージョニングされたリモートステートは、コラボレーション、回復可能性、およびロックを可能にする。

2. 必要なサービスを有効化し、最小権限の自動化アイデンティティを確立する

• compute.googleapis.com、container.googleapis.com、clouddeploy.googleapis.com、artifactregistry.googleapis.com を有効化する。
• Terraform、Cloud Build、Cloud Deploy 用に環境ごとのサービスアカウントを作成し、最小限のロール（例：ビルダーではなくデプロイヤーに roles/container.admin）を付与する。
• 理由：事前の有効化とロールのスコープ設定は、デプロイの失敗を減らし、影響範囲を限定する。

3. ネットワーキングのプロビジョニングとレガシー IP の予約

• Terraform を使用して、カスタム VPC、リージョンサブネット、およびネットワークタグに基づいたファイアウォールルールを作成する。
• 内部 IP を予約する： gcloud compute addresses create license-ip --region=us-central1 --subnet=core-us --addresses=10.0.3.21
• 理由：宣言的なネットワーキングは再現性を保証する。IP を予約することで、アプリケーションの前提条件を維持する。

4. Cloud Build でアーティファクトをビルドし、Artifact Registry に公開する

• cloudbuild.yaml を定義して、テストの実行、コンテナのビルド、スキャンを行い、不変のダイジェストを Artifact Registry にプッシュする。
• 理由：スキャン済みの不変なアーティファクトは、安全なプロモーションと来歴の基礎となる。

5. dev → qa → prod のターゲットを持つ Cloud Deploy パイプラインを構成する

• デリバリーパイプラインとターゲットを定義し、マニフェストをレンダリングするために Skaffold 構成を参照する。本番環境（prod）には手動承認を要求し、検証を構成する。
• 理由：構造化されたプロモーションは統制を強制する。ターゲットごとのポリシーは、偶発的な本番環境へのデプロイを回避する。

6. カナリア戦略とヘルスゲートを用いて GKE の更新をロールアウトする

• カナリアロールアウトポリシーを使用して、SLO とエラー率のチェックを条件に、トラフィックを 10%、次に 50%、そして 100% とシフトさせる。
• 理由：プログレッシブデリバリーはリスクを低減し、自然なロールバックポイントを提供する。

7. スケジュールされた plan とポリシーチェックでドリフトを排除する

• 夜間ジョブで terraform plan と Policy-as-Code バリデーターを実行し、予期しない差分や違反があった場合にアラートを出す。
• 理由：早期検出により、ドリフトが蓄積して将来の apply を破壊するのを防ぐ。

8. 予約済み IP を使用してライセンスサーバー VM を運用可能にする

• 予約済みアドレスと適切なタグにバインドされた VM を作成する： gcloud compute instances create license-server --zone=us-central1-a --subnet=core-us --private-network-ip=10.0.3.21 --tags=license
• 理由：アプリケーションを変更することなく到達可能性を確保する。タグにより、ファイアウォールルールのスコープを狭く保つ。

9. Scheduler、Workflows、jobs で定期的なタスクを自動化する

• Cloud Scheduler が Workflow をトリガーして、避けられない場合にサービスアカウントキーをローテーションし、週次のデータベースバキュームタスクのために Cloud Run job を起動する。
• 理由：中央集権的なスケジューリングとオーケストレーションを組み合わせることで、リトライと補償を備えた信頼性と可観測性が得られる。

10. ロールバックを計画し、readiness のしきい値を検証する

• 最後に成功したリリースを再プロモートするためのロールバック手順書を定義する。readiness probe を調整し、MIG ベースのワークロードについては、アプリのウォームアップ時間に合わせて初期ヘルスチェックの遅延を長くする。
• 理由：事前に計画されたロールバックと調整されたヘルスチェックは、インシデント中の連鎖的な障害や過剰プロビジョニングを防ぐ。

このアプローチは、不変のアーティファクト、宣言的なインフラ、ゲート付きのプロモーション、最小権限の自動化を組み合わせることで、Google Cloud 上で安全で監査可能、かつ再現性のある運用を実現する。

← ストレージ、データベース、データサービス · すべてのドメイン · モニタリング、ロギング、運用のトラブルシューティング →

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

Googleを閲覧 →