模擬問題集一覧

GCP-PCDBE 模擬問題集（練習問題）

Professional Cloud Database Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PCDBE（Professional Cloud Database Engineer）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PCDBE の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PCDBE の学習ガイドにまとめています。

GCP-PCDBE の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1また、将来のトラフィック増加にも備える必要があります。革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
あなたの e ラーニング プラットフォームは、北米のユーザーにサービスを提供する Cloud SQL for PostgreSQL インスタンス（16 vCPU、メモリ 60 GB、1 TB SSD）で稼働しています。分析チームが実行する複雑なレポート クエリは CPU リソースの 80% を消費することが多く、ピーク時間帯に受講者のトランザクションの応答時間が遅くなっています。現在のワークロードは 1 秒あたり 8,000 トランザクションで、読み取りが 60%、書き込みが 40% です。レポート クエリは数百万行を持つ複数の大規模テーブルにまたがる JOIN 操作を含み、非常に効率的な分析処理を必要とします。また、このプラットフォームでは分析レポートの需要が突発的に急増することがあり、読み取り容量を弾力的にスケーリングする必要があります。トランザクションのユーザーに影響を与えずに分析チームがレポートを効率的に実行できるよう、クエリのパフォーマンスを改善する必要があります。また、将来のトラフィック増加にも備える必要があります。どうすればよいですか。

選択肢と解説

  • 1
    Cloud SQL for PostgreSQL Enterprise エディションにアップグレードし、トランザクション クエリと分析クエリをプライマリ インスタンスにルーティングする。
  • 2
    AlloyDB for PostgreSQL に移行し、プライマリ インスタンスのマシンタイプを 32 vCPU にアップグレードする。一般的な分析クエリ用にマテリアライズド ビューを作成する。
  • ✓
    16 vCPU のプライマリ インスタンスを持つ AlloyDB for PostgreSQL に移行し、分析ワークロード用にカラム型エンジンを有効にして、クエリの分離には読み取りプールを使用する。
  • 4
    Cloud SQL for PostgreSQL インスタンスを db-n1-highmem-32 にアップグレードし、増加する負荷に対応するために PgBouncer による接続プーリングを実装する。

解説

【正解】C

【0からの解説】
①前提知識
AlloyDB for PostgreSQL は、PostgreSQL 互換のフルマネージド データベースで、トランザクション処理（OLTP）と分析処理を同じデータベースで高速に扱える（HTAP）ことを特徴としています。主な機能は次の 2 つです。
・カラム型エンジン（columnar engine）: よく分析されるテーブルの列データをメモリ上に列指向形式で保持し、集計・スキャン・JOIN を伴う分析クエリを大幅に高速化します。アプリケーションの SQL を書き換える必要はなく、オプティマイザが自動的に利用します。
・読み取りプール インスタンス（read pool）: プライマリとは別の読み取り専用ノード群で、1 つのエンドポイントの背後で複数ノードに負荷分散されます。ノード数は後から増減でき、読み取り容量を弾力的にスケールできます。読み取りプールでもカラム型エンジンを有効にできます。

②要件と制約の整理
・分析レポート（大規模テーブルの JOIN）が CPU の 80% を消費し、トランザクション ユーザーの応答を遅くしている → 分析と OLTP の「分離」が必要。
・分析処理は「非常に効率的」である必要がある → 列指向の分析高速化が有効。
・分析需要が突発的に急増する → 読み取り容量の「弾力的なスケーリング」が必要。
・将来のトラフィック増加にも備える。

③正解が要件を満たす理由
C は、AlloyDB に移行して分析クエリを読み取りプールに振り向けることで、プライマリ（トランザクション処理）から分析負荷を物理的に切り離します。さらにカラム型エンジンで JOIN・集計を伴う分析クエリを効率化し、需要の急増には読み取りプールのノード追加で対応できます。プライマリを 16 vCPU のまま維持しても分析負荷が外れるため、トランザクション性能が改善され、将来の増加にもノードの追加やスケールアップで備えられます。

【誤りの選択肢】
A：Enterprise エディションへの変更自体は性能改善策ではなく（むしろ高性能なのは Enterprise Plus エディション）、トランザクションと分析の両方をプライマリに送り続けるため、分析による CPU 競合という根本原因が解消されません。読み取り容量の弾力的なスケーリングも実現できません。
B：32 vCPU へのスケールアップとマテリアライズド ビューは一時的な改善にはなりますが、分析とトランザクションが同じプライマリで動き続けるため「影響を与えない」分離にはなりません。マテリアライズド ビューは定期的な更新（REFRESH）が必要で鮮度や運用負荷の課題もあり、突発的な需要に対する読み取りの弾力的なスケーリングも提供しません。
D：マシンタイプのスケールアップと PgBouncer による接続プーリングは、接続数の多さには効果がありますが、重い分析クエリの CPU 消費そのものは減らず、分析とトランザクションの分離も実現しません。行指向の PostgreSQL のままでは大規模 JOIN の分析効率も改善されず、読み取りの弾力的スケーリングもできません。

【参考】
AlloyDB のカラム型エンジンについて | AlloyDB for PostgreSQL
AlloyDB クラスタに読み取りプール インスタンスを作成する | AlloyDB for PostgreSQL
AlloyDB の概要 | AlloyDB for PostgreSQL
この問題のページを開く →
問題 2複数のデータベース技術にまたがるソリューションの管理複数のデータベース技術にまたがるソリューションの管理
問題
本番環境のワークロードを処理している、オートスケーラーを使用していないリージョン構成の Spanner インスタンスがあります。実施中のプロモーション イベントの間に、データベースへの書き込みが急増していることを確認しました。データベースがストレージの上限に近づいているというアラートを受け取りました。ストレージ使用率の傾向から、数時間以内にデータベースのストレージが不足する見込みです。この問題をできるだけ早く解決したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    カスタム インスタンス構成を作成し、Spanner インスタンスにカスタムの読み取り専用レプリカを追加する。
  • ✓
    Spanner インスタンスのコンピューティング容量を増やす。
  • 3
    Spanner インスタンスをマルチリージョン構成に移動する。
  • 4
    データベースから過去のデータをアーカイブして削除する。

解説

【正解】B

【0からの解説】
①前提知識
Spanner では、インスタンスに割り当てる「コンピューティング容量」（ノード数または処理ユニット（PU）数。1 ノード = 1,000 PU）によって、処理能力だけでなく保存できるデータ量の上限（ストレージ上限）も決まります。公式ドキュメントでは、1 ノード以上のインスタンスはノードあたり 10 TiB、1 ノード未満では 100 PU ごとに 1,024 GiB が割り当てられます。上限を超えるとデータベースへの書き込みが拒否される可能性があり、その場合はコンピューティング容量を追加する必要があります。コンピューティング容量の変更はオンラインで行え、ダウンタイムは発生しません。

②要件と制約の整理
・オートスケーラーがないため、容量は手動で増やす必要がある。
・数時間以内にストレージが不足する → 「できるだけ早く」解決する必要がある。
・本番稼働中で、書き込みが拒否されると業務に直接影響する。

③正解が要件を満たす理由
ノード数（または PU 数）を増やせば、ストレージの割り当て上限も比例して増えます。コンソールや gcloud から数分で実行でき、サービスを止めずに直ちに上限を引き上げられるため、「できるだけ早く」という要件に最も合致します。今後は Spanner のマネージド オートスケーラーを有効にして、ストレージ使用率も考慮した自動スケーリングを検討するとよいでしょう。

