DSQL導入判断 総合レポート
自社の業務をAurora DSQLで運用してよいか。よいとすれば、どのような条件においてか。
結論
Aurora DSQLは本番のOLTPに使えます。ただし、すべてのサービスに適した選択ではなく、以下の条件を満たすサービスで有利です。 この判断は、ソウルリージョンで同じ注文業務をDSQLと既存サービス3種(RDS PostgreSQL Multi-AZ、Aurora Provisioned、Aurora Serverless v2)で実行した12件の実験(2026-09-24–29)に基づいています。12件のうちE001、E002、E004は計画に近い規模で、残りの9件は最小範囲(MVP)で実行しました。
DSQLが明確に優れていた点は4つです。第一に、スループットが最も大きく拡張しました。接続256本で毎秒2万4千件以上を遅延目標内で処理し、同じ条件の既存サービスはすべて目標を超えました(E002)。第二に、リクエストがないときにはほとんどコストがかからず、15分休止した後でも最初のリクエストに0.3秒以内で応答しました(E009、E010)。第三に、コミットしたデータがどの接続からもすぐに見えるため、読み取りのルーティングが不要でした(E005)。第四に、クラスターを30秒あまりで作成でき、容量・パスワード・vacuumを管理する必要がありませんでした(E011)。
代償も明確です。リクエスト1件の遅延はAuroraの3–6倍で(書き込みp95 約30–40 ms)、既存のPostgreSQL SQLの約半分を修正する必要があり(E001)、競合時の再試行・トランザクション分割・接続の入れ替えといったアプリケーションコードが必須でした(E004、E008、E003)。人気商品のように同じ行に書き込みが集中すると、再試行後も多くの失敗が残り(E004)、任意の時点に戻すポイントインタイムリカバリがありませんでした(E007)。高い負荷が一日中続く場合は、リクエスト数に比例する料金が固定インスタンスより高くなりました(E010)。
判断基準別の結果
| 基準 | DSQL | 既存サービス | 判定 | 根拠 |
|---|---|---|---|---|
| 整合性 | 再試行・業務IDレシートを実装した場合、不変条件違反0件(競合66セル、接続障害) | 同じ | 同等 | E004, E006 |
| スループット(接続256、SLO内) | 24,541 TPS以上 | A2 11,559、R1 5,839、A1 3,375 TPS | DSQL優位 | E002 |
| リクエスト遅延 | 書き込みp95 約28–41 ms、読み取り約5–10 ms | A2 書き込み約7–9 ms、読み取り約2–3 ms | 既存優位 | E002 |
| 急増(最大2,000 TPS) | 介入なしで失敗0 | A2 介入なしで失敗0 | 同等 | E009 |
| 15分アイドル後の最初のリクエスト | 接続0.1–0.3秒 | A2(0 ACUで一時停止)15秒超で失敗 | DSQL優位 | E009 |
| 書き込み直後の読み取り | 別の接続からも即時 | A2 readerは22–33 ms後 | DSQL優位 | E005 |
| 接続 | 新規接続p50 15 ms、1,000本の同時接続で拒否0。リクエストごとに新規接続するとスループット1/70 | 比較せず | プール必須 | E003 |
| 競合の集中 | コミット時点の競合、接続256で再試行後の最終失敗39% | ロック待ちでスループット急減(小型インスタンス) | どちらも設計が必要 | E004 |
| 運用中のDDL | 1,100万行の非同期インデックス12分、ビルド中の書き込みp99 30.7→79.8 ms、SLO維持 | 比較せず | 可能 | E008 |
| トランザクション上限 | 3,000行、300秒を超えると拒否 | 上限なし | 制約 | E008 |
| 大規模集計 | 1,100万行の全件集計36秒、約1,700 DPU。OLTPへの干渉は小さい | 比較せず | 制約 | E012 |
| 誤操作からの復旧 | ポイントインタイムリカバリなし。フルバックアップ(481秒)→新クラスター(129秒) | A2 ポイントインタイムリカバリ587秒 | 既存優位(RPO) | E007 |
| SQL移行 | 35件中16件で修正が必要 | ほぼ修正なし | 既存優位 | E001 |
| インフラ運用 | 作成32秒、削除約2分、容量・パスワード・vacuumなし | A2 作成約11分、削除約15分 | DSQL優位 | E011 |
| コスト | リクエスト100万件あたり約$0.31、アイドル時はほぼ0、ストレージ$0.40/GB-月 | R1 1時間あたり約$1.22(固定)、ストレージ$0.12–0.131/GB-月 | 負荷の形による | E010 |
判定は、今回の測定範囲内でどちらが導入判断に有利だったかを示します。「同等」は差を見つけられなかったという意味であり、差がないことの証明ではありません。
DSQLが適しているサービス
- 新規に設計するサービス: 最初からDSQLのSQL対応範囲、再試行、トランザクション上限に合わせて作れば、E001・E004・E008で見られた移行負担の大部分がなくなります。
- 負荷の変動が大きい、または休止時間が長いサービス: 平均負荷が約1,100 TPSより低い場合(今回の業務基準)、DSQLは固定インスタンスより安く、8時間稼働して16時間休止するパターンでは1日あたり約$9対約$29でした。休止後でも最初のリクエストはすぐに処理されます。
- 急増が予測できないサービス: 容量を事前に決めなくても、2万4千 TPSまで遅延はほとんど増えませんでした。
- 運用人員が少ないチーム: インスタンスサイズ、フェイルオーバー用スタンバイレプリカ、パスワードのローテーション、vacuum、readerへのルーティングを管理する必要がありません。
- 自分の書き込みをすぐに読む必要がある画面: レプリケーション遅延がないため、書き込み直後の読み取りのためのルーティングコードが不要です。
DSQLを避けるべき、または慎重になるべきサービス
- 既存のPostgreSQL機能に深く依存するサービス: PL/pgSQL・トリガー、sequence・
serial、一時テーブル、パーティション、READ COMMITTED、statement_timeoutを使うコードは書き直す必要があります。 - 同じ行に書き込みが集中する業務: 人気商品の在庫やグローバルカウンターのように少数の行に競合が集中すると、再試行後も多くの失敗が残ります。行の分割などのスキーマ再設計が先です。
- リクエストごとの遅延が重要な業務: 1つのリクエストで複数のクエリを順番に実行すると、DSQLのクエリごとの遅延(書き込み約30–40 ms)が累積します。
- 高い負荷が一日中続くサービス: 平均数千TPSが続くと、リクエスト数に比例するDPU料金が固定インスタンスより高くなります。
- 大量バッチ・分析が多いサービス: 3,000行・300秒の上限に合わせてバッチを分割する必要があり、大規模な集計は処理量に応じて課金されます。分析は別のストアに分離するほうが安全です。
- 秒単位の復旧時点が必要なサービス: ポイントインタイムリカバリがないため、復旧できる最新時点はバックアップ周期で決まります。
- データが非常に大きいサービス: ストレージ単価がAuroraの約3.3倍です。
導入前に必須の準備
具体的なコード例とコーディングエージェント向けのルールはAurora DSQL利用ガイドにまとめています。
- 再試行と冪等処理: コミット時点の競合(
40001)を再試行し、コミット応答を受け取れなかったリクエストは業務IDで結果を確認してから再試行します(E004、E006)。 - トランザクション分割: 3,000行・300秒を超えるロード・削除・バッチを分割します(E008)。
- 接続管理: 接続プールを使い、1時間以内に接続を入れ替え、IAMトークンを再利用し、同時の初回接続でトークン署名が集中しないようにします(E003)。
- スキーマのデプロイ手順: 非同期インデックスは
indisvalidを確認してから使用し、外部キーの参照側のインデックスは自分で作成します(E002、E008)。 - 復旧設計: 許容できるデータ損失時間に合わせてAWS Backupの周期を決め、新しいクラスターに切り替える手順(エンドポイント・IAM権限の変更)を準備します(E007)。
- コスト確認: 実際の業務でリクエストあたりのDPUを測定し、平均負荷とアイドル比率をもとに固定インスタンスと比較します(E010)。
根拠の限界
- 実行規模: ほとんどの測定は1回です。繰り返し間のばらつきは測定しておらず、9件の実験は計画の一部のみを実行したMVPです。欠けている範囲は各レポートの「計画から変わった点」に記載しています。
- 比較条件: DSQLと対照群のスループット探索は、別の日に、異なるランナー仕様で実行しました。DSQLはパブリックエンドポイント、対照群はVPC内部の経路です。E004の対照群は小型のバースト可能インスタンスでした。
- DSQLの上限: DSQLのスループット24,541 TPSは、負荷生成器の飽和付近の下限値であり、サービスの上限ではありません。
- 業務とデータ: 1種類の注文業務の組み合わせと約5 GiBのデータです。他のクエリパターンやTB規模のデータでは、遅延・DPU・コストが変わる可能性があります。
- 可用性: DSQL内部の障害とAZ障害、Aurora・RDSのフェイルオーバー時間は測定していません。
- コスト: ソウルリージョンのOn-Demand単価と、測定値の線形換算です。割引・クレジット、Aurora I/Oの負荷別の切り分け、人の作業時間は金額に含めていません。
実験一覧とコスト
| 実験 | テーマ | 範囲 | レポート |
|---|---|---|---|
| E001 | SQL互換性 | 計画範囲 | 見る |
| E002 | OLTPスループットと遅延 | 探索まで、本測定は除外 | 見る |
| E003 | 接続と認証 | MVP、DSQL単独 | 見る |
| E004 | 競合と整合性 | 計画条件、小型対照群 | 見る |
| E005 | 書き込み直後の読み取り | MVP、D1・A2 | 見る |
| E006 | 接続障害とコミットの保持 | MVP、D1・A2 | 見る |
| E007 | バックアップと誤操作からの復旧 | MVP、D1・A2 | 見る |
| E008 | 運用中のDDLと上限 | MVP、DSQL単独 | 見る |
| E009 | 急増とアイドル後の再開 | MVP、D1・A2 | 見る |
| E010 | コストと選択基準 | MVP、測定値の換算 | 見る |
| E011 | 開発・運用の利便性 | MVP、作業記録の整理 | 見る |
| E012 | 大容量クエリと干渉 | MVP、DSQL単独 | 見る |
研究全体の実験コストは、Cost Explorerの請求額で約$75です。E001が約$0.08、E004が約$2.07、E002の1回目が$48.57、E002の2回目とE003・E008・E012が$18.54、E005・E006・E007・E009が$5.07、2026-09-29の2つの実行で共用した転送・ストレージなどが$0.65です。すべての実験リソースは削除し、実行ごとに残存リソースが0であることを確認しました。