負荷試験＃開始と目的 の続きで、最初から目標を大きくしすぎず、アプリケーションと目的をなんとなく理解して、とりあえず始めていきましょうというところです。

どのようなデータを採取し整理すれば、ゴールに向かっていきやすいのか、を考えていきます。

条件と結果の記録

負荷試験には多くの関連項目があります。項目１つの記録や考察が抜けていただけで、最初からやり直し、ということも普通にあります。

最初から完璧な試験はなく、進行したことで判明する要素もあるので、最初から最後まで項目を決めつけて記録することは非常に危うく、常に今現在の試験が正しいのか、設定は最適なのかを疑う姿勢が必要です。

また、途中で項目数が変動する可能性があるということは、それまでの記録が一瞬にしてゴミに変わる可能性が常にある、ということなのですが、例えゴミだとしてもそれがゴミである証拠は必要ですし、それがなければゴミである確認のための再試験をする場合もあり、時間のムダが生じやすいところです。

そのため、まず絶対的に守りたいこととして、その試験中において認識している固定値・変動値は、可能な限り記録しながら進行しましょう、ということです。

多少、項目が多く面倒だとしても、項目を欠いてよくわからなくなるよりは、結果的に時間の浪費を抑え、精度を高く進行できることは確実です。なんとなく始めつつも、早い段階で記録を整理し始めることが、基本であり奥義にもなります。

記録する項目

それでは、どのような記録すべき項目があるのかを整理していきます。認識する値といっても、たいして関係のないカーネルパラメータは？とか、野暮なツッコミは不要です。また、ツールやアプリケーションによって、いくらでも異なるので、あくまで参考例ということで。

Client Specs

まずはツールを使ってトラフィックを発生させる Client の環境条件です。

項目	補足
サーバースペック	インスタンスタイプ、vCPU数、CPUモデル、など
サーバー台数	EC2、コンテナタスク数など
Worker数	１台あたりのWorker数と全体の数。ツールがクラスタ可能か、シングル or マルチスレッドタイプかで必要性は変わる

Server Specs

Server側はまさに被試験体なので、基本項目もそれ以外も多く確認することがあります。リファクタリングやチューニングを試みると、注意する項目が増えていきます。

項目	補足
サーバースペック	インスタンスタイプ、vCPU数、CPUモデル、など
	メモリ容量、ストレージ性能（IOPS,Latency）、ネットワーク性能
サーバー台数	EC2、コンテナタスク数など
接続数・スレッド数	各種ミドルウェアの、最大受け入れ同時接続数や、並列稼働Worker数など
設定	調整に関わるOSやミドルウェアの各種設定値

Data

データベースなどのテストデータの変化による結果の変化をチェックしていく場合、その特徴を記録しておきます。大雑把に書きますが、実際にはモノによって詳細に記録することになります。

• データ容量
• データ件数
• データ分布・割合
• データ分割条件（垂直・水平・分割数など）
• データ保存形式（暗号化・圧縮など）
• データ転送形式（暗号化・圧縮など）

Client Conditions

負荷試験ツール実行時の、トラフィック流量決定条件です。ツールによって異なるので、可能な変動値を全て記録します。

項目	補足
Users	最大同時実行ユーザーセッション数
Spawn	1秒毎に何ユーザーセッションずつ増やすか
RunTime	試験実行時間
WaitTime	リクエスト間毎の待機時間
Metadata	レスポンスに影響を与える HTTP Header など

Test Result

負荷試験ツールが出力するテキストやグラフの結果をまとめます。徐々にトラフィックを増やす場合、ピーク部分のみ記録したり、異常な形状のグラフ部分を記録します。

項目	補足
RPS	Requests per second 毎秒あたりのリクエスト数。RPM (per minite) より秒がオススメ。全体としてのと、必要なら処理ごとも残す
Failures/s	毎秒あたりのエラー数やエラー率。全体と、特にゼロではない処理
ResponseTime	レスポンス速度を単位はms(millisecond)がオススメ。min/max/avg を、全体の平均と特に遅い処理を
ResponseSize	レスポンスのデータ平均容量。全体の平均と特に大きい処理を
Users	予定通りのユーザー数増加と最大数に到達したかチェックし、ダメならファイル・ディスクリプタ数や、プロセスID数など、接続上限数に関わる設定を確認します
Logs	ツールの実行ログに異常があれば残す

Client Metrics

