負荷試験をお願いされたエンジニアが考えることを整理します。
負荷試験の定義（本記事内での）
負荷試験といっても人によって解釈は微妙にずれがありそうなので、本記事が指す負荷試験の定義を最初に書いておきます。
- システムの性能を測るテスト
- 特定の期間内に予め計画した量のリクエストをシステムに流しシステムの挙動を確認する
- 実施する環境は検証環境とする
2つの確認項目
負荷試験で必ず確認すべき2つの確認項目は、「スループット」と「レスポンスタイム」です。
スループット
スループットとは、単位時間あたりに処理されたトランザクションの数です。TPS (Transaction Per Second、秒間トランザクション数) や RPS (Request Per Second) で定義されます
スループットが高いほど、システムは多くのトランザクションを捌くことができ、短期間にユーザーのアクセスが集中しても耐えることができます。逆にスループットが不足していると、システムの読み込み時間が長くなったり最悪の場合システムの読み込みに失敗しユーザーからのアクセスを拒否することになりかねません。これはビジネス的には機会損失となるため、起きてはならないことです。（とはいっても起こってしまうことはあるんですが）
負荷試験では、システムが発揮できるスループットの限界値を計測する必要があります。DAU(Daily Access User)やサーバースペックやDBスペックなど、あらゆる要因を考慮に入れた上でシステムが発揮すべきスループットの値を導出し、そのスループットをシステムが発揮できているかを確認しましょう。
レスポンスタイム
レスポンスタイムとは、システムにリクエストを送信してからレスポンスが返却されるまでに要する時間のことです。
レスポンスタイムの時間が長いとユーザーの離脱率が上がってしまいます。昔聞いた話なのでうろ覚えですが、ページ読み込み時間が一秒増加するだけで数十%のユーザーが離脱すると言われています。
負荷試験では複数のリクエストのレスポンスタイムを計測するため、個々のリクエストのレスポンスタイムではなくリクエスト全体のパーセンタイル値で計測することになります。例えば「95%のリクエストが3秒以内に返ってきた」などです。
負荷試験のハードルの高さ
負荷試験の実施ハードルは高いです。
シナリオ作成
まず計画が大変です。システムが満たすべきスループットとレスポンスタイムの設定は負荷試験担当のエンジニアが一人で勝手に決めていいものではなく、エンジニアチーム・ビジネスサイド・ユーザーサイドなどの複数のチームと相談しながら決める必要があります。シナリオの作成だけでそこそこの時間を要します。
環境準備
負荷試験実施のための環境準備もコストが高いです。負荷試験環境は可能な限り本番環境と同等のスペックで行うべきです。インフラコストの観点から、往々にして検証環境というのは本番よりもサーバーの台数を減らし、DBのスペックも低いものを使うことが多いです。負荷試験のために本番と同等スペックの環境を試験期間中ずっと稼働させるとそれだけインフラコストは発生するので、無邪気に提案できるものではありません。
また、仮に負荷試験環境作成の承認が降りたとして、環境の構築コストもかかります。ここはIaCなどでどこまで効率化できているかにも依存しますが。
実施
負荷試験はシナリオを一回通せば終わり、とはいきません。
シナリオで定義したスループット・レスポンスタイムを満たせなかった場合は、TPSやRPSをチューニングして再実施が必要になります。そしてこのチューニング作業が一番大変です。求めるスループット・レスポンスタイムを発揮できなかった原因がどこにあるのか？サーバーなのか？DBなのか？どこの何がボトルネックになっているのかを調査する必要があり、これはとても骨の折れる作業です。まあ、本番ローンチ後に障害が発生して、本番環境で同じ調査をするよりは先に負荷試験の段階で調査できる方が精神的にはまだ楽ですが。。
まとめ
- 負荷試験は大変
- スループット・レスポンスタイムを確認しよう
- シナリオ作成は複数のチームと決める必要がある
- 環境の準備コストが高い
- シナリオの実施は複数回発生する。チューニングが大変。
参考