はじめに

負荷試験をやってみたことが無い人向けに
どういうことをしたらいいかを記載してます。

負荷試験の目的

構築したサーバー構成が運用中にどれくらい負荷に耐えられるかを知るためです。

負荷の見積もりを行う

いざ負荷をかけようと行っても闇雲に行っても意味がないです。
まずどれくらいの同時リクエス数が必要かを見積もる必要があります。
下記のサイトが非常にわかりやすいのでこちらを基準に必要リクエス数を見積もりました。

お客さん、PMはなかなか数字を出してくれないこともありますが、
見積もりがないと始まらないので概算でもいいので出してください。

負荷試験ツールの準備

負荷試験ツールとはサーバに対して指定した量のリクエストを送り、そのレスポンスを受けることでパフォーマンス計測することができるツールです。
負荷試験を行うテスト計画(シナリオという場合もある)を設定し、実施・計測を行います。
JMeterを例にとると簡単には下記の通りです。

実施事項

スレッドグループを設定
- どのくらいの期間でどのくらいのスレッドを生成するか
- ループ回数はどのくらいにするか
送信HTTPを設定
テスト実施
結果表示

各種要素

スレッド数：文字通りrequestを投げるスレッド数
Ramp-Up期間：設定されたスレッド数になるまでの期間
ループ回数：1スレッドにおける一連のリクエストの繰り返し回数
総リクエスト数 = スレッド × ループ回数

その他の準備

サーバー監視ツール(munin, NewRelic, ....)
ログ監視(アクセスログ, エラーログ) ※エラーが発生した際に通知が来るようになっていればベスト

ボトルネックを把握する

ループ回数は1ですべてのリクエスト処理を一様に実行します
リクエスト数を最初は低負荷で徐々に負荷を上げていきます

各主要機能の中でどの機能が重い処理なのか、つまりボトルネックを把握するのが目的です。

高負荷で動作させる計画

高負荷にて動作させるための計画を立てます。
先の項目にてボトルネック把握した上で負荷計画を考えます。

例えば、ログイン処理がボトルネックのアプリなのか、
それともログイン後の例えば、課金処理やゲームであればイベントバトル処理などがボトルネックのアプリかで負荷のかけ方の計画が変わります。

極端な例ですが、下記のようにスレッドループ計画に差が出るかと思います

ログイン認証/ユーザー作成がボトルネック
いかに多くのスレッド数を短時間で増やすことに重きを置きます。
ログイン以降のアクションがボトルネック
総リクエスト数 = スレッド数 × ループ回数です。ユーザー作成処理・認証処理でなければ、同じリクエスト回数でもループを駆使して賄うことができるかと思います。
ある一定のスレッド数でループ回数を使用することによりボトルネック処理が繰り返し実施させたほうが、負荷試験ツールがハングアップしないで済みます。
(インストール環境にもよりますが、JMeterなどの高性能負荷試験ツールはスレッドを多く生成するとメモリーが枯渇することがよくあります)

エラー発生時の対応

負荷試験中のエラーの種類をまず振り分ける必要があります。

エラーの種類
- 負荷試験ツールの設定の誤り
- 見落としていたバグ
- 高負荷により発生したエラー

前2つはすぐに対応するものとして、3番目は下記の問題をはらんでいることがあると思います。

StackTraceを見ても原因が分かりづらい
発生のトリガーとなっている箇所が実はログとは別の場所

アプリ全体の知識と想像力が試される箇所です。
WEBサーバー、DBやキャッシュのステータスを確認しながら、
不要なリソースアクセスはないか？などの観点て考えてみると軽減される箇所が見つかったりする場合があります。

結果の評価について

例えばWebサーバーのステータス項目だけでもこれだけあります。

代表的なWebサーバーのステータス項目
- disk容量
- ネットワークトラフィック数
- netstat情報
- CPU使用率
- load avarage
- memory使用量

初めての方は何をどころ評価しなくては行けないのか迷うところでしょうが、
すでに運用中の別プロジェクトの結果と見比べてみてください。

サーバー台数や規模は違うかもしれませんが、
サイト全体のスループットで考えると許容値が見えてくるかもしれません。

最後に

負荷試験は試行錯誤が必要で、検証と評価を繰り返し実施する必要があるかと思いますが
なるべく体系的に整理をしておくことでコスト削減につながるのではないでしょうか。

負荷試験の仕方