「RDBMS in the Cloud: Oracle Database on AWS」を読んでみたメモ (3) 〜パフォーマンス管理〜

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

AWS クラウドコンピューティング ホワイトペーパー に、AWS で Oracle Database を利用する際のホワイトペーパー「RDBMS in the Cloud: Oracle Database on AWS」が掲載されたので、読んでみました。

第3回目は P8〜P14「Performance Management」

※2013.10.15 修正 EBSボリュームの項において、「複数AZのサーバーでミラーされている」は誤りで「単一AZ内の複数サーバーでミラーされている」に修正しました。@hirot78 さんご指摘ありがとうございました。

パフォーマンス管理

AWS上のRDBインスタンスのパフォーマンスは、RDSやEC2のインスタンスタイプ、データベースソフトの設定、アプリケーションワークロード、EC2上にデータベースを稼働している場合であればストレージ設定など、沢山の要素に依存している。以下の章では、Oracle database を稼働しているAWSインフラのパフォーマンスをチューニングするために設定可能なオプションについて記載する。

インスタンスサイズ

データベースのパフォーマンス向上のためには、サーバーのリソースがパフォーマンスの制約になることを理解する必要がある。もしデータベースの性能がCPUやメモリ、ネットワークのスループットにより制限されているなら、より大きなインスタンスタイプを選択することで、メモリやコンピュートリソース、ネットワークパフォーマンスをスケールすることができる。

多くの顧客にとって、シングル構成のDBインスタンスのパフォーマンスを向上することは、アプリケーション全体のパフォーマンスを向上する最も簡単な方法である。これを解決する方法の一つが垂直スケールである。インスタンスサイズをスケールアップ(あるいはダウン)することで、データベースを、求めるパフォーマンスを提供できるハードウェアに配置する。


Amazon RDS のインスタンスサイズを決める
Amazon RDS ではワークロードに適したインスタンスクラスを選ぶことができる。Amazon RDS はいくつかのデータベースインスタンスのクラスをサポートしている。本書を書いてる時点で、とても小さい Micro インスタンスから、8仮想コア、68GBメモリ、高I/Oキャパシティを備えた 8xlarge インスタンスまで選択肢がある。Amazon RDS のインスタンスクラスはCPU、メモリ、I/Oキャパシティという観点でいうと Amazon EC2 と中身は同じである。完全で最新な情報は、 以下のAmazon RDS for Oracle のホームページを参照されたい http://aws.amazon.com/rds/oracle/

データベースインスタンスを開始するために、ユースケースに最も適していると思われるインスタンス(コア数やメモリサイズの観点で)を選択し、それをとっかかりにしよう。その後そのインスタンスタイプが最適か、もっと大きいあるいは小さいインスタンスタイプのほうが適しているかどうか決断するためにパフォーマンスを計測しよう。Oracle database のパフォーマンスを監視する方法の詳細については、"Monitoring and Management"の章に譲る。

インスタンスのサイズを変更したい場合は、AWS Management Console や CLI、API を使って変更可能だ。変更可能なパラメータの一つがインスタンスタイプだ。これにはデータベースインスタンスの再起動が伴うが、即時実行するか、インスタンス作成時に選択(あるいは変更時に選択)した次回のメンテナンスウィンドウの間か選択することができる。


Amazon EC2 のインスタンスサイズを決める
Amazon EC2 のインスタンスは(Standard(第1、第2世代)、Micro、ハイメモリ、ハイCPU、クラスターコンピュート、クラスターGPU、ハイI/O、ハイストレージ)という、8つのインスタンスファミリーに分類されている。完全で最新な情報は、 以下の Amazon EC2 インスタンスタイプのページを参照されたい http://aws.amazon.com/ec2/instance-types/

高パフォーマンスのデータベースを稼働する際に、ハイメモリインスタンスはデータベースのSGAに割当てるメモリを最大化できる点でよい選択肢である。クラスターコンピュートインスタンスであればとても高速なCPU能力とハイメモリを割当てられる。また、ハイI/OインスタンスであればローカルのSSDドライブをどのインスタンスタイプより高速なI/Oを実現できる点も考慮したい。ハイメモリクラスターインスタンス大容量のメモリをローカルSDストレージを利用できる点で大きめのデータベースインスタンスを稼働させるためのよい選択肢である。インスタンスサイズによるI/O性能の違いについての詳細については、"Disk I/O Management” の章に譲る。

