Amazon Web Services ブログ
Oracle Database@AWS におけるレジリエンシーのための Well-Architected 設計
本記事は 2026/2/24に投稿された Well-Architected design for resiliency with Oracle Database@AWS を翻訳した記事です。
Oracle Database@AWS は、Amazon Web Services(AWS)データセンター内で Oracle Cloud Infrastructure(OCI)によって管理される Oracle Exadata インフラストラクチャを使用するデータベースサービスを通じて、エンタープライズグレードのデータベース機能を提供します。Oracle Database@AWS を使用して、オンプレミスの Oracle Exadata と同じパフォーマンスと機能を維持しながら、Oracle Exadata ワークロードを AWS に移行できます。Oracle Exadata と AWS 上で実行されているアプリケーション間で低遅延接続を確立することで、アプリケーション遅延の削減という恩恵を受けることができます。さらに、観測可能性、分析、人工知能と機械学習(AI/ML)、生成 AI アプリケーションの構築など、様々な機能のために Oracle Database@AWS を他のAWS サービスと統合できます。複数のアベイラビリティーゾーンにわたって自動管理、最適化されたパフォーマンス、および組み込みセキュリティ機能を提供することで、Oracle Database@AWS は最高レベルのデータベース信頼性とパフォーマンスを維持しながら運用オーバーヘッドの削減に役立ちます。
高可用性(HA)と災害復旧(DR)オプションは、Oracle Database@AWS で重要なデータベースを移行または展開する際に考慮すべき重要な側面であり、アーキテクチャがアプリケーションのサービスレベルアグリーメント(SLA)を満たせるようにするためにも役立ちます。ハードウェア障害、リージョン障害、またはその他の中断によってデータベースにダウンタイムが発生すると、重大な収益損失、顧客関係の悪化、および潜在的なコンプライアンス違反に直面する可能性があり、堅牢な可用性ソリューションがビジネスにとって必要不可欠です。これらの課題に対処するために、Oracle Database@AWS の多層的なアプローチを使用して、包括的な保護戦略を実装できます。高可用性のためのクロス AZ 構成と災害復旧のためのクロスリージョン設定の両方で Oracle Data Guard を使用することにより、ローカルハードウェア障害から AWS リージョン全体の障害まで及ぶ多層防御保護を構築できます。
この投稿は、Oracle の Maximum Availability Architecture(MAA) のベストプラクティスと AWS の Well-Architected フレームワークに従った Data Guard 構成の実装と維持に役立ちます。適切なネットワークアーキテクチャの選択方法と、クロス AZ とクロスリージョンの両方に Data Guard アソシエーションを構成する方法を示します。これにより、ロール移行中にアプリケーションがシームレスな接続を維持できるようにします。
Data Guard を使用した Oracle Database@AWS での HA とDR
Oracle Database@AWS で提供される Exadata Database Service on Dedicated Infrastructure(ExaDB-D)と Autonomous Database Dedicated(ADB-D)サービスは、Data Guard 構成を作成および維持するためのマネージド体験を提供します。プライマリとスタンバイの仮想マシン(VM)クラスター間で必要な接続が確立された後、OCI コンソールまたはコマンドラインインターフェース(CLI)を使用してプライマリサイトとスタンバイサイト間の Data Guard 構成を構築できます。次の図は、同一リージョン内の2つの AZ 間およびリージョン間で Data Guard アソシエーションを使用した ExaDB-D の HA/DR 構成のリファレンスアーキテクチャを示しています。