【誤りの選択肢】
A：読み取り専用レプリカは読み取りスループットやリージョン外への低レイテンシ読み取りのための機能であり、書き込み可能なデータの保存上限は増えません。カスタム インスタンス構成の作成も即時の対処には向きません。
C：マルチリージョン構成への移動は可用性と地理的な分散のための変更で、ストレージ上限の問題を直接解決しません。インスタンス構成の移動には時間がかかり、コストも大きく増えるため、数時間以内という緊急性にも合いません。
D：過去データのアーカイブと削除は長期的なデータ保持の施策としては有効ですが、エクスポートや削除の実施・検証に時間がかかります。また Spanner では削除したデータの領域がバージョンの保持期間やコンパクションを経てから回収されるため、ストレージ使用量がすぐには減らず、緊急の対処として不確実です。本番データを急いで削除するリスクもあります。

【参考】
コンピューティング容量、ノード、処理単位 | Spanner
インスタンスを作成、管理する | Spanner
この問題のページを開く →
問題 3このデータベースには、ストアド プロシージャとして記述された大量のアプリケーション ロジックが含まれており、それらも移行…データ ソリューションの移行
問題
大規模な Oracle データベースを AlloyDB for PostgreSQL に移行する計画を立てています。このデータベースには、ストアド プロシージャとして記述された大量のアプリケーション ロジックが含まれており、それらも移行先のデータベースに移行する必要があります。移行の労力とダウンタイムの両方を最小限に抑えたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    スキーマとコードの変換、およびデータ移行に Ora2pg を使用する。
  • 2
    スキーマとコードの変換に Ora2pg を使用する。AlloyDB で oracle_fdw 拡張機能を使用し、CREATE TABLE AS SELECT ステートメントを使用してソースから宛先にデータを複製する。
  • ✓
    Database Migration Service を使用する。スキーマとコードの変換用にコンバージョン ワークスペースを設定する。移行ジョブを作成し、バックフィルと変更データ キャプチャ（CDC）を実行してソースから宛先にデータを複製する。
  • 4
    Database Migration Service を使用する。スキーマとコードの変換用に従来のコンバージョン ワークスペース（legacy conversion workspace）を設定する。移行ジョブを作成し、バックフィルと変更データ キャプチャ（CDC）を実行してソースから宛先にデータを複製する。

解説

【正解】C

【0からの解説】
①前提知識
Database Migration Service（DMS）は、Oracle から AlloyDB for PostgreSQL / Cloud SQL for PostgreSQL への異種（heterogeneous）移行をサポートするマネージド サービスです。異種移行では次の 2 つを行います。
・スキーマとコードの変換: 「コンバージョン ワークスペース（conversion workspace）」で、Oracle のテーブル定義やストアド プロシージャ、関数、トリガーなどの PL/SQL コードを PostgreSQL の構文に変換します。現行のコンバージョン ワークスペースは DMS 内で変換を行う対話型の SQL エディタを備え、Gemini による変換支援（コードの説明や変換問題の修正提案）にも対応しています。
・データの移行: 移行ジョブがまず既存データを一括で読み込み（フルダンプ / バックフィル）、その後は変更データ キャプチャ（CDC）でソースの変更を継続的に複製します。これにより、ソースを稼働させたまま同期し、最後に短時間で切り替える（カットオーバー）ことができます。
一方「従来のコンバージョン ワークスペース（legacy conversion workspace）」は、古く機能が限定されたタイプです。オープンソースの変換ツール Ora2Pg の設定ファイルを DMS の外部であらかじめ作成し、その設定に従って変換する仕組みで、Gemini による変換機能や対話型 SQL エディタには対応していません。さらに、生成されたコードは利用者が自分で移行先データベースに適用する必要があり、移行前にスキーマをテストできず、主キーのないテーブルには移行前に手作業で主キー制約を作成する必要があります。公式ドキュメントでも、従来型のコンバージョン ワークスペースを移行に使うことは推奨されていません。
この 2 種類の違いは細かい論点に見えますが、判断の軸はシンプルです。「変換・適用・テストまでを DMS の中で完結できるか（＝人手の作業が少ないか）」と「CDC で稼働を止めずに同期できるか（＝ダウンタイムが短いか）」の 2 点で選択肢を比べると、名前に「従来（legacy）」と付く方式は、現行方式より手作業が多い旧来の選択肢だと判断できます。

②要件と制約の整理
・大規模な Oracle データベースで、大量のストアド プロシージャ（コード）の変換が必要。
・「移行の労力」と「ダウンタイム」の両方を最小にしたい。

③正解が要件を満たす理由
C は、DMS の現行コンバージョン ワークスペースでスキーマとストアド プロシージャを DMS 内で（Gemini の支援も受けながら）変換でき、変換作業の労力を抑えられます。さらに移行ジョブのバックフィル + CDC で、ソースを止めずにデータを継続的に同期できるため、カットオーバー時のダウンタイムもごく短くできます。両方の要件を満たすのは C です。

【誤りの選択肢】
A：Ora2pg はオープンソースのツールで、スキーマ・コード変換とデータのエクスポートができますが、自前で環境を用意して実行・管理する必要があり労力が大きくなります。また基本的には一括コピーのため、大規模データベースでは移行中にソースへの書き込みを止める必要があり、ダウンタイムが長くなります。
B：oracle_fdw と CREATE TABLE AS SELECT によるデータのコピーは一回限りのスナップショット コピーで、継続的な変更の複製（CDC）がありません。大規模データのコピー中はソースを停止する必要があり、ダウンタイムが大きくなります。手作業の SQL が多く労力も大きくなります。
D：DMS とバックフィル + CDC を使う点は C と同じで、ダウンタイムの面では差がありません。違いはスキーマとコードの変換方法です。従来のコンバージョン ワークスペースでは、Ora2Pg の設定ファイルを DMS の外部で作成・調整し、変換されたコードを自分で移行先に適用し、主キーの不足も手作業で補う必要があります。移行前にスキーマをテストすることもできず、Gemini による変換支援や対話型エディタもありません。大量のストアド プロシージャを変換する本問では、この手作業の差がそのまま労力の差になるため、「労力を最小化」という要件では C に劣ります。

【参考】
Oracle から AlloyDB for PostgreSQL への移行の概要 | Database Migration Service for heterogeneous Oracle to AlloyDB for PostgreSQL
Database Migration Service を使用して SQL を変換する
この問題のページを開く →
問題 4us-west1 リージョンにデータ損失ゼロの障害復旧（DR）を設定してテストする必要があります。Google Cloud でのスケーラブルで高可用性のデータベースのデプロイ
問題
あなたは小売企業の DBA（データベース管理者）です。本番データベースは us-central1 リージョンの Cloud SQL for MySQL Enterprise Plus エディション、バージョン 8.0.34 で稼働しています。us-west1 リージョンにデータ損失ゼロの障害復旧（DR）を設定してテストする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    us-west1 リージョンにカスケード リードレプリカを設定して高度な DR を使用し、それをフェイルオーバー DR レプリカとして指定する。gcloud の switchover コマンドを使用してスイッチオーバーをテストする。
  • 2
    us-west1 リージョンにバージョン 8.0.37 のクロスリージョン リードレプリカを作成する。それをフェイルオーバー DR レプリカとして指定し、gcloud の switchover コマンドを使用してスイッチオーバーをテストする。
  • ✓
    us-west1 リージョンにバージョン 8.0.34 のクロスリージョン リードレプリカを作成する。それをフェイルオーバー DR レプリカとして指定し、gcloud の switchover コマンドを使用してスイッチオーバーをテストする。
  • 4
    us-west1 リージョンにバージョン 8.0.34 のクロスリージョン リードレプリカを作成する。gcloud の promote-replica コマンドを failover 付きで使用してスイッチオーバーをテストする。

