シラバス詳細 — Professional Cloud Database Engineer

公式試験ガイド v1.2 の 全範囲を日本語化し、各項目に「何が問われるか」「キーサービス」を補足 したものです。 学習前にここで地図を頭に入れ、各論は 02_学習資料/ で深掘りしてください。

凡例：🔑 = 頻出キーサービス／⚠️ = ひっかけ・判断ポイント／💡 = 試験で問われる「ベストプラクティス」

🏗 セクション1：革新的・スケーラブル・高可用なクラウドDBソリューションの設計（~32%）★最重要

出題比重トップ。アーキテクト視点で「どのDBを、どんな構成で」選ぶかが核心。設計判断ができれば実質40%以上を取りに行ける。

1.1 容量計画と使用量計画のための変数分析

Analyze relevant variables to perform database capacity and usage planning

• 現環境のワークロードメトリクス + 将来要件から ソリューションサイジング を行う
• 異なるDB構成（マシンタイプ、ストレージタイプ）の 性能とコストのトレードオフ を評価する
• 性能要件に基づいた コンピュート/ストレージのサイジング

🔑 Cloud SQL Enterprise vs Enterprise Plus / AlloyDB / Spanner Processing Units / Bigtable Nodes (HDD vs SSD) ⚠️ 過剰プロビジョニングはコスト超過、不足は性能劣化 ─ 観測 → サイジング → 検証のループ 💡 サイジングは「CPU・メモリ・IOPS・スループット・接続数・データサイズ」の6軸で考える

1.2 高可用性と災害復旧のオプション評価

Evaluate database HA and DR options given the requirements

• マルチリージョン / リージョナル / ゾーナル デプロイ戦略のトレードオフ
• 可用性要件に応じた メンテナンスウィンドウと通知 の設計

🔑 Cloud SQL HA (zonal failover) / AlloyDB HA / Spanner マルチリージョン / Bigtable レプリケーション / Memorystore HA ⚠️ RPO=0 / RTO 数十秒 が必要 → Spanner マルチリージョン ⚠️ RPO 分単位 / RTO 分単位 で許容 → Cloud SQL HA + クロスリージョンレプリカ 💡 SLA は「リージョナル 99.95% / マルチリージョン 99.99%」が基本ライン

1.3 アプリケーションがDBに接続する方法の決定

Determine how applications will connect to the database

• ネットワーキング、鍵管理、暗号化、セキュリティ の設定
• セッションプーラー （Cloud SQL Auth Proxy、PgBouncer、AlloyDB プーラー）の使用判断
• マネージドサービスの 監査ポリシー の評価

🔑 Cloud SQL Auth Proxy / Private Service Connect (PSC) / Private IP / IAM DB Authentication / CMEK ⚠️ Public IP はインターネット経由 → 本番環境は Private IP + Auth Proxy が基本 ⚠️ 大量の短命接続（サーバーレスから）→ コネクションプーラー必須 💡 Cloud SQL ⇄ App 接続は次の順で検討: Private Service Connect > Private IP > Auth Proxy (Public IP)

1.4 Google Cloud 上の適切なDBソリューション評価

Evaluate appropriate database solutions on Google Cloud ★最頻出

• マネージド vs アンマネージド の使い分け（セルフマネージド / Bare Metal / Google 提供 / GCP ネイティブ / パートナー）
• SQL vs NoSQL の業務要件分析（構造化/半構造化/非構造化/ベクトル）
• Google Cloud 上での DB ソリューションのコスト比較分析
• アプリ ⇄ DB の依存関係 の評価
• 規制・コンプライアンス を満たすソリューションの特定
• 組織ポリシー がDB戦略に与える影響の理解
• 複数のDB技術にまたがる構成（フェデレーション、エクスポート、ハイブリッド）
• 生成AI / LLM ユースケース を支えるDB技術の活用（pgvector、Vector Search）

🔑 すべてのDBサービス：AlloyDB / Cloud SQL / Spanner / Bigtable / Firestore / Memorystore / BigQuery / Bare Metal Solution / partner DB (MongoDB Atlas, Neo4j 等) ⚠️ 意思決定ツリーは丸暗記必須（後述） 💡 移植困難なエンタープライズ DB（Oracle）→ Bare Metal Solution 💡 グローバル分散OLTP + 強整合 → Spanner 💡 PostgreSQL互換 + 4倍速 + ベクトル/AI → AlloyDB

