TL

Cloud Service

HeatWave / Autonomous Database

OCI のマネージドRDB。MySQL HeatWave はトランザクションと分析(OLTP/OLAP)を1基盤で、Autonomous Database は自動運用のOracleDBを提供する。AWS の Amazon Aurora に相当。

中級信頼性パフォーマンス効率コスト最適化運用上の優秀性
最終更新: 2026-06-03公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.高性能マネージドRDBで Aurora に相当する立ち位置。
  • 2.HeatWave は OLTP と分析を ETL なし1基盤で高速処理。
  • 3.Autonomous DB は Oracle を自己運用。用途で選ぶ。

解決する課題

  • 分析のために MySQL から別のDWH(データウェアハウス)へ ETLでコピーする手間と遅延 をなくしたい
  • DB の パッチ・チューニング・バックアップといった運用作業を自動化 したい
  • 標準的なマネージドMySQL/Oracleより 高い性能とスケール が欲しい
  • トランザクションと分析、さらに 機械学習・ベクトル検索を同じDB で完結させたい

主要概念と用語

  • MySQL HeatWave: マネージド MySQL(oci mysql db-system)。OLTP に加え、HeatWave クラスタを足すと分析・ML が同居する
  • HeatWave クラスタ: インメモリ・列指向の分析エンジン。データを 複数ノードに分散保持 してスケールアウトする(最大512ノード級)
  • Autonomous Database (ADB): 自己運用 Oracle DB。ワークロード別に ATP(トランザクション)/ ADW(データウェアハウス)/ AJD(JSON)/ APEX を選ぶ
  • ECPU / OCPU: 課金・割当の計算単位。新規は ECPU が推奨(OCPU は旧来単位)
  • Autoscaling: ADB は CPU/ストレージを 基準値の最大3倍まで自動拡張。HeatWave も自動スケール対応
  • HeatWave AutoML / Lakehouse / GenAI: DB内で機械学習・オブジェクトストレージ上データの直接分析・生成AIを実行する拡張

仕様・制限・クォータ

  • HeatWave DB システムは アベイラビリティドメイン(AD) に配置。is-highly-available で 3 ノード(1プライマリ+2セカンダリ)構成にすると複数ADへ分散しフェイルオーバーする
  • HeatWave クラスタは メモリにデータをロードして処理するため、対象データ量に応じてノード数を見積もる
  • ADB は ECPU 最小2(Serverless)、ストレージは TB 単位で指定。Autoscaling で基準の3倍まで伸縮
  • Always Free 枠あり(ADB は最大2インスタンス、HeatWave は条件付き)。検証に使える
  • 管理者パスワードは要件あり(HeatWave は8〜32文字、ADB は12〜30文字で大小英字・数字を含む等)

内部の仕組み

MySQL HeatWave は、行指向の InnoDB(OLTP用)と、列指向インメモリの HeatWave エンジン(OLAP用)を1つのMySQLに統合しています。クエリオプティマイザが分析的なクエリを自動で HeatWave 側へオフロードし、変更は InnoDB から HeatWave へ自動同期されるため、利用者は ETL を書かずに同じテーブルへ SQL を投げるだけで済みます。HeatWave クラスタはデータをノード間に分割(パーティション)して並列処理し、ノードを足すほどスケールします。

Autonomous Database は Oracle Exadata 基盤の上で、パッチ適用・インデックス作成・統計収集・バックアップ・障害復旧を自動で行う「自己運用(self-driving)」DBです。OLTP 向けの ATP と DWH 向けの ADW で内部の最適化が切り替わります。

標準マネージドDBとの違い

普通のマネージドMySQLは「OLTP用DB＋別のDWHへETL」が定番。HeatWave は 同じDBに列指向エンジンを同居させ、ETLなしで分析できるのが最大の差です。Aurora が「ストレージ分離で高速・高可用」を売りにするのに対し、HeatWave は OLTPとOLAPの統合、ADB は 運用自動化 が売りです。

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

  • HTAP(混在ワークロード): トランザクション処理と分析を分けず、HeatWave クラスタを追加して1基盤に集約。レポート用DBの二重持ちをやめる
  • 本番は高可用構成: HeatWave は --is-highly-available を有効化し、複数ADへ冗長化。ADB は標準でExadataの冗長性を享受
  • 計算とストレージを需要に追従: ADB / HeatWave の Autoscaling を有効化し、ピークだけ自動でCPUを伸ばす
  • ワークロードでサービスを選ぶ: 純トランザクションなら ATP、分析中心なら ADW、JSON中心なら AJD。MySQL 資産があるなら HeatWave

