Section 1 問題集：DB 設計

全 20 問。本番に近いシナリオ形式。各問題の後に 正解 + 詳細解説 あり。目標: 中堅以上で 正答率 80% 以上。

Q1. 大規模 IoT データの選定

問題：あなたは 5,000 台のセンサーから 1 秒ごとに送信されるデータ（合計 500 万メッセージ/分）を保管・分析する基盤を設計しています。データは最低 5 年間保管し、リアルタイムでの直近データ参照と長期傾向分析の両方が必要です。最も適した DB はどれか。

A. Cloud SQL for PostgreSQL
B. Firestore Native
C. Bigtable
D. Spanner

正解: C

解説:

高 QPS（>1万 QPS）、時系列、>1TB のデータ → Bigtable
Cloud SQL は単一インスタンスで 500万 msg/分はスケール限界
Firestore は 500/秒/コレクションの書き込み上限あり
Spanner も可能だが、コスト効率で Bigtable が圧倒的に有利

Q2. グローバル E コマースの DB

問題：グローバル展開する EC サイトで、世界中のどこからでも 強整合で在庫を更新でき、SLA 99.999% を満たすトランザクション DB を選定したい。最適なのは？

A. Cloud SQL for PostgreSQL with Cross-region replica
B. Spanner Multi-region
C. AlloyDB Secondary Cluster
D. Bigtable Multi-cluster routing

正解: B

解説:

グローバル分散 + 強整合 + 99.999% はすべて Spanner Multi-region のみ
Cloud SQL のクロスリージョン Replica は非同期（強整合ではない）+ SLA 99.95%
AlloyDB Secondary も非同期
Bigtable は結果整合（マルチクラスタ）→ 強整合ではない

Q3. PostgreSQL の HTAP 要件

問題：既存の PostgreSQL アプリを Google Cloud に移行します。OLTP 処理に加え、同じ DB に対して BI ツールから分析クエリを実行したく、PostgreSQL 互換のまま トランザクションと分析の両方を高速 にしたい。どの DB を選ぶべきか。

A. Cloud SQL Enterprise Plus
B. AlloyDB
C. BigQuery
D. Spanner PostgreSQL Interface

正解: B

解説:

PostgreSQL 互換 + HTAP（同 DB で OLTP + 分析） → AlloyDB の ColumnarEngine
Cloud SQL Enterprise Plus は OLTP には強いが、分析クエリ加速は限定的
BigQuery は OLTP 非対応
Spanner PostgreSQL Interface は OLTP 専用、ColumnarEngine 相当機能なし

Q4. Oracle 完全移行

問題：オンプレの Oracle Exadata 環境を Google Cloud へ移行します。アプリは Oracle 固有の PL/SQL ストアドプロシージャ、Real Application Clusters (RAC) 機能、Spatial 拡張に依存しています。ダウンタイムは 1 週間まで許容できます。最適なソリューションは？

A. DMS で AlloyDB へ異種移行
B. Bare Metal Solution へリフトアンドシフト
C. Cloud SQL for PostgreSQL + Ora2Pg
D. Spanner PostgreSQL Interface

正解: B

解説:

Oracle 固有機能（RAC、Spatial、複雑な PL/SQL）への強い依存 → リフトアンドシフトが現実的
Bare Metal Solution は Oracle ライセンスをそのまま持ち込んで物理サーバーで動かせる
AlloyDB / Cloud SQL は Oracle 固有機能の変換が極めて高コスト
Spanner PostgreSQL Interface も Oracle 機能を吸収できない

Q5. MongoDB アプリ移行

問題：既存 MongoDB アプリを Google Cloud へ移行します。アプリは Mongo の Wire Protocol を使用しており、コード変更を最小化したい。最適な移行先は？

A. Bigtable + HBase API
B. Firestore (MongoDB-compatible)
C. Spanner
D. AlloyDB

正解: B

解説:

MongoDB Wire Protocol 互換 が必要 → Firestore (MongoDB-compatible) または MongoDB Atlas on Google Cloud
Bigtable は HBase API 互換だが MongoDB 非互換
Spanner / AlloyDB は MongoDB 互換性なし

Q6. リアルタイムモバイル同期

問題：新規モバイルアプリを開発中。オフライン時にもデータが閲覧でき、オンラインに戻った瞬間に リアルタイム同期 する必要があります。最適な DB は？

A. Cloud SQL for MySQL
B. Spanner
C. Firestore Native
D. Memorystore for Redis

正解: C

解説:

モバイル + オフライン対応 + リアルタイム同期 は Firestore Native の独壇場
Cloud SQL/Spanner はモバイル直接接続を想定していない
Memorystore はキャッシュ用途であり永続化が限定的

Q7. キャッシュレイヤー設計

問題： Cloud SQL for PostgreSQL の前段に 読み取りキャッシュ を配置し、頻繁にアクセスされるユーザープロファイルをキャッシュしたい。さらに リーダーボード（ソート付きセット）を Redis のソート機能で実装したい。最適なサービスは？

