Oracle Database@AWSが東京リージョンに使えるようになりました。
オンプレミスやデータセンターでExadataを利用して基幹システムや重要なデータベースをホストしている企業はとても多く、AWSへのクラウド化を進めるうえでは大きな障壁のひとつです。
Exadataを使っているからパフォーマンスが、、
RACを組んで冗長化を図っているから、、
などなど
Oracle Database@AWSはAWS上のExadataが使えることでAWSへのクラウドリフトが大きく前進するのではと期待しています。
当記事ではエンタープライズ企業が自社データセンターでExadataを利用しOracle DBをホストしている環境でAWSへクラウドリフトするという仮説で考察してみます。
AWSでOracle Databaseを使う方法は下記が現時点で下記が考えられます。
- Oracle Database@AWS
- RDS for Oracle
- Oracle DB on EC2
実際に利用するにはMarket Place経由でOracle社からライセンスを購入しないといけないので簡単に検証は出来ないので、どのように活用していけばいいか比較しながら机上で検討してみます。
基幹DBのクラウド化における比較検証
基幹システムの停止やデータ損壊は、単なるITプロジェクトの失敗にとどまらず、ビジネスの存続に関わる経営リスクそのものではないでしょうか。
特にOracle Databaseを採用しているシステムにおいてはどれも重要度が高く、移行後のパフォーマンス劣化や可用性の低下、運用継続性の喪失が許されないケースがほとんどです。
サービス概要・アーキテクチャ比較
まずは簡単にサービス概要とアーキテクチャの比較です。
概要からはExadataをそのまま使えるのとマネジメントにOracle社も関与しているのが大きな特徴だと読み取れます。
| 比較項目 | Oracle Database@AWS | RDS for Oracle | Oracle DB on EC2 |
|---|---|---|---|
| 主要コンセプト | AWS内でのExadata提供 | AWSによる完全マネージド | 仮想サーバー上での自前構築 |
| 基盤ハードウェア | Oracle Exadata (OCI基盤) | AWS 汎用インフラ | AWS 汎用インフラ |
| マネジメント主体 | Oracle & AWS (共同運用) | AWS | ユーザー |
| 主なターゲット | 超大規模・高負荷・最重要基幹 | 中〜大規模・標準的基幹 | 特殊要件・レガシーOS依存 |
| 導入の容易さ | 中（インフラ設定は自動） | 高（フルマネージド） | 低（設計・構築が必要） |
可用性・事業継続性（BCP/DR）
次にエンタープライズ企業では当然考えるべき可用性・事業継続性について比較してみます。
| 比較項目 | Oracle Database@AWS | RDS for Oracle | Oracle DB on EC2 |
|---|---|---|---|
| RAC(Active-Active) | 完全対応(Real Application Clusters) | 非対応 | 非対応（基本不可） |
| 可用性構成 | Exadataの高可用性を継続 | Multi-AZ | Data Guard等による自作 |
| RTO/RPO | 極小（RACによる無停止） | 秒～分単位（フェイルオーバー時） | 構成・設計に依存 |
| SLA | 99.99%以上（構成による） | 99.95% | EC2などのインフラ部分のみ保証 |
| パッチ適用 | ゼロダウンタイム・パッチ適用 | メンテナンスウィンドウでの停止 | ユーザーの計画に依存 |
Oracle独自機能・パフォーマンス
次にOracle独自機能やパフォーマンスについて比較してみます。
Oracle Database@AWSが登場するまではこのOracle独自機能を使っているかどうかでAWS自体がノックアウトとなることもありました。
本当に活用できているかどうかは見極めが必要ですが。
| 比較項目 | Oracle Database@AWS | RDS for Oracle | Oracle DB on EC2 |
|---|---|---|---|
| Smart Scan/Offloading | 利用可能（Exadata独自） | 利用不可 | 利用不可 |
| Multitenant(PDB) | 完全サポート | 対応（一部制限あり） | 利用不可 |
| GoldenGate/DG | ネイティブ統合 | 対応（一部制限・設定要） | 制限なし（自前で構築） |
| I/O | 極めて高い（RDMA Over Converged Enthernet） | EBS帯域に依存 | EBS/インスタンス性能に依存 |
| 最大メモリ/CPU | 極めて大規模（Exadataスペック） | インスタンスタイプに依存 | インスタンスタイプに依存 |
セキュリティ・ガバナンス
次に最重要だと言っても過言ではないセキュリティやガバナンスについて比較します。
| 比較項目 | Oracle Database@AWS | RDS for Oracle | Oracle DB on EC2 |
|---|---|---|---|
| ネットワーク分離 | AWS内自VPCにダイレクト接続 | 自VPC内 | 自VPC内 |
| OSアクセス | 不可（マネージド） | 不可（マネージド） | 可能（完全制御） |
| 監査（Unified Audit） | 完全対応 | 対応 | 制限なし |
| 暗号化（TDE） | 標準対応（推奨） | 対応 | 自前で構成 |
| アイデンティティ管理 | IAM連携/OCI IAM | IAM連携 | IAM連携/OS内 |
コスト・ライセンス・保守
Oracleを使い続けるか、脱Oracleを目指すかエンタープライズ企業が必ず遭遇する大きな壁であるコストについても比較します。
具体的なライセンス費はOracle社やAWS社との契約で決められるので概要での比較です。
| 比較項目 | Oracle Database@AWS | RDS for Oracle | Oracle DB on EC2 |
|---|---|---|---|
| ライセンス形態 | License Includeed/BYOL | License Includeed/BYOL | BYOLのみ |
| 運用工数（OpEx） | 低（ハード・OS管理不要） | 極小（完全マネージド） | 高（パッチ・バックアップは自前） |
| サポート体制 | AWSとOracleの共同サポート | AWSのみ（Oracle社へは要連絡） | 各社個別契約 |
| ベンダーロックイン | AWS/Oracle両方へ依存 | AWSへ依存度高 | 低（移行は比較的容易） |
可用性とパフォーマンスの深堀り
ここからは可用性設計においてData Guardの活用、特にマルチAZやマルチリージョン構成におけるパフォーマンスについて比較していきます。
これらも影響は重要システムのサービスレベルを決定づける最重要事項です。
構成別パフォーマンス・可用性比較
Oracle Database@AWSの可用性を高めるためにどうすればいいか。考えうる構成ごとにパフォーマンスと可用性を比較します。
| 比較項目 | マルチAZ構成（同期） | マルチAZ構成（非同期） | マルチリージョン構成（非同期） |
|---|---|---|---|
| 主な用途 | ゼロダウンタイム・データ損失ゼロ（HA） | 性能優先のHA | 広域災害対策（DR） |
| レプリケーション方式 | 同期（SYNC/Far Sync） | 非同期（ASYNC） | 非同期（ASYNC） |
| RPO | 0 | 数秒程度 | 数秒～数分（距離に依存） |
| RTO | 数秒～30秒以内（Fast-Start Failover） | 数分以内 | 数十分～（手動または自動） |
| レイテンシ | AZ間往復分（およそ0.5-2ms） | ほぼゼロ（オーバーヘッドなし） | ほぼゼロ（オーバーヘッドなし） |
| ネットワーク帯域影響 | 高（コミット毎に待機が発生） | 低（バックグラウンド転送） | 低（バックグラウンド転送） |
| コスト | 高（AZもしくはリージョン分） | 高（AZもしくはリージョン分） | 最高（リージョン間通信費発生） |
Oracle Database@AWSを使用した場合の高可用性を得られる構成は現時点で以下が鉄壁の布陣です。
- プライマリAZ: Oracle Database@AWSを配置したプライマリAZでOracle Exadata Database Serviceが稼働
- セカンダリAZ: プライマリAZと同等のExadataを配置。Active Data Guard（ADG）により、リアルタイム同期
- ネットワーク: AWSとOracleの専用プライベート接続により、AZ間は極めて低遅延で維持される。
SQL特性別レイテンシ影響
Oracle Database@AWSで同期DataGuardを利用した場合のSQL特性ごとのレイテンシ影響も比較してみます。
| SQLタイプ | 処理内容 | 同期DGによる影響 | Exadataによる最適化 | 判定 |
|---|---|---|---|---|
| OLTP | 顧客情報更新、決済処理など | +1.5ms（Commit待機） | PMEM加速により相殺 | 現状維持～微増 |
| Batch | 月次集計、帳票作成など | 無視可能（一括処理） | Smart Scanで数倍加速化 | 劇的改善 |
| Read-Only | 参照系レポート | なし（Standbyで実行） | 負荷分散による並列化 | 劇的改善 |
現行システム分析および適合性アセスメント仮説
ここからはおまけとして、仮説を置いて自社データセンターに存在する現行システムで発生した過去の苦い経験をどうやってOracle Database@AWSで克服するか分析してみます。
仮説を自社の数値に当てはめて考えて考察してみてください。
現行データセンター環境のI/O負荷（ピーク時分析、仮説）
- ①09:00-11:00（OLTPピーク）：朝一番の決済・注文処理の集中により、リード／ライトともにランダムI/Oが急増。現状、平均応答時間が10msを超え、遅延が発生。
- ②22:00-02:00（月次・日次バッチ）：大規模集計処理によりストレージ帯域が飽和。バッチ完了が翌朝に食い込むリスクが常態化。
- ③突発的スパイク：インフラの拡張性がなく、I/O待ちでシステムが沈黙。
過去3年間の障害発生パターンと解消策
| 障害カテゴリ | 発生件数 | 内容と影響 | Oracle Database@AWSによる解決策 |
|---|---|---|---|
| ハードウェア障害 | 4件 | ストレージコントローラ故障、ディスク多重障害 | Exadataのストレージ・グリッド 自動再構築によりサービス無停止を維持。 |
| OS/DBハングアップ | 2件 | 特定ノードのリソース枯渇によるサービス停止 | RAC（Active-Avtive） AWSの別のノードが即座に処理を継承 |
| 人的ミス・論理損壊 | 1件 | パッチ適用失敗、または誤操作によるデータ消失 | Flashback＆Data Guard 過去の特定の時点へ数秒で戻すことが可能 |
| パフォーマンス劣化 | 頻発 | 索引不足や統計情報の不備による長時間のバッチ遅延 | Smart Scan & Storage Index ストレージ層で処理を完結させ劇的に高速化 |
サイジング・適合性アセスメント
上記の仮説での障害を乗り越えるための推奨構成は以下の通り。
- Compute: データベース・サーバー・ノード x2（RAC構成。ピーク時CPUに対し40%の余力を確保）
- Storage: Exadataストレージサーバー x3（HCC圧縮により容量を30%削減、スループット10倍以上）
- Networking: AWS VPC内 25Gbps 超低遅延ネットワーク
簡易版移行ロードマップ
最後にもうひとつのおまけとしてカットオーバーを無事迎えるための戦略も仮説をたててみます。
移行戦略：Zero Downtime Migration（ZDM）の採用、比較
| 手法 | 物理移行（ZDM Physical） | 論理移行（ZDM Logical） |
|---|---|---|
| 技術基盤 | Data Guard | GoldenGate |
| 主な利点 | 最も安全・確実。 ブロックレベルで同一の複製を作成。 |
バージョンアップやOS変更を同時に実行可能。 |
| ダウンタイム | 数分以内（DGの役割切替のみ） | ほぼゼロ（GGによる双方向同期） |
移行ロードマップ
- フェーズ1：アセスメントと接続確立（ネットワーク構築、ZDMサーバー構築）
- フェーズ2：データ初期同期と継続レプリケーション（Data Guardによりデータセンター更新をリアルタイム反映）
- フェーズ3：移行リハーサルと性能検証（Snapshot Standbyにより本番負荷をかけて最終確認）
- フェーズ4：本番切り替え（Role Transitionによる数分程度の停止で移行完了）
まとめ
様々な観点で比較をしてみて、エンタープライズ企業においてOracle Database@AWSはとても有力なオプションであることの確信が持てました。
AWSに周辺システムを配置している企業は多数ありますし、いままではExadataにデータベースがあるがためにそのままデータセンターへ置いておき、レイテンシに目をつぶって構成するか、Outpostsを使うなど労力もコストもかかる構成を取るしかありませんでした。
Oracle Database@AWSが登場し、東京リージョンで使えることによりデータ保管場所の問題やExadataの制約も気にする必要なくクラウドリフトすることができるのでひとまずクラウドへ。ということがより簡単にできるようになったと感じました。
AWSへリフトしたあとはExadataのハード障害や保守期限を気にすることなくさらなるモダナイゼーションやリファクタリングに全力を注ぐことができますね。