性能試験の設計 — どの負荷を、どの構成で、いつ測るか

性能試験で最もよくある失敗は、使えない数字を根拠に設計判断を下すことだ。どの環境で、どの負荷パターンを、どのタイミングで計測するかを設計段階で決めなければ、試験をいくら重ねても本番の挙動は保証できない。この記事では、性能試験を設計する際の判断軸——環境差異の影響、試験手法の選択、目標値の定義、計測点の設計、試験を収束させるための割り切り——と、典型的な落とし穴を整理する。

本番と違う環境で測って出た数字が使えない構造

環境差異が測定値を無効にする仕組み

性能試験の結果が本番に使えない理由の多くは、「スペックを合わせた」だけで「トポロジーと設定を合わせていない」ことにある。たとえばDBを試験環境では1台構成で動かし、本番ではRead Replicaを2台追加した3台構成にする場合、レプリカへの書き込み伝搬とルーティングの遅延が上乗せされる。ハードウェアが同じでもソフトウェア構成が違えば計測値は別物になる。試験環境で「p95が200ms以内」を確認して本番投入したところ、本番では常時400ms超になったという話は現場で繰り返し聞く失敗パターンだ。

ミドルウェア設定の差が数字を歪める

Nginxのworker_connections・MySQLのinnodb_buffer_pool_size・JVMのヒープサイズといったチューニングパラメータは、試験環境と本番環境で揃えていないと計測値に乖離が生じる。特に、本番でチューニングが施されているにもかかわらず試験環境がデフォルト値のままになっているケースは多い。バッファプールが本番の30%しか割り当てられていない試験環境では、キャッシュヒット率の差がそのままレスポンスタイムの差として現れる。試験計画には「本番との設定差一覧」と「その差が評価指標に与える影響の考察」を記載する欄を設けておくと、後から数字を使う際の注釈として機能する。

アンチパターン：開発環境の計測値を要件に使う

開発環境（SSD・メモリ潤沢・単一ユーザー）で計測したスループット上限をそのままシステム要件として扱うのは、典型的なアンチパターンだ。開発環境はI/Oレイテンシもネットワーク遅延も実環境より大幅に低いため、数字だけ見ると過剰に楽観的になる。ある構築を担当したチームが、SSDローカルディスクで動作する開発環境で「1秒あたり1,000リクエスト処理可能」という数字を測定し、それを要件として契約書に記載したところ、本番環境がiSCSI接続のNASであったためランダムI/Oのレイテンシが桁違いになり、要件を達成できなかったケースが報告されている。計測値は「それが出た条件セット」と不可分であり、条件が変われば数字も変わる。開発環境での計測は仮説の確認に留め、要件に使う数字は本番同等環境から取得するという基準を試験計画に明記しておく必要がある。

試験で確かめる性能と設計計算で足りる性能の判断

設計計算が有効な範囲

性能確認のすべてを試験で行う必要はない。処理が線形にスケールし、共有リソースへの競合がない場合は計算で上限値を見積もれる。サーバー20台で各台が独立して処理するバッチジョブであれば、1台のベンチマーク値をスケールした試算が成立する。キューイング理論（M/M/1モデル）を使った待機時間の試算や、CPUコア数・スレッド数・処理時間から導くスループット上限は、「このアーキテクチャが要件を満たせるか」を試験前に判定するために使える。試験コストを抑えたい場合は、計算で仮説を絞り込んでから試験で確認するという段階的アプローチで試験期間を短縮できる。

試験でしか確かめられない振る舞い

キャッシュのコールドスタートとウォームアップ後の性能差、ガベージコレクション起動タイミングの一時的なレスポンス劣化、コネクションプール枯渇時のリトライ挙動——これらは計算では再現できず、試験でしか観察できない。特に見落とされやすいのは長時間負荷時の性能劣化だ。30分間の連続負荷をかけると、メモリリークが顕在化したり、ファイルディスクリプタが徐々に積み上がって上限に到達することがある。「負荷をかけた時間が長くなるほど性能が落ちる」という挙動は短時間ベンチマークには現れないため、試験シナリオの実施時間設計で見落とされがちになる。

試験か計算かを選ぶ判断軸

共有リソースへの競合・外部システムへの依存・非線形スケール特性（負荷増加に対してレスポンスタイムが急増する区間があること）のいずれかが存在するなら試験が必要になる。すべて当てはまらないなら計算で十分と判断できる。判断に迷う場合は「最悪のケースを計算で求め、その値が要件の2倍以上余裕があるなら試験不要」という安全策が使える。逆に、計算上はギリギリを通過するが非線形な挙動が疑われる場合は、計算だけで判断せず試験で確認する判断を優先する。

単体ベンチ・シナリオ負荷試験・本番トラフィック複製の比較