A. Memorystore for Memcached
B. Memorystore for Redis (Standard Tier)
C. Firestore Native
D. Bigtable

正解: B

解説:

ソート付きセット（Sorted Set） が必要 → Redis（Memcached にはない）
HA が必要 → Memorystore for Redis Standard Tier（Basic は HA なし）
Memcached はシンプル KV のみ、ソート不可
Firestore/Bigtable はキャッシュ用途には不向き（コスト・レイテンシ）

Q8. データレジデンシー要件

問題：ある金融機関のシステムで、データは EU 域内に保管 しなければならない法令要件があります。Cloud SQL for PostgreSQL を使用する場合、最も適した設定は？

A. eur3 マルチリージョン構成
B. europe-west1 リージョン + 組織ポリシー gcp.resourceLocations で EU 制限
C. Cloud Storage Multi-region (EU) でバックアップ
D. Spanner Multi-region

正解: B

解説:

データレジデンシー = 特定地理に保管 → リージョン指定 + 組織ポリシー で他リージョン作成を禁止
Cloud SQL は リージョン単位のサービス（Cloud Storage の Multi-region とは別概念）
eur3 は Spanner の Multi-region 設定であり Cloud SQL では存在しない
「マルチリージョン」は複数リージョンに分散されるため、データレジデンシーと矛盾する場合がある

Q9. Spanner ホットスポット回避

問題： Spanner にイベントログテーブルを設計します。主キーに タイムスタンプ（毎ミリ秒昇順） を使う案ですが、書き込み性能が問題になる懸念があります。最も効果的な対策は？

A. インデックスを追加する
B. タイムスタンプを反転 (9999999999999 - ts) して主キーとする
C. Processing Units を増やす
D. Multi-region 構成にする

正解: B

解説:

連番（昇順タイムスタンプ）の主キーは 末尾スプリットにすべての書き込みが集中 → ホットスポット
タイムスタンプ反転 で書き込みを分散
インデックス追加では根本解決にならない
PU 増加・Multi-region 化はコスト増だけで本質的には解決しない

Q10. Bigtable 行キー設計

問題： Bigtable に各センサーの時系列データを保管します。よくあるクエリは「センサーID で時刻範囲を絞る」「特定時刻でセンサー全体を取る」の 2 パターン。最適な行キー設計は？

A. <sensor_id>_<timestamp>
B. <timestamp>_<sensor_id>
C. <hash(sensor_id)>_<sensor_id>_<timestamp>
D. <sensor_id>_<reversed_timestamp>

正解: D

解説:

「センサーID で時刻範囲を絞る」 → センサーID プレフィックスが必要
「ホットスポット回避」 → 同センサーの連続書き込みが末尾に集中するため タイムスタンプ反転
A はホットスポット問題あり
B はセンサーID プレフィックスでないため範囲スキャン困難
C はセンサー単位の範囲スキャンが分散するが、シナリオに合わない（パターン2 のクエリでは不利）

Q11. Cloud SQL Enterprise Plus 採用判断

問題：本番 Cloud SQL for PostgreSQL でメンテナンス時のダウンタイムを 10 秒以下に抑える要件があります。最適なソリューションは？

A. Cloud SQL Enterprise + クロスリージョンリードレプリカ
B. Cloud SQL Enterprise Plus
C. AlloyDB
D. Spanner Multi-region

正解: B

解説:

Near-Zero Downtime メンテナンス は Cloud SQL Enterprise Plus 限定 機能
Enterprise + リードレプリカでは切替時間がメンテナンス毎に大きく取られる
AlloyDB も検討候補だが、設問は Cloud SQL の機能を問うシナリオ
Spanner はオーバースペックで開発コスト高

Q12. AlloyDB の Read Pool

問題： AlloyDB クラスタで読み取り性能を 水平スケール したい。最適なアプローチは？

A. Primary インスタンスを Compute サイズアップ
B. クロスリージョン Secondary Cluster を追加
C. Read Pool に読み取り専用ノードを追加
D. Memorystore を前段に配置

正解: C

解説:

AlloyDB の水平読み取りスケール は Read Pool の役割
Compute サイズアップは垂直スケールでありコスト効率が悪い
Secondary Cluster は DR + 読み取り（別リージョン）
Memorystore は静的データ向き、動的読み取り全般には不適

Q13. Spanner Processing Unit のサイジング

問題： Spanner Regional インスタンスで、現在 CPU 利用率が 65% に達しています。安全に運用するために最も適切なアクションは？

A. そのまま運用継続（65% は問題ない）
B. Processing Units を増やす
C. Multi-region 構成へ変更
D. クエリのキャッシュを増やす

正解: B

解説:

Spanner の CPU 利用率 65% が推奨上限
65% を超えるとオートスケーリング推奨、または手動で PU 追加
Multi-region は SLA 向上が目的、CPU 対策ではない
Spanner は標準でクエリキャッシュが効いている

Q14. データ暗号化と顧客管理

問題：コンプライアンス要件で、Cloud SQL の暗号化鍵を 顧客自身で管理し、いつでも無効化できる 必要があります。最適な設定は？

