本記事は 2026 年 7 月 9 日 に公開された「 Diagnose and resolve replica lag in Amazon RDS for Oracle replicas – Part 2 」を翻訳したものです。 本記事は、Amazon Relational Database Service (Amazon RDS) for Oracle リードレプリカのレプリケーション遅延を減らす方法を扱う 2 回シリーズの後編です。 Part 1 では、REDO 圧縮とレプリカ遅延を最適化する設定オプションを紹介しました。 本記事では、次の内容を説明します。 Amazon CloudWatch メトリクスとデータベースビューを使ったレプリカ遅延の監視。 待機イベント分析による一般的な根本原因の特定。 パフォーマンス問題を解消するための段階的なトラブルシューティング手法。 Amazon RDS for Oracle の リードレプリカ でレプリカ遅延が発生した場合、迅速な診断と解消が欠かせません。遅延は、災害対策 (DR) の準備態勢の維持に影響し、リードレプリカ上で実行されるレポート用ワークロードでのデータ提供を遅らせ、データベースのメジャー / マイナーバージョンアップグレードといった通常のメンテナンス作業を遅くする可能性があります。 問題の原因が設定、アプリケーションのワークロードパターン、リソース制約のいずれであっても、根本原因を特定し、的を絞った対策を実施するための体系的な手法を紹介します。 前提条件 始める前に、次の条件を満たしていることを確認してください。 Oracle Enterprise Edition (EE) — レプリケーションを担う Oracle Data Guard は Enterprise Edition でのみ利用できるため、リードレプリカではプライマリインスタンスに Enterprise Edition が必要です。 2 つ以上の vCPU を持つ DB インスタンスクラス — レプリケーションプロセスが正しく機能するには十分なコンピューティングリソースが必要です。 適切なライセンス — 読み取り専用モードには Active Data Guard ライセンスが必要ですが、マウントモードのレプリカには不要です。バージョンやライセンスに関する具体的な制限は、「Requirements and considerations for RDS for Oracle replicas」で確認してください。 Amazon RDS for Oracle のレプリケーション遅延のトラブルシューティング 本セクションでは、遅延の特定方法と一般的な原因を扱います。遅延の存在を特定できたら、以降のセクションの手法を使って根本原因を突き止め、対策を実施できます。 レプリカ遅延を特定する方法 レプリカ遅延は、 Amazon CloudWatch メトリクスを使うか、Oracle のデータベースビューを直接クエリして特定できます。CloudWatch メトリクスでは遅延を素早く特定でき、データベースビューではより詳細な診断情報が得られます。 Amazon RDS for Oracle では、ReplicaLag CloudWatch メトリクスはリードレプリカインスタンスでのみ利用できます。CloudWatch メトリクスの粒度について詳しくは、 CloudWatch metrics のドキュメントを参照してください。 Amazon CloudWatch メトリクス – ReplicaLag ReplicaLag CloudWatch メトリクスは、リードレプリカでの REDO 適用の遅延を表示します。適用遅延が大きい場合は、リードレプリカ側のリソース制約 (CPU、I/O) や、適用プロセスに影響する同様の問題を示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 注 : RDS はリードレプリカに非同期の REDO 転送を使用するため、データベースアクティビティがない場合でもレプリカ遅延が 1 秒と表示されることがあります。 V$ ビューやアプリケーションテーブルに対して手動でデータベースクエリを実行し、データベースの変更が同期しているか検証できます。 Amazon CloudWatch メトリクス – ReplicaTransportLag ReplicaTransportLag CloudWatch メトリクスは、プライマリデータベースからリードレプリカへの REDO 転送の遅延を測定します。転送遅延が大きい場合は、通常、ネットワークの問題やプライマリ側のボトルネックを示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaTransportLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 2 つのメトリクスを比較すると、遅延が転送の遅れによるものか、適用プロセスのボトルネックによるものかを判断できます。 標準的なデータベースクエリ レプリカ遅延に関するより詳細な診断情報を得るには、Oracle のデータベースビューを直接クエリできます。 公開ドキュメント に記載されているとおり、次のビューがレプリカ遅延の診断に役立ちます。 V$ARCHIVED_LOG 。 V$DATAGUARD_STATS 。 V$DATAGUARD_STATUS 。 V$ARCHIVE_GAP 。 遅延に関連するビュー ( V$DATAGUARD_STATS 、 V$DATAGUARD_STATUS 、 V$ARCHIVE_GAP ) をリードレプリカインスタンスでクエリすると、遅延の状態を取得できます。 V$ARCHIVED_LOG はプライマリとリードレプリカの両方でクエリでき、インスタンス間のログ状態を比較して特定できます。 注: Amazon RDS for Oracle の マウントモードのリードレプリカ では、データベースがクエリのためにアクセスできないため、リードレプリカ上でデータベースビューをクエリできません。ReplicaLag と TransportLag の CloudWatch メトリクスが遅延の監視情報を提供します。さらに、アラートログをダウンロードして確認することで、レプリケーション遅延や適用の問題を特定できます。 レプリカ遅延を引き起こす一般的な要因 レプリカ遅延の特定方法を理解したところで、本セクションでは一般的な原因を掘り下げます。Amazon RDS for Oracle のレプリカ遅延は、設定の問題、アプリケーションのワークロードパターン、外部要因という 3 つの主要なカテゴリから生じます。 設定の問題 インフラストラクチャとデータベースの設定は、レプリケーションのパフォーマンスに重要な役割を果たします。一般的な設定の問題としては、REDO ログやスタンバイログのサイズが不足または過小であること、メモリ設定が想定水準に達していないこと、プライマリやリードレプリカのデータベースワークロードを処理するにはコンピューティングやストレージのリソースが不十分であることが挙げられます。 アプリケーションのワークロードパターン アプリケーションがデータベースとやり取りする方法は、レプリケーションのパフォーマンスに大きく影響します。バッチジョブや高並行性ワークロードといった大量の処理は過剰な REDO を生成し、レプリカが追従する能力を圧倒することがあります。同様に、リードレプリカ上で実行される読み取り集約型のクエリは、コンピューティングとストレージのリソースを大量に消費し、適用プロセスを遅くする可能性があります。 データベース設計の選択も遅延の一因になります。過剰なコミットは REDO 生成を増やし、 特権ユーザー (SYS、SYSTEM、RDS_DATAGUARD、rdsdb) の操作を制限するトリガー は内部のレプリケーションプロセスを妨げる恐れがあります。 外部要因 ネットワークレイテンシーもレプリカ遅延の一因になり、特にリージョン間リードレプリカで顕著です。本シリーズの Part 1 では、ネットワークレイテンシーに関連する遅延への対処方法を詳しく説明しています。 レプリカ遅延のトラブルシューティング 前述の方法でレプリカ遅延の存在を特定できたら、次のステップは根本原因の判断です。根本原因はプライマリインスタンスまたはリードレプリカインスタンスのいずれかで生じます。 Amazon RDS for Oracle でレプリカ遅延のトラブルシューティングや根本原因の特定を行う際は、プライマリとリードレプリカの両方のインスタンスで CloudWatch Database Insights (DBI) と 拡張モニタリング (EM) を 1 秒粒度で有効にすることをお勧めします。これらのツールを使うと、システム負荷をほぼリアルタイムで能動的に検証でき、CloudWatch メトリクスの 1 分粒度よりも細かい情報が得られます。 通常、レプリカ遅延の根本原因は、遅延が増加し始めた時点で発生していたイベントに関係しています。その時間帯 (5～10 分以内) の DBI と EM のグラフを評価すると、システムで何が変化したかが明らかになることがよくあります。データベースの待機イベントとリソース競合を相関させることで、問題を特定し、緩和または解消するための適切な対策を講じられます。 注: 遅延が増加したときに固有の異常が見当たらない場合は、遅延のある期間とない期間で Active Session History (ASH) または Automatic Workload Repository (AWR) レポートを比較し、差分を特定します。リードレプリカ向けの AWR レポートの生成方法については、 Generate AWR reports for Amazon RDS for Oracle read replicas を参照してください。 レプリカ遅延のトラブルシューティングでは、データベースの待機イベントを特定すると根本原因を突き止めやすくなります。待機イベントは、期待されるデータベースアクティビティがないのに、データベースがどこで時間を費やしたりリソースを保持したりしているかを示します。次の待機イベントは、レプリカ遅延と関連することが多いものです。 Data Guard プロセスの待機イベント これらの待機イベントは、 V$DATAGUARD_PROCESS をクエリして監視できます。 Log Network Server (LNS) wait on SENDREQ または ARCH wait on SENDREQ。 Managed Recovery Process (MRP) wait on archivelog arrival または WAIT_FOR_LOG。 セッションレベルの待機イベント これらの待機イベントはデータベースセッションに影響し、 V$SESSION をクエリして監視できます。 log file sync。 db file sequential read / db file scattered read / db file parallel write。 CPU 関連の待機、または高い DB CPU 時間。 これらの待機イベントは、直接的または間接的にレプリカ遅延と関係しています。特定した根本原因に基づき、適切な対策を講じてこれらの待機イベントを排除 / 減少させ、レプリケーション遅延を減らしてください。 一般的な原因と解決策 REDO ログのサイズが不十分 archive_lag_target パラメータは、ログスイッチの発生頻度を制御します。このパラメータは、ログスイッチが強制されるまでの最大時間 (秒) を指定します。Amazon RDS for Oracle では最大値は 300 秒で、Oracle 本来の最大値である 7200 秒 (2 時間) とは大きく異なります。この Amazon RDS for Oracle 固有の制限により、1 時間あたり少なくとも 12 回のログスイッチが発生します。REDO ログがワークロードに対して小さすぎると、ログスイッチが頻繁に発生しすぎます。頻繁なログスイッチにより、チェックポイントの増加と I/O スパイクが生じ、プライマリとリードレプリカの両方を圧迫する可能性があります。 次のクエリを使って、1 時間あたりのアーカイブログ生成量を特定します。 alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select trunc(COMPLETION_TIME,'HH') TIME, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) REDO_GENERATED_IN_GB, count(*) GENERATION_COUNT from v$archived_log group by trunc(COMPLETION_TIME,'HH') order by 1 ; このクエリは、1 時間あたりの REDO 生成量とログスイッチ頻度を時系列で示し、ピーク時間帯を特定して、現在の REDO ログサイズが適切かどうかを判断するのに役立ちます。 注: Amazon RDS for Oracle インスタンスでは ALTER SYSTEM/DATABASE コマンドが制限されているため、 Oracle DB インスタンスで一般的なログ関連タスクを実行する AWS ドキュメントに従い、RDSADMIN パッケージを使って必要な REDO ログ関連の作業を行ってください。 ワークロードに対するシステム構成の不足 リソースのスロットリングは、コンピューティングレベル (CPU、メモリ、ネットワーク帯域幅) やストレージレベル (IOPS/スループット) で発生する可能性があります。プライマリやリードレプリカに十分なリソースがないと、レプリケーションプロセスが他のデータベース操作と競合し、遅延を引き起こします。 注: スループットのスロットリングはネットワークレベルでも発生し得るため、ワークロード向けに選択したコンピューティングが、アプリケーションのワークロードを支えるベースライン帯域幅を備えているか確認してください。 ストレージレベルのリソーススロットリングが発生している場合、通常は読み取り / 書き込みのレイテンシーが 10 ミリ秒を超えます。スロットリングされている値に応じて IOPS/スループットを増やせば、問題を緩和 / 解消できます。 DBI で CPU 使用率が割り当て済みの最大 vCPU を超えていないか確認してください。また、前述の待機イベントがソースまたはターゲットのいずれかで DBI に現れていないかも確認します。プライマリとリードレプリカが同じコンピューティングおよびストレージ構成であることを確認してください。これにより、レプリカがソースからのピーク負荷を処理できるようになります。 注: 高い CPU 使用率は、直接的な負荷から生じることもあれば、リソースのスロットリングから間接的に生じることもあります (たとえば、 Amazon Elastic Block Store (EBS) の IOPS 上限によりサーバープロセスが待機し、CPU 使用率が上がる場合など)。したがって、関連する根本原因を修正すれば、CPU 消費を割り当て済み vCPU 以下に抑えられます。 シナリオ: レプリカ遅延を段階的にトラブルシューティングする 次のシナリオでは、増加するレプリカ遅延の原因を特定し、絞り込む方法を示します。 ステップ 1: CloudWatch でレプリカ遅延を確認し、遅延の開始時刻を特定する リードレプリカインスタンスの [ Monitoring ] タブに移動して、ReplicaLag メトリクスを表示します。「ReplicaLag」グラフで [Maximize] を選択し、正確な開始時刻を特定します。 この例では、スナップショットは 1 月 5 日の 18:00 UTC に取得されました。グラフを見ると、レプリカ遅延は 17:50 UTC 頃から増加し始めています。遅延は数分前に始まり、現在 9.15 秒に達しています。 ステップ 2: プライマリで DBI を確認する AWS マネジメントコンソールでプライマリデータベースインスタンスに移動します。 [Monitoring] → [Database Insights] を選択します。デフォルトのビューには直近 3 時間が表示されます。 右上隅の [Custom] を選択し、分析に適した時間範囲を選びます。 ステップ 3: 転送遅延と適用遅延を比較する 「レプリカ遅延を特定する方法」セクションで説明したとおり、AWS マネジメントコンソールでリードレプリカのモニタリングセクションにある ReplicaLag と ReplicaTransportLag の遅延メトリクスを確認します。 CloudWatch メトリクスで ReplicaTransportLag と ReplicaLag のメトリクスを比較し、ボトルネックがどこにあるかを判断します。 シナリオ 示す内容 TransportLag が高く、ApplyLag が同程度 問題は REDO の送信であり、適用ではない TransportLag が正常で、ApplyLag が高い レプリカでの適用プロセスのボトルネック 両方のメトリクスが高いが値が異なる 詳細な分析が必要 このシナリオでは、Transport Lag と Apply Lag がほぼ同じであり、ボトルネックが適用プロセスではなく REDO の生成 / 送信にあることを示しています。 ステップ 4: リードレプリカで MRP プロセスの状態を確認する リードレプリカで V$MANAGED_STANDBY をクエリして、Managed Recovery Process の状態を確認します。 SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 15844 259554 現在、MRP プロセスの状態を見ると、ログを適用中であることが示されています。次のステップとして、プライマリで生成されたログシーケンスを確認する必要があります。 SQL> select thread#,max(sequence#) from v$log_history group by thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 15863 ここで、適用済みのログとプライマリで生成されたログを比較すると、19 のログシーケンスのギャップがあることがわかります。これは REDO の大量生成が原因である可能性があります。過去 1 時間に生成された REDO を確認して、生成状況を把握する必要があります。 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; Session altered. SQL> SELECT TRUNC(COMPLETION_TIME, 'HH24') AS COMPLETION_TIME, SUM(BLOCKS * BLOCK_SIZE) / (1024 * 1024 * 1024) AS GENERATED_GB, COUNT(*) AS LOG_COUNT FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 AND COMPLETION_TIME >= SYSDATE - 1/24 GROUP BY TRUNC(COMPLETION_TIME, 'HH24') ORDER BY 1; COMPLETION_TIME GENERATED_GB LOG_COUNT --------------------- -------------- ---------- 05-JAN-2026 17:00:00 2.54819012 21 05-JAN-2026 18:00:00 40.2287965 326 SQL> これは、過去 1 時間に 40 GB の REDO が生成されたことを示しています。分析に応じて COMPLETION_TIME フィルターを適宜変更してください。 注: アラートログが、ORA-16055: FAL request rejected や ORA-16401: archivelog rejected by RFS のように、レプリカ遅延が発生している理由に関する重要な手がかりを与えてくれることがあります。そのような場合は、関連する My Oracle Support ノートを確認して次のステップを判断してください。 ステップ 5: プライマリインスタンスのメトリクスを分析する 1 月 5 日 17:50～18:00 UTC のこのシナリオでは、DBI アラームが自動的に次を捕捉しました。 読み取りおよび書き込みレイテンシーが 10 ミリ秒を超過。 DB Load Analysis は、最も CPU (5 vCPU) を消費している UPDATE ステートメントを示しています。 Top Waits セクションは、レプリカ遅延が始まった時間帯にデータベースで発生した上位 2 つの待機イベントとして、log file switch (checkpoint incomplete) と log file switch completion を示しています。 Database Telemetry Metrics は、17:55 UTC 頃に I/O 操作が大きくスパイクしたことを示しています。 CloudWatch メトリクスは、読み取り + 書き込み IOPS が Amazon RDS プライマリデータベースに割り当てられた 3,000 IOPS を超えていることを裏付けています。 ステップ 6: Database Insights でリードレプリカを分析する 1 月 5 日 17:50～18:00 UTC のリードレプリカを DBI で確認します。 上位の SQL は unknown と表示されています。これは通常、リソースを消費しているプロセスが SQL_ID を持たない場合に発生します。このような状況では、リソースを消費している OS プロセスのプロセス ID (PID) を特定し、そのプロセスが何を実行しているかを調べられます。 ステップ 7: CPU を最も消費しているプロセスを特定する 消費しているプロセスを特定するには、次の手順に従います。 [Database Telemetry] → [OS Processes] に移動します。 CPU % で並べ替えます。 このシナリオでは、CPU を最も消費しているプロセスは ora_pr00_ORCL で、プロセス ID は 751957、CPU を 3.31% 消費しています。このプロセス名は、ターゲット上で REDO ログの変更を並列に適用する Parallel Recovery (PR) ワーカープロセスであることを示しています。 ステップ 8: 問題を修正または緩和するための推奨アクション ストレージ負荷に対応するため EBS IOPS を増やす。 ログスイッチ頻度を減らすため REDO ログサイズを増やす。 バースト処理に必要であれば REDO ログループを追加する。 変更を実施する前に、アプリケーションチームおよびビジネスチームと連携して負荷パターンを確認する。 シナリオ: リードレプリカでの適用側のボトルネック 次のシナリオでは、プライマリやネットワークではなく、リードレプリカの適用パスのボトルネックによって生じるレプリカ遅延を特定する方法を示します。この例では、プライマリで大量の UPDATE ワークロードが実行されており、それがリードレプリカでの適用 I/O 需要を押し上げています。 ステップ 1: ReplicaLag と ReplicaTransportLag を比較する リードレプリカインスタンスの [Monitoring] タブに移動し、同じ時間帯の ReplicaLag と ReplicaTransportLag を並べて表示します。 この例では、ReplicaLag は 2026-05-02 15:00 UTC に増加し始め、約 2 時間まで拡大する一方で、ReplicaTransportLag は終始 35 秒未満にとどまっています。前のシナリオの比較表によれば、このパターン (TransportLag が正常で ApplyLag が高い) は、リードレプリカでの適用プロセスのボトルネックを示しています。 ステップ 2: データベースレベルで遅延パターンを確認する リードレプリカで V$DATAGUARD_STATS をクエリして、CloudWatch のビューを裏付けます。 SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS 2 WHERE NAME IN ('transport lag', 'apply lag'); NAME VALUE DATUM_TIME --------------- ----------------- ------------------- transport lag +00 00:00:00 05/03/2026 03:23:47 apply lag +00 02:01:05 05/03/2026 03:23:47 転送遅延がゼロである一方で適用遅延は 2 時間を超えており、ボトルネックが適用側にあることを裏付けています。 プライマリの現在のログシーケンスと、リードレプリカで MRP が適用しているシーケンスを比較します。 -- On the primary SQL> SELECT thread#, MAX(sequence#) FROM v$log_history GROUP BY thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 97565 -- On the Read Replica SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# 2 FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 97540 90708 MRP はプライマリより 25 のログシーケンス遅れており、 V$DATAGUARD_STATS が報告する 2 時間の適用遅延と一致します。 ステップ 3: Database Insights でリードレプリカの待機イベントを分析する Database Insights でリードレプリカを開き、同じ時間帯の Waits で分割した Database load を確認します。 15:00 UTC 以降、平均アクティブセッションは約 6 に跳ね上がり、I/O 関連の待機が大半を占めています。control file sequential read、checkpoint completed、db file async I/O submit、parallel recovery read buffer free、Data Guard server operation complete などです。これらはすべて適用 / メディアリカバリのパス上にあり、リードレプリカが REDO の変更を十分な速さで永続化できていないことを示しています。 ステップ 4: リードレプリカのストレージメトリクスを確認する ReplicaLag が増加し始めたのと同じ時刻の、リードレプリカボリュームの BurstBalance と WriteIOPS を確認します。 BurstBalance は 14:59 UTC に 0% まで低下し、WriteIOPS は 15:00 UTC 以降、約 300 で頭打ちになっています。ReplicaLag も同じ分に上昇し始めます。gp2 ボリュームがバーストクレジットを使い果たし、ベースライン IOPS にスロットリングされたため、MRP と並列リカバリワーカーはすべての書き込みで待機せざるを得なくなっています。 ステップ 5: 根本原因 REDO はリードレプリカに正常に送信されていますが (ReplicaTransportLag は低い)、ボリュームがバーストクレジットを使い果たすと、レプリカのストレージが適用 I/O に追従できなくなります。このため、未適用の REDO によるバックログが増大します。 ステップ 6: 問題を修正または緩和するための推奨アクション リードレプリカのストレージを、持続的な適用ワークロードに合わせてサイジングしたプロビジョンド IOPS を備える gp3 または io1/io2 に切り替えるか、gp2 ボリュームのサイズを増やしてベースライン IOPS をレプリカの適用レート以上に引き上げます。 リードレプリカのストレージをプライマリとは独立してサイジングします。持続的な適用には、プライマリのワークロードと同等かそれ以上の書き込みスループットが必要になることがあります。 BurstBalance と ReplicaLag に CloudWatch アラームを設定し、クレジットが枯渇する前に通知を受け取れるようにします。 クリーンアップ 本記事に沿って AWS リソースをデプロイしたり設定を変更したりした場合は、それらの変更を必ず削除または元に戻してください。 まとめ Amazon RDS for Oracle リードレプリカのレプリケーション遅延は、アプリケーションのパフォーマンスと災害対策の準備態勢に影響を与える可能性があります。Database Insights と拡張モニタリングを有効にし、一般的な待機イベントを理解し、本記事で説明したトラブルシューティングの手法に従うことで、根本原因を素早く特定し、適切な対策を実施できます。これらの手法で解決しない複雑なシナリオについては、AWS Support または Oracle ベンダーサポートに連絡して追加の支援を受けてください。 著者について Jobin Joseph トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースに関して 25 年以上の経験を持っています。 Manoj Ponnurangam Amazon Web Services のシニアクラウドデータベースエンジニアです。Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon Aurora for PostgreSQL、AWS DMS の Subject Matter Expert です。リレーショナルデータベースに関して 15 年の経験を持ち、さまざまなデータベースおよび移行プロジェクトでお客様にガイダンスと技術支援を提供しています。 Deepak Mani AWS のシニアテクニカルアカウントマネージャーで、データベース技術に関してお客様と協働してきた業界経験が 17 年以上あり、そのうち 6 年以上を AWS でネットワーキング、ストレージ、データベースを担当してきました。Amazon RDS for Oracle と Amazon RDS インフラストラクチャの Subject Matter Expert として、エンタープライズのお客様と連携し、戦略的なガイダンスと予防的なサポートを通じて、運用の卓越性の推進、耐障害性の向上、クラウドジャーニーの加速を支援しています。 この記事はSolutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 25 日 に公開された「 Centralized traffic inspection for Oracle Database@AWS 」を翻訳したものです。 前回の記事「 Implement network connectivity patterns for Oracle Database@AWS 」では、3 つの接続パターンを紹介しました。アプリケーション VPC と Oracle Database@AWS ネットワーク間の直接ピアリング、 AWS Transit Gateway を使用した単一リージョン接続、 AWS Cloud WAN を使用したマルチリージョン接続の 3 つです。アプリケーション VPC、オンプレミスネットワーク、Oracle Database@AWS ネットワーク間のトラフィックや、インターネット向けの送信トラフィックのいずれも検査が必要です。本記事では、トラフィックを宛先に到達する前に専用の検査 VPC を経由させる 2 つの集中検査パターンを説明します。1 つは AWS Transit Gateway を使用するパターン、もう 1 つは AWS Cloud WAN のサービス挿入を使用するパターンです。 Oracle Database@AWS は、AWS データセンター内の専用 Oracle Exadata インフラストラクチャ上で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata Database Service と Oracle Autonomous Database へのアクセスを提供するサービスです。金融、ヘルスケア、官公庁などの規制産業では、侵入検知・防止 (IDS/IPS)、データ損失防止 (DLP)、ドメインフィルタリングなどの目的でデータベースとの間を流れるネットワークトラフィックの検査が求められることがあります。 前提条件 前回の接続パターンの記事 で解説した ODB ネットワーク、ODB ピアリング、ピアリングされた CIDR、ODB トランジット VPC の概念を理解しておく必要があります。AWS Transit Gateway または AWS Cloud WAN に接続されたトランジット VPC にピアリングされた ODB ネットワークが必要です。また、 AWS Cloud WAN サービス挿入の概念 や、 Amazon Virtual Private Cloud (Amazon VPC) のルートテーブル、サブネット、 NAT ゲートウェイ 、インターネットゲートウェイといった概念にも精通している必要があります。 重要: 現時点では、ODB トランジット VPC にファイアウォールエンドポイントを直接デプロイできません。トランジット VPC 自身の CIDR 外のアドレス宛てのトラフィックは、サブネットルートテーブルの検索を完全にバイパスして Transit Gateway または AWS Cloud WAN アタッチメント経由で直接転送されます。一部のユースケースでは個別のアプリケーション VPC にファイアウォールエンドポイントをデプロイできますが、この分散型アプローチはルートテーブル設定のオーバーヘッドが増大し、すべての VPC で繰り返す必要があるため、大規模環境では集中検査が実用的な選択肢です。 パターン 1: AWS Transit Gateway による集中トラフィック検査 図 1 のように、このパターンでは ODB ネットワーク、ODB ネットワークとピアリングされた ODB トランジット VPC、アプリケーション VPC、集中検査 VPC (ファイアウォールエンドポイント、NAT ゲートウェイ、インターネットゲートウェイ)、オンプレミスネットワークを Transit Gateway にアタッチメントとして接続します。オンプレミス接続には AWS Direct Connect または AWS Site-to-Site VPN を使用します。Transit Gateway は 2 つのルートテーブルでトラフィックを制御します。検査前ルートテーブルはスポークアタッチメント (アプリケーション VPC、オンプレミス、ODB トランジット VPC) に関連付けられ、デフォルトルート (0.0.0.0/0) が検査 VPC アタッチメントを指します。検査後ルートテーブルは検査 VPC アタッチメントに関連付けられ、アプリケーション VPC CIDR、オンプレミス CIDR、ODB ネットワーク CIDR への個別ルートがそれぞれのアタッチメントを指します。 図 1: Transit Gateway と集中検査 VPC を使用した東西・南北トラフィック検査 東西トラフィックフローのパケットウォークスルー 以下は東西トラフィックフロー (図 1 の ‘a’ / オレンジ色) の手順です。 アプリケーション VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが Oracle データベースのホスト名を解決し、ODB ネットワーク CIDR 内の IP アドレスで接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR (またはデフォルトルート) が Transit Gateway を指すルートがあります。パケットはアプリケーション VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブル (アプリケーション VPC アタッチメントに関連付けられたもの) でルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 検査 VPC の Transit Gateway アタッチメントサブネットにパケットが到着します。サブネットルートテーブルにより、パケットは検査のためファイアウォールエンドポイントにルーティングされます。 検査アプライアンスがセキュリティポリシーに従ってパケットを処理します。検査を通過した場合、サブネットルートテーブルにより検査後のトラフィックは Transit Gateway に戻されます。 Transit Gateway は検査後ルートテーブル (検査 VPC アタッチメントに関連付けられたもの) を参照します。ODB ネットワーク CIDR への個別ルートが ODB トランジット VPC アタッチメントを指しており、パケットはそこに転送されます。 ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続にルーティングします。パケットは ODB ピアリングを経由して ODB ネットワークに入り、Oracle データベースに到達します。 ODB ネットワークからのレスポンストラフィックは対称的な逆パスをたどります。 南北トラフィックフロー (インターネット送信トラフィック) のパケットウォークスルー Oracle データベースワークロードがインターネットアクセスを必要とする場合、インターネットに出る前に集中検査 VPC 経由でトラフィックをルーティングできます。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。このパターンでは、ODB ネットワーク上のピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。詳細は「 Oracle DB@AWS Internet Outbound Traffic blog 」を参照してください。 以下は南北トラフィックフロー (図 1 の ‘b’ / 緑色) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 パケットは ODB トランジット VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブルでルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは NAT ゲートウェイにルーティングされ、ソースアドレス変換が行われます。 NAT ゲートウェイがパケットをインターネットゲートウェイに転送し、インターネットに送出します。 インターネットからの戻りトラフィックは、インターネットゲートウェイ、NAT ゲートウェイ、ファイアウォール、Transit Gateway を経由し、ODB トランジット VPC を通じて ODB ネットワークに戻る逆パスをたどります。 パターン 2: AWS Cloud WAN による集中トラフィック検査 図 2 のように、アプリケーション VPC とオンプレミスネットワークは AWS Cloud WAN コアネットワークにアタッチされ、それぞれのセグメント (App VPC と Hybrid) にマッピングされます。検査 VPC アタッチメントは ネットワーク機能グループ (NFG) にマッピングされます。Transit Gateway は TGW ルートテーブルアタッチメントを介して ODB トランジット VPC と AWS Cloud WAN コアネットワーク間の接続を提供します。ODB ネットワーク CIDR への静的ルートが Transit Gateway 上の ODB トランジット VPC アタッチメントを指しており、この TGW ルートテーブルは Cloud WAN TGW ルートテーブルアタッチメントに関連付けられています。これにより ODB CIDR が BGP 経由で Cloud WAN のセグメントおよび NFG ルートテーブルに動的に伝播されます。 この構成により、Cloud WAN のサービス挿入アクションがトラフィックを検査 NFG 経由で制御します。東西フローには send-via アクション、南北フローには send-to アクションを使用します。以降のセクションで詳しく説明します。 東西トラフィックフロー (send-via アクション) 図 2: AWS Cloud WAN のサービス挿入を使用した東西トラフィック検査 send-via アクションは ODB Network セグメントと App VPC セグメント (およびオンプレミストラフィック用の hybrid セグメント) の間に、検査 NFG を経由するよう設定されます。 以下は東西トラフィックフロー (図 2 の ‘c’) の手順です。 アプリケーション VPC 内の Amazon EC2 インスタンスが Oracle データベースのホスト名を解決し、データベース接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR が AWS Cloud WAN コアネットワークアタッチメントを指すルートがあります。パケットは AWS Cloud WAN コアネットワークに転送されます。 App VPC セグメント (またはオンプレミストラフィックの hybrid セグメント) と ODB Network セグメント間に send-via アクションが設定されています。AWS Cloud WAN のルーティングテーブルがパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは検査 VPC を出て NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。 AWS Cloud WAN は検査後のトラフィックを Transit Gateway ルートテーブルアタッチメントにルーティングします。Transit Gateway から BGP で動的に伝播された ODB ネットワーク CIDR がそこに存在します。 Transit Gateway がパケットを ODB トランジット VPC に転送します。ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続経由で ODB ネットワークにルーティングし、Oracle データベースに到達します。 戻りトラフィックは対称的な逆パスをたどります。send-via アクションは双方向で、ODB ネットワークからのトラフィックもアプリケーション VPC に到達する前に同じ検査 VPC を通過します。 オンプレミストラフィックも同じパターンに従います。hybrid セグメントで Direct Connect または AWS Site-to-Site VPN アタッチメントを通じて AWS Cloud WAN に入り、ODB ネットワークに到達する前に検査 VPC を通過します。 南北トラフィックフロー (インターネット送信トラフィックの send-to アクション) 図 3: AWS Cloud WAN のサービス挿入を使用した南北インターネット送信トラフィック検査 図 3 のように、ODB Network セグメントに検査 NFG を指す send-to アクションが設定されています。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。ODB ネットワークからのインターネット宛てトラフィックは検査 VPC に誘導され、検査後に NAT ゲートウェイとインターネットゲートウェイを経由してインターネットに出ます。パターン 1 と同様に、ピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。 以下はこのフロー (図 3 の ‘d’) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 ODB トランジット VPC がパケットを Transit Gateway に転送します。Transit Gateway は TGW ルートテーブルアタッチメント経由で AWS Cloud WAN コアネットワークにパケットを送信します。 ODB Network セグメントに send-to アクションが設定されているため、AWS Cloud WAN のルーティングテーブルがインターネット宛てパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査を通過したパケットは NAT ゲートウェイに転送されます。NAT ゲートウェイがソース NAT を実行し、インターネットゲートウェイにパケットを転送してインターネットに送出します。 インターネットからの戻りトラフィックはインターネットゲートウェイに到着し、NAT ゲートウェイでアドレス変換を経てファイアウォールに戻り検査されます。検査後、パケットは NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。NFG ルートテーブルには TGW ルートテーブルアタッチメントを指す ODB ネットワーク CIDR の伝播ルートがあり、パケットは Transit Gateway、ODB トランジット VPC を経由して ODB ネットワークに戻ります。 これらのパターンはマルチリージョンデプロイメントにも拡張できます。リージョン VPC、Transit Gateway、検査インフラストラクチャを同じ AWS Cloud WAN コアネットワークにアタッチすることで、追加リージョンをオンボードできます。 考慮事項 Oracle Database@AWS のネットワーク検査を実装する際は、以下の考慮事項を念頭に置いてください。 ODB ピアリングされた CIDR – ピアリングされた CIDR リストは、ピアリング接続を通じて ODB ネットワークと通信可能なすべての CIDR を定義します。東西トラフィックの場合、アプリケーション VPC CIDR (プライマリおよびセカンダリ) とオンプレミスネットワーク CIDR を含めます。AWS 経由で出る南北インターネット宛てトラフィックの場合、データベースが到達する必要がある特定のインターネット宛先 CIDR を含めます。本記事の執筆時点では 0.0.0.0/0 エントリは許可されていないため、ピアリングされた CIDR の制限に準拠する個別の CIDR 範囲にインターネット宛先を分割する必要があります。検査は透過的でオリジナルのソース IP を保持するため、検査 VPC CIDR を含める必要はありません。ピアリングされた CIDR の設定と制限については「 Oracle DB@AWS Internet Outbound Traffic 」を参照してください。 フロー対称性のためのアプライアンスモード – 検査 VPC の Transit Gateway アタッチメント (パターン 1) または AWS Cloud WAN アタッチメント (パターン 2) で アプライアンスモード を有効にしてください。有効にしないと、往路と復路が異なるアベイラビリティゾーンを通過し、ステートフル検査が破綻する可能性があります。 AWS Network Firewall ネイティブ Transit Gateway アタッチメント – AWS Network Firewall は専用の検査 VPC なしで東西検査を行うネイティブ Transit Gateway アタッチメントをサポートしています。南北の送信トラフィックには NAT ゲートウェイを備えた別の VPC が引き続き必要です。 DNS トラフィックパス – ODB ネットワークへの DNS クエリはデータトラフィックと同じ検査パスを通ります。ファイアウォールルールで考慮するか、検査をバイパスするために ODB トランジット VPC に Amazon Route 53 Resolver アウトバウンドエンドポイントを配置してください。 マルチリージョンデプロイメント – クロスリージョンのレイテンシーとデータ転送コストを回避するため、各リージョンに検査 VPC をデプロイしてください。パターン 2 では、AWS Cloud WAN の機能 (シングルホップモード) でどのリージョンの検査 VPC を使用するかを制御できます。 まとめ 本記事では、Oracle Database@AWS に対する集中ネットワークトラフィック検査を実装する方法を紹介しました。単一リージョンデプロイメントでは AWS Transit Gateway と集中検査 VPC を、マルチリージョンアーキテクチャでは AWS Cloud WAN のサービス挿入を使用します。ODB トランジット VPC はインライン検査をサポートしないため、どちらのアプローチも専用の検査 VPC 経由でトラフィックをルーティングします。詳細は「 AWS Network Firewall のドキュメント 」、「 AWS Cloud WAN サービス挿入のドキュメント 」、「 Oracle Database@AWS ユーザーガイド 」を参照してください。 著者について Sameer Malik Sameer は、AWS のプリンシパルデータベースソリューションアーキテクトです。RDS と Aurora に注力し、23 年以上にわたりリレーショナルデータベースに携わってきました。多数のお客様のデータベースワークロード移行・モダナイゼーションを支援しています。 Anvesh Koganti Anvesh は、AWS のソリューションアーキテクトで、ネットワーキングを専門としています。高いスケーラビリティとレジリエンスを備えた AWS ネットワーキングアーキテクチャの構築を支援しています。 Shubham Singh Shubham は、AWS のシニアネットワークスペシャリストソリューションアーキテクトです。AWS サービスを活用した革新的でレジリエントかつコスト効率の高いソリューション設計を支援しています。ネットワーキングとセキュリティ分野でのソリューション構築に注力し、Northeastern 大学でコンピュータネットワーキング専攻のテレコミュニケーションシステム管理修士号を取得しています。 Vihar Kodakandla Vihar は、AWS のドメインスペシャリストエンジニアです。UOps のお客様に対し、オンボーディング、コンテキスト構築、Critical Workload Review を通じたプロアクティブなメカニズムの提供に注力しています。複雑な技術的課題のトラブルシューティングや、AWS ネットワーキングサービス全体のレジリエンスとオブザーバビリティ向上の機会特定を支援しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 11 日 に公開された「 Provision Oracle Database@AWS resources using Terraform 」を翻訳したものです。 本記事では、 Terraform を使用して Oracle Database@AWS の主要コンポーネント（ ODB ネットワーク 、 Oracle Exadata インフラストラクチャ 、 Exadata VM クラスター 、 Autonomous VM クラスター ）をプロビジョニングする方法を紹介します。 Oracle Database@AWS （ODB@AWS）は、 Oracle Cloud Infrastructure（OCI） が管理する Oracle Exadata インフラストラクチャを AWS データセンター内から提供するサービスです。Oracle Database@AWS を使用すると、Oracle データベースを AWS に移行しながら、Exadata の高パフォーマンス、スケーラビリティ、高度な機能を活用できます。Oracle Database@AWS は、 Amazon Simple Storage Service（Amazon S3） 、 zero-ETL パイプライン、 AWS Key Management Service（AWS KMS） などの AWS サービスと密に統合されています。Oracle データベースは、Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service（Amazon EKS）などにデプロイされたアプリケーションと並行して動作します。この密な統合により、データフローが簡素化され、セキュリティが強化され、多様なコンピューティング環境でのアプリケーション開発が加速します。 現在、Oracle Database@AWS では以下の Oracle Database サービスが提供されています： Oracle Autonomous AI Database on Dedicated Exadata Infrastructure （ADB-D） Oracle Exadata Database Service on Dedicated Infrastructure （ExaDB-D） Infrastructure as Code（IaC）は、構成ファイルを通じてアプリケーションのインフラストラクチャをプロビジョニング・管理するプロセスです。IaC を使用すると、インフラストラクチャ管理を一元化し、リソースを標準化し、迅速にスケールできます。新しい環境を再現可能で、信頼性が高く、一貫性のある状態で構築できます。Oracle Database@AWS のリソースは、 Terraform や AWS CloudFormation などの IaC ツールでデプロイできます。 HashiCorp Terraform は、クラウドとオンプレミスのリソースを、バージョン管理・再利用・共有が可能な人間が読める構成ファイルで定義できる IaC ツールです。一貫したワークフローで、ライフサイクル全体を通じてインフラストラクチャをプロビジョニング・管理できます。 本ウォークスルーは、Oracle Database@AWS のプロビジョニングを自動化したいデータベース管理者や DevOps エンジニアを対象としています。 ソリューション概要 Oracle Database@AWS を使い始めるには、 AWS Marketplace のリスティングを確認します。サービスを利用するには、 オンボーディング と呼ばれるプロセスで AWS アカウント内の構成を行います。オンボーディングを開始するには、Oracle の担当者に連絡してプライベートオファーをリクエストします。価格、利用条件に合意した後、AWS Marketplace で購入を完了します。購入完了後、AWS アカウントと OCI テナンシーをリンクします（マルチクラウドリンク）。要件に応じて、 エンタイトルメント共有機能 を使用して、同じ AWS Organization 内の AWS アカウント間で ODB@AWS の AWS Marketplace エンタイトルメントを共有できます。オンボーディング完了後、Exadata Database Service on Dedicated Infrastructure および Autonomous AI Database on Dedicated Exadata Infrastructure 用の Oracle Database@AWS システムリソースのプロビジョニングを開始できます。プロビジョニングは ODB ネットワークと Exadata インフラストラクチャの作成から始まります。ワークロードと要件に基づいて、Exadata VM クラスターまたは Autonomous VM クラスターを作成します。Exadata VM クラスターは Oracle Exadata Database Service をサポートし、Autonomous VM クラスターは Autonomous AI Database on Dedicated Exadata Infrastructure をサポートします。 Oracle Database@AWS の利用を開始するには、Oracle Database@AWS コンソール、AWS Command Line Interface（AWS CLI）、または API を使用して以下のリソースを作成します： ODB ネットワーク Oracle Exadata インフラストラクチャ Exadata VM クラスターまたは Autonomous VM クラスター ODB ピアリング接続 次の図は Oracle Database@AWS のアーキテクチャを示しています。 以下のセクションでは、Oracle Database@AWS のアーキテクチャと主要コンポーネントについて説明します。 Amazon Virtual Private Cloud とサブネット ： Amazon Virtual Private Cloud（Amazon VPC）では、定義した仮想ネットワークに AWS リソースを起動できます。この仮想ネットワークは、自社データセンターで運用する従来のネットワークと同様ですが、AWS のスケーラブルなインフラストラクチャを活用できます。VPC を作成した後、サブネットを追加できます。サブネットは Amazon VPC 内の IP アドレス範囲です。特定のサブネットに Amazon EC2 インスタンスなどの AWS リソースを作成できます。 OCI Virtual Cloud Network（VCN）とサブネット ： Virtual Cloud Network（VCN）は、指定した Oracle リージョン内の OCI テナンシーに設定するカスタマイズ可能なプライベートネットワークです。コンピュートインスタンス、データベース、ストレージなどの OCI リソースをデプロイ・管理するための、安全でスケーラブルなネットワーク環境を提供します。VCN により、論理的に分離されたネットワーク内でクラウドリソースを隔離・セグメント化し、セキュリティと管理性を向上できます。Oracle マルチクラウドアーキテクチャでは、AWS リージョン内にクライアントサブネットとバックアップサブネットを持つ ODB ネットワークを作成すると、対応する OCI VCN とサブネットが OCI テナンシーに自動的に作成されます。VCN はペアリングされた OCI リージョンに作成されます。詳細については、「 Overview of VCNs and Subnets 」を参照してください。 OCI リージョン（親サイト）： OCI リージョンは、アベイラビリティドメインと呼ばれる 1 つ以上のデータセンターがある地理的エリアです。Oracle マルチクラウドモデルでは、ペアリングされた AWS リージョンに接続された OCI リージョンを親サイトと呼びます。ODB@AWS は「 Regional Availability 」で説明されているリージョンでのみ利用可能です。 OCI 子サイト ： OCI 子サイトは、OCI アベイラビリティドメイン（AD）を AWS リージョン内のアベイラビリティゾーン（AZ）に拡張するデータセンターです。OCI 子サイトモデルでは、Oracle Database@AWS で使用される Exadata インフラストラクチャは物理的には AWS データセンター（AWS リージョン内の AZ）に配置されますが、論理的には OCI リージョンとそのネットワークコンポーネントにマッピングされます。 ODB ネットワーク ： ODB ネットワークは、指定した AWS アベイラビリティゾーン（AZ）内で Oracle Exadata VM クラスターと Autonomous VM クラスターをホストするプライベートで分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI 子サイト内のネットワークに直接マッピングされ、AWS と OCI 間の通信を実現します。Oracle マルチクラウドアーキテクチャでは、ODB ネットワークが Oracle Database@AWS サービスの OCI コンポーネントにネットワーク接続を提供します。 ODB ネットワークの作成時に、以下の情報を指定します： アベイラビリティゾーン — ODB ネットワークは特定の AZ に紐づきます。サポートされるリージョンとアベイラビリティゾーンの最新リストは「 Regional Availability 」を参照してください。アカウント内の論理 AZ 名と物理 AZ ID のマッピングを確認するには、次のコマンドを実行します。 aws ec2 describe-availability-zones \ --region us-east-1 \ --query "AvailabilityZones[*].{ZoneName:ZoneName, ZoneId:ZoneId}" \ --output table クライアント CIDR アドレス — ODB ネットワークには、Exadata VM クラスターと Autonomous VM クラスター用の クライアントサブネット CIDR が必要です。 バックアップ CIDR アドレス — ODB ネットワークには、VM クラスターのマネージドデータベースバックアップ用の バックアップサブネット CIDR が必要です。バックアップサブネットは Exadata VM クラスターではオプションです。 AWS サービス統合 — Amazon S3 や Amazon Redshift との zero-ETL など、AWS サービス統合用のネットワークパスを構成できます。詳細については「 AWS service integrations 」を参照してください。CIDR 要件の詳細については「 ODB Network creation 」を参照してください。 Oracle Exadata インフラストラクチャ ： Oracle Exadata インフラストラクチャは、Oracle データベースを実行するために設計された高パフォーマンスの統合ハードウェア・ソフトウェアプラットフォームです。Oracle マルチクラウドアーキテクチャでは、Exadata インフラストラクチャは Oracle Exadata Database Service と Oracle Autonomous AI Database の両方の基盤ハードウェアです。 Oracle Database@AWS で Exadata インフラストラクチャを作成する際に、以下の情報を指定します： データベースサーバーの総数 ストレージサーバーの総数 Exadata システムモデル（X11M） インフラストラクチャをホストする AZ（「 Supported Regions for Oracle Database@AWS 」を参照） 詳細については「 Exadata Infrastructure 」を参照してください。 Exadata VM クラスター ：Exadata VM クラスターは、密結合された Exadata VM のセットです。各 VM には、Oracle Real Application Clusters（Oracle RAC）や Oracle Grid Infrastructure などの Oracle Enterprise Edition の機能を含む、完全な Oracle データベースインストールがあります。VM クラスター上に 1 つ以上の Oracle Exadata データベースを作成できます。 VM と VM クラスターのアーキテクチャ図については「 Exadata Database Service on Dedicated Infrastructure Technical Architecture 」を参照してください。 VM クラスターの作成時に、以下の情報を指定します： ODB ネットワーク Oracle Exadata インフラストラクチャ クラスター内の VM を配置するデータベースサーバー 使用可能な Exadata ストレージの合計容量 詳細については「 Exadata VM Cluster 」を参照してください。 Autonomous VM クラスター ：Autonomous VM クラスター（AVMC）を使用すると、物理的な Exadata クラスター（マシン）を複数の仮想クラスターにパーティション分割できます。アクセスルール、ネットワーク構成、コンピューティング・メモリ・ストレージリソースのカスタマイズにより、データベースワークロードごとに環境を分離できます。Autonomous VM クラスターの作成時に、VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous コンテナデータベースの最大数を構成できます。詳細については「 Create Autonomous VM Cluster 」を参照してください。 ODB ピアリング ： ODB ピアリングは、Amazon VPC と ODB ネットワーク間でトラフィックをプライベートにルーティングするネットワーク接続です。Oracle マルチクラウドアーキテクチャでは、VPC 内のアプリケーションと ODB ネットワーク内の Oracle データベース間のトラフィックは、パブリックインターネットを経由せず ODB ピアリングを通じてプライベートにルーティングされます。詳細については「 creating ODB peering connection 」を参照してください。 Oracle Exadata データベース ：Oracle Database@AWS では、AWS コンソールを使用して Exadata データベースをホストする Oracle Exadata インフラストラクチャと VM クラスターを作成します。その後、OCI API を使用して Oracle データベースを作成・管理します。データベースの作成方法の詳細については「 Exadata Database 」および「 Autonomous Database 」を参照してください。 Oracle Database@AWS のコンポーネントの詳細については「 Architecture 」を参照してください。 上記リソースの作成手順の詳細については「 creating resources in your Oracle Database@AWS 」を参照してください。 前提条件 開始する前に、以下の前提条件を確認してください： Terraform の基本的な理解 Oracle Database@AWS の概要の理解 「 Onboarding to Oracle Database@AWS 」の手順の完了。Oracle Database@AWS を使用するにはプライベートオファーを受け入れている必要があります。 AWS Identity and Access Management（IAM）プリンシパルに「 Allow users to provision Oracle Database@AWS resources 」に記載されたポリシー権限を付与。Oracle Database@AWS を使用するにはこれらの権限が必要です。 以下の Terraform テンプレートを使用して、Oracle Database@AWS のさまざまなリソースをプロビジョニングできます。ビジネス要件に応じてパラメータをカスタマイズしてください。テンプレートを適用する前に、各パラメータの意味と許容値を理解してください。 Oracle Database@AWS リソースのプロビジョニング用に以下のテンプレートが利用可能です。最新情報については「 Provisioning Oracle Database@AWS through Terraform 」を参照してください。 ステップ 1：ODB ネットワークの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で ODB ネットワークを作成 します。 # Create an ODB Network without AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "DISABLED" zero_etl_access = "DISABLED" tags = { "env" = "dev" } } # Create an ODB Network with AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "ENABLED" zero_etl_access = "ENABLED" tags = { "env" = "dev" } } IP アドレス要件の詳細については「 Planning IP address space in Oracle Database@AWS 」を参照してください。 ステップ 2：Oracle Exadata インフラストラクチャの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で Oracle Exadata インフラストラクチャを作成 します。 # Create an Exadata Infrastructure resource "aws_odb_cloud_exadata_infrastructure" "example" { display_name = "my-exa-infra" shape = "Exadata.X11M" storage_count = 3 compute_count = 2 availability_zone_id = "use1-az6" customer_contacts_to_send_to_oci = [{ email = "abc@example.com" }, { email = "def@example.com" }] database_server_type = "X11M" storage_server_type = "X11M-HC" maintenance_window { custom_action_timeout_in_mins = 16 days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [11, 16] is_custom_action_timeout_enabled = true lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] patching_mode = "ROLLING" preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 3：Exadata VM クラスターまたは Autonomous VM クラスターの作成 以下の Terraform 構成を使用して、Oracle Database@AWS で Exadata VM クラスター または Autonomous VM クラスター を作成します。 # Create Exadata VM cluster with minimum parameters resource "aws_odb_cloud_vm_cluster" "with_minimum_parameter" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["public-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["db-server-1", "db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 data_collection_options { is_diagnostics_events_enabled = false is_health_monitoring_enabled = false is_incident_logs_enabled = false } } # Create Exadata VM cluster with all parameters resource "aws_odb_cloud_vm_cluster" "with_all_parameters" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["my-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["my-dbserver-1", "my-db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 cluster_name = "julia-13" timezone = "UTC" scan_listener_port_tcp = 1521 tags = { "env" = "dev" } data_collection_options { is_diagnostics_events_enabled = true is_health_monitoring_enabled = true is_incident_logs_enabled = true } } # Create Autonomous VM cluster with minimum parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_minimum_parameters" { cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" # ids of db server. refer your exa infra. This is a mandatory field. Refer your cloud Exadata infrastructure for db server id db_servers = ["<my_db_server_id>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { preference = "NO_PREFERENCE" } } # Create Autonomous VM cluster with all parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_all_params" { description = "my first avmc" time_zone = "UTC" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" db_servers = ["<my_db_server_1>", "<my_db_server_2>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [4, 16] lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 4：ODB ピアリング接続の作成 以下の Terraform 構成を使用して、 ODB ピアリング接続を作成 します。 resource "aws_odb_network_peering_connection" "example" { display_name = "example" odb_network_id = "my-odb-network-id" peer_network_id = "my-vpc-id" tags = { "env" = "dev" } } Terraform を使用した ODB@AWS スタックの作成 Terraform でリソースをプロビジョニングするには、以下の手順を完了します。この Terraform テンプレートは以下のリソースを作成します： VPC インターネットゲートウェイ パブリックサブネット 2 つ プライベートサブネット 2 つ パブリックルートテーブル プライベートルートテーブル パブリックルート 4 つのサブネットすべてのルートテーブル関連付け ODB ネットワーク ODB ピアリング接続 Exadata インフラストラクチャ Exadata VM クラスター Autonomous VM クラスター デプロイ前にテンプレートをよく確認してください。不要なリソースがある場合は、テンプレートを適宜修正してください。 GitHub リポジトリ をローカルマシンにクローンするか、AWS Samples からスクリプトをダウンロードします。 git clone https://github.com/aws-samples/sample-odb-launch-using-terraform GitHub README に従って前提条件を確認し、Terraform スタックをデプロイします。 terraform apply を実行する前に terraform plan を実行して、提案されたすべての変更を確認します。適用前にプラン出力で destroy や replace アクションがないか慎重に確認してください。 スタックデプロイの完了を確認します。 重要： Terraform リソースの特定のプロパティ（CpuCoreCount や DbServers など）を変更すると、Terraform はインプレース更新ではなくリソース全体を置き換えます。既存リソースを変更する前に、 Terraform ドキュメント で置き換えをトリガーするプロパティの完全なリストを確認してください。 リソースの作成後、VPC と ODB ネットワーク間の接続を構成します。以下の手順を完了してください： OdbPeeringConnection 用の VPC ルートテーブルの構成 Oracle Database@AWS 用の DNS 構成 アウトバウンドエンドポイント： ODB ネットワークに DNS クエリを送信するために必要です。 リゾルバールール： Amazon Route 53 Resolver が ODB ネットワークの DNS に転送する DNS クエリのドメイン名を指定するルールです。 詳細については「 network configuration 」を参照してください。 クリーンアップ 継続的な課金を避けるため、作成したリソース（ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター）を削除してください。 Terraform スタックの一部として起動されたその他のリソースを削除するには、 GitHub README に記載された手順に従い terraform destroy を実行してください。 ODB ネットワークの削除時は、 delete_associated_resources を true に設定してください。このパラメータのデフォルトは false です。 true に設定しない場合、以前の ODB ネットワークにマッピングされた OCI VCN はそのまま残ります。 まとめ 本記事では、Terraform を使用して ODB ネットワーク、Exadata インフラストラクチャ、Exadata VM クラスター、Autonomous VM クラスターなどの Oracle Database@AWS リソースをプロビジョニングする方法を説明しました。Terraform による Infrastructure as Code を採用することで、デプロイを自動化し、環境全体で一貫性を維持し、Oracle Database@AWS スタックの管理を効率化できます。 詳細については「 Getting started with Oracle Database@AWS 」を参照してください。 著者について Javeed Javeed は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当しています。AWS Cloud でのリレーショナルデータベースワークロードの設計、デプロイ、最適化の支援に情熱を注いでいます。 Sharath Chandra Kampili Amazon Web Services のデータベーススペシャリストソリューションアーキテクトです。AWS RDS チームで Oracle などの商用データベースエンジンを担当しています。AWS のお客様と直接協力し、データベースプロジェクトに関するガイダンスと技術支援を提供しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。