AWS において、インスタンス見積りが過小あるいは過大であると気づいた場合でも、垂直スケール(インスタンスタイプとサイズの変更)させることは非常に容易である。インスタンスサイズの変更方法は、選択したAMIのタイプに依存する。

  • EBS-backed インスタンスはルートデバイスが Amazon Elastic Block Store (Amazon EBS) にストアされている。この場合、インスタンスを停止して、AWS Management Console や CLI、API を使用してインスタンスタイプを変更後、インスタンスを再起動すればよい。
  • Instance-store インスタンスはルートデバイスがインスタンス内部のストレージにストアされている。この場合、ルートデバイスに変更(たとえばAMIのリバンドル)を施し、インスタンスをターミネートし、新しいインスタンスを開始すればよい。
  • どちらのシナリオでも、インスタンスサイズの変更は数分以内に完了する。

注意:そのインスタンスが EBS-backed か instance-store か判別したい場合、AWS Management Console 上のEC2ダッシュボードを見るか、CLI のコマンド ec2-describe- images -v の出力結果の rootDeviceType 項目を見るとよい。

Amazon RDS でのディスクI/O管理

Amazon RDS は データベースやログのストレージに Amazon EBS を利用している。要求されたストレージサイズに基づいて、Amazon RDS は自動的に EBS ボリュームをストライピングしてIOPSの性能を増強する。EBS に関する高度な説明については "EBS Volumes" の章に譲る。


Amazon RDS のストレージサイズを拡張する
Amazon RDS は AWS Management Console や CLI(rds-modify- db-instance コマンド)や ModifyDBInstance API を使用することで簡単にスケールアップできる。Amazon RDS はDBインスタンスの再起動やアクティブなプロセスへの割り込みを行わずにストレージを追加できる点に注意すること。Amazon RDS のストレージサイズを増やす主要な理由はデータベースの成長によるが、これに合わせて I/O の向上もされる。既存のDBインスタンスについて、ストレージを拡張すると、I/O性能が向上することにも気づくだろう。


Amazon RDS のインスタンスサイズを拡張する
Amazon RDS のインスタンスサイズを拡張して大きめのインスタンスにすると、以下のような点でパフォーマンスが向上する。

  • メモリ容量の向上(キャッシュされるデータ量の向上)
  • ネットワーク帯域の向上(EBSのパフォーマンス向上による)


Amazon RDS Provisioned IOPS
Amazon RDS Provisioned IOPS (秒間のI/O処理数) は、データベース作成時にIOPS値を指定することでデータベースのストレージ性能を自分で制御することができるオプションである。この機能は素早く、予測可能で一貫したI/O性能を提供するように設計されている。新しいOracleデータベースインスタンスを作成するときに、AWS Management Console や Amazon RDS のAPIを利用し、関連するストレージのサイズを100GBから3TBまで指定することで、1,000 IOPS から 30,000 IOPS を指定可能である。小さい値から開始して 1,000 IOPS単位で増加が可能である。Amazon RDS の Provisioned IOPS を利用するうえでの注意点は以下である。

  • ストレージの量と Provisioned IOPS で指定可能な値の比率は 3 から 10 である。たとえば 100GB のデータベースであれば、Provisioned IOPS は300〜1,000 が指定可能である。
  • Oracle RDS のページサイズは 8KB である。1,000 Mbps で I/O チャネルが完全に二重化された m2.4xl インスタンスのようなDBインスタンスであれば、8KB I/O における最大IOPSは 25,000 IOPSになる。16KB I/O のワークロードの read 50%、write 50%が、あるいは 8KB I/O 全てが 25,000 IOPSに到達する。
  • Provisioned IOPSストレージを使うなら、Provisioned IOPSのためのインスタンス最適化オプション(現在使えるのは m1.large、m1.xlarge、m2.2xlarge、m2.4xlargeのインスタンスクラスのみ)を合わせて推奨する。これは Provisioned IOPS のために利用可能なネットワーク帯域を、m1.large インスタンスの500Mbpsから、m1.xlarge、m2.2xlarge、m2.4xlarge インスタンスで利用可能な1000Mbps まで割当てるものである。IOPS集約型の類似のワークロードを処理するために、1000Mbpsのストレージネットワーク帯域が、他のインスタンスより高速に実際のIOPSを処理する。
  • Amazon RDS のデータベースが利用している標準ストレージを Provisioned IOPS ストレージに変換することもできる。実際のI/Oスループット量はワークロードにより異なる。Oracleの場合、最大IOPSは8KBページサイズのとき25,000である。

