G-genの杉村です。Google Cloud (旧称 GCP) の認定資格である Professional Cloud Database Engineer 資格の試験対策に有用な情報を記載します。

基本的な情報

Professional Cloud Database Engineer とは

Professional Cloud Database Engineer は Google Cloud (旧称 GCP) の認定資格の一つです。当試験は Preview 期間を経て、 2022 年 7 月に Generally Available (一般公開) となりました。

当試験は Professional レベルの資格であり Google Cloud の各種データベース系サービスの知識・技能 に関する問題が出題されます。

試験時間は 120 分、問題数は 50 問。

2023 年 1 月現在は 英語版のみ の提供です。

難易度

Professional Cloud Database Engineer 試験の難易度は、主観的ではありますが 中程度 と言えます。

基本情報技術者試験〜応用情報技術者試験レベルの IT 一般に関する知識に加えて Associate Cloud Engineer 試験レベルの Google Cloud の基礎知識があれば、追加の学習を 1 〜 2 ヶ月程度することで十分でしょう。

受験者に推奨される経験として公式サイトには「データベースと IT に関する全般的な経験 5 年以上（Google Cloud データベースソリューションの実務経験 2 年以上を含む）」とありますが、これに満たなくても、データベース (DBMS) に関する一般的な知識とある程度の試験対策で十分に合格を狙える資格となっています。

英文に関しては、そこまで複雑で長大なシチュエーションが出題されるわけではありません。日常的に英語版ドキュメントを読み、単語や言い回しに慣れておくことが望ましいです。

出題傾向

Google Cloud におけるインフラ寄りのデータベース管理に関する出題がされます。例として「スケーラブルで可用性の高いアーキテクチャを組むにはどういったサービスと機能を選べばいいか」「オンプレミスのデータベースからクラウドへの移行手法」「モニタリングやパフォーマンス測定」「バックアップなどの管理運用」といった内容です。

一方で SQL の記述やデータモデリングに関する知識は問われません。

Cloud SQL に関する問題が大半を占めており、続いて Cloud Spanner、 Bigtable、 Firestore などのデータベースサービスが続き、 Database Migration Service (DMS) などの移行ツールやデータベース移行手法も出題されます。

当試験では BigQuery など分析系データベースに関する出題は ありません 。データ分析に関する出題は、名前はよく似ているものの全く別の Google Cloud 認定資格である Professional Data Engineer 試験が担っています。データ分析に関する知見を磨きたい方は、そちらの試験の合格を目指して学習する方が望ましいでしょう。

試験対策

以下の勉強方法はあくまで一例であり、最適な方法は、受験者の予備知識や経験によって異なるものとご了承ください。

Associate Cloud Engineer 試験を学習し、合格することで Google Cloud の基本的な知見を得る
公式の試験ガイドで試験範囲を理解する
Cloud SQL の知識を全体的に学ぶ
Cloud Spanner、Bigtable、Firestore、Oracle DMS などよく問われるサービスの公式ドキュメントを読んで学習する
当記事の出題傾向を読み足りない知識領域をカバーする学習を行う

当記事ではこれ以降、出題傾向や勉強すべき内容を解説します。とはいえ、これらが全てではありません。あくまで公式の試験ガイドを基準として、自分に足りない知識を補ってから試験に挑むようにしてください。

Cloud SQL

基本的な知識

Cloud SQL は当試験に向けて最も押さえておくべきサービスです。半分以上が Cloud SQL に関する知識・経験を問うものと思っていいでしょう。

以下の徹底解説記事を読み、また記事中のリンクから公式マニュアルへ飛んで詳細を把握するなどしてまずは Cloud SQL の全体像を掴んでください。

blog.g-gen.co.jp

高可用性構成におけるフェイルオーバーの仕組み、バックアップやダンプのエクスポート、モニタリング、接続方法などについては、上記記事上のリンクから公式マニュアルに飛んでより詳細を把握しておいて損はありません。

接続と認証・認可

Cloud SQL インスタンスへの接続は独特です。徹底解説記事や公式ドキュメントを読み、 Cloud SQL で Private IP アドレスを構成した際のマネージドネットワークへのプライベートサービスアクセスの仕組みや、 Cloud SQL Auth Proxy など特有のキーワードを押さえてください。以下がキーワードです。

