Zenn
🐈

Google Cloud Professional Cloud Developer を（再）取得したい

に公開
Google Cloud
Google Cloud
certification
clouddeveloper
tech

はじめに

以前取得した「Professional Cloud Developer」認定資格の有効期限が切れてしまったため、再取得を目指しています。本記事は、Google が提示した試験範囲に沿って、理解を深めるために調査・整理した知識を体系的にまとめました。

Professional Cloud Developerの試験範囲

公式ドキュメントに記載されている試験範囲は以下の通りです（2025年5月時点）。

  1. スケーラビリティ、可用性、信頼性に優れたクラウドネイティブ アプリケーションの設計
  2. アプリケーションのビルドとテスト
  3. アプリケーションのデプロイ
  4. アプリケーションと Google Cloud サービスの統合

本記事は、Google Cloud 公式の Professional Cloud Developer 認定試験ガイド に基づく4つの主要セクションに沿って構成しています。

試験の申し込み方法

https://zenn.dev/takaha4k/articles/howto-regist-google-cloud-cert

第1章: スケーラビリティ、可用性、信頼性に優れたクラウドネイティブ アプリケーションの設計

抑えておくポイント

Kubernetesの基本構成要素

  • Deployment：ステートレスなアプリケーションを複数のPodで管理するためのリソース。ローリングアップデート (spec.strategy.rollingUpdate で maxSurge, maxUnavailable を制御) やロールバック機能を提供。
  • StatefulSet：ステートフルなアプリケーション（例：DBなど）を管理する。Pod名が固定され、順序性や永続ボリュームのマッピングが保証される（Headless Service, PersistentVolumeClaim テンプレートとの連携が必要）。
  • Service：Pod群への安定した単一のアクセスポイントを提供。
  • ConfigMap：設定データ（環境変数、設定ファイルなど）をキーバリューペアとして保存し、Podからマウントまたは環境変数として利用可能にする。

セキュリティ設計

  • Workload Identity：GKE 上の Kubernetes サービスアカウント (KSA) に Google サービスアカウント (GSA) の権限を付与する仕組み。Pod は KSA を通じて、GCP リソースへ安全にアクセスできる。
  • NetworkPolicy：Kubernetes クラスタ内で Pod 間の通信ルールを定義するファイアウォール。Namespace スコープで適用され、意図しない通信を拒否するよう設定する。
  • mTLS（相互TLS）：サービスメッシュ (Istio や Anthos Service Mesh など) を利用して、Pod 間の通信を暗号化し、双方のサービスが互いを認証する仕組み。
  • 限定公開 Google アクセス（Private Google Access）：外部IPアドレスを持たないVMインスタンスやGKEノードから、Google API およびサービス (Cloud Storage, BigQuery など) へプライベートネットワーク経由でアクセスできるようにするVPCネットワークの機能。

スケーラビリティ設計

  • 水平スケーリング (Horizontal Pod Autoscaler - HPA)：CPU 使用率やカスタムメトリクスに基づいて、Pod のレプリカ数を自動的に増減させる。
  • 垂直スケーリング (Vertical Pod Autoscaler - VPA)：Pod の CPU やメモリの要求 (requests) と上限 (limits) を、自動調整する。

チーム分離と権限制御

  • Namespace：Kubernetes クラスタ内のリソースを論理的に分離する単位。チームやプロジェクトごとにリソース、ポリシー (NetworkPolicyなど)、権限 (RBAC) を管理でき、リソースクォータの設定も可能。
  • RBAC（Role-Based Access Control）：ユーザー、グループ、サービスアカウントに対して、Kubernetes API リソースへの操作権限 (Role, ClusterRole) を Namespace スコープまたはクラスタスコープで割り当てる (RoleBinding, ClusterRoleBinding) ことで、制御する。

IAMと認証設計

  • 最小権限の原則（Least Privilege）：ユーザーやサービスアカウントには、タスク実行に必要な最小限の権限のみを付与し、セキュリティリスクを低減する。
  • OAuth / JWT / サービスアカウント：
    • OAuth 2.0: ユーザーの同意に基づいて、第三者アプリケーションに特定のリソースへの限定的なアクセス権を付与するための認可フレームワーク。
    • JWT (JSON Web Token): 認証と認可の情報をコンパクトに表現するためのもの。主にAPI認証などで利用される。
    • サービスアカウント: アプリケーションやVMインスタンスなどが、人手を介さずに Google Cloud API を認証するために使用する特別なアカウント。

秘匿情報の管理

  • Secret Manager：APIキー、パスワード、証明書などの秘匿情報を安全に保存、管理、バージョン管理し、アクセス制御できるフルマネージドサービス。監査ログとの連携も可能。
  • Cloud KMS (Key Management Service)：暗号鍵の作成、管理、ローテーションを行うフルマネージドサービス。保存データの暗号化 (CMEK: Customer-Managed Encryption Keys) や、より高度なセキュリティを実現するエンベロープ暗号化の実装などに利用される。

Cloud Storageの運用とセキュリティ

  • 保持ポリシー（Retention Policy）：バケット内のオブジェクトが指定期間削除・上書きされないようにロックする機能。コンプライアンス要件（例: WORM - Write Once Read Many）への対応に有効。
  • ライフサイクルポリシー：オブジェクトの経過日数、ストレージクラス、バージョン数などに基づいて、オブジェクトのストレージクラス変更 (例: Standard から Nearline へ) や削除を自動化。コスト最適化やデータ管理の効率化に貢献。
  • Cloud Storage FUSE：Cloud Storage バケットをローカルファイルシステムのようにマウントできるオープンソースドライバ。VM や GKE Pod から既存のファイルI/Oでアクセス可能になるが、パフォーマンス特性（レイテンシ、スループット、一貫性）はローカルディスクと異なるため注意が必要。

理解チェック

Q1: Deployment と StatefulSet の主な違いと、それぞれの適切なユースケースを説明してください。

Deployment はステートレスアプリケーションに適しており、Pod は交換可能で順序や永続的なIDを持ちません。ローリングアップデートやロールバックが容易です。
StatefulSet はステートフルアプリケーション (例: データベース、メッセージキュー) に適しており、Pod には安定した永続的な識別子 (例: pod-0, pod-1) と永続ストレージが紐付けられます。Pod の順序性 (起動・停止・スケール) が保証されます。

Q2: GKE クラスタ内で Pod 同士が安全に通信するために使える、主なセキュリティの仕組みを2つ教えてください。

  1. NetworkPolicy: Kubernetes ネイティブのリソースで、Pod レベルのファイアウォールルールを定義し、意図しないネットワークアクセスを制限します。
  2. mTLS (相互TLS): Istio や Anthos Service Mesh などのサービスメッシュを導入することで、Pod 間の通信を暗号化し、相互認証を行います。これにより、より高度なセキュリティが実現できます。

