こんにちは！IT基盤部の k-jun です。IT基盤部にて大規模ゲームのインフラを見ているインフラエンジニアです。この記事では、2022/04/21 に GA となった AWS の新サービス Aurora Serverless v2 に対して行った技術検証とその調査結果をご紹介させて頂きます。

Aurora Serverless v2 とは

Aurora Serverless v2 は Amazon Aurora のオンデマンドなオートスケーリング設定であり、その実態は Amazon Aurora に追加された新インスタンスクラスです。Aurora Serverless v2 は あらかじめ決められたスペックを持たず、ACU(Aurora Capacity Unit) という値に従ってスケールダウン・スケールアップします。また、この ACU は ２つのプロパティ( Min ACU / Max ACU )によって変化域を設定でき、利用者側からのある程度のコントロールも可能としています。

他にも前世代の Aurora Serverless v1 からの改善や、Amazon Aurora の機能が踏襲されており、Aurora Serverless v2 はまさにこの２つのハイブリッドとも言える素晴らしいサービスです。

Aurora Serverless v2 のニーズ

我々は Aurora Serverless v2 の登場を首を長くして待ち望んでいました。Aurora Serverless v2 の持つ特性が、我々の “ツラミ” を或いは改善してくれることを期待しているためです。 以前の記事 でも書かせていただきましたが、この “ツラミ” は大きく２つ、運用とコストに分けられます。

運用面の “ツラミ” はスペック変更によって発生する作業工数の多さです。我々のスペック変更作業は、短期間のスペックアップと中長期的なスペックダウンという２種類の作業に分けられます。いずれの作業もフェイルオーバーを伴う危険な作業であり、我々の作業工数を圧迫しています。

コスト面の “ツラミ” はやはり Amazon Aurora の単価の高さです。Amazon Aurora はデータベースとしての性能も高く、レプリケーション・フェイルオーバー・バックアップなどがマネージド側で行える素晴らしいサービスです。反面価格は高額であると言わざるをえず、インフラコスト全体のかなりの割合を占めています。

これが我々のデータベースが抱える “ツラミ” です。Aurora Serverless v2 は ACU によるオートスケーリングとコスト削減効果によってこれらの “ツラミ” を解消する可能性を秘めています。このため早急に導入へこぎつけるべく、Aurora Serverless v2 に対して技術検証を行いました。

Aurora Serverless v2 の性能検証①

目的 in 性能検証①

本検証は主に、Aurora Serverless v2 の性能面と品質面を明らかにすることです。改善が望まれているのは運用とコストではありますが、性能・品質無くしてこの２つは成り立ちません。導入を見据えた技術検証としては避けて通るわけにも行かず、今回はこの２つに絞って検証することとなりました。

具体的な検証の目的としては以下の問を設定しました。今回はこの内、Aurora Serverless v2 の負荷に対する挙動の技術検証と調査結果を記載させて頂くことになりました。そして「これらの謎を解明するため我々エンジニアは Amazon の奥地へ向かった」というわけです。

• Aurora Serverless v2 は どんな負荷に対して、どのような挙動を示すのか
• Aurora Serverless v2 は Aurora Provisioned と同程度の可用性を担保しているのか

手法 in 性能検証①

検証手法は AWS 上に Aurora Serverless v2 を構築、EC2 上のインスタンスから sysbench のテストケース oltp_read_write を実行。sysbench と CloudWatch から得られた、QPS・ACU・CPU の推移を結果として回収・記録するものとしました。また、様々な条件下の結果とするべく、Min ACU・Max ACU、加えて Aurora Serverless v2 に投入するデータ量を変更しながら全 18 通りの検証を行いました。

まずは AWS 上に検証環境を構築します。Launcher は sysbench 発射台の EC2 インスタンスです。異なるレコード数を投入するため、Aurora Serverless v2 は３台構築しました。各コンポーネントの詳細設定は以下の表にまとめています。

次に Aurora Serverless v2 へのデータ投入です。MySQL Client でデータベースの作成、sysbench でスキーマの作成とレコード挿入を行っています。

