Amazon Web Services ブログ

REDO 圧縮による Amazon RDS for Oracle レプリカのレプリケーションラグ最適化 – パート 1

本記事は 2026 年 7 月 9 日 に公開された「Optimize replication lag for Amazon RDS for Oracle replicas using redo compression – Part 1」を翻訳したものです。

Amazon Relational Database Service (Amazon RDS) for Oracle レプリカは Oracle Data Guard テクノロジーで構築されており、プライマリインスタンスから読み取り専用ワークロードをオフロードしたり、エンドユーザーの近くにデータを配置したり、クロスリージョンレプリカによるディザスタリカバリ保護を実現したりできます。RDS for Oracle は、Data Guard 設定の Maximum Performance モードでレプリカをデプロイします。リモートレプリカインスタンスへの REDO 変更転送のレイテンシーがプライマリのパフォーマンスに影響しないようにするためです。

レプリカラグは、プライマリとレプリカインスタンス間のデータ乖離を示すメトリクスです。レプリカラグには、プライマリとレプリカ間のネットワークレイテンシー、インスタンスのリソース構成、ネットワーク帯域幅、トランザクションレートなど、さまざまな要因が影響します。ユースケースにかかわらず、レプリカをできるだけ低いラグで稼働させることが重要です。特に、低い目標復旧時点 (RPO) を満たすためのディザスタリカバリターゲットとして使用する場合に重要になります。この 2 部構成のブログシリーズでは、RDS for Oracle レプリカのラグを最適化する各種構成やチューニングオプション、トラブルシューティング手順を説明します。

パート 1 (本記事) では、REDO 圧縮機能を使用した RDS for Oracle レプリカのラグ最適化方法を紹介します。パート 2 では、RDS for Oracle レプリカのレプリケーションラグを監視、トラブルシュート、解決する各種テクニックを説明します。

REDO 圧縮とは何か、どのように役立つのか

低い RPO 要件を満たすために Oracle データベースをリモートロケーションにレプリケートする際の課題の一つは、レイテンシーが高かったり帯域幅に制約のあるネットワーク構成への対応です。トランザクション負荷の高いワークロードで REDO 生成レートが高い場合、特にクロスリージョンデプロイメントでは同一リージョン構成に比べてネットワーク経路のレイテンシーが増大するため、課題が顕著になります。ネットワーク制約に対する一般的なアプローチとして、圧縮技術を適用し、制約のあるネットワーク接続を通じて転送されるデータ量を削減する方法があります。

Oracle Data Guard の REDO トランスポート圧縮機能は、プライマリで REDO を圧縮してから転送し、スタンバイインスタンスで解凍することで、ネットワーク経由でリモートスタンバイインスタンスに送信されるデータ量を削減します。

RDS for Oracle は、レプリカインスタンスの REDO トランスポート効率を最適化する REDO 圧縮機能をサポートしています。特にクロスリージョンレプリカでは、同一リージョンレプリカに比べて REDO トラフィックがレイテンシーの高いネットワークを経由するため、トランスポートラグを大幅に削減できます。REDO 圧縮は転送する REDO データ量を大幅に削減できますが、圧縮と解凍の操作に追加の CPU サイクルを消費するというコストがあります。

Oracle Database の REDO トランスポート圧縮機能の詳細は、Redo Transport Compression in a Data Guard Environment (Doc ID 729551.1) を参照してください。

前提条件

本記事の手順は、以下のリソースとスキルがあることを前提としています。

  1. クロスリージョンレプリカを持つ RDS for Oracle Enterprise Edition インスタンスのペアが 2 セット。レプリカは Enterprise Edition の機能です。レプリカはマウント状態でもオープン状態でもかまいません。本記事ではリードレプリカ (オープンモード) を使用します。RDS for Oracle インスタンスのバージョンが REDO 圧縮機能をサポートしていることを確認してください。
  2. REDO 圧縮機能の実装に必要な Advanced Compression ライセンス。
  3. RDS for Oracle インスタンスのリソース使用率とレプリカラグの監視に Amazon CloudWatch モニタリングが有効化されていること。
  4. Oracle Data Guard の概念と構成に関する基本的な知識。

