負荷試験の勉強兼ねてAurora Serverlessを試してみました
負荷試験の勉強兼ねてAurora Serverlessを試してみました
これは12/18のゆめみAdvent Calenderの記事になります。
（要注）すみません。以前「v2を試してみた」というタイトルで本記事を公開していましたが、実際にはv1を試した状態でした。
v2（1/24現在プレビュー版）はAWSに申請して承認を得ないと使えないようです。現在申請していますので、改めて試せたら記事を挙げようと思います。
要約
Aurora Serverless v1を触ってみて、
特にオートスケール周りが非常に便利なサービスだと感じたためその紹介をさせて頂きます。
Aurora Serverlessとは
Amazon Aurora Serverless は、Amazon Aurora のオンデマンドの Auto Scaling 設定です。
とあるように、インスタンスタイプ他を管理せずに使えるAuroraです。
我々が管理するのは"ACU"(Aurora Capacity Unit)という、メモリ/CPU/Network容量の最小値と最大値のみとなっています。
オートスケール早いです
図は負荷試験シナリオを流した時にACUが1→16になるまでのメトリクスですが、ACUが倍々に増えているのがわかります。
v1でもかなりの短時間でスケールアップ・スケールインしてくれるので、もちろん要件次第ではありますがかなりのワークロードに耐えてくれそうです。
停止状態からの立ち上げ早いです
Aurora Serverlessは一定時間操作しなければ停止状態となり、再びアクセスが来た時に立ち上がるようになっています。
どのくらいの時間で停止になるのかは設定があります。
$ curl -kL 'http://**.**.**.***/api/sample' -o /dev/null -w "%{time_total}" 2> /dev/null
30.099126
停止状態からの立ち上げは時間が1分ほど掛かる、と聞いていたのですが、実際には30秒程度でレスポンスが帰って来ています。
(注意？)ACU増加時に一時的に処理待機が入る
こちらはAurora Serverlessを繋いだLaravelのエンドポイントに負荷を掛けた際のGatlingの結果グラフなのですが、あるタイミングでRPSが下がっていることが分かります。
これはACUが増加したタイミングとぴったり重なります。
また、CPUのメトリクス、キャッシュヒット率を見ると同じタイミングで一時的に減少しているのが分かります。
ここから先は確証のない予測ですが、
挙動としては裏側で立ち上がった別のマシンと入れ替わったような挙動を見せています。
予めキャッシュヒット率を高めておくことが前提になるようなサービスだと問題になるかもしれません。
最後に
負荷試験の勉強でAurora Serverless側にボトルネックを作ってみようと試みたのですが、
ACUを1に固定してインデックスの効かないクエリを投げる、くらいでしかパフォーマンスが悪くなるような現象を起こせませんでした。
AWS公式としてもv2にはかなり自信があるらしく、v1とv2では以下のようにユースケースの違いが明確です。
v1の場合：
Amazon Aurora Serverless v1 では、使用頻度が低い、断続的、または予測不能なワークロード向けのシンプルでコスト効率の良いオプションです。
v2の場合
Aurora Serverless v2 (プレビュー) は、開発およびテスト環境、ウェブサイト、使用頻度が低い、断続的、または予測不能なワークロードを有するアプリケーションから、大規模で高可用性を必要とする最も要求の厳しいビジネスクリティカルなアプリケーションまで、あらゆる態様のデータベースワークロードをサポートします。
Discussion