負荷試験とは何か
パフォーマンス全般の担保を主な仕事とする我ら「まかせいのう[1]」チームにとって、性能試験は頻繁に実施するタスクの1つです。性能試験と一口にいっても色々と種類がありますが、システムの性能を担保するうえで最も重要になるのがEnd-to-Endの負荷試験です。
End-to-Endとは「フロントエンドからバックエンドまで、ユーザから実行された処理が通過するシーケンスすべてのコンポーネントを範囲とする」という意味です。例えば、Web3層であれば、
Web層 - AP層 - DB層
に存在するすべてのコンポーネントに本番相当の負荷を発生させることになります。「DB層だけ」とか「Web層だけ」というようにスコープを限定すると、それ以外のコンポーネントがボトルネックになるリスクが残ります[2]。当然、キャッシュサーバや帳票サーバといった周辺的なコンポーネントも処理シーケンスに含まれるならば、それらも試験スコープに含める必要があります。
負荷試験とは、複数のユーザが同時にアクセスするときにシステムにかかる負荷を擬似的に発生させる試験のことです。必ず同時に1人しか使えないシステム（例えばローカルPC上で処理が完結するようなソフトウェア）であれば、負荷試験は不要ですが、普通のWebシステムでは、サーバサイドに多人数の処理が並行してアクセスすることが普通です。こうしたユーザ負荷を擬似的に生成するツールとしては、オープンソースのJMeterはじめ、ベンダが提供するLoadRunnerなどいくつかの選択肢があります。
本番相当の負荷をすべてのコンポーネントにかけることで、
- リソースのキャパシティ充足を確認する
- 性能要件（レスポンスタイム／スループット）の達成を確認する
ことが、End-to-End負荷試験の主な目的です。
本稿のテーマは、このうち、性能要件の指標の一つである「スループット」とは何か、ということです。この概念は、もう一つの指標であるレスポンスタイムに比べると少し分かりにくく、勘違いされていることがあり、それが原因で間違った負荷試験が行われることもしばしばです。本稿を通して、スループットを正しく理解してもらえれば幸いです。
1000人乗っても大丈夫？
負荷試験を実施しようとする方から非常によく聞かれるのが、次のような質問です。
Xシステムの負荷試験を実施しようと考えています。試験の負荷量としてユーザ数1000人を想定していますが、これは今回の試験で妥当でしょうか？
残念ながら、この質問には答えることができません。それはこのXシステムの情報が足りないからではなく、原理的に答えられない質問だからです。
「1000人」のような利用する総ユーザ数や、あるいは同時セッション数や総トランザクション数といった、いわゆる「多重度」をあらわす数値は、負荷試験を実施する上で重要であることは事実です。この数値によって必要な負荷端末の台数なども決まります。 しかし、多重度の数値は、システムが満たすべき性能要件にはなりえません。
スループット≠多重度
システムの性能要件（性能目標）は、一般に、レスポンスタイムとスループットという2つの指標によって定義します。次の性能要件をご覧ください。
性能要件の例
- オンラインレスポンスタイム 90%ile 3秒以下[3]
- オンラインスループット 900TPS以上
この性能要件には、先ほどの質問に含まれていた「ユーザ数」のような多重度をあらわす言葉は登場しません。従って「多重度が性能要件として妥当か」と聞かれても、それは「牛スジ煮込みを作るときの温度は5000ヘクトパスカルで妥当か」という質問と同じで、返答に窮します。多重度とスループットは、温度と気圧くらい違う概念だからです（まったく無関係ではないのですが、それについては後で説明します）。
では、スループットとは何か。それは単位時間あたりの処理量です。単位時間というのがポイントで、これはつまり、スループットは必ず「○○あたり」という限定付きの数値だということを意味しています。例えば、
- 1日に50000人がアクセス
- 秒速で1億円稼ぐ
- 1bps
これらはすべてスループットです。以下のように「単位時間あたり」の表現になっているからです。
- 5000人 / 日
- 1億円 / 秒
- 1bit / second
一方、「1000人」といった限定なしの数字は、スループットではありません。「1年で1000人アクセスする」のか「1秒で1000人アクセスする」のか分からないからです。同じ1000人でも、両者では性能要件として雲泥の差です[4]。冒頭に書いたような質問をしてくる人は、この点を勘違いして、「1000人が同時にアクセスする」負荷試験をすることがあるのですが、これはすなわち「1000人/秒」に近いスループットを達成しようとする負荷試験を意味します。しかし、システムの総ユーザ数が1000人であれば、現実のスループットはこれよりずっと小さくなるのが普通です[5]。
常に単位時間が必要という意味で、スループットは「50km/h」や「時速5ノット」のような速度と似ています。車を買うとき、「この車の性能は200kmです」という説明を受けて納得する人はいないでしょう。最高時速が50km/時しか出なくても、4時間かければ200km走ることはできます。車の性能において重要なのは時速すなわち「速度」のほうであることは誰もが理解しているのに、システムの速度であるスループットが軽視されるのは、少し不思議な話ではないでしょうか？
注
[1]: パフォーマンスを主な対象としてシステム開発・運用の改善や設計を行うNTTデータのコンサルタントチーム。
[2]: このとき、クライアント端末（PCやスマートフォン）をスコープに含むかどうかは、状況により異なります。
[3]: 「％ile」（パーセンタイル）は、集合をある順序でソートして一定の割合で分割するという意味です。「90％ile 3s」であれば、「すべての処理のうち最も遅い上位10％に含まれるものは、3秒を超えてもよい」という解釈になります。90％ile 3sはWebシステムでは平均的な目標ですが、もちろんシステムに求められる性能によって変わります。筆者が見た商用システムの中で最も厳しい目標は「99％ile 1s」というものです。これは「すべての処理のうち最も遅い上位1％に含まれるものは、1秒を超えてもよい」ということなので、逆にいうと「99％の処理が1秒以下で処理される」必要があります。
[4]: 1秒で1000人のアクセスが発生するならば、そのまま線形に伸ばすと、1年では31億人を超えるアクセス数となります。
[5]: 朝一番のログイン集中や、特売イベントのピークでは、「全ユーザが同時にアクセスする」に近いスループットが実現されることもあるのですが、例外的なケースです。