次の表は、ExaDB-D と ADB-D サービスで利用可能な Data Guard アソシエーション機能の比較を示しています。
| 機能 | ExaDB-D | ADB-D |
| Data Guardの作成と管理のマネージド体験 | はい | はい |
| クロス AZ 構成の自動フェイルオーバー | はい:顧客管理の Data Guard Observer(FSFO) | はい |
| クロスリージョン構成の自動フェイルオーバー | はい:顧客管理の Data Guard Observer(FSFO) | はい |
| サポートされるスタンバイデータベース数(ローカルとリモートを含む) | 6 | 2 |
| 推奨構成 | クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) | クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) |
Data Guard アソシエーションのネットワーク接続を確立するには、2つのオプションから選択できます:
- AWS Transit Gateway を使用して、2つの AZ または2つのリージョンにある2つのODBネットワークを接続する。
- クロス AZ 構成ではローカルピアリングゲートウェイを使用し、クロスリージョンでの Data Guard 構成の場合はリモート VCN ピアリングと動的ルーティングゲートウェイ(DRG)を使用して、OCI Virtual Cloud Network(VCN)レベルでピアリングを確立する。
次のセクションでは、Oracle Database@AWS の Data Guard アソシエーションにおける様々な接続オプションのネットワーク詳細、利点、およびコストへの影響について詳しく説明します。
同一リージョン内のクロス AZ デプロイメント
AWS 上のレジリエンシーのあるデータベースアーキテクチャの基盤は、プライマリ AZ の障害から重要なデータベースを保護することから始まります。ExaDB-D と ADB-D の両方のサービスで利用可能なクロス AZ Data Guard 構成のネットワークオプションを見ていきましょう。
Data Guard 接続に2つの ODB ネットワークを接続するための Transit Gateway を使用する
Transit Gateway を使用して、リージョン内の2つの AZ にある2つの ODB ネットワーク間のトラフィックを AWS ネットワーク内でルーティングできます。次の図は、2つの AZ (az1とaz2)でホストされている2つの Exadata VM クラスターと ODB ネットワーク間の構成の詳細を示しており、各 ODB ネットワークとピアリングされたトランジット仮想プライベートクラウド(VPC)を経由してルーティングされる接続を持つ Transit Gateway を使用しています。
この例では、b.b.b.b/b は az1 の ODB ネットワークのクライアントサブネット CIDR 範囲、a.a.a.a/a は az1 の ODB ネットワークとピアリングされた Transit VPCの CIDR 範囲、y.y.y.y/y は az2 の ODB ネットワークのクライアントサブネット CIDR 範囲、x.x.x.x/x は az2 の ODB ネットワークと ODB ピアリングされた Transit VPC の CIDR 範囲です。
| ネットワーク | CIDR |
| プライマリ Transit VPC | a.a.a.a/a |
| プライマリ ODB ネットワーククライアントサブネット | b.b.b.b/b |
| スタンバイ Transit VPC | x.x.x.x/x |
| スタンバイ ODB ネットワーククライアントサブネット | y.y.y.y/y |
Oracle Database@AWS のネットワークアーキテクチャと ODB ピアリングの概念について学ぶには、ODB ピアリングを参照してください。
次の図は、リージョン内の2つの AZ 間で Transit Gateway を使用して Data Guard トラフィックの接続を設定する方法を示しています。

