More than 5 years have passed since last update.

負荷試験の仕方

Last updated at 2018-08-11Posted at 2018-08-10

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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