Aurora vs RDS — 構造の違いと乗り換える基準

インフラ AWS コスト
読了 6分

RDS コンソールでエンジンを選ぶときの最初の分かれ道は、MySQL か PostgreSQL かではなく、標準 RDS か Aurora かです。どちらもマネージドで同じプロトコルで接続するので見た目はグレードの違いのようですが、実際にはストレージ構造が異なる別の製品です。結論を先に書くと、小規模で安定した負荷は標準 RDS が安く、読み取りスケール・可用性・スパイクの多い負荷の要求が実測で見えたら Aurora に移ります。 インスタンスクラスの選択は RDS インスタンスクラス比較 で扱ったので、この記事はその前段階の選択です。料金は us-east-1 基準です。

構造が違います — ディスクではなくストレージサービス #

標準 RDS はインスタンスに EBS ボリュームが付く構造です。サイズを事前に決め、Multi-AZ ならスタンバイに同じボリュームがもう一つでき、リードレプリカはそれぞれ自分のストレージに複製を書きます。

Aurora はコンピュートとストレージを分離しました。データは 3 つの AZ にまたがって 6 重に複製される共有ストレージ層にあり、インスタンスはその上に取り付きます。この構造から違いが連鎖的に生まれます。

  • リードレプリカ最大 15 台が同じストレージを読むので、レプリケーション遅延はミリ秒単位です。標準 RDS のレプリカは論理レプリケーションなので、遅延が秒単位に広がることがあります。
  • フェイルオーバーが速いです。 レプリカがすでに同じデータを見ているので、昇格はたいてい 30 秒以内に終わります。標準 RDS の Multi-AZ は 1〜2 分ほど見ます。
  • ストレージが自動で増えます。 事前にサイズを決めず、使った分だけ課金され、上限は 256TiB まで引き上げられました。「ディスクが満杯になった」という運用トラブルの類型が一つ消えます。
  • スナップショット復元なしで数分で書き込み可能な複製クラスターを作る高速クローン、MySQL 互換版の Backtrack(復元なしで時点を巻き戻す)といった付加機能も、このストレージ層から生まれています。

料金構造 — インスタンスのプレミアム + ストレージ・I/O #

Aurora の料金は 3 層です。

  • インスタンス: 同じクラス基準で、標準 RDS より時間あたり料金が 20% 前後高くなります。
  • ストレージ: 基本構成(Aurora Standard)で GB・月あたり約 $0.10。標準 RDS の gp3(約 $0.115/GB・月、ストレージの選択基準 参照)と同水準ですが、使った分だけ払います。
  • I/O: ここが変数です。Aurora Standard は I/O リクエスト 100 万件あたり約 $0.20 を別に取ります。キャッシュがよく効くワークロードなら無視できる水準で、書き込みやスキャンが多いとインスタンス料金を超えることもあります。請求書でこの項目が膨らむのが、Aurora の料金が予測を外れる典型的なパターンです。

そこで I/O-Optimized 構成があります。I/O 課金をなくす代わりに、インスタンス料金が約 30% 高く、ストレージが GB・月あたり約 $0.225 に上がります。基準線は明確です。Aurora の支出全体に占める I/O が 25% を超えたら I/O-Optimized が安くなります。 クラスター単位で切り替えられるので、Standard で始めて請求書の I/O 比率を見て決めれば十分です。

Serverless v2 — スパイクの多い負荷への答え #

Aurora にはインスタンスクラスの代わりに容量単位(ACU)で秒単位課金する Serverless v2 があります。ACU あたり 1 時間約 $0.12(I/O-Optimized は約 $0.156)で、負荷に応じて数秒で増減します。最小容量を 0 にしておくと、アイドル時に自動一時停止してコンピュート料金が 0 になります。 夜間に空く社内ツール、開発・検証環境、トラフィックが予測できない新規サービスが対象です。

計算は必要です。常時負荷なら同じ容量のプロビジョンドインスタンスより ACU 単価が高いので、ベース負荷が安定したサービスはプロビジョンド + 必要に応じたレプリカのほうが安くつきます。Serverless v2 は「負荷が大きく揺れるか、0 に落ちる時間が長い」という条件でだけ削減の手段になります。

標準 RDS が依然として正解になる条件 #

  • 小規模で安定した負荷: db.t4g.micro(月 $12 ほど)で足りるサービスに Aurora のプレミアムを乗せる理由がありません。開発・検証環境も同じです(0 ACU の Serverless v2 が競合相手ではあります)。
  • エンジンが違う場合: Aurora には MySQL 互換と PostgreSQL 互換しかありません。MariaDB、Oracle、SQL Server は標準 RDS で確定です。
  • バージョンや拡張の要求が具体的な場合: Aurora は互換であって同一エンジンではないので、コミュニティ版の特定マイナーバージョンや一部の拡張・ストレージエンジン(MyISAM など)が必要なら標準 RDS に行きます。
  • 料金の予測可能性: I/O 課金のない固定構成を優先するなら、標準 RDS + gp3 が単純です。

逆に、リードレプリカを増やし続けている、フェイルオーバー時間が SLA に引っかかる、ストレージ増設の作業が繰り返し発生する、I/O ボトルネックの実測(バッファプールの判定 参照)がクラス増強で解消しない — こうした状況が Aurora への移行を検討するタイミングです。

移行の実務 — リードレプリカの昇格が定石です #

標準 RDS の MySQL・PostgreSQL から Aurora へは、Aurora リードレプリカを作ってレプリケーションが追いついた後に昇格する手順が定石です。スナップショット復元より中断が短く、移行前に Aurora 側の性能を実際の負荷の複製で検証できます。昇格の前にアプリケーションの接続文字列をクラスターエンドポイント(書き込み)とリーダーエンドポイント(読み取り)に分けておくと、その後のレプリカ拡張がコード変更なしでできます。接続・移行の一般的な実務は AWS 実践 #2 で扱いました。

まとめ #

  • Aurora はグレードではなく構造が異なる製品です。3AZ・6 重複製の共有ストレージから、15 台のレプリカ、30 秒のフェイルオーバー、256TiB の自動拡張が生まれます。
  • 料金はインスタンスのプレミアム(20% 前後)にストレージと I/O が乗る 3 層構造です。I/O が支出の 25% を超えたら I/O-Optimized に切り替えます。
  • Serverless v2 は ACU の秒単位課金で、0 ACU の一時停止ができます。スパイクが多いかアイドルが長い負荷でだけ削減の手段です。
  • 小規模で安定した負荷、MySQL・PG 以外のエンジン、特定のバージョン・拡張の要求、料金予測の優先なら標準 RDS が正解です。
  • 移行は Aurora リードレプリカの昇格が定石で、その前にクラスター・リーダーエンドポイントの分離をしておきます。
X