Cloud SQL インスタンスへの External IP アドレスを使った接続と Private IP アドレスを使った接続
- External IP : 承認されたネットワーク
- Internal IP : プライベートサービスアクセス
  - 似た用語である「Private Google Access」と間違えないこと（名前が似ているが Private Google Access は限定公開の Google アクセスのこと）
Cloud Auth Proxy
- Cloud Auth Proxy とは
- IAM データベース認証とは
- データベースフラグ cloudsql.iam_authentication（参考）

高可用性（HA）

高可用性構成（HA 構成）とは

前掲の徹底解説記事にあるように、高可用性（HA）構成とリードレプリカは、似ていますが異なるものです。目的はそれぞれ「可用性」と「負荷分散」である点に留意してください。

選択肢には HA 構成を選ぶか、リードレプリカを選ぶか迷う場合は、それぞれの機能の本来の目的を考えれば、正しい選択肢が選べます。

フェイルオーバー

HA 構成でのフェイルオーバーの挙動は公式ドキュメントで確認できます。短い RTO（Recovery Time Objective）が求められる場合に HA 構成が有用であることが分かります。

参考 : フェイルオーバーの概要

また HA 構成においてはテスト目的やフェイルバック等のためにフェイルオーバーを 意図的に発生 させることができます。コンソールから実行できるほか gcloud sql instances failover ${PRIMARY_INSTANCE_NAME} というコマンドを使います。

HA 構成への変更

シングル構成の既存インスタンスを HA 構成に、後から変更することができます（再起動が発生します）。

変更にはコンソールからの操作か、あるいは gcloud sql instances patch コマンドを使用します。このコマンドは HA 構成への変更だけでなく、 vCPU やメモリ量を変更するとき等にも使いますので、覚えておいて損はありません。

リードレプリカ

リードレプリカとは

リードレプリカは読み取り専用のコピーインスタンスです。メインであるプライマリインスタンスから非同期レプリケーションを受けて、読み取りリクエストを受け付けます。

基本的な目的は読み取りワークロードの負荷分散ですが、プライマリインスタンスへの昇格も可能なため、リージョンを跨いだ DR 目的にも利用されます。この利用用途をしっかり把握してください。

非同期レプリケーション

HA 構成が同期レプリケーションであるのに対し、リードレプリカは非同期レプリケーションです。アプリケーションがトランザクションをコミットしても、内容が同期されるまでにラグが発生します。

レプリケーションラグは Cloud Monitoring のメトリクスで確認可能です。

また上記リンク先ドキュメントから、レプリケーションラグを最適化する方法も確認しておきましょう。

非同期レプリケーションであるため、プライマリインスタンスで障害が起き、リードレプリカにフェイルオーバーした際、データに不整合が発生する場合もあります。これが原因で、プライマリインスタンスで問題なかった処理が、昇格後のリードレプリカではエラーになるといったケースも想定できます。

同期パフォーマンスの改善

リードレプリカへのデータ同期は非同期であるため、ラグが発生します。同期のパフォーマンスが問題になる場合、並列レプリケーション（parallel replication）を設定できます。

設定手順は以下のようになります。どちら（プライマリか、リードレプリカか）のインスタンスにどの順番で設定を行うか、把握しておきましょう。

リードレプリカでレプリケーションを無効化する
リードレプリカのフラグでパラレルレプリケーションを有効化する
リードレプリカでレプリケーションを再開する
必要に応じて、プライマリインスタンスのフラグでパフォーマンスを調整する

参考 : 並列レプリケーションを構成する

フェイルバック

リードレプリカが昇格したあと、元のプライマリインスタンスにボタン1つでフェイルバックするということはできません。

元のリージョンにフェイルバックしたい場合、昇格したインスタンスから再度、元のリージョンにリードレプリカを作り直し、そのインスタンスを昇格させるという手順が必要になります。

参考 : 元のプライマリリージョンにフォールバックする

バックアップ・リストア

Cloud SQL の基本的なバックアップ・リストアの仕様は解説記事から確認しておきましょう。

また Cloud SQL Serverless Export 機能を確認しておいてください。 Cloud Storage にダンプファイルをエクスポートする機能です。同機能では一時的なエクスポート用インスタンスが自動的に作成され、このインスタンスに対してダンプ処理が走るので、本番インスタンスに負荷がかかりません。

モニタリング

