Google Cloud認定 Professional Cloud Database Engineer WEB問題集

正解：D

1. 「ホットスタンバイ」による継続的レプリケーション

• 何をするか: オンプレミスの現行データベース（マスター）と、Compute Engine (GCE) 上に構築したPostgreSQLインスタンス（スタンバイ/レプリカ）の間で、ストリーミングレプリケーションを設定します。

• 効果: GCE上のスタンバイインスタンスは、オンプレミスのマスターに加えられたすべての変更（トランザクション）をほぼリアルタイムで受け取り、適用します。これにより、両データベースのデータ同期が継続的に行われます。

• ダウンタイムの最小化: 移行（カットオーバー）の瞬間までデータの同期が保たれるため、移行ウィンドウで必要な作業は、レプリカをマスターに昇格させることと、アプリケーションの接続先を切り替えることの2つだけになり、ダウンタイムが数秒〜数分に抑えられます。

2. 「PgBouncer」による接続の素早い切り替え

• PgBouncerの役割: PgBouncerはPostgreSQLの接続プーラーです。アプリケーションとデータベースの間に位置し、アプリケーションの接続要求をデータベースへの実際の接続に仲介します。

• ダウンタイムの最小化: 移行のカットオーバー時、以下の手順でアプリケーションのダウンタイムを最小化します。

  1. PgBouncerを通じて行われている**既存の接続を一時的にドレイン（切断）**させます。

  2. GCE上のホットスタンバイを新しいマスターに昇格させます。

  3. PgBouncerの設定を、新しいGCEマスターを指すように変更します。

  4. アプリケーションは、PgBouncerを介して新しいGCEマスターへの接続を再確立します。

• 利点: PgBouncerを使用することで、アプリケーション側の設定（IPアドレスやポートなど）を変更することなく、新しいデータベースインスタンスにトラフィックを迅速に切り替えることができます。これにより、アプリケーションの再デプロイや設定変更に伴う複雑さや時間的コストが削減されます。

まとめ

このDのソリューションは、以下の理由から「最小限のダウンタイム」を実現するための最も適切な技術的アプローチです。

この手法は、マネージドサービス（CのDMSなど）が特定のターゲット（この場合はCompute Engine）をサポートしていない場合に、高可用性やゼロダウンタイム移行を実現するための最も信頼性の高い手動設定のアプローチとなります。

正解：C

この問題の鍵は、マルチクラスター・インスタンスにおいて、高い可用性と自動フェイルオーバーを実現するための Bigtable の設定です。

1. アプリプロファイル (App Profile) とルーティング

Bigtableでは、アプリケーションからのトラフィックをどのようにクラスターにルーティングするかをアプリプロファイルで制御します。

• シングルクラスター・ルーティング: 特定の単一のクラスターにトラフィックを送信します。そのクラスターがダウンすると、リクエストは失敗します。

• マルチクラスター・ルーティング: 複数のクラスターをグループ化し、高可用性を実現します。トラフィックは自動的に最も近い利用可能なクラスターに送信されます。

2. 要件の達成

問題の要件は、「いずれかのクラスターが利用不能になった場合でも読み取り/書き込みを受け付け続け、自動的にもう一方のクラスターにルーティングされる」ことです。

• 可用性の維持と自動ルーティング: これは、まさに マルチクラスター・ルーティング が提供する機能です。これにより、両クラスター間でレプリケーションが有効になり、一方のクラスターがダウンしても、Bigtableクライアントライブラリが自動的に健全なクラスターに切り替えます（フェイルオーバー）。

3. カスタムアプリプロファイルの使用

• デフォルトのアプリプロファイル: デフォルトのプロファイルは、インスタンス作成時に自動で作成され、通常はシングルクラスター・ルーティングを使用するように設定されます（特に単一クラスターのインスタンスの場合）。

• カスタムの必要性: Bigtableは、アプリケーションごとに異なるトラフィックのルーティング、分離、またはリトライ動作を定義するためにカスタムアプリプロファイルの作成を推奨しています。特に、ルーティング戦略（シングルからマルチへ）を変更したり、特定のワークロードに対してフェイルオーバー動作を制御したりする場合は、デフォルトを変更するのではなく、新しいカスタムアプリプロファイルを作成するのがベストプラクティスです。

したがって、要件である「自動フェイルオーバーによる可用性の確保」を満たすために マルチクラスター・ルーティング を選択し、かつ Bigtable の設計原則に従って カスタムアプリプロファイル を作成するのが正解となります。

正解：D

この問題の要件は、「保存されたデータ（つまり保存時のデータ）が独自のキーで暗号化されること」です。

1. データの暗号化のタイプ

データベースにおける暗号化には主に以下の3つのタイプがあります。

• 転送中の暗号化 (Encryption in transit): データがネットワーク上を移動する際に保護すること。

• 保存時の暗号化 (Encryption at rest): ディスクなどのストレージにデータが保存されているときに保護すること。

• 独自のキー管理: Googleが管理するキーではなく、ユーザー自身がキーの作成、ローテーション、アクセス制御を管理すること。