📋 セクション1 意思決定ツリー（暗記必須）

要件: 強整合トランザクション (OLTP)?
├─ Yes
│   ├─ グローバル分散 + 99.999% → Spanner
│   ├─ PostgreSQL 互換が必要 → AlloyDB (HTAP / AI/ML 含む)
│   └─ 単一リージョン or 小〜中規模 → Cloud SQL (MySQL/PostgreSQL/SQL Server)
│
└─ No (NoSQL)
    ├─ 大規模 KV/時系列 (>1TB) → Bigtable
    ├─ ドキュメント + リアルタイム同期 → Firestore (Native / MongoDB-compatible)
    ├─ キャッシュ / セッション → Memorystore (Redis / Memcached / Valkey)
    ├─ 分析 (OLAP) → BigQuery
    └─ Oracle / SAP / レガシー DB → Bare Metal Solution

🛠 セクション2：複数のDB技術にまたがるソリューション管理（~25%）

運用フェーズ。接続管理・監視・バックアップ・最適化・自動化 が網羅される。日常業務に近い領域。

2.1 DB接続とアクセス管理の検討

Determine database connectivity and access management considerations

• DB接続とアクセス制御のための IAM とポリシー の決定
• DB ユーザー管理 （認証とアクセス）

🔑 Cloud SQL IAM DB Authentication / AlloyDB IAM / Spanner IAM / IAM Service Account / Workload Identity Federation ⚠️ アプリ → DB はサービスアカウント を使い、人間→DB は IAM DB認証 + ユーザー個別アカウント 💡 ユーザー名/パスワードよりも IAM DB認証を優先（証明書 + 短命トークン）

2.2 DB監視とトラブルシュートの設定

Configure database monitoring and troubleshooting options

• スロークエリ / ロック の評価、不足しているインデックス の特定
• DBバイタル（RAM, CPU, ストレージ, I/O, 監査ログ）の監視と調査
• クォータ の監視と更新
• DB リソース競合 の調査
• エラーと性能メトリクスに対する アラート の設定

🔑 Cloud Monitoring / Cloud Logging / Query Insights (Cloud SQL / AlloyDB) / Spanner Query Stats / Cloud Audit Logs ⚠️ スロークエリ → Query Insights で実行計画と top クエリを特定 → インデックス追加 💡 アラートは「閾値 + 期間 + 通知チャネル」で設計。CPU 80%が5分続いたら通知 など

2.3 バックアップとリカバリの設計

Design database backup and recovery solutions

• 要件に基づき バックアップとリカバリ を推奨（自動スケジュールバックアップ）
• DB の エクスポート/インポート の設定
• RTO / RPO / PITR に基づく設計
• データ保持期間 の管理

🔑 Cloud SQL 自動バックアップ / PITR / Spanner Backup / Firestore export / Bigtable バックアップ / Cloud Storage ⚠️ PITR は トランザクションログを連続適用 することで任意の時点に復旧可能。Cloud SQL は最大35日、Spanner は7日 💡 RPO (Recovery Point Objective) = どれだけのデータ喪失を許容できるか 💡 RTO (Recovery Time Objective) = どれだけのダウンタイムを許容できるか

2.4 GCP 上での DB コスト & 性能最適化

Optimize database cost and performance in Google Cloud

• スケールアップ / スケールアウト の選択肢評価
• 現在 + 将来のワークロードに基づく DB インスタンスのスケーリング
• レプリケーション戦略 の定義
• DB ソリューションのコスト最適化の 継続的な評価
• クエリ最適化（コスト・性能）

🔑 Cloud SQL マシンタイプ変更 / AlloyDB クラスタスケーリング / Spanner PU 調整 / Bigtable オートスケーリング ⚠️ 読み取り重視 → リードレプリカ追加。書き込み重視 → スケールアウト DB (Spanner/Bigtable) 💡 クエリ最適化は「実行計画 → インデックス → クエリ書き換え」の順

2.5 共通的なDBタスクの自動化

Automate common database tasks

• DBメンテナンス（インデックス再構築、データエクスポート）
• DBエクスポートの スケジューリング
• マネージド DB の アップグレード管理
• DB の SLA / SLO 監視

