RDS Multi-AZとRead Replicaのシナリオ判断

この単元で学ぶこと

• 可用性と読取り負荷の条件から構成を選べる
• 複製遅延を許容する処理としない処理を分離できる
• 切替え・誤更新・接続先の試験項目を決められる

本文解説

設計の前提 受注アプリはRDSの主系へ注文を書き込みます。月次分析は数分前の情報でも構いませんが、支払い完了画面では確定済みの最新状態が必要です。また単一AZの障害へ備えます。「DBを増やす」という一つの施策へまとめず、停止への備え、分析負荷、読取りの新しさをそれぞれ表にします。

提案A：従来型待機系へ分析を送る 単一スタンバイ型のMulti-AZ DBインスタンスを採用し、待機系へ月次分析を送る提案は、その待機系が通常読取りを扱わないため成立しません。可用性の仕組みとしては意味がありますが、分析先としてリードレプリカなどを別に評価します。「待機しているから自由に使える」という推測をしないことが重要です。

提案B：全参照を非同期レプリカへ送る 月次分析は少し古い情報でも要件を満たすので、レプリカへ分けられる可能性があります。しかし決済直後の画面まで同じように送ると、複製が追い付く前の状態を表示するおそれがあります。最新性を厳密に求める処理は、書込み結果や必要な一貫性を満たす読取り先を利用するよう分離します。

提案C：レプリカを作るだけで終える 既存アプリが主系へ全SELECTを送り続ければ、レプリカを作っても主系の読取り負荷は分散されません。分析アプリの接続先をレプリカへ変更し、実際にそちらでクエリが実行されることを確認します。接続先の変更には権限・接続数・エラー時の扱いも伴います。

提案D：すべてのMulti-AZを同じものとする 比較候補にMulti-AZ DBクラスターがあるなら、writer 1つとreader 2つを3AZへ配置する構成であることを確認します。readerで読取りできる点は単一スタンバイ型と違います。利用エンジンやリージョンで採用できるか、接続先と運用条件が要件に合うかを公式仕様で確認してから比較します。

障害試験を設計する 許可された検証環境でフェイルオーバーを試し、接続の切断、再接続までの時間、失敗した処理の再試行、注文の重複がないことを観測します。AWSが引継ぎを実施することと、アプリが正常に業務を再開できることを別に確かめます。実測せずに復旧時間をゼロと置かないようにします。

誤削除の復旧を設計する 担当者が正規の権限で誤って注文を削除すると、その変更は待機系やレプリカにも伝わり得ます。AZ障害の切替え試験とは別に、必要な時点へ復元できるか、復元後にどの接続先を使うか、業務としてどこまで戻せるかを確認します。複製の有無だけでデータ保護を完了としません。

例題：集計レポートの遅延許容 経営向けレポートに「最大5分前の情報まで許容」という条件があれば、レプリカの遅延がその範囲内かを監視して運用します。一方、決済確認の最新性を5分へ緩めてよいとは限りません。同じDBの読取りでも、用途ごとに許容条件を決め、レプリカの性能と遅延を測定して採用します。

図解

重要ポイント

• 従来型の待機系を分析用として使う提案は修正する。
• 分析と決済確認で許容されるデータの古さを分ける。
• レプリカ作成後は実際の接続先とクエリ実行先を確認する。
• 障害切替えと誤削除の復元は別の試験で検証する。

間違えやすい点

• レプリカの存在だけを主系負荷軽減の証拠にしない。
• 通常のリードレプリカを可用性用の自動待機系と見なさない。
• AWS側の切替え成功だけでアプリの業務再開を合格にしない。

用語解説

プライマリ

従来型RDS Multi-AZ DBインスタンス構成で、アプリケーションの読取り・書込みを通常処理する主系。

スタンバイ

障害時の引継ぎに備える待機系。従来型Multi-AZ DBインスタンス構成では通常の読取り要求を受けない。

フェイルオーバー

障害などを契機として別のDBへ処理を引き継ぐこと。アプリケーション側では再接続への対応が必要になる。

リードレプリカ

元DBのデータを複製し、主に読取り処理を分散するDB。通常のRDS DBインスタンスのリードレプリカは非同期複製で、遅延が生じ得る。

レプリケーションラグ

元DBへ反映された更新が複製先へ到達するまでの遅れ。直後の最新値が必要な読取りでは注意する。

Multi-AZ DBクラスター

書込みインスタンス1つと読取り可能なインスタンス2つを3AZへ配置するRDSの構成。単一スタンバイ型と能力が異なる。

関連教材

• RDS Multi-AZとRead Replicaを理解する