Google Cloud PCA資格の学習記録 - Management編

はじめに

Google CloudのPCA(Professional Cloud Architect)認定資格取得に向けて学習した内容を自分なりに整理します。Google Cloudのサービスに限らず、それを扱う上での関連知識についても触れています。
本記事はManagement編ということで、下記の要素を扱います。

• デプロイ
  • デプロイ管理（Iacツール）
  • デプロイ戦略（リリース戦略）
• アクセス制御
  • Cloud IAM
  • Resource Manager
  • Identity Platform
• ID管理
  • Cloud Identity
  • Google Cloud Directory Sync (GCDS)
• システム監視
  • Cloud Operations (Operations Suite)
• セキュリティ
  • Secret Manager
  • Cloud Data Loss Prevention (DLP)
• 災害対策（Disaster Recovery）

この記事における「現在」や「最近」などの表現は、特に断らない限り2025年6月時点を指します

デプロイ

デプロイ管理（IaCツール）

Cloud Deployment Manager(CDM)

• Google Cloudに特化したネイティブツール
  • gcloudコマンドを使って操作するよう設計されている
• テンプレートは YAML または Jinja2 / Python で記述
  • Google Cloudのコンソールで作成および管理される
• シンプルな要件に対応
• 最近は、新しい機能の追加が止まっている or 遅い
  • 将来的にはDeprecatedの方向性

Cloud Foundation Toolkit(CFT)

• Terraformをベースとした、IaCツール用のテンプレート/モジュール集
  • 現在はこちらがベストプラクティス構成
• 下記のコンポーネントで構成される
  • CFTコマンドラインツール
    • CFTが独自にCLIツールを持っている訳ではなく、Terraform や Pulumi などの既存のIaCツールのCLIを使う
  • CFTテンプレート
    • HCL (Terraform) / YAML / TS (Pulumi)
    • Gitなど、Google Cloud外のサービスで管理できる
  • CFTライブラリ
• Terraformベースなのでマルチクラウド構成も可能

デプロイ戦略（リリース戦略）

カナリアリリース

新しいバージョンのアプリケーションを、段階的に本番環境に展開するリリース戦略

• 最初にごく一部のユーザーやトラフィックにだけ新しいバージョンを提供し、問題がなければ徐々に展開範囲を広げる方式
• 問題（例えば想定以上のパフォーマンス負荷など）が起きた場合、すぐに元のバージョンにロールバックできる
  • 逆に言うと、すぐに元に戻せる体制を整えておくことも重要
  • 問題を解決したら修正して次のリリースに回す
• Google Cloudで実現する場合、Cloud Runの「リビジョン間トラフィック分割」という機能を利用できる
  • 新バージョンに10%、旧バージョンに90%といった具合に、段階的にトラフィックを移行できる
  • 問題が発生した場合は即座にトラフィック割合を変更して、旧バージョンに戻すことも可能
• 他にはCloud Load Balancingを利用したり、GKEを利用したりして実現できる

Blue/Green Deployment

本番環境にBlueとGreenの2つの独立した環境を持ち、切り替えで反映させるリリース戦略

• Blue: 現在稼働中のバージョン
• Green: 新しいバージョン
  • Green上でテストを行い、問題なければトラフィックをBlueからGreenに切り替える
• 公開後に問題が起きれば、またBlueに戻す
• トラフィックの切り替えでリリースするので、ダウンタイムが短いのが特徴
• ちなみにRed/Black Deploymentとも呼ばれる
  • この場合はRedが現在のバージョンでBlackが新しいバージョン

アクセス制御

Cloud IAM（Identity and Access Management）

• ロールベースのアクセス制御（RBAC: Role-Based Access Control）に基づいた設計
  • 「誰（Identity）」に「どのロール」を「どのリソース」に対して割り当てるか

アイデンティティ（Identity）

• アクセスする主体のことをアイデンティティ（Identity）という
• アイデンティティの例
  • ユーザーアカウント（Googleアカウント）
  • サービスアカウント
    • Google Cloud内で動作するアプリケーションやVMが使う
      • メールアドレスと秘密鍵が付与され、これらの認証情報を用いてGoogle CloudサービスのAPIを利用する
  • Googleグループ
    • チームや部門単位の制御
  • Cloud Identity / Workspace
    • 企業ドメインの管理
    • 最上位リソースであるOrganizationの管理基盤

