「Aurora のメリットって何ですか？」
わりとよく聞かれる質問です。 なんとなく「速い」「強い」「クラウド向け」とは思っているけれど、きちんと整理して説明できるかと言われると自信がありません。
ということで今回は、
- RDS for MySQL と Aurora MySQL の違い
- Aurora を選ぶメリット
- 何がスケールして、何がスケールしないのか
を、教科書的な観点で整理してみました。
RDS for MySQL と Aurora MySQL の本質的な違い
一言でまとめると、こうなります。
- RDS MySQL は「1台の MySQL サーバー＋EBS」
- Aurora MySQL は「MySQL 互換の分散データベース」
同じ MySQL プロトコルで接続できますが、中身の設計はかなり違うようです。
① ストレージがまったく別物
| RDS MySQL | Aurora MySQL | |
|---|---|---|
| ストレージ | EBS（単一ボリューム） | 分散ストレージ（6コピー） |
| 可用性 | AZ障害で停止の可能性 | 2台壊れても継続可能 |
| 拡張 | サイズ指定が必要 | 自動拡張（最大128TB） |
Aurora は、最初から「クラウド向けの分散DB」として設計されているらしく、ストレージが 6 重化されているのが特徴です。
RDS MySQL は基本的に EBS 上にデータを持つ構成なので、「単一ボリューム」という前提が残ります。
② I/O性能と安定性が違う
| RDS MySQL | Aurora | |
|---|---|---|
| I/O | EBS に依存 | 分散ストレージで並列処理 |
| バックアップ | DBインスタンスの I/O を消費 | ストレージ側で実行 |
| IOPS設計 | 必要（gp2/gp3など） | 基本不要 |
Aurora はバックアップをストレージ側で処理する設計らしく、DBインスタンス側の I/O をあまり消費しないと言われています。
つまり、負荷が高いときでも挙動が変わりにくい、というのが強みのようです。
③ フェイルオーバーが速い
| RDS MySQL | Aurora | |
|---|---|---|
| 障害時切替 | 1〜2分程度 | 10〜30秒程度 |
| 再同期 | データコピーが必要 | 不要（共有ストレージ） |
Aurora はレプリカが同じストレージを参照しているため、切り替えが速い、という説明がされています。
RDS MySQL の場合はレプリカ側にデータを同期させる必要があるため、切替時間が長くなりがちです。
④ リードレプリカの質が違う
| RDS MySQL | Aurora | |
|---|---|---|
| 同期方式 | binlog同期 | 共有ストレージ |
| 遅延 | 数秒〜数十秒あり得る | ほぼリアルタイム |
| Writer負荷 | 影響あり | ほぼ影響なし |
Aurora はレプリカが同じ分散ストレージを直接読むため、遅延が小さいと言われています。
そのため「読み取りの水平スケールがしやすい」というのがメリットの一つのようです。
⑤ バックアップが安全で高速
| RDS MySQL | Aurora | |
|---|---|---|
| 方式 | フル＋増分 | 常時増分 |
| 負荷 | DBのI/Oを消費 | ほぼ影響なし |
| 安全性 | ボリューム単位 | ストレージ分散 |
Aurora は常時増分バックアップで、ストレージ側で処理される設計になっているため、バックアップ中に重くなりにくいと言われています。
運用面ではこれはかなりありがたいポイントです。
⑥ 管理の手間が減る
Aurora では：
- ストレージサイズ管理が不要
- IOPS設計が不要
- バックアップ負荷の心配が少ない
RDS MySQL では：
- ディスク容量を事前指定
- IOPS設計
- 容量上限の監視
といった運用設計が常に必要になります。
Aurora は「考えることが減る」という意味で、運用負荷が軽くなる傾向があるようです。
では RDS MySQL の方が良い場面は？
Aurora が万能というわけではありません。
RDS MySQL が向いているのは：
- 小規模
- 負荷が予測可能
- コストを抑えたい
- MySQL の挙動を完全にそのまま使いたい
Aurora が向いているのは：
- 可用性が重要
- I/Oが多い
- 将来スケールの可能性がある
- 運用を楽にしたい
といったケースです。
Aurora でスケールするもの / しないもの
ここは誤解されやすいポイントです。
| 項目 | 自動スケール？ | 補足 |
|---|---|---|
| Writer（書き込み用DBのCPU/RAM） | ❌ しない | インスタンスタイプ固定 |
| Read Replica台数 | ✅ 可能 | Auto Scaling対応 |
| Read処理能力 | ✅ スケール | レプリカ追加で水平拡張 |
| ストレージ容量 | ✅ 完全自動 | 最大128TB |
| ストレージIOPS | ✅ 自動 | 上限設計不要 |
| バックアップ容量 | ✅ 自動 | 増分バックアップ |
① Writer はスケールしない
一番誤解されがちなのがここです。
Aurora でも、
- 書き込み用インスタンスの CPU / RAM は固定
です。
CPU が 100% になっても、勝手に大きなインスタンスに変わることはありません。
スケールアップは：
- 手動で変更
- 運用で切替
が必要です。
② Read はスケールする
Aurora の強みはここです。
- 最大15台のレプリカ
- CPUや接続数に応じた Auto Scaling
- ほぼリアルタイム
つまり：
読み取りはオートスケールできるが、書き込みはできない
これが Aurora の基本的なスケールモデルのようです。
③ ストレージは完全自動
RDS MySQL では：
- 100GB と指定
- 上限に近づいたら手動拡張
Aurora では：
- サイズ指定不要
- 自動拡張（最大128TB）
ディスクフルで落ちる事故が起きにくい、というのは大きな安心材料です。
④ I/O も自動
RDS では：
- gp2 / gp3 の IOPS 上限
- IOPS を上げると課金増
Aurora では：
- 分散ストレージが並列処理
- IOPS の事前設計が不要
ここも運用設計の差になります。
最終まとめ（超要約）
Aurora MySQL は、
RDS MySQL をクラウドネイティブに進化させたもの
と言われることがあります。
具体的なメリットは：
- 高可用性（6重化ストレージ）
- 高I/O性能
- 高速フェイルオーバー
- 強力なリードスケール
- 安全で軽いバックアップ
- ストレージ自動拡張
ただし、
- Writer の性能は固定
- 書き込みスケールは自動ではない
という点は理解しておく必要があります。
「Aurora は勝手に全部スケールする魔法の DB」ではなく、
- 読み取りとストレージはクラウド型
- 書き込みは従来型
というハイブリッドな設計。
これが Aurora のスケールモデルだと言えそうです。