手を動かして覚える JMeter
Apache JMeter は「たくさんの人が同時に使ったとき、システムが耐えられるか」を測る道具です。 このサイトは JMeter をまったく触ったことがない人が、実際に壊れるシステムを相手に 手順どおり進めるだけで一通り身につくように書いてあります。 各手順には必ず 観点 → 操作 → コマンド → 確認 → 期待値 が付いています。
このサイトの読み方
上から順に進めてください。飛ばすと後半でつまずきます。 期待値の枠には「こうなれば成功」という具体的な数字が書いてあります。 自分の画面の数字と見比べてください。合わなければつまずきポイントの枠に原因が書いてあります。
なぜ負荷試験をするのか
作ったシステムを自分ひとりで触っている限り、たいてい何の問題も起きません。 問題は同時に大勢が使ったときにだけ現れます。負荷試験はこの3つを知るためにやります。
| 問い | 答えの例 | 知らないとどうなるか |
|---|---|---|
| 何人まで耐えられるか | 同時30人までは平均80ms。50人を超えると急に3秒かかる | キャンペーンを打った日にサイトが落ちる |
| どこが先に限界を迎えるか | アプリではなくデータベースのCPUが先に100%になる | 効かない対策（アプリのサーバー増設）に金を使う |
| 同時アクセスで壊れないか | 在庫1個の商品が20個売れてしまう | 本番で在庫がマイナスになり、謝罪と返金が発生する |
3つ目が特に大事です。これは1人でテストしている限り絶対に発見できない種類のバグです。 この教材では実際にそれを再現します。
練習台 loadlab とは
JMeter を練習するには「負荷をかけてよくて、しかも壊れてくれる相手」が必要です。 本番サイトに負荷をかけるのは論外ですし、よくできたサイトは少々叩いても何も起きず勉強になりません。
そこで loadlab という練習用の通販サイトを用意してあります。見た目はただの通販サイトですが、 管理画面のスイッチで、負荷をかけている最中にわざと壊せるのが特徴です。
| スイッチ | 入れると何が起きるか |
|---|---|
n_plus_one | 商品一覧が「1件ずつ何度もDBに問い合わせる」非効率な作りに変わる |
review_index | データベースの索引を本当に削除する。商品ページが60倍遅くなる |
stock_mode | 在庫チェックを壊れた作りに変える。同時注文で在庫がマイナスになる |
error_rate | 指定した割合でエラーを返すようになる |
rate_limit | アクセス過多を検出して 429 を返すようになる |
cache | 結果を10秒間おぼえておくようになる（＝速くなる） |
さらに JMeter 側の数字（スループット、応答時間）と、サーバー側の数字（DBの待ち行列、CPU使用率）を 同じ画面に並べて見るためのダッシュボードも付いています。 これが無いと「なんか遅い」で終わってしまい、原因を突き止める練習になりません。
練習台は2か所に置ける
loadlab は自分のPC（ローカル）にも、負荷試験用に借りたサーバーにも置けます。 このサイトは両方に対応していて、各ページ上部の切り替えスイッチを操作すると 掲載しているコマンドがその環境用に自動で書き換わります。
| ローカル | サーバー | |
|---|---|---|
| 準備 | Docker で練習台と観測ツールを起動する | すでに動いている。手元はJMeterだけ |
| グラフ | 手元の Grafana | サーバー上の Grafana（PCを閉じても動き続ける） |
| 測定の正確さ | JMeterと同じPCなので数字が汚れる | 正確（負荷生成と対象が別マシン） |
| ネットワーク | 無し | あり（本番に近い） |
| 向いている段階 | STEP 1〜7（操作を覚える） | STEP 8〜11（本気で測る） |
おすすめ
前半はローカル、後半はサーバー。 操作を覚える段階は手元で完結する方が速く、限界点を測る段階は分けないと数字が信用できません。 実測でも同じテストで 同居 329.5 req/s / 分離 374.0 req/s と差が出ています。
JMeter の部品を6つ覚える
JMeter の画面には部品が何十種類も並んでいて最初は面食らいますが、 役割は6種類しかありません。これさえ分かれば画面が読めるようになります。
| 種類 | 役割 | 代表例 |
|---|---|---|
| スレッドグループ | 何人が、どれくらいの時間をかけて、何回繰り返すか | スレッドグループ |
| サンプラー | 実際にリクエストを送る人。これが無いと何も起きない | HTTPリクエスト |
| 設定エレメント | サンプラーに情報を足す。宛先、Cookie、ヘッダ、CSVなど | HTTPリクエスト初期値、Cookieマネージャ、CSV Data Set Config |
| アサーション | 返ってきた中身が正しいかを判定する。これが無いと失敗を見逃す | 応答アサーション、継続時間のアサーション |
| タイマー | リクエストの前に待つ。人間らしさを再現する | 一様乱数タイマー、Synchronizing Timer |
| リスナー | 結果を見る・記録する | 結果を表示(ツリー)、集計レポート、Backend Listener |
もうひとつ後処理エレメント（レスポンスから値を抜き出す）とコントローラ（実行順序をまとめる）が ありますが、これは後の章で出てきたときに覚えれば十分です。
最初に押さえる用語
スレッド ＝ 仮想的な利用者ひとり
「スレッド数 30」は30人が同時に使っている状態という意味です。 JMeter の用語で一番よく出てくるので、頭の中で常に「人」に読み替えてください。
Ramp-up ＝ 全員がそろうまでの秒数
「スレッド数30 / Ramp-up 10秒」なら、10秒かけて1人ずつ増えて30人になります。 0秒にすると30人が同時に殺到します。現実の利用者はそうならないので、通常は数十秒かけます。
スループット ＝ 1秒あたりに何件さばけたか（req/s）
システムの処理能力そのものです。人を増やしてもこの数字が増えなくなったら、そこが限界です。
応答時間 ＝ 1件が返ってくるまでの時間（ms）
利用者の体感です。平均値ではなく 90%Line / 95%Line を見ます （後述しますが、平均値は嘘をつきます）。
初心者が必ず守る3つの掟
1. GUI で負荷をかけない
JMeter の GUI 画面は作成とデバッグ専用です。GUI のまま負荷をかけると、
画面描画に CPU を取られて JMeter 自身が遅くなり、測っているのがサーバーではなく JMeter になります。
計測は必ずコマンド（-n オプション）で行います。JMeter 自身も起動時にこの警告を出します。
2. 自分の持ち物以外に負荷をかけない
他人のサイトへの負荷試験は攻撃と区別がつきません。練習は必ず loadlab に対して行ってください。
3. 負荷をかける機械と、かけられる機械を同居させない
同じPCで JMeter と対象システムを動かすと、CPU を取り合って数字が汚れます。 この教材でも実際に、同居させた場合 329 req/s、分けた場合 374 req/s という差が出ました。 練習の最初はローカル同居で構いませんが、本気で測るときは必ず分けます。
学習の順序
全部で6章、あわせて4〜6時間ほどを想定しています。1日で終わらせる必要はありません。
準備
JMeter と練習台 loadlab を動かして、画面が開くところまで。ここが一番つまずきやすいので丁寧に書いてあります。
STEP 1-4 ・ 90分基本
1本のリクエストを送る、結果を読む、人数を増やす、ログインを突破する、テストデータを散らす。
STEP 5-7 ・ 90分シナリオ
購入までの一連の流れを組み立て、アサーションで失敗を捕まえ、グラフでリアルタイムに眺める。
STEP 8-11 ・ 120分限界と改善
限界点をさがす、ボトルネックを特定する、直して同じ試験で測り直す。ここが負荷試験の本番です。
いつでもリファレンス
コマンド集、用語集、期待値の一覧、困ったときの対処。行き詰まったらここを見てください。
この教材を終えたときにできるようになること
- シナリオを自分で組み立てて、コマンドで実行し、HTMLレポートを出せる
- ログインが必要なサイトに対してテストを通せる（＝相関ができる）
- 「何人まで耐えられるか」を数字で言える
- 遅い原因がアプリなのかDBなのかCPUなのかを切り分けられる
- 改善の効果を「前後の同じ試験」で証明できる