ロール

事前定義ロール（Predefined Roles）

• 特定のリソースに対する一般的な操作をカバーするために、Google Cloudが提供しているロール

カスタムロール（Custom Roles）

• 細かい要求に対応するため、ユーザーがカスタマイズできるロール

基本ロール

• プロジェクト全体に作用する古いロール
• 3種類しかなくてカスタマイズ性が低く、権限が広すぎるため最小権限の原則に反する
  • 2022年11月に非推奨、2023年11月には廃止された

IAMポリシー

• IAMのポリシー（Policy）は、主に複数のバインディングで構成される
• バインディング（bindings）とは、メンバー（ユーザーやグループ）とロールをセットにしたもの

ロギング

• IAMポリシーの変更履歴を外部にエクスポート出来る
  • エクスポート先はCloud Storage, BigQuery がサポートされている

Resource Manager

Google Cloudのリソース構造を定義し、ポリシーやIAMロールの適用範囲（スコープ）を提供するメタサービス

Resource ManagerとIAMは連携して機能しており、リソース階層に対してIAMポリシーを適用することで、組織全体・フォルダ単位・プロジェクト単位のアクセス制御を効率的に構築できる。

リソースと階層

Google Cloudのリソースは、上から順に下記の階層構造を持つ

• 組織（Organization）
• フォルダ（Folder）
• プロジェクト（Project）
• リソース（Resource）
  • e.g. Compute Engine, Cloud Storage など

リソース階層とロール管理

IAMの権限は、足し算（累積）が基本ルール

• 上位のリソースに割り当てられたロールは、下位のリソースにも引き継がれる
  • Projectに割り当てたリソースは、それに含まれるResourceにも適用される、など
• 下位の階層で新しい権限を追加することは出来るが、上位から与えられた権限を「上書き」したり「無効化」したりはできない
• 下記の方針によって「最小権限の原則」を実現するのがベストプラクティス
  • 上位階層では最小限のロール付与に留める。強い権限は与えない
  • 下位の階層（プロジェクトなど）でも、そこで必要な最小権限のみを与える

Identity Platform

• ユーザー認証や外部IDとの連携を提供するアクセス管理プラットフォーム
• シングルサインオンなどにも対応

ID管理

Cloud Identity

Cloud IAMがアクセス制御を行うのに対し、Cloud Identityは、ユーザーやグループ、デバイスなどIdentityそのものの管理を行う（IDプロバイダ）。

Google Cloud Directory Sync (GCDS)

• Google アカウントのデータを、オンプレミスのMicrosoft Active Directoryと同期する
• パスワードは同期しない

システム監視

Cloud Operations (Operations Suite)

Google Cloudのリソースを監視し、リアルタイム・または直近の状況を素早く把握するためのツール群。旧称Stackdriver。

リアルタイムや直近の状況把握が主目的のため、データの保存期間は数週間から数ヶ月程度。それ以上の長期保管や分析が必要であれば、Cloud StorageやBigQueryなどの別サービスへ連携が必要

Cloud Logging

ログの収集・検索・可視化を行うログ管理基盤

• アプリやインフラのログを1か所に集約
  • Google Cloudのサービスに関するログは基本的に自動で収集される
  • その上で動いているVM内部のログ（システムログなど）や、ミドルウェアのログ（Tomcatのログなど）は自動で収集できない。それらの収集にはツールのインストールが必要
    • Ops Agentというツールでログ収集でき、これはLoggingとMonitoring両方に対応している
    • 以前はLogging Agentというツールもあったが現在は非推奨
• リアルタイムで検索・フィルタ・分析
• ログベースメトリクスやアラートの設定も可能
  • 特定ログの出現数を数えてCloud Monitoringへ送信、など
• ログを長期保存するために転送する場合は BigQuery / Cloud Storage / Pub/Sub と連携できる

Cloud Audit Log（監査ログ）