REDO 圧縮の有効化

RDS for Oracle での REDO トランスポート圧縮は、Redo transport compression with RDS for Oracle で説明されているとおり、パラメータグループで実装できます。レプリカインスタンスの rds.replica.redo_compression パラメータを ZLIB または LZO に設定して有効化します。これらがサポートされている圧縮アルゴリズムです。オプショングループでこのパラメータを有効にすると、LOG_ARCHIVE_DEST_n パラメータに COMPRESSION 属性が自動的に設定されます。パラメータを ENABLE に設定すると、圧縮アルゴリズムとして ZLIB が選択されます。プライマリインスタンスでこのパラメータを有効化しても、ロールトランジション後にプライマリがレプリカになる場合を除き、REDO 圧縮には影響しません。

Oracle ライセンスガイドによると、Data Guard Redo Transport Compression は Advanced Compression オプションに含まれ、Oracle Database Enterprise Edition とは別にライセンスされます。REDO 圧縮は、マウントレプリカ (データベースはマウント状態のまま、Active Data Guard ライセンス不要) とリードレプリカ (読み取り専用アクセス用にオープン、Active Data Guard ライセンスが必要) の両方で動作します。

RDS for Oracle で REDO 圧縮を有効にする際、ライセンス面を除き追加コストはかかりません。

REDO 圧縮の有無によるレプリケーションラグのテスト

このセクションでは、クロスリージョンレプリカ構成で REDO 圧縮を有効にした場合の影響と効果を示します。この例では、プライマリ-レプリカのペアが 2 組あり、一方は REDO 圧縮を有効、もう一方は無効にしています。プライマリインスタンスは us-east-1 で稼働し、リードレプリカは us-west-2 リージョンで稼働しています。テストは SLOB Oracle I/O ワークロード生成ツールキットを使用して合成ワークロードを生成しています。

SLOB ツールと設定の詳細は、SLOB ドキュメントを参照してください。

注意: このテスト結果は学習目的でのみ共有しています。REDO 圧縮の効果と影響はワークロード特性とデータ特性によって異なります。本番環境で有効にする前に、非本番インスタンスで実際のアプリケーションを使って REDO 圧縮をテストすることを強く推奨します。

ステップ 1: 圧縮有効と圧縮無効のプライマリ/レプリカインスタンスペアを準備する (プライマリは us-east-1、レプリカは us-west-2)

以下のテーブルは、テストに使用した 2 セットのプライマリ/レプリカインスタンスの構成を示しています。

インスタンス名 ロール インスタンスタイプ ストレージ構成 リージョン REDO 圧縮設定 (rds.replica.redo_compression)
blog-primary-compression-off primary db.r7i.8xlarge io2, 1TB, 40K iops us-east-1 DISABLE
blog-replica-compression-off read-replica db.r7i.8xlarge io2, 1TB, 40K iops us-west-2 DISABLE
blog-primary-compression-on primary db.r7i.8xlarge io2, 1TB, 40K iops us-east-1 ENABLE
blog-replica-compression-on read-replica db.r7i.8xlarge io2, 1TB, 40K iops us-west-2 ENABLE
  • アプリケーションのワークロード要件を満たすインスタンス/EBS 構成を選択することが重要です。今回のテストでは、安定した 40K IOPS と 1250 MB/s のスループットを得るために r7i.8xlarge を選択しました。
  • Performing common log-related tasks for Oracle DB instances で説明されているとおり、rdsadmin.rdsadmin_util.add_logfile を使用してプライマリインスタンスの REDO ログサイズを 512 MB に増やし、トランザクション負荷の高いワークロードに対応します。
  • Redo transport compression with RDS for Oracle で説明されているとおり、インスタンスペア (blog-primary-compression-on と blog-replica-compression-on) で rds.replica.redo_compression=ENABLE を有効にします。

ステップ 2: 両方のプライマリインスタンスに接続できる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに SLOB をインストールして設定する

SLOB はクライアント側のリソース消費は大きくありませんが、8 vCPU、32 GB RAM のインスタンスの使用を推奨します。

