本記事は セゾンテクノロジー Advent Calendar 2025 8 日目の記事です。
はじめに
稼働しているRDSが限界状態で移行先を検討したので比較表を記事にしました。
同じように「RDSからスペックアップするか、Auroraやサーバレス／分散系に寄せるか」で悩んでいる方の検討材料になればうれしいです。
移行先検討比較表
前提は後述するとして、下記が現行RDSと移行先候補を並べて比較した表です。
凡例
青の網掛け：選択肢のなかで一番良いもの
赤の網掛け：移行先として懸念のある選択肢
Geekbenchスコアや最大コネクション数などは、実測値やドキュメントからの推定を含むため、あくまで検討時点での目安として見てください。
表中の数値・料金は特定リージョン・特定条件での試算ベースであり、実際の料金・性能を保証するものではありません。
前提と現行課題
とあるシステムが機能拡張により用途が広がり、ミッションクリティカルなシステムへ変化しました。
ボトルネックの１つがデータベースで、現行は以下のような状況です。
- 構成
- RDS PostgreSQL 17.2
- インスタンスタイプ: db.t3.large（2vCPU/8GiB）
- Multi-AZ配置
- ストレージ: 399GB（gp2）
- 状況
- CPU使用率が恒常的に高止まり（50%超えが常態）
- 頻繁にCPU使用率100%に張り付き
- バーストCPUクレジットが枯渇しUnlimitedモードで追加コスト発生
つまり「スパイクに耐えられない」「平常時ですらCPUが苦しい」という状態で、スペックアップはほぼ必須という前提です。
- 試算前提
- 2025/12/5時点
- 現行から4倍以上の性能向上を目指す
- 東京リージョン
- 為替：1$=150円
- ストレージ：399GB
- Baseline IO rate：700/s
- Peak IO rate：2000/s
- Duration of peak IO activity：550h/month
- Database Insights：有効
- Performance Insights：有効、1ヵ月保存
移行候補と比較観点
今回の検討では、次のような「選択肢の軸」を整理しました。
- 同じRDSのままインスタンススペックだけ上げる（m7g / m8g 系）
- Aurora Provisionedに移行して、ストレージ性能・フェイルオーバー時間なども底上げする
- Aurora Serverlessv2で利用率に応じたスケールを取りに行く
- Aurora Limitless Databaseでシャーディング前提の水平スケールを取りに行く
- Aurora DSQL（クエリ従量型）のような新しいの分散SQLを検討に含めておく
Aurora Limitless DatabaseやAurora DSQLまわりの制約や限界値は、公式ドキュメントをベースに整理しているので、細かいところが気になる場合は必ず最新のドキュメントを参照してください。
RDSスペックアップ
- 移行リスクが少なく大幅な性能向上が見込める
- ストレージもgp2からgp3へ変更
- ディスクを少し増強（最小10%）して400GBを超えるとRDSはボリュームが1→４でストレイピングされ、性能が4倍に向上
- db.m7g.4xlargeへの変更
- 最新世代ではないがReserved Instanceの対象のためコストを抑えられる
- SPではなくRIを優先するなら最有力
- db.m8g.4xlargeへの変更
- 比較した中でCPUベンチマーク（Geekbench6スコア）が一番高い
- 最新世代でReserved Instanceの対象になっていない
- AWS re:invent 2025で発表されたDatabase Savings Plansの対象
- RIではなくSPを優先するなら最有力
Aurora Provisioned
- 低ダウンタイムの運用性とストレージ性能/耐久性に強み
- リードレプリカにより本番影響無く調査作業が可能となる
- 現行の17.2がサポートされておらずマイナーバージョンアップになるため影響調査が必要
Aurora Serverless v2
- 常時トラフィックがあるワークロードではProvisionedよりも費用対効果は劣る
- 自動スケールアップ／ダウンができるためスパイク耐性に強み
- ProvisionedとServerless v2のハイブリッドもできますが複雑度が上がり非機能テストノパターンも増えるため今回は外しました
- 少し情報が古いかもしれませんが下記の比較記事も参考にしてください
Aurora Limitless Database
シャーディング前提で水平スケールさせるためのAuroraの新しいオプションで、シャードキーに基づいて自動的にデータを複数シャードへ分散しつつ、アプリケーションからは1つのデータベースとして見えるようにしてくれます。
ペタバイト級のデータと、数百万トランザクション/秒クラスのスループットを想定した設計になっており、「単一インスタンスの限界を超える必要がある」ケース向けの選択肢です。
-
シャードキー設計が前提
- テーブルごとにシャードキーを定義し、その値に応じてどのシャードに保存されるかが決まる
- テナントIDやユーザIDなど、アプリケーション側のアクセスパターンと強く結びつくキー設計が必要になる
-
アプリケーション影響が大きいポイント
- シャードをまたぐJOINやトランザクションには制約があり、従来の「なんでも1台のRDBに投げる」設計からの発想転換が必要
- 一部のSQL文やPostgreSQL拡張が利用できない、トランザクション分離レベルに制約がある（Serializable は非サポート）など、アプリケーションロジック側で吸収すべき差分が発生する
-
運用・スケールの特徴
- ルータノードとシャードノードを組み合わせた構成で、ACU（Aurora Capacity Unit）を指定して水平方向にスケールさせる
- ストレージはAurora I/O-Optimizedの分散ストレージを前提としており、シャード数に応じて実質的に無制限に近いスケールを狙える
-
データベースの再設計によりアプリケーションへの影響が大きい
-
オートスケール機能や実質無制限のストレージは強力だが本件ではアンマッチ
Aurora DSQL
PostgreSQLベースの分散SQLをフルマネージドかつサーバレスで提供するサービス
クラスターを意識せずに、常時Active-ActiveなマルチリージョンRDBとして利用できます
コンピュート、トランザクション制御、ストレージがそれぞれ分離された分散アーキテクチャで構成されており、トラフィックに応じて自動的にスケールしてくれます。
- 特徴的なポイント
- クエリ負荷に応じたDPU消費による従量課金
- サーバレスでマルチAZ/マルチリージョンに分散され、シングルリージョンで99.99%、マルチリージョンで 99.999%の可用性
- 強整合なACIDトランザクションを維持しつつ、分散環境でのスナップショット分離やフェイルオーバーを自動的にハンドリングしてくれる
- アプリケーション設計への影響
- 外部キーやシーケンスといったPostgreSQLの一部機能が使えず、整合性管理や連番採番などをアプリケーション側で実装する必要がある
- 1トランザクションあたりの更新件数・データサイズ、接続レートや接続時間などに上限があり、大量一括更新や長時間トランザクションとは相性が良くない
- 接続認証はIAMベースの一時トークンを前提としており、既存アプリの接続方式を見直す必要がある
- 本件のように既存PostgreSQLアプリをほぼそのまま載せ替えたいケースでは、制約や再設計コストが大きく、やはりアンマッチ
検討してみての所感
- 「とりあえずCPU苦しいのでスペックアップしたい」だけなら、m7g/m8g系へのスケールアップが一番シンプルですが、せっかくの機会なのでよりスケーラブルなデータベースを採用したいという思いがありましたが意外と難しいのがわかりました。
- Aurora Provisionedはフェイルオーバー時間やストレージ性能、リードレプリカのWriter昇格など「ミッションクリティカル向けの総合力」が高く、アプリ改修を最小限にしたまま一段レベルを上げたいときの本命でしたが、現行バージョン17.2がAuroraではサポートされていない上に、意外とRDSとの非互換がありアセスメント調査が必要な点でマイナス要素でした。
- Aurora ServerlessV2は、ワークロードの波が大きい場合に最適ですが、本件では恒常的なトランザクション量が多く、Provisionedに譲る形となりました。
- Aurora Limitless DatabaseやAurora DSQLは、スケールの天井を外す代わりに「データモデリングとアプリ側の設計思想を根本から変える」必要があるので、既存システムの延命というよりは、次世代アーキテクチャをゼロベースで設計するときに本命候補として検討するのがよさそうです。
この記事が、同じようにRDSの次の一手を検討している方の材料として少しでも役に立てば幸いです。
参考情報
比較表を作成する際に下記のサイトを参考にさせていただきました
Auroraのリストアにかかる時間
https://polar3130.hatenablog.com/entry/2022/03/04/160500
Serverless v2
https://blog.serverworks.co.jp/aurora-serverless-v2-max_connections
https://www.reddit.com/r/aws/comments/1f7fvvt/experiences_with_aurora_serverless_v2/
CPUベンチマーク
https://browser.geekbench.com/v6/cpu/9524060
https://browser.geekbench.com/v6/cpu/4070114
https://browser.geekbench.com/v6/cpu/7978512
https://browser.geekbench.com/v6/cpu/11335856
https://browser.geekbench.com/v6/cpu/528109
https://browser.geekbench.com/v6/cpu/624290
AWS公式サイト
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Storage.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.FastFailover.html
https://aws.amazon.com/jp/rds/sla/
https://aws.amazon.com/jp/rds/aurora/sla/
https://aws.amazon.com/jp/rds/aurora/dsql/sla/
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/limitless-updates.html