Amazon RDS・AuroraとリレーショナルDBのシナリオ判断

DB移行や障害対応の事例から、RDSとAuroraのどの機能が要件に直接対応するかを判断します。読取り量、更新の鮮度、復旧点、管理の自由度を問題文から読み取ります。

この単元で学ぶこと

具体的要件からDB構成を選ぶ
接続と複製の影響を判断する
復旧点と容量調整の条件を検証する

本文解説

1. 管理作業を減らす社内MySQLのOSやDBパッチ管理に時間がかかる事例では、RDSの対応エンジンやAurora MySQL互換を候補として比較します。両方が候補になる段階で一方を唯一の正解と決めず、互換性や保存構成、運用条件を追加して絞ります。SQLと業務権限は移行後も管理します。

2. 読取りを分ける朝のレポートSELECTがDBを圧迫し、数秒程度の鮮度差を許容できるならread replicaへの分散を検討します。writerへ向く既存接続をそのまま残すだけでは負荷は移りません。アプリ側で読取り経路を設計し、実際の負荷と複製遅延を確認します。

3. 更新直後の表示注文を確定した直後の確認画面が非同期複製先を読んだ場合、新しい注文がまだ見えないことがあります。書込み成功と複製先へ届いたことを分け、直後の表示に必要な鮮度を満たす方法を選びます。複製遅延を許す集計と同じ接続先へ一律に寄せないようにします。

4. 可用性の配置を読む従来のRDS Multi-AZ DBインスタンス構成のスタンバイは読取り用ではありません。読取り可能な副系を要求する場合、read replicaや対応するMulti-AZ DBクラスター、Aurora等を比較します。可用性だけの要件と読取り拡張を兼ねる要件を文章で分けます。

5. writer切替えへの対応 Auroraのreaderを別AZに置く構成では、読取り用途に加え切替え先としての役割を考えます。writerが切り替わった後、接続プールや再試行を確認します。確定したか不明な注文処理を無条件に再送すると二重登録の恐れがあるため、業務側の識別や冪等性も必要です。

6. 誤更新前へ戻す 12時に誤更新し、11時59分の時点が復元可能範囲にあるなら、その時点から新DBへ復元する方法を検討します。単に複製先へ切り替えても誤更新が反映されているかもしれません。復元後は正しい内容と、その後に失われる変更、利用する接続先を確認します。

7. 変動する需要平日の昼だけ負荷が高いAuroraで計算容量管理を減らすなら、Serverlessの対応条件と容量範囲を比較します。最低容量と上限を負荷試験で決め、保存やI/O等の費用も含めます。需要がゼロの時間に全ての料金がゼロになるという前提は置きません。

8. 達成条件を記録移行で確認するのはエンジン名だけではありません。必要なSQLと権限、負荷、データの一致、フェイルオーバー時の再接続、バックアップからの業務再開までを記録します。サービス仕様の確認と実際の負荷・復元の試験を分け、未試験の性能を達成済みとしないようにします。

図解

障害と負荷で必要な手段を選ぶ — 同じ「DBが困った」状況でも、原因によって必要な手段が違います。

重要ポイント

複数サービスが候補なら追加要件で絞る。
非同期複製と直前更新の表示を分けて考える。
誤更新からの復元と可用性切替えは別。

間違えやすい点

read replica作成だけで既存接続も移ったと考える。
不明な更新結果を無条件再送する。

用語解説

接続プール: DB接続を再利用して管理する仕組み。
冪等性: 同じ処理を繰り返しても重複による望まない結果を増やさない性質。
鮮度: データが直近の更新をどこまで反映しているか。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。