DSQLと既存サービスの負荷急増への対応とアイドル後の再開
DSQLと既存のサーバーレス・固定容量サービスの遅延・手動介入・費用はどう違うか？
結果の要約
この実験では、リクエスト量が急に増えたとき、または長くリクエストがなかった後に再び届いたときに、人が容量を調整しなくても遅延目標を守れるかを、DSQLとAurora Serverless v2（A2）で比較しました。最小範囲（MVP）として、基準1,000 TPSの20%（2分）→200%（1分）→100%（2分）→5%（1分）と到着率を変える急増負荷を1回送り、その後すべての接続を閉じて15分待ってから最初のリクエストを送るアイドル試験を2回行いました。
急増負荷では、両サービスとも手動介入なしですべての段階を失敗0件で処理しました。DSQLの注文作成p95は29.2–36.0 msで、到着率が10倍になってもほとんど変わらず、2,000 TPS段階のp99は51.5 msでした。A2は4–32 ACUの範囲でwriterが10.5 ACUから最大21 ACUまで増え、注文作成p95は8.2–12.1 ms、2,000 TPS段階のp99は37.9 msでした。この急増幅（最大2,000 TPS）はE002で測定した両サービスの容量より小さいため、容量限界での急増対応は今回の結果からは判断できません。
アイドル後の最初のリクエストでは大きな差が出ました。DSQLは15分間接続がなかった後でも、最初の接続112–287 ms、最初の照会115–123 msで応答し、その後の照会は約2 msに戻りました。A2はこの試験の間、最小容量を0 ACU、自動一時停止を300秒に設定しており、CloudWatchで実際に0 ACUまで停止したことを確認しました。この状態で最初の接続は2回ともドライバーの接続タイムアウト15秒以内に完了せず失敗し、その接続試行が再開を引き起こして約1分以内に容量が戻りました。
本番利用の観点
リクエストがまばらに届く、または夜間に止まるサービスでは、DSQLが明確に有利でした。DSQLは15分のアイドル後も最初のリクエストを0.3秒以内に処理し、アイドル中はコンピューティング料金がかかりません。Aurora Serverless v2も0 ACUの自動一時停止でアイドル費用をなくせますが、再開中に最初の接続が15秒を超えて失敗したため、接続タイムアウトとリトライを長めに設定する必要があります。今回の急増幅では両サービスとも手動介入なしで処理できたため、容量限界付近での急増対応はE002の容量結果と合わせて判断する必要があります。1回の実行、小規模データでの結果です。
確認する問い
DSQLと既存のサーバーレス・固定容量サービスの遅延・手動介入・費用はどう違うか？
実行条件
- リージョンと日時: ソウル（ap-northeast-2）、2026-09-29。急増 08:43–08:51 UTC、アイドル 08:51–09:21 UTC。
- 構成: D1 Aurora DSQL 単一リージョン、A2 Aurora PostgreSQL 16.15 Serverless v2（writer+reader、急増試験は4–32 ACU）。データはE002規模の2%です。R1・A1（固定容量）は今回のMVPから除外しました。
- 急増負荷: E002と同じ業務の組み合わせを固定到着率で送りました。段階ごとに新しいセルとして実行し、ウォームアップはありません。段階の間にセルの準備時間（D1 約20–45秒、A2 約10秒）があるため、計画どおりに途切れず続く負荷ではありません。
- アイドル試験: ランナーの接続をすべて閉じて900秒待った後、新しい接続 → 商品1件の照会 → 続けて20件の照会の時間を測りました。2回繰り返しました。A2はこの間
MinCapacity 0、SecondsUntilAutoPause 300に変更し、試験後に4–32 ACUへ戻しました。接続タイムアウトはドライバー設定の15秒です。 - 負荷発生器: D1
c6g.4xlarge、A2m7g.4xlargeのSpotランナー。 - 計画から変わった点： Qref基準の比率（20%→200%→100%→5%）の代わりに1,000 TPS基準を使い、段階の時間を短縮し（10/2/20/10分 → 2/1/2/1分）、3回の繰り返しとアイドル5回の代わりに1回と2回を実行しました。
性能結果
急増負荷
注文作成 p95 / p99（ms）。すべての段階で失敗率0（D1の1,000 TPS段階は0.0008%）。
| 段階 | 到着率 | D1 成功TPS | D1 注文作成 | A2 成功TPS | A2 注文作成 | A2 writer ACU（最大） |
|---|---|---|---|---|---|---|
| 20% | 200 | 198 | 29.2 / 38.6 | 198 | 8.5 / 12.2 | 15 |
| 200% | 2,000 | 1,960 | 30.1 / 51.5 | 1,960 | 9.3 / 37.9 | 19–21 |
| 100% | 1,000 | 965 | 29.2 / 40.2 | 965 | 8.2 / 9.9 | 10.5–19 |
| 5% | 50 | 49 | 36.0 / 67.4 | 49 | 12.1 / 14.9 | 10.5 |
- D1の5%段階でp99が大きくなったのは、リクエスト数が少なく（1分で約3,000件）、少数の遅いリクエストがp99を左右したためと考えています。
15分アイドル後の最初のリクエスト
| 構成 | 回 | 最初の接続 | 最初の照会 | 以降20件のp50 | 結果 |
|---|---|---|---|---|---|
| D1 | 1 | 287 ms | 123 ms | 2.2 ms | 成功 |
| D1 | 2 | 112 ms | 115 ms | 1.9 ms | 成功 |
| A2 | 1 | 15.2秒後に失敗 | - | - | 接続タイムアウト超過 |
| A2 | 2 | 15.1秒後に失敗 | - | - | 接続タイムアウト超過 |
- A2 writerのACUは08:57–09:05 UTCと09:12–09:20 UTCに0で、最初の接続試行後1分以内に2–6 ACUへ上がりました。再開にかかった正確な時間は今回のツールでは測定できませんでした（15秒以上）。
開発・運用のしやすさ
- 急増試験の間、両サービスとも人の介入は不要でした。A2はACUの範囲（最小・最大）を事前に決める必要があり、DSQLには設定する容量値がありません。
- A2の自動一時停止を使うには、最小容量を0に変更し、アプリケーションの接続タイムアウトとリトライを再開時間より長く設定する必要があります。DSQLはアイドル後の最初の接続にIAMトークンの署名とTLS接続が必要でしたが、0.3秒以内に完了しました。
費用
E005・E006・E007・E009は同じ実行B（e002-20260929t082035z-afbe、2026-09-29 08:20–10:20 UTC）でリソースを共有したため、費用を実行単位で記載します。推定費用はCloudWatchの使用量にソウルリージョンのオンデマンド単価を掛けた値で、実際の請求額は2026-09-30にCost Explorer（2026-09-29 UTC、使用タイプ別）で確認した値です。同じ日に実行したE002の2回目の測定とDSQL DPU・Spotランナーが同じ行で請求されたため、DPUはクラスター別のCloudWatch値で、Spotランナーはインスタンスタイプ別の稼働時間の比率で分けました。実験前日から発生していたアカウントの常時料金は除外しました。
| 項目 | 使用量 | 推定費用 | 実際の請求額 |
|---|---|---|---|
| A2コンピューティング | 推定19.05 ACU時間（writer 8.53、reader 9.26、E007の復元コピー1.26）、請求18.77 ACU時間 × $0.20 | 約$3.81 | $3.75 |
| A2 I/O | 請求119万8千I/O | 約$0.29 | $0.29 |
| D1 DPU | 34,055 DPU + E007の復元コピー33 DPU | 約$0.23 | $0.34 |
| E007 DSQL復元 | 復元データ0.095 GB | - | $0.002 |
| Spotランナー2台 | c6g.4xlarge 約1.8時間、m7g.4xlarge 約1.8時間 |
約$0.8 | $0.68 |
| 合計 | 約$5.1 | $5.07 |
- 2つの実行が共有したAZ間転送・EBS・パブリックIPv4の約$0.65は、どちらの実行にも割り当てていません。
-
D1 DPUの推定が実際より低かったのは、ハーネスが最後に測定した後の使用量が含まれていなかったためです。
- ハーネスのコストガードは測定されていないA2区間を最大32 ACUで計算して約$9.5と見積もり、そのためE006の再測定前にガードの上限を$14から$16に引き上げました。
- A2の費用の大部分は、リクエストがほとんどない間も最小4 ACUずつ稼働していたwriterとreaderから発生しました。DSQLは同じ時間にリクエストを処理した分のDPU（$0.34）だけが請求されました。
結論と限界
- 今回の急増幅では両サービスとも介入なしで失敗0件で、DSQLの遅延は負荷に関係なく一定でした。
- アイドル後の最初のリクエストでは、DSQLがすぐに応答した一方、0 ACUで停止したA2は再開が15秒の接続タイムアウトを超えました。
- 限界: 1回の実行、小規模データ、段階間に途切れがある急増負荷です。急増幅が容量限界より小さく、固定容量の対照群（R1・A1）やアイドル区間の費用比較は行っていません。
後片付けの記録
- 実行Bで作成したリソース: BATCH（VPC、サブネット2個、IGW、セキュリティグループ2個、DBサブネットグループ、ランナーのIAMロール・インスタンスプロファイル）、D1 DSQLクラスター、A2クラスターとwriter・reader、RDS管理シークレット、Spotランナー2台（D1
c6g.4xlarge、A2m7g.4xlarge）。E007でAWS Backupボールト、バックアップサービスロール、復旧ポイント2個、復元したDSQLクラスター1個、ポイントインタイム復元したA2クラスターとインスタンスを追加で作成しました。 - 削除: バックアップボールトと復旧ポイント2個は09:35 UTCに、復元したDSQLクラスターとA2復元コピーは09:48 UTCから約10:05 UTCまでの間に所有タグを確認したうえで削除しました。残りは
e002.py batch-downで10:04–10:20 UTCに削除しました。削除に失敗したリソースはありません。 - 検証（10:20:27 UTC）:
e002.py verifyのremaining_count=0です。手動のクロスチェックで、AWS Backupボールト0個、この実行のプレフィックスを持つRDSクラスター・IAMロール0個、オープンなSpotリクエスト0個を確認しました。この時点で残っていたDSQLクラスター1個は、同時に実行中だった実行A（E002・E003・E008・E012）のものです。