Amazon Aurora Serverless V2のスケーリング能力を試してみる

2022.4.28

こんにちは、NRIデジタルの島です。

AWSクラウドをベースにシステムを構築する際、データベースの一つの選択肢として「Amazon Aurora（以下Aurora）」があります。AuroraはWeb系、バッチ系問わずあらゆるシステムのユースケースに汎用的に利用できるマネージドなRDBMSサービスです。これまでオンプレミス上で稼働させていたMySQL等のRDBMSと同じように利用できる為、オンプレミスからクラウドへのデータベース移行もスムーズに行えます。
そのAuroraについて、先日ついに「Amazon Aurora Serverless V2（以下 Serverless V2）」がGAされました。

Amazon Aurora Serverless v2 is generally available

Serverless V2は、後述する「Amazon Aurora Serverless V1（以下 Serverless V1）」と比べスケーリング能力が格段にアップしたようですので、早速そのスケーリング能力を試してみました。

Auroraの課題

既存Auroraは可用性も高く、非常に優れたマネージドなRDBMSサービスですが、スケールという観点で見ると、ストレージのオートスケールはされますが、コンピューティングレイヤーのオートスケールには未対応です。その為、ワークロードに応じた最適なコンピューティング環境（サーバスペックや台数）の調整やコスト最適化の実現は難しく、繁忙時間帯のワークロードに必要なコンピューティング環境に固定化する必要があります。
※繁忙時間帯だけスケールすることは工夫すれば出来ないことはありませんが、あまり現実的ではありません。
この課題を解決する選択肢として2018年にGAされたのが「Serverless V1」です。
Amazon Aurora Serverless v1 の使用 – Amazon Aurora

しかしながら、Serverless V1にはスケーリングの仕組みに課題があり、使用頻度が低い小規模なワークロード環境にしか採用できませんでした。

Serverless V1とV2

Serverless V1とV2の差異は下記ページを見るとわかりやすいです。
Amazon Aurora Serverless

執筆時点では、上記ページのServerless V2がまだ「プレビュー」となってますが、前述の通り既にGAされております。

上記ページに記載されてますが、Serverless V1が小規模なブログサイト等をターゲットにしているのに対して、Serverless V2はよりエンタープライズなアプリケーションにおけるデータベースワークロードもサポート可能になっています。

以下引用です。

Serverless V1

使用頻度が低い、断続的、または予測不能なワークロード向けのシンプルでコスト効率の良いオプションです

Serverless V2

開発およびテスト環境、ウェブサイト、使用頻度が低い、断続的、または予測不能なワークロードを有するアプリケーションから、大規模で高可用性を必要とする最も要求の厳しいビジネスクリティカルなアプリケーションまで、あらゆる態様のデータベースワークロードをサポートします

具体的には、以下2点が主な改善点となります。

①スケーリング能力の向上
数百から数十万のトランザクションまで、ほんの一瞬（1秒未満）で瞬時にスケール可能

②可用性の向上
マルチAZ、グローバルデータベース、リードレプリカ等Auroraの幅広い機能に対応
※Serverless V1では未対応

アーキテクチャ

Serverless V1もV2もユーザがインスタンスをプロビジョニングする必要はなく、ワークロードに応じたAurora Capacity Unit(ACU) に基づいてスケールします。
※1ACU=メモリ2GBとそれに対応する CPU とネットワーク

しかしながら、Serverless V1とV2の大きな違いはスケーリング（つまり容量拡張）の実現方法にあります。

Serverless V1は下図の通り、インスタンスのウォームプールを使用して、ACUの要求に基づいてインスタンスをプロビジョニングします。具体的にはスケールアップの際に上位のインスタンスへの入れ替えが行われます。その為、インスタンススペックを倍増する形でACU数をスケールアップ（e.g. 1ACU→2ACU→4ACU→8ACU・・・)するような動きになります。

※「Aurora Serverless v1 の仕組み」より引用

この実現方法のデメリットは以下が考えられます。

スケーリングがトリガーされてからのスケーリング遅い
ワークロードに見合ったリソースにならない（コスト効率低）
キャッシュヒット率等が一時的に悪化する

また、Serverless V1のスケーリングポイント（特定の閾値（最大接続数やCPU使用率等）を超えたかどうかの判定）は最小「1分」となっている為、そもそもスケーリングがトリガーされるまでが遅いという課題もあります。

一方Serverless V2はスケーリング時にインスタンススペックを倍増させるのではなく、CPUとメモリ等のリソースを追加します。Serverless V1のような入れ替え方式ではない為、ディスクのアタッチ等のオーバヘッドもなく、メモリ情報（キャッシュ等）の引継ぎも不要です。

このアーキテクチャへの変更により、0.5ACU単位のきめ細かい単位での増減をミリ秒単位で実現することが可能です。

※「re:Invent 2020資料」より引用

スケーリング検証

では、Serverless V2がV1と比較してスケーリング能力にどのくらいの差があるのか試してみたので、その結果を共有させていただきたいと思います。
※Auroraの「MySQL 互換エディション」で検証しました。