Q3: Workload Identity を利用する主な利点は何ですか？

Kubernetes Pod が Google Cloud API にアクセスする際に、サービスアカウントキー (JSON ファイル) を Pod 内に保存・管理する必要がなくなる点です。これにより、キー漏洩のリスクを削減し、セキュリティを向上させることができます。Kubernetes サービスアカウントと Google サービスアカウントをマッピングすることで、Pod は安全に認証を行えます。

Q4: 「限定公開 Google アクセス」はどのようなシーンで利用され、どのようなセキュリティ上のメリットがありますか？

VPC ネットワーク内にあり、外部 IP アドレスを持たない VM インスタンスや GKE ノードから、Google の API やサービス (例: Cloud Storage, BigQuery, Pub/Sub) へインターネットを経由せずにアクセスしたい場合に利用します。
セキュリティ上のメリット:

  • トラフィックが Google のプライベートネットワーク内にとどまるため、インターネットへの露出を避けることができます。
  • 外部IPアドレスが不要なため、攻撃対象領域を削減できます。
  • VPC Service Controls と組み合わせることで、データ漏洩リスクをさらに低減できます。

Q5: Cloud Storage でデータのコンプライアンス要件 (例: 特定期間のデータ保持義務) を満たすには、どの機能を利用しますか？

バケットに保持ポリシー (Retention Policy) を設定します。これにより、指定した期間、オブジェクトの削除や上書きが禁止され、データの不変性が保証されます。これは監査対応や規制遵守に役立ちます。

Q6: Cloud Storage FUSE を利用する際の利点と、特に注意すべきパフォーマンス上の考慮事項は何ですか？

利点: Cloud Storage バケットを既存のアプリケーションからファイルシステムとして容易に扱えるようになります。
注意点: ローカルディスクと比較してレイテンシが大きく、スループットもネットワーク帯域に依存します。頻繁な小さいファイルの読み書きや、低レイテンシを要求するワークロードには不向きな場合があります。キャッシュ設定やアクセスパターンを工夫する必要があります。

Q7: GKE で Namespace を利用する主な利点を3つ挙げ、それぞれの利点がどのような課題を解決するか説明してください。

  • リソースの分離: 複数のチームやプロジェクトが同じクラスタを共有する際に、名前空間によってリソース（Pod、Service、Deploymentなど）のスコープを論理的に分割できます。これにより、命名の衝突を防ぎ、管理単位を明確にします。
  • アクセスコントロール (RBACとの連携): Namespace ごとに Role や RoleBinding を設定することで、ユーザーやグループに対して特定のリソースへの操作権限を細かく制御できます。チームごとの権限分離を実現します。
  • リソースクォータの適用: Namespace ごとに CPU、メモリ、ストレージなどのリソース使用量の上限 (ResourceQuota) を設定できます。これにより、特定のチームやアプリケーションによるリソースの使いすぎを防ぎ、クラスタ全体の安定性を保ちます。

Q8: StatefulSet で Pod の永続性と安定したネットワーク識別子を保証するために重要な関連リソースと、それらがどのように機能するか説明してください。

  • Headless Service: StatefulSet に関連付けられる Headless Service は、個々の Pod に対して安定したDNS名 (例: <pod-name>.<headless-service-name>.<namespace>.svc.cluster.local) を提供します。これにより、Pod は再起動や再スケジューリング後も同じネットワーク識別子でアクセス可能になります。
  • PersistentVolumeClaim (PVC) テンプレート (volumeClaimTemplates): StatefulSet の定義内で PVC テンプレートを指定することで、各 Pod に対して個別の永続ボリュームが動的にプロビジョニング（または既存のボリュームにバインド）されます。Pod は再起動後も同じ永続ストレージにアクセスできます。
  • 順序性のある安定した識別子: Pod 名 (例: web-0, web-1) やホスト名が順序付けられ、予測可能です。

Q9: Cloud KMS でエンベロープ暗号化を行う際、データ暗号化キー (DEK) とキー暗号化キー (KEK) はそれぞれどのように生成・管理され、なぜこの方式が推奨されるのですか？

  • データ暗号化キー (DEK): 実際にデータを暗号化・復号するためのキーです。通常、アプリケーション側で生成されるか、Cloud KMS を利用して生成されます。DEK は暗号化されたデータと共に保存されることが多いですが、DEK 自体も保護する必要があります。
  • キー暗号化キー (KEK): DEK を暗号化するためのキーです。KEK は Cloud KMS 内で安全に管理されます (例: HSM 内)。
  • 推奨理由:
    • キー管理の簡素化: 大量のデータを暗号化する場合、多数の DEK を管理する必要がありますが、KEK は Cloud KMS で一元的に強力に保護されるため、管理対象の機密性の高いキーが少なくなります。
    • キーローテーションの容易性: KEK をローテーションすることで、その KEK で暗号化された全ての DEK の実質的な暗号強度を高めることができます。
    • パフォーマンス: 実際のデータ暗号化・復号は DEK を使用してアプリケーションに近い場所で行われるため、都度 KMS にアクセスするよりもパフォーマンスが良い場合があります。

Q10: マイクロサービスアーキテクチャを採用するアプリケーションをGKEにデプロイする際、サービス間の通信におけるレイテンシと信頼性を確保するための設計上の考慮事項を3つ挙げてください。

  1. サービスディスカバリと負荷分散: Kubernetes の Service リソースや、より高度な機能を提供するサービスメッシュ (Istio/ASM) を利用して、動的に変化するマイクロサービスのインスタンスへのリクエストを適切に負荷分散します。
  2. リトライとサーキットブレーカー: 一時的なネットワークの問題やサービスの過負荷に備え、クライアント側にリトライ機構 (指数バックオフ) やサーキットブレーカーパターンを実装します。これにより、障害の連鎖を防ぎ、システムの回復力を高めます。
  3. 非同期処理の活用: 可能な限り、Pub/Sub や Cloud Tasks などのメッセージングサービスを利用した非同期処理によって、サービス間の直接的な依存関係を減らし、システム全体の応答性と耐障害性を向上させます。

※ 参考文献

第2章: アプリケーションのビルドとテスト

抑えておくポイント

開発ツールの活用

  • Cloud Shell
    ブラウザからアクセス可能な、gcloud CLI、kubectl、Docker、Terraform などの開発ツールがプリインストールされた一時的な Compute Engine VM。認証・認可が設定済みで、手軽に GCP 操作や開発を開始できる。
  • Cloud Code
    VS Code や IntelliJ などの拡張機能。Kubernetes や Cloud Run アプリケーションの開発、デプロイ、デバッグを IDE 内で効率的に行うためのサポート (スキャフォールディング、ローカル実行・デバッグ、ログ表示など) を提供。

