はじめに

2024年9月の Oracle CloudWorld 2024上でラリーの基調講演に AWS の CEO である Matt Garman氏が登壇し、Oracle Database@AWS を2024年12月中に Go Live される旨の発表がありました。

そして、2024年12月3日の Re:Invent 直前に Oracle Database@AWS が限定プレビューで開始されました。

パブリッククラウドにおける「高可用性をマルチAZとして担保する」という前提と、「複数のサーバやストレージを高性能ネットワークでつなげて高い性能を出す」というExadataの仕組みが両立しないように思えて、どのようにAWS上で実装されているのか机上で確認してみました。

Oracle Database@AWSの構成

Oracle Database@AWS は Azure や Google Cloud と同様に AWSデータセンターの中に Oracle Exadataの機器を設置しそれを利用するような形です。概観としては次図のようになります。

（出典：What is Oracle Database@AWS?）

見慣れない「ODB network」と「ODB peering」というコンポーネントが初出してますので、それぞれ紹介します。

ODB network

ODB networkはAWS AZ で OCI インフラストラクチャをホストするプライベートな分離ネットワークになります。ODB networkは、IP アドレスの CIDR 範囲で構成され、OCI 子サイト内に存在するネットワークへ直接マップされ、AWS と OCI 間の通信手段として機能します。Exadata VM クラスタを作成するときに、ODB networkを指定する必要があります。

（出典：ODB network）

ODB networkとVPCの差分は次になります。

オンプレミスネットワークまたはインターネットへの接続がない
Amazon EC2 APIではなくOracle Database@AWSツールを使用して作成
Oracle Database@AWSリソースの作成のみをサポート
顧客ではなくAWSが管理

ODB peering

ODB networkと VPC 間のODB ピアリングにより、1 つの VPC と 1 つの ODB network間でトラフィックをプライベートにルーティングできます。ODB networkはプライベートであるため、デフォルトでは VPC、オンプレミスネットワーク、またはインターネットに接続できません。ODB network内の Exadata データベースに接続するには、ODB peering接続を設定します。

（出典：ODB peering）

ODB peeringは個別にルートテーブルの構成やDNSを設定する必要があります。Oracle RAC(Real Application CLusters)ではDNSを利用して単一のエンドポイント（Oracle Listener）を設定するため必要になると考えています。

（出典：Configuring the network in Oracle Database@AWS）

Previewでの制限

Previewでは次の制限がありますので、確認しておきましょう。

サポートされている AZ は use1-az6、米国東部 (バージニア北部) リージョンのみ
VPC 内のサブネットまたは Oracle Database@AWS に接続するアプリケーションは use1-az6 AZ 内にある必要がある
クォータ制限（一部緩和可能）
- ODB network数 5
- ODB peering数 10
アカウント制限
- Oracle Exadata インフラストラクチャの AWS アカウント間の共有不可
- VM クラスタは、Oracle Exadata インフラストラクチャと同じ AWS アカウントに存在する必要がある
VM クラスタは、ODB networkと Oracle Exadata インフラストラクチャを作成した AZ にのみデプロイ可能
ODB networkには VM クラスタのみデプロイ可能。その他のリソースのデプロイは不可
VPC と複数の ODB network間、または同じ AWS アカウント内の ODB networkと複数の VPC 間に ODB peering接続の作成不可。VPC と ODB networkの間には 1:1 の関係が必要
Oracle Exadata X9M では IPv6 はサポートされない

（出典：Limitations for Oracle Database@AWS）

なお、GAの際には幾つかの制限が緩和されることになると re:invent で発表されていました。

（出典：AWS re:Invent 2024-Transform your data with Oracle Database@AWS, featuring State Street (DAT246-NEW)）

レイテンシと高可用性のハザマで

さて、本題になります。
re:inventの Dominic Preussによる講演 AWS re:Invent 2024-Transform your data with Oracle Database@AWS, featuring State Street (DAT246-NEW) においても、Oracle Database@AWS の利点として「Low Latency」が挙げられていました。
Low Latencyは同一の AZ においてのみ実現されるため、AWS上で通常の高可用性構成としてシステム設計を行う場合には、何か障害が発生した場合には別 AZ での稼働を許容する(※)か、全て同一の AZ で稼働させるかを選択する必要がでてくると考えています。

(※)Previewでは同一の AZ からの接続しか許容されないため、現時点では別AZからの接続を許容する構成は取れません

RDS for Oracle を利用しているときの構成は次図のようになり、同一のAZからの接続と別のAZからの接続ではレイテンシに差分が発生します。

同じように、Oracle Database@AWS を利用するときの構成は次図のようになると想定され、同一のAZからの接続と別のAZからの接続ではレイテンシに差分が発生することになると想定されます（図中にも記載しましたが、別のAZにODB Peeringできるかは不明です。PreviewではPeering対象は一つになるためできません。）。

したがって、よくあるロードバランサで分散して複数のAZからデータベースに接続したい、という場合にはレイテンシ(AZ構成)を意識してシステム設計を行う必要があります。

オンプレミスからの移行となる場合には、そもそもオンプレミス環境でマルチAZのような構成を組んでいることは稀である(DRとして近場のDC間でデータ同期を組むことはありますが)と思われますので、基本的に業務を稼働する処理を1つのAZに集約しつつ、高可用性の確保として別AZへのHAや別リージョンへのDRの考えを整理していくのが良いと考えています。

また、現在AWS上で稼働しているOracle Databaseを要するシステムを Oracle Database@AWS に移行する場合には、現在のマルチAZ構成をそのままとることはできないため、改めて AZ障害についての対応を考えておく必要が出てくることが想定されます。

なお、AZ障害などを含めたOracle Databaseの高可用性についての整理には、MAA(Maximum Availability Architecture)というリファレンスアーキテクチャを元にすると良いでしょう(MAAの詳細は次図の出典の資料などを参照ください)。

（出典：MAAリファレンス・アーキテクチャ）

まとめ

Oracle Database@AWSではLow Latencyが一つの特長となりますが、Low Latencyの構成を選択する場合にはアプリケーション側含めて同じAZ内に配置することが求められます。
同じAZ内に配置する、という事は、単純なマルチAZではない形での高可用性の確保が求められるため、システム特性を考慮したうえで改めて検討を行う必要が出てきます。
といっても、Oracle Databaseの高可用性を今まで実施してきた方からするとそんなに難しくはないと思いますので、上で述べたようないくつかの前提があってそれを考慮して改めて設計する必要がある、という点を思い出してもらえれば大丈夫だと思います。

ライセンスコストはそれなりに必要となる可能性がありますが、Oracle Database@AWS ではライセンス込みのモデルもあり、RACが利用できるモデル（EE-EP(Enterprise Edition - Extreme Performance)）では Active Data Guardなども追加費用なしで利用できるため、一度試算してみると良いと思います。