両方のプライマリインスタンスに対する負荷テストを同時に実行して結果を直接比較するために、SLOB を 2 つ別々にインストールします。

ステップ 3: SLOBDATA というテーブルスペースを作成し、800 スキーマ分のサンプルデータをロードする

プライマリインスタンスに接続するには、SQL*Plus などの任意のクライアントツールを使用して SLOBDATA テーブルスペースを作成します。

create tablespace SLOBDATA datafile size 100G

800 スキーマで SLOB データロードプロセスを実行します。

SLOB>./setup.sh SLOBDATA 800

データロードには slob.conf で以下のパラメータを使用しました。

各パラメータの詳細は、SLOB ドキュメントを参照してください。

UPDATE_PCT=50
SCAN_PCT=0
RUN_TIME=900
WORK_LOOP=0
SCALE=12428
SCAN_TABLE_SZ=1M
WORK_UNIT=256
REDO_STRESS=HEAVY
LOAD_PARALLEL_DEGREE=1
THREADS_PER_SCHEMA=3
ADMIN_SQLNET_SERVICE="compresson"  # This is the tnsnames.ora entry pointing to the primary instance
SQLNET_SERVICE_BASE="compresson" # This is the tnsnames.ora entry pointing to the primary instance

このステップは両方のプライマリインスタンスで実行する必要があります。

ステップ 4: 800 スキーマを使用して負荷テストを実行する

約 140 MB/s の REDO を生成する負荷が発生します。

2 つの SLOB インストールディレクトリをホストする同一の Amazon EC2 インスタンスから、両方のプライマリインスタンスに対する負荷テストを同時に開始できます。

負荷テストの開始時と終了時にプライマリインスタンスで SQL*Plus を使用して以下のクエリを実行し、インスタンスが生成した REDO サイズを確認できます。インスタンスで他のアクティビティが行われていないと仮定すると、開始値と終了値の差が負荷テストで生成された REDO サイズを示します。

select value from v$sysstat where name='redo size'  -> Consider this as Begin_redosize

SLOB を使用して負荷テストを実行します。

sh ./runit.sh 800 --> run load test with 800 schemas for 15 minutes

負荷テスト終了後に、クエリを再実行して REDO サイズを取得します。

select value from v$sysstat where name='redo size'  -> End_redosize

End_redosize-Begin_redosize が生成された REDO のバイト数を示します。

ステップ 5: CloudWatch とデータベースへのクエリでリソース使用率とレプリカラグを監視する

CloudWatch メトリクスを使用して、インスタンスの CPU 使用率、ネットワーク送信スループット、レプリカラグを監視できます。

以下のグラフは、REDO 圧縮を有効にしたレプリカインスタンスのレプリカラグが低く (最大 20 秒)、REDO 圧縮なしのレプリカインスタンスで発生した大きなラグ (338 秒) と比較して大幅に改善されたことを示しています。REDO 圧縮なしのインスタンスは、負荷テスト完了後のギャップ解消にもより長い時間を要しました。

以下のグラフは、テスト期間中のプライマリインスタンスでの REDO 生成レートと書き込みスループットを示しています。

Redo generation rate and write throughput on the primary instances during the testing period

以下のグラフは、テスト期間中に両インスタンスで同程度の REDO 生成統計 (ピーク約 140MB/s) を示しています。

Redo generation statistics during the testing period for both instances, with a peak of approximately 140 MB/s

この例では、REDO 圧縮によりプライマリとレプリカの両インスタンスで CPU 使用率がやや高くなっています。

以下のグラフは、テスト期間中のプライマリインスタンスの CPU 使用率を示しています。

CPU utilization on the primary instances during the testing period

以下のグラフは、テスト期間中のレプリカインスタンスの CPU 使用率を示しています。

CPU utilization on the replica instances during the testing period

以下のグラフは、REDO 圧縮を有効にした場合のネットワーク送信スループットの削減を示しています。

Reduced network transmit throughput when redo compression is enabled