Amazon EC2 でのディスクI/O管理

この章では、Oracleデータベースのために選択可能な Amazon EC2 のディスクストレージのオプションについて確認する。


インスタンスストレージ
Amazon EC2 インスタンスには特定のサイズのエフェメラルなローカルストレージが搭載されている。顧客によりインスタンスがターミネートされたり、予期せぬハード障害でインスタンスが別のサーバーで再起動した場合など、ここに保存したデータにはアクセスできなくなる。この特徴から、データベースの永続ストレージに使うには挑戦的なオプションとなっている。しかし以下のようなメリットもある。

  • エフェメラルディスクはシーケンシャルアクセスに対して性能がよく、ネットワークの接続性にも影響を受けない。一部の顧客はネットワークの帯域を節約するために一時ファイルをストアする目的でエフェメラルディスクを利用することが有用だと判断している。
  • (後述する)ハイI/Oインスタンスは、圧倒的なI/Oパフォーマンスを活かし、データベースのワークロードに推奨されるが、揮発的な特徴を回避するバックアップやレプリケーション戦略は考慮されたい。
  • ハイストレージインスタンスには 48TB の内部ストレージが提供され、とても大きいデータベースをインスタンスストレージ上で稼働できる。ハイI/Oインスタンスのように、ローカルストレージを失うリスクを軽減するバックアップやレプリケーション戦略は必要である。


EBSボリューム
AWS はAmazon EBS という永続的なブロックレベルのストレージボリュームも提供している。Amazon EBSボリュームはインスタンスのライフサイクルとは切り離すことのできる off-instance なストレージである。Amazon EBSボリュームのデータは単一コンポーネントで発生しうる障害によるデータロスとを避けるために、単一AZ内の複数サーバーでミラーされている。スナップショットを用いて容易に Amazon S3 にバックアップできる。これらの属性は EBS にデータファイルやログファイルやフラッシュリカバリエリアを設定するのに適している。EBSの最大サイズは1TBであるが、複数ボリュームをストライピングすることでより大きいサイズのデータベースを配置することも可能だ。EBSボリュームには下記に章で記載するように、標準ボリュームとProvisioned IOPSボリュームの2種類ある。


標準 EBS ボリューム
標準 EBS ボリュームは平均 約100 IOPS と、ベストエフォートで数百 IOPS までバーストする性能を提供する。標準EBSボリュームは起動ボリュームのように通常適度でバーストも必要なI/O要件を満たすのに最適である。標準EBSボリュームは(ランダムリード/ライトより)シーケンシャルリード/ライトに適している。


Provisioned IOPS ボリューム
Provisioned IOPS ボリュームは予測可能で一貫した高いパフォーマンスを実現するように設計されており、データベースのようなI/Oの集中するワークロードを処理するのに適している。Provisioned IOPS ボリュームを利用すれば、作成するボリュームのライフサイクルにわたり、IOPSを指定することが可能になる。以下がProvisioned IOPS ボリュームの重要な特徴である。

  • Amazon EBS は現在 Provisioned IOPS ボリュームあたり 4,000 IOPSをサポートしている。
  • 10個のボリュームをストライピングすることで 40,000 IOPS までデータベースの性能を引き上げることができる。
  • Provisioned IOPS のI/O操作は 16KB 以下のサイズで保証される。16KB以上だと、IOPS は I/O サイズに比例して減少する。たとえば 4,000 IOPS ボリュームを用意し、平均I/Oサイズが 32KB だと 2,000 IOPS しか期待できない。I/Oサイズが 64KB の場合は、1,000 IOPS しか期待できない。
  • ボリュームサイズ(GBあたり)と Provisioned IOPS の比率の最大は 10 である。たとえば 50GB のボリュームの場合、Provisioned IOPS の最大は 500 である。
  • より一貫したパフォーマンスが必要だったり、データベースが一貫して高いI/Oワークロードを生成する場合、Provisioned IOPS は、標準EBSボリュームはよりもコスト的に有効である。(標準EBSボリュームが実際使用されたI/Oに課金されるのに対し)Provisioned IOPS は Provisioned IOPS に設定されたIOPS数に課金される。これには、I/Oコストがより予測しやすいという利点がある。