CI/CD

  • Cloud Build
    ソースコードの取得、ビルド、テスト、アーティファクトの保存、デプロイまでを自動化するフルマネージドな CI/CD プラットフォーム。ビルドステップは cloudbuild.yaml で定義し、コンテナベースで実行される。Secret Manager と連携することで、認証情報を安全に取り扱うことができます。
  • ビルド構成ファイル（cloudbuild.yaml）
    Cloud Build のビルドプロセスを定義する YAML ファイル。steps に各ビルドタスク (ビルダーコンテナと引数) を記述し、順次または並列実行が可能。ビルドトリガーと連携して自動実行される。

セキュアなビルドパイプラインの構築

  • Artifact Registry
    コンテナイメージや言語パッケージ (Maven, npm など) といったビルドアーティファクトを一元的に管理するフルマネージドサービス。リポジトリモード (標準、リモート、仮想) を活用した依存関係管理や、脆弱性スキャン機能、IAM によるアクセス制御を提供。
  • Binary Authorization
    GKE クラスタへのデプロイ時に、信頼できる機関によって署名されたコンテナイメージのみを許可するセキュリティポリシーを強制する仕組み。ソフトウェアサプライチェーンのセキュリティを強化し、SLSA (Supply-chain Levels for Software Artifacts) に貢献。

テスト戦略

  • ローカルテスト環境 (エミュレータ)
    Pub/Sub Emulator, Firestore Emulator などを使用して、ローカル開発環境で単体テストや統合テストを迅速に実行。
  • 負荷テスト（Load Testing）
    Locust などのツールを GKE 上で実行し、スケーラブルな負荷テスト環境を構築。アプリケーションのパフォーマンスや耐久性を検証。
  • CI環境での自動テスト (ユニット、インテグレーション、E2E)
    Cloud Build パイプラインにユニットテスト、インテグレーションテスト、静的解析などのステップを組み込み、コード変更のたびに自動実行することで、品質を早期に担保し、迅速なフィードバックループを実現できる。

理解チェック

Q1: Cloud Build を使用して CI/CD パイプラインを構築する主なメリットは何ですか？

フルマネージドサービスであるためインフラ管理が不要で、ビルド環境の一貫性が保たれます。cloudbuild.yaml でビルドプロセスを宣言的に定義でき、GCP の他のサービス (Artifact Registry, Binary Authorization, Cloud Deploy など) との連携が容易です。また、様々なビルドトリガー (リポジトリへの push, pull request など) に対応し、スケーラブルなビルドが可能です。

Q2: cloudbuild.yaml の基本的な構造と、主要な構成要素について説明してください。

基本的な構造は、一連のビルドステップを定義する steps フィールドと、ビルド結果のイメージをプッシュする先を指定する images フィールド (Artifact Registry の場合) などから構成されます。各ステップでは、実行するビルダーイメージ (name)、引数 (args)、環境変数 (env) などを指定します。ステップはデフォルトで順次実行されますが、waitFor を使って依存関係や並列実行を制御できます。

Q3: Artifact Registry での脆弱性スキャンはどのように機能し、どのような情報を提供しますか？

Artifact Registry は、保存されているコンテナイメージに対して自動的に脆弱性スキャンを実行します (Container Analysis API を利用)。このスキャンは、イメージ内のOSパッケージやアプリケーションライブラリに含まれる既知の脆弱性 (CVE) を検出し、その深刻度や修正可能性に関する情報を提供します。これにより、デプロイ前にセキュリティリスクを特定できます。

Q4: Binary Authorization を導入する主な目的と、その仕組みの概要を説明してください。

目的: GKE クラスタにデプロイされるコンテナイメージが、信頼されたソースからビルドされ、承認プロセスを経たものであることを保証し、不正なイメージや脆弱なイメージのデプロイを防ぐことです。
仕組み: デプロイ時に、ポリシーで定義された証明者 (attestors) によってイメージにデジタル署名 (attestation) がされているかを検証します。署名がない、または検証に失敗したイメージのデプロイはブロックされます。

Q5: Cloud Run functions Emulator はどのような目的で使用されますか？

ローカル開発環境で Cloud Run Functions の関数をデプロイせずにテスト・デバッグするために使用されます。これにより、実際のクラウド環境へのデプロイを待つことなく、迅速に関数のロジックやHTTPトリガー、イベントトリガー (Pub/Sub Emulator などと連携) の動作を確認できます。

Q6: Locust を使用した負荷テストは、どのような特徴がありますか？

Python でテストシナリオを記述でき、ユーザーの行動をコードでシミュレートします。分散実行に対応しており、多数の同時ユーザーからのリクエストを生成して、大規模な負荷テストが可能です。Web UI を通じてリアルタイムにテスト状況を監視できます。GKE 上で実行することで、負荷生成能力を容易にスケールさせることができます。

Q7: Cloud Build でビルド時に外部のプライベートリポジトリ (例: Private GitHub Repository) からソースコードを取得したり、非公開のライブラリ (例: Private npm package) を利用したりする場合、認証情報を安全に扱うための一般的な方法を2つ説明してください。

  1. SSHキーの利用 (ソースコード取得): Cloud Build のビルドステップ内で SSH キーを生成または Secret Manager から取得し、known_hosts の設定と合わせて SSH 経由でプライベートリポジトリにアクセスします。SSH キー自体は Secret Manager に保存し、ビルド時に適切な権限でアクセスします。
  2. アクセストークンの利用 (ライブラリ取得): 非公開ライブラリリポジトリ (例: npm private registry, Artifactory) のアクセストークンを Secret Manager に保存します。ビルドステップ内でそのトークンを取得し、ライブラリ管理ツールの設定ファイル (例: .npmrc, .m2/settings.xml) に一時的に設定して認証を行います。ビルドログにトークンが直接出力されないように注意が必要です。

