Amazon RDSのリードレプリカ
非同期レプリケーションによる読み取りスケール、レプリカの昇格、クロスリージョン構成、エンジンごとの制約を解説します。
Amazon RDSのリードレプリカ
データベースへのアクセスが増えたとき、読み取りと書き込みを1台のDBインスタンスに集めると、参照処理が更新処理と計算資源やI/Oを取り合います。Amazon RDSのリードレプリカは、プライマリDBインスタンスのデータを別のDBインスタンスへ複製し、読み取り処理の接続先を増やす機能です。
リードレプリカは、プライマリから通常非同期でデータを受け取る、参照処理向けのインスタンスです。標準的な使い方では読み取り専用として扱い、プライマリが書き込みを受け持ちます。アプリケーションが参照系の処理をレプリカへ送ることで、読み取り負荷を分散できます。レポート生成や商品一覧の参照など、更新と分離できる読み取り処理が代表的な対象です。RDS for MySQLとRDS for MariaDBではレプリカを書き込み可能にする設定もありますが、これは標準の読み取り分散動作とは異なるため、エンジン固有の仕様を確認します。MySQLとMariaDBでは、それぞれ1つのソースから同一リージョン内に最大15台のレプリカを作成できます。
読み取りを分散する仕組み
各リードレプリカには、プライマリとは別の接続エンドポイントがあります。アプリケーションは書き込み先としてプライマリのエンドポイントを使い、読み取り可能なレプリカのエンドポイントを参照処理に使います。どのレプリカへ送るかは、アプリケーションの接続設定や読み取りルーティングの仕組みで決めます。RDSの通常のDBインスタンス向けリードレプリカでは、作成しただけでアプリケーションの全クエリが自動的に振り分けられるわけではありません。
たとえば、音楽配信サービスで利用者がプレイリストを更新した場合、その書き込みはプライマリへ送ります。人気プレイリストの一覧表示や集計画面の参照をリードレプリカに振り分ければ、プライマリの参照負荷を抑えられます。更新直後に同じ利用者が最新の内容を必ず確認する処理は、複製遅延を考慮してプライマリへ送るなど、読み取り経路を分ける設計が必要です。
リードレプリカが増やすのは、主に読み取り処理を受け持つ容量です。書き込み要求は引き続きプライマリへ集まるため、リードレプリカを増やしても書き込み性能が同じ割合で伸びるわけではありません。また、レプリカの追加はプライマリからの複製処理やネットワーク転送を伴います。読み取り要求の振り分け、複製遅延、費用を合わせて評価します。
非同期複製とレプリケーションラグ
非同期レプリケーションでは、プライマリでコミットされた変更がレプリカに反映されるまで時間差が生じます。この時間差をレプリケーションラグと呼びます。通常は小さくても、書き込みが集中した場合、ネットワークやレプリカ側の処理が滞った場合などに大きくなる可能性があります。
そのため、プライマリで書いた直後にレプリカを読むと、更新前の値が返ることがあります。常に最新の値が必要な読み取りはプライマリへ送る、更新直後の読み取りを一定時間プライマリに固定する、ラグを監視して閾値を超えたレプリカをルーティング対象から外す、といった対策を検討します。レプリカからの読み取りが許容できるかどうかは、画面や処理ごとの整合性要件で決まります。
非同期であることは、プライマリ障害時にレプリカを昇格した場合にも関係します。複製が完了していない更新はレプリカに存在しない可能性があり、直前の書き込みを失う可能性をゼロにはできません。目標復旧時点（RPO）を決める際は、レプリケーションラグ、バックアップ、復旧方式を合わせて考えます。
レプリカの昇格と障害復旧
リードレプリカは、必要に応じて**昇格（プロモート）**し、独立した書き込み可能なDBインスタンスにできます。昇格後のDBは元のプライマリから独立して動作し、元のプライマリとの複製関係がそのまま継続するわけではありません。新たな書き込み先として利用するには、アプリケーションの接続先やDNS、データベース構成を切り替える必要があります。
この性質を利用し、プライマリ障害時の復旧、移行先へのデータコピー、別リージョンを使った災害復旧などにレプリカを活用できます。ただし、レプリカを作成したこと自体は、障害を検知して自動的に昇格し、アプリケーションの接続先を切り替える仕組みを意味しません。復旧を自動化するには、障害判定、昇格の実行、接続先更新、アプリケーション再接続の各段階を設計します。手動運用の場合は、手順と復旧時間をあらかじめ定めます。
読み取り可用性のためのレプリカと、高可用性のためのMulti-AZスタンバイは役割が異なります。通常のMulti-AZ DBインスタンスのスタンバイは読み取り処理の接続先ではなく、障害時のフェイルオーバーを目的とします。一方、リードレプリカは読み取りに利用でき、必要時に昇格できます。Multi-AZの同期レプリケーション、通常のリードレプリカの非同期レプリケーション、そして一部エンジンにある読み取り可能なMulti-AZ DBクラスターは、それぞれ構成と目的を区別してください。
リージョンをまたぐレプリカ
対応するエンジンでは、別のAWSリージョンにリードレプリカを作成できます。異なるリージョンに複製先を持てば、リージョン障害時の復旧候補を用意したり、利用者に近いリージョンで読み取りを処理して応答時間を改善したりできます。別リージョンのレプリカにも固有のエンドポイントがあり、読み取り要求の転送先や障害時の昇格方法をアプリケーション側で扱います。
リージョン間レプリケーションも非同期であり、リージョン間の通信時間や更新量の影響を受けます。プライマリと完全に同時点のデータを常に保持する保証ではありません。リージョン障害時の復旧では、レプリカの最新状態を確認したうえで昇格し、アプリケーションの接続先を切り替えます。データ転送量、レプリカの稼働費用、復旧手順も設計に含めます。
エンジンごとの対応と制約
リードレプリカの作成可否、上限数、リージョン間構成、昇格動作は、RDS全体で一律ではなく、データベースエンジン、エディション、バージョン、リージョンによって異なります。したがって、すべてのRDSエンジンを「最大5台」といった単一の台数で扱わず、対象構成の現行クォータとユーザーガイドを確認してください。Auroraのレプリカ数や読み取りエンドポイントの仕様も、通常のRDS DBインスタンスの数え方と混同しないようにします。
RDS for Db2のレプリカはスタンバイモードで動作し、ユーザー接続を受け付けません。そのため読み取り負荷の分散には利用できず、主にクロスリージョンの災害復旧向けです。このように、リードレプリカと呼ばれる複製先であっても、エンジンによって読み取り接続の可否が違います。
Microsoft SQL Server
RDS for SQL Serverのリードレプリカは、Enterprise Editionのみで利用でき、DBインスタンスクラスは4 vCPU以上である必要があります。1つのソースから最大15台を作成できますが、5台を超えると複製遅延が発生する場合があるため、台数だけでなくソースとレプリカの計算資源、ストレージ、ネットワーク負荷を確認します。対応バージョン、クラス、リージョンも作成前に確認してください。
RDS for SQL Serverは、現在クロスリージョンのリードレプリカにも対応しています。したがって、SQL Serverのリードレプリカは別リージョンに作成できない、と一律に判断するのは正しくありません。クロスリージョンの対応バージョンやリージョン、暗号化時の宛先リージョンKMSキーなどの条件をAWS公式の対応表で確認します。
Oracle
RDS for Oracleのレプリカは、Enterprise Editionでのみ利用できます。読み取り専用モードはデフォルトで、プライマリから変更を受け取りながら SELECT クエリを実行できます。このモードにはActive Data Guardライセンスが必要です。1つのソースDBインスタンスから最大5台を作成できます。
Oracleレプリカをマウントモードで運用すると、レプリカはログを適用しながら待機できますが、ユーザー接続を受け付けず、クエリを実行できません。マウントモードにはActive Data Guardライセンスは不要ですが、読み取り負荷を分散する用途には使えず、主にクロスリージョンの災害復旧向けです。AWSではマウントモードと読み取り専用モードを同じソースに組み合わせたり、レプリカのモードを切り替えたりできます。Oracleレプリカの昇格時はData Guardのスイッチオーバーを利用する構成も確認し、一般的なエンジンと同じ操作手順だと決めつけないようにします。
リードレプリカとMulti-AZの比較
| 観点 | リードレプリカ | 通常のMulti-AZ DBインスタンス |
|---|---|---|
| 主な目的 | 読み取り負荷の分散、読み取り容量の拡張、昇格を使った復旧 | 同一リージョン内の可用性向上と自動フェイルオーバー |
| 複製 | 一般に非同期 | 同期レプリケーションを使う構成 |
| 読み取り接続 | レプリカ固有のエンドポイントへ読み取りを送れる | スタンバイは通常の読み取り接続先として使えない |
| 書き込み | 通常はプライマリが受け付ける。昇格後は独立した書き込み先になる | 通常時はプライマリが書き込みを受け付け、障害時にスタンバイへ切り替わる |
| 自動切り替え | レプリカを作成しただけでは自動昇格・切り替えされない | マネージドなフェイルオーバーを提供する |
この比較は、通常のRDS DBインスタンスのリードレプリカとMulti-AZ DBインスタンスについての整理です。読み取り可能なスタンバイを持つMulti-AZ DBクラスターなど、別の配置モードは個別の仕様を確認してください。
試験での見分け方
- プライマリの参照負荷を減らしたい: リードレプリカを作り、アプリケーションから参照要求をレプリカ固有のエンドポイントへ送る。
- 読み取り専用データを別インスタンスへ分散したい: 非同期複製によるラグを許容できるか確認し、最新性が必須の読み取りはプライマリへ送る。
- プライマリ障害から復旧したい: レプリカを昇格する方法がある。作成だけで自動フェイルオーバーするわけではなく、昇格と接続先変更が必要。
- リージョン障害に備えたい: エンジンが対応するクロスリージョンレプリカを候補にする。遅延、昇格、アプリケーション切り替え、エンジン制約も含めて設計する。
- 読み取り可能なスタンバイが必要: 通常のMulti-AZ DBインスタンスのスタンバイを読み取り先にしない。リードレプリカ、または読み取り可能スタンバイを持つ対応クラスターを検討する。
- 書き込み負荷を分散したい: リードレプリカは読み取り用であり、プライマリへの書き込み集中を解消しない。
- Oracleのマウントモードを使っている: マウントされたレプリカはクエリ実行に利用できず、Active Data Guardライセンスは不要で、主にDR用途として扱う。
- SQL Serverは別リージョンにレプリカを作成できないとする選択肢: 現在はSQL Serverのクロスリージョンリードレプリカもサポートされている。対応するバージョンやリージョンなどの条件を確認する。
- 全エンジン共通の台数上限を選択肢に示された: 上限はエンジンや構成で異なる。たとえばMySQL/MariaDBとSQL Serverは同一リージョンで最大15台、Oracleは最大5台だが、作成前に対象エンジンの現行条件を確認する。
AWS公式ドキュメント
重要ポイント
- ▸リードレプリカはプライマリから主に非同期で複製される読み取り専用DBインスタンスで、読み取り負荷を分散する
- ▸レプリカごとに接続エンドポイントがあり、アプリケーションが参照系の接続先を選ぶ。書き込みはプライマリに送る
- ▸非同期レプリケーションには遅延があり、更新直後にレプリカを読むと古い値を得る可能性がある
- ▸レプリカは昇格して独立した書き込み可能DBにできるが、一般に作成しただけで自動フェイルオーバーするわけではない
- ▸クロスリージョンレプリカはリージョン障害への備えや近接読み取りに利用できる。台数、昇格、読み取り可否はエンジンごとに異なる
- ▸SQL ServerとOracleにはエディションやライセンスの制約がある。Oracleのマウントされたレプリカは読み取りに使えず、SQL Serverも現在はクロスリージョン複製に対応する
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
AWSデータベースサービス に関連するトピックを続けて確認できます。