Google Cloud の各種サービスに対する操作を記録するログ機能
プロジェクト / フォルダ / 組織 単位で自動的に収集され、構造化されたJSON形式で一貫したスキーマが提供される

おもに以下の種類がある

• Admin Activity Logs（管理アクティビティ監査ログ）
  • リソースの作成・変更・削除など「管理操作」に関するログ
  • デフォルトで有効になっている
• Data Access Logs（データアクセス監査ログ）
  • データの読み取りや書き込みなど、実データへのアクセス操作に関するログ
  • 明示的に有効化が必要な場合あり
• System Event Logs（システムイベント監査ログ）
  • Google Cloud のシステムによる内部イベント（ユーザーアクションなしで実行される操作）に関するログ
  • Compute Engine等で使用
    • VMの自動移行などを追跡するのに役立つ
• Policy Denied Logs（ポリシー拒否監査ログ）
  • IAM ポリシーによって拒否されたリクエスト（拒否イベント）を記録
  • セキュリティ監査向け
    • セキュリティとコンプライアンスの観点から、どのリクエストが拒否されたのか、なぜ拒否されたのかを把握できる

Cloud Monitoring

Google Cloudやアプリケーションのメトリクスを可視化・監視し、アラートも設定できる

• インフラ／アプリの状態をリアルタイムで可視化
• カスタムダッシュボード
  • ユーザーが重要と考える指標を、ひと目で分かるように視覚化する
• 異常検知やアラート通知
• AWSやオンプレミスなど、外部サービスの監視もサポートしている
  • 監視対象にエージェント（Monitoring Agent）をインストールする必要がある
  • エージェントをインストールせずとも、API経由で取得できるメトリクスもある
    • 1つ1つの環境にエージェントを導入する手間が省ける
    • ただし取得できる指標が限定される場合もある

Cloud Trace

アプリケーションのレイテンシ（遅延）やパフォーマンスのボトルネックを可視化・分析する分散トレーシングサービス

• 各リクエストのライフサイクル（どこで時間がかかったか）を視覚的に表示
  • WebアプリやAPIで特に有効
  • マイクロサービス間の通信（gRPC / HTTP）でのボトルネック分析に活躍
  • サービスの遅延原因がDBなのかAPIなのか通信なのかを特定したい場合に有効
• Stackdriver Trace SDK や OpenTelemetry に対応
  • Cloud Run / App Engine / GKE / Compute Engine 上のアプリケーションから利用可能

Cloud Debugger

本番環境で動作しているアプリケーションの状態をリアルタイムで観察できるデバッガ

• コードに「スナップショットポイント」を設定することで、その時点の変数値やスタックトレースを取得可能
• アプリケーションの動作には影響を与えない（ノンブロッキング）
• バグ再現が困難なケースや、本番でのみ発生する問題の調査に向いている
• App Engine / Cloud Run / GKE / Compute Engine など、Google Cloud上の一般的な実行環境で使用可能

Cloud Profiler

本番環境でのアプリケーションのCPU / メモリ使用状況を継続的に可視化・最適化するツール

• サンプリングベースのプロファイリング（オーバーヘッドは非常に低い）
• 高頻度で呼び出されている関数やメモリ消費の多い箇所を特定できる
• レイテンシではなくリソース使用量のボトルネックを解消する用途に向く
• スケーラビリティやコスト最適化のために、プロファイリングによる不要なリソース消費の削減が推奨される
• パフォーマンス改善を継続的に行う文化を支えるツールとして活用されることが望ましい

Cloud Error Reporting

アプリケーションの実行時エラー（例外）を自動的に検出・集計・通知するサービス

• 同じスタックトレースを持つエラーを自動でグルーピング
• 発生回数や発生時間、影響度をUIで確認可能
• 新規エラー発生時には通知が届くため、潜在的な問題の早期発見が可能
• サービス品質指標（SLO / SLA）を満たすために、エラーのトラッキングと通知は必須
• 特にサーバーレス環境では、Error Reporting を通じて運用状況を把握するのが推奨される

セキュリティ

Secret Manager