Q8: Artifact Registry のリポジトリモードについて、「標準 (Standard)」、「リモート (Remote)」、「仮想 (Virtual)」のそれぞれの特徴と主なユースケースを説明してください。

  • 標準リポジトリ:
    • 特徴: ユーザーが直接アーティファクト (コンテナイメージ、言語パッケージなど) をプッシュしたりプルしたりする通常のリポジトリです。
    • ユースケース: 組織内でビルドした独自のアーティファクトを保存・管理する。
  • リモートリポジトリ:
    • 特徴: パブリックな外部リポジトリ (例: Docker Hub, Maven Central, npmjs.org) のプロキシおよびキャッシュとして機能します。初回アクセス時にアーティファクトをキャッシュし、以降はキャッシュから提供します。
    • ユースケース: 外部リポジトリへの依存を管理し、ビルドの信頼性と速度を向上させる。ネットワーク障害時にもキャッシュから利用可能。
  • 仮想リポジトリ:
    • 特徴: 複数の標準リポジトリまたはリモートリポジトリを単一のエンドポイントでグループ化します。クライアントは仮想リポジトリを通じて、集約されたリポジトリ群からアーティファクトをプルできます。アップストリームの優先順位も設定可能。
    • ユースケース: 開発者が複数のリポジトリを意識することなく、単一のURLで必要なアーティファクトにアクセスできるようにする。内部リポジトリと外部プロキシを透過的に扱う。

Q9: SLSA (Supply chain Levels for Software Artifacts) の観点から、Cloud Build と Binary Authorization はソフトウェアサプライチェーンのセキュリティをどのように強化しますか？具体的にそれぞれ説明してください。

  • Cloud Build:
    • ビルドプロセスの自動化と再現性: cloudbuild.yaml による宣言的なビルド定義により、手動操作を排除し、一貫性のある再現可能なビルド環境を提供します (SLSAレベル1-2)。
    • ビルド来歴 (Provenance) の生成: ビルドプロセスに関するメタデータ (ソースのコミットハッシュ、使用したビルダー、ビルドステップなど) を自動的に生成・保存できます。これはソフトウェアの出所を証明し、改ざん検知に役立ちます (SLSAレベル2-3)。
    • 隔離された一時的なビルド環境: 各ビルドは独立した環境で実行されるため、ビルド間の影響を防ぎます。
  • Binary Authorization:
    • デプロイ時のポリシー強制: 信頼できるビルドプロセス (例: Cloud Build で特定の来歴情報を持つビルド) を経て、かつ特定の証明者によって署名されたコンテナイメージのみデプロイを許可することで、未承認のコードや改ざんされたコードの本番環境への混入を防ぎます (SLSAレベル3-4)。
    • 証明 (Attestation) の活用: ビルドパイプラインの特定のチェックポイント (例:脆弱性スキャンクリア、手動承認) で証明を作成し、デプロイ時にこれらの証明を検証します。

Q10: アプリケーションのテスト戦略において、ユニットテスト、インテグレーションテスト、エンドツーエンド (E2E) テストのそれぞれの主な目的と、CI/CD パイプラインでこれらを効果的に配置するためのアプローチを説明してください。

  • ユニットテスト:
    • 目的: 個々のコンポーネントや関数が期待通りに動作することを確認する。バグを早期に発見し、リファクタリングを容易にする。
    • 配置: コミットごと、またはプルリクエスト時に実行。フィードバックが最も速い。
  • インテグレーションテスト:
    • 目的: 複数のコンポーネントやサービスが連携して正しく動作することを確認する。モジュール間のインターフェースやデータのやり取りを検証。
    • 配置: ユニットテストの後、メインブランチへのマージ前や、ステージング環境へのデプロイ後に実行。
  • エンドツーエンド (E2E) テスト:
    • 目的: ユーザーの視点からシステム全体のフローが期待通りに動作することを確認する。実際の環境に近い状態でテストする。
    • 配置: ステージング環境や、場合によっては本番環境（一部トラフィックなど）で、リリース前に実行。実行時間が長くなる傾向があるため、頻度は他のテストより低いことが多い。

※ 参考文献

第3章: アプリケーションのデプロイ

抑えておくポイント

デプロイ戦略の理解と選択

  • インプレースデプロイ (In-place deployment)
    既存のアプリケーションインスタンスを停止し、新しいバージョンで上書きする方式。シンプルだが、デプロイ中はダウンタイムが発生するリスクがある。
  • ローリングアップデート (Rolling update)
    インスタンスの一部を新しいバージョンに順次置き換えていく方式。ダウンタイムを最小限に抑えつつデプロイ可能。Kubernetes の Deployment などで標準的にサポートされ、maxSurge や maxUnavailable といったパラメータで挙動を制御可能。
  • カナリアデプロイ (Canary deployment)
    一部のユーザーやトラフィック (例: 1%) のみを新バージョンにルーティングし、問題がないことを確認しながら段階的にトラフィックの割合を増やしていく手法。リスクを低減し、早期に問題を発見できる。
  • Blue-Green デプロイ (Blue-Green deployment)
    現在の本番環境 (Blue) とは別に、新バージョンの環境 (Green) を完全に構築し、テスト後にロードバランサ等でトラフィックを一気に切り替える方式。迅速なロールバックが可能だが、リソースが一時的に2倍必要になる。データベーススキーマ変更など、ステートフルな変更への対応が課題となることがある。

Google Cloud におけるトラフィック分割・段階的リリース

  • Cloud Run
    リビジョン (バージョン) ごとにトラフィックをパーセンテージで分割可能。GUI や gcloud コマンドで容易に設定でき、カナリアリリースや Blue-Green デプロイ戦略をサポート。
  • App Engine
    バージョン間でトラフィックを分割 (splitting) または移行 (migrating) 可能。IPアドレス、Cookie、ランダムな割合でトラフィックをルーティングできる。トラフィック移行はウォームアップを考慮した段階的な切り替えが可能。
  • GKE + Istio / Anthos Service Mesh (ASM)
    サービスメッシュを利用することで、リクエストヘッダー、パス、ユーザーエージェントなど、より高度な条件に基づいたトラフィックルーティング (VirtualService, DestinationRule を使用) が可能。カナリア、A/Bテスト、トラフィックミラーリングなどを柔軟に実現。

テスト戦略と検証手法

  • A/Bテスト
    2つ以上の異なるバージョン (AとB) をユーザー群にランダムに提示し、どちらのバージョンがより良い成果 (例: コンバージョン率、エンゲージメント) を示すかを統計的に比較・検証する手法。
  • シャドーテスト (トラフィックミラーリング / Shadow testing)
    本番トラフィックの一部または全部を新バージョンにコピーして送信するが、新バージョンからのレスポンスはユーザーには返さない。本番同等の負荷で新バージョンの動作やパフォーマンスを安全に検証できる。
  • カナリアテスト
    カナリアデプロイと連携し、新バージョンに割り当てられた一部のトラフィックに対してエラー率、レイテンシ、リソース使用率などの主要メトリクスを重点的に監視し、問題があれば迅速にロールバックする。

