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