Oracle Exadata Database Service

解決する課題

• 大規模な Oracle DB を 最高水準の性能で安定稼働 させたい（基幹・勘定系・大規模 ERP など）
• 標準的なマネージド DB では足りない 極めて低い遅延と高い IOPS / スループット が要る
• 計画停止・障害でも止められない、ミッションクリティカルな高可用性 を確保したい
• オンプレミスの Exadata 資産・スキルを クラウドへそのまま延伸 したい
• データベースとストレージの間で起きる ボトルネックを根本から解消 したい

主要概念と用語

• Exadata Database Service: Oracle DB 専用に設計されたハードウェア（計算ノード＋ストレージセル＋高速ネットワーク）をクラウド上で提供するサービス。最重要ワークロード向け
• データベースサーバー（計算ノード）: Oracle DB のインスタンスが動くノード。複数ノードで RAC を構成する
• Exadata ストレージサーバー（ストレージセル）: データを保持する専用ストレージ。スマートスキャンなどの処理をストレージ側で実行する
• スマートスキャン: 検索やフィルタ・集計の一部を ストレージセル側でオフロード処理 し、不要なデータを計算ノードへ送らない仕組み。ネットワーク転送量を大幅に削減する
• Oracle RAC（Real Application Clusters）: 複数ノードで1つの DB を共有運用するクラスタ技術。1ノード障害でも継続でき、可用性とスケールを高める
• Exadata Smart Flash Cache: 高速フラッシュをキャッシュとして使い、I/O を加速する仕組み
• デプロイモデル: クラウドのデータセンターに置く形態と、自社データセンターへ置く Exadata Cloud@Customer（クラウドの管理性をオンプレに延伸）がある
• OCPU / ECPU: 課金・割当の計算単位。スケールに応じて増減できる
• ASM（Automatic Storage Management）: Oracle のストレージ管理層。ストレージセル上のディスクを束ねて冗長化・分散する

仕様・制限・クォータ

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

内部の仕組み

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

計算ノードとストレージセルは RDMA を使う高速ネットワーク でつながり、I/O 遅延を極小化します。さらに Smart Flash Cache が頻繁にアクセスされるデータをフラッシュ上に保持して I/O を加速します。可用性面では、計算ノードを RAC で束ねることで1ノードが落ちても DB は止まらず、ストレージは ASM が複数セルへ冗長化して保持するため、セル障害でもデータを失いません。

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

• 最重要ワークロードに集中投下: 勘定系・基幹・大規模分析など、止められず性能要件が厳しい系に絞って採用する。軽い系は別サービスへ振り分けてコスト最適化する
• RAC で高可用を前提に設計: 複数ノード構成とし、アプリ側も RAC を意識した接続（接続プール・フェイルオーバー対応）にする
• Data Guard で災害対策: 別サイト・別リージョンへスタンバイを構え、計画停止やリージョン障害でも継続できるようにする
• 弾性スケールでピークに追従: OCPU を需要に合わせて増減し、月末バッチなどピークだけ増強する
• 既存ライセンスの活用: 既に Oracle DB ライセンスを持つなら BYOL（ライセンス持ち込み） でコストを抑える
• 拠点要件があるなら Cloud@Customer: データを自社拠点に置く規制・低遅延要件があれば、クラウド管理のままオンプレ設置を検討する

運用・監視

• OCI Monitoring / メトリクスで CPU・I/O・ストレージ使用量・ノードの状態を監視する
• 自動バックアップをオブジェクトストレージ等へ取得し、任意時点への復元（point-in-time recovery） を可能にしておく
• パッチ適用は 計画的なメンテナンスとして実施。RAC のローリング適用により、ノードを順次更新して 無停止に近い形 で適用できる
• ノード障害時は RAC が残りノードで継続、サイト障害時は Data Guard でスタンバイへ切り替え て復旧する
• OCPU の弾性スケールやノード追加といった構成変更は、サービス側の操作として実施できる

コスト

計算（OCPU / ECPU）とストレージ、インフラの稼働時間が課金の中心です。専用基盤のため、一般的なマネージド DB より単価は高めで、性能・可用性が本当に必要なワークロードに使ってこそ費用対効果 が出ます。

セキュリティ

• 保存データは デフォルトで暗号化。鍵は OCI Vault（KMS） で管理し、顧客管理キー（CMK）も利用できる
• DB は プライベートサブネットへ配置し、セキュリティリスト / NSG（ネットワークセキュリティグループ） で接続元を最小化する
• IAM ポリシーで操作権限を制御し、最小権限の原則を徹底する
• 通信は TLS で暗号化し、資格情報はコードに直書きせず OCI Vault のシークレットに保管する
• 規制・データ所在の要件が強い場合は Cloud@Customer で自社拠点にデータを留めることも選択肢になる

Well-Architected の観点

• パフォーマンス効率: スマートスキャンと専用 I/O により、大規模スキャン・高 IOPS 要件で最高水準の性能を発揮する。弾性スケールで需要に追従する
• 信頼性: RAC によるノード冗長、ASM によるストレージ冗長、Data Guard による災害対策で、ミッションクリティカルな可用性を実現する
• コスト: 単価が高い上位サービスのため、本当に必要なワークロードへ集約し、軽い系は別サービスへ振り分けて全体最適を図る

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Exadata インフラ（VM クラスタ用の基盤）を作成
oci db cloud-exa-infra create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name prod-exa-infra \
  --availability-domain "AD-1" \
  --shape Exadata.X11M \
  --compute-count 2 \
  --storage-count 3

# 作成した Exadata インフラの一覧を確認
oci db cloud-exa-infra list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# インフラ上に VM クラスタ（RAC を構成する計算ノード群）を作成
oci db cloud-vm-cluster create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name prod-exa-vmcluster \
  --cloud-exadata-infrastructure-id ocid1.cloudexadatainfrastructure.oc1..xxxx \
  --subnet-id ocid1.subnet.oc1..xxxx \
  --backup-subnet-id ocid1.subnet.oc1..xxxx \
  --cpu-core-count 4 \
  --hostname exadbnode \
  --ssh-authorized-keys-file ./id_rsa.pub