この記事はアイスタイル Advent Calendar 2022 19日目の記事です。
こんにちは、アイスタイルで決済の開発,運用に携わっているomuramと申します。
この記事ではAurora Serverless v2の導入検討にあたり負荷試験検証をしたので、そこで得られた知見をまとめました。
Aurora Serverless v2とは
Aurora Serverless v2 の主な特徴
- 負荷に応じて処理を中断することなく自動でスケールアップされる
- Aurora ServerlessではACU（Aurora Capacity Unit）という単位のべき乗でDBのキャパシティがスケーリングし、消費したACUによって利用費が決定
- 1ACUあたり約2ギビバイト(GiB)のメモリ、対応するCPU、ネットワークの組み合わせ
- 1ACU：0.2USD/時間
- 0.5ACU単位でスケールアップさせることが可能
導入しようとした背景
現状の実態
現在決済サービスではAmazon Aurora（プロビジョンド）を使用しています。
決済サービスにかかる負荷の特徴として、データベースの使用負荷が短時間だけ増大するというのがあげられます。
例えば12:00に人気商品の販売の際に、たくさんのお客様がアクセスし12:00から数分間のみ通常時の何倍も負荷が増大するといった具合です。
プロビジョンドのDBインスタンスは負荷に応じて勝手にスペックアップしてくれないので、高負荷が見込まれる前にRDSのスペックを引き上げて高負荷に臨む必要があります。
ただ、スペックアップの際にフェイルオーバーで瞬断が起こるので、事業部に相談してお客様や売上への影響の少ない（アクセスの少ない）早朝に作業する必要があります。（これがなかなかつらい...）
目指すところ・実現したかった内容
- 瞬間的な負荷に合わせて自動スペックアップ、スペックダウン
負荷状況に合わせてスペックを自動で調整してくれることで、早朝の作業や細かなスペック調整から解放されたい。 - コスト削減
比較的アクセスの多い昼間とアクセスの少ない深夜でスペックの自動調整をすることでコストを抑えられるようになればうれしい。
負荷試験と結果
負荷試験の概要
※実際のアクセス数などを載せないようにしているので、不明確な箇所があります。ご了承ください。
- k6という負荷試験ツールを使用
- シナリオは「商品の選択～購入完了」まで
- Aurora Serverless v2のACU
- 最小ACU:0.5,最大ACU:128
- ※負荷に応じで上記ACUの間で自動で調整してくれます
- k6でかける負荷（スレッド数）
- ①250スレッド
- ②500スレッド
- ③1000スレッド
- ④2250スレッド
※上記スレッド数で10分負荷をかけています
結果
①250スレッド(11:25~11:35)
ACU使用率(MaxACUに対しての使用率)
CPU使用率
②500スレッド(12:10~12:20)
ACU使用率
CPU使用率
備考
- 250スレッドからスレッド数は倍になっているがACU、CPU使用率の伸びが思ったよりも高くならない
- こちらには載せていないが、250スレッドと比較して捌けた注文件数も微増程度
③1000スレッド(12:34~12:45)
ACU使用率
CPU使用率
備考
- 500スレッドからスレッド数は倍になっているがACU、CPU使用率の伸びは微増
- 捌けた注文件数は500スレッドの倍
④2250スレッド(12:55~13:05)
ACU使用率
CPU使用率
備考
- Too many connectionsのエラーが発生
- 1000スレッドからスレッド数は倍以上になっているがACU、CPU使用率の伸びはほぼ変わらず
- 捌けた注文件数も1000スレッドから微増程度
コストについて
過去の平常稼働時とイベント時からAurora Serverless v2に移行した場合の試算をDBAチームの方々が出してくれました。
金額は公開できないのですが、プロビジョンドと比較するとコストはかなり下がっていました。
プロビジョンドでは多少の負荷があってもいいように余裕をもってスペックを設定しているので、余分なスペックをAurora Serverless v2がうまく調整してくれているのだと思います。
また、弊社決済サービスはAWSがAurora Serverless v2の用途例として挙げている下記に当てはまると思うのですが、Aurora Serverless v2の性能に見合った負荷のかかり方をしていない場合、リザーブドインスタンスを利用できるプロビジョンドの方が価格としては安くなる可能性があります。
用途の例としては、データベースの使用負荷が短時間の間だけ増大し、その後に軽いアクティビティが長時間続くか、またはアクティビティがまったく発生しなくなるケースが挙げられます。
結果を受けての考察&今後
- ACUの最小値が低い状態から一気に負荷をかけると、Aurora Serverless v2のスペックアップがついていかない可能性がある。
- ACU、CPU使用率の伸びが微増だったのもスペックアップ追いついていなかった可能性がある。
→ACUの最小値を引き上げて検証する必要がある
- 瞬間的な負荷に対応できるようであれば、コストが下がりや運用面でも恩恵を受けられそう。
おわり
今回の負荷試験ではスレッド数に対して、CPU,ACU使用率が想定したより上がらず望んていたパフォーマンスが出ませんでしたが、Aurora Serverless v2の機能やコスト面の検証ができました。
（自分がちゃんとACUなどのチューニングができてないだけかもしれませんが...）
パフォーマンス面では次検証する点が明確になったので、今後も進めていきたいと思います。