どんな場面で検討するか
MySQL または PostgreSQL 系の業務アプリで、読取り負荷・高可用性・時間帯ごとの負荷変動を DB 構成で吸収したい場合。通常の RDS と、読取り分散や Serverless の必要性を比較する。
組織で使う条件
接続の再確立、reader の遅延、長いトランザクション、容量の上限、スキーマ更新を管理する。容量の自動増加に索引不足の解消まで任せない。 reader を含む切替と時点復元を確認する。Serverless の拡張・縮小と、採用時に必要なら休止・再開による待ち時間を実測する。
採用前に試すこと
- 同じ合成スキーマを Aurora に配置し、writer の更新と reader の照合、主要 SQL の実行計画を確認する。
- 負荷を上げ下げして容量・遅延を測定し、reader を用意した構成で writer 切替とアプリ再接続を試す。
- 復元した別クラスターで期待データを照合し、計算・保存・I/O の内訳から RDS、Standard、I/O-Optimized を比較する。
合格と判断する条件
- SQL 結果・金額合計が一致し、更新直後に必要なデータをどの接続先から読むか説明できる。
- 確定済みデータの欠落と二重確定が 0 件。負荷時と切替時の応答・復帰が事前の要件内に収まる。
- 復旧点の件数・金額が一致し、採用する方式を性能と総費用の両面で判断できる。
見落としたくない点
- Oracle・SQL Server 固有の機能をそのまま維持する目的では互換先にならない。対応する RDS エンジンや自己管理 DB と比較する。 小規模で一定負荷の DB は通常 RDS と総費用を比較する。Serverless という名称だけで常時費用が 0 円になるとは判断しない。自動休止は対応版・構成の条件を確認する。
- Oracle・SQL Server 固有の機能をそのまま維持する目的では互換先にならない。対応する RDS エンジンや自己管理 DB と比較する。
- 小規模で一定負荷の DB は通常 RDS と総費用を比較する。Serverless という名称だけで常時費用が 0 円になるとは判断しない。自動休止は対応版・構成の条件を確認する。
根拠となる資料
Relational Database – Amazon Aurora MySQL PostgreSQL