解説

【正解】C

【0からの解説】
①前提知識：Cloud SQL for MySQL の Enterprise Plus エディションでは「高度な障害復旧（advanced DR）」を利用できます。これは、別リージョンに作成したクロスリージョン リードレプリカを「DR レプリカ（フェイルオーバー DR レプリカ）」として指定しておき、(a) リージョン障害時には gcloud sql instances promote-replica REPLICA --failover による「レプリカ フェイルオーバー」で即座にプライマリを切り替え、(b) 障害がないときの DR テストや、フェイルオーバー後に元の構成へ戻すときには gcloud sql instances switchover REPLICA による「スイッチオーバー」でプライマリと DR レプリカの役割を入れ替える仕組みです。スイッチオーバーは、レプリカが全トランザクションを適用し終えてから役割を交代するため「データ損失ゼロ」です。一方、レプリカ フェイルオーバーは非同期レプリケーションの遅延分のデータが失われる可能性があります。DR レプリカの指定は gcloud sql instances patch PRIMARY --failover-dr-replica-name=REPLICA で行います。
DR レプリカの主な要件：Enterprise Plus エディションであること、プライマリと同じメジャー バージョンかつ同じマイナー バージョン（MySQL 8.0.31 以降）であること、プライマリと別リージョンにあること、プライマリの直接のリードレプリカであること（カスケード レプリカや外部レプリカは不可）、バイナリログが有効であること、ポイントインタイム リカバリ（PITR）用のトランザクション ログを Cloud Storage に保存していること、など（現行の Cloud SQL ドキュメントで「メジャー・マイナー バージョンともプライマリと同一、かつ MySQL 8.0.31 以降」と明記されています）。

②要件と制約語の整理：(1) プライマリは us-central1・Enterprise Plus・MySQL 8.0.34、(2) DR 先は us-west1、(3)「データ損失ゼロ」で DR を「設定してテスト」する。

③正解の理由：C は、プライマリと同じ 8.0.34 のクロスリージョン リードレプリカを us-west1 に作成し（DR レプリカの要件を満たす）、DR レプリカとして指定したうえで、データ損失ゼロの switchover でテストしています。要件をすべて満たすのは C だけです。

【誤りの選択肢】
A：DR レプリカはプライマリの直接のリードレプリカである必要があり、カスケード リードレプリカ（レプリカのレプリカ）は DR レプリカに指定できません。
B：DR レプリカはプライマリと同じメジャー バージョンかつ同じマイナー バージョンである必要があります。プライマリが 8.0.34 なのに 8.0.37 のレプリカを作成すると、DR レプリカとして指定できません。
D：レプリカを DR レプリカとして指定する手順がなく、高度な DR の構成になっていません。また promote-replica の failover は障害時に即座に切り替える操作で、レプリケーション遅延分のデータが失われる可能性があるため「データ損失ゼロ」のテストになりません。データ損失ゼロで役割を入れ替えてテストするには switchover を使います。

【参考】
高度な障害復旧（DR）を使用する | Cloud SQL for MySQL
Cloud SQL の障害復旧（DR）について | Cloud SQL for MySQL
リージョン移行または障害復旧のためにレプリカを昇格させる | Cloud SQL for MySQL
この問題のページを開く →
問題 5革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
頻繁にアクセスされるデータをキャッシュしてアプリケーションのパフォーマンスを向上させるために、Memorystore for Redis を使用しています。リージョン全体が停止した場合、アプリケーションは別のリージョンにフェイルオーバーします。フェイルオーバー後に、新しいリージョンの Memorystore インスタンスが空のキャッシュから開始されないようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    Memorystore Standard Tier を使用する。リードレプリカを無効にする。
  • 2
    Memorystore Standard Tier を使用する。少なくとも 1 つのリードレプリカを構成する。
  • ✓
    Memorystore インスタンスのエクスポートをスケジュールする。エクスポート先としてデュアルリージョンの Cloud Storage バケットを指定する。
  • 4
    Memorystore の Redis RDB スナップショットを有効にする。

解説

【正解】C

【0からの解説】
①前提知識
Memorystore for Redis は Google Cloud のフルマネージドな Redis サービスです。インスタンスはリージョン単位のリソースで、主な可用性・永続化の機能は次のとおりです。
・Standard Tier: 同じリージョン内の別ゾーンにレプリカを持ち、ゾーン障害時に自動フェイルオーバーします。リードレプリカを有効にすると読み取りもスケールできますが、レプリカはすべて同じリージョン内にあります。
・RDB スナップショット（永続化）: インスタンス内部の永続ストレージに定期的にスナップショットを保存し、ノードの障害後などに同じインスタンスのデータを復元するためのものです。スナップショットは内部的なシステム復旧専用で、ユーザーがアクセスしたり、別リージョンのインスタンスで使ったりすることはできません。
・エクスポート / インポート: インスタンスのデータを RDB ファイルとして Cloud Storage バケットに書き出し、別のインスタンスに読み込めます。Cloud Scheduler と Cloud Run functions（旧 Cloud Functions）などを使って定期的なエクスポートを自動化できます。

②要件と制約の整理
・リージョン全体の停止に備え、別リージョンへのフェイルオーバーを想定している。
・フェイルオーバー先の Memorystore インスタンスが「空のキャッシュから始まらない」ようにしたい → 停止したリージョンに依存せずに、別リージョンからアクセスできるデータのコピーが必要。

③正解が要件を満たす理由
定期的なエクスポートをデュアルリージョン（2 つのリージョンにデータを冗長保存する）Cloud Storage バケットに書き出しておけば、一方のリージョンが完全に停止しても、もう一方のリージョンから RDB ファイルを読み出せます。フェイルオーバー先のリージョンの Memorystore インスタンスにこのファイルをインポートすれば、最後のエクスポート時点のデータでキャッシュを事前にウォームアップでき、空の状態から始まるのを避けられます。

【誤りの選択肢】
A：Standard Tier のレプリカは同じリージョン内のゾーン障害に対する保護であり、リージョン全体の停止には対応できません。さらにリードレプリカを無効にしても別リージョンにデータが残るわけではないため、要件とは無関係です。
B：リードレプリカも同じリージョン内に作成されるため、リージョン全体が停止すればプライマリと一緒に利用できなくなります。別リージョンのインスタンスにデータを引き継ぐ手段にはなりません。
D：RDB スナップショットは同じインスタンス内のシステム復旧専用で、ユーザーはアクセスできず、別リージョンの新しいインスタンスへの復元には使えません。リージョン全体の停止時の対策にはなりません。

【参考】
Redis インスタンスからデータをエクスポートする | Memorystore for Redis
RDB スナップショットについて | Memorystore for Redis
Memorystore for Redis の高可用性
この問題のページを開く →
問題 6複数のデータベース技術にまたがるソリューションの管理複数のデータベース技術にまたがるソリューションの管理
問題
アプリケーションで Cloud SQL for MySQL インスタンスを使用しています。最近、ピーク時間帯にパフォーマンスが低下して応答時間が遅くなり、ユーザーが不満を感じていることに気付きました。非効率なクエリが問題の一因になっている可能性があると考えています。問題のあるクエリを特定して分析し、最適化のためにアプリケーション チームに引き渡したいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    アンダープロビジョニング状態のインスタンスのレコメンダーを使用する。
  • 2
    Cloud SQL インスタンスの read_buffer_size フラグの値を増やす。
  • ✓
    Query Insights を有効にして使用する。
  • 4
    database/mysql/queries 指標に基づく Cloud Monitoring アラートを作成する。

