Exadata Database Service on Cloud@Customer

解決する課題

• データの所在を規制・社内ポリシーで 自社データセンター内に留めねばならない が、クラウドの運用性も欲しい
• オンプレ業務システムと DB の間で 極めて低い遅延 が必要で、リモートのクラウドリージョンでは届かない
• 大規模 Oracle DB を 最高水準の性能で動かしたいが、ハードウェアの調達・構築・パッチ運用は抱えたくない
• オンプレミスの Exadata 資産やスキルを活かしつつ、調達からスケールまでをクラウドのモデルへ寄せたい
• 自社拠点と Oracle 管理の責任分界を明確にし、インフラ運用を Oracle に肩代わりしてもらいたい

主要概念と用語

• Exadata Database Service on Cloud@Customer: Exadata 専用ハードウェアを 顧客のデータセンターに設置し、Oracle がリモート管理するクラウドサービス。データは自社拠点に留まる
• Exadata Cloud@Customer インフラ: 顧客拠点に置かれる物理基盤。データベースサーバー（計算ノード）と Exadata ストレージサーバー（ストレージセル）、高速ネットワークから成る
• VM クラスタ: インフラ上に作る仮想マシン群。複数ノードで RAC を構成し、その上で Oracle DB を稼働させる
• 責任分界: ハードウェアと基盤運用は Oracle が担い、DB やデータは顧客が管理する。データベースサーバーの VM では顧客が root 権限を持ち DB を運用できる
• コントロールプレーン接続: Oracle のクラウド管理機能と拠点の基盤をつなぐ管理経路。プロビジョニングやパッチ配信に使う
• スマートスキャン: 検索条件の絞り込みや集計の一部を ストレージセル側でオフロードし、計算ノードへ送るデータ量を減らす Exadata 中核機能
• Oracle RAC（Real Application Clusters）: 複数ノードで 1 つの DB を共有運用するクラスタ技術。ノード障害でも継続できる
• ASM（Automatic Storage Management）: ストレージセル上のディスクを束ねて冗長化・分散する Oracle のストレージ管理層
• Data Guard: プライマリの REDO をスタンバイへ転送して複製する仕組み。サイト間・拠点間のディザスタリカバリに使う
• デプロイモデルの対比: 同じ Exadata Database Service でも、Oracle のリージョン上に置く形態が Dedicated Infrastructure、自社拠点に置く形態が本サービスにあたる

仕様・制限・クォータ

• Exadata 専用基盤を顧客拠点に設置する形態で、計算ノードとストレージセルが 専用の高速ネットワーク（RDMA） で接続される。共有マネージド DB より格段に高い性能を狙える
• 構成は ノード数・CPU 数・ストレージ容量を選んでスケールできる。需要に応じて CPU を後から増減する 弾性スケールにも対応する
• 計算ノードは複数で RAC を組み、Data Guard によるサイト間・拠点間のディザスタリカバリにも対応する
• 利用できる Oracle DB のエディション・バージョンや上限ノード数・最大ストレージ容量は シェイプ（世代・モデル） により異なる。具体的な数値は世代で変動するため、最新の公式ドキュメントで確認すること
• 設置には 電源・冷却・ラック・ネットワークなどの物理前提条件と、Oracle 管理用のコントロールプレーン接続を満たす必要がある

内部の仕組み

本サービスの核心は、Exadata の データベース層とストレージ層を専用設計で密結合した基盤を、そのまま顧客のデータセンターへ持ち込む点にあります。一般的な構成では「ストレージは単にデータを返すだけ」で検索やフィルタは計算ノードが引き受けますが、Exadata は スマートスキャンにより検索条件の絞り込みや列の射影、一部の集計を ストレージセル側で先に実行し、計算ノードへは必要なデータだけを返します。結果としてネットワークを流れるデータ量が激減し、大規模スキャンが高速化します。

