社内 LT で 負荷試験について発表したので Qiita に焼き増しします。
ご自身の環境での負荷試験に思いを馳せるきっかけになれば幸いです。
はじめに
サービスの安定に欠かせない負荷試験ですが本腰を入れて勉強したことがありません。
今回は勉強のきっかけ作りとして試験の目的や種別を整理してみます。
負荷試験の目的
負荷試験の目的を端的に言うなら「本番稼働にシステムが耐えうるか」を確認するためかと思います。
具体化すると「あるシナリオで想定される負荷を掛けて問題が発生しないか」を確認するためと言えます。問題が起きているか判断するための観点は一般的に以下のようなものがあります。
- リソース使用率が跳ね上がっていないか
- レスポンスのステータスコードは正常か
- レスポンスのレイテンシは許容範囲か
同時にシステムの特性を把握したり正常に機能が動作しているか確認します。
- 負荷量とリソースの関係はどうなっているか
- マシンスペックの選定は正しいものか
- オートスケーリングは働いているか
よし負荷試験してみよう
目的を整理できたので、いきなりですが（脳内シミュレーションで）負荷試験をしてみましょう。
例えば新規ページを /new-feature のようなパスで公開するとします。
トップページにリンクを配置するのでかなりのアクセスが見込まれます。
このようなケースでどのように負荷試験を行うでしょうか。
パッと考えつくのは「1日当たりの最大トラフィックで同時に負荷を掛ける」です。
そして上述のようにリソース状況やレスポンスが期待通りであるか確認します。
さて、これは十分な負荷試験と言ってよいでしょうか。
なんだか単純化されすぎていて不安な気持ちになりませんか？
不安の正体
「システムへの入力値ってそんなに単純じゃなくね？」
恐らく多くの方がこのように感じるのではないかと思います。
雑な絵ですが負荷試験で単純化されたシナリオと、実世界のシナリオを見比べてみましょう。
| 単純化されたシナリオ | 実世界のシナリオ |
|---|---|
 |
 |
単純化されたシナリオでは1種のリクエストが大量に送られてきています。実世界のシナリオでは様々なユーザから様々なリクエストが様々な順番で送られてきています。CM が始まれば突発的なリクエスト増もあるかもしれません。わざわざ絵にして書くほどのことでもない気がしますが非常に重要な点だと思います。
負荷試験の多くは Stg 環境など実ユーザのいない環境で行われます。そうした差分をきちんと念頭に入れないと正しい負荷試験ができません。（データ量やマシンスペックに差分がある場合は考慮すべきことは更に複雑化します。）
Prd 環境を再現すればいいじゃない
Stg で Prd を再現できればよいのですが、完全な再現は不可能と言ってよいでしょう。
Stg を Prd に近づけることは様々な制約があるため簡単ではありません。
頑張って100%の再現を目指すより80%くらいを再現する方が効率がよいのは間違いないです。
とはいえ何をもって80%というのか。そもそも%で表現することも難しいです。
そこで用いられるのが「負荷の抽象化」です。
複雑な実世界を3つの切り口で抽象化
下図は k6 ドキュメントからの引用となります。
図を見ると負荷試験を以下の3つに分類しています。（本当はもう少し細かいので詳細はドキュメントへ）
- 既存負荷・・・・想定されるユーザ数分のリクエストに対する性能を評価する
- 過負荷・・・・・システムのボトルネックを推定しオートスケールの指標とする
- 長時間負荷・・・一時的な負荷テストでは発見できない問題をあぶり出す
このように複雑な実環境のシナリオを3つに分類して試験することで、実世界におけるユーザトラフィックを完全再現することなくかなりの問題を回避できるでしょう。もちろんデータ量やマシンスペックは Prd 環境と同等である必要はあります。
補足: シナリオテストを考える 
上記の3つの切り口に加えてシナリオテストが必要か検討しなければなりません。
シナリオテストとは実際のユースケースをシミュレートするテストのことです。
EC サイトを例にすると カート追加→住所登録→注文確定 の一連のフローを再現します。
どの負荷試験を実施すべきか
実世界のトラヒックを抽象化して3つに分類できることが分かりました。
では全ての試験を実施すれば OK なのかと言うとそれもまた違います。
この先は「場合による」としか言えないです。
決まりきった一連のフローがあるならシナリオテストを組むかもしれませんし、クライアントも再現した E2E 試験が必要かもしれません。また、負荷試験とは毛色が異なりますがカオスエンジニアリングの世界に踏み入るのもよいのかもしれません。その組織やアーキテクチャ、試験対象に応じて何をどこまでやればよいかは変わってきます。自身の環境に合わせて適切な試験を組めるようにひたすら考えましょう。
むしろ大切なこと
ただ負荷試験をちゃんとやったつもりでも問題が起きるときは起きます。
そのため次のような対策を講じておくことも大切だと思います。
- 素早く安全にロールバックできるような体制・仕組みを作る
- スループットやレイテンシの異常を早期検知する仕組みを作る
さいごに
今まで何となくで負荷試験をしていたので目的や種別を整理できてよかったです。
参考