# create database
$ mysql -h $MYSQL_HOSTNAME -u $MYSQL_USERNAME --password=$MYSQL_PASSWORD -e "CREATE DATABASE $MYSQL_DATABASE;"
# prepare testcase
$ sysbench --mysql-host=$MYSQL_HOSTNAME --mysql-user=$MYSQL_USERNAME --mysql-password=$MYSQL_PASSWORD --mysql-db=$MYSQL_DATABASE --db-driver=mysql --tables=$TABLES --table-size=$TABLE_SIZE oltp_common prepare

コマンド中の変数は以下の表に記載しました。前述の通り３台の Aurora Serverless v2 にはそれぞれ異なった TABLE_SIZE の値を代入しています。なお、MYSQL_HOSTNAME、MYSQL_USERNAME、MYSQL_PASSWORD は省略しました。

最後に sysbench で負荷を掛けます。Min ACU・Max ACU の設定値が ACU の推移に与える影響を調査するべく、表の通り６パターンの Min ACU・Max ACU の組み合わせを用意しました。ACU が Min ACU になっていることを確認してから sysbench を実行して負荷を与え、継続時間は５分間としています。

# run testcase
$ sysbench --mysql-host=$MYSQL_HOSTNAME --mysql-user=$MYSQL_USERNAME --mysql-password=$MYSQL_PASSWORD --mysql-db=$MYSQL_DATABASE --db-driver=mysql --tables=$TABLES --table-size=$TABLE_SIZE --threads=$THREADS --report-interval=1 --time=$TIME --db-ps-mode=disable $TESTCASE run >> `date '+%Y-%m-%d'`.log && date '+%Y-%m-%dT%H:%M:%SZ' -d "$TIME seconds ago"

コマンド中の変数は以下の表に記載しました。THREADS は Min ACU に 16 を掛けた値を採用しています。これは Min ACU の４倍の ACU で最も QPS が出るスレッド数であり、最も Aurora Serverless v2 のスケール速度が出るであろうと自分が推測した値になります。

結果 in 性能検証①

検証結果をグラフにまとめました。各通りそれぞれ ACU と QPS、ACU と CPU の２つ、合計 36 個のグラフを作成しています。

なお Aurora Serverless v2 の CPUUtilization メトリクスの見方には多少の癖があります。グラフ上の CPU 使用率の値は ACU が Max ACU の際に割り振られる CPU 量を分母としており、現 ACU に割り振られている CPU 量ではありません。よって現 ACU が 4、Max ACU が 16 の場合、CPU 使用率は理論上最大 25% となります。

cluster-105

4-16	4-128	8-32	8-128	16-64	16-128

cluster-107

4-16	4-128	8-32	8-128	16-64	16-128

cluster-109

4-16	4-128	8-32	8-128	16-64	16-128

真っ先に目に付くのは ACU の推移です。検証前は、ACU が上がるほどに遅くスケールする対数関数的なグラフを予想していました。しかし、実際の ACU の推移は以下３つのポイントを持つ何とも形容し難い形になっています。この３つのポイントは考察パートで詳細に検討していきます。

• 負荷を与え始めてから最初の ACU 変化まで、数秒の ACU 無反応期間がある。
• 負荷を与え始めてから最初の ACU 変化の上昇値は、１秒で数 ACU との急激なものである。
• 最初の ACU 変化を除いた上昇値は、十数秒に１程度の緩やかなものである。

QPS は大枠として ACU に比例した値を見せるものの、データ量によってかなり差が出る結果となりました。$10^7$ のデータ量が最も高い QPS を記録しており、16-64 のテストケースで $10^5$、$10^9$ と比較するとその最大値の差は 2-2.5 倍にもなります。Performance Insight にて待機イベントを確認したところ、$10^5$ では row_lock_wait が、$10^9$ では index_tree_rw_lock が多く発生しており、その分 QPS が下がったと考えられます。

CPU は割り当て量をほとんど使い切っています。ACU の値から計算した CPU 割り当て量を分母とした場合、sysbench の実行後 1-3 秒でその CPU 使用率は 95% 以上にもなります。急激な ACU スケール直後も即座に CPU 使用率が増えた分だけ消費されており、sysbench は Aurora Serverless v2 に十分な負荷を与えていることが分かります。