EBS-Optimized インスタンス
EBS-Optimized インスタンスは EBS ボリュームに対する Provisioned IOPS を十分に活用する方法だ。EBS-Optimized インスタンスは、インスタンスにより 500Mbps あるいは 1,000Mbps をオプションとして指定可能にし、Amazon EC2 と Amazon EBS 間の専用の帯域を保証する。EBS-Optimized インスタンスにアタッチすると、Provisioned IOPS ボリュームは 99.9% の確率で、指定のパフォーマンスのブレ 10% 以内の性能を提供するように設計されている。EBS-Optimized インスタンスと Provisioned IOPS ボリュームの組合せは、インスタンスが一貫した高いI/Oパフォーマンスを発揮する完全な方法である。高いI/O要件のある多くのデータベースがこの機能によりメリットを享受する。インスタンスと EBS の間で予測可能な帯域が必要な場合には EBS-optimized インスタンスと標準 EBS ボリュームを利用するということもできる。 EBS-Optimized インスタンスは現在いくつか大きめのインスタンスタイプでしかサポートされていない点には注意が必要である。詳細な情報は以下を参照されたい。http://aws.amazon.com/ec2/instance-types/


正しいインスタンスタイプを選択する

パフォーマンスがディスクI/Oにより制限されている場合、ディスクリソースの設定変更に順番はない。EBSボリュームはネットワークを介して接続されているので、インスタンスに利用可能なネットワークスループットがディスクパフォーマンスに影響を及ぼす可能性がある。経験則で言えば、大きなインスタンスはより大きなネットワークスループットを提供する。標準あるいは Provisioned IOPS ボリュームの利点を最大限引き出すには、クラスタコンピュート,、ハイメモリクラスターやハイI/Oインスタンスといった 10Gbps ネットワーク上で実行されているインスタンスか、前の章で記述した EBS-Optimized インスタンスを選択することが有効だ。ネットワークスループットがネットワーク上にアタッチされたストレージのパフォーマンスに重大な影響を与えることを考え、適切なインスタンスタイプを選択されたい。


いくつかの EBS ボリュームに I/O アクティビティを分散する

ランダムI/Oのパフォーマンスを向上するために、たとえば800GBのボリューム1本より、100GBのボリュームを8本使うといったように、データを配置するボリューム数を増やすことも有効である。複数のEBSボリュームの統合は、論理ボリュームの全体的なIOPSを向上させる。LinuxのソフトウェアRAIDや、論理ボリューム管理(LVM)あるいは Oracle Automatic Storage Management(ASM)のような様々な技術がEBSボリュームの統合に利用可能である。

単一の標準EBSボリュームの平均IOPSは 100 であり、10本以上のEBSディスクをアタッチした単一インスタンスのは平均IOPSは 1000 である。Provisioned IOPS はハイI/Oなデータベースにとって、より予測可能な IOPS を確保する方法である。EBS-optimizedインスタンス上で10本の Provisioned IOPS ボリュームをストライピングして数千IOPSまで向上させたものを2本以上束ね、データベースのストレージを 20,000 IOPS にまで向上することも可能である。

しかしながら、ストライピング技術は一般的に、ストライプセット内のEBSボリューム数に反比例して、論理ボリュームのオペレーション耐久性を低下させてしまう点に注意が必要である。EBSボリューム上のデータはそもそもレプリケートされて冗長化されているため、RAID0構成にすれば、冗長性や可用性は十分かもしれない。ディスクの統合の可用性として、RAID 0 の代わりに RAID 10(ストライピングとミラーリング)も使えるが、多くの場合、RAID 0 に比べて、RAID 10 のほうがパフォーマンスが劣ってしまうだろう。RAID 0 を選ぶべきか RAID 10 を選ぶべきかは、可用性の要件と、統合可能なボリューム数に依存する。いずれにしても、EBS ボリュームのスナップショットは、できるかぎり頻繁に取得しておくべきだろう。

独立したEBSボリュームや統合されたボリュームは違ったI/O特性を示すため、データ、ログ、一時ファイルを格納することにはメリットがある。追加のEBSボリュームを活用するために、インスタンスサイズで必要とされるネットワーク帯域が十分であるかどうか確認のために、ネットワーク負荷を評価されたい。


Amazon EBS 上の Oracle ASM