責任分界の面では、基盤の物理運用・ハードウェア交換・基盤パッチを Oracle がリモートで担い、VM クラスタ上の DB は顧客が運用します。可用性は計算ノードを RAC で束ねることで 1 ノード障害でも DB を止めず、ストレージは ASM が複数セルへ冗長化して保持するため、セル障害でもデータを失いません。データは拠点内のストレージセルに留まり続け、Oracle のクラウドへ流れ出るのは管理用のメタデータ中心です。

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

• 拠点要件のある最重要系に集中投下: データ所在規制や低遅延が必須の基幹・勘定系に絞って採用し、要件の緩い系は別サービスへ振り分ける
• RAC で高可用を前提に設計: 複数ノード構成とし、アプリ側も接続プールやフェイルオーバーに対応した接続にする
• Data Guard で災害対策: 別拠点や Oracle リージョンへスタンバイを構え、サイト障害でも継続できるようにする
• 弾性スケールでピークに追従: CPU を需要に合わせて増減し、月末バッチなどピークだけ増強する
• 既存ライセンスの活用: 既に Oracle DB ライセンスを持つなら BYOL（ライセンス持ち込み） でコストを抑える
• 物理前提条件を事前確認: 電源・冷却・ラック・ネットワーク・コントロールプレーン接続の要件を、設置前にデータセンター側と擦り合わせる

運用・監視

• OCI Monitoring / メトリクスで CPU・I/O・ストレージ使用量・ノードの状態を監視する。拠点設置でもクラウド側の管理画面から運用できる
• 自動バックアップを構成し、任意時点への復元（point-in-time recovery）を可能にしておく。バックアップ先は拠点内ストレージやオブジェクトストレージなどから要件に合わせて選ぶ
• パッチ適用は 計画的なメンテナンスとして実施。基盤側のパッチは Oracle がリモートで配信し、RAC のローリング適用でノードを順次更新して無停止に近い形で当てられる
• ノード障害時は RAC が残りノードで継続、サイト障害時は Data Guard でスタンバイへ切り替えて復旧する
• コントロールプレーン接続が切れると管理操作に影響するため、管理経路の冗長性と監視を確保しておく

コスト

計算（CPU）とストレージ、インフラの稼働時間が課金の中心です。専用基盤を顧客拠点に置くため単価は高めで、データ所在要件や性能・可用性が本当に必要なワークロードに使ってこそ費用対効果が出ます。具体的な料金は変動するため最新の価格表で確認してください。

セキュリティ

• データが 自社データセンター内に留まること自体が大きな統制点。所在規制やデータ主権の要件を満たしやすい
• 保存データは デフォルトで暗号化。鍵は OCI Vault（KMS） で管理し、顧客管理キー（CMK）も利用できる
• DB は プライベートサブネットへ配置し、セキュリティリスト / NSG（ネットワークセキュリティグループ） で接続元を最小化する
• IAM ポリシーで操作権限を制御し、最小権限の原則を徹底する。データベースサーバーの VM では顧客が root を持つため、OS レベルの統制も顧客責任となる
• 通信は TLS で暗号化し、資格情報はコードに直書きせず OCI Vault のシークレットに保管する

関連サービス・比較

最も近いのは、同じ Exadata Database Service の Dedicated Infrastructure（Oracle リージョン上に置く形態）です。性能特性や RAC・ASM・Data Guard といった中核は共通で、違いは「どこに基盤を置くか」と「責任分界・物理前提条件」にあります。

ハンズオン / CLI例

# Cloud@Customer の Exadata インフラ（拠点設置済みの基盤）を一覧表示
oci db exadata-infrastructure list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# 基盤上に VM クラスタ（RAC を構成する計算ノード群）を作成
oci db vm-cluster create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name prod-exacc-vmcluster \
  --exadata-infrastructure-id ocid1.exadatainfrastructure.oc1..xxxx \
  --vm-cluster-network-id ocid1.vmclusternetwork.oc1..xxxx \
  --cpu-core-count 4 \
  --gi-version 19.0.0.0 \
  --ssh-authorized-keys-file ./id_rsa.pub

# 作成した VM クラスタの状態を確認
oci db vm-cluster get \
  --vm-cluster-id ocid1.vmcluster.oc1..xxxx