【PCD】WEB問題集:GCPサービスとの統合編

WEB問題集

PCD#351(integrating)

Cloud Run サービスから Cloud SQL for PostgreSQL に Private IP 経由でセキュアに接続したいと考えています。サービスアカウントベースの認証情報ハンドリングと暗号化を Google が自動管理する方法を選びたいです。どの構成が最適ですか？

A. Cloud Run の Direct VPC Egress を有効化し Cloud SQL Auth Proxy ライブラリで Private IP に接続します
B. Cloud SQL の Authorized Networks に Cloud Run の外向き IP レンジを登録し、Public IP 経由で接続する構成にします
C. Cloud Run のサイドカーに HAProxy を構成し、TCP レベルで Public IP に転送する経路で接続を成立させる方針にします
D. Cloud SQL の Serverless VPC Access コネクタのみで、IP 制限の無い Public IP に到達する構成で運用する方針にします

正解と解説ディスカッション 0

正解：A

正解の根拠

Cloud Run から Cloud SQL に到達する推奨パターンは、Direct VPC Egress で VPC に直接接続し、Cloud SQL Auth Proxy ライブラリ経由で Private IP に接続する構成です。これにより、TLS と IAM 認証情報の取り扱いを Google 管理ライブラリに委譲できます。

接続オプション比較

方式	到達経路	認証情報	推奨度
Direct VPC Egress + Auth Proxy	VPC 内 Private IP	IAM 委譲	本問の正解
Serverless VPC Connector + Auth Proxy	VPC 経由	IAM 委譲	旧来の選択肢
Public IP + Authorized Networks	インターネット経由	静的 IP 制限	非推奨

接続コード例

// Java + JDBC + Auth Proxy library
jdbc:postgresql:///mydb?cloudSqlInstance=project:region:inst&socketFactory=com.google.cloud.sql.postgres.SocketFactory&ipTypes=PRIVATE

不正解の理由

B: Cloud Run のマネージド環境は egress IP が固定でないため、Authorized Networks による Public IP 制限は安定運用に向きません。
C: HAProxy サイドカーの自前管理は TLS と IAM の責務を増やし、Auth Proxy 利用の優位性を失います。
D: Serverless VPC Access コネクタ単独では Private IP 経由の Auth Proxy 認証統合が得られず、Public IP 利用も推奨されません。

参考：Cloud SQL: Connect from Cloud Run

PCD#352(integrating)

GKE 上のワークロードから Cloud SQL に接続する際、シークレット管理を簡素化しつつ短命な IAM トークンで認証する方式を検討しています。データベース側に静的パスワードを保持したくありません。どの方法が要件に合致しますか？

A. Secret Manager に DB パスワードを格納し、起動時に環境変数として注入して常時利用する運用方針で構築します
B. IAM Database Authentication を有効化し Workload Identity 経由でアクセストークンを取得して接続します
C. GKE Node の Service Account 鍵を JSON でマウントし、JDBC 接続文字列の secret 部から参照する構成にします
D. Cloud KMS で暗号化した DB パスワードを ConfigMap で配布し、起動時に Pod 側で復号して接続する運用にします

正解と解説ディスカッション 0

正解：B

正解の根拠

Cloud SQL の IAM Database Authentication は、PostgreSQL と MySQL の DB ユーザーを IAM プリンシパルに紐付け、短命なアクセストークンをパスワードとして利用する仕組みです。Workload Identity と組み合わせることで、Pod が静的鍵を持たずに認証できます。

方式比較

方式	クレデンシャル	ローテーション	監査
IAM DB Auth	短命 OAuth トークン	自動 (1 時間)	IAM 監査ログ統合
Secret Manager + 静的 PW	静的パスワード	手動運用	取得操作のみ監査

有効化手順

Cloud SQL のフラグ cloudsql.iam_authentication を on にします
IAM プリンシパルに cloudsql.instanceUser 権限を付与します
DB 側で CREATE USER "sa@project.iam" WITH LOGIN を実行します
クライアントは gcloud sql generate-login-token 相当のトークンをパスワードとして使用します

不正解の理由

A: Secret Manager は便利ですが、静的パスワードのままでは漏えい時の影響範囲が広く、短命トークンを要件とする本問の最適解にはなりません。
C: Service Account 鍵 JSON のマウントは長期鍵運用となり、Workload Identity の利点を放棄する設計です。
D: ConfigMap の暗号化配布は仕組みが複雑な割に静的パスワードへの依存が残り、要件を満たしません。

参考：Cloud SQL IAM Database Authentication

PCD#353(integrating)

Cloud SQL を利用するマイクロサービスで、ピーク時に接続が枯渇し PgBouncer 相当のコネクションプーリングを導入したいです。アプリ改修を最小限にしつつマネージドに利用したい場合、どの選択肢が適していますか？

