Aurora DSQL vs Serverless v2:実測で見るコストの真実

まずはAWSが公開している料金体系を確認し、両者をきちんと比較できるかを見ていきましょう。先に結論をお伝えすると、そのままでは比較できません。

Aurora DSQL

• コンピュート: Distributed Processing Unit(DPU)単位で課金

- 料金: 100万DPUあたり$8

- 10万DPU ≈ 約70万件のTPC-Cトランザクション(AWSベンチマークに基づく)

https://aws.amazon.com/rds/aurora/dsql/pricing/

• ストレージ: $0.33/GB-月
• 無料利用枠: 毎月最初の10万DPUと1GB-月のストレージは無料

では、DPUとは具体的に何なのでしょうか。ACUのときと同じで、実際にどれくらいの処理量に相当するのかを把握するのはほぼ不可能ですよね。

Aurora Serverless v2と比べてみましょう。

• コンピュート: Aurora Capacity Unit(ACU)単位で課金

- 料金: $0.12/ACU-時

- 0.5〜128 ACUの範囲でスケール、アイドル時は0までスケールダウン可能

• ストレージ: 2つの選択肢

- 標準: $0.10/GB-月 + $0.20/100万I/O

- I/O最適化: $0.225/GB-月、I/O料金は別途発生せず

まず分かるのは、Aurora Serverless v2とAurora DSQLでは課金体系そのものが異なるため、ストレージ以外は直接比較できないということです。ストレージはDSQLがI/O最適化版と比べてもおよそ50%高く、大容量ストレージかつ低トランザクションのシステムでは、そもそもDPUとは何かを考えるまでもなくDSQLのほうが必ず割高になります。続きで詳しく見ていきましょう。

DPUはAurora DSQLにおけるコンピュート課金の単位です。各DPUは、Auroraの高度に並列化されたクエリ実行エンジンで分散クエリを処理する際に使われるリソース量を表しています。CPU時間、メモリ使用量、そしてデータの取得・操作に必要な処理が含まれます。

DPUは小数単位の従量課金で、実際に消費したコンピュートリソース分のみが請求されます。この点は、毎秒0.5単位ずつプロビジョニングされるAurora Serverless v2のACUとは異なります。とはいえACUと同様、事前に使用量を正確に見積もるのはほぼ不可能で、実測してみるしかありません。

Aurora DSQLには、毎月以下の無料利用枠が用意されています。

• 10万DPUまで無料($0.80相当)
• 1GB-月のストレージ無料($0.33相当)

合計すると月額$1.13の節約です。本番環境では決定打にはなりませんが、無料の開発・検証用ワークロードにはぴったりでしょう。ただし、1 DPUがどれだけの処理量に相当するのか分からない以上、これが焼け石に水なのか、本番ワークロードを丸ごとカバーできるのかも判断できません。実際に数値を測ってみましょう。

今回はpgbenchを使い、現実に近いシナリオでデータベースに負荷をかけます。標準のpgbench TCP-Bベンチマークを用い、各データベースで10万トランザクションを実行しました。当初は60分間動かす予定でしたが、DSQLのスループットがASv2と比べてあまりにも低く、コスト分析の記事としては成立しないと判断しました。パフォーマンス面については最後に簡単に触れます。

ご自身で検証したい方のために、使用したpgbenchコマンドを以下に示します。楽観的ロックの仕組み(前回の記事を参照 — https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a)により、複数クライアントで実行するとDSQL側で競合エラーが多発し、両エンジンの公平な比較ができなくなるため、シングルクライアントで実行しています。

pgbench -n -p 60 -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$DB_NAME" -c 1 -j 2 -t "$NUMBER_OF_TRANSACTIONS"

あるいは、私が使用したスクリプトをそのまま利用することもできます( https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5)。ASv2のpgbench結果は以下のとおりです。

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 100000
number of transactions actually processed: 100000/100000
latency average = 4.835 ms
initial connection time = 16.942 ms
tps = 206.831172 (without initial connection time)

続いてDSQLの結果です。

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 100000
number of transactions actually processed: 100000/100000
latency average = 19.700 ms
initial connection time = 243.453 ms
tps = 50.760523 (without initial connection time)

このワークロードは、Aurora DSQLの課金インサイトで計測したところ8327 DPUを消費し、Aurora Serverless v2では0.48 ACUでした。冒頭で述べたとおり、両者を直接比較することはできません。

非常にシンプルな例ですが、ここから簡単な計算と前提を置けば、月額コストの概算を導き出せます。

では1ヶ月単位ではどうなるかを見ていきましょう。多くの仮定を置く必要がありますが、両者のコスト差をある程度イメージできるはずです。DSQLの心強い$1.13の無料利用枠もお忘れなく。

• 10万件のクエリを毎時実行(つまり今回のワークロードテストを毎時実行)— 720時間
• ピークや谷のないフラットなワークロード
• データベースストレージサイズ:10GB

1. コンピュート(DPU)

• 8327(pgbenchテストの実測値)× 720(月間時間)= 5,995,440 DPU

- 最初の10万DPUは無料

- 課金対象DPU:5,895,440

• コスト = 5,895,440/1,000,000 × $8 = $47.16

2. ストレージ

• 合計10GB — 無料枠1GB × $0.33 = $2.97

DSQL合計コスト:$47.16 + $2.97 = $50.13

1. コンピュート(ACU)

• 0.48(pgbenchテストの実測値)× 720(月間時間)= 345.6 ACU
• コスト = 345.6 × $0.12 = $41.47

2. ストレージ(I/O最適化)

• 10GB × $0.225 = $2.25

ASv2(I/O最適化)合計コスト:$41.47 + $2.25 = $43.72

• DSQL — $50.13
• ASv2 — $43.72

トランザクションあたりのコストとストレージのみで比較すると、ASv2はDSQLよりおよそ13%安価です。

とはいえ、現実にはコストだけで判断するわけにはいきません。パフォーマンスとのトレードオフも当然あります。残念ながら、DSQLはその点でも芳しくないのです……。

パフォーマンス面はあまり深掘りしません。本記事の主眼がコストにあることに加え、DSQLは他のどのデータベースとも振る舞いが大きく異なるため、同条件でのパフォーマンス比較自体が困難だからです。今回使ったpgbenchをはじめ、現行のベンチマークツールは楽観的ロックやリトライを前提にしておらず、高負荷をかけると失敗してしまいます。それでも今回の検証では、DSQLはASv2より4倍遅いという結果になりました。

pgbenchの秒間トランザクション数(tps)を見てみましょう。

• DSQL – 50.760523
• ASv2 — 206.831172

つまり、安くもなければ、明らかに遅い。となると……

Aurora DSQLが向いているケース

• 線形なパフォーマンスを伴う予測可能なスケーリングを求めている
• 多少の柔軟性を犠牲にしてでも強力な書き込みスケーラビリティを得たい
• 低レイテンシでのマルチリージョン書き込みが大きな価値を持ち、それに見合うコストを払う価値がある
• 毎秒数千件のトランザクションと接続を扱う大規模環境で、Aurora RDSがボトルネックになり始めている

Aurora Serverless v2が向いているケース

• バースト性または断続的なワークロードがある
• ACUによるスケーリングで自動的なコスト最適化を実現したい
• よりシンプルで柔軟なデプロイモデルを好む

端的に言えば、現時点でDSQLの採用を正当化するには、かなり特殊なユースケースが求められるということです。