ツールを実行しているサーバーのメトリクスは、特に最初の方は必ず確認します。サーバーがキャパオーバーで詰まるのは試験上問題ないですが、クライアントが詰まると正確な試験にならないからです。

項目	補足
CPU	CPUの使用率が100%に到達しないよう調整します
Network	NetworkのBandwidthが上限に到達しないよう調整します
Memory	ユーザーセッションを増やしすぎるとメモリ不足になるので注意します

Server Metrics

サーバーメトリクスの基本項目とミドルウェアごと専用の項目を記録し、適切な処理量と性能上限の算出に利用します。

項目	補足
基本項目	参考：ミドルウェア性能検証の手引き | 外道父の匠
クラウド	マネージドサービスとして提供される各種メトリクス
サーバーステータス	ミドルウェアに直接リクエストすることで得られる各種ステータス値

記録媒体

試験の始めたては、試験そのものがちゃんと動くかを確認し、それから手探り気味に目的に向かって本格的な調整をしながら実施します。

そのため、最初は何も記録しなかったり、適当なテキストデータにメモ書きして進めることがありますが、これは早い段階で社内情報共有ツールや表計算ソフトに記録することをオススメします。

採取値を使った計算は、そう複雑なものは多くないですが、試験数が増えるほど表計算になっていたほうが当然楽です。また、自分で見るにせよ他人と共有するにせよ、テキストや箇条書きも多くなるほど見づらくなるので、表に落とし込む方が結果の記録も整理も効率的です。

美しくない自身の記録行為が億劫になってモチベが下がっても仕方ないので、初手の試験後には、そろそろちゃんと整理し始めた方がいいかな！って気付けると良いです。

試験の実行時間

多くの試験は、数回程度で済むことは少なく、数十回は実施することになります。そのため、試験の実行時間だけでも合計すると結構なモノになるため、１回１回の試験時間を最適化することは大切です。

悪い例としては、サービスのとあるイベント実施が30分間あるとします。アプリケーションの設定も30分単位でしか設定できないし、試験も実際の時間と同じだけ実行した方がいいでしょう。という考えは誤りです。最終的な確認試験としてはアリですが、初手～中盤までを30分ずつ実行する必要はありません。

理由は、判断材料としての結果採取には普通は30分も必要ないからです。大雑把に言えば、必要なデータが採取できた時点で、その試験はいったん打ち切ってよく、打ちきれず最後まで実行する必要がある場合は、先に最小限の実行時間を判断してから、繰り返しの実施に入るべきです。

では、何を採取できればOKと判断するかというと、メトリクスの採取が基本となります。メトリクスの多くは、１分または５分間隔でデータが更新されるので、メトリクス値の変動が安定期に入ってから２～３回分あれば、その後のデータは不要です。５分間隔ならば、15分実行すれば２回分は確実に採取され、点ではなく線のデータとなります。最近はほとんどが１分間隔だと思うので、より短時間で十分であることが多いです。

試験実行時に、長いからとインターネット徘徊しても別にいいんですが、理想的には試験実行終了後にはすぐ次の条件で試験を回し、それが回っている間に前の試験条件と結果を整理する。というように交互に回転することが最も効率的です。

ハードウェア単体の試験だと、OS上で秒単位で観測するので、もっと周期が早かったりします。逆にどうしても長くせざるを得ないのもあるでしょうし、大事なのは所要時間の最適化をしようとする姿勢ということで。

データ整理

実行条件と試験結果を表に整理していくと、数値が綺麗に比例するもの、しない箇所が出てきます。比例しない場合で、かつ特にそれが許容できない変化の場合は、原因を探って、必要があればその項目を試験に組み込んで再実施します。

この時点ですでにデータから何かを判断しているわけではありますが、これを納得のいくデータになるまで繰り返し、次のフェーズであるデータの判断と算出へと移っていきます。


できれば、データ採取をガーッと全部を終わらせてから考察に移れたほうが効率的だし幸せなのですが、なかなかそういかないこともあります。それを上手くやるには、データ採取の時点で異常や不足に気づいて試験を調整していく洞察力、これで十分だという判断力が必要です。

ですが、それを磨くには多くの結果考察の経験が必要で、そう考えるといきなり上手くやってみようとするよりは、まずはやってみるべし！で、途中や終了後に、試験自体を振り返って改善しようとする姿勢が、もっとも重要なんかなとも思ったり:-)