解説

【正解】C

【0からの解説】
①前提知識
Query Insights は、Cloud SQL に組み込まれたクエリ パフォーマンスの診断機能です。有効にすると、データベースの負荷をクエリ単位・タグ単位で可視化し、実行時間・実行回数・スキャン行数などからどのクエリが負荷を生んでいるかを特定できます。クエリ プラン（実行計画）の確認や、アプリケーション側でタグ（Sqlcommenter）を付けることでどのアプリケーション コードが問題のクエリを発行しているかの追跡もできます。追加のツールを導入する必要がなく、Cloud SQL Enterprise エディションと Enterprise Plus エディションの両方で利用できます（Enterprise Plus ではより長い保持期間などの拡張機能があります）。

②要件と制約の整理
・非効率なクエリが原因と推測している。
・「問題のあるクエリを特定して分析」し、その結果を「アプリケーション チームに引き渡して最適化」してもらいたい。
→ 必要なのは、クエリ レベルで原因を特定・分析できるツール。

③正解が要件を満たす理由
Query Insights を有効にすれば、ピーク時に負荷の高いクエリを上位から特定し、そのクエリの実行計画や待機要因、呼び出し元のアプリケーション情報まで確認できます。これらの情報をそのままアプリケーション チームに渡してクエリの書き換えやインデックス追加を依頼できるため、要件を直接満たします。

【誤りの選択肢】
A：アンダープロビジョニング インスタンスのレコメンダーは、CPU やメモリが不足しているインスタンスに対してマシンタイプの増強を提案する機能です。リソース不足は分かっても、どのクエリが非効率なのかは特定できません。
B：read_buffer_size はシーケンシャル スキャン用のバッファ サイズを調整する MySQL のフラグで、推測に基づくチューニングにすぎません。問題のクエリを特定・分析するという要件を満たさず、値を大きくしすぎるとメモリ消費が増える副作用もあります。
D：database/mysql/queries はクエリ数（実行された文の数）の指標で、アラートを作れば負荷の増加は検知できますが、どのクエリが非効率なのかを特定・分析する情報は得られません。

【参考】
Query Insights を使用してクエリのパフォーマンスを向上させる | Cloud SQL for MySQL
この問題のページを開く →
問題 7移行に伴うスキーマとアプリケーションの変更は最小限にする必要があります。革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
オンプレミスのオンライン トランザクション処理（OLTP）用の PostgreSQL データベースを Google Cloud に移行しようとしています。VACUUM やメモリのチューニングといったデータベースのメンテナンス作業に関する管理オーバーヘッドを削減したいと考えています。また、このデータベースで分析のユースケースを導入することも計画しています。移行に伴うスキーマとアプリケーションの変更は最小限にする必要があります。どうすればよいですか。

選択肢と解説

  • 1
    PGAdapter を使用して Spanner を使用する。
  • 2
    Cloud SQL for PostgreSQL を使用する。
  • ✓
    AlloyDB for PostgreSQL を使用する。
  • 4
    Compute Engine 上にセルフマネージドの PostgreSQL データベースをデプロイする。

解説

【正解】C

【0からの解説】
①前提知識
・AlloyDB for PostgreSQL: PostgreSQL と互換性のあるフルマネージド データベースです。標準の PostgreSQL に加えて、適応型の自動 VACUUM（adaptive autovacuum）や自動メモリ管理など、従来 DBA が手作業で行っていたチューニングを自動化する機能を備えています。さらにカラム型エンジンにより、同じデータベース上で分析クエリを高速に実行できます（HTAP）。PostgreSQL 互換なので、既存のスキーマや SQL、ドライバをほぼそのまま利用できます。
・Cloud SQL for PostgreSQL: マネージドな PostgreSQL ですが、VACUUM の設定やメモリ関連のフラグのチューニングは基本的に利用者側で行います。分析専用の高速化機能（列指向エンジン）は持ちません。
・Spanner + PGAdapter: Spanner は水平スケールする分散データベースで、PostgreSQL インターフェースと PGAdapter により PostgreSQL ドライバから接続できますが、PostgreSQL と完全互換ではありません。

②要件と制約の整理
・VACUUM やメモリのチューニングなどのメンテナンス作業の管理オーバーヘッドを削減したい。
・分析のユースケースを同じデータベースに導入したい。
・スキーマとアプリケーションの変更を最小限にしたい（PostgreSQL 互換が必要）。

③正解が要件を満たす理由
AlloyDB は PostgreSQL 互換のため変更を最小限に移行でき、適応型自動 VACUUM と自動メモリ管理によりメンテナンスの手間を減らせます。さらにカラム型エンジンで分析クエリを OLTP と同じデータベース上で効率的に実行できるため、3 つの要件をすべて満たします。

【誤りの選択肢】
A：Spanner の PostgreSQL インターフェースは PostgreSQL の機能の一部のみをサポートしており、データ型や関数、拡張機能、主キーの設計（ホットスポット回避）などでスキーマとアプリケーションの変更が必要になることが多く、「変更を最小限」という要件に反します。
B：Cloud SQL for PostgreSQL は PostgreSQL 互換で移行は容易ですが、VACUUM やメモリのチューニングは利用者が引き続き管理する必要があり、分析を高速化する列指向エンジンもありません。メンテナンス負荷の削減と分析ユースケースの両面で AlloyDB に劣ります。
D：Compute Engine 上のセルフマネージド PostgreSQL では、OS やデータベースのパッチ適用、バックアップ、高可用性、VACUUM、メモリ チューニングなどをすべて自分で行う必要があり、管理オーバーヘッドを削減するという要件と正反対です。

【参考】
AlloyDB の概要 | AlloyDB for PostgreSQL
AlloyDB のカラム型エンジンについて | AlloyDB for PostgreSQL
この問題のページを開く →
問題 8このセール期間中にデータベースのパフォーマンスを安定して維持できるよう、Spanner を構成する必要があります。複数のデータベース技術にまたがるソリューションの管理
問題
Google Cloud で新しい e コマース アプリケーションを設計しています。セールのピーク期間中は、書き込み量が多く、かつ急激に増減（バースト）すると予想されます。このセール期間中にデータベースのパフォーマンスを安定して維持できるよう、Spanner を構成する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    シャーディングを実装して、書き込み負荷を複数の Spanner インスタンスに分散する。
  • 2
    ピーク期間中の読み取りパフォーマンスを向上させるために、読み取り専用トランザクションを構成する。
  • 3
    インターリーブ テーブルを使用して、ノード間のトランザクションの数を減らす。
  • ✓
    Spanner インスタンスで自動スケーリングを有効にし、最大ノード数をピーク時の書き込み量に見合う値に設定する。

解説

【正解】D

【0からの解説】
①前提知識
Spanner はノード数（処理ユニット数）を増やすことで処理能力（読み取り / 書き込みスループット）をほぼ線形に拡張できる分散データベースです。Spanner には「マネージド オートスケーラー」が組み込まれており、インスタンスの設定で有効にすると、CPU 使用率とストレージ使用率の目標値に基づいてコンピューティング容量を自動的に増減します。最小 / 最大のノード数（または処理ユニット数）を指定でき、最大値を設定することで、負荷の急増時にどこまで拡張するか（とコストの上限）を制御できます。スケーリングはオンラインで行われ、ダウンタイムはありません。