A. Cloud SQL Auth Proxy をプール代替として有効化し、内部キャッシュで再利用する構成にします
B. アプリ側の JDBC 接続プールを 1 接続あたり 5000 セッションに引き上げて Cloud SQL に直接接続する方針にします
C. アプリと Cloud SQL の間に PgBouncer をサイドカーで起動しトランザクションプーリングで多重化します
D. Cloud Run の min-instances を 0 に固定し、コネクション数の自然減を待つ運用にして対応します

正解と解説ディスカッション 0

正解：C

正解の根拠

Cloud SQL は接続数に上限があり、サーバーレスや GKE での多インスタンス運用ではコネクション枯渇が起こりやすいです。PgBouncer のトランザクションプーリングを挟むことで、多数のアプリ接続を少数の DB 接続に集約し、アプリ改修を最小限に抑えられます。

プール方式比較

方式	多重化粒度	注意点
Session pooling	セッション単位	多重化効果は限定的
Transaction pooling	トランザクション単位	prepared statement 制約あり
Statement pooling	ステートメント単位	機能制約が大きい

PgBouncer 設定例

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 25

不正解の理由

A: Cloud SQL Auth Proxy はセキュアな接続経路を提供するもので、アプリ層のコネクションプーリング機能は持ちません。
B: JDBC プールの上限引き上げだけでは Cloud SQL 側の max_connections に到達し、根本解決にはなりません。
D: min-instances を 0 にする運用はコールドスタートを招き、ピーク時のコネクション圧を解消する手段としては不適切です。

参考：Cloud SQL Manage database connections

PCD#354(integrating)

Cloud Run gen2 のリビジョンから Cloud SQL に到達する際、Serverless VPC Connector から Direct VPC Egress に切り替える理由として、最も妥当な利点はどれですか？

A. Cloud SQL のリージョン制限を超えてグローバル接続が可能になります
B. Public IP を介して Cloud SQL に到達できるようになり、Authorized Networks が任意に設定できます
C. TLS 終端を Direct VPC Egress 側で行うため、Cloud SQL Auth Proxy が省略できます
D. コネクタインスタンスを介さず VPC に直接 ENI を割り当てるため、レイテンシとコストの観点で有利になります

正解と解説ディスカッション 0

正解：D

正解の根拠

Direct VPC Egress は Cloud Run の Pod に対して VPC のネットワークインターフェースを直接割り当てる方式で、Serverless VPC Connector のように中間ホップを経由しません。これによりレイテンシが減少し、コネクタの実行コストも削減できます。

方式比較

方式	仕組み	レイテンシ	コスト
Direct VPC Egress	VPC NIC を直接割り当て	低	追加コンポーネントなし
Serverless VPC Connector	仲介 VM プールを経由	中	コネクタ料金あり

利用ケース

Cloud Run gen2 で Direct VPC Egress オプションを有効化します
VPC とサブネットを指定し、Pod に Private IP を付与します
Cloud SQL Auth Proxy ライブラリで Private IP に接続します

不正解の理由

A: Cloud SQL リージョン制約はネットワーク方式に関係なく存在するため、Direct VPC Egress でグローバル化はできません。
B: Direct VPC Egress は VPC 内 Private IP 利用を主目的とし、Public IP 経由運用への切替を促進する技術ではありません。
C: Auth Proxy が提供する IAM 認証と TLS の自動管理は依然として有用であり、Direct VPC Egress 単独では代替できません。

参考：Cloud Run Direct VPC Egress

PCD#355(integrating)

Cloud SQL Auth Proxy をローカル開発から本番デプロイまで一貫して使う設計を考えています。Auth Proxy が提供する主要な機能を選んでください（2 つ選択）。

（2つ選択）

A. TLS による暗号化と Cloud SQL インスタンスへの認可を自動で実施します
B. Service Account やユーザー資格情報を使い IAM ベースで接続を認可します
C. DB スキーマのマイグレーションを Auth Proxy 経由で実行する機能を提供します
D. Cloud SQL のリージョン間レプリケーションを Auth Proxy 経由で構成する仕組みを持ちます

正解と解説ディスカッション 0

正解：A, B

正解の根拠

Cloud SQL Auth Proxy は、TLS 暗号化と IAM 認可を組み合わせた安全な接続経路を提供します。クライアントは TCP/Unix Socket のローカルエンドポイントに接続するだけで、TLS の証明書管理と IAM 認可を Auth Proxy が代行します。

Auth Proxy 機能整理

機能	内容
TLS 暗号化	Google 提供の証明書で自動構成
IAM 認可	呼び出し元の Service Account / ユーザーで認可
Private IP / Public IP 透過	接続文字列でモード切替可能

起動コマンド例

cloud-sql-proxy --private-ip --port 5432 
  project:region:instance &

不正解の理由

C: スキーマ管理は Liquibase / Flyway などのマイグレーションツールの守備範囲であり、Auth Proxy の責務外です。
D: クロスリージョンレプリカは Cloud SQL 側の機能で構成するもので、Auth Proxy の経路設定とは別物です。

参考：About the Cloud SQL Auth Proxy