こんにちは、配配メール開発エンジニアのhiro_jiです。
突然ですが、負荷テストの進め方ってイメージできますか？
ある程度経験があれば難なく進めることができると思いますが、そうでない場合はそもそも進め方のイメージが湧きづらいかと思います。かくいう私も最初は何から手を付ければよいか分からなかった記憶があります。。。
そこで今回は負荷テスト初心者の方向けに、私の所属するチームで実施している手順を紹介します！

負荷テストとは？

本題に入る前に、負荷テストとは何かについて軽く触れておきます。
負荷テストとは、特定の条件下でシステムやアプリが示す性能を評価、検証するものであり、運用中の障害を未然に防いだり、パフォーマンスの問題やボトルネックを改善するために非常に重要な役割を持ちます。
負荷テストには、性能要件を満たしているか検証するための「ロードテスト」や、限界値を特定するための「ストレステスト」など、目的や観点に応じて様々な手法があり、計測方法や分析する指標がそれぞれが異なります。
（テスト手法の名称に関してはサービスや会社によってまちまちなようですが、本記事ではそれらの総称を「負荷テスト」として扱います）
本記事ではそれぞれの手法については触れませんが、「スムーズにテストを進める方法」という観点で参考になれば幸いです。

負荷テストのフロー

全体像

私たちのチームではいくつかの工程に分けてテストを進めていて、工程ごとにレビューを挟むことで余計な手戻り作業を削減しています。

方針検討

このフェーズでは以下のようなことを決めます。

テストを行う背景や目的
- 性能要件を満たしているかを確認したい？それともシステム限界値まで特定したい？
どのような指標で評価するか
- 応答時間
- エラー率
- スループット
- サーバリソースの使用量
評価対象とする機能や処理の範囲

など

ここの方針がずれていると、無駄な作業や大幅なやり直しにつながってしまいます。
例えば、限界値を特定したかったのに性能要件の範囲までの負荷しかかけれていなかったり、あるSQLの性能だけを計測したいのに機能全体も性能を計測したり...
効率的に進めるためにも、最低限上記のような内容は早い段階で明確にしておきましょう。

詳細計画

ここでは方針検討で決めた内容を元により詳細な内容を決めます。具体的には、

使用する環境やサーバ構成
負荷の量
- 同時ユーザー数
- リクエスト数
- レコード数やファイルサイズ
エビデンスとして残す情報
- 処理時間だけでよいのか？サーバリソースの状況も取得するのか？
操作手順（負荷をかけるシナリオ）
使用ツール
評価基準

などなど
決めることは多いですが、ここが曖昧だと実は想定する負荷をかけれていなかったなんてことになりかねないので、可能な限り詳細に記載することが大切です。
随分過去の話ですが、DBに用意するレコードに関してレコード数自体は想定通りだけど、その内訳に関して計画担当とデータ準備担当間で認識齟齬が生じていしまい、テストのやりなおしが発生したことがありました。
特にデータ量などを記載する際は、数値だけでなくその数値とした根拠や内訳も明確に記載し、チーム内の認識を合わせましょう。

テスト準備

詳細計画で決めた内容に沿って必要な環境、データやスクリプトなどを準備します。

テスト用の環境
テストシナリオ
DBに登録するレコードやリクエストなどのデータ
負荷の計測用スクリプトやツール

詳細計画に沿ってテスト準備をするだけといえばそれまでですが、個人的にはここが一番時間がかかるフェーズだと思います。
対象機能の理解や大量データの作成方法など、ある程度の前提知識やコツが求められることが多いです。詰まったら迷わずチーム内の有識者に聞いちゃいましょう。
また、次回以降のテストの効率と再現性向上のために、データ作成や計測用に作成したスクリプトはどこかに残しておくことをおススメします。

テスト実施

準備ができたらいよいよテスト実施です。
テストの内容にもよりますが、大量データを扱う場合などは色々と注意が必要になります。
私たちのチームではトラブルや手戻りを未然に防ぐために、以下のような内容をチェックリスト化し、テスト実施前に毎回確認しています。

使用する環境が正しいか
共用の環境を利用する場合、事前に利用することを周知できているか
リソース監視対象のサーバで、余計な処理が動いていないか
- 計測データにノイズが入らないか
外部サービスへ大量リクエストを送るようなことはないか
- 送る必要がある場合は、許可を得ているか
テスト手順が適切か

負荷テストはその性質上、他のテストに比べて様々なリスクがあります。
いきなり本番テストを行うのではなく、まずはミニマムで実施することでテストの妥当性を確認しましょう。

評価

計測した結果が、詳細計画で決めた基準を満たしているかどうかを明確にします。
単純にOK、NGだけ記載するのではなく、その評価に至った根拠や補足情報を記載し、結果の妥当性を示すことが大切です。例えばサーバリソース（LAやメモリ）に関して、瞬間的な値のみで判断するのと、連続的な値も含めて判断するのとでは、大きく意味合いが異なると思います。

分析・チューニング

評価、分析の結果、基準を満たさない場合はアプリの改修もしくはインフラ側の拡張を検討する必要があります。
いきなりアプリ改修やインフラ側の拡張に走ってしまうと、全く改善効果が得られず無駄な対応に時間をかけてしまったなんてことになりかねません。
まずはボトルネックの特定から進めることがチューニングの一番の近道です。

おわりに

本記事では私のチームで実践している負荷テスト手順についてご紹介させていただきまいた。
負荷テストと聞くと身構えてしまう方もいる多いかもしれませんが、段階的にチーム内で認識を合わせて進めることができていれば、なんてことないと思います。
今回は進めかたという点に絞ってご紹介しましたが、次回は具体的に使用している負荷計測ツールや分析方法についても紹介できればと思います！