このアーキテクチャを実装するには、次の手順に従う必要があります:
- ODB ピアリング方法を使用して、Transit VPC1(CIDR a.a.a.a/a)を
ODBNetwork-az1(クライアント CIDR b.b.b.b/b)とピアリングし、Transit VPC2(CIDR x.x.x.x/x)をODBNetwork-az2(クライアント CIDR y.y.y.y/y)とピアリングします。 - Transit Gateway をプロビジョニングするか既存の Transit Gateway を使用し、ODB ネットワークがデプロイされている AZ にマッピングされたサブネットに対して、Transit VPC1 と Transit VPC2の両方にアタッチします。Transit VPCへの Transit Gateway アタッチメントは、ODB ネットワークがプロビジョニングされている AZ にマッピングされたサブネットのみをカバーする必要があります。
- Transit VPC1 のルートテーブル(Transit Gateway アタッチメント用のサブネットで使用される)を変更して、Transit VPC2 CIDR(x.x.x.x/x)と
ODBNetwork-az2CIDR(y.y.y.y/y)を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 - Transit VPC2 のルートテーブル(Transit Gatewayアタッチメント用のサブネットで使用される)を変更して、Transit VPC1 CIDR(a.a.a.a/a)と
ODBNetwork-az1CIDR(b.b.b.b/b)を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 - これらのサブネットにアタッチされたルートテーブルからのルートは、Transit Gateway のルートテーブルに自動的に入力されます。
- Transit Gateway に直接接続されていない両方の AZ の ODB ネットワーククライアント CIDR に対して、Transit Gateway 上に2つの静的ルートを追加します。CIDR b.b.b.b/b とy.y.y.y/y の静的ルートは、Transit VPC の対応する Transit Gateway アタッチメントを指す必要があります。
- ODB ピアリング接続を変更して、他の ODB ネットワークとその Transit VPC のピアリング CIDR 範囲を追加します:
ODBNetwork-az1の ODB ピアリング接続を変更して、x.x.x.x/x と y.y.y.y/y をそのピアリング CIDR リストに追加します。ODBNetwork-az2の ODB ピアリング接続を変更して、a.a.a.a/a と b.b.b.b/b をそのピアリング CIDR リストに追加します。
ODB ピアリング接続のピアリング CIDR リストを変更することで、対応する OCI VCN のネットワークセキュリティグループが自動的に更新されて必要なトラフィックが許可されます。データベースリスナーポート、SSH(22)、および ICMP での接続を確認するために、ネットワークセキュリティグループルールを確認できます。
- 接続をテストして、ソリューションが適切に実装されていることを確認します。
グローバル接続を管理するために AWS Cloud WAN を使用している場合は、Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じものを使用できます。
Data Guard 接続に OCI VCN でローカルピアリングゲートウェイを使用する
VM クラスター間の接続を確立する2番目のオプションは、ローカルピアリングゲートウェイを使用して ODB ネットワークに関連付けられた2つの OCI VCN 間でトラフィックをルーティングすることです。
次の図では、ODBNetwork-az1 はクライアント CIDR b.b.b.b/b を持つ AZ1 の ODB ネットワークの名前であり、ODBNetwork-az2 はクライアント CIDR y.y.y.y/y を持つ AZ2 の ODB ネットワークの名前です。

OCI VCN をピアリングして接続を実装するには、次の手順に従う必要があります:
- OCI コンソールから ODB ネットワークに関連付けられた OCI VCN を特定し、クライアントネットワークの CIDR 範囲を記録します。
- 各 VCN に1つのローカルピアリングゲートウェイを追加します。
- 2つのローカルピアリングゲートウェイをピアリングします。
ODBNetwork-az1に対応する OCI VCN のデフォルトルートテーブルを変更して、ODBNetwork-az2の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。ODBNetwork-az2に対応する OCI VCN のデフォルトルートテーブルを変更して、ODBNetwork-az1の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。- 各 OCI VCN のネットワークセキュリティグループ(名前が調整可能なもの)を変更して、他の ODB ネットワーククライアント CIDR からのトラフィックを許可します。
- 接続をテストして、ソリューションが適切に実装されていることを確認します。
この構成の詳細については、Oracle Database@AWS でのクロスゾーン Data Guard を使用したディザスタ・リカバリの実装についてを参照してください。
クロス AZ Data Guard アソシエーションの接続オプションの比較
次の表は、Transit Gateway と OCI VCN ピアリングを使用して AZ 間で Data Guard トラフィックをルーティングする2つのオプションを比較しています。
| 機能 | Transit Gateway | OCI VCN ピアリング |
| トラフィック分離 | AWS ネットワーク | OCI ネットワーク |
| レイテンシー | 1桁台前半のミリ秒 | 1桁台前半のミリ秒 |
| コスト | Transit Gatewayとクロス AZ 料金 | データ転送料金なし |
| データ常駐とコンプライアンス要件 | トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす | データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない |
| トラブルシューティングの責任 | AWS | OCI |
ExaDB-D は Data Guard アソシエーションを追加する際、自動フェイルオーバー用の Data Guard Observer を自動的に構成しません。ただし、Observer 構成を手動で構築することができます。アプリケーションとデータベース間の接続が影響を受けた際にフェイルオーバーをトリガーするために、アプリケーションスタックが主に配置されている AWS ネットワーク上に Data Guard Observer インスタンスをホストすることが推奨されます。次の図は、Fast-Start Failover(FSFO)用に3番目の AZ に展開された Observer 構成を持つ、2つの AZ にわたる Data Guard アソシエーションのリファレンスアーキテクチャを示しています。ADB-D の場合、Observer プロセスを手動で構成することなく、クロス AZ 構成の自動フェイルオーバーを有効にできます。

