Aurora Serverless v2とAurora Provisionedのコスト比較　3つの変数を“羅針盤”に優位境界面を探る

熊谷氏の自己紹介と、本セッションの概要

熊谷圭遵氏：それでは「Aurora Serverless v2　コスト戦略の羅針盤」という題で、DeNA熊谷よりお話しします。よろしくお願いします。

最初に自己紹介です。社内ではk-junというハンドルネームでやっています。入社は2020年度の新卒になるので、社会人3年目ということになります。職種はインフラエンジニアに従事していて、大規模のゲームのインフラを見るような仕事をしています。趣味はウクレレとかボードゲームなどが好きです。

はじめに、今回のプレゼンで話す内容を簡単に2点紹介します。1点目に、Aurora Serverless v2のACU増加速度検証についてアップデートがあるので、こちらを紹介します。2点目に、Aurora Serverless v2の導入検討のコスト面について紹介できればと思います。

目次です。4フェーズに分けてお話ししていければと思います。紹介、性能、コスト、最後に懸念点ですね。よろしくお願いいたします。

Aurora Serverless v2の仕組み

最初にAurora Serverless v2について簡単に説明します。Aurora Serverless v2は、正式名称を「Amazon Aurora Serverless v2」と言います。ちょっと長いので、今回のプレゼンの中ではAurora Serverless v2と記載しています。また、僕が説明する際に「Serverless v2」といったような、さらに省略する表記を用いることもあります。

Aurora Serverless v2をキュッと1文にまとめて説明すると、「Amazon Aurora用のオンデマンドなオートスケーリング設定」です。（スライドを示して）これが何かというと、いわゆる一般的なAmazon Auroraにはインスタンスクラスなるものがあります。図の左側のAurora Provisionedという枠内に書かれたdb..large、db..xlargeみたいに、インスタンスクラスに応じてスペックが付随しています。

ですが、これでは柔軟にインスタンスがスケールしないので、これをスケールできるようにしたのがAurora Serverless v2と呼ばれるものになります。

Aurora Serverless v2、v2があるならv1はどうだというところですが、Aurora Serverless v2はv1からのスペックの柔軟な変更を受け継ぎつつ、さらに改善を加え、かつAmazon Auroraとの機能とも合わせた、いわゆる2つのあいのことも取れるハイブリッドサービスとなっています。

次に、Aurora Serverless v2の仕組みです。今回、Aurora Serverless v2を説明するにあたって、2点ほど事前に説明しておきたい用語があります。1点目がdb.serverlessといわれるAurora Serverless v2のDBインスタンスクラスです。

Auroraクラスタと言われる既存のクラスタの中にdb.serverlessといったようなインスタンスクラスが書かれている際、それはイコールAurora Serverless v2ということになります。

次に、Aurora Capacity Units（ACU）といわれるserverless v2のスケーリング単位です。このACUにしたがってAurora Serverless v2にスペックが付与されるので、この値が高ければ高いほど、強いスペックを持っているAurora Serverless v2のインスタンスということになります。

AuroraクラスタにはMin ACU、Max ACUといったような、ACUに関する設定が2点ほど設定可能になっています。（スライドを示して）図の左側の状態だと、まったく負荷がない状態であれば、Min ACU4に従った4ACUを付与されたdb.serverlessのインスタンスができてくるかたちになります。

これを右に移行するようにMin ACUを1に下げた場合、負荷がまったくない状態を想定しているので、ACUは1まで下がってしまう。この際、クラスタ内にすでに組み込まれていたdv.r5.xlargeなどの他のインスタンスクラスには影響はありません。

Aurora Serverless v2の性能

次に2点目、Aurora Serverless v2の性能です。こちらは2022年6月16日にDeNAエンジニアブログにて、ACU増加速度検証を僕のほうで（実施し、その記事を）公開しています。「新サービスAurora Serverless v2の検証とその評価」という題で公開しているので、気になる方はご覧ください。

やった内容を簡単に説明すると、Launcherと呼ばれるちょっと強めのEC2インスタンスを作って、Aurora Serverless v2のインスタンスを3つほど用意して、異なるデータを突っ込みます。そこに対してLauncherからsysbenchを実行してみて、ACUの増加速度を調べるといった検証になっています。

ブログはけっこうがんばって7,000字ぐらい書いたのですが、要点を絞ってまとめてしまうと30字ぐらいになります。簡単な要点は2点ですね。アクセスがまったくない状態、いわゆる無風状態から、ACU増加速度が5〜15秒ほど無反応（になる）期間がありました。もう1点、ACU増加速度。増加はだいたい2段階に分かれていて、1秒で5〜7ほど増加する急激なACUと、ACUごとに0.05〜0.15増加する緩やかな増加速度の2段階になっていました。