Google Cloud上の機密情報（シークレット）を集中管理するサービス

• Cloud Audit Logsと統合されているため、シークレットへのアクセスや変更などの監査トレイルを容易に実行できる
• Cloud Functionsと併用して、シークレットに有効期限を設けたり、定期的なローテーション（更新）を強制したりできる

Cloud Data Loss Prevention (DLP)

機密情報を含むデータを発見、保護する機能を提供する。

• データの中の機密情報に対しマスキングやトークン化などの不可逆な変換処理を行い、匿名化する
• 機密情報の代表例
  • PII (Personally Identifiable Information)
    • 個人を特定可能な情報
  • クレジットカード情報
    • PCI DSS (Payment Card Industry Data Security Standard) に準拠した対応が必要
    • トークン化やマスキングはその要件を満たすもの
• BigQuery, Cloud Storage, Datastore などのGoogle Cloudのストレージとは統合されている
• APIを通じて、Google Cloud外のデータに対して検査や変換を行うこともできる

災害対策（Disaster Recovery）

システム障害や自然災害などが発生した場合でも、サービスを継続させ、データの保全性を確保することにより、システム全体の耐障害性・高可用性を実現する

指標

• RPO（Recovery Point Objective: 復旧時点目標）
  • データをどの時点まで復旧するか（≒ どの時点のデータまでなら失ってもよいか）
  • e.g. 直近1時間まで失ってもよいのであれば、RPOは1時間
• RTO（Recovery **Time++ Objective: 復旧時間目標）
  • サービスをどれくらいの時間内に復旧するか

一般的に、RPOとRTOを短くすると、それだけコストは高くなる

DR戦略

Google CloudにおけるDR戦略のパターンは下記の通り

• バックアップ&リストア
  • 普段から定期的にデータをバックアップしておき、災害が発生したらリストアする
  • 復旧までに時間がかかり、失われるデータも多いが、コストは最も低い
• パイロットライト（コールドスタンバイ）
  • 本番環境と同じアーキテクチャだが必要最低限のリソース（= 構成のスケルトン）だけを持つスタンバイ環境を常時稼働しておく
    • スタンバイ環境は別のリージョンに構築する
    • ここでいう必要最低限のリソースは、主に永続化層に留まるケースが多い
  • 災害が発生したら、本番環境と切り替えてスケールアウト/スケールアップさせる
• ウォームスタンバイ
  • パイロットライトに加えて、アプリケーション層を含む主要なサービスを縮小構成でスタンバイ環境に構築しておく
• アクティブ-アクティブ構成（ホットスタンバイ / マルチサイト）
  • 本番環境と同じスペックをスタンバイ環境でも常に同時稼働させておく
  • 災害が発生しても即時にサービス復旧できるがコストも最も高い

下にいけばいくほどコストは高くなるが、RTO/RPOを短くすることが出来る

アーキテクチャ戦略

マルチゾーン / マルチリージョン構成

• Compute Engine, GKE（Google Kubernetes Engine）などはリージョン単位の管理が基本
• 高可用性（HA）を担保するためには、複数ゾーンに分散配置し、ゾーン障害に強くする
• より広範な障害（地震など）に備えるには、複数リージョンにまたがって冗長化する

ストレージとデータ保全

• Cloud Storage：マルチリージョン、リージョン、デュアルリージョンのクラス選択が可能。DR目的にはマルチリージョンやデュアルリージョンが推奨される
• Cloud SQL / Spanner / Bigtable：リージョン内レプリケーションやマルチリージョン構成に対応。Spannerはグローバル分散型DBとして特にDRに強い
• バックアップとリストア：Cloud SQLなど多くのマネージドサービスは自動バックアップとスナップショット機能を提供

ネットワークとアクセス

• Global Load Balancing：トラフィックをヘルスチェックに基づき健全なリージョンへ振り分け。自動フェイルオーバーを実現
• Cloud DNS：「通常はプライマリの環境に接続し、障害時には自動でセカンダリ環境へ切り替える（フェイルオーバーする）」という仕組みをDNSレベルで実現できる
• CDNのキャッシュにより一時的にサービスを継続することも可能