性能評価で最初に決めるのは「合否」と「指標」
性能評価が揉める最大の原因は、速いか遅いかの基準が人によって違うことです。なので最初に決めるのは「合否」。ここが腹落ちしていないと、テスト結果が出ても会議が長くなるだけ。
指標は3つに絞ると混乱しません。
- 応答時間（平均ではなくp95/p99）
- スループット（1秒あたりの処理数）
- エラー率（タイムアウトや5xx）
平均値だけを見ると「速いじゃん」で終わるのに、ユーザーは“たまにめちゃ遅い”を体験して離脱します。p95/p99を見るのはそのズレを潰すため。ここは地味だけど、後から効いてきます。
SLOの考え方も同じで、「この操作はp95で何ms以内ならOK」みたいに自然な日本語に落とすとチームに通ります。難しい言葉にしない方が通りがいいです。
性能評価の全体フロー：計画→環境→データ→実行→分析→改善
いきなり負荷をかけると大抵失敗します。順番が命。
1) 計画：何を、どの条件で、いつ合格にするか
目的（例：ピーク時でも購入完了まで3秒以内）と範囲（どのAPI/画面まで）を先に書きます。ここを丁寧にやるだけで、あとが楽になります。
2) 環境：本番相当性と観測を用意する
「本番と違うから結果が使えない」が最悪のパターン。完全一致は無理でも、ボトルネックになりやすい要素（DBサイズ、外部API、キャッシュ、スケール設定）は寄せます。
観測はこの時点で仕込む。たとえばメトリクスの可視化は Grafana と Prometheus の組み合わせが話が早いことが多いです。クラウドやSaaSでまとめたいなら Datadog や New Relic も候補になります。結論としては「負荷の数字だけ見ない」ための準備。理由は、遅い原因は“だいたい別の場所”にあるから。補足すると、トレースもあると捗ります。分散トレースなら Jaeger Tracing や OpenTelemetry を入れておくと切り分けが速いです。
3) データ：テストデータが弱いと結果が嘘になる
小さいデータで速いのは当たり前。検索や一覧の性能評価は、データ量が増えた瞬間に崩れます。個人情報の扱いに気をつけつつ、実運用に近い分布を作るのがコツです。
4) 実行：段階的に上げる（単発→シナリオ→耐久）
最初は単一APIを軽く叩いて、次にユーザー行動のシナリオ、最後に長時間の耐久へ。いきなり最大負荷をかけると、どこで壊れたか分からなくなります。
テスト種類の使い分け：性能・限界・耐久・スパイク
ここも結論はシンプルで、「目的に合わせて種類を選ぶ」だけです。理由は、同じ負荷でも見たい現象が違うから。補足として、ざっくりこう考えると迷いません。
- 性能テスト：想定負荷で目標値を満たすか
- 限界テスト：どこで崩れるか、崩れ方は安全か
- 耐久テスト：時間が経って遅くならないか（メモリリークなど）
- スパイク：急増に耐えられるか（バースト）
“検索機能”みたいにアクセスが偏る機能はスパイクも相性がいいです。
ツール選定：JMeterかk6か、それ以外か
ツールは最終的に好みもあるんですが、記事としては「どう選べば事故らないか」を書くのが強い。
GUIで始めやすいのは Apache JMeter。既存のノウハウも多い。ただ、シナリオが増えてくると管理が重くなりがちで、複数人運用だと“誰がどれを直した？”になりやすいです。
コードで管理したいなら k6 が気持ちいい。スクリプトでレビューできるし、CIに組み込みやすいのが大きい。結論としては「継続運用するならk6寄り」になりやすく、理由はテストが資産になるから。補足すると、短期スポットならJMeterでも十分勝てます。
他にも、重厚な商用選択肢として Micro Focus LoadRunner や NeoLoad が出てくるケースもあります。チーム規模や監査要件が絡むと、このへんがハマることもあります。
軽量にHTTPを叩いて癖を見るなら wrk や Vegeta、古典的にサクッとなら Apache Bench ab も候補。負荷“試験”というより健康診断に近い使い方がしっくりきます。
体験談：性能評価がグダる瞬間と、立て直し方
ここからが実際のところ一番役に立つ話です。
つまずき1：いきなりフルシナリオで回して、原因が迷子
最初にやりがちなのがこれ。検索→詳細→購入みたいな一連を最初から回して、遅いのは分かったけど「どこが？」が分からない。結論は、単一APIに戻って段階化するのが最速です。理由は、分解すると“遅い場所”が露骨に出るから。補足として、単一APIで「検索だけ」を叩いた瞬間にDBが100%になったら、もう勝ちです。改善の当たりが付く。
つまずき2：平均はOKなのに、ユーザーだけ不満
これもあるある。平均500msで「速い」と言えるのに、SNSでは「重い」。こういうときはp95/p99を見ると現実と一致することが多いです。待ってる人は待ってる。そこを見ないと永遠に噛み合いません。
つまずき3：観測が弱くて“雰囲気改善”になる
負荷ツールの結果しかないと、改善が当てずっぽうになります。メトリクスとトレースがあると、切り分けが段違い。例えば「アプリは空いてるのにDBが詰まってる」「外部API待ちでスレッドが枯れてる」みたいな話が、数字で言えるようになります。
ネットワーク面も疑うなら Wireshark が役立つことがあります。API確認を手早くやるなら Postman があると便利。性能評価って“負荷”の話に見えて、実は「観測と切り分け」の話でもあります。
ボトルネック特定：観測→仮説→検証の順で回す
遅い原因って、だいたい型があります。
- DBの実行計画が悪い（INDEXが効いてない）
- 外部APIが遅い、あるいはリトライ地獄
- コネクション枯渇（DB/HTTP）
- スレッド枯渇、キュー詰まり
- キャッシュ未命中が連鎖
ここで大事なのは、直したら必ず再テストすること。再現性がないと、次のリリースでまた燃えます。結論としては「改善は必ず同じ条件で戻し検証」。理由は、性能は気分で上下するから。補足として、検証条件をメモして残すだけで、次回の性能評価が半分になります。
報告書は“1枚要約”が強い：合否・根拠・次アクション
報告書で喜ばれるのは、長文より意思決定できる情報です。
- 目的と合否（達成/未達）
- 主要指標（p95/p99、スループット、エラー率）
- ボトルネックの結論（どこが原因か）
- 改善案と次の再テスト計画
これが書けると、性能評価が「不安を潰す活動」になります。
すぐ使えるチェックリスト
- 合否基準（p95/p99）を決めた
- 想定ユーザー行動をシナリオにした
- 監視（メトリクス/ログ/トレース）を準備した
- 単一API→シナリオ→耐久の順で段階化した
- 結果は平均ではなく分位を見た
- 改善後に同条件で再テストした
参考に手元に置くなら
体系的に学ぶなら SRE サイトリライアビリティエンジニアリング が読みやすいです。負荷試験だけじゃなく「指標で運用する」感覚が掴める。性能試験の手順に寄せるなら エンジニアのための性能試験入門 みたいな本があると迷いにくいです。現場で詰まったとき、結局こういうのが助けてくれます。
性能評価は、派手さはないけど“安心を買う作業”です。検索機能みたいにユーザー体験の中心にある箇所ほど、段階的にやるだけで結果がガラッと変わります。ツールは後からいくらでも替えられるので、まずは「合否」「段階」「観測」。ここだけは外さないのがいちばん効きます。
コメント