運用・監視

  • OCI Monitoring / メトリクスで CPU・接続数・HeatWave のメモリ使用量・クエリ性能を監視
  • バックアップは 自動バックアップ + 手動バックアップ。ADB は 保持期間内の任意時点へ復元(point-in-time) が可能
  • パッチ・アップグレードは ADB が完全自動。HeatWave は メンテナンスウィンドウで管理
  • 障害時は HA 構成なら セカンダリへ自動フェイルオーバー(接続はエンドポイント経由で継続)

コスト

計算(ECPU/OCPU)とストレージが課金の中心です。HeatWave は分析を足すと HeatWave ノード分が加算されます。

課金要素内容最適化のコツ
DB システム(OLTP)MySQL/Oracle の ECPU(またはOCPU)＋ストレージ時間課金ワークロードに合うシェイプ/ECPU数を選ぶ
HeatWave クラスタ分析ノード数 × 稼働時間分析が不要な時間帯はクラスタを停止/縮小
ストレージ・バックアップデータ量・バックアップ保持に応じて従量保持期間を要件に合わせて短縮
Autoscaling基準ECPUの最大3倍まで自動伸縮常時上限ではなくピークのみ伸ばし無駄を抑える
Always Free / BYOL無料枠 / 既存Oracleライセンス持ち込み検証は無料枠、本番はBYOLで割引

セキュリティ

  • 保存データは デフォルトで暗号化。鍵は OCI Vault(KMS) で管理し、顧客管理キー(CMK)も利用可能
  • DB は プライベートサブネットに配置し、セキュリティリスト / NSG(ネットワークセキュリティグループ) で接続元を最小化
  • IAM ポリシーで操作権限を制御。アプリ資格情報は OCI Vault のシークレットに保管する
  • ADB は mTLS / TLS 接続(ウォレット)を標準とし、通信を暗号化
アンチパターン

DB をパブリックサブネットに置き、0.0.0.0/0 で全開放するのは厳禁。プライベートサブネット + NSG で接続元を限定し、資格情報はコードに直書きせず OCI Vault に保管してください。

関連サービス・比較（AWS との対応）

観点OCI HeatWave / Autonomous DBAWS Amazon Aurora
位置づけOCI の高性能マネージドRDBAWS の高性能マネージドRDB
エンジンMySQL(HeatWave) / Oracle(ADB)MySQL / PostgreSQL 互換
分析(OLAP)HeatWave 列指向エンジンを同居(ETL不要)別途 Redshift 等へ連携が基本
運用自動化ADB は自己運用(パッチ/チューニング自動)マネージドだが手動運用要素は残る
スケールECPU/ストレージ Autoscaling(基準の3倍)リードレプリカ最大15 / Serverless v2
可用性HA構成(複数AD) / Exadata冗長6コピー(3AZ×2)・高速フェイルオーバー
計算単位ECPU / OCPUインスタンスクラス / ACU(Serverless)

ハンズオン / CLI例

# MySQL HeatWave の DB システムを作成（プライベートサブネットへ配置）
oci mysql db-system create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name app-heatwave \
  --shape-name MySQL.HeatWave.VM.Standard.E3 \
  --subnet-id ocid1.subnet.oc1..xxxx \
  --availability-domain "AD-1" \
  --admin-username admin \
  --admin-password 'Ex4mple_Pass!' \
  --data-storage-size-in-gbs 100 \
  --is-highly-available true

# Autonomous Database（ATP / トランザクション用）を ECPU で作成
oci db autonomous-database create \
  --compartment-id ocid1.compartment.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-auto-scaling-enabled true

# DB システムの一覧を確認
oci mysql db-system list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

OCI Service

HeatWave / Autonomous Databaseを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

データベース

比較で見る軸

クラウド: OCI / カテゴリ: データベース / 難易度: intermediate

導入後に効く点

HeatWave は OLTP と分析を ETL なし1基盤で高速処理。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
データベース
難易度
intermediate
関連資格
—
設計柱
reliability / performance / cost / operational

判断チェックリスト

  • 自社の用途が「データベース / reliability」に近いか確認する。
  • 強みである「高性能マネージドRDBで Aurora に相当する立ち位置。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

データベースreliabilityperformancecostoperational
参考: 公式ドキュメント

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。

AWS
Amazon Aurora
解説を読む →
Azure
Azure SQL Hyperscale
解説を読む →
Google Cloud
AlloyDB / Cloud Spanner
解説を読む →