こちらは前の発表から9ヶ月ほど経っているので、何か差分があるのではとまったく同じ条件で検証してみたところ、1点だけアップデートがありました。無風状態からのACU増加速度が5〜15秒だったものが、3〜4秒に改善していました。

これらはまさしくマネージドサービスを使う恩恵であり、知らないうちにこのように改善が行われていることはとてもすばらしいなと感じてます。

Aurora Serverless v2の導入でコストメリットは得られるのか

次に3点目、Aurora Serverless v2のコスト。今回のメインでお話ししたいところです。Aurora Serverless v2のコスト、要するに導入したらコストメリットは得られるのかどうかというところです。これと切っても切り離せないのがAurora Provisionedとのコスト比較ですね。最初に結論をお話ししてしまいますが、Aurora Serverless v2のコストメリットはケース・バイ・ケースなのが正直なところです。

（スライドを示して）これはどういうことかというと、図に記載されたように、db.serverless は ACU が柔軟に変化する関係上、ACU が大きければその分お金がかかります。結果、コストが掛かりすぎるという状況になるかもしれません。逆に、ACU が小さい状態を維持できれば、その分コストは減額します。これに対して、r5.xlarge は 一定のコストが常に掛かり続けます。このため、この２つを単純に比較することは出来ません。

このケース・バイ・ケースと言われるところに今回の題になっている「コスト戦略の羅針盤」を適用して、Aurora Serverless v2のコスト優位境界面のようなものを考えてみたいというのが今回の主題になります。

コスト優位境界面がわかれば、Serverless v2優位であればServerless v2を使えばいいし、Aurora Provisionedが優位であればAurora Provisionedを使えばいいといった、単純明快な基準ができてくるわけですね。

Aurora Serverless v2とAurora Provisioneのコスト比較

コスト優位境界面を設定するにあたり、まずはベースとしてAurora ProvisioneがどれぐらいAurora Serverless v2と比べて安いのか、Serverless v2がどれだけ高いのかを考えてみます。

比較に伴ってスペックは揃えなければいけないので、db.r5.2xlargeをまず持ってきます。これと同じスペックであるdb.serverless（32ACU）を持ってきて、それぞれの月額コスト比較を出してみると、東京リージョンであればAurora Serverless v2（32ACU）のほうがだいたい4.6倍高額。us-east-1、いわゆるバージニア北部であればServerless v2のほうが3.3倍高額であることになります。

この4.6、3.3という数字だけを見ても、「同じスペックなのにこれだけコスト差があるなんて、Serverless v2を使うメリットはないじゃん」といったような印象を持つかと思います。もう本当にそうだと思いますね。

このままだとまったく高くて使えないので、「じゃあServerless v2のコスト的なメリットはどこにあるんだ」となります。そうなると、やはりオンデマンドなスケーリングをできるのがServerless v2のメリットになるわけです。

このメリットは実際にどれぐらいメリットがあるのか、具体的な数字で落とし込んで考えてみるために右のようなグラフを考えてみます。（スライドを示して）右の図は縦軸がresource utilization、リソースの使用量です。横軸が時間で、黒い軸にしたがってリソースの使用量が変化するものとします。

db.r5.2xlargeでデータベースを構築したとしたら、常に100パーセントのリソースのコストがかかり続けるわけですね。needed resource、いわゆるリソース必要量が1日に25〜75で負荷変動する。これは簡単なsignカーブを使って描いています。最大75パーセントですが、スパイクに備えて25パーセントほど余剰を常に確保しているような状況を想定しています。

これをServerless v2に移行した場合にはどういったようなコストメリットが享受できるかというと、Serverless v2は余剰リソースがほぼ発生せず、リソースの必要量に追従するような変化をすることになります。

（スライドを示して）面積で話してしまえば、緑のラインがコスト削減領域に該当して、赤いところがServerless v2に移行した場合にコストが増加する領域といった扱いになるわけですね。

このように面積で定義ができると、計算ができるわけです。例えば東京リージョンであれば、全体の面積と赤い面積を4.6倍したものがそれより小さければServerless v2優位であり、バージニア北部であれば、この、4.6 という数字を 3.3 に入れ替えたものを満たすかが境界面になるわけです。