🔑 Cloud Scheduler / Cloud Functions / Cloud Workflows / メンテナンスウィンドウ / pglogical ⚠️ メジャーバージョンアップは インプレース vs ブルーグリーン のトレードオフ 💡 Cloud SQL のメジャーアップグレードはインプレース可だが、ロールバック不可 → 事前スナップショット必須

🚚 セクション3：データソリューションの移行（~23%）

オンプレ／他クラウド → Google Cloud への DB 移行。DMS / Datastream の使い分け と ダウンタイム最小化 が焦点。

3.1 データ移行とレプリケーションの設計と実装

Design and implement data migration and replication

• 移行戦略と計画 の策定と実行
  • ゼロ／ニアゼロダウンタイム
  • 長時間アウテージ許容
  • フォールバック（切り戻し）計画
• Google Cloud → ソース DB への 逆方向レプリケーション（リバースレプリケーション）
• DB 移行の計画と実行（フォールバック計画、DDL/DML 変換 を含む）
• シナリオに応じた 正しい移行ツール の決定（GCP 外でホストされている DB を含む）

🔑 Database Migration Service (DMS) / Datastream / mysqldump / pg_dump / gcloud database-migration / Bare Metal Solution（Oracle 用） ⚠️ 同種(MySQL→Cloud SQL MySQL) → DMS ⚠️ 異種(Oracle→PostgreSQL) → Striim / DataStream + 手動 DDL 変換、または DMS Heterogeneous (PostgreSQL → AlloyDB, SQL Server → Cloud SQL PostgreSQL など対応拡大中) ⚠️ CDC（変更データキャプチャ） が必要 → Datastream（Oracle/MySQL/PostgreSQL/SQL Server → BigQuery/Cloud Storage/Pub/Sub） 💡 ゼロダウンタイム移行 = 初回スナップショット + CDC レプリケーション + アプリ切り替え + リバースレプリケーション保険

📋 セクション3 移行ツール選定マップ

ソース → ターゲット            推奨ツール
───────────────────────────────────────────────────
MySQL → Cloud SQL MySQL        DMS
PostgreSQL → Cloud SQL Postgres DMS
PostgreSQL → AlloyDB           DMS
SQL Server → Cloud SQL SQL Server DMS (近年対応強化)
Oracle → PostgreSQL/AlloyDB    DMS Heterogeneous / Striim / Ora2Pg
Oracle → Bare Metal Solution   そのまま L&S（Lift & Shift）
任意のRDBMS → BigQuery (分析用)  Datastream + BigQuery Sink
任意のRDBMS → Pub/Sub/GCS       Datastream（イベント連携）
オフライン大容量 (>10TB)         Transfer Appliance

🏛 セクション4：Google Cloud 上でのスケーラブル・高可用 DB のデプロイ（~20%）

設計したものを 実装・デプロイ・スケーリング・自動化 する実行フェーズ。

4.1 スケーラブル・高可用なDB実装の概念適用

Apply concepts to implement scalable and highly available databases

• Google Cloud 上で 高可用な DB ソリューションをプロビジョニング
• HA・DR 戦略のテスト（フェイルオーバー試験）
• マルチリージョナルレプリケーション の設定
• リードレプリカ のデプロイとスケール
• DB インスタンスのプロビジョニング自動化
• 高可用な DB のための 監視設定

🔑 Terraform / Deployment Manager / gcloud sql / gcloud spanner / gcloud alloydb / Cloud Build / Spanner Backup ⚠️ 手動 GUI 構築は再現性なし → Terraform / IaC が試験のお手本回答 ⚠️ Cloud SQL HA = 同期スタンバイ on 別ゾーン + 自動フェイルオーバー（数分）。クロスリージョン リードレプリカは 手動昇格 💡 フェイルオーバー試験は 手動フェイルオーバー → アプリ動作確認 → メトリクス確認 → 切り戻し の流れ

🎯 学習優先度マトリクス

戦略：比重 32% のセクション1（DB 選定 + 設計判断）で確実に得点する。意思決定ツリーを丸暗記する。次に運用（2）と移行（3）の DMS/Datastream の使い分けを押さえる。デプロイ（4）は範囲が狭く、IaC + HA 構成の基本パターンを押さえれば十分。

🧠 全セクション横断の頻出キーワード

暗記必須サービスとキーワード

暗記必須数値