API公開と互換性管理

  • Cloud Endpoints
    OpenAPI や gRPC を用いて API を設計、デプロイ、管理するためのプラットフォーム。ESP (Extensible Service Proxy) または ESPv2 を利用し、認証 (APIキー, JWT)、モニタリング、ロギング、レート制限などの機能を提供。
  • APIのバージョニング
    API に変更を加える際に、既存クライアントとの互換性を維持するための戦略。URL パス (/v1/, /v2/)、リクエストヘッダー、クエリパラメータなどでバージョンを指定。破壊的変更を避け、後方互換性を意識した設計が重要。
  • APIゲートウェイの導入
    複数のバックエンドサービスへの単一のエントリポイントを提供し、認証、認可、レート制限、キャッシュ、リクエスト変換、モニタリングなどの共通機能を一元的に管理するコンポーネント。(Google Cloud では API Gateway サービスや Cloud Endpoints が該当)

理解チェック

Q1: ローリングアップデートとカナリアデプロイの主な違いは何ですか？

ローリングアップデートは、古いバージョンのインスタンスを新しいバージョンのインスタンスで自動的に順次置き換えていく方式です。通常、全インスタンスが置き換わるまでプロセスが継続します。
カナリアデプロイは、まずごく一部のトラフィック（またはインスタンス）のみを新バージョンに向け、その動作を監視・評価します。問題がなければ段階的にトラフィックの割合を増やしていき、最終的に全トラフィックを新バージョンに切り替えます。より慎重で、リスクをコントロールしやすいデプロイ戦略です。

Q2: Cloud Run や App Engine でトラフィック分割機能は、どのようなデプロイ戦略に活用できますか？

主に以下の戦略に活用できます。

  • カナリアリリース: 新しいリビジョン/バージョンに少量のトラフィック (例: 5%) を割り当て、動作を確認しながら徐々に割合を増やしていく。
  • Blue-Green デプロイ: 新しいリビジョン/バージョンにトラフィックを0%でデプロイし、テスト後に100%切り替えることで実現可能。
  • A/B テスト: 複数のリビジョン/バージョンにトラフィックを分割し、ユーザーの反応やパフォーマンスを比較する。

Q3: Blue-Green デプロイの主な利点と、考慮すべき注意点は何ですか？

利点:

  • 迅速なロールバック: 問題が発生した場合、トラフィックを即座に旧バージョン (Blue 環境) に戻せるため、ダウンタイムを最小限に抑えられます。
  • デプロイ前の完全なテスト: 新バージョン (Green 環境) を本番トラフィックから隔離した状態で十分にテストできます。
    注意点:
  • リソースコスト: 一時的に本番環境の2倍のリソースが必要になるため、コストが増加します。
  • 状態の同期: データベーススキーマの変更やステートフルなアプリケーションの場合、Blue 環境と Green 環境間でのデータ同期や互換性維持に注意が必要です。

Q4: シャドーテスト (トラフィックミラーリング) は、どのような目的で実施され、どのようなデータが得られますか？

目的: 新しいバージョンのアプリケーションを、ユーザーに影響を与えることなく、実際の本番トラフィックでテストすることです。
得られるデータ: 新バージョンのパフォーマンス特性 (レイテンシ、スループット)、エラー発生率、リソース消費量などを、本番相当の負荷状況下で評価できます。これにより、本番リリース前に潜在的な問題を発見し、修正することが可能になります。新バージョンからのレスポンスはユーザーには返却されません。

Q5: Cloud Endpoints の主な役割と、提供する主要な機能について説明してください。

役割: API の開発、デプロイ、管理、保護を支援するプラットフォームです。
主要な機能:

  • OpenAPI や gRPC に基づく API の定義とデプロイ。
  • ESP (Extensible Service Proxy) または ESPv2 を介したリクエスト処理。
  • 認証 (API キー、Firebase Auth、Auth0、Google ID トークンなど)。
  • モニタリング (トラフィック、エラー率、レイテンシなど Cloud Monitoring と連携)。
  • ロギング (Cloud Logging と連携)。
  • レート制限 (割り当て)。
  • API キーの検証と管理。

Q6: GKE で Deployment リソースを使用してローリングアップデートを行う際に、アプリケーションの可用性を最大限に高めつつ安全にデプロイするために、マニフェストファイル (deployment.yaml) で考慮すべき重要な設定項目 (spec.strategy.rollingUpdate 以下など) を3つ挙げ、その役割を説明してください。

  1. maxUnavailable: ローリングアップデート中に利用不可であっても許容される Pod の最大数または割合。例えば 25% と設定すると、全レプリカの25%が利用不可になるまではアップデートが進められます。これを適切に設定することで、サービス提供に必要な最低限の Pod 数を維持します。
  2. maxSurge: ローリングアップデート中に、望ましいレプリカ数を超えて一時的に作成されてもよい Pod の最大数または割合。例えば 25% と設定すると、一時的にレプリカ数が125%になることを許容します。これにより、新しい Pod の準備ができてから古い Pod を停止することで、切り替え時の処理能力低下を防ぎます。
  3. readinessProbe と livenessProbe: Pod の readinessProbe が成功するまで新しい Pod にトラフィックがルーティングされないようにし、livenessProbe で Pod の健全性を継続的に監視します。これにより、準備ができていない Pod や不健康な Pod がサービスを提供することを防ぎ、アップデートの安定性を高めます。

Q7: App Engine のトラフィック移行 (migrating traffic) とトラフィック分割 (splitting traffic) の主な違いと、それぞれの機能が適している具体的なユースケースを説明してください。

  • トラフィック分割 (Splitting traffic):
    • 違い: 複数のバージョンに対して、指定した割合で同時にトラフィックをルーティングします。例えば、バージョンAに90%、バージョンBに10%といった設定が可能です。
    • ユースケース: カナリアリリース (新バージョンに少量のトラフィックを流してテスト)、A/Bテスト (異なるバージョンをユーザーグループに提示して効果を比較)。
  • トラフィック移行 (Migrating traffic):
    • 違い: あるバージョンから別のバージョンへ、徐々にトラフィックを移行します。新しいバージョンに問題がなければ自動的に移行が進み、問題があれば停止またはロールバックできます (ウォームアップリクエストを送信しながら)。
    • ユースケース: 新しいバージョンへの段階的なロールアウト。特に、新バージョンがリクエストを処理するためにウォームアップが必要な場合や、急激なトラフィック増を避けたい場合に有効。デフォルトサービスなどでバージョンを切り替える際にも利用。