こういうふうに計算はできます。これはsignカーブを使ったものだし、実際にはこんなリソースの変化量にはならないので、もうちょっと単純にして考えてみようと（します）。

リソース変化量なんかは気にせず、もうちょっと話を簡単にして計算を可能にするため、2（つの）状態で理想化してみます。理想化する2つ、BusyとLazy、つまり最大リソース使用量と最小リソース使用量の2つを理想化してみます。

こういうふうに理想化をすると、変数が3つほど定義できるんですよ。この3つがoffpeak、loadgap、buffer。図中に記載されているようなラインですね。offpeakはいわゆるオフピークの時間的な割合。loadgapがBusyとLasyのパーセント的な負荷の差。bufferは100パーセントからどれだけ余剰を確保しているかという値になっています。

こういうふうに値を定義してあげると、カラーマッピングといって、おもしろいことができるんですよ。どうおもしろいかというと、グラフの説明を先にしますが、まずbufferは0.2で固定しましょうと。loadgapは0〜0.8。この0.8はloadgapとbufferを足した値が1を超えてはならないので、0.8までとなっています。

offpeakを0〜1で変化させて、それぞれの値の時にServerless v2、Aurora Provisionedのどちらのほうがコストメリットが出るかみたいなものをグラフにして出してあげる。（スライドを示して）そうすると、（このような）カラーマッピングになるわけですね。

縦軸がLなのでloadgap、横軸がOなのでoffpeakとしています。この2つの間、だいたい白い色で記載されているところが、コスト境界面になってくるわけです。ここまで定義してくると、実際にはExcelで作っているんですがけっこうおもしろくって。ポチポチいじれたりするんですよ。

例えばbufferを0にしてあげてloadgapを0から1にしてあげると、白いラインがより右上に寄ったりして。

さらにbufferを0.5にしてloadgapを0〜0.5にすると、より鋭角になったコスト境界面が現れる。けっこうおもしろいことができるわけですね。

話を本筋に戻して、bufferは0.2の状態、loadgapが0〜0.8の状態に持ってきました。この時にいわゆるコストメリットができるのが青いところなので、ここに着目するためにちょっと拡大して見てみましょう。

offpeakが0.7〜1、loadgapが0.49〜0.8のところだけ拡大してみました。

さらにoffpeakが0.79とかになるとあまり現実的ではないので、一番あり得そうなラインを持ってくると、offpeakが0.9、loadgapが0.7、bufferが0.2の状態になります。

こちら（の状態）になってくると、約18パーセントのコスト削減が可能な結果が得られます。つまり、先ほどのようなユースケースでAurora Serverless v2に移行すれば、約18パーセントコスト削減ができる。

この3つの変数の値だけ見てもあまり現実味が湧かないと思うので、グラフに直してみましょう。offpeakが0.9、loadgapが0.7、bufferが0.2です。グラフを作ってあげると、このようなリソース使用量であればServerless v2にコストメリットがある結果になります。

これはどういうことかというと、ピークの状態がoffpeakの8倍のリクエスト量であり、ピーク時間が144分間続くようなユースケースであれば、コストメリットが得られることになります。

これを踏まえて考えると、ログインサービスのソーシャルゲームだったり、締め切り間際のオークションサービスといったような特定の時間にリクエストが集中するようなサービスがやはりユースケースとして上がってくるんじゃないかと思います。

最後にコストのところのまとめです。再掲にはなりますが、Aurora Serverless v2のコストメリットはケース・バイ・ケースであることが多いです。ですが、offpeakやloadgap、bufferみたいな値を定義して、こ（れら）の羅針盤である程度判断をつけることはできます。

Aurora Serverless v2の懸念点

最後にAurora Serverless v2の懸念点です。ここまでいろいろとお話ししましたが、最後に懸念点を話して終わろうと思います。

先ほどAurora Serverless v2、Aurora Provisionedのコスト比較を行いましたが、Aurora Provisionedには切り札が、まだ何枚かあるわけです。そのうちの1つはAWS Graviton2と呼ばれるものです。Aurora Graviton2を搭載したdb.r6gと、これを搭載していない先ほど比較したdb.r5と比較すると、（db.r6gのほうが）性能・コスト共に優れたものになっています。

先ほどdb.r5は同スペックのServerless v2とQPSが同じものと仮定してコスト的な比較のみに終始しましたが、db.r6gはこの性能も上がっているので、「じゃあQPSもどれぐらい上がっているのか」という検証が必要になるわけです。この検証に応じてアルファ値をかけて、このアルファ値を加味した上でコスト比較を行う必要があるわけです。

