アソビュー！ Advent Calendar 2023の16日目（裏面）の記事です🎄
アソビューでバックエンドエンジニアをしている上中です。
早速ですが、みなさん負荷テストはされていますでしょうか。
アソビューでは過去にシステム負荷増大に伴うシステムダウンを経験したことから、可用性の向上にここ数年注力してきました。
そんな中、今回私が担当したプロジェクトでも可用性の維持を目的としたシステムの負荷テストを実施しましたので、こんな感じでやったよというのを参考までに共有できればと思います。
負荷テストは難しい
負荷テストって難しいですよね。
どうやって負荷をかければいいのか？負荷をかけるにしてもどの機能にどれくらいの負荷をどれくらいの時間で？負荷テストの合格ラインは？負荷に耐えられているのかどうかの判断は？
そういったことを１つ１つ頭を使って考える必要があり、また開発しているサービスによってもそれらの考え方は違ってきます。
負荷テストをやってみよう
どうやって負荷をかけるのか？
アソビューではテストツールとしてgatlingを使っています。 負荷テストの実行環境についてはこちらに詳しく説明していますので、そちらを参考にしてみてください。（本記事では割愛します）
どの機能に負荷をかけるのか？
アソビューでは、アクティビティ、チケット、日時指定チケット、年間パスポートなどいくつかの商品群を販売しております。それら商品群ごとに、購入ステップや購入した電子チケットの利用ステップにおける処理内容が異なっています。
今回私のチームで開発を行なった機能は、超特割チケットという商品群の購入ステップや利用ステップに関連する機能になります。
アソビューは電子チケットを販売するECサイトですので、購入ステップや利用ステップは非常に重要なユーザの利用導線となっており、ここで障害が起きてしまうとECサイトとしての意義を失いかねません。
よって、今回のテスト対象もこの購入ステップや利用ステップを中心に行います。
まずはこれらの購入ステップと利用ステップのパターンを洗い出します。
| シナリオパターン |
|---|
| Top~アクティビティ予約ステップ-QR利用ステップ |
| Top~アクティビティ予約ステップ-もぎり利用ステップ |
| Top~チケット購入ステップ-QR利用ステップ |
| Top~チケット購入ステップ-もぎり利用ステップ |
| Top~日付指定チケット購入ステップ-QR利用ステップ |
| Top~日付指定チケット購入ステップ-もぎり利用ステップ |
| Top~ 超特割チケット購入ステップ :通常券-QR利用ステップ |
| Top~ 超特割チケット購入ステップ :通常券-もぎり利用ステップ |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-QR利用ステップ |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-もぎり利用ステップ |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-QR利用ステップ |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-もぎり利用ステップ |
他にも細かくあるのですが、便宜上簡略化しています。
アソビューにはQRコードによる着券(入場)と、電子チケットのもぎりによる着券(入場)の２パターンがあるので、それぞれのパターンを含めています。
また、今回は超特割チケットの修正なので超特割チケットの負荷耐性を見たいわけですが、当然超特割チケットが購入されている間も他の商品は購入されています。
超特割チケットへの負荷が他に影響を与えないか、あるいはその逆のケースがないかをチェックするため、他の機能も同時に負荷をかけます。
どれくらい負荷をかけるのか？
まずは、各パターンごとの負荷割合を決定します。
前述の通り、超特割チケットが購入されている間も他の商品は購入されていますので、実運用にできるだけ即した形にするために各商品群が同時にどれくらいのアクセスがきているのか、その中で超特割チケットがどこまで負荷に耐えられるのか確認する必要があります。
アソビューでは、Datadogを用いてシステムのモニタリングを行なっていますので、各種商品群がどの程度の割合で購入されているのか調べることができます。
あるいはデータベースで単位時間あたりの購入数を検索するでも良いかもしれません。
負荷量は繁忙期を基準に決めるため、直近１年間でもっともアクセスが多かった日の購入割合をざっくり算出します。 （数字はフィクションです）
| シナリオパターン | 購入割合 |
|---|---|
| Top~アクティビティ予約ステップ-QR利用ステップ | 12% |
| Top~アクティビティ予約ステップ-もぎり利用ステップ | 12 |
| Top~チケット購入ステップ-QR利用ステップ | 9% |
| Top~チケット購入ステップ-もぎり利用ステップ | 9% |
| Top~日付指定チケット購入ステップ-QR利用ステップ | 11% |
| Top~日付指定チケット購入ステップ-もぎり利用ステップ | 11% |
| Top~ 超特割チケット購入ステップ :通常券-QR利用ステップ | 7% |
| Top~ 超特割チケット購入ステップ :通常券-もぎり利用ステップ | 7% |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-QR利用ステップ | 6% |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-もぎり利用ステップ | 5% |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-QR利用ステップ | 6% |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-もぎり利用ステップ | 5% |
次に、TPM(トランザクション数 / 分間)を確認します。
ここでいうトランザクション数は、「１分間に購入ステップ内に入っていたユーザの総数」としました。
こちらもDatadogから、１分間あたりのアクセス数をベースに算出しています。
それをここでは仮に1000TPMとします。
今回、負荷量の目安を「繁忙期の5倍」としました。
ここは正直決めの問題なのですが、アソビューは年々利用者が増えているため、２年先を見据えた場合に予想される最大負荷量+αぐらいを目安にしています。
あまり先を見過ぎても、そのころにはアソビューのサービスは大きく形を変えている可能性があるため、大体２年先を目安としています。
よって、今回の負荷テストの合格ライン(目標)となるTPMは、1000TPM×5倍の5000TPMとなります。
これを、シナリオパターンの購入割合に基づいて按分します。
| シナリオパターン | 購入割合 | TPM |
|---|---|---|
| Top~アクティビティ予約ステップ-QR利用ステップ | 12% | 600 |
| Top~アクティビティ予約ステップ-もぎり利用ステップ | 12 | 600 |
| Top~チケット購入ステップ-QR利用ステップ | 9% | 450 |
| Top~チケット購入ステップ-もぎり利用ステップ | 9% | 450 |
| Top~日付指定チケット購入ステップ-QR利用ステップ | 11% | 550 |
| Top~日付指定チケット購入ステップ-もぎり利用ステップ | 11% | 550 |
| Top~ 超特割チケット購入ステップ :通常券-QR利用ステップ | 7% | 350 |
| Top~ 超特割チケット購入ステップ :通常券-もぎり利用ステップ | 7% | 350 |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-QR利用ステップ | 6% | 300 |
| Top~ 超特割チケット購入ステップ QR(既存):ペアチケット-もぎり利用ステップ | 5% | 250 |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-QR利用ステップ | 6% | 300 |
| Top~ 超特割チケット購入ステップ もぎり (既存):セット券-もぎり利用ステップ | 5% | 250 |
Top~アクティビティ予約ステップ-QR利用ステップの場合、分間600人のユーザが購入ステップに流れ込む、というテストになります。
なお、アソビューの購入ステップは、
枚数選択->購入者情報入力->入力内容確認->購入・決済完了
となっています。
TPMはあくまでトランザクション数であり、１購入ステップを通しで完了して1トランザクションとなります。
ここまで決めたら、あとはgatlingでコードを書いて実行です！
合否をどう判定するのか？
さて、あとは負荷に耐えることができたのかどうかを確認します。
なお、アソビューでは以下の２種類のシナリオが存在します。
- 一定の負荷をかけ続けるテスト
- 負荷を少しずつ上げていくテスト
上記1.は、繁忙期の継続的な負荷を想定したシナリオで、2.は人気の商品に発売と同時にアクセスが集中したときの負荷を想定したシナリオです。
1.の場合は繁忙期をベースに、2.の場合は過去最大のアクセス数をベースに算出するという違いはありますが、目標TPMの決め方はどちらも同じです。
合否判定については、
1. -> 1時間持ち堪えられるか
2. -> 目標のTPMまでは耐えられるか
をそれぞれ合格ラインとしました。 アソビューではアクセスが集中する時間帯に傾向があるため、それを参考に時間を設定しています。
2.についてはどこまでの負荷に耐えられるかの限界値を見極めることも目的としています。
判定もDatadogで確認します。
例えば、2.の負荷を少しずつ上げていくテストのリクエスト数とレイテンシー(下図)を見ると、大体12:28分ごろからレイテンシーが悪化し始めています。
また、Request and Errorsを見ても、徐々にアクセスは増えているはずなのに、12:30過ぎたあたりでリクエスト数が増加していないことがわかります。
この時点でシステムに何かしらの問題が発生し、リクエストを捌ききれなくなってきたと考えられます。
Podの負荷を見てみても、やはり12:28あたりから負荷が上がり始めています。
そして購入成功数を見てみても、同じく12:28を過ぎたあたりで頭打ちになっています。
他にもエラーの発生数で見ることもできるかと思いますが、このように多角的な情報によって限界値を見極めています。
まとめ
ここまで、かいつまんでの説明にはなりますが、負荷テスト実施のプロセスについてこんな感じでやってみましたという内容を共有しました。
特に難しいのは、実際の運用に沿ったシナリオや前提条件の検討と、そうした場合に各APIのアクセス数のをどう設定するかでしょうか。
まだまだ探り探りな状況ではありますが、今後も可用性向上に向けて取り組みを継続していきます。
アソビューでは一緒に働くメンバーを大募集しています！ カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います！