Oracle Automatic Storage Management(ASM)は Oracle データベース用に特別に設計された、統合的でハイパフォーマンスなファイルシステムおよびディスク管理機構である。他のファイルシステムに比べ、ASM は以下のような
Oracle データベース向けに特化したいくつかの特長を持っている:

  • データのチャンクは、潜在的なパフォーマンスの「ホットスポット」が発生しないように、ディスクグループ内の複数の論理ディスクに分散される。
  • ASM はそれ自身の I/O は発生せず、(ファイルシステムのように)キャッシュにデータベースで使わないデータを先読みして置いておくことがない。
  • 断片サイズやファイルシステムのジャーナルの設定といった、徹底したチューニングを行う必要がない。
  • Oracle の REDO ログはすでにこの機能に対応しているので、一貫性を保つためのジャーナルは必要ない。
  • ストレージの追加や削除は簡単である。ストレージを追加すると、ストレージが均等に利用されるように、ASMが自動的にリバランスを行う。これにより、オンデマンドで新しいEBSボリュームを追加できるAWSのような環境では特にパフォーマンスが向上される。

Oracle ASM のディスクグループは、標準冗長性、高冗長性、外部冗長性という3種類の冗長性を提供する。標準冗長性、高冗長性の場合、ファイルはディスクグループ内で冗長化される。外部冗長性では、ASMはディスクグループに対する冗長性を提供しない。ASM のボリュームのグループの設定をするときには、EBS ボリュームがすでにAZ内でデータを冗長化している点から、外部冗長性を選択することを推奨する。データファイルとログファイル、ワーク領域とリカバリ領域で別々のディスクグループを使うという Oracle ASM のベストプラクティスは、そのまま Amazon EBS にも適用可能である。


ハイI/Oインスタンスとクラスターハイメモリーインスタンス

ハイI/Oなワークロードのためであれば Provisioned IOPS ボリュームの代わりに、内部ストレージとしてSSDドライブを備えたハイI/Oインスタンスを使って、特に要件の厳しいデータベースのワークロードを実行できる。ハイI/O Quadruple Extra Large(4xlarge)インスタンスは、120,000 Random Read、85,000 Random Write を提供する。ハイメモリークラスター Eight Extra Large(8xlarge)インスタンスは、240GB のローカルSSDストレージに加え、244GB のメモリを提供する。ただしこのSSDストレージは、インスタンスを停止したり、基盤のハードウェアが故障したりすると消えてしまう点に注意が必要だ。このタイプのストレージをデータベースに使うときには、データ喪失を避けるため、たとえば頻繁に Amazon S3 にバックアップを行うなどの戦略を決めておく必要がある。また、ストレージの性能に加えて、ハイI/Oインスタンスとクラスターハイメモリーインスタンスは、EBS の性能を向上させるのにも役立つ 10Gbps のとても高速なネットワークを持っている。


Oracle Advanced Compression で I/O を削減する

11g バージョンから Oracle は Advanced Compression というオプションを提供している。構造化データ(数値、文字)と同様に、非構造化データ(ドキュメント、スプレッドシート、XMLと他のファイル)も圧縮できる。advanced compression を使うと、結果的に 2倍〜4倍 のディスク容量が節約される。ディスクに書込む量が減り、フルスキャンやレンジスキャンも、行が圧縮されることでディスクI/Oが少なくなるため早くなる。ブロックがメモリ上に圧縮されたままになるのでメモリ的にも効率的である。しかしこれらはトレードオフの関係にある。Advanced Compression はI/Oやストレージの使用量を削減するが、ワークロードの中には、圧縮・解凍処理部分がパフォーマンスのオーバーヘッドになりうる。


ベンチマークの取得

前に書いたとおり、Amazon EC2 には I/O サブシステムを最適化してチューニングできるたくさんのオプションが用意されている。最も適切な設定を選択するために、複数のインスタンスタイプとストレージの設定を用いて、実際に稼働させるアプリケーションのベンチマークを取得することをオススメしたい。たとえば Oracle のベンチマークツールである Orion (Oracle I/O Numbers) という Oracle データベースの I/O 動作を再現する I/O キャリブレーションツールを使い、ストレージシステムの I/O 性能を計測することができる。

キャッシュ