Q8: Istio や Anthos Service Mesh (ASM) を使用してカナリアデプロイを行う際に、トラフィックのルーティングを制御する主要な Kubernetes カスタムリソース (CRD) は何ですか？また、それらはどのように連携して機能しますか？

  • VirtualService: 特定のホスト名やゲートウェイに向けられたトラフィックを、どのようにルーティングするかを定義します。HTTPヘッダー、URIパス、送信元ラベルなどに基づいて、トラフィックを異なるサービスバージョン (サブセット) に振り分けるルールを設定できます。カナリアデプロイでは、ここでトラフィックの割合を指定します。
  • DestinationRule: VirtualService によってルーティングされたトラフィックが、実際にどの Pod 群 (サービスバージョン) に送られるかを定義します。これには、サービスのサブセット (例: v1, v2) の定義や、負荷分散ポリシー、TLS設定などが含まれます。
  • 連携: VirtualService は「どこからのトラフィックを、どのように分けるか」を定義し、DestinationRule は「分けられたトラフィックの宛先となる具体的なPod群は何か、そこにどう送るか」を定義します。これらが連携することで、柔軟なトラフィック管理が実現されます。

Q9: API の破壊的変更 (breaking change) を避けるために、バージョニング以外に考慮すべきAPI設計上の原則やプラクティスを3つ挙げてください。

  1. 後方互換性のある変更を心がける:
    • 新しいフィールドを追加する場合、既存のクライアントがそれを無視できるようにする (必須フィールドにしない)。
    • レスポンスからフィールドを削除せず、非推奨 (deprecated) としてマークし、将来のバージョンで削除することを予告する。
    • 列挙型 (enum) に新しい値を追加する場合、古いクライアントが未知の値を適切に処理できるようにする。
  2. 拡張性を考慮した設計:
    • リクエスト/レスポンスのペイロードに、将来の拡張のための予備のフィールドや構造 (例: extensions オブジェクト) を設けておく。
    • HTTPヘッダーを活用して、オプションの機能やメタデータをやり取りする。
  3. 明確なドキュメントとコミュニケーション:
    • API の変更履歴、非推奨となる機能、将来の変更計画などをAPIドキュメントに明記し、利用者に早期に通知する。
    • 変更に対するフィードバックチャネルを設け、利用者との対話を促す。

※ 参考文献

第4章: アプリケーションと Google Cloud サービスの統合

抑えておくポイント

イベントドリブンアーキテクチャ

  • Eventarc
    Google Cloud サービス (Cloud Storage, Pub/Sub, Audit Logs など) からのイベントをトリガーとして、Cloud Run, Cloud Run functions, GKE, Workflows などのターゲットにイベントをルーティングするフルマネージドなイベントバスサービス。CloudEvents 仕様に準拠し、フィルタリング機能も提供。
  • Cloud Pub/Sub
    スケーラブルで信頼性の高い非同期メッセージングサービス。疎結合なシステム連携やイベント駆動型アーキテクチャの基盤となる。デッドレターキュー (DLQ) やリトライポリシーによる耐障害性の確保が重要。
  • Cloud Tasks
    HTTP エンドポイントに対して非同期タスクを実行するためのフルマネージドサービス。タスクのキューイング、順序制御、リトライポリシー、レート制御、スケジューリングなどが可能。長時間実行される可能性のある処理や、外部サービスへの確実なリクエスト送信に適している。
  • Cloud Workflows
    複数の Google Cloud サービス (Functions, Cloud Run API, Pub/Sub など) や外部 HTTP API の呼び出しを、サーバーレスなワークフローとして順序付け、自動化するサービス。YAML または JSON による宣言的な定義で、エラー処理、待機処理、並列処理などの組み込み機能が豊富。

サーバーレス / コンテナサービスとの統合

  • Cloud Run functions / Cloud Run
    • Cloud Run functions: イベント駆動型の短いコードスニペット (関数) を実行するサーバーレスプラットフォーム。HTTP リクエストや Pub/Sub メッセージ、Cloud Storage の変更などをトリガーに関数を実行。
    • Cloud Run: ステートレスなコンテナをサーバーレスで実行するプラットフォーム。HTTP リクエストやイベント (Eventarc, Pub/Sub 経由) をトリガーにコンテナを起動・スケール。任意の言語、ライブラリ、バイナリを使用可能。最小インスタンス数や最大インスタンス数の設定によるコールドスタート対策やコスト管理が重要
  • App Engine
    フルマネージドなアプリケーションプラットフォーム。標準環境とフレキシブル環境があり、トラフィックに応じた自動スケーリング、バージョン管理、トラフィック分割などの機能を提供。Web アプリケーションやモバイルバックエンドの迅速な開発・運用に適している。

データサービスとの連携

  • Firestore / Cloud SQL / Spanner
    • Firestore: NoSQL ドキュメントデータベース。モバイル、ウェブ、サーバー開発に適した柔軟なデータモデル (コレクション、ドキュメント、サブコレクション) とリアルタイム同期機能を提供。クエリ設計はデータの取得パターンに依存し、インデックス戦略が重要。
    • Cloud SQL: フルマネージドなリレーショナルデータベースサービス (MySQL, PostgreSQL, SQL Server)。既存アプリケーションの移行や、構造化データの管理に適している。Cloud SQL Auth Proxy を利用した安全な接続が推奨される。リードレプリカによる読み取り負荷分散も可能。
    • Spanner: グローバルにスケーラブルで強整合性を持つリレーショナルデータベース。高い可用性と水平スケーラビリティが求められる大規模アプリケーション向け。トランザクションモデルやインターリーブテーブルの理解が重要。
  • BigQuery
    フルマネージドでペタバイト規模の分析データウェアハウス。SQL ライクなクエリによる高速なデータ分析、ストリーミング取り込み (Storage Write APIなど)、機械学習 (BigQuery ML) 機能などを提供。アプリケーションログの分析やビジネスインテリジェンスに活用。パーティショニングやクラスタリングによるクエリパフォーマンスとコストの最適化が重要
  • Cloud Storage
    スケーラブルで耐久性の高いオブジェクトストレージ。画像、動画、バックアップ、アーカイブなど、あらゆる種類のデータを保存。アプリケーションからのファイルアップロード/ダウンロード、署名付きURLによる一時アクセス、イベント通知 (Eventarc, Cloud Run functions) などで連携。

API管理とゲートウェイ

  • API Gateway
    Functions, Cloud Run, App Engine, Compute Engine, GKE などのバックエンドサービスへの安全で一貫したアクセスを提供するフルマネージドサービス。認証 (APIキー, JWT)、モニタリング、レート制限などの機能を提供し、API の公開と管理を簡素化。OpenAPI 仕様をサポート。
  • Cloud Endpoints
    (前述の通り) OpenAPI や gRPC に基づく API の設計、デプロイ、管理プラットフォーム。ESP/ESPv2 を利用。

