WEB問題集
あなたのチームはステートレスな REST API を構築しており、HTTPS、カスタムドメイン、リクエスト単位課金で、ゼロから毎秒数千リクエストまで自動スケールさせたいと考えています。コードはコンテナイメージとして配信されます。どの Google Cloud サービスを採用すべきですか。
正解：B
正解の根拠
Cloud Run はコンテナイメージをそのままデプロイでき、ゼロから水平スケール、HTTPS、カスタムドメイン、リクエスト単位課金（vCPU 秒・メモリ秒）をネイティブにサポートします。ステートレスな REST API の要件すべてに合致します。
| 要件 | Cloud Run の対応 |
|---|---|
| コンテナ配信 | OCI イメージ直接デプロイ |
| ゼロスケール | min-instances=0 対応 |
| HTTPS と独自ドメイン | マネージド証明書を自動発行 |
| 課金単位 | リクエスト処理時間に応じた秒課金 |
不正解の理由
- A: App Engine Standard はコンテナではなく言語ランタイム前提で、コンテナ配信要件に合いません。
- C: MIG は VM 単位の課金とウォームアップが必要で、リクエスト単位課金にはなりません。
- D: Cloud Functions 1st gen はソース関数ベースであり、任意のコンテナイメージ実行はサポートされません。
プロデューサーサービスからイベントを発行し、複数のコンシューマーへファンアウト配信したいと考えています。要件は at-least-once 配信、キー単位の順序保証、再試行とデッドレターキューのマネージド管理です。どのサービスを選ぶべきですか。
正解：A
正解の根拠
Pub/Sub は at-least-once 配信、ordering keys によるキー単位順序保証、dead-letter topic と retry policy をマネージドで提供します。複数サブスクリプションでファンアウト構成が可能です。
| 機能 | 提供方法 |
|---|---|
| ファンアウト | 1 トピックに複数サブスクリプション |
| 順序保証 | ordering key（同一リージョン） |
| DLQ | dead_letter_topic を指定 |
不正解の理由
- B: Cloud Tasks は単一ワーカーへのタスク投入用で、複数コンシューマーへのファンアウト配信に向きません。
- C: Cloud Scheduler はクーロン起動のジョブスケジューラで、イベント配信機構ではありません。
- D: Firestore トリガーは DB 書込起点で、汎用 Pub/Sub のファンアウト要件に応えられません。
モバイルアプリのユーザープロファイルドキュメントを格納する必要があります。要件は低レイテンシ読取、モバイルクライアントへのリアルタイム同期、オフラインキャッシュ対応です。最も適したデータベースはどれですか。
正解：C
正解の根拠
Firestore Native モードは、モバイル/ウェブ SDK によるリアルタイムリスナー、オフラインキャッシュ、強整合な単一ドキュメント読取をネイティブに提供します。ユーザープロファイルなどスキーマ柔軟なドキュメントモデルに最適です。
| 要件 | Firestore の機能 |
|---|---|
| リアルタイム同期 | onSnapshot リスナー |
| オフライン | SDK のローカル永続化 |
| 低レイテンシ読取 | マルチリージョン自動レプリケーション |
不正解の理由
- A: Cloud SQL は OLTP RDB でモバイル SDK リアルタイム同期とオフラインキャッシュ機構を持ちません。
- B: Spanner はグローバル強整合 RDB が強みで、モバイル直結 SDK の用途では Firestore に劣ります。
- D: Bigtable は大規模時系列ワイドカラム DB で、ドキュメント同期 SDK を提供しません。
Cloud Run で稼働するアプリケーションが、Cloud SQL データベースへインターネットを介さずプライベートにアクセスする必要があります。どの構成を採用すべきですか。
正解：C
正解の根拠
Cloud Run の Direct VPC Egress（または Serverless VPC Access）と Cloud SQL のプライベート IP（VPC ピアリング）を組み合わせ、Cloud SQL Auth Proxy または直接接続を使うことで、トラフィックは Google ネットワーク内に留まりインターネットを通りません。IAM 認証にも対応します。
| 選択肢 | 判定 |
|---|---|
| A | 不正解 |
| B | 不正解 |
| C | 正解 |
| D | 不正解 |
不正解の理由
- A: Cloud NAT はアウトバウンドの公衆 IP 経路で、プライベート要件と方向が逆になります。
- B: Authorized Networks 方式でも通信はパブリック IP 経由で公衆網を通過します。
- D: Cloud Run はサーバーレスで VPN ピアの片端になれず、Cloud VPN の構成対象外です。
GKE 上のマイクロサービスを Blue/Green 戦略でデプロイし、エラー率が 1% を超えた場合に自動でロールバックさせたい場合、ベストプラクティスに合致する設計の組み合わせを 2 つ選んでください。
（2つ選択）
正解：A, B
正解の根拠
Cloud Deploy は GKE への Blue/Green/Canary 戦略をネイティブにサポートし、Skaffold によるレンダリングと自動ロールバックを提供します（A）。Cloud Monitoring メトリクスベースのアラートをプロモーション制御に組み込むことで、エラー率超過時の自動ロールバックを実現できます（B）。Cloud Build と統合した GitOps パイプラインが構築可能です。
| 役割 | サービス |
|---|---|
| ビルド | Cloud Build |
| デプロイ戦略 | Cloud Deploy（Blue/Green） |
| シグナル | Cloud Monitoring アラート |
不正解の理由
- C: Cloud Functions 単体ではマルチステージのプログレッシブデリバリを統制できません。
- D: Cloud Composer はワークフロー指向で、デプロイ戦略の自動切替には設計が不適合です。
- E: 手動 kubectl では Blue/Green と自動ロールバックを実現する仕組みが備わりません。