考察 in 性能検証①

検証結果より ACU の推移について詳細に考察していきます。３つのポイントを元に以下の評価値を作成しました。

• X 値 - 負荷を与え始めてから、最初の ACU 変化までの秒数
• Y 値 - 負荷を与え始めてから、最初の ACU 変化の上昇値
• Z 値 - 最初の ACU 変化の上昇値を除いた、ACU の増加速度

全 18 通りのテストケースにおける X、Y、Z 値を表にまとめました。

※ Y 値に相当する大きな ACU の増加以前に 0.5 程度の小さな ACU 変動が現れたもの。

X 値は Min ACU・Max ACU、データ量と関係性が見えず、平均値(* を除く)を取ると 11.25 にもなります。これは複数のワークロードにて Aurora Serverless v2 のスケール開始がこの秒数遅れることを示唆しており、特に本番環境では好ましくありません。また、AWS の Aurora Serverless v2 紹介ページには “Aurora Serverless v2 は瞬時にスケールする” という旨の記載がありますが、この秒数はとても “瞬時(in a fraction of a second)” とは言えません。(2022-06-08 時点)

Amazon Aurora Serverless v2 scales instantly to hundreds of thousands of transactions in a fraction of a second. As it scales, it adjusts capacity in fine-grained increments to provide the right amount of database resources that the application needs. There is no database capacity for you to manage. You pay only for the capacity your application consumes, and you can save up to 90% of your database cost compared to the cost of provisioning capacity for peak load.

https://aws.amazon.com/rds/aurora/serverless/

CPU 使用率も前述の通り、sysbench の実行後 1-3 秒で CPU 95% 以上に達しています。よって、最低でも数秒間は CPU が枯渇した状態が継続しており、ここで Aurora Serverless v2 がスケールアップしないのはあまりにも不自然です。違和感は残りますが、今回の条件下では Aurora Serverless v2 は 5-15 秒の ACU 無反応期間があるという結果を得ました。

Y 値の Min ACU・Max ACU、データ量との関連性も曖昧です。Min ACU と Y 値の間に相関が無くも無いという程度でしょうか。全 18 通り中、17 通りが 5-7 の範囲に収まっており、負荷の絶対量には差があるものの同程度の ACU 上昇量となっています。他のテストケース・ツールではどうなるのかという懸念は残りますが、今回の条件下では Aurora Serverless v2 はスパイク直後にその ACU を 5-7 増加させました。

Z 値は Min ACU とのある程度の相関が確認できます。それぞれの Min ACU で平均値を取ると、Min ACU 4 では 0.38、Min ACU 8 では、0.44、Min ACU 16 では 0.52 となり、徐々に上昇しています。また、AWS のドキュメントには現 ACU が高ければ高いほど、スケールの速度が早くなるという旨の記載があります。(2022-06-08 時点)

The scaling rate for an Aurora Serverless v2 DB instance depends on its current capacity. The higher the current capacity, the faster it can scale up. If you need the DB instance to quickly scale up to a very high capacity, consider setting the minimum capacity to a value where the scaling rate meets your requirement.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min_capacity_considerations

今回の結果はこの記載とも矛盾がありません。別のワークロードではより早くスケールするのではという期待はあるものの、今回の条件下ではその速度は 0.03-0.06 つまり 16-33 秒に１ACUという上昇速度でした。

結論 in 性能検証①

今回の性能検証の結果、得た結論は以下の２点です。

• Aurora Serverless v2 はスパイクによるスケール開始前、5-15 秒の ACU 無反応期間が存在する。
• Aurora Serverless v2 はスパイクによるスケール開始後、ACU を２段階に分けてスケールさせる。１段階目は、１秒間のみの 5−7 の急激な ACU 増加。2段階目は、時間無制限の 16-33 秒に１ACU の緩やかな ACU 増加である。