②要件と制約の整理
・セールのピーク期間中、書き込み量が多く、バースト的に増減する。
・その期間中も「一貫した（安定した）データベース パフォーマンス」を確保したい。

③正解が要件を満たす理由
マネージド オートスケーラーを有効にし、最大ノード数をピーク時の書き込み量を処理できる値に設定しておけば、書き込みの急増に合わせて自動的に容量が増え、負荷が下がれば縮小されます。手動の介入なしに性能を安定させつつ、ピーク以外の期間のコストも抑えられるため、要件に最も合致します。

【誤りの選択肢】
A：Spanner はそれ自体が自動的にデータをスプリットに分割して複数のサーバーに分散する（自動シャーディング）データベースです。アプリケーション側で複数の Spanner インスタンスにシャーディングすると、インスタンス間のトランザクション整合性が失われ、運用も複雑になります。Spanner の強みを捨てるアンチパターンです。
B：読み取り専用トランザクションはロックを取得せずに読み取りを行うため読み取り性能の向上には役立ちますが、問題は書き込みのバーストであり、書き込み性能の安定化には効果がありません。
C：インターリーブ テーブルは、親子関係のある行を物理的に近くに配置して結合や関連行の更新を効率化するスキーマ設計の手法で、特定のアクセス パターンには有効です。しかし、バースト的な書き込み量の増加に対して処理能力を増やすものではなく、ピーク時の性能の安定を保証しません。

【参考】
マネージド オートスケーラー | Spanner
自動スケーリングの概要 | Spanner
この問題のページを開く →
問題 9既存の整数ベースのテーブル主キーを扱う方法を決める必要があります。データ ソリューションの移行
問題
オンプレミスの PostgreSQL データベースを Spanner に移行しています。既存の整数ベースのテーブル主キーを扱う方法を決める必要があります。アプリケーションへの変更を最小限に抑えつつ、Google が推奨するプラクティスにも従いたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    アプリケーションで生成した連番の整数値を主キーとして使用する。
  • 2
    主キーのデフォルト値を max(primary_key) + 1 に更新する。
  • 3
    UUID バージョン 4 の値を生成する UUID 関数を主キーとして使用する。
  • ✓
    BIT_REVERSED_POSITIVE シーケンスを使用して値を生成する。

解説

【正解】D

【0からの解説】
①前提知識：Spanner は主キーの値の範囲（キー範囲）ごとにデータを「スプリット」に分割し、複数のサーバーに分散して処理する分散データベースです。そのため、1, 2, 3, … のように単調に増加する値を主キーにすると、新しい行の書き込みが常にキー範囲の末尾（同じスプリット）に集中し、1 台のサーバーに負荷が偏る「ホットスポット」が発生します。これを避けるため Spanner には、内部の連番カウンタをビット反転してから返す「ビット反転シーケンス（bit-reversed sequence）」が用意されています。PostgreSQL 言語のデータベースでは CREATE SEQUENCE ... BIT_REVERSED_POSITIVE で作成し、列のデフォルト値に nextval('seq') を指定できます。生成される値は正の 64 ビット整数（bigint）で、キー空間全体に均等に散らばります。

②要件と制約語の整理：(1) 移行元の主キーは「整数」である、(2) アプリケーションの変更を「最小限」にしたい、(3) Google 推奨のプラクティスに従う（＝ホットスポットを作らない主キー設計）、の 3 点です。

③正解の理由：Spanner の「主キーを移行する」ドキュメントでは、移行元で AUTO_INCREMENT / SERIAL / IDENTITY などで自動採番された整数キーについて、Spanner のシーケンス（ビット反転シーケンス）を列のデフォルト値として作成し、既存行は元のキー値のまま移行し、既存の値と衝突しないよう ALTER SEQUENCE で使用済みの範囲をスキップする（SKIP RANGE）か開始カウンタを既存値より大きくする方法が説明されています。主キーの型は整数のまま、既存の値も変わらず、アプリは INSERT でキー列を省略するだけで新しい値が自動採番されるため、アプリ側の変更が最小で済みます。同時にビット反転によって値が分散するのでホットスポットも回避でき、Google 推奨のプラクティスにも合致します。

【誤りの選択肢】
A：アプリケーションで連番の整数を生成すると、新しい行が常にキー範囲の末尾に書き込まれ、Spanner で典型的なホットスポットになります。さらに、採番ロジックをアプリ側に実装・維持する必要があり、複数のアプリ インスタンス間で重複しないよう調整する仕組みも必要になります。Google が明確に避けるよう推奨している設計です。
B：max(primary_key) + 1 で次のキーを決める方法は、やはり単調増加の値になるためホットスポットを生みます。加えて、挿入のたびに最大値を読み取る必要があり、同時実行される挿入どうしでロック競合やキー重複が発生しやすく、スケーラビリティも性能も劣ります。
C：UUID バージョン 4 は値がランダムに分散するため、Spanner でも推奨される主キーの選択肢の 1 つです。しかし UUID は文字列（STRING / text）型であり、既存の整数型の主キーを置き換えることになるため、主キーの型変更・既存データの変換・外部キーや参照側の列の変更、アプリケーションでのキーの扱いの変更が必要になります。「アプリケーションへの変更を最小限に」という制約に対しては、整数型のまま使えるビット反転シーケンス（D）の方が適しています。

【参考】
主キーを移行する | Spanner
主キーのデフォルト値管理 | Spanner
スキーマ設計のベスト プラクティス | Spanner
この問題のページを開く →
問題 10この機能をどのように実現すればよいですか。革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
製品情報のテーブルを持つ Cloud SQL for MySQL インスタンスがあり、そのテーブルには製品説明の列が含まれています。アプリケーション開発チームは顧客向けのチャットボットを構築しており、顧客が入力した自由形式のテキストの説明に最もよく一致する製品を見つけたいと考えています。この機能をどのように実現すればよいですか。

選択肢と解説

  • 1
    正規表現を使用して、顧客の検索テキストを製品説明列の値と照合するストアド プロシージャを作成する。
  • ✓
    製品テーブルに製品説明のエンベディングの列を作成してデータを格納し、顧客の検索テキストを使用して近似最近傍探索を実行する。
  • 3
    LIKE 演算子を使用して顧客の検索テキストを製品説明と照合し、類似した行を返す。
  • 4
    SOUNDEX 関数を使用して製品説明と顧客の検索テキストを比較する SQL スクリプトを作成する。

解説

【正解】B

【0からの解説】
①前提知識
・ベクトル エンベディング（埋め込み）: 文章などのデータを、その「意味」を表す数値のベクトルに変換したものです。意味が近い文章ほどベクトル同士の距離が近くなるため、言い回しが違っても意味的に似た文章を見つけられます（セマンティック検索）。
・近似最近傍探索（ANN）: 大量のベクトルの中から、検索ベクトルに最も近いものを、ベクトル インデックスを使って高速に（厳密さを少し犠牲にして）見つける手法です。
Cloud SQL for MySQL はベクトル検索に対応しており、テーブルにベクトル エンベディング列を追加してデータを格納し、ベクトル インデックスを作成して ANN 検索を実行できます。エンベディングは Gemini Enterprise Agent Platform（旧 Vertex AI）などのエンベディング モデルで生成できます。