Cloud SQL のリソースモニタリングは Cloud Monitoring を使って行います。何も設定しなくても Cloud Monitoring がメトリクスを収集します。

これに加えて当試験でたびたび問われるのは Query Insights 機能です。 Cloud SQL で稼働するデータベースにおいて、負荷の高い SQL やその実行計画を確認できます。

問題文や選択肢の中で Cloud SQL Insights と表記されていることもありますが Query Insights と同じものを指しています。

またアプリケーション側で ORM を使っている場合でも、Sqlcommenter というオープンソースライブラリを使うことで、SQL の特定に役立ちます。

暗号化

Cloud SQL 利用の際のセキュリティ要件として、「データを暗号化する」「暗号鍵は自分で管理する」「暗号鍵の所在地はコントロールできる」「データへのアクセス制御を厳密にする」などがある際の対応を問われます。

Cloud KMS ではユーザー側で用意した暗号鍵を登録・管理でき、 KMS に登録した鍵を使って Cloud SQL のストレージを暗号化できます。このユーザー側で管理する鍵のことを CMEK (Customer Managed Encryption Key) といい、大事なキーワードになります。

Google Cloud では何もしなくてもデフォルトでストレージが暗号化されますが、この場合の鍵は Google 側で管理されます。ユーザー側で管理しなくてよいのが魅力ですが、各種セキュリティ監査要件などの要求によりユーザー側で鍵を管理する必要がある際は、ユーザー側で鍵を用意して Cloud KMS に登録し (= CMEK) この鍵を使って Cloud SQL のストレージを暗号化します。

blog.g-gen.co.jp

アップデート・メンテナンス

スペック変更

Cloud SQL は構築後も vCPU やメモリ量を変更することができます (再起動が伴います) 。

コンソール画面から編集できる他、 gcloud sql instances patch コマンドで変更が可能です (このコマンドは前述の通り既存インスタンスを HA 構成に変更するとき等にも使われます) 。

メンテナンスウインドウ

データベースのマイナーバージョンへのパッチや OS / Cloud SQL 自体のパッチなどはメンテナンスウインドウの時間帯で適用されます。

時間は 1 時間のウインドウで曜日・時間が指定できます。また 最大 90 日間のメンテナンス拒否期間 が設定でき、この期間はメンテナンスを延期できます。業務繁忙期にメンテナンスを避けたい、などのシチュエーションが考えられます。

Cloud Spanner

Cloud Spanner の基本

Cloud Spanner はリレーショナルデータベースでありながら分散アーキテクチャであるという変わった DBMS です。Cloud Spanner の学習には以下の記事をご参照ください。

blog.g-gen.co.jp

Cloud Spanner のユースケースや、主要なキーワードを押さえておきましょう。

グローバルにまたがる（リージョンをまたぐ）アプリから利用する
リレーショナルデータベースである
トランザクション処理（ACID 特性を持つ）
99.999 % の SLA
自動シャーディング

テーブル設計

Cloud Spanner は分散アーキテクチャであり、データが複数のノードに分散して保管されます。

データは主キーの範囲に基づいて分散先のノードが決まるため、主キーの設計を誤ると、データが特定ノードに集中してホットスポットができてしまいます。複数ノードに負荷を分散させるためには、ホットスポットを回避するような主キー設計をする必要があります。

参考 : スキーマとデータモデル

バックアップとステイル読み取り

Spanner ではバックアップを取得することが可能です。そのバックアップからは、別インスタンスとしてデータをリストアできます。

参考 : バックアップの概要

論理的バックアップの代替となり得る手段として、ステイル読み取りがあります。ステイル読み取りでは、タイムスタンプを指定して、過去データを読み取ることができます。また、強い整合性を求めない読み取りの場合に、より高い読み取りパフォーマンスのためにステイル読み取りを使う場合もあります。

参考 : 読み取りのタイプ
参考 : タイムスタンプの範囲

誤ってデータを削除した場合など、論理的なデータ破損が発生した際に、規模の小さい復元の場合はこのステイル読み取りを使うこともできます。デフォルトでは最短1時間でデータがガベージコレクションされてしまいますが、データが残っていれば、ステイル読み取りによって過去のデータを読み取ることができます。

Compute Engine

Compute Engine にデータベースをホストするケースも出題されます。 Compute Engine の基本は、以下の記事で押さえてください。

blog.g-gen.co.jp