セキュリティと監査

  • IAM (Identity and Access Management) の活用
    各 Google Cloud サービスとの統合において、サービスアカウントや Workload Identity を利用し、「最小権限の原則」に従って必要な権限のみを付与する。リソースへのアクセス制御を厳格に行う。
  • Cloud Logging / Cloud Monitoring / Cloud Audit Logs
    • Cloud Logging: アプリケーションや Google Cloud サービスからのログを一元的に収集、検索、分析、アラート設定。構造化ログの活用による効率的なログ分析も重要。
    • Cloud Monitoring: パフォーマンスメトリクス、稼働時間、アラートなどを提供。ダッシュボードでの可視化やインシデント対応に活用。カスタムメトリクスによるアプリケーション固有の指標監視も可能。
    • Cloud Audit Logs: Google Cloud リソースに対する管理アクティビティやデータアクセスに関するログを記録。セキュリティ監査やコンプライアンス対応、トレーサビリティ確保に不可欠。

理解チェック

Q1: Eventarc はどのような場合に特に有効ですか？Cloud Run functions のイベントトリガーや Pub/Sub と比較した利点は何ですか？

Eventarc は、特に多様な Google Cloud サービス (Audit Logs、多くの Google Cloud サービスからの直接イベント) をトリガーとして、Cloud Run などのコンテナベースのワークロードへ標準化された方法 (CloudEvents) でイベントをルーティングしたい場合に有効です。Pub/Sub は汎用的なメッセージング基盤ですが、Eventarc は Pub/Sub をイベントソースや配信チャネルとしても利用でき、より広範なイベントドリブンアーキテクチャの構築を支援します。

Q2: Cloud Pub/Sub と Cloud Tasks は、非同期処理においてどのように使い分けますか？具体的なユースケースを挙げてください。

  • Cloud Pub/Sub:
    • 使い分け: イベントのブロードキャスト、多数の独立したコンシューマへの配信、リアルタイム性の高いイベント通知に適しています。デカップリングが主な目的です。
    • ユースケース: リアルタイムのデータストリーム処理 (例: IoTセンサーデータ)、複数システムへのファンアウト通知 (例: 商品在庫変更の通知)、非同期マイクロサービス間通信。
  • Cloud Tasks:
    • 使い分け: タスクの確実な実行、順序性 (限定的)、レート制御、リトライ制御、実行時間のスケジューリングが必要なバックグラウンド処理に適しています。
    • ユースケース: 時間のかかる処理のオフロード (例: メール送信、画像リサイズ)、外部APIへのリクエスト (リトライ付き)、定期的なバッチ処理のトリガー。

Q3: API Gateway と Cloud Endpoints の主な違いと、それぞれの適切な利用シナリオを説明してください。

  • API Gateway:
    • 違い: 主にサーバーレスバックエンド (Functions, Cloud Run, App Engine) 向けに設計されており、より迅速かつシンプルな API 公開が可能です。OpenAPI v3 仕様をサポート。
    • 利用シナリオ: 新規にサーバーレスバックエンドでAPIを構築する場合、迅速なセットアップと従量課金モデルを活かしたい場合。
  • Cloud Endpoints:
    • 違い: ESP (Extensible Service Proxy) または ESPv2 を GKE や Compute Engine 上にデプロイして利用。OpenAPI v2 や gRPC 仕様をサポートし、より詳細な設定や既存のESPベースのデプロイメントがある場合に適しています。
    • 利用シナリオ: GKE や Compute Engine 上でホストされるサービスへのAPIゲートウェイ機能、gRPC API の管理、既存の Endpoints v1 からの移行。

Q4: Cloud Run functions と Cloud Run を選択する際の主な判断基準は何ですか？それぞれの得意な処理を挙げてください。

  • Cloud Run functions:
    • 判断基準: 単機能の短い処理 (イベント駆動)、特定のイベントに応答するシンプルなロジック、コードデプロイの容易さを重視する場合。
    • 得意な処理: Cloud Storage オブジェクト変更時の画像処理、Pub/Sub メッセージ受信時のDB書き込み、軽量なHTTP APIエンドポイント。
  • Cloud Run:
    • 判断基準: 任意の言語・ライブラリ・バイナリを利用したコンテナベースのアプリケーション、HTTP/S リクエストだけでなく、より長時間実行される可能性のある処理、複雑な依存関係を持つアプリケーション、既存のコンテナ化されたアプリケーションの移行。
    • 得意な処理: Webアプリケーション、マイクロサービスバックエンド、データ処理パイプライン、長時間実行されるバッチジョブ (Cloud Run jobs)。

Q5: アプリケーションから BigQuery にデータを書き込む主な方法と、それぞれの特性を比較してください。

  1. Storage Write API:
    • 特性: 高スループットなリアルタイムストリーミング取り込み。Exactly-once セマンティクスを提供。スキーマの事前定義が必要。リアルタイム分析や大規模ストリーミングに適している。
  2. bq load コマンド / API (バッチロード):
    • 特性: Cloud Storage などから大容量データを一括でロード。コスト効率が良い場合がある。リアルタイム性は低い。
  3. 従来のストリーミング API (tabledata.insertAll):
    • 特性: 低レイテンシでの行単位のストリーミング。スループットは Storage Write API に劣り、コストも比較的高めになることがある。スキーマの自動検出や更新機能があるが、ベストエフォート型。小規模なストリーミングに適している。
  4. Dataflow / Dataproc からの書き込み:
    • 特性: 大量のデータ変換・集計処理を伴う場合に利用。ETL/ELTパイプラインの一部としてBigQueryに書き込む。

Q6: Cloud Storage のオブジェクト変更をトリガーとして Cloud Run functions を実行する構成のメリットと、同様の目的で Eventarc を利用する場合との違いは何ですか？

  • Cloud Run functions (直接トリガー) のメリット:
    • 設定が非常にシンプルで、特定のバケットとイベントタイプに直接関数を紐付けられる。
    • 小規模な自動化や、単一のシンプルな応答処理に適している。
  • Eventarc 利用との違い:
    • 柔軟性: Eventarc は Cloud Run など、より多様なターゲットにイベントをルーティングできる。
    • イベントソース: Eventarc は Cloud Storage だけでなく、遥かに多くの Google Cloud サービスやカスタムイベントを統一的に扱える。
    • フィルタリング: Eventarc はイベントペイロードに基づいた高度なフィルタリングが可能。
    • 標準化: CloudEvents 仕様に準拠しており、異なるプラットフォーム間でのイベントの相互運用性が向上する。

