この記事は、Ludovico Caldaraによる”Application and AI Scalability with Oracle Active Data Guard“の日本語翻訳版記事です。
2025年08月22日
ビジネス成長や季節的需要、マーケティングキャンペーンなどによりワークロードが予測できず急増する現代において、スケールアウト戦略は重要な役割を果たします。ワークロードを効率的に分散する計画がなければ、リードもしくはライト処理の急激な増加によってプライマリ・データベースの処理能力が限界に達し、パフォーマンスが著しく低下したり、インフラの拡張やアプリケーションのアーキテクチャ変更に迫られる可能性も出てきます。
Oracle Active Data Guardは、データ保護に最適なソリューションとして高い評価を得ています。その強みは、非常に効率的なレプリケーション技術、包括的なエンドツーエンドのデータ検証、さらにAutomatic Block RepairやFast-Start Failoverなどの先進機能にあります。なかでも「リアルタイム・クエリー」や「DMLリダイレクション」といった主要機能により、リニアなリードオンリー・スケーラビリティなど、数多くの利点を提供します。
Active Data Guardのスケールアウト機能を活用することで、企業は予期せぬ負荷増大にも対応できる柔軟な基盤を構築できます。複数のスタンバイ・データベース間でリードオンリー・トラフィックを分散させることで、プライマリ・システムのパフォーマンスを維持しつつ、リード負荷を容易に拡張することが可能です。ダウンタイムや遅延が収益や顧客満足度に直結する環境において、Oracle Active Data Guardは欠かすことのできないソリューションといえるでしょう。
リードオンリーワークロードの一貫した線形スケーラビリティ
「リアルタイム・クエリー」により、スタンバイ・データベースでリードオンリー・ワークロードを処理できるため、プライマリ・データベースの重要なリソースをリード／ライト処理に集中させ、トランザクション全体のスループットを向上させます。この方式には二重の利点があります。プライマリ・データベースはリード／ライト処理に特化する一方、複数のスタンバイ・データベースにリードオンリー・ワークロードをリニアに拡張できます。各スタンバイ・データベースはプライマリ・データベースの完全なレプリカであり、スケールアウト可能な“共有しない”アーキテクチャによるデータアクセスを実現します。
下図では、多くのリード操作をプライマリからスタンバイへオフロードすることで、追加された計算リソースによってリード／ライトのスループットが向上する様子を示しています。
DMLリダイレクションで、リードオンリーサービスの枠を超えたアプリケーション展開
Oracle Active Data Guardを利用すれば、アプリケーションがスタンバイ・データベースに接続し、DML操作をDMLリダイレクション機能によって実行することができます。この機能は、書き込み操作を透過的にプライマリ・データベースへリダイレクトする一方で、取引はスタンバイ上で実行されたように見えます。これによりACIDトランザクションの一貫性が保証され、トランザクションがコミットされるまで変更内容はアクティブ・セッションのみが閲覧できます。
この機能は、主にリード操作が多いが、ごく稀にライトも必要とするアプリケーションに新たな機会をもたらします。従来、このようなアプリケーションは書き込み操作時には必ずプライマリ・データベースへの接続が必要でしたが、DMLリダイレクションを使えば、全てのリード操作をスタンバイにオフロードしつつ、ライト操作もシームレスに実現できます。
DMLリダイレクションに関する詳細は、こちらのブログ記事 をご参照ください。
読み取りのみのワークロード以外をスタンバイ・データベースにオフロード
https://blogs.oracle.com/oracle4engineer/post/ja-dml-redirection
セレクトだけではない：AIワークロードなどのオフロードも実現
Oracle Databaseに組み込まれているONNX Runtimeを利用することで、機械学習モデルをデータの近くで、最小限のレイテンシやデータ移動で実行できます。モデルはプライマリにロードされていれば、スタンバイ・データベースでも推論に利用可能です。推論時に生成されるベクトルやメタデータもDMLリダイレクションを通してプライマリへトランザクション処理されます。
このアーキテクチャは、特に大規模データセットを用いたAIワークロードにおいて優れたスケーラビリティを発揮します。エンベッディング生成からRAG（Retrieval-Augmented Generation）やベクトル検索まで、エンド・ツー・エンドのAIワークフローをサポートしながらも、プライマリ・データベースのパフォーマンスを犠牲にしません。これにより、Oracle Databaseは拡張性に優れたAI対応アプリケーションのための魅力的なプラットフォームとなります。
スケールアウト・ワークロードの分散
リードオンリー・サービスへのオフロード時にはバッファキャッシュの役割が重要です。リカバリ中は影響を受けたブロックがキャッシュにロードされる必要があり、同時にスタンバイ・データベースでのクエリー・セッションもデータをディスクからバッファキャッシュへ読み込むため、競合する場合があります。
キャッシュを効率的に活用するため、主に2つの方法があります。
-
全スタンバイ・データベースで同じリードオンリー・サービスを分散
シンプルな構成で、アプリケーションからリードワークロードを均等に分散します。しかし、複数のスタンバイで“ホットブロック”が重複キャッシュされるため、冗長となりやすい点がデメリットです。 -
用途特化サービスの作成
各アプリケーションモジュールやマイクロサービスごとに専用サービスを割り当て、特定用途ごとにインスタンスを分散配置することで、特定用途のキャッシュヒット率を向上できます。特にマイクロサービス展開に最適で、それぞれが専用スタンバイで自身のデータ領域へアクセスできます。Oracle Real Application Clusters（RAC）との組み合わせでは、サービスを適切なインスタンスに起動できますし、シングルインスタンス構成にも応用可能です。
リード処理をプライマリ・データベースからスタンバイ・データベースへオフロードすることで、プライマリのバッファキャッシュに対する負荷も軽減されます。これは、リード専用でキャッシュしなければならないブロック数が減少するためです。その結果、バッファキャッシュ内に「ダーティブロック」（更新済みだがまだディスクに書き込まれていないブロック）用の空き領域が増え、データベース・ライター（DB writer）の活動量を抑えることができます。
同様に、Oracle Cloud Infrastructure（OCI）やエンジニアド・システム上で稼働するワークロードの場合、スタンバイ・データベースにおけるDatabase In-Memoryの活用も可能です。サービスごとの要件に応じて、必要なテーブルだけをインメモリで展開できるため、リソースを効率的に利用しつつパフォーマンスの最適化が図れます。
サービスが最適に分散されている場合、この機能によってインメモリ領域の有効活用範囲を大きく広げることができ、対象テーブルに対して高速なインメモリのカラム型スキャンを実現します。
例えば、プライマリ・データベースはOLTPワークロード専用として運用し、レポーティング用のテーブルはSGA内のインメモリ領域がより大きいスタンバイ・データベースに配置することが可能です。この構成により、レポートでは従来のヒープテーブルの読み取りよりも桁違いに高速なカラム型スキャンを活用できるようになります。
アプリケーションで複数のデータソースを活用
現代のアプリケーション、特にマイクロサービス・アーキテクチャを採用する場合、少なくとも2つの異なるデータソースを用意することが重要です。1つはリード／ライト処理用、もう1つはリードオンリー処理用です。
リードオンリー専用のデータソースを構成することで、アプリケーションのリード処理を簡単にスタンバイ・データベースへオフロードでき、ライトを伴わないワークロード全体のスケールアウトを実現できます。この分離により、リソースの有効活用とアプリケーションの応答性向上が期待できます。
さらに、スタンバイ・データベースを複数用意しておけば、プライマリとスタンバイの切り替えが発生した場合もリードオンリーサービスを継続して提供でき、リードオンリーサービスを利用するアプリケーション・モジュール（またはマイクロサービス）が途切れることなく稼働し続けることができます。
多数のサービスやスタンバイ・データベース接続の簡素化
多数のサービスやスタンバイ・データベースへの接続の簡素化
リードオンリー・レプリカが複数存在する環境でアプリケーションをスケールさせる際、特に同一サービスを複数のレプリカが提供している場合、アプリケーションをどのスタンバイ・データベースへ効率よくリダイレクトするかがアーキテクチャ上の大きな課題となります。そのためには、スタンバイ・データベースの可用性やレプリケーションの遅延（特に一貫性や最新性が求められる場合）、各スタンバイの現在の負荷、さらにはアプリケーションサーバやコンテナとの地理的な近接性（レイテンシもパフォーマンスに大きな影響を及ぼします）など、さまざまな要素を考慮する必要があります。
この課題をシームレスに解決するのがGlobal Data Services（GDS）です。GDSはアプリケーションのための単一のエントリーポイントを提供し、バックエンドのデータベースやサービスの状況を完全に把握した、インテリジェントかつデータベースを理解したリバースプロキシのような役割を果たします。スタンバイ・データベースは常に自身の負荷やレプリケーション遅延をGDSへ報告しており、GDSは予め定められた基準を満たさないデータベースへのクライアント接続を自動的にブロックします。また、GDSはロケーション認識も備えており、クライアント接続を最も近いレプリカへインテリジェントにルーティングすることで、レイテンシを最小化し、アプリケーションのパフォーマンスを向上させます。
さらに、GDSは業界標準のSQL*Netプロトコル上に構築されており、どのデータベースが現在必要なサービスを実際に提供しているかをリアルタイムで把握できます。GDSを利用するアプリケーションは、Oracleドライバーが持つ自動リトライ、セッション排出、アプリケーション継続性などの機能を最大限活用でき、分散環境においても高い可用性と最適なパフォーマンスを確保することが可能です。
最終的に、アプリケーションはGDSエンドポイントに接続するデータソースを利用することで、必要なサービスを高可用性パラメータ付きで指定するだけで、背後にあるレプリケーション構成やスタンバイ・データベースの数を意識する必要がなくなります。
GDSは一つのレイヤーを追加するものの、全体のアーキテクチャを大幅にシンプル化できます。GDSが存在しない場合、お客様はスタンバイ・データベースの追加や削除のたびに都度、データソースURL（接続ディスクリプタ）の手動更新が必要となり、各スタンバイの古さ（スタレ具合）の管理や接続先のリダイレクト対応も求められます。GDSを利用することでこれらの複雑な作業は不要となり、最小限の運用負荷で最適な接続性とパフォーマンスを実現する、シームレスかつインテリジェントなソリューションを提供します。
Oracle DatabaseエコシステムにおけるActive Data Guardのスケーラビリティ
Oracle Active Data Guardは、リニアなリードオンリー・スケーラビリティを提供し、スタンバイ・データベース上でのDML実行もサポートしていますが、完全なリード／ライト・スケーラビリティには対応していません。
優れたリード／ライトのスケーラビリティと高いパフォーマンスを求めるお客様には、Oracle Real Application Clusters（RAC）が最適なソリューションです。RACを利用することで、リード／ライトのワークロードを数十ノードにわたって分散しつつ、サブミリ秒レベルのトランザクション遅延を維持することが可能です。Oracle Active Data GuardとReal Application Clustersは、それぞれの強みを補完し合い、最適なスケーラビリティを実現します。
さらに大規模なスケーラビリティを求める場合には、Oracle ExadataおよびOCI上で提供されるExadata Database Servicesによって、RACのパフォーマンスを次のレベルへ引き上げることが可能です。これにより、ほぼリニアなストレージのスケーラビリティと、極限のパフォーマンスや超低I/Oレイテンシ（Exadata X11では14マイクロ秒）といった独自の機能を実現できます。
Oracle Exadataは、世界でも有数の重要かつ大規模なワークロードを支えています。また、リード／ライトのスケーラビリティとデータ分散の両方を必要とする組織には、Oracle Globally Distributed Databaseが、これらの機能をExadataクラスタや異なるリージョン間へ拡張し、他に類を見ないパフォーマンスとグローバルな展開力を提供します。
最後に、Oracle True Cacheは、高容量なストレージを必要とせずに、Active Data Guardの多くのスケールアウト機能を実現します。全データベースのコピーを常時保持することなく、クエリーのオフロードに最適な、一貫性と最新性を兼ね備えたレプリカを提供できます。