Oracle を Amazon EC2 や RDS どちらを利用しているかに関わらず、重たいワークロードの処理がWebサーバーやAPサーバーから繰り返しデータベースにアクセスすることに直面した場合、Oracle利用者はデータをキャッシュすることでこの読み込みを削減することになる。キャッシュを配置する場所に応じて使えるいくつかのツール(Oracleのツールも含む)を紹介する。

  • Memcached : オープンソースで、高性能な、分散メモリオブジェクトキャッシュシステム。データベース呼び出しの結果のような、小さいチャンクの任意の型のデータ(文字列だったりオブジェクトだったり)のための、インメモリのキーバリューストア。Memcachedは、すでに広く普及しており、主にデータベースの負荷を軽減することで、動的なWebアプリケーションを高速化するために使用される。
  • Amazon ElastiCache : デプロイ、運用、スケールが容易なクラウド上のウェブサービスである。ディスクベースのデータベースのような遅延に依存しない、管理されたインメモリキャッシュシステムから素早く情報を取得することで、ウェブアプリケーションの性能を向上させるサービスである。ElastiCache は Memcached とプロトコルに準拠しており、現在 Memcached 環境で動作しているコードやアプリケーション、標準的なツールであれば、本サービスでもシームレスに動作する。ElastiCacheは、自身のアプリケーションを差別化する部分に注力できるよう、Memcached 環境の管理、監視、運用を簡素化し、負荷をオフロードする。
  • Oracle In-Memory Database Cache : Oracle TimesTen In-Memory Database に搭載されている、アプリケーション層にインメモリキャッシュデータベースとしてデプロイされるキャッシュ機能。アプリケーションは、基礎となる Oracle データベースと自動的な永続性、トランザクションの一貫性、データ同期ができ、SQLやPL/SQLを使用して、キャッシュテーブルに対して Read/Write 操作を実行する。キャッシュへの書込みは、同期的あるいは非同期的にデータベースにレプリケートされる。
  • Oracle Coherence : 高度にスケーラブルでフォールトトレラントな分散キャッシュエンジンである。信頼性やスケーラビリティ、性能向上のために設計されたインメモリデータグリッドである。データをキャッシュする Coherence クラスターをプロビジョンしして構成し、サーバが動作不能になったり、ネットワークから切断されたときに、自動的かつ透過的に、データ管理サービスをフェイルオーバーして再開する。

データベースレプリカ

より高い性能を引き出すための手法は、複数のインスタンス間でデータベースクエリの負荷を分散することである。この手法は、多くの場合、スケールアウトまたは水平スケールと呼ばれる。


Amazon RDS でリードレプリカを作成する

Amazon RDS では現在、Oracle 用のリードレプリカ機能を提供していない。データベースのスループットを向上させるためには、垂直スケール(大きいインスタンスタイプを使う)しかない。別の方法として、データベースを「シャーディング」する方法(複数のRDSインスタンスに対する水平パーティショニング)がある。データは実世界の条件(たとえば製品の種類や、顧客の位置情報)に基づいて共有するか、ハッシュのアルゴリズムを用いて複数のインスタンスに分散することができる。


Amazon EC2 でリードレプリカを作成する

Oracle Active Data Guardは、プライマリのデータベースからトランザクションログのアーカイブを適用している間でも、読取専用でオープンできるスタンバイデータベースを設定することができる Oracle Database のアドオン機能である。スタンバイデータベースはプライマリデータベースのリードレプリカとして利用することができる。プライマリーデータベースとスタンバイデータベースは同期制御ができる。これによりプライマリーデータベースへの読取専用のクエリをリードレプリカにオフロードして、データベース全体を水平スケールさせることができる。多くのアプリケーションが、データベースに対して書込みよりも読取クエリを多く生成するため、この設定方法は効果的なことが多い。また、BIアプリケーションのように読み込み量の多いクライアントはスタンバイインスタンスで実行することで、プライマリの商用環境のデータベースへの影響をなくすこともできる。

Oracle Active Data Guard を使って、柔軟なデータベースインフラを構築できる。Amazon CloudWatch でプライマリデータベースを監視することで、重たい読み込み処理がしきい値に達したり超過したことを、通知させることができる。この場合、プライマリ側への読み込みを軽減させるための新しいスタンバイデータベースをオンデマンドに作成することができる。いったんその重たい処理の時間が終われば、スタンバイインスタンスと、そこで消費するリソースが配置される。

注意:Oracle Active Data Guard は Oracle Database Enterprise Edition でしか利用できない、Standard Edition や Standard Edition One では使用不可能である。

性能を高めるためにアクティブ/アクティブなレプリケーション構成も可能である。このシナリオにおいては、書込みも読込みも可能な、一つかそれ以上のデータベースを用いて、全てのレプリカが同期している分散データベースの実装を行う。この技術については "高可用性" の範囲でも説明する。

図2(ホワイトペーパー参照)は Oracle Active Data Guard でいくつかのリードレプリカを用いてスケーラブルな読込み用のファームを構築した図である。