このアルファ値を求めるために、性能検証を簡単にやってみました。インスタンスクラスはdb.serverlessの32ACUのもので、もちろんこの比較対象とするのはdb.r6g.2xlargeです。これもそれぞれ3台、レコード数は10の5乗、10の7乗、10の9乗の3つを2つずつ用意して、6パターンそれぞれに対して10回（実行するもの）なので、計60回sysbenchを実行してみて、そのQPSからアルファ値を求めてみました。

（スライドを示して）実際にどういうsysbenchのコマンドを実行したとか、変数の定義とかはこちらに載せています。ここで説明する気はありませんので、詳細を確認したい方はこちらを見てください。

得られた結果になります。ざっくりですが、QPSはdb.r6g.2xlargeがServerless v2の0.9〜1.27倍の性能が出ることが明らかになりました。平均をしてみるとアルファ値がだいたい1.20になっていて、1.2という結果になりました。r5.2xlargeよりもコストも下がっているので、コスト比も再計算してあげると東京リージョンで5.1倍、バージニア北部で3.7倍のコスト比率となりました。

（スライドを示して）このあたりで得られたアルファ値だったり、コストの倍率だったりを諸々を含めて計算するとこのようになります。カラーマッピングですね。pffpeakが0〜1、loadgapが0〜0.8、bufferは先ほどと変わらず0.2で比べてあげると、こんな感じになります。

（スライドを示して）一見、あまり変わらないように思いますが、先ほどと同様に右上を拡大してみてあげると、このようなかたちになります。先ほどのoffpeakが0.9、loadgapが0.7、bufferが0.2の状態に着目してあげると、コストメリットが得られたものが10パーセントのコスト増加、つまりServerless v2に変更したら10パーセントコストが増加する結果になっていて、明らかに悪化をしています。

厳しくはなっていきますが、でもまだそんなに変わらないので、先ほどのoffpeakとloadgapをより詰めればなんとかなるんじゃないかなと思えます。

先ほど見せたグラフの右上の、さらに4ブロックをもうちょっと値を細かく分割して見てみましょう。ここまで見てあげると、「0.7はだめでしたが、offpeakがだいたい0.9であれば（よい）。ちょっと上げればコストメリット出るじゃん」「あんまり変わらないじゃん」と思うわけですね。

ですが、Aurora Provisionedにはまだ伏兵というか隠し札というか。まだ手札が残っていて、Reserved Instanceというものがあるわけです。このReserved Instanceは、あらかじめ決められた使用量を1年か3年か前払いすることによって、コスト的なメリットが得られるものになります。

今回はdb.r6g.2xlargeを1年間前払いしたものとして、コストメリットを加味した上で計算をしてあげると、この結果はさらに悪化するわけですね。悪化するというのは、Serverless v2にとっては厳しいコスト計算結果となるわけです。

（スライドを示して）これは先ほど同様値を細かくしていったところを拡大していますが、これを見てあげるとけっこう厳しくて。先ほど左下にちょっと出ていた赤い潮みたいなものがより寄ってきて、真ん中ぐらいに境界が出てくるわけですね。

（スライドを示して）この縦と横の比率も今のままだとoffpeakの値、loadgapの値でちょっとわかりにくいので、現実に引き戻すために、ピーク時間の分数が横軸でoffpeakとピークのリクエストの差を比較してあげると、こういった結果になります。

これを右から2つ目の29分のラインで見てあげると、だいたい10〜13倍とか。11倍のコスト比差でないとコストメリットが出ないような結果になります。ここまで見てくると、かなり厳しいとわかると思います。けっこう絞られたユースケースにしかコストメリットが出ないんじゃないかなと思います。

終わりに、2点ほど要点として述べます。Aurora Serverless v2のACU無反応期間が、5〜15秒から3〜4秒に短縮しました。こういった改善はまさしくマネージドサービスの恩恵によるもので、昨年の6月の検証から70パーセントほど短縮しています。このようにいろいろな改善が加えられると、利用者としても非常にうれしいですね。

もう1点、Aurora Serverless v2コスト削減はかなり厳しい結果になりました。先ほど比較をしてはみましたが、ほぼすべてのケースでdb.r6g系統に軍配が上がります。これはやはり5.1倍のベースコストが響いた結果ではないかなと思います。

なので、コスト削減のみを目的としてServerless v2を導入するのは難しいかなという結果になりました。とは言ってもやはりマネージドサービスなので、今後の価格改定に期待という結びに今回はさせていただきます。

ご清聴ありがとうございました。