さて、ここまで Aurora Serverless v2 の性能を調査してきました。しかし、上記の結論は検証の余地を残した箇所が多く存在します。具体的には X 値の “違和感” や、Y の “懸念”、Z 値の “期待” です。これらの疑問点を解消し上記の結論をより確実なものにするべく、追加調査を２件行いました。

Aurora Serverless v2 の性能検証②

目的 in 性能検証②

１つ目の追加調査は X 値についてです。先程の性能検証では、Aurora Serverless v2 のスケールまでには数秒の時間が必要なことが分かりました。が、全く負荷がかかっていない状態から大量のリクエストを送っており、アプリケーションの挙動を完全再現しているとは言えません。よって、より実践的な負荷試験とするべく、Aurora Serverless v2 への負荷を２段階に分けることにしました。1段階目は “背景負荷” とも言うべき、弱めの負荷。２段階目は “スパイク” の今まで通りの強めの負荷です。これが１つ目の追加検証の目的です。

２つ目の追加検証は Y、Z 値に関してです。先の性能検証より、Aurora Serverless v2 が変則的な ACU 増加を行うことは分かりました。しかし、得られた結果が Aurora Serverless v2 の限界性能かと問われると疑問が残ります。そこで、より確実に Aurora Serverless v2 の性能を引き出すべく、強制的に ACU を増加させスケール速度を計測することにしました。これが２つ目の追加検証の目的です。

手法 in 性能検証②

まずは１つ目の検証手法です。“背景負荷” のデータ投入・負荷のかけ方を記載していきます。なお、検証環境と “スパイク” のデータ投入・負荷のかけ方はそのままのため、省略しています。

“背景負荷” のデータ投入コマンドも “スパイク” と全く同じもののため、コマンド中で利用する変数のみ記載しています。データベース名は２つの負荷間での干渉を避けるべく別のものを。データ量は雑に $10^5$ としています。

“背景負荷” の負荷のかけ方は、“スパイク” から少し変更を加えました。--rate オプションを追加し、秒あたりのトランザクション数を 10 に制限しています。スレッド数は８、時間は適当に１日としています。事前に３台の Aurora Serverless v2 へそれぞれ実行しておき、ACU が落ち着いたことを確認してから、“スパイク” の負荷を開始しています。なお、“背景負荷” の QPS は 100-200 程度でした。

# run testcase
$ sysbench --mysql-host=$MYSQL_HOSTNAME --mysql-user=$MYSQL_USERNAME --mysql-password=$MYSQL_PASSWORD --mysql-db=$MYSQL_DATABASE --db-driver=mysql --tables=$TABLES --table-size=$TABLE_SIZE --threads=$THREADS --report-interval=1 --time=$TIME --rate=$RATE $TESTCASE run >> `date '+%Y-%m-%d'`.log && date '+%Y-%m-%dT%H:%M:%SZ' -d "$TIME seconds ago"

次に２つ目の検証手法です。こちらは、今までと比較するとかなりシンプルな検証になります。３台の Aurora Serverless v2 の Min ACU を指定の値にしておき、ACU が Min ACU と一致するまで待機。その後 Min ACU を 128 まで引き上げ、ACU が強制的に変化する様子を 30 分間追跡しました。３台それぞれに以下の３通りを実施し、合計９回分のデータを収集しています。

結果 in 性能検証②

検証結果をそれぞれグラフにまとめました。性能検証① と同様に 36 個のグラフと、強制的な ACU の変化を追った４つのグラフです。

cluster-105

4-16	4-128	8-32	8-128	16-64	16-128

cluster-107

4-16	4-128	8-32	8-128	16-64	16-128

cluster-109

4-16	4-128	8-32	8-128	16-64	16-128

force scaling

4-128	8-128	16-128	30min

１つ目の追加検証の X 値には、明らかな違いが現れました。性能検証①で現れていた序盤の ACU 無反応期間が無くなり、ほぼ０秒からスケールするようになりました。この速度感であれば、“瞬時” にスケールするという表現も納得がいきます。僅かではありますが ACU の最終到達点も高くなっており、Aurora Serverless v2 における “背景負荷” の効果が見て取れます。

