はじめに
マルチ AZ DB インスタンス、マルチ AZ DB クラスター、リードレプリカは、どれも複数のDBインスタンスが登場します。ただし、待機系への自動切り替えが目的なのか、読み取り先を増やすのかで役割は違います。
- 障害時の自動切り替えが必要ならマルチ AZ DB インスタンス
- 読み取り可能な待機系も欲しいならマルチ AZ DB クラスター
- 参照クエリを分散したいならリードレプリカ
対象読者: RDSを学び始めた人、SAA-C03のマルチ AZ とリードレプリカの選択で迷う人
SAAの問題集を解いていて、選択肢に「スタンバイ」「Reader」「リードレプリカ」が並ぶと、どれも同じような複製DBに見えることがあります。見分ける鍵は、複製方式と、複製先を通常時に読み取りへ使えるかです。
参考文献
- Multi-AZ DB instance deployments for Amazon RDS
- Multi-AZ DB cluster deployments for Amazon RDS
- Working with DB instance read replicas
- Monitoring read replication
まず「複数インスタンス」の目的を分ける
DBインスタンスを複数にする理由は、大きく分けて2つあります。
1つは、稼働中のDBに障害が起きたとき、別のインスタンスへ処理を切り替えること。これが高可用性です。もう1つは、読み取りクエリの接続先を増やし、Writerに集中する負荷を分散することです。
「DBを複製する」という言葉だけでは、この2つを区別できません。複製先がフェイルオーバー用の待機系なのか、アプリが通常時から読むReaderなのかを見ます。
図の実線はデータ複製、点線はアプリの読み取り経路です。リードレプリカを読み取り先にするかどうかは、アプリ側の接続先設計で決まります。
マルチ AZ DB インスタンスは待機系に読み取りを流さない
マルチ AZ DB インスタンスは、Writer 1台とStandby 1台の構成です。Standbyは別のアベイラビリティーゾーン（AZ）に配置され、Writerのデータを同期的に複製します。
WriterやAZに障害が起きたときは、RDSがStandbyへ自動で切り替えます。一方で、Standbyは通常時の読み取り先ではありません。普段のアプリ接続はWriterに向けたままです。
同期複製では、複製先への確認が書き込み完了に関係するため、Single-AZ構成より書き込みやコミットの応答が長くなる場合があります。AWSも同期複製により書き込み・コミット遅延が増える場合があると説明しています。ここでいう「応答が遅くなる」は、書き込み時の待ち時間です。Standbyのデータが古くて読み取りに遅れる、という意味ではありません。Standbyはそもそも読み取りに使わないためです。
選ぶ場面は、読み取り性能の拡張よりも、AZ障害やインスタンス障害から自動で復旧することを優先したいときです。
マルチ AZ DB クラスターはReaderもフェイルオーバー先になる
マルチ AZ DB クラスターは、Writer 1台とReader 2台を3つのAZに配置します。Readerは読み取りクエリを処理でき、Writerに障害が起きたときの自動フェイルオーバー先にもなります。
アプリは書き込み用のWriterエンドポイントと、読み取り用のReaderエンドポイントを使い分けられます。読み取りをReaderへ逃がせるため、マルチ AZ DB インスタンスと違い、可用性に加えて読み取り容量も増やせます。AWSは、マルチ AZ DB インスタンス構成と比べて書き込みレイテンシも通常は低いと説明しています。
複製方式は準同期です。AWSの説明では、変更をコミットする前に少なくとも1台のReaderから確認応答を受け取ります。ただし、2台のReader両方で変更が完全に適用されるまで待つ方式ではありません。このためReader間で反映状態に差が出ることがあり、フェイルオーバー時にはレプリカ遅延が関係します。
マルチ AZ DB クラスターの利用可能なエンジンやリージョンは限られます。現行のAWSドキュメントでは、RDS for MySQL と RDS for PostgreSQL を対象とし、細かな対応はエンジンバージョンとリージョンで異なります。採用前に対応状況を確認してください。
リードレプリカは読み取り負荷を分散する
リードレプリカは、既存のDBインスタンスから作る読み取り専用の複製DBです。Writerへの変更を非同期で受け取り、アプリや分析処理からの参照クエリを引き受けます。
非同期複製では、Writerが書き込み完了を返したあとに、変更がレプリカへ反映されます。そのため、書き込んだ直後にリードレプリカを読むと、更新前の値が返ることがあります。WriterとReaderの反映時点の差をレプリカ遅延と呼びます。マルチ AZ DB クラスターでも、準同期の確認は「少なくとも1台のReaderが確認応答した」ことを示すもので、すべてのReaderで適用が完了した保証ではありません。そのため、Reader endpointから直近の更新を読む場合も、反映差が残る可能性があります。
リードレプリカを障害対策に使うこともできますが、Multi-AZのような自動フェイルオーバーとは異なります。障害時にはレプリカを独立したDBへ昇格し、アプリの接続先を切り替える作業が必要です。読み取り負荷の分散と自動フェイルオーバーは、別の要件として考えます。
3構成を比較する
| 構成 | 複製先の役割 | 複製方式 | 通常時に読み取り可能か | 障害時の動き |
|---|---|---|---|---|
| マルチ AZ DB インスタンス | フェイルオーバー用Standby | 同期 | いいえ | RDSが自動切り替え |
| マルチ AZ DB クラスター | Reader兼フェイルオーバー先 | 準同期 | はい | RDSがReaderへ自動切り替え |
| リードレプリカ | 読み取り負荷分散用 | 非同期 | はい | 自動では切り替わらない。必要なら手動昇格 |
「Readerがある」「複製先がある」だけで同じ構成だと判断しないでください。自動フェイルオーバーの要件と読み取り負荷分散の要件を分けて見ます。
混同しやすいのは「遅延」の意味
「遅延」という言葉は、2つの違う現象に使われます。
1つは、書き込み処理そのものが完了するまでの応答時間です。同期複製のマルチ AZ DB インスタンスでは、複製先との同期が関係するため、書き込み応答が長くなる場合があります。
もう1つは、Writerの更新がReaderに適用されるまでの時間差です。これがレプリカ遅延です。非同期のリードレプリカで特に意識が必要ですが、準同期のマルチ AZ DB クラスターでも、Reader全台への適用完了を待つわけではないため起こり得ます。複数インスタンスを用意しただけで、必ずレプリカ遅延が起きるわけではありません。書き込み量、Readerの処理能力、読み取り負荷、ネットワークなどによって変わります。
「更新直後の値を必ず読む」処理では、読み取りをWriterへ送る設計が必要になることがあります。分析やレポートなど、多少古いデータでも問題ない読み取りなら、リードレプリカへ分散する設計が向いています。
RDSのマルチ AZ DB クラスターと、Amazon AuroraのDBクラスターは別の構成です。どちらもWriterとReaderを持つ場合がありますが、複製方式や運用上の仕様は同一ではありません。
まとめ
試験では「同期スタンバイ」「読み取り可能なReader」「非同期の読み取り専用インスタンス」を見分けます。前者はマルチ AZ DB インスタンス、Readerと自動切り替えの両立はマルチ AZ DB クラスター、読み取り負荷の分散はリードレプリカです。
実際に構成を選ぶときは、読み取り直後に最新データが必要か、自動フェイルオーバーが必要か、使うDBエンジンがマルチ AZ DB クラスターに対応しているかを先に確認します。