Data Guardアソシエーションを使用したクロスリージョンディザスタリカバリー
AZ 間で HA 構成を確立した後、次のステップは DR 保護を実装することです。DR 要件がクロス AZ 構成で提供できる範囲を超える場合は、リージョン間で Data Guard を実装します。クロスリージョン Data Guard 構成で利用可能な接続オプションを検討し、その効果を比較してみましょう。
リージョン間での2つの ODB ネットワークを接続するために Transit Gateway を使用する
次の図に示すように、Transit Gateway 構成を使用して、AWS ネットワーク内の2つのリージョンにある2つの ODB ネットワーク間でトラフィックをルーティングできます。

この構成の高レベルの手順には以下が含まれます:
- 各リージョンに1つずつ、2つの Transit Gatway をプロビジョニングします。既存の Transit Gateway を使用することもできます。
- 各リージョンの ODB ピアリングVPCに、ODB ネットワークが存在する AZ にマッピングされたサブネットへ Trasnit Gateway をアタッチします。
- AWS Transit Gateway の Transit Gateway ピアリングアタッチメントで説明されているように、ピアリングアタッチメントを作成し、ピアリングリクエストを受け入れて、Transit Gateway 間の接続を確立します。
- クロス AZ トラフィック用の Transit Gatway 構成について前述した手順に従って、ルーティングルールを更新します。
- ODB ネットワーク構成を変更して、リモート ODB ネットワークからのトラフィックを許可するように ODB ネットワークのピアリング CIDR リストを更新します。
- 接続をテストして、ソリューションが適切に実装されていることを確認します。
グローバル接続を管理するために Cloud WAN を使用している場合は、Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じ手順を使用できます。
OCI VCN とのリモート VCN ピアリングを使用する
クロスリージョンの Data Guard 構成のための接続を確立するためにバックエンドの OCI VCN をピアリングする2番目のオプションでは、各側に追加の HUB VCN を構成する必要があります。これは、OCI VCN は1つの DRG にのみアタッチできるためであり、ODB ネットワークにマッピングされた VCN はすでに AWS-OCI ネットワーク統合のために DRG にアタッチされているためです。そのため、HUB VCN を導入し、ODB ネットワークの OCI VCN と HUB VCN 間でローカルピアリングゲートウェイ接続を確立します。その後、次の図に示すようにクロスリージョン接続のために DRG にアタッチできます。

詳細な構成手順については、Oracle Database@AWS 上のリージョン間 Active Data Guard によるディザスタ・リカバリの実装を参照してください。
クロスリージョン Data Guard アソシエーションの接続オプションの比較
次の表は、Transit Gateway と OCI VCN ピアリングを使用してリージョン間でData Guardトラフィックを行う接続オプションを比較しています。
| 機能 | Transit Gateway | OCI VCN ピアリング |
| トラフィック分離 | AWS ネットワーク | OCI ネットワーク |
| レイテンシー | ミリ秒 | ミリ秒 |
| コスト | Transit Gateway 料金とクロスリージョンデータ転送料金 | クロスリージョンデータ転送料金 |
| データ常駐とコンプライアンス要件 | トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす | データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない |
| トラブルシューティングの責任 | AWS | OCI |
ExaDB-D と ADB-D の Data Guard アソシエーションの構成
ExaDB-D と ADB-D は両方とも、バックアップ、リストア、および Data Guard 構成の手順を手動で実行することなく、コンソールまたは API と CLI を使用して Data Guard アソシエーションを設定するためのマネージド体験を提供します。ExaDB-D の場合は、次の手順を実行します:
- OCI コンソールを使用して OCI テナンシーにログインします。
- Oracle AI Database セクションで Oracle Exadata Database Service on Dedicated Infrastructure を選択します。
- プライマリデータベース用の VMC を選択します。
- プライマリデータベースを選択します。
- Data Guard associations を選択します。
- スタンバイインスタンスに適切なターゲット AD、インフラストラクチャ、および VMC を選択して、スタンバイ追加オプションを使用して構成します。
- 構築完了後にスイッチオーバーをテストします。

