Professional Cloud Database Engineer 認定試験範囲の解説
こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬 隆博です。
みなさんは夏休みの宿題が「油断していたら期限ギリギリだった」ということはありませんか。
私は先日、かなり観たかったバンドの来日公演チケットが発売されるタイミングを見逃してしまい、気づいたら完売していたということがありました。
本当に悔しくて、その日はヤケ酒を飲むことになってしまいました。
今回の記事は Professional Cloud Database Engineer に関する記事であり、実は 2024 年末から執筆を始めていました。
ところが、年度末にかけて業務が多忙すぎて執筆が止まってしまい、最近ようやく再開したという背景があります。
その結果、なんと試験が 2025 年 6 月 1 日にリニューアルされたそうです。
私の記事はリニューアル前の試験ガイドを参照していたため、「早くやっておけば良かった」という 夏休みの宿題状態 となってしまいました。
新試験のガイドも確認したのですが、今のところ旧試験の内容で大丈夫かなと思ったので、そのような内容となっています。
ちょうど 2025 年の 7 月 24 日から更新試験を受験可能ですので、その結果を受けて本記事のアップデートを検討しようかと考えています。
- 現行試験ガイド（2025 年 5 月 31 日まで）
- 新試験ガイド（2025 年 6 月 1 日より）
みなさんにおかれましては、チケットの発売日はしっかりウォッチして、私と同じ失敗をしないように心がけていただけると、私の失敗も少しは報われるかもしれません。
本記事を読み始める前に
本記事は Professional Cloud Database Engineer の認定試験範囲について解説するものであり、システム開発に対してある程度の知識・経験を保有している方に向けた内容となっています。具体的には、Google Cloud における初級の認定試験である Cloud Digital Leader や、中級の認定試験である Associate Cloud Engineer の合格者、もしくは同等の知識・経験をお持ちの方を想定しています。どなたにも理解いただけるように、なるべく平易な表現を心がけておりますが、あらかじめご了承ください。
概要
はじめに、Professional Cloud Database Engineer 認定試験について整理しましょう。
本試験は Google Cloud のデータベースに関するプロダクトの知識を問うものです。
Google Cloud 経験者であれば 真っ先に Cloud SQL が思いつくでしょう。
本試験もその通りであり、過半数が Cloud SQL に関する出題と言っても過言ではありません。
また、Google Cloud でデータを扱うと言えば BigQuery が有名かと思います。
しかし、同プロダクトは本試験の範囲外です。
Professional Cloud Data Engineer に多く出題されるので、そちらを学習いただければ幸いです。
同試験については、私の所属するクラウドエース株式会社が試験対策のコラムや記事を公開しています。
興味のある方は是非ご参照ください。
データベースの特徴
本試験に登場する主なデータベース プロダクトを紹介します。
前提知識
各プロダクトを紹介する前に、データベースで良く使われる用語を理解しましょう。
リレーショナル データベース
リレーショナル データベース マネージメント システム（以下、RDBMS） という言葉を聞いた事のある方も多いでしょう。
リレーショナルとは日本語で 関係 を意味し、データに関係性を持たせることができるデータベースですね。
詳細はこの後に出てきますが、これを管理する仕組みが RDBMS であり、本試験に登場するソフトウェアとして以下のものがあります。
- MySQL
- PostgreSQL
- Microsoft SQL Server
- Oracle Database
SQL
Structured Query Language（以下、SQL） とは、データベースを操作するための言語です。少しでもデータベースを触ったことがある方なら select * from <table name> みたいな構文に覚えがあるのではないでしょうか。
トランザクション
データベースにおける一連の処理を トランザクション と言います。
データベースにおいては、このトランザクションの単位で処理の取り消しなどを扱い、取り消しはロールバックと呼びます。
トランザクションおよびロールバックについては、よく銀行振込に例えられます。
振込元からお金を減らした後に振込先のお金を増やす処理が失敗した場合、全部元に戻してあげないとお金が減っただけになっちゃいますよね。
ACID
Atomicity（原子性）、Consistency（整合性）、Isolation（独立性）、Durability（耐久性）の頭文字を取って ACID と呼ばれます。
トランザクションが正しく動作するために守らなければならない特性ですが、本試験で詳しく問われるものではないので、言葉だけ覚えておきましょう。
もう少し知りたい方は、以下のリンクをご参照ください。
分散データベース
分散データベース とは、データを複数の異なる場所に分散して保存させる仕組みを指します。
地理的に離れた場所へデータを保存することで災害に備えたり、多数のノードに処理を分散することで処理速度を高めることができます。
整合性の種類
データベースの整合性には 強整合性 と 結果整合性 があります。それぞれの特徴を覚えておくと各プロダクトを理解する助けになります。
- 強整合性
- 常に最新のデータが反映されるため、銀行のような正確性が求められるシステムで用いられる
- 結果整合性
- 分散型のデータベースに多い特徴であり、リアルタイムな結果の反映が保証されない代わりに処理速度を高めやすく、ソーシャル ネットワーク サービスなどで用いられる
NoSQL
NoSQL とは Not Only SQL の略であり、RDBMS では難しかった拡張性や柔軟性、耐障害性を実現しています。
本試験に出題される NoSQL については、後ほどのプロダクト紹介で解説します。
データベース プロダクトの紹介
本試験に登場する主なデータベース プロダクトを紹介します。
これを覚えるだけで数問は取れるでしょうし、このあと各プロダクトを理解する助けにもなりますね。
| 種類 | 特徴 | 主な用途 | SLA（※） |
|---|---|---|---|
| Cloud SQL | MySQL、PostgreSQL および SQL Server を動作させることができるマネージド リレーショナル データベース | - Web アプリケーションのデータベース - トランザクション処理 |
>= 99.99% |
| Spanner | 分散型 SQL データベースであり、大規模なアプリケーションのトランザクションとスケーラビリティに対応できる | - グローバル アプリケーションのデータベース - トランザクション処理 |
>= 99.999% |
| Bigtable | カラム指向の NoSQL データベースであり、高スループットに期待できる | - IoT データ - クリックストリーム |
>= 99.999% |
| Firestore | ドキュメント指向の NoSQL データベースであり、一時的にオフラインとなるような通信環境でも使用可能 | - モバイル アプリケーション | >= 99.999% |
| Bare Metal Solution for Oracle | オンプレミスの Oracle Database をクラウドに移行するためのハードウェア | - Oracle Database | No SLA |
※ SLA は構成によって異なり、表には最大値を記入している
なお、上記の表以外に AlloyDB も存在しています。
本試験の範囲に入りそうなものですが、本記事執筆時点の試験ガイドに名前が出ていないため、解説は割愛いたします。
詳細を知りたい方は、以下のリンクから公式ページをご確認ください。
Cloud SQL
MySQL、PostgreSQL および SQL Server を動作させるためのデータベース プロダクトが Cloud SQL です。
これらのソフトウェアをほぼそのまま動かすことができるうえに、マネージド サービスなので管理の手間も軽減されます。
しかし、完全に互換性があるわけではなく、Cloud SQL では使えない機能を問う問題が出題されることもあるので理解しておきましょう。
エディション
Cloud SQL には、Enterprise と Enterprise Plus といった 2 つのエディションがあります。 Plus と言うだけあって後者の方が優れていますが、その分コストが高いといった形ですね。
試験に出そうな項目を抜粋しましたが、詳しくは公式ドキュメントをご参照ください。
| 項目 | Enterprise | Enterprise Plus |
|---|---|---|
| 可用性 SLA | 99.95% | 99.99% |
| メンテナンスによるダウンタイム | 60 秒未満（MySQL） | 1 秒未満（MySQL） |
| 30 秒未満（PostgreSQL） | 1 秒未満（PostgreSQL） | |
| 120 秒未満（SQL Server） | 120 秒未満（SQL Server） | |
| データ キャッシュ | × | ○ |
| ポイントインタイム ログの保持 | 最長 7 日 | 最長 35 日 |
ネットワーク
Cloud SQL のネットワークはパブリックとプライベートがあります。
読んで字のごとくな構成ですが、一つずつ見ていきましょう。
なお、パブリックとプライベートを両方使用することも可能です。
ネットワーク構成概要
簡単に書くと、「Cloud SQL は 自プロジェクトの VPC には作成されない」という特徴があります。
じゃあどこかと言えば、Google が管理するプロジェクトに作成されます。
公式ドキュメントには「Service producer project for customer」と表記されています。
（次の項目に図を掲載）
プライベート ネットワーク
Cloud SQL にパブリックな IP アドレスを持たせない プライベートなネットワーク構成です。
データベースを使う際に、多くの方はこの構成にしたいと思います。
インターネット経由でアクセス可能なデータベースはセキュリティがちょっと怖いですからね。
さて、プライベートなネットワークを構成した場合、画像のようになります。
Google Cloud の公式ドキュメントから引用してきました。
前述のように「自プロジェクトには作成されない」Cloud SQL に対してプライベートに接続する仕組みは VPC ピアリング によって実現されます。
詳細は省きますが、文字通り VPC 同士を接続するための機能ですね。
この機能によってプライベートなサービス アクセスが実現されます。
パブリック ネットワーク
Cloud SQL にパブリックな IP アドレスを持たせる ことで VPC ピアリングを不要とし、分かりやすくなった構成が パブリック ネットワーク です。
Cloud SQL がパブリックな IP アドレスを保有するため、そちらに対してインターネット経由でアクセスすることになります。
Web コンソールで作成しようとした際の既定値でもあります。
経路暗号化
データベースにはシステムに関する様々な情報が詰まっているため、そこへのアクセス経路は暗号化したいと思いませんか。
公式ドキュメントでも SSL モード設定を使用して SSL/TLS 暗号化を適用することを強くおすすめします。 と書かれており、その重要性が感じられますね。
通信の暗号化と言えば SSL / TLS 証明書ですが、Cloud SQL でも同様です。
詳細は公式ドキュメントに譲りますが、証明書を用いて通信経路を暗号化することができると覚えておきましょう。
接続方法
ネットワークを介して Cloud SQL へ接続するには、以下の要素も理解しておきましょう。
承認されたネットワーク
Cloud SQL への接続はホワイトリスト方式であり、承認されたネットワークからのみ接続することができます。
ただし、RFC 1918 アドレス範囲、いわゆるプライベートな IP アドレスは自動的に承認されます。
実質 パブリックな IP アドレスを承認する機能 と思ってもらえば良いですね。
Cloud SQL Auth Proxy
ここまでに解説した方法でネットワークを承認したり、経路を暗号化するのは手間ですよね。Cloud SQL Auth Proxy を使うことで、そういった手間を軽減することができます。
公式ドキュメントを引用すると、Cloud SQL Auth Proxy は、承認済みネットワークや SSL の構成を必要とせず、安全にインスタンスにアクセスできる Cloud SQL コネクタ です。
理解の助けになるかと思い、公式ドキュメントから画像を引用してきました。
クライアント側、サーバー側でそれぞれ Proxy が動作し、これが接続を中継してくれます。
Proxy には経路の暗号化や認証機能が備えられており、それらを用いることで簡単、かつ安全に Cloud SQL を利用することが可能となります。
なお、ネットワーク構成は Cloud SQL Auth Proxy とは関係ありません。
例えば、プライベートな IP アドレスのみ保有する Cloud SQL に対して、インターネットから接続することはできません。
Cloud SQL Auth Proxy を介するとはいえ、プライベートなデータベースにインターネット経由でアクセスされたらビックリしますよね。
HA 構成
Cloud SQL では、可用性を高めた High Availability（以下、HA）構成 が可能です。
こちらの画像も公式ドキュメントから引用しました。
同一リージョン内の複数ゾーンにインスタンスを用意することで、プライマリ側が停止した際には自動的にスタンバイ側がデータを提供する仕組みとなっており、ゾーン障害に耐えられる構成となります。
この仕組みは フェイルオーバー と呼ばれます。
また、フェイルオーバー後に障害が回復し、元のゾーンに戻す操作が フェイルバック であり、セットで覚えておくと良いですね。
具体的な操作を試しておくと、より効果的な試験対策になりますよ。
リードレプリカ
データベースの複製を作成する機能が リードレプリカ です。
公式ドキュメントからの引用ですが、以下の場面で有効活用することができます。
- リージョン間でのデータ移行
- 仮想化基盤や他者のクラウドといったプラットフォーム間でのデータ移行
結構幅広い用途ですね。
レプリカをプライマリ インスタンスへ昇格させることも可能なので、移行だけではなく災害対策でも使用可能です。
HA 構成だとリージョン内で冗長構成にすることが精一杯ですが、リードレプリカを組み合わせることでリージョンを超えることができるようになります。
また、データベースの読み取り性能を向上させることが可能です。
読んで字のごとくリード、つまり読み取り専用なのがリードレプリカです。
データを読み取るだけのバッチ処理などがあれば、リードレプリカに任せてしまうことでプライマリ インスタンスの負荷を下げるという使い方ですね。
試験にも様々な形で出題されるので、公式ドキュメントや模擬試験は確認しておきましょう。
レプリケーション ラグ
リードレプリカはプライマリ インスタンスの変更を非同期で複製しますが、若干の遅延が発生することがあります。そういった レプリケーション ラグ が大きい場合、レプリカから読み取ったデータが古くなっている可能性があり、アプリケーションの要件によっては問題となることがあります。
レプリカは即時反映じゃないことをしっかり覚えておきましょう。
移行
オンプレミスや他のクラウド環境で稼働している既存のデータベースを Cloud SQLに移行する方法はいくつかあります。試験に出やすい内容なので、順に確認していきましょう。
Database Migration Service
Database Migration Service は、オンプレミスや他のクラウドで稼働するデータベースを簡単かつ安全に移行するためのサービスです。
継続的なデータ レプリケーション技術により、ダウンタイムを最小限に抑えながら、本番環境の切り替え直前までデータの同期を保ちます。
同種移行から異種移行まで幅広くサポートしているのが大変便利ですね。
Oracle や SQL Server といった有償製品から PostgreSQL への移行パスも用意されているので、うまく使いこなしましょう。
トラブルシューティング
移行においてトラブルはつきものです。
試験前にトラブルシューティングをサッと見返しておくだけで取れる点もありそうですね。
外部レプリカとしての設定
移行元のデータベースを Cloud SQL の外部プライマリとして設定 し、Cloud SQL へ継続的なレプリケーションを行う方法です。これにより、ダウンタイムを最小限に抑えながらデータを移行できます。最終的な切り替えの直前までデータを同期し続けることができます。
スマートで格好良い方法ですが、既存のデータベースに手を加えなくてはいけないことに注意しましょう。
インポート・エクスポート
データベースのデータをファイルとしてエクスポートし、それを Cloud SQL にインポートする方法です。 小規模なデータベースや、一時的なダウンタイムが許容できる場合に利用されます。
シンプルで分かりやすい方法ですね。
アクティブ接続によるエクスポートエラー
エクスポート処理は、データベースに対するロックを伴う場合があります。
長時間実行されるアクティブなトランザクションや接続があると、エクスポート処理がロックに失敗した結果、遅延や失敗しの可能性があります。
エクスポートを実行する際は、データベースの負荷が低い時間帯を選ぶなどの配慮が必要です。
割とデータベースあるあるな事象かもしれません。
バックアップ・リストア
Cloud SQL では、データの損失に備えて バックアップ機能 が提供されています。
マネージド サービスを利用するメリットなので活用しましょう。
Point-in-Time Recovery
Point-in-Time Recovery を有効にすると、過去の特定の時点にデータベースを復元することができます。
これは、バックアップに加えて、トランザクション ログ と呼ばれる変更履歴のようなものを保存することで実現されています。
誤ってデータを削除・変更してしまった場合に非常に有効な機能ですね。
監視
Cloud SQL インスタンスの状況を把握するためには、Cloud Monitoring を利用した監視が不可欠です。 CPU 使用率、メモリ使用量、ディスク I/O、ディスク空き容量、アクティブな接続数、レプリケーション ラグなどの指標を監視し、必要に応じてアラートを通知することができます。
メンテナンス
Cloud SQL はマネージド サービスであるため、Google Cloud によって定期的なメンテナンスが実施されます。
この処理に関する問題も割と出題されるので、しっかり把握しておきましょう。
メンテナンス ウィンドウ
メンテナンスが行われる曜日と時間帯を メンテナンス ウィンドウ として設定することができます。これにより、サービスの負荷が低い時間帯にメンテナンスが実施されるように調整することが可能です。
「サービス提供時間帯なのにメンテナンスが動作しちゃった」とならないよう、注意して設定しましょう。
メンテナンスの延期
計画されたメンテナンスを一定期間延期することも可能 です。ただし、重要なセキュリティ パッチなどは延期できない場合があるので覚えておきましょう。
性能
データベースに性能問題はつきものです。問題を解消するための方法も提供されているので、しっかり理解しましょう。
Query Insights
Query Insights は、Cloud SQL のクエリ パフォーマンスに関する問題の検出、診断、防止に役立つツールです。実行に時間のかかったクエリ、頻繁に実行されるクエリ、CPU を多く消費しているクエリなどを特定し、その実行計画や統計情報を確認できます。アプリケーションのパフォーマンス チューニングに非常に有効なので、うまく活用しましょう。
ディスク変更
Cloud SQL インスタンスのディスクタイプ（SSD、HDD）やディスクサイズは、パフォーマンスや容量要件に応じて変更可能です。
ただし、それぞれ以下の要件があることに注意しましょう。
- ディスクタイプの変更にはインスタンスの再作成が必要となるため、バックアップ・リストアが必要となります
- ディスクサイズの拡張はインスタンス稼働中でも可能ですが、縮小にはインスタンスの停止が必要です。
ストレージの自動拡張
ディスク容量が逼迫するとデータベースの動作に支障をきたすため、ストレージの自動拡張機能を有効にしておくことがおススメです。
空き容量が一定のしきい値を下回ると自動的にディスクサイズが拡張されるため、とても便利ですね。
インスタンス変更
ディスクだけではなく、CPU コア数やメモリ容量を決定する インスタンスのマシンタイプ も、変更することができます。
変更にはインスタンスの再起動が伴うため、ダウンタイムが発生することを覚えておきましょう。
コスト最適化
Cloud SQL のコストを最適化するためには、インスタンスの適切なサイジング、不要な HA 構成やリードレプリカの削除、ストレージクラスの適切な選択、コミットメント利用割引の活用などが考えられます。
Cloud Recommender は、アイドル状態や過剰なサイジングに関する推奨を提示してくれることがあるので、最適なコストを目指して調整してみましょう。
前述のようにマシンタイプの変更にはダウンタイムが発生するため、事前の計画が大切ですね。
各ソフトウェアの機能一覧
Cloud SQL でサポートされている各データベースエンジンには、それぞれ利用できる機能や拡張機能、制限事項があります。
すべてを覚える必要はありませんが、受験直前に公式ドキュメントを見返す程度でも大作としては効果があると思います。
ベスト プラクティス
Cloud SQL を効果的かつ安全に運用するための ベスト プラクティス が公式ドキュメントにまとめられています。
一読しておくと加点に繋がる可能性が高そうですね。
Spanner
ここからは Cloud SQL 以外も少しだけ触れておきましょう。
Spanner は、リレーショナル データベースの特性と NoSQL の拡張性を兼ね備えた強力なデータベース サービスです。
お値段も少し強力かもしれません。
特徴と主な用途
Spanner には強力な機能が多数提供されています。
- グローバルな分散と強整合性
- データを複数のリージョンにまたがって分散しつつ、全ての読み取りに対して常に最新のデータを提供します。これは、地理的に分散したユーザーに対して低レイテンシでサービスを提供しつつ、データの正確性が非常に重要な金融取引や在庫管理などのアプリケーションに適しています。
- 水平スケーラビリティ
- データベースのサイズやトランザクション量が増加しても、ノードまたは処理ユニットを追加することで、パフォーマンスを水平にスケールさせることができます。
- Cloud SQL はインスタンスの性能を増加させる垂直スケールしか対応しておらず、上限に達すると拡張が不可能となるため、水平スケーリングに対応していることは大きなメリットとなります。
- リレーショナル セマンティクス
- スキーマ、主キー、外部キー、SQL クエリ、ACID トランザクションといったリレーショナル データベースの使い慣れた概念をサポートしています。
前述の通り、リレーショナル データベースと NoSQL の良いところを兼ね備えているので、大規模であったり高性能が求められる場合に有効な選択肢となりますね。
インポート / エクスポートのファイル形式
Spanner からデータをエクスポートしたり、Spanner にデータをインポートしたりする際には、Avro 形式 が主に使われます。CSV 形式もサポートされていますが、複雑なスキーマや大規模データの場合は Avro が推奨されます。
Avro がどういったものか、CSV より推奨される理由は何か、公式ドキュメントを確認しておきましょう。
自動スケーリング
Spanner には CPU 使用率やストレージ使用率に基づいて、処理ユニット（またはノード）の数を自動的に調整する 自動スケーリング機能 があります。
増やすことはもちろん、減らすこともできるので、コスト最適化の観点からとても嬉しい機能ですね。
スキーマ設計
Spanner のパフォーマンスを最大限に引き出すためには、適切なスキーマ設計が非常に重要です。特に、データの偏りによる ホットスポットの発生を避けるためのキー設計が重要 となります。
ホットスポットが発生すると、特定のノードに負荷が集中し、全体のパフォーマンスが低下する可能性があります。
少し複雑なお話ですが、試験に出題されやすい内容だと思うので理解しておきましょう。
Bigtable
Bigtable は、ペタバイト規模の構造化データを扱うために設計された、非常に高性能な NoSQL データベースです。
低レイテンシでの大量の読み書きアクセスが求められる大規模な分析アプリケーションに適しているので、是非とも覚えておきましょう。
Firestore
Cloud Firestore は、モバイルアプリ、ウェブアプリ、サーバー開発向けの NoSQL データベースです。
リアルタイム同期やオフライン サポートといった特徴を持っているのと、ドキュメント型のデータベースという点が注目ポイントですね。
ネイティブ モードと Datastore モード
Firestore には 2 つのモードがあります。
- ネイティブ モード
- Firestore の機能をフルに利用できるモードです。リアルタイム更新、より強力なクエリ、セキュリティ ルールなどが特徴です。
- Datastore モード
- 従来の Cloud Datastore と下位互換性を持つモードです。既存の Datastore アプリケーションを利用したい場合に選択します。
新たに使い始める場合は断然ネイティブ モードがおススメですね。
Bare Metal Solution for Oracle
Bare Metal Solution for Oracle は、オンプレミスで稼働している Oracle データベースを、最小限の変更で Google Cloud に移行するための専用ハードウェア ソリューションです。
Google Cloud のデータセンター内に設置された、Oracle 認定済みの物理サーバーとストレージをユーザーが占有して利用する仕組みとなっています。
これによって Oracle のライセンスの制約を回避し、Google Cloud で動作させることが可能となります。
Oracle のクラウド移行に向けた第一歩として使いどころがありそうですね。
まとめ
Professional Cloud Database Engineer の現行試験ガイドを元に、試験範囲の概要を説明してきました。
現行試験は Cloud SQL をバッチリ押さえたら合格できると言っても過言ではなかったのですが、新試験ガイドでの変更点が気になるところですね。
とはいえ、Google Cloud のデータベースと言えば Cloud SQL なのは間違いないので、まずはこの内容で学習を進めていただければ合格に近づくことは間違いないと思っています。
クラウドエース株式会社 Google Cloud 認定トレーナーの廣瀬 隆博がお届けしました。また次の記事でお会いしましょう。
Discussion