表示モード
画像位置
文字位置
理解度の自動記録
Q1Google Professional Cloud Database Engineer
Q1. あなたの開発チームは、株式や為替などストリーミングで届く時系列の金融データを保存・分析するアプリケーションを構築しています。
サブ秒のレイテンシで時系列ベースのスキャンを行えるデータベースが必要です。
また、数百テラバイト規模までスケールでき、毎秒最大1万件の書き込みと毎秒最大200MBの読み取りに対応できることが求められています。
どのデータベースソリューションを選ぶべきですか。
解答を見る
正解：B. Bigtableを採用する。
Bigtableは取引履歴や株価などの金融時系列データの保存に適したワイドカラム型データベースです。SSD構成のBigtableは毎秒最大1万行の読み書きと最大220MB/秒のスキャンに対応し、サブ秒のレイテンシで数百TB規模までスケールできるため、本要件を満たします。
Firestoreと Cloud Spannerはトランザクション処理向けで時系列スキャンのスループットに劣り、BigQueryは分析向けであり低レイテンシのオンライン読み取りには不向きです。
Bigtable の概要（Google Cloud 公式ドキュメント）
Q2Google Professional Cloud Database Engineer
Q2. あなたは新規ウェブサービスのデータベース戦略を検討しています。
最初は1か国限定の小規模なパイロット運用から始め、将来的には世界中の数百万ユーザーへ展開する計画です。
メンテナンスによるダウンタイムを最小限に抑えつつ、サービスを24時間365日稼働させる必要があります。
どのように構成すればよいですか。
解答を見る
正解：A. Cloud Spannerをリージョナル構成で運用する。
Cloud Spannerはスキーマ変更などのメンテナンスをダウンタイムなしで行えるため、24時間365日稼働の要件に適します。パイロット段階は1か国のみなので、まずはコスト効率の良いリージョナル構成で始めるのが妥当です。
Spannerはインスタンス移動機能により、後からダウンタイムなしでマルチリージョン構成へ拡張できるため、将来のグローバル展開にも柔軟に対応できます。
Spanner インスタンスの移動（Google Cloud 公式ドキュメント）
Q3Google Professional Cloud Database Engineer
Q3. あなたの会社は、大量のバージョン管理された時系列データを扱う、24時間365日稼働のグローバルなリアルタイム分析基盤を開発しています。
急激なトラフィック増加に耐えるスケーラビリティと、ミッションクリティカルな運用を支える高可用性の両方を確保した設計が必要です。
どのように構成すればよいですか。
解答を見る
正解：C. 複数リージョンにまたがるマルチクラスターのBigtableインスタンスをレプリケーション付きで構築する。
複数リージョンにまたがるマルチクラスターのBigtableインスタンスは、フルマネージドのレプリケーションとマルチクラスタールーティングを備え、グローバルかつ24時間365日の可用性を実現します。リージョンをまたぐレプリケーションがミッションクリティカルな高可用性を担保し、オートスケーリングと時系列に最適化したスキーマがトラフィック急増への対応を支えるため、要件をすべて満たします。
単一クラスター（A）はリージョン障害に弱く、AlloyDB（D）はこの規模の時系列ワークロードには不向きです。
Bigtable レプリケーションの概要（Google Cloud 公式ドキュメント）
Q4Google Professional Cloud Database Engineer
Q4. あなたはフルマネージドのデータベースサービスの利用を検討している金融サービス企業に勤務しています。
消費者向けサービスのトラフィックは毎年一定の割合で増加し、加えて祝日前後には一時的に急増します。
そのため、データベース容量のアップグレードを頻繁に行う必要が生じています。
Cloud Spannerを採用し、同時実行性の高まりに合わせてハードウェア容量を自動的に増やす仕組みを組み込みたいと考えています。
どうすればよいですか。
解答を見る
正解：A. 線形スケーリング（linear scaling）を用いたオートスケーラーベースのアーキテクチャを構築する。
Cloud Spanner向けのAutoscalerツールには段階的（stepwise）・線形（linear）・ダイレクト（direct）の3つのスケーリング方式があります。stepwiseは小刻みな複数のピークに、directは開始時刻が既知のバッチ処理に適しています。
緩やかな増加傾向に加えて時折大きなピークが生じる本ケースには、利用率に応じて容量を比例的に増減させる線形スケーリングが最も適しているため、選択肢Aが正解です。
手動アップグレード（C・D）は自動化という要件を満たしません。
Autoscaler tool for Spanner（Google Cloud 公式ドキュメント）
Q5Google Professional Cloud Database Engineer
Q5. あなたはGoogle Cloud上で運用される急成長中スタートアップのデータベース管理者を務めています。
事業拡大に伴い、Cloud SQL for PostgreSQLのワークロードが指数関数的に増加しています。
パフォーマンス要件を維持しながら、データベースのコストを継続的に評価・最適化する先回りの戦略を導入する必要があります。
どうすればよいですか。
解答を見る
正解：C. Query Insightsを使ってパフォーマンスのボトルネックを特定・対処し、その推奨事項に基づいてインスタンスサイズを調整する。
Query Insightsは、Cloud SQL for PostgreSQLにおける低速クエリやリソースを大量消費するワークロード、パフォーマンスのボトルネックを継続的に可視化し、データに基づく最適化を可能にします。このインサイトを用いてインスタンスを適正サイズへ調整することで、パフォーマンス要件を満たしながら先回りでコストを最適化できる点が、単なる予算アラート（A）や手動レビュー（D）よりも優れています。
Query Insights を使用したクエリパフォーマンスの改善（Google Cloud 公式ドキュメント）
Q6Google Professional Cloud Database Engineer
Q6. あなたの会社では、Cloud SQLのディスク不足（out-of-disk）レコメンダーを用いて、本番データベースの直近30日間のストレージ使用傾向を分析しています。
運用チームはこの推奨事項をもとに、ストレージ状況を先回りで監視し是正措置を講じています。
ある時、インスタンスがディスク容量を使い切る可能性が高いという推奨事項を受け取りました。
このストレージアラートにはどう対応すべきですか。
解答を見る
正解：C. ストレージ容量を手動または自動で増やす。
ディスク不足レコメンダーがストレージ枯渇の可能性を示している場合、根本的かつ確実な対処は推奨に従いストレージ容量を増やすことです。Cloud SQLではストレージの自動増量を有効にするか手動で容量を引き上げることで、ダウンタイムなしにディスク枯渇を回避できるため、選択肢Cが正解です。
正規化や圧縮、スキーマ追加は根本的な容量不足の解決にはなりません。
ディスク不足レコメンダーの使用（Google Cloud 公式ドキュメント）
Q7Google Professional Cloud Database Engineer
Q7. あなたは、世界各地の公園に関する情報を保存するグローバルアプリケーションのデータベースアーキテクチャを設計しています。
アプリケーションはデータベースを読み取り専用で利用し、中央集約型のバッチジョブが毎晩データを更新します。
オープンソースかつSQL準拠のデータベースを選定したいと考えています。
どうすればよいですか。
解答を見る
正解：C. クロスリージョンレプリカを持つCloud SQL for PostgreSQLを利用する。
「オープンソースでSQL準拠」という要件により、独自エンジンのSpanner（D）やNoSQLのBigtable（A）・Memorystore（B）は除外されます。PostgreSQLはオープンソースかつSQL準拠であり、Cloud SQL for PostgreSQLのクロスリージョンレプリカが世界各地からの読み取り専用アクセスに低レイテンシで対応できるため、選択肢Cが最適です。
毎晩のバッチ更新はプライマリで行い、各地のレプリカで読み取りを処理します。
クロスリージョンレプリカ（Google Cloud 公式ドキュメント）
Q8Google Professional Cloud Database Engineer
Q8. あなたの会社は、ミッションクリティカルなグローバル決済ゲートウェイアプリケーション向けに、Google Cloudのデータベース選定を進めています。
アプリケーションは世界中のユーザーに対して24時間365日利用可能であり、水平方向にスケーラブルで、オープンソースデータベースをサポートしている必要があります。
加えて、自動シャーディングが可能で、99.999%の可用性と強整合性を備えたフルマネージドデータベースを選ぶ必要があります。
どうすればよいですか。
解答を見る
正解：D. Cloud Spannerを選ぶ。
Cloud Spannerは自動シャーディングによる水平スケーリングを備えたフルマネージドのリレーショナルデータベースで、グローバル分散と強整合性（外部整合性）を両立します。マルチリージョン構成のSpannerは99.999%の可用性SLAと強いトランザクション整合性を提供し、グローバル決済ゲートウェイの要件にすべて合致するため、選択肢Dが正解です。
Cloud SQLは自動シャーディングや99.999%可用性に対応せず、BigtableはACIDトランザクションの強整合性を満たしません。
Spanner のインスタンス構成と可用性（Google Cloud 公式ドキュメント）
Q9Google Professional Cloud Database Engineer
Q9. あなたは、100個のデータベースで利用される高可用性（HA）構成のCloud SQL for PostgreSQLインスタンスを設計しています。
各データベースには、オンプレミス環境から移行された80個のテーブルが含まれています。
これらのデータベースを利用するアプリケーションは米国内の複数リージョンに分散しており、読み取り・書き込みの両方を低レイテンシで行えるようにする必要があります。
どうすればよいですか。
解答を見る
正解：C. us-central1リージョンにHAを有効化したCloud SQLインスタンスを4つデプロイし、us-central1・us-east1・us-west1にリードレプリカを作成する。
100個のデータベース（合計8,000テーブル）を扱うには、1インスタンスあたりのデータベース・テーブル数の上限を考慮した十分なインスタンス数が必要です。HAを有効化した4つのインスタンスで可用性を確保し、各リージョン（us-central1・us-east1・us-west1）にリードレプリカを配置することで、書き込みの低レイテンシと地域分散した読み取りの両方を満たせるため、選択肢Cが適切です。
HAなしの構成（B・D）は可用性要件を満たしません。
Cloud SQL の高可用性（Google Cloud 公式ドキュメント）
Q10Google Professional Cloud Database Engineer
Q10. あなたの組織は、重要なオンプレミスのMySQLデータベースをCloud SQL for MySQLへ移行する必要があります。
オンプレミスのデータベースはCloud SQLがサポートするバージョンのMySQLで稼働しており、InnoDBストレージエンジンを使用しています。
トランザクションを保持しながら、ダウンタイムを最小限に抑えて移行を行う必要があります。
どうすればよいですか。
解答を見る
正解：A. Database Migration Serviceでオンプレミスのデータベースに接続し、継続的レプリケーションを選択する。移行完了後にCloud SQL for MySQLインスタンスをプロモートし、アプリケーションをそちらへ接続する。
ダウンタイムを最小化しつつトランザクションを保持してMySQLを移行するには、Database Migration Service（DMS）の継続的レプリケーションが最適です。DMSは初期ロード後に変更をリアルタイムで同期し続け、準備が整った時点でCloud SQLインスタンスをプロモートしてカットオーバーできるため、ダウンタイムを大幅に削減できます。
mysqldumpを用いるC・Dはアプリ停止が必要でダウンタイムが大きく、Cloud Data Fusion（B）も計画停止を要します。
Database Migration Service（MySQL）（Google Cloud 公式ドキュメント）