変更要約: Professional Cloud Database Engineer 第1章を新規作成（ドメイン1「設計」: 容量計画と HA/DR＝ワークロードメトリクス/性能・コスト/ゾーナル・リージョナル・マルチリージョナル/メンテナンスウィンドウ/RTO・RPO・PITR、接続/アクセスと DB 選択＝Cloud SQL Auth Proxy/プライベート IP/CMEK/セッションプーラー/監査・Cloud SQL/AlloyDB(ベクトル/生成 AI)/Spanner/Bigtable/Firestore・マネージド/SQL/NoSQL/ベクトル）。
1.1容量計画と高可用性・災害復旧の設計
現在のワークロードメトリクスと将来要件に基づくデータベースの容量・使用量計画、性能とコストのトレードオフ、マルチリージョナル/リージョナル/ゾーナルのデプロイ戦略、メンテナンスウィンドウ、そして RTO/RPO/PITR を満たす高可用性と災害復旧の設計を理解します。
Professional Cloud Database Engineer は、ビジネス/技術要件をスケーラブル・回復性・コスト効率の高いデータベースへ翻訳します。設計はまず、容量計画と可用性・災害復旧から始まります。
1.1.1容量計画と性能/コスト
容量計画は、現在の ワークロードメトリクス（CPU/メモリ/IOPS/接続数）と将来要件から、データベースの コンピュートとストレージ をサイジングします。性能とコストのトレードオフ を評価し（マシンタイプ・ストレージタイプ）、過剰でも不足でもない構成を選びます。「現状＋将来でサイジング」「性能とコストを天秤にかける」と結びます。
1.1.2高可用性と災害復旧（RTO/RPO/PITR）
可用性は配置で決まります：ゾーナル（単一ゾーン・弱い）→ リージョナル（複数ゾーンでゾーン障害に耐える）→ マルチリージョナル（地域障害に耐える）。災害復旧は RTO（復旧時間）と RPO（許容データ損失）で設計し、特定時点へ戻せる PITR（ポイントインタイムリカバリ） を備えます。メンテナンスは メンテナンスウィンドウ を可用性要件に合わせて設定します。「ゾーン障害に耐える＝リージョナル（HA 構成）」「特定時点へ復旧＝PITR」と結びます。
「要件 → 設計」が頻出。例：「ゾーン障害に耐える DB」＝リージョナル（HA 構成）、「地域障害に耐える」＝マルチリージョナル、「誤操作前の時点へ戻す」＝PITR、「許容データ損失/復旧時間」＝RPO/RTO、「現状＋将来でサイジング」＝ワークロードメトリクスから容量計画、「停止を可用性要件に合わせる」＝メンテナンスウィンドウ。
混同に注意：
①RTO（時間）と RPO（データ損失量）と PITR（特定時点復旧）を取り違えない。
②可用性は配置の広がりで決まる（ゾーナルは弱い）。
③容量は現状だけでなく将来要件も見てサイジング。
1.1.3この節のまとめ
- 容量計画＝現状メトリクス＋将来要件で compute/storage をサイジング、性能/コストを評価
- 可用性＝ゾーナル<リージョナル(HA)<マルチリージョナル
- DR は RTO/RPO で設計し PITR を備え、メンテナンスウィンドウを可用性要件に合わせる
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. データベースをゾーン障害に強くしたい。最も適した配置はどれですか？
Q2. 誤操作や破損の前の特定時点へデータベースを戻したい。使う機能はどれですか？
Q3. RTO と RPO の違いとして正しいものはどれですか？
Q4. データベースの容量計画で最も適切な考え方はどれですか？
Q5. 地域全体の障害にも耐える最高レベルの可用性が必要です。最も適した配置はどれですか？
Q6. アプリの可用性要件に合わせて計画停止を制御したい。設定するのはどれですか？