OCI Database with PostgreSQL

解決する課題

• PostgreSQL サーバーの OS パッチ・マイナーバージョン更新・バックアップが重い → マネージドで自動化したい
• 障害でプライマリが止まると困る → 複数の可用性ドメインに分散した冗長構成で可用性を確保したい
• 読み取りや参照系クエリが増えてきた → **読み取りレプリカ（リードレプリカ）**で読み取りをスケールしたい
• 互換レイヤーや独自フォークではなく、標準の（オープンソースの）PostgreSQL をそのまま OCI 上で使いたい
• AWS でいう Amazon RDS for PostgreSQL に相当するものを OCI 側でも使いたい

主要概念と用語

• DB システム（DB System）: PostgreSQL の稼働単位。プライマリと、必要に応じた読み取りレプリカで構成される
• プライマリ（Primary）: 読み書き可能なメインのインスタンス
• 読み取りレプリカ（Read Replica）: プライマリから複製される読み取り専用インスタンス。読み取りをスケールしつつ、冗長化にも寄与する
• コンピュートとストレージの分離: 計算リソースと永続ストレージが分かれており、ストレージ層は複数の可用性ドメインにまたがって冗長化される設計
• コンフィグレーション（Configuration）: PostgreSQL のパラメータをまとめた設定単位。AWS のパラメータグループに相当する
• バックアップ: 自動バックアップと手動バックアップに対応し、ポイントインタイムリカバリ（PITR）に利用できる
• フェイルオーバー: プライマリ障害時に、別の可用性ドメインのリソースへ自動的に切り替える動作
• エクステンション（Extension）: PostgreSQL の拡張機能。利用できる拡張はサービスがサポートする範囲に限られる
• エンドポイント: 接続先の FQDN/IP。アプリはこのエンドポイント経由で接続する

仕様・制限・クォータ

• 提供されるのは標準の PostgreSQLであり、互換実装ではなくオープンソースの PostgreSQL エンジンを管理する形
• **シェイプ（Shape）**でコンピュートの CPU・メモリを選択する。Flex シェイプでは OCPU とメモリを柔軟に指定できる
• ストレージは作成時に確保し、後から**拡張（拡大方向）**が可能。一般に縮小はできない点に注意
• 自動バックアップの保持期間は設定可能で、PITR に利用できる。手動バックアップは任意の保持が可能
• メンテナンスウィンドウでパッチやマイナーバージョン更新を適用する
• 利用できる PostgreSQL のメジャーバージョンやエクステンションはサービスのサポート範囲に限られる。具体的な対応バージョンや拡張は変動するため、利用前に公式ドキュメントで確認すること
• リージョン/テナンシごとに**サービス制限（リミット）**があり、必要なら引き上げを申請できる
• スーパーユーザー権限はマネージドサービスのため制限され、管理用の特権ロールが提供される

内部の仕組み

• コンピュートとストレージの分離: 計算ノードと永続ストレージが分かれているため、ストレージを保ったままコンピュートを差し替えるような運用がしやすい設計になっている
• ストレージの冗長化: データは複数の可用性ドメインにまたがって冗長に保持され、単一ドメイン障害に耐える
• フェイルオーバー: プライマリが障害となった場合、別の可用性ドメインのリソースへ切り替えて復旧する。切り替え時はエンドポイントの向き先が更新される
• 読み取りレプリカ: プライマリの変更を複製した読み取り専用コピー。非同期で複製されるため、わずかな遅延（レプリケーションラグ）が生じうる。書き込みはプライマリにのみ向ける
• バックアップと PITR: 自動バックアップと WAL（先行書き込みログ）相当の仕組みにより、指定時点への復元が可能

設計パターン / ベストプラクティス

• 本番は複数の可用性ドメインに分散する構成とし、フェイルオーバーで単一ドメイン障害に耐えるようにする
• 参照系の負荷は読み取りレプリカへ分散し、書き込みはプライマリに集約する
• DB はプライベートサブネットに配置し、パブリックには公開しない
• 接続元は**セキュリティリスト / ネットワークセキュリティグループ（NSG）**で PostgreSQL のポート（既定の 5432 など）に最小限の許可だけを与える
• パスワードや資格情報は**OCI Vault（Secrets）**で集中管理し、アプリにハードコードしない
• PostgreSQL のパラメータはコンフィグレーションで管理し、本番適用前にステージングで検証する
• アプリ側は接続プールを用い、コネクション数の上限を踏まえて設計する

運用・監視

• OCI Monitoring（メトリクス）/ Logging で接続数・CPU・ストレージ・レプリケーション遅延などを可視化する
• 接続できないときはセキュリティリスト・NSG・サブネット・ルート・エンドポイントの設定を順に確認する
• スロークエリはインデックス設計や PostgreSQL のパラメータ（コンフィグレーション）、EXPLAIN による実行計画の確認で見直す
• パッチやマイナーバージョン更新はメンテナンスウィンドウで適用し、重要更新は事前に検証環境で確認する
• 定期的にバックアップからの復元（リストア）演習を行い、PITR が想定どおり機能することを確かめる

コスト

• 基本はコンピュート＋ストレージ＋バックアップの積み上げで、読み取りレプリカを足すとその分が加算される
• 使っていないレプリカや過大なシェイプは無駄になりやすいため、メトリクスを見て定期的に見直す

セキュリティ

• 保存時の暗号化は既定で有効。鍵は Oracle 管理に加え、OCI Vault のカスタマー管理鍵を指定できる
• 転送時は TLS/SSL で暗号化し、クライアント接続でも暗号化を有効にする
• DB はプライベートサブネットに配置し、NSG/セキュリティリストで接続元を最小に絞る
• 操作権限は IAM ポリシー（グループ/動的グループ＋ポリシー）で最小権限に設計する
• DB 内のロール・権限は PostgreSQL の GRANT/REVOKE で最小化し、アプリ専用ユーザーを用意する

Well-Architected の観点

• 信頼性（Reliability）: 複数の可用性ドメインへの分散とフェイルオーバーで可用性を確保し、自動バックアップと PITR で復旧性を担保する。読み取りレプリカは冗長化にも寄与する
• 運用（Operational Excellence）: パッチ・バックアップ・監視をマネージドに任せ、メンテナンスウィンドウとコンフィグレーション管理で変更を統制する。IaC とメトリクス監視で運用を自動化・標準化する

試験で問われるポイント

関連サービス・比較

• OCI 内で MySQL を使うなら OCI MySQL HeatWave、Oracle DB なら Base Database / Autonomous Database が選択肢になる
• 互換実装ではなく標準の PostgreSQL である点が利点で、既存の PostgreSQL アプリや拡張資産を活かしやすい

ハンズオン / CLI例

# 利用可能な PostgreSQL のシェイプを確認
oci psql shape list \
  --compartment-id "$COMPARTMENT_OCID"

# PostgreSQL の DB システムを作成（プライベートサブネット前提）
oci psql db-system create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name app-postgres \
  --db-version "16" \
  --shape "PostgreSQL.VM.Standard.E4.Flex.2.32GB" \
  --instance-count 2 \
  --storage-details '{"systemType":"OCI_OPTIMIZED_STORAGE","iops":75000}' \
  --network-details '{"subnetId":"'"$PRIVATE_SUBNET_OCID"'"}' \
  --credentials '{"username":"adminuser","passwordDetails":{"passwordType":"VAULT_SECRET","secretId":"'"$VAULT_SECRET_OCID"'"}}'

# 作成した DB システムの状態を確認
oci psql db-system get \
  --db-system-id "$DB_SYSTEM_OCID"

# 手動バックアップを取得（自動バックアップとは別に保持できる）
oci psql backup create \
  --compartment-id "$COMPARTMENT_OCID" \
  --db-system-id "$DB_SYSTEM_OCID" \
  --display-name app-postgres-manual-bkp