②要件と制約の整理
・顧客が入力する「自由形式のテキスト」で検索する（表現が毎回異なり、製品説明の文言と一致するとは限らない）。
・その内容に「最もよく一致する（最も近い）」製品を返す必要がある → 文字列の一致ではなく意味の類似度で探す必要がある。

③正解が要件を満たす理由
製品説明をエンベディングに変換して列に保存し、顧客の検索テキストも同じモデルでエンベディングに変換してから ANN 検索を行えば、言い回しが違っていても意味的に最も近い製品を高速に見つけられます。生成 AI のチャットボットで一般的な、公式に推奨されるセマンティック検索の実装方法です。

【誤りの選択肢】
A：正規表現は決められた文字パターンとの一致を調べるもので、自由形式の文章の「意味」の近さは判定できません。言い回しが違えば一致せず、類似度による順位付けもできません。
C：LIKE 演算子は部分文字列の一致を調べるだけで、同義語や言い換えに対応できず、どれが「最も近いか」の順位付けもできません。先頭がワイルドカードの検索はインデックスも使えず遅くなります。
D：SOUNDEX は英単語の発音の類似度を表すコードを比較する関数で、つづりの揺れの検出には使えても、文章全体の意味の類似度は判断できません。自由形式の説明文に最も一致する製品を探す用途には適しません。

【参考】
ベクトル検索 | Cloud SQL for MySQL
ベクトル インデックスを作成して管理する | Cloud SQL for MySQL
ベクトル エンベディングを使用した検索とフィルタ | Cloud SQL for MySQL
この問題のページを開く →
問題 11ダウンタイムを最小限に抑えつつ、データベースが負荷に対応できるようにする必要があります。複数のデータベース技術にまたがるソリューションの管理
問題
あなたの会社の急成長しているeコマース アプリケーションは Cloud SQL for MySQL を使用しています。トラフィックのピーク時にパフォーマンスの問題が表面化しています。ダウンタイムを最小限に抑えつつ、データベースが負荷に対応できるようにする必要があります。どうすればよいですか。

選択肢と解説

  • ✓
    クエリのオフロードのためにリードレプリカを使用し、自動フェイルオーバーを構成し、フェイルオーバー手順を定期的にテストする。
  • 2
    vCPU やメモリなどのコンピューティング リソースを大幅に増やして、プライマリ インスタンスを垂直方向にスケーリングする。
  • 3
    既存のインスタンスのストレージ サイズを増やし、頻繁にアクセスされるデータに対してクライアント側のキャッシュを実装する。
  • 4
    高負荷時のパフォーマンスを向上させるために Cloud SQL for PostgreSQL データベースに移行する。

解説

【正解】A

【0からの解説】
①前提知識：Cloud SQL のリードレプリカは、プライマリ インスタンスのデータを非同期で複製した読み取り専用のインスタンスです。eコマースのように読み取り（商品の閲覧・検索など）が大半を占めるワークロードでは、読み取りクエリをリードレプリカに振り分ける（オフロードする）ことで、プライマリの負荷を下げて書き込み処理に余裕を持たせることができます。リードレプリカは稼働中のプライマリを停止せずに追加でき、Enterprise Plus エディションでは複数のレプリカを 1 つのエンドポイントで扱える読み取りプールも利用できます。また、高可用性（HA）構成（リージョン インスタンス）を有効にすると、プライマリのゾーン障害時にスタンバイへ自動フェイルオーバーされ、ダウンタイムを最小化できます。

②要件と制約語の整理：(1) 急成長中でピーク時に性能問題がある＝負荷に耐えるスケーラビリティ、(2)「ダウンタイムを最小限に抑えつつ」。

③正解の理由：A は、リードレプリカによる水平スケーリング（スケールアウト）で読み取り負荷を分散してピーク時の性能問題に対処し、さらに自動フェイルオーバー（HA 構成）とフェイルオーバー手順の定期的なテストで、障害時のダウンタイムも最小化します。リードレプリカの追加自体はプライマリの再起動を伴わないため、導入時のダウンタイムもありません。急成長を続けるワークロードにも、レプリカの追加で継続的に対応できます。

【誤りの選択肢】
B：垂直スケーリング（マシンタイプの変更）は性能向上に有効ですが、Cloud SQL Enterprise エディションではマシンタイプの変更にインスタンスの再起動が必要で、ダウンタイムが発生します（Enterprise Plus エディションではほぼゼロのダウンタイムで変更できますが、問題文にはエディションの指定がありません）。また、単一インスタンスを大きくし続ける方法にはマシンサイズの上限があり、急成長するワークロードへの継続的な対応や可用性の向上にはつながりません。
C：ストレージ サイズを増やすと（Cloud SQL では容量に応じてディスクのスループット・IOPS も増えますが）、ピーク時の CPU やクエリ処理の負荷そのものは解決しません。クライアント側キャッシュはアプリケーションの改修が必要で、キャッシュの整合性管理も必要になり、データベース層の負荷対策としては部分的です。
D：MySQL から PostgreSQL への移行は、異なるデータベース エンジン間の移行（スキーマ・クエリ・アプリの改修を伴う異種移行）になり、大きな工数と移行時のダウンタイムのリスクを伴います。エンジンを変えるだけでピーク時の性能問題が解決する根拠もなく、要件に合いません。

【参考】
Cloud SQL でのレプリケーションについて | Cloud SQL for MySQL
高可用性について | Cloud SQL for MySQL
読み取りプールについて | Cloud SQL for MySQL
この問題のページを開く →
問題 12新しいバッチ分析ジョブが同じデータを読み取る必要があり、この新しいジョブが既存のワークロードに影響を与えないようにしたい…Google Cloud でのスケーラブルで高可用性のデータベースのデプロイ
問題
あるアプリケーションが、単一の Bigtable クラスタ上で一日中大量の読み取りと書き込みを行っています。新しいバッチ分析ジョブが同じデータを読み取る必要があり、この新しいジョブが既存のワークロードに影響を与えないようにしたいと考えています。どうすればよいですか。

選択肢と解説

  • 1
    ノードを手動で追加して Bigtable インスタンスをスケールアップする。
  • 2
    既存のインスタンスに新しいクラスタを追加し、アプリ プロファイルでマルチクラスタ ルーティングを有効にする。
  • ✓
    既存のインスタンスに新しいクラスタを追加し、2 つのアプリ プロファイルを使用してワークロードを分離する。
  • 4
    自動スケーリングを有効にして Bigtable インスタンスをスケールアップする。

解説

【正解】C

【0からの解説】
①前提知識：Bigtable のインスタンスは 1 つ以上のクラスタ（ノードの集まり）を持つことができ、複数クラスタにすると各クラスタ間でデータが自動的にレプリケーションされます。アプリケーションがどのクラスタにリクエストを送るかはアプリ プロファイルで制御します。ルーティング ポリシーには、(a) 単一クラスタ ルーティング（指定した 1 つのクラスタにだけ送る）と、(b) マルチクラスタ ルーティング（最も近い利用可能なクラスタに自動で送り、障害時は自動フェイルオーバー）があります。Google の公式ドキュメントでは、レプリケーションのユースケースとして「サービング用のトラフィックとバッチ分析のトラフィックを分離する」ことが挙げられ、その場合は用途ごとにアプリ プロファイルを作成し、それぞれ単一クラスタ ルーティングで別のクラスタを指定する構成が推奨されています。

②要件と制約の整理：既存アプリは一日中高負荷の読み書きを行っている。新たなバッチ分析ジョブは同じデータを読む必要がある。そして既存ワークロードに影響を与えない（ワークロードの分離）ことが条件です。

