どんな場面で検討するか
受発注・会計連携などの SQL とトランザクションを維持し、DB のバックアップ・更新・障害切替にかかるサーバー運用を減らしたい場合。既存の DB エンジンを大きく変えない移行で比較する。
組織で使う条件
AWS が基盤管理を担っても、SQL・索引・接続数・スキーマの移行は利用者側の責任。アプリの再接続とトランザクション再試行を設計する。 保守・メジャー版更新・バックアップ復元を検証する。アプリの接続エラーを DB の自動切替だけで解決済みとは扱わない。
採用前に試すこと
- 対象エンジン・版の RDS にスキーマと合成データを移し、権限・拡張・SQL を照合する。
- 採用予定の Multi-AZ 等の構成で切替を試し、アプリから同時更新と接続再試行を行う。
- バックアップまたは時点復元で別の検証 DB を作り、接続切替と元環境への戻しを実行する。
合格と判断する条件
- テーブル件数、参照整合性、主要 SQL の金額合計が一致し、必要な操作が管理者権限の差で失敗しない。
- 確定済み注文の欠落と重複確定が 0 件。復帰時間と未確定処理の扱いが事前の業務要件を満たす。
- 指定復旧点の件数・金額が一致し、接続設定・認証情報の管理・復旧時間を含む手順が第三者に再現できる。
見落としたくない点
- OS への直接アクセス、独自拡張や全権管理者操作が必要な DB を、そのまま RDS へ置く前提にしない。RDS Custom の対応エンジンや自己管理 EC2 と比較する。 大量集計が主目的なら Redshift 等と比較する。Multi-AZ のスタンバイが必ず読取り可能とは限らず、DB インスタンス方式と DB クラスター方式を区別する。
- OS への直接アクセス、独自拡張や全権管理者操作が必要な DB を、そのまま RDS へ置く前提にしない。RDS Custom の対応エンジンや自己管理 EC2 と比較する。
- 大量集計が主目的なら Redshift 等と比較する。Multi-AZ のスタンバイが必ず読取り可能とは限らず、DB インスタンス方式と DB クラスター方式を区別する。
根拠となる資料
Fully Managed Relational Database – Amazon RDS
Master user account privileges