手法	主な目的	本番再現度	コスト感	主な適用場面	主な限界
単体ベンチマーク	コンポーネント単体の性能上限把握	低（単体動作のみ）	低	設計初期・コンポーネント選定	複合負荷下の競合が見えない
シナリオ負荷試験	複合負荷下の挙動・ボトルネック確認	中（操作フローを模擬）	中	本番投入前の最終確認	シナリオ設計の精度に依存する
本番トラフィック複製	実際の負荷パターンでの挙動確認	高	高	移行判断・SLA保証確認	本番規模の試験環境が必要

各手法の適用場面と限界

単体ベンチマークはコンポーネントの性能上限を把握するために使う。DBのINSERTスループット、APIエンドポイントの単体レスポンスタイム——これらを複合試験の前に確認しておくと、後でボトルネックが現れた際に切り分けが容易になる。ただし、「他の処理が何もない状態での上限」であり、複合負荷下の振る舞いとは異なる点に注意する。シナリオ負荷試験はユーザーの実際の操作フロー（ログイン→検索→詳細参照→カート追加など）を複数の仮想ユーザーで並行実行する手法だ。コンポーネント間の競合が浮かび上がりやすく、単体ベンチマークでは見えなかった問題を発見しやすい。ユーザー操作の比率（読み取り80%・書き込み20%など）を実際のアクセスログから引いてくることが精度を高める鍵になる。

本番トラフィック複製の選択基準と工数の目安

本番のリクエストログを試験環境に向けて再生するトラフィック複製は、実際の負荷パターンを最も忠実に再現できる。一方、試験環境を本番に近い規模で用意するコストが高く、実施できるプロジェクトは限られる。移行判断の最終確認やSLA保証が必要な本番切り替え前など、精度が求められる場面に絞って使う判断が現実的だ。なお、性能試験全体の工数の目安として、中規模プロジェクト（サーバー10〜30台程度）では試験設計・実施・分析込みで2〜4週間、大規模プロジェクト（100台超）では4〜8週間を見積もるケースが多い。この工数は「何を試験するか」の範囲定義が確定していることが前提で、範囲が曖昧なまま着手すると工数が2倍以上に膨らむことがある。

目標値（応答時間・スループット）をどこから引いてくるか

SLA/SLOからの逆引き

試験の合格基準はSLAで約束した数字から逆算するのが基本だ。「p99のレスポンスタイムが500ms以内」というSLAがあれば、試験の評価指標もp99で設定する。平均値だけを計測して合否を判定するのは落とし穴で、外れ値が多くてもp50（中央値）が良好なら平均値は優れて見えてしまう。評価指標をp95・p99で設定することで、テール部分の挙動まで含めた判定が可能になる。SLAがない場合はSLO（内部目標値）を先に設定し、それを合格基準にする。SLOは「ユーザーが体感上の快適さを感じる閾値」から引いてくることが多い。

既存ログ・成長率からの目標値設定

既存システムからの移行プロジェクトでは、現行のアクセスログからピーク時のrps（requests per second）とp95レスポンスタイムを計測し、それを新システムの最低水準にする。将来の成長分を見込む場合は、直近12ヶ月のトラフィック増加率から1.5〜3倍の余裕を設定する判断が多い。新規構築で参照できるログがない場合は、類似規模のリファレンスアーキテクチャの測定値を仮置きとして使い、試験結果に応じて調整する前提で扱う。仮置きの数字であることを試験計画に明記しておかないと、後のフェーズで「決まった数字」として独り歩きするリスクがある。

目標値の定義に含めるべき要素

「レスポンスタイム200ms以内」という目標値だけでは合否の判定が曖昧になる。測定対象（どのAPIか）・測定点（クライアント側かサーバー側か）・計測範囲（正常系のみか異常系を含むか）・評価パーセンタイルをセットで定義する必要がある。また、スループット目標（rps）と同時接続数目標は別物だ。Little’s Law（同時接続数 = スループット × レスポンスタイム）を使って両者の整合性を確認しておくと、目標値の内部矛盾を事前に検出できる。たとえば「500rpsを処理しながらp99が1秒以内」という目標は、同時接続数が最低でも500必要であることを意味しており、コネクションプールの設定に直結する。

ボトルネックを切り分けられる計測点の置き方

レイヤー別計測点の設計

ボトルネック切り分けに失敗する典型パターンは、エンドポイントのレスポンスタイムだけを計測していて「遅い」とわかっても「どこが遅いか」が特定できない状態だ。試験設計の段階で、LB→アプリサーバー→DBという処理フローの各レイヤーに計測点を設けることで、遅延の所在をレイヤー単位で特定できる。LBのアクセスログへの処理時間出力、アプリサーバーへのAPMエージェント導入、DBのスロークエリログの有効化を試験前に済ませ、試験中にリアルタイムで観察できる状態にしておく。試験が終わってからログ設定を追加しても、再現できるとは限らない。