③正解の理由：インスタンスに 2 つ目のクラスタを追加すると、データは自動的に新クラスタにレプリケートされるため、バッチ ジョブも同じデータを読めます。そのうえで、オンライン アプリ用のアプリ プロファイルは既存クラスタへ、バッチ分析用のアプリ プロファイルは新クラスタへ、それぞれ単一クラスタ ルーティングで向ければ、バッチ ジョブの重いスキャンが既存クラスタの CPU を消費することはなく、両ワークロードを物理的に分離できます。なお現在は、Bigtable の Data Boost（サーバーレスの分離されたコンピューティングで読み取り専用の分析ジョブを実行する機能）も選択肢になりますが、本問の選択肢の中ではアプリ プロファイルによる分離が最適解です。

【誤りの選択肢】
A：ノードを手動追加すると処理能力は上がりますが、オンライン ワークロードとバッチ ジョブは同じクラスタ・同じノードを共有したままです。大規模スキャンによる CPU やディスクの負荷が既存ワークロードのレイテンシに影響する可能性が残り、「影響を与えない」という分離の要件を保証できません。
B：クラスタを追加してもマルチクラスタ ルーティングを使うと、リクエストは最も近い利用可能なクラスタに自動的に振り分けられるため、バッチ ジョブのリクエストが既存アプリと同じクラスタに送られる可能性があります。マルチクラスタ ルーティングは高可用性（自動フェイルオーバー）のための設定で、ワークロード分離には単一クラスタ ルーティングが必要です。
D：自動スケーリングは CPU 使用率などに応じてノード数を増減させますが、A と同様に同じクラスタを共有するため分離にはなりません。また負荷急増からスケールアウト完了までに時間差があり、その間は既存ワークロードが影響を受けます。

【参考】
アプリ プロファイルの概要 | Bigtable
レプリケーションの概要 | Bigtable
レプリケーション構成の例 | Bigtable
この問題のページを開く →
問題 13Google が推奨するプラクティスに従いながら、より高速な性能と高可用性を確保できるよう、Google Cloud 上…革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
あなたの組織は、大量かつ低レイテンシのセンサーデータ取り込みシステムをデプロイしています。復元力（レジリエンス）が極めて重要で、ワークロードは時間の経過とともに大幅に増加すると見込まれています。Google が推奨するプラクティスに従いながら、より高速な性能と高可用性を確保できるよう、Google Cloud 上のデータベース層を設計する必要があります。どうすればよいですか。

選択肢と解説

  • 1
    複数の Bigtable クラスタをデプロイし、それらの間でデータを手動でシャーディングし、フォールト トレランスのためのアプリケーション ロジックを構築する。
  • 2
    単一ゾーンの Bigtable クラスタをデプロイし、書き込みスループットが最大になるようにアプリケーション コードを最適化する。
  • 3
    単一リージョンの Bigtable インスタンスをデプロイし、データの耐久性を最大化するためにノード数を増やす。
  • ✓
    マルチゾーンの Bigtable クラスタをプロビジョニングし、レプリケーションを構成し、アプリケーションの負荷テストを実施し、パフォーマンス モニタリングを設定する。

解説

【正解】D

【0からの解説】
①前提知識：Bigtable は、IoT やセンサーの時系列データのような大量の書き込みを低レイテンシで処理できるフルマネージドのワイドカラム型 NoSQL データベースです。Bigtable の「インスタンス」は 1 つ以上の「クラスタ」を持ち、各クラスタは 1 つのゾーンに配置されます。インスタンスに複数のクラスタ（同一リージョンの別ゾーンや別リージョン）を追加すると、Bigtable がクラスタ間のレプリケーションを自動で行います。アプリ プロファイルでマルチクラスタ ルーティングを使うと、リクエストは最も近い利用可能なクラスタに自動でルーティングされ、ゾーンやクラスタの障害時も自動フェイルオーバーされるため、高可用性（SLA 99.99% 以上）が得られます。ノードを追加（またはオートスケーリング）すればスループットはほぼ線形に伸び、データの分散（シャーディング）も Bigtable が自動で行います。

②要件と制約語の整理：(1) 大量・低レイテンシの取り込み、(2) レジリエンスが極めて重要（＝高可用性）、(3) ワークロードが大幅に増加（＝スケーラビリティ）、(4) Google 推奨のプラクティスに従う。

③正解の理由：D は、複数ゾーンにクラスタを配置してレプリケーションを構成することで、ゾーン障害に耐える高可用性を実現します。さらに、負荷テスト（ストレステスト）で想定ピーク時の性能とノード数を事前に検証し、Cloud Monitoring などでパフォーマンス（CPU 使用率、レイテンシ、レプリケーション遅延など）を監視して、増加するワークロードに合わせてスケールできるようにしています。これは Bigtable の公式ドキュメントで推奨される「レプリケーションによる可用性確保」「本番前の性能テスト」「継続的なモニタリング」をすべて含む構成です。なお、厳密には Bigtable のクラスタは単一ゾーンに配置されるため、「マルチゾーンのクラスタ」は「複数ゾーンにクラスタを持つインスタンス」と読み替えて理解してください。

【誤りの選択肢】
A：複数のクラスタ（実質的には別々のインスタンス）にデータを手動でシャーディングし、フォールト トレランスをアプリ側で実装するのは、Bigtable が自動で提供するデータ分散とレプリケーション／自動フェイルオーバーをわざわざ自作することになります。運用負荷とバグのリスクが大きく、Google 推奨のやり方ではありません。
B：単一ゾーンのクラスタはそのゾーンに障害が起きるとサービス全体が停止するため、「レジリエンスが極めて重要」という要件を満たしません。アプリ コードを最適化しても可用性の問題は解決しません。
C：ノード数を増やすとスループット（処理能力）は向上しますが、データの耐久性や可用性は向上しません。Bigtable のデータは Colossus（分散ストレージ）に保存されており、耐久性はノード数とは無関係です。単一クラスタのままではゾーン障害時の可用性も確保できません。

【参考】
レプリケーションの概要 | Bigtable
アプリ プロファイルの概要 | Bigtable
Monitoring | Bigtable
この問題のページを開く →
問題 14アプリケーションをどのように開発すべきですか。複数のデータベース技術にまたがるソリューションの管理
問題
AlloyDB for PostgreSQL をバックエンドのデータストアとして接続する Python アプリケーションを開発しています。組織のセキュリティ要件では、データベース認証にユーザー名とパスワードを使用することが許可されていません。アプリケーションをどのように開発すべきですか。

選択肢と解説

  • 1
    任意の PostgreSQL 互換の Python クライアントを使用する。Identity-Aware Proxy（IAP）を使用して AlloyDB クラスタに接続する。
  • ✓
    AlloyDB Python コネクタを使用する。接続には自動 IAM 認証を使用する。
  • 3
    AlloyDB Python コネクタを使用する。gcloud alloydb instance update コマンドに --ssl-mode=ENCRYPTED_ONLY オプションを指定して、AlloyDB への SSL 接続を強制する。
  • 4
    任意の PostgreSQL 互換の Python クライアントを使用する。接続時に、サービス アカウント名と認証情報をそれぞれユーザー名とパスワードとして使用する。

解説

【正解】B