ADB-D の場合は、次の手順を実行します:
- OCI コンソールを使用して OCI テナンシーにログインします。
- Oracle AI Database セクションで Autonomous Database on Dedicated Infrastructure を選択します。
- Autonomous Container Database(ACD)を選択します。
- Data guard associations を選択します。
- スタンバイに適切なターゲット AD、インフラストラクチャ、および AVMC を選択して、スタンバイ追加オプションを使用して構成します。
- 構築完了後にスイッチオーバーをテストします。
クロス AZ Data Guard フェイルオーバーとスイッチオーバーのアプリケーション接続
データベースへのアプリケーション接続は、ADB-D と ExaDB-D の両方で Data Guard のスイッチオーバーとフェイルオーバーのシナリオを計画する際に慎重な検討が必要です。このセクションでは、適切な TNS 構成を使用することで、アプリケーションが再構成なしにロール移行シナリオ全体でデータベースへの接続を透過的に確立できるようにする、アプリケーションスタックからデータベースへの接続のための Well-Architected で推奨されるモデルについて説明します。
ほとんどの場合、顧客は高可用性のために異なる AZ にマッピングされたサブネットにまたがる VPC 内にアプリケーションスタックをデプロイします。VPC はプライマリ AZ とスタンバイ AZ の ODB ネットワークと同時にピアリングできるため、その VPC で実行されているアプリケーションは、次の図に示すように Data Guard のスイッチオーバーとフェイルオーバーのシナリオ全体でデータベースへの透過的な接続を促進できます。

Transit Gateway を介して ODB ネットワーク内のデータベースにアプリケーションが接続されている場合、プライマリおよびスタンバイ AZ の ODB ネットワークとピアリングされた Transit VPC を Transit Gatway にアタッチすることで、スイッチオーバーとフェイルオーバーのシナリオ全体で透過的な接続を確立できます。次の図に示すように、アプリケーションは Transit Gateway を介して ODB ネットワークに接続し、ODB ピアリング VPC は単にトランジットパスとして機能します。

このアーキテクチャでは、Transit VPC はアプリケーションコンポーネントをホストせず、アプリケーションは Transit Gateway を使用してデータベース層に接続します。
まとめ
この投稿では、Oracle Database@AWS で実行されている重要なデータベースの HA と DR 要件を満たすために Data Guard を使用する方法を示しました。また、Data Guard トラフィックをルーティングするための接続オプションについて説明し、データベースへのアプリケーション接続のベストプラクティスを共有しました。Oracle RAC (Real Application Clusters) が提供するサーバーラックレベルのレジリエンシー、Data Guard マルチ AZ レプリケーション、クロスリージョンディザスタリカバリなど、複数の保護層を慎重に実装することで、Oracle Database@AWS にデプロイされたデータベースに対して望ましい保護レベルと可用性を実現できます。現在の可用性要件を評価し、適切な Data Guard 構成を選択し、ビジネスニーズに最適なネットワークアーキテクチャを実装することで、包括的なデータベースレジリエンシーへの取り組みを今日から始めましょう。この投稿の詳細な構成手順とアーキテクチャパターンは、アプリケーションのビジネス継続性を提供する堅牢な Oracle Database@AWS 環境の構築と維持に役立ちます。
Oracle Database@AWS の機能と構成について詳しく学ぶには、Oracle Database@AWS ユーザーガイドを参照してください。