2. 選択肢の検証

• A. Cloud Storage へのエクスポート (CSEK):

  • これはCloud SQL データベース内の保存されたデータを独自のキーで保護するソリューションではありません。データをCloud Storageに移動させているだけです。

  • CSEK (Customer-Supplied Encryption Keys) は、ユーザーがキーを提供しますが、この問題の直接的な解決策ではありません。

• B. Cloud SQL Auth Proxy の使用:

  • Auth Proxy は、**安全な接続（転送中の暗号化）**と IAM 認証を容易にするためのツールであり、保存時のデータの暗号化キーを管理する機能は提供しません。

• C. SSL 接続の使用:

  • SSL/TLS は、転送中のデータを暗号化するために使用されます。保存時のデータの暗号化には関係ありません。

• D. 顧客管理の暗号化キー (CMEK) の使用:

  • CMEK (Customer-Managed Encryption Keys) は、この要件を直接的かつ完全に満たす Google Cloud の機能です。

  • Cloud SQL で CMEK を構成すると、データベースのディスクに保存されるデータ（データベースファイル、バックアップ、リードレプリカのデータなど）が、Google Cloud KMS (Key Management Service) でユーザーが管理するキーを使用して暗号化されます。

  • これにより、「保存されたデータが独自のキーで暗号化される」という要件が満たされます。

したがって、Cloud SQL データベースの保存データを独自のキーで保護するための公式かつ適切な方法は、CMEK を使用することです。

正解：B

この問題の鍵は、提示されたワークロードの特性、特に「ストリーミング時系列データ」「サブ秒の低レイテンシ」「高いスケーラビリティ」「高スループット」をすべて満たす Google Cloud のデータベースを選択することです。

1. 要件の分析とデータベースの適性

2. 選択肢の検証

• A. Firestore (NoSQL ドキュメントデータベース):

  • 適さない点: 数百テラバイトという大規模なデータセットや、毎秒 10,000 レコードという高い書き込みスループットを扱う設計にはなっていません。低レイテンシな単一ドキュメントの操作には優れますが、時系列ベースの大規模なスキャンには適していません。

• B. Bigtable (NoSQL ワイドカラムデータベース):

  • 最も適切: Bigtable は、ペタバイト級の時系列データ、金融データ、IoT データなどの大規模な分析ワークロードのために構築されたサービスです。

  • 低レイテンシ: 高速なランダムアクセスとキーベースの行スキャンに最適化されており、サブ秒のレイテンシ要件を満たします。

  • 高スループット: 秒間数万〜数十万の読み書きリクエストを処理する高いスケーラビリティとスループットを提供します。

• C. BigQuery (分析用データウェアハウス):

  • 適さない点: BigQuery は、大規模なデータに対するアドホックな複雑な分析クエリ（OLAP）に優れています。しかし、レイテンシは通常秒単位であり、サブ秒の低レイテンシでのスキャンや、リアルタイムなアプリケーションのトランザクション要件（OLTPに似た要求）には適していません。

• D. Cloud Spanner (グローバル分散リレーショナルデータベース):

  • 適さない点: Cloud Spanner は、グローバルな分散と強整合性が求められるトランザクション（OLTP）に優れています。しかし、時系列データや超高スループットのランダムアクセスを数百テラバイト規模で扱う場合、費用対効果や設計上の最適性において、Bigtableが明確に有利です。

したがって、大規模な時系列データを高スループットかつ低レイテンシで処理するという要件の組み合わせを満たす唯一のソリューションは Bigtable です。

正解：A

この問題の鍵となる要件は以下の3つです。

1. 高いトランザクション性 (Highly transactional): データの整合性、特に読み書き操作の原子性 (ACID特性) が極めて重要であること。

2. リレーショナルデータベース (Relational database): プレイヤーデータとインベントリデータの間に関係性があり、スキーマと整合性が必要であること。

3. 複数のリージョンで起動 (Launch in multiple regions): グローバルな低遅延と高い可用性が求められること。

1. 選択肢の検証

2. Cloud Spanner が最適である理由

Cloud Spanner は、Google Cloud が提供する唯一のマネージドデータベースであり、以下の特徴からこのユースケースに最適です。

• グローバルな整合性を持つリレーショナル: 従来のSQLデータベースの厳格なトランザクション整合性（ACID特性）とリレーショナルな構造を維持しながら、水平スケーラビリティとマルチリージョン構成を提供します。

• 高いトランザクション性: プレイヤーの認証やインベントリの更新（例: アイテムの購入/消費）のような重要な操作において、地理的な距離に関係なく、高い一貫性と原子性をグローバルに保証できます。

• マルチリージョン対応: Spanner はデータを複数のリージョンに同期的にレプリケートし、いずれかのリージョンがダウンしてもサービスが継続される高い可用性と、ユーザーの地理的な近接性に基づく低遅延を実現します。

結論として、リレーショナルな構造、高いトランザクション性、およびグローバルなマルチリージョンでの運用というすべての要件を満たすのは Cloud Spanner のみです。