【0からの解説】
①前提知識：AlloyDB for PostgreSQL は Google Cloud のフルマネージドの PostgreSQL 互換データベースです。AlloyDB には「IAM データベース認証」があり、データベース固有のパスワードではなく、Google Cloud の IAM プリンシパル（ユーザーやサービス アカウント）の認証情報でデータベースにログインできます。さらに、AlloyDB 言語コネクタ（Python・Java・Go など向けのライブラリ。Python では google-cloud-alloydb-connector）を使うと、mTLS による暗号化接続と IAM による接続の認可を自動で処理でき、enable_iam_auth=True を指定すると「自動 IAM データベース認証」が有効になります。この場合、コネクタがアプリケーションの実行環境のサービス アカウント（アプリケーションのデフォルト認証情報）から OAuth 2.0 アクセス トークンを取得・更新して自動的にログインに使うため、コード内にパスワードを一切持たずに接続できます。

②要件と制約語の整理：(1) Python アプリから AlloyDB に接続、(2) データベース認証に「ユーザー名とパスワード」を使ってはならない。

③正解の理由：B の AlloyDB Python コネクタ＋自動 IAM 認証であれば、データベースのユーザーは IAM プリンシパル（サービス アカウント）として作成され、認証は IAM のトークンで行われるため、パスワードの保管・ローテーションが不要になります。アクセス権も IAM ロール（AlloyDB データベース ユーザーのロールなど）で一元管理でき、セキュリティ要件を満たす Google 推奨の方法です。

【誤りの選択肢】
A：Identity-Aware Proxy（IAP）は、Web アプリケーションや VM への SSH / TCP 転送などへのアクセスを ID で制御するサービスで、AlloyDB のデータベース認証を置き換えるものではありません。IAP を経由してもデータベースへのログインには別途データベースの認証（ユーザー名・パスワードなど）が必要です。
C：--ssl-mode=ENCRYPTED_ONLY は通信の暗号化（SSL/TLS）を強制する設定であり、認証方式を変えるものではありません。暗号化されていても、データベースへのログインにはユーザー名とパスワードを使い続けることになるため、要件を満たしません。
D：サービス アカウントの名前と認証情報（サービス アカウント キーなど）をユーザー名・パスワードとして渡すのは、結局「ユーザー名とパスワード」による認証と同じ形で、長期間有効な秘密情報をアプリ内に保持することになります。サービス アカウント キーの配布・保管は Google が推奨しないセキュリティ上のリスクでもあります。IAM 認証では短期間有効なアクセス トークンを使うのが正しく、コネクタの自動 IAM 認証を使えばトークンの管理も不要です。

【参考】
AlloyDB 言語コネクタの概要 | AlloyDB for PostgreSQL
AlloyDB 言語コネクタを使用して接続する | AlloyDB for PostgreSQL
AlloyDB for PostgreSQL の IAM データベース認証
この問題のページを開く →
問題 15次の要件をすべて満たす必要があります。革新的でスケーラブルかつ高可用性のクラウド データベース ソリューションの設計
問題
あなたはヨーロッパの大手銀行で働く DBA です。ビジネス クリティカルな銀行アプリケーションが、オンプレミス データセンターの Oracle 12.2 で稼働しています。あなたは、オンプレミスの Oracle データベースを AlloyDB に移行してモダナイズすることを決定しました。次の要件をすべて満たす必要があります。 • オンプレミスにとどまり、オープンソースのポータビリティを維持する。 • データ所在地（データ レジデンシー）に関する規制要件を満たす。 • OLTP と OLAP の両方のワークロードをサポートする。 • 高可用性（HA）モードと自動フェイルオーバーを維持する。 どうすればよいですか。

選択肢と解説

  • 1
    オンプレミスのスタンドアロン VM に AlloyDB Omni をデプロイし、AlloyDB for PostgreSQL で障害復旧（DR）を設定する。
  • 2
    Database Migration Service を使用して AlloyDB for PostgreSQL に移行する。
  • ✓
    Kubernetes ベースの AlloyDB Omni データベース クラスタをオンプレミスにデプロイする。AlloyDB Omni Kubernetes オペレーターを使用して HA を有効にし、Oracle データベースを Omni に移行する。
  • 4
    オンプレミスの VM に Docker ベースのコンテナとして AlloyDB Omni をデプロイして HA を有効にし、Oracle データベースを Omni コンテナに移行する。

解説

【正解】C

【0からの解説】
①前提知識：AlloyDB for PostgreSQL は Google Cloud 上のフルマネージドな PostgreSQL 互換データベースです。これに対し AlloyDB Omni は、同じ AlloyDB のエンジン（列指向エンジンによる分析クエリの高速化、自動メモリ管理など）を、オンプレミスや他クラウドなど任意の環境で自分で実行できるダウンロード版です。PostgreSQL 互換なので、標準の PostgreSQL ツールや拡張機能がそのまま使え、特定ベンダーへのロックインを避けられます（オープンソースのポータビリティ）。AlloyDB Omni には Kubernetes オペレーターが提供されており、データベース クラスタのマニフェストでスタンバイ数を指定するだけで HA 構成を作れます。オペレーターはプライマリとスタンバイを定期的にヘルスチェックし、プライマリの障害を検知すると自動でスタンバイを昇格させる自動フェイルオーバーを行い、故障したスタンバイの自動再作成（ヒーリング）や、計画的なスイッチオーバーも管理します。

②要件と制約の整理：(1) オンプレミスにとどまる＝Google Cloud のマネージド AlloyDB には移せない。(2) データ レジデンシー規制＝データを自社データセンター内に保持する。(3) OLTP と OLAP の両立＝AlloyDB の列指向エンジンが有効。(4) HA と自動フェイルオーバーを維持＝障害時に人手を介さず切り替わる仕組みが必要。

③正解の理由：Kubernetes 上に AlloyDB Omni のデータベース クラスタを構築し、AlloyDB Omni Kubernetes オペレーターで HA を有効化すれば、オンプレミスのままデータを国外に出さずに、AlloyDB エンジンによる OLTP / OLAP の両立と、オペレーター管理の自動フェイルオーバーをすべて満たせます。Oracle からの移行は、スキーマとコードを PostgreSQL 互換に変換（Ora2Pg などのツールや Database Migration Service の変換機能で生成した DDL を活用）したうえで Omni に移します。4 つの要件をすべて満たすのは C だけです。

【誤りの選択肢】
A：スタンドアロン VM に単一の Omni をデプロイするだけでは HA と自動フェイルオーバーがありません。さらに DR 先を Google Cloud 上の AlloyDB for PostgreSQL にすると、データがオンプレミス外に複製されるため「オンプレミスにとどまる」「データ レジデンシー」の要件に反するおそれがあります。
B：Database Migration Service で Google Cloud 上の AlloyDB for PostgreSQL に移行すると、データベースはクラウドに移ります。「オンプレミスにとどまる」という最初の要件を満たしません。
D：単一 VM 上の Docker コンテナは、その VM 自体が単一障害点になります。コンテナ単体の AlloyDB Omni では、オペレーターによるヘルスチェック・自動昇格・スタンバイの自動ヒーリングといった仕組みが提供されず、HA を組むには Patroni などを自前で構築・運用する必要があります。自動フェイルオーバーを確実かつ低い運用負荷で実現するという点で、Kubernetes オペレーターを使う C に劣ります。

【参考】
AlloyDB Omni のドキュメント
Oracle から AlloyDB for PostgreSQL への移行の概要 | Database Migration Service for heterogeneous Oracle to AlloyDB for PostgreSQL
この問題のページを開く →

GCP-PCDBE 模擬問題集についてよくある質問

GCP-PCDBE の練習問題は無料で試せますか？

はい。GCP-PCDBE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

GCP-PCDBE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。