負荷テストツール

MySQLの負荷エミュレーションクライアント「mysqlslap」を使用しました。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 4.5.7 mysqlslap — 負荷エミュレーションクライアント

シナリオ

以下のような設定で、Serverless V1、V2双方に対して負荷をかけました。

合計SQL実行数：3,000,000
実行SQL：mysqlslap自動生成
同時実行クライアント数：100～200

設定イメージ

mysqlslap \
--host={host} \
--port=3306 \
--user=coe_admin \
--engine=innodb \
--iterations=30 \
--concurrency=100 \
--auto-generate-sql \
--auto-generate-sql-add-autoincrement \
--auto-generate-sql-load-type=mixed \
--auto-generate-sql-write-number=1000 \
--number-of-queries=100000 \

キャパシティ（ACU）設定

Serverless V1、V2それぞれのACU設定を以下の通り設定しました。

Serverless V1

最小0 – 最大64（設定可能な最大値は「256ACU」）
※スケーリングタイミングは「1分且つ強制」で設定（最も早くスケールする設定）

Serverless V2

最小0.5 – 最大64（設定可能な最大値は「128ACU」）

執筆時点では、最小「0」は設定不可のようです。

結果

以下が上記シナリオを複数回、並列度を変えながら実行した結果となります。
※折れ線の青が「Serverless V1」、緑が「Serverless V2」となります。

CloudWatchダッシュボード

①スケールアップ

Serverless V1は、前述した仕様通りACU数を倍増するようにスケールしています。
初動含めスケールアップ自体が遅く、Serverless V2と比べると増加するACU数も圧倒的に少ないです。
また、ツール実行中以下のようなコネクションエラーも多数発生しておりました。

ERROR : Lost connection to MySQL server during query

一方Serverless V2は、負荷をかけ始めたタイミングで瞬時にスケールが開始され、あっという間に必要なACU数に到達しています。
※わかりにくいですが、必要数に達した付近でこまめにACU数の調整しているところもポイントです
また、Serverless V1で発生したコネクションエラー等の発生もなく、CPU使用率も安定しております。

②スケールダウン

Serverless V1は、トラフィック完了後最小数までダイレクトにスケールダウンしています。
一方Serverless V2は、段階的にゆっくりスケールダウンしています。

スケールダウンが早すぎると、追加のワークロード発生時に再スケールアップのオーバヘッドが大きくなることや、急なバッファープール減少による大幅なキャッシュヒット率の低下など、パフォーマンスへ影響を与える可能性があります。
このあたりの全体的なパフォーマンス効率を考慮し、Serverless V2はゆっくりと段階的にスケールダウンする方式を採用しているのではないかと思います。

③キャッシュヒット率

Serverless V1は一時的にキャッシュがクリアされているような状態になっています。

Serverless V2でも一時的に悪化はしてますが、V1のような顕著な状態にはなっておりません。
これは、前述したスケーリングアーキテクチャの差異によるものだと考えられます。
高いキャッシュヒット率を維持する必要があるシステムにおいては重要なポイントになると思います。

以上、Serverless V1とV2の比較検証結果を共有させていただきました。
結果の通り、スケーリングアジリティにおいても安定性においてもかなりの改善がされたと言えるのではないでしょうか。

コスト

コストについても触れておきます。

下記ページに記載の通り、1ACU（米国東部 (バージニア北部)）あたり、Serverless V1が「0.06USD/ACU 時間」なのに対してServerless V2が「0.12USD/ACU 時間」と割高になっております。
https://aws.amazon.com/jp/rds/aurora/pricing/

執筆時点では上記ページはまだ「Serverless V2（プレビュー）の米国東部 (バージニア北部)）」についての料金しか記載されておりません。近々更新されると思われます。

しかしながら、単価は高くても、ワークロードに応じて0.5ACU単位で最適なキャパシティ調整ができる分、コスト的にもServerless V2のほうがアドバンテージが出てくるのではないか、と思っております。
（Serverless V1は前述の通りインスタンス入れ替えでの調整となる為、余分なリソースを確保している時間が多くなる）

下記ページでも、「データベースコストを最大 90% 節約できます」と記載されております。
（再掲）Amazon Aurora Serverless

さいごに

通常のRDSやAuroraは利用していなくても起動しているだけでコストがかかり、スケーリングにも対応していない為、コスト効率が非常に悪く頭を悩ませている方々も多いのではないでしょうか？
これまでは、本番環境以外の環境ではServerless V1を利用する選択肢もありましたが、本番環境と同一構成の環境（準商用環境など）は少なくとも用意しなければなりませんし、環境毎に構成が違うのは避けたいところでした。

Serverless V2はスケーリング性能、可用性も優秀な為、ミッションクリティカルなエンタープライズアプリケーションのユースケースでも利用でき、コスト効率も非常に良く、今後のデータベース環境選択の最有力候補になってくると思います。

GAされたので、本番適用に向けた追加の検証作業などに早速取り組んでまいりたいと思います。

以上