次に、２つ目の追加検証の Y 値です。意外なことに Min ACU を変更したスケーリングでも Y 値に相当する急激な ACU の増加を確認することが出来ました。また、この変化量は性能検証①、１つ目の追加検証の変化量とほとんど一致しています。この点から、Aurora Serverless v2 は 強制・自動の区別なく同じ処理系によって ACU を計算しているという推察も立ちます。

２つ目の追加検証の Z 値も、興味深い遷移を示しています。グラフから分かる通り、性能検証① をわずかに上回るペースで ACU を増加させています。Min ACU 変更による強制 ACU スケールは、ACU 増加速度を最大にしない理由が思いつきません。sysbench による上昇量より僅かに早いという結果もこれを後押ししており、これが Aurora Serverless v2 の ACU 増加速度の限界性能であるという捉え方も出来ます。

また、蛇足ぎみではありますが、最後の９つの 30 分間 ACU を追跡したグラフからより高い ACU であれば、より速い速度で ACU がスケールすることの再確認もできました。

考察 in 性能検証②

性能検証① と同要に X、Y、Z 値を表にまとめました。

追加検証の X 値は、性能検証① から明らかに減少しています。その平均値は 約 1.4 であり、性能検証① から9 秒以上も短縮しています。検証の内容から判断して、唯一の差分である “背景負荷” が この秒数の差を引き起こしていると考えるのが妥当です。よって Aurora Serverless v2 は QPS 100-200 程度の負荷下であれば、1-2 秒程度でスケールを開始するという結果を得ました。

追加検証の Y 値は、性能検証① の変化域に沿う結果となりました。９つの Y 値は性能検証① の 5-7 の内部に全て収まっており、スパイクと Min ACU の変更どちらでも同じような結果となりました。AWS Console から Min ACU を変更した場合は、スケール開始までに 30-60 秒程度と sysbench より多少遅いですが変化量には一貫性を感じます。Aurora Serverless v2 はスパイク、Min ACU 変更、いずれの場合もその直後に 5-7 の ACU を増加させるという結果になりました。

追加検証の Z 値は、性能検証① よりも高い値を示しています。まずは、この結果が Y 値を除いた 30 分間 の ACU の変化から算出されている値であることを明記しておかなければなりません。従って、ACU が高い状態を多く含んでいる追加検証では、Z 値が上昇するのは当然とも言えます。

結論 in 性能検証②

今回の性能検証の結果、最終的に得た結論は以下の２つです。

• Aurora Serverless v2 はスパイクによるスケール開始前、1-2 秒の ACU 無反応期間が存在する。が、Aurora Serverless v2 に全く負荷が発生していない状態ではこの限りではなく、より長い 5-15 秒の ACU 無反応期間となる。
• Aurora Serverless v2 はスパイク、及び Min ACU の変更によるスケール開始後、ACU を２段階に分けてスケールさせる。１段階目は、１秒間のみの 5-7 の急激な ACU 増加。2段階目は、現 ACU によって速度の異なる緩やかな ACU 増加である。

参考までに、ACU 増加速度を区間ごとにまとめた表を作成しました。２つ目の追加検証の結果９回分を元に、その平均値を記載しています。

あとがき

本記事では Aurora Serverless v2 導入の前段階として実施した技術検証をご紹介しました。本検証の目的は Aurora Serverless v2 の性能を可能な限り明らかにすることではありますが、Aurora Serverless v2 は GA したばかりであり、その全てを語るのは早計です。数年後に Aurora Serverless v2 の挙動が全く異なるという可能性も否定できません。

また、本検証は１個人が試験環境・試験条件を設定し実施したものであり、見方によっては考慮漏れ、未熟な点が随所に存在していることも承知しています。異なる結果、矛盾する点などございましたら、SNS などで読者のみなさんと議論ができれば嬉しいなと思っております。

我々 DeNA は技術により難題を解決し利用者に Delight を届けるべく、新技術に絶えず挑戦し続けています。

おわりに

私たちは、DeNA グループ全体のシステム基盤を横断して管理しているインフラ部門に所属しています。こちらでチームの紹介をしていますので、ぜひご覧ください。