さらに、REDO 圧縮を無効にしたレプリカで v$dataguard_stats ビューに対するクエリを実行すると、ラグの主な原因がアプライラグではなくトランスポートラグであることがわかります。

select name,value from v$dataguard_stats where name like '%lag%'
NAME VALUE
transport lag                    +00 00:04:11
apply lag                        +00 00:04:11

ドキュメントに記載されているとおり、アプライラグはターゲットデータベースのデータが元のデータベースのデータからどの程度遅延しているかを示す指標であり、ターゲットデータベースへの REDO の伝搬と適用の遅延が原因です。アプライラグにはトランスポートラグも含まれており、今回のテストではラグ全体がトランスポートラグに起因していました。

このテストにより、約 140 MB/s の REDO を生成するアプリケーションで RPO を最適化するために REDO 圧縮機能を使用する効果が明確に示されました。

注意: 140MB/s の REDO 生成は、インスタンスクラスとストレージ構成に基づいて今回のテスト用に選択したものです。ワークロードのリソース要件に対応する適切なインスタンスと EBS 構成を使用すれば、より高いトランザクションレートでテストできます。

推奨事項

  • プライマリインスタンスで rds.replica.redo_compression パラメータを設定してもレプリカへの REDO トラフィック圧縮には影響しませんが、Data Guard のロールトランジション後も REDO 圧縮が維持されるよう、プライマリでもパラメータを設定することを推奨します。
  • 本番インスタンスで REDO 圧縮を有効にする前に、追加の CPU 消費がワークロードのパフォーマンスに与える影響をテストしてください。
  • すべてのワークロードに最適な圧縮アルゴリズムは存在しません。本番環境に実装する前に、どのアルゴリズムが要件を満たすかテストする必要があります。
  • REDO 圧縮の有効/無効が混在したレプリカインスタンスの構成は可能ですが、混在構成では圧縮の実質的な効果が得られない場合があります。すべてのレプリカで同じ圧縮設定を統一することを推奨します。
  • データベースで Transparent Data Encryption (TDE) が構成されている場合や LOB 列が含まれている場合、圧縮率に悪影響を及ぼす可能性があります。本番環境に実装する前に、実際のスキーマとアプリケーションで効果をテストしてください。

クリーンアップ

テスト後、今回のテスト用にプロビジョニングしたリソースをクリーンアップできます。対象は以下のとおりです。

  1. RDS for Oracle プライマリインスタンス。
  2. RDS for Oracle リードレプリカ。
  3. SLOB モジュールをホストする Amazon EC2 インスタンス。

まとめ

本記事では、REDO 圧縮機能を使用して RDS for Oracle レプリカのレプリケーションラグを最適化する方法を説明しました。レプリカラグの最適化は、クロスリージョンのディザスタリカバリシナリオでビジネスサービスレベルアグリーメント (SLA) と RPO 要件を満たすための重要な要件です。また、データ乖離に対する許容度が低い読み取り専用クエリにレプリカを使用する場合にも重要になります。

RDS for Oracle は REDO トランスポート圧縮機能をサポートしており、低帯域幅ネットワーク経由でリモートレプリカに低いラグで REDO を転送できます。Advanced Compression 機能を使用するためのライセンス要件を確認し、ワークロード要件を満たすためにレプリカラグ最適化への活用を検討してください。

レプリカラグ関連の課題を解決するための各種監視およびトラブルシューティング手順については、パート 2 を参照してください。

著者について

Jobin Joseph

Jobin Joseph

Jobin は、トロント拠点の Senior Database Specialist Solutions Architect。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master の資格を持ち、Oracle データベースに関して 25 年以上の経験があります。

Manoj Ponnurangam

Manoj Ponnurangam

Manoj は、AWS の Senior Cloud Database Engineer。Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon Aurora for PostgreSQL、AWS DMS のサブジェクトマターエキスパートです。リレーショナルデータベースに関する 15 年の経験を持ち、各種データベースおよび移行プロジェクトについてお客様にガイダンスと技術支援を提供しています。

この記事は Kiro が翻訳を担当し、Solutions Architect の Satoru Yagi がレビューしました。