A. デフォルトの Google 管理暗号化キー
B. CMEK（Cloud KMS 顧客管理鍵）
C. CSEK（顧客提供鍵）
D. クライアント側暗号化

正解: B

解説:

CMEK = Cloud KMS の鍵をユーザーが管理、ローテーション・無効化・削除を制御可能
Google 管理鍵はデフォルトだが、顧客側で無効化不可
Cloud SQL は CSEK 非対応（CMEK のみ）
クライアント側暗号化は実装複雑、Cloud SQL の機能としては不適切

Q15. Cloud SQL Auth Proxy の用途

問題： GKE 上の Cloud Run/Pod から Cloud SQL（Private IP）に TLS + IAM 認証 で接続したい。最も適した接続方法は？

A. Public IP に直接接続
B. Cloud SQL Auth Proxy を sidecar コンテナとして起動
C. SSH トンネル経由
D. PgBouncer 経由

正解: B

解説:

GKE から Cloud SQL の標準パターンは Auth Proxy sidecar + Workload Identity
自動 TLS、IAM 認証、証明書管理不要
Public IP 接続は本番非推奨
PgBouncer はコネクションプーラーであり認証管理ではない

Q16. NoSQL の選定（リアルタイムランキング）

問題：ゲームアプリで リアルタイムランキング（プレイヤースコアのソート、TOP100 取得）を実装します。読み取り QPS は 10万を想定。最適な DB は？

A. Cloud SQL for MySQL
B. Bigtable
C. Memorystore for Redis (Sorted Set)
D. Firestore Native

正解: C

解説:

リアルタイムランキング（Sorted Set）の最適解は Redis ZADD/ZRANGE
Cloud SQL は OLTP には強いが、ランキング操作は遅い
Bigtable は範囲スキャンに強いが、ソート付きセット非対応
Firestore は書き込みが Sorted Set ほど効率的でない

Q17. AlloyDB pgvector の用途

問題：社内ナレッジ検索の RAG パイプラインを構築します。質問をベクトル化し、文書ベクトルとの 類似検索 を行い、Gemini に渡してレスポンス生成。文書ベクトルは PostgreSQL に保管したい。最適な DB は？

A. Cloud SQL for PostgreSQL + pgvector
B. AlloyDB + pgvector + ScaNN インデックス
C. Spanner Vector Index
D. BigQuery + ML.GENERATE_EMBEDDING

正解: B

解説:

AlloyDB の pgvector + ScaNN インデックス は高速 ANN 検索のためのベストプラクティス
Cloud SQL + pgvector も可能だが、ScaNN インデックスがないため大規模だと遅い
Spanner Vector Index は新機能だがグローバル分散が不要なら過剰
BigQuery は分析統合には強いが、低レイテンシな検索パイプラインには不適

Q18. Cloud SQL HA の動作

問題： Cloud SQL HA 構成の Standby インスタンスについて 正しい説明 は？

A. アプリは Standby へ読み取り接続を分散できる
B. Standby は同期レプリで、Primary 障害時に自動昇格する
C. Standby は別リージョンにある
D. Standby は別プロジェクトに作成される

正解: B

解説:

Standby は別ゾーンに同期スタンバイ、アプリは直接接続できない
読み取り分散は リードレプリカ の役割（別インスタンス）
別リージョンへは クロスリージョンリードレプリカ を使う
別プロジェクトは関係ない

Q19. データ共有とアクセス制御

問題：データサイエンティスト向けに Spanner の特定テーブルのみ読み取り を許可したい。最小権限の原則に従う設定は？

A. roles/spanner.databaseAdmin を付与
B. roles/spanner.databaseUser を付与
C. roles/spanner.databaseReader をデータベースに付与 + IAM 条件で特定テーブル限定
D. 別の Spanner インスタンスにテーブルをコピー

正解: C

解説:

読み取り専用 には databaseReader
特定テーブルのみ は IAM Conditions またはビュー作成で制御
databaseAdmin は DDL も可能で過剰
databaseUser は書き込みも可能
別インスタンスへのコピーはコスト・同期の問題あり

Q20. ベクトル DB の選択肢

問題：画像検索アプリで 1億枚 の画像ベクトル（768次元）を保管し、超高速 ANN 検索（p99 < 50ms）を実現したい。最適な DB は？

A. Cloud SQL + pgvector
B. AlloyDB + pgvector + ScaNN
C. Vertex AI Vector Search
D. BigQuery VECTOR_SEARCH

正解: C

解説:

超大規模 + 超低レイテンシ は Vertex AI Vector Search が最適
Cloud SQL/AlloyDB は中規模（数千万まで）には強いが、1億超 + p99 < 50ms は厳しい
BigQuery は分析統合向き、低レイテンシ検索には不適

📊 採点と次のステップ

正答率 80% 以上 → Section 2 へ進む
60-79% → 学習資料 01_設計を再読し、間違えた問題の周辺知識を補強
60% 未満 → 1_設計/03_要点と暗記.md を毎日眺める習慣をつける