読み取りスケーリングのためのリードレプリカ

Read Replicasは、非同期レプリケーションによって更新を受け取る RDS プライマリインスタンスのコピーです。Multi-AZ のスタンバイとは異なり、Read Replicas は SELECT クエリでアクセスできるため、読み取りトラフィックを分散し、プライマリデータベースの負荷を軽減できます。

Read Replicas は、MySQL、PostgreSQL、MariaDB、Oracle（Active Data Guard 使用時）、およびすべての Aurora エディションでサポートされています。Aurora MySQL と Aurora PostgreSQL では最大15 個の Read Replicas、標準の RDS MySQL と PostgreSQL では最大 5 個まで作成できます。

Read Replica を作成するには、ソースインスタンスで自動バックアップを有効化しておく必要があります（保持期間が 0 より大きいこと）。AWS はプライマリのスナップショットを取得して新しい DB インスタンスに復元し、プライマリからの非同期レプリケーションを確立します。

各 Read Replica には固有の DNS エンドポイントが割り当てられます。アプリケーションを更新し、読み取りをレプリカのエンドポイントへ送る必要があります。接続プールや、読み書き分離に対応したアプリケーションフレームワークを使用すれば、SELECT クエリをレプリカへ自動的にルーティングできます。

レプリケーションは非同期で行われるため、書き込み量によっては Read Replicas がプライマリに数ミリ秒から数秒遅れることがあります。これをレプリケーションラグと呼びます。ReplicaLag CloudWatch メトリクスで監視できます。

レプリカから読み取る場合に結果整合性を許容できるよう、アプリケーションを設計する必要があります。たとえば、レコードを挿入した直後にレプリカから読み取ると、新しい行がまだ返されない場合があります。書き込み後の読み取り整合性が必要な場合は、その読み取りをプライマリへルーティングしてください。

RDS では、別の AWS リージョンに Read Replicas を作成できます。これにより、グローバルな読み取りスケーラビリティとディザスタリカバリを実現できます。リージョン間レプリケーションではパブリックインターネットまたは AWS Global Accelerator を使用するため、ネットワークレイテンシーにより、リージョン内よりもレプリケーションラグが大きくなります。

リージョン間レプリカは、別の地域のユーザーに近い場所で読み取りを処理したい場合、別のリージョンにプロモート可能なウォーム DR コピーを用意したい場合、または本番環境から分析クエリの負荷を切り離したい場合に役立ちます。

Read Replica をプロモートするとレプリケーションリンクが切断され、独立した書き込み可能なプライマリ DB インスタンスになります。これは、元のプライマリが利用できない場合のディザスタリカバリや、レプリカを別のエンジンバージョンへアップグレードして新しいプライマリとして使用する場合に行います。

プロモーションは元に戻せません。プロモート後、そのインスタンスをレプリカとして使用することはできなくなります。プロモートする前に、データ損失を最小限に抑えるため、レプリカが可能な限り最新の状態（ラグが最小の状態）であることを確認してください。プロモート後は、アプリケーションの接続文字列を新しいプライマリエンドポイントへ更新します。

SAA-C03 試験では、Read Replicas と Multi-AZ の違いを見分けることが重要です。

• シナリオが読み取りパフォーマンスの向上または読み取りのスケーリングを求めている → Read Replicas
• シナリオが自動フェイルオーバーまたは高可用性を求めている → Multi-AZ
• シナリオが両方を求めている → プライマリに Multi-AZ を使用し、Read Replicas を追加

また、Multi-AZ のスタンバイは読み取りを処理せず、Read Replicas は自動フェイルオーバーを提供しないことも覚えておいてください（Aurora 以外のレプリカでは手動でプロモートする必要があります）。

Aurora では、標準の RDS とは Read Replicas の処理方法が異なります。Aurora は共有分散ストレージレイヤーを使用するため、レプリカはプライマリと同じ基盤データページにアクセスします。そのため、Aurora のレプリカはレプリケーションラグが最小限（通常 100 ms 未満）で、それぞれが読み取りトラフィックを処理できます。

Aurora は、利用可能なすべてのレプリカインスタンス間で接続をロードバランシングするReader Endpointを提供します。アプリケーションが Reader Endpoint に接続すると、Aurora が読み取りを自動的に分散します。レプリカに障害が発生した場合は、エンドポイントに影響を与えずにリーダープールから除外されます。

Aurora では、プライマリ（ライター）インスタンスに障害が発生すると、Aurora が約 30 秒でRead Replicas の 1 つを自動的にプライマリへプロモートします。これは、標準 RDS の Multi-AZ フェイルオーバーよりも大幅に高速です。プロモートされたレプリカは、直ちに Cluster Writer Endpoint 経由で書き込みを受け付け始めます。

Aurora はフェイルオーバー優先度ティア（0～15）をサポートしており、どのレプリカを最初にプロモートするかを制御できます。大きなインスタンスクラスまたは優先する AZ に配置されたレプリカには、より高い優先度（ティア 0）を割り当ててください。

一般的な読み取りスケーリングのアーキテクチャでは、Application Load Balancer またはアプリケーションロジックを介してトラフィックをルーティングします。

• すべての書き込み操作（INSERT、UPDATE、DELETE）→ プライマリ DB エンドポイント
• すべての読み取り操作（SELECT）→ Read Replica のエンドポイントまたは Aurora Reader Endpoint
• セッションキャッシュと結果キャッシュ → ElastiCache（レプリカへの読み取りをさらに削減）

非常に負荷の高い分析クエリについては、レプリカをプロモートするか、Aurora の並列クエリ機能を使用してストレージレイヤーで計算を実行し、本番クラスターへの影響を避けることを検討してください。

Read Replicas で重要な CloudWatch メトリクスは次のとおりです。

• ReplicaLag — プライマリからの遅延秒数。予期せず増加した場合はアラートを設定します
• ReadIOPS — レプリカのストレージがクエリ負荷に対応できているかを確認します
• DatabaseConnections — レプリカが接続数の上限に達していないかを確認します
• CPUUtilization — レプリカの CPU 使用率が高い場合は、クエリの最適化が必要であることを示します

RDS Performance Insights は Read Replicas でも利用でき、DB 時間を最も多く消費している SQL ステートメントを表示します。これにより、コストの高い読み取りクエリを特定して最適化できます。

SAA-C03 試験における RDS Read Replicas の一般的なユースケースは次のとおりです。

• レポート作成と分析：負荷の高い SELECT クエリをレプリカで実行し、本番環境の書き込みを遅延させない
• 地理的分散：リージョン間レプリカによって、他の大陸のユーザーに低レイテンシーでサービスを提供する
• ディザスタリカバリ：プライマリリージョンに障害が発生した場合に、リージョン間レプリカをプロモートする
• 開発とテスト：レプリカをプロモートし、本番データの最新コピーを使ったテスト環境を作成する

Read Replicas はバックアップの代替ではありません。自動バックアップと手動スナップショットは、必ず別途維持してください。

このレッスンで学んだ AWS Solutions Architect（SAA-C03）の概念を確認しましょう。

このレッスンでは、Read Replicas は非同期レプリケーションを使用して読み取りトラフィックを分散すること、レプリケーションラグによってレプリカがプライマリよりわずかに遅れる場合があること、そしてAurora のレプリカはラグが最小限で自動プロモーションをサポートすることを学びました。リージョン間レプリカは、グローバルな読み取りスケーラビリティと DR の選択肢の両方を提供します。次は、暗号化とパラメータグループを使用した RDS のセキュリティについて説明します。