Q7: Cloud Monitoring と Cloud Logging は、アプリケーションの運用においてそれぞれどのような役割を果たし、どのように連携して活用できますか？

  • Cloud Logging:
    • 役割: アプリケーションや Google Cloud サービスからのログデータ (テキストベースのイベント記録) を収集、検索、分析、保存、アラート設定する。エラーの原因特定、監査証跡の追跡、デバッグに使用。
  • Cloud Monitoring:
    • 役割: システムやアプリケーションのパフォーマンスメトリクス (例: CPU使用率、レイテンシ、エラーレート) を収集、可視化 (ダッシュボード)、アラート設定する。システムの健全性監視、パフォーマンス分析、SLA/SLOの追跡に使用。
  • 連携活用:
    • Logging で収集したログからログベースメトリクスを作成し、Monitoring でそのメトリクスを監視・アラート設定する。
    • Monitoring のアラートが発生した際に、関連する期間やリソースのログを Logging でドリルダウンして調査する。
    • 両者を組み合わせることで、問題の検知から原因特定までの時間を短縮し、システムの可観測性 (Observability) を高める。

Q8: Cloud Workflows を使用して複数の Google Cloud サービスを連携させるワークフローを構築する主なメリットと、同様のオーケストレーションを例えば Cloud Run functions のチェーンやカスタムコードで実装する場合と比較した際のトレードオフを説明してください。

  • Cloud Workflows のメリット:
    • サーバーレス: インフラ管理が不要。
    • 宣言的な定義: YAML または JSON でワークフローを視覚的に定義でき、ロジックが追いやすい。
    • 組み込みの機能: リトライ、エラーハンドリング、並列実行、待機処理、条件分岐などが標準でサポートされており、これらを自前で実装する手間が省ける。
    • GCPサービス連携: 多くの Google Cloud API や外部 HTTP API への呼び出しが容易。
    • トレーサビリティ: 実行履歴や各ステップの状態をコンソールで確認できる。
  • カスタムコード (例: Functions チェーン) とのトレードオフ:
    • 柔軟性: カスタムコードの方が複雑なロジックや状態管理、外部ライブラリの利用など、より高度な柔軟性を持つ。Workflows は定義された構文と機能の範囲内での実装となる。
    • テストの容易さ: 単純なワークフローであれば Workflows の方がテストしやすいが、複雑な分岐や状態を持つ場合は、各ステップを個別にテストしやすいカスタムコードの方が有利な場合もある。
    • コスト: 実行時間やステップ数に応じた課金。非常に多数のステップや長時間の実行がある場合、カスタムコードによる最適化された実装の方がコスト効率が良い場合があり得る。
    • 学習コスト: Workflows の構文やベストプラクティスを習得する必要がある。

Q9: Firestore のデータモデル (コレクション、ドキュメント、サブコレクション) の特徴を説明し、それがリレーショナルデータベースと比較してアプリケーションのクエリ設計やスケーラビリティにどのような影響を与えるか説明してください。

  • Firestore のデータモデル特徴:
    • ドキュメント指向: データはJSONライクなドキュメントとして保存される。
    • コレクション: ドキュメントのコンテナ。
    • サブコレクション: ドキュメントの下に階層的にコレクションを持つことができる。
    • スキーマレス (柔軟なスキーマ): 同じコレクション内のドキュメントが異なるフィールドを持つことができる。
  • アプリケーションへの影響:
    • クエリ設計:
      • リレーショナルデータベースのようなJOIN操作は直接サポートされないため、非正規化やアプリケーション側でのデータ結合が必要になることが多い。
      • クエリはコレクションに対して行い、インデックスを利用して効率化する。特定のフィールドでのフィルタリングやソートが可能。
      • データの取得パターンに合わせてデータ構造を設計することが重要。
    • スケーラビリティ:
      • 水平方向にスケールしやすい設計。シャーディングやレプリケーションは自動的に管理される。
      • クエリのパフォーマンスは、結果セットのサイズに依存し、コレクション全体のサイズには直接依存しにくい。
      • 書き込みスループットは、特定のドキュメントへの集中アクセスを避けることで向上できる。

Q10: アプリケーションから Cloud SQL インスタンス (例: MySQL, PostgreSQL) に安全かつ効率的に接続するための主要な方法を3つ挙げ、それぞれの方法が適したシナリオとセキュリティ上の考慮事項を説明してください。

  1. Cloud SQL Auth Proxy:
    • シナリオ: GKE、Compute Engine、App Engine Flex、ローカル開発環境など、ほぼ全ての環境からの接続に適している。
    • 仕組み: ローカルプロキシを介して Cloud SQL インスタンスへの安全なトンネルを確立。IAM 権限に基づいて認証し、トラフィックは自動的に暗号化 (TLS)。
    • セキュリティ考慮事項: プロキシ自体が認証を行うため、データベースの認証情報 (ユーザー名/パスワード) をコードや設定ファイルに埋め込む必要がない (IAM 認証の場合)。プロキシを実行するサービスアカウントには最小限の Cloud SQL クライアント権限を付与する。
  2. パブリック IP + SSL/TLS (自己管理証明書):
    • シナリオ: Cloud SQL Auth Proxy が利用できない環境や、特定のクライアントツールがプロキシ経由の接続をサポートしていない場合。
    • 仕組み: Cloud SQL インスタンスにパブリックIPアドレスを割り当て、SSL/TLS証明書を設定してクライアントからの接続を暗号化。承認済みネットワーク (ファイアウォールルール) で接続元IPを制限。
    • セキュリティ考慮事項: データベース認証情報 (ユーザー名/パスワード) の管理が必要。承認済みネットワークを適切に設定し、不要なアクセスをブロック。SSL/TLS証明書の管理と更新。
  3. プライベート IP (VPC Service Controls との組み合わせも可能):
    • シナリオ: 同じVPCネットワーク内、または共有VPCやVPCピアリングを通じて接続されたネットワーク内のアプリケーションからの接続。インターネット経由のアクセスを完全に排除したい場合。
    • 仕組み: Cloud SQL インスタンスにプライベートIPアドレスを割り当て、VPCネットワーク内からのみアクセス可能にする。
    • セキュリティ考慮事項: データベース認証情報の管理が必要。VPCネットワーク自体のセキュリティ (ファイアウォールルール、限定公開Googleアクセスなど) が重要。VPC Service Controls を利用することで、承認されたネットワークやIDからのみアクセスを許可し、データ漏洩リスクをさらに低減できる。

※ 参考文献

最後に

本記事が、「Professional Cloud Developer」認定資格の取得を目指す方々にとって、学習の一助となれば大変幸いです。公式ドキュメントの参照やハンズオンラボでの実践を通じて、さらなる知識の習得とスキルアップしていきましょう。

ここまでお読みいただき、ありがとうございました！

GitHubで編集を提案

Discussion