見落とされがちな計測の盲点

DBへの1リクエストあたりのクエリ発行本数は、DBの全体スループットには現れにくく、クエリカウンターを別途計測して初めて発見されることがある。N+1問題がこれに当てはまる。ネットワーク帯域がボトルネックになっている場合、アプリのプロファイルを改善しても性能は上がらないため、NIC送受信バイト数・パケットドロップ率を試験中に確認することで早期に除外できる。OS層ではCPU・メモリだけでなく、ディスクI/OのAwait値とiowaitの確認がDBサーバーの診断に有効だ。DBサーバーでiowaitが高止まりしているなら、アプリのチューニングより先にディスク構成の見直しを検討する判断になる。

計測基盤は試験シナリオより先に設計する

メトリクス収集・ダッシュボード・ログ集約といった計測基盤を試験開始と同時に手配するのでは遅い。計測基盤はシナリオ設計と並行して構築し、試験前の動作確認フェーズで「計測できていること」を先に検証しておく。計測基盤がダウンした場合に試験データが欠損するリスクを避けるため、ローカルログへのフォールバックも事前に用意する判断が現場では多い。手を動かす詳細な計測設定の手順については、インフラ構築の手順系リソースで確認するとよい。設計の核心は「どの計測点で何を取るか」を試験開始前に決め切っておくことにある。

本番同等を追い求めて試験が終わらない境界

「本番同等」を定義しないリスク

「本番同等環境で試験する」という合意だけでは、どこまで再現すれば本番同等かが不明確なまま試験計画が立てられない。CDNの再現、外部決済APIのモック、メール送信サーバーの構成、バッチスケジューラーの設定まで「本番同等でなければならない」という要求が積み上がり、試験環境の構築だけで6週間を要したプロジェクトの話を聞くことがある。試験の目的を先に明確にし、その目的に必要な再現範囲だけを「本番同等」として定義するアプローチが現実的だ。目的が「WebアプリのAPIレスポンスタイム確認」であれば、CDNや外部メール送信サーバーまで再現する必要は通常ない。

差分の影響を評価する判断軸

試験環境の差分を「本番と同じか否か」の二値で判断しようとすると、差分が見つかるたびに試験が停止する。代わりに「この差分が今回の試験目的の評価指標に影響するか」を問う軸を持つことで取捨選択が可能になる。DBレプリカ台数は読み取り負荷の分散に影響するため再現すべきだが、レプリカのCPUが本番より1〜2世代古くても今回の目的では許容できる、といった具体的な判断ができるようになる。差分の影響を「あるかないか」ではなく「評価指標に対して無視できる水準か」で評価することが、試験を前進させる鍵になる。

試験を収束させる設計上の割り切り

試験は「合否を判定できる状態になったら終わり」にする設計が必要だ。合格条件（例：ピーク負荷時にp99が目標値以内、かつ1時間連続負荷でエラー率0.1%以下）を試験計画に記載し、ステークホルダー間で事前に合意しておく。試験で発見された問題をすべて解決してから本番投入する方針にすると、低優先度の問題が残り続けて投入できなくなる。「本番投入を妨げる問題」と「投入後に対応可能な問題」の分類基準をあらかじめ定めておくと、収束判断がしやすくなる。これは技術的な問題ではなく、試験計画の設計段階で決めておくべきプロジェクト管理上の判断だ。

性能試験設計チェックフレーム

試験計画を作成する前に、以下の項目を確認する。チェックが入らない項目は試験開始前に意思決定が必要な未解決事項として扱う。

1. 環境差異の明示：試験環境と本番環境の設定差一覧（ミドルウェア・ネットワーク・OS）を作成し、各差分が評価指標に与える影響を考察しているか。
2. 試験手法の選択根拠：単体ベンチ・シナリオ負荷試験・トラフィック複製のどれを使うかを、コストと精度の観点から選択し、その根拠を記載しているか。
3. 目標値の定義セット：評価指標（p95/p99など）・測定対象・測定点・計測範囲・スループットと同時接続数の整合性（Little’s Law）を確認しているか。
4. 「試験 vs 計算」の判断：共有リソース競合・外部依存・非線形スケール特性の有無を評価し、試験が本当に必要な範囲を絞り込んでいるか。
5. 計測点の設計：LB・アプリ・DB・OS各レイヤーに計測点を設けており、試験前に計測基盤の動作確認を完了させる計画になっているか。
6. 「本番同等」の範囲定義：試験目的に照らして再現すべき範囲を明示し、再現しない差分とその影響評価を記載しているか。
7. 合格条件の事前合意：ステークホルダー間で合格条件（パーセンタイル・エラー率・試験時間）と「投入を妨げる問題」の分類基準を合意しているか。
8. 長時間負荷試験の計画：短時間ベンチマークに加え、30分〜1時間以上の連続負荷試験をシナリオに含めているか。