また以下のような運用タスクの方法も簡単に押さえておきましょう (永続ディスク拡張後、 VM にログインして resize2fs コマンドを使う等 ※ ext4 の場合) 。

参考 : 永続ディスクのサイズの変更

Bigtable

Bigtable の基本

Bigtable は NoSQL ビッグデータ向けのフルマネージドなデータベースサービスです。Bigtable は、IoT デバイスからのデータを受け取るというユースケースで語られることも多いデータベースです。

基本的な仕様の理解には、以下の記事も参考にしてください。

blog.g-gen.co.jp

テーブル設計

Bigtable は NoSQL の分散データベースであり、スキーマ設計は通常の RDB とは大きく異なります。Bigtable では入れるデータの 行キー によってデータ配置先のノードが決まります。キー設計を誤ると ホットタブレット / ホットスポット と呼ばれる、データの偏りが発生してしまいます。

例えば、行キーがタイムスタンプだったりすると、値がシーケンシャルであるため特定のノードに連続してデータが書き込まれてしまい、分散データベースの利点を活かせなくなってしまいます。「Bigtable 上の特定データセットのみパフォーマンスが悪い」といった場合、データの偏りを疑います。

データの偏りを特定するために Key Visualizer といったツールが用意されています。

以下の公式ドキュメントは押さえておいてください。

参考 : スキーマ設計のベストプラクティス
参考 : Key Visualizer の概要

Firestore

Firestore はフルマネージドでサーバーレスなドキュメントデータベース（NoSQL データベース）です。

モバイルアプリ（App）のデータベースとして使われるケースが多く出題されます。

参考 : Firestore の概要

特徴として、オフラインモードが挙げられます。この機能を使うと、アプリが頻繁に使用するデータはローカルのキャッシュに保存されるため、インターネットに接続できなくてもアプリが利用できます。インターネット接続が復旧すると、ローカルキャッシュのデータが Firestore に同期されます。

インターネット接続環境が不安定な場合（intermittent internet connectivity）でもアプリが使えるようにしたい、という要件が出題されたら、Firestore が使えないかを検討します。

参考 : オフラインデータを有効にする

Bare Metal Solution (BMS)

Bare Metal Solution (BMS) は Google Cloud の持つベアメタルサーバーを利用できるサービスです。

このサービスの主目的は Oracle ワークロードの Google Cloud への移行にあります。かつてはライセンスの問題から、Compute Engine の VM や Cloud SQL では Oracle Database を稼働させることができなかったことから、ベアメタルサーバーの扱いとなる BMS が利用されていました。

ただし、2024年6月に Oracle が Google Cloud を Authorized Cloud Environments として認定したため、現在では Compute Engine でも Oracle を利用することができます。

データベースの移行

適切なデータベースの選択

ユースケースに応じて、適切なデータベースサービスを選択させる問題があります。概ね以下の表のユースケースが理解できていれば、適切な DB を選択できます。

No	ユースケース	選択するサービス
1	オープンソースデータベースが利用可能で、費用対効果に優れたマネージドサービス	Cloud SQL
2	世界中に分散するアプリから使われる RDB。トランザクション（ACID）あり。99.999% の SLA	Cloud Spanner
3	IoT デバイスから高スループットでデータを受け取る	Bigtable
4	モバイル端末から使う。インターネット接続が無いとき (オフライン時) でもキャッシュ利用可能	Firestore

Database Migration Service (DMS)

Database Migration Service (DMS) の仕様を理解しましょう。

Continuous Migration 機能を使うことで「初回同期」と CDC (Change Data Capture) を使った「継続同期」を行い、最小限のダウンタイムで DB を移行することができます。

例として DMS を使った同種間移行では、オンプレミスの MySQL / PostgreSQL / SQL Server を Cloud SQL に移行することができます。

なお DMS は Cloud SQL への移行ツール なので、 Compute Engine でホストされたデータベースへの移行は できません 。

機能の概要を押さえておきましょう。

Datastream

Datastream も Google Cloud が提供する移行ツールの一つです。

Datastream は Oracle または MySQL から CDC (Change Data Capture) により Cloud Storage にデータをストリーミングします。 Dataflow と組み合わせることで BigQuery や Cloud SQL 、 Cloud Spanner などに対してデータを同期することが可能です。

機能の概要を、大まかで良いので押さえておきましょう。