Autonomous Database on Dedicated Exadata

解決する課題

• Autonomous Database の 自動運用は享受しつつ、基盤を他テナントと共有したくない(強い分離が要る)
• パッチ適用やメンテナンスの 時期・順序を自社のポリシーで制御 したい
• 金融・公共など、規制で 専有環境・厳格な統制 が求められる
• 多数の DB を 1つの専有 Exadata 上に集約 し、運用とコストをまとめたい
• 共有型 Serverless では満たせない 隔離・カスタマイズ要件 に応えたい

主要概念と用語

• Autonomous Database on Dedicated Exadata: 専有の Exadata インフラ上に Autonomous Database を構築するデプロイ形態。自己運用の自動化はそのままに、基盤を専有して分離と統制を高める
• Autonomous Exadata Infrastructure(AEI): 専有割り当てされる Exadata の物理基盤。計算ノードとストレージセルから成り、この上に上位リソースを載せる
• Autonomous Exadata VM Cluster(AVMC): インフラ上に作る仮想マシンクラスタ。ネットワーク(サブネット)やライセンス方式を持ち、コンテナ DB の入れ物になる
• Autonomous Container Database(ACD): VM クラスタ上に作るコンテナ DB。パッチ適用やメンテナンス、Data Guard の管理単位で、複数の Autonomous Database を束ねる
• Autonomous Database(ADB): 利用者が実際に接続する DB。ACD の中に作成し、ATP/ADW などのワークロードを選ぶ
• リソース階層: インフラ → VM クラスタ → コンテナ DB → DB の4階層で構成される。上から順に作成する
• メンテナンススケジュール: ACD 単位でパッチ時期や更新順序を制御できる仕組み。共有型より細かく統制できる
• ECPU / OCPU: 課金・割当の計算単位。新規は ECPU が推奨で、OCPU は旧来単位

仕様・制限・クォータ

• リソースは インフラ → VM クラスタ → コンテナ DB → DB の順に上から作成する。共有型 Serverless が DB 1つの作成で済むのと異なり、専有では基盤の階層を自分で管理する
• 1つの専有インフラ上に 複数の VM クラスタ・コンテナ DB・DB を集約 でき、計算ノード数・OCPU/ECPU 数・ストレージ容量はシェイプ(世代・モデル)に応じてスケールする
• パッチやメンテナンスは コンテナ DB 単位でスケジュール制御 でき、適用時期や順序を自社のポリシーに合わせられる
• ネットワークは プライベートサブネット に閉じる構成が基本で、VM クラスタにサブネットを割り当てる
• 利用できる Oracle DB のバージョン・上限ノード数・最大ストレージ容量は シェイプにより異なる。具体値は世代で変動するため、要件確定時に公式ドキュメントで最新値を確認する

内部の仕組み

Autonomous Database on Dedicated Exadata は、自己運用(self-driving)の自動化はそのままに、稼働する基盤を専有 Exadata に閉じ込めた 形態です。パッチ適用・チューニング・統計収集・バックアップ・復旧といった作業は引き続き自動化されますが、その実行先が他テナントと共有しない専有基盤になる点が共有型との本質的な違いです。

仕組みの中心は 4階層のリソースモデル です。まず専有割り当てされる物理基盤である Autonomous Exadata Infrastructure があり、その上に Autonomous Exadata VM Cluster(ネットワークやライセンス方式を持つ仮想クラスタ)を作ります。さらにその中に Autonomous Container Database(パッチ・メンテナンス・Data Guard の管理単位)を作り、最後に利用者が接続する Autonomous Database を載せます。上の階層ほど運用・統制の単位として機能します。

この階層化により、パッチやメンテナンスの時期・順序をコンテナ DB 単位で制御 できます。共有型ではメンテナンス時期は Oracle 側の計画に従いますが、専有では「先に検証系の ACD へ適用し、問題なければ本番系へ」といった自社ポリシーでの段階適用が可能になります。

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

• 階層を上から設計する: インフラ → VM クラスタ → コンテナ DB → DB の順に、命名・コンパートメント分割・ネットワークをあらかじめ決めてから作成する
• コンテナ DB で環境を分離: 本番・検証・開発をコンテナ DB 単位で分け、メンテナンス適用を段階的に行う
• 専有基盤へ集約してコスト効率化: 多数の小規模 DB を1つの専有インフラへ集約し、基盤を遊ばせず単価を回収する
• プライベート接続を基本にする: VM クラスタはプライベートサブネットに置き、NSG(ネットワークセキュリティグループ)で接続元を限定する
• 既存ライセンスの活用: 既に Oracle ライセンスを持つなら BYOL(ライセンス持ち込み) でコストを抑える
• 要件が軽ければ共有型へ: 分離・統制要件がないワークロードは共有型 Serverless へ振り分け、専有は要件のある系に絞る

運用・監視

• OCI Monitoring / メトリクス で CPU・接続数・ストレージ使用量・SQL 性能を、インフラ/VM クラスタ/DB の各階層で監視する
• パッチ・メンテナンスは コンテナ DB 単位でスケジュール し、適用順序を制御してローリングで反映する
• バックアップは 自動バックアップ が標準で、保持期間内の 任意時点へのリストア(point-in-time recovery) が可能
• スケール操作(ECPU/OCPU 数やストレージの変更)は オンラインで無停止 に近い形で行える
• 災害対策は Autonomous Data Guard をコンテナ DB 単位で構成し、別ドメイン/別リージョンへスタンバイを作って切り替える

コスト

専有 Exadata インフラの稼働時間と、計算(ECPU/OCPU)・ストレージが課金の中心です。専有基盤のため、多数の DB を集約して 基盤を遊ばせず使い切るほど費用対効果 が出ます。

セキュリティ

• 基盤を 専有 するため、他テナントとリソースを共有せず 強い分離 が得られる
• 保存データは デフォルトで暗号化 され、鍵は OCI Vault(KMS)で管理し顧客管理キー(CMK)も利用できる
• VM クラスタは プライベートサブネット に配置し、セキュリティリスト / NSG で接続元を最小化する
• IAM ポリシー で各階層の操作権限を制御し、最小権限の原則を徹底する
• クライアント接続は mTLS(ウォレット) を標準とし、資格情報はコードに直書きせず OCI Vault のシークレット に保管する
• セキュリティパッチも自動適用されるが、適用時期は コンテナ DB 単位で統制 できる

関連サービス・比較

最も近いのは同じ Autonomous Database の 共有型(Serverless) です。自動運用は共通で、違いは基盤の専有度と統制の細かさにあります。

ハンズオン / CLI例

# 1) 専有 Exadata インフラ（基盤）を作成
oci db autonomous-exadata-infrastructure create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name prod-adb-exa-infra \
  --availability-domain "AD-1" \
  --shape Exadata.X11M \
  --subnet-id ocid1.subnet.oc1..xxxx

# 2) インフラ上に Autonomous Container Database（パッチ・メンテ単位）を作成
oci db autonomous-container-database create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name prod-acd \
  --cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1..xxxx \
  --patch-model RELEASE_UPDATES

# 3) コンテナ DB の中に Autonomous Database（接続先）を作成
oci db autonomous-database create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --autonomous-container-database-id ocid1.autonomouscontainerdatabase.oc1..xxxx \
  --db-name appatp \
  --display-name app-atp \
  --db-workload OLTP \
  --compute-model ECPU \
  --compute-count 2 \
  --data-storage-size-in-tbs 1 \
  --admin-password 'Ex4mplePass123' \
  --is-dedicated true

# 作成した専有インフラの一覧を確認
oci db autonomous-exadata-infrastructure list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table