1 性能テストの概要
1.1 目的と評価観点
1.1.1 応答時間（レイテンシ）
応答時間は、要求が投入されてから結果が返るまでの所要時間を指標として捉える。平均値だけでなく、中央値や分位点を用いることで、遅い要求がどの程度混入するかを把握する。レイテンシのばらつきは利用者体験やシステムの待ち行列状態に直結するため、時間帯や負荷水準ごとに観測するのが一般的である。
1.1.2 スループット（処理量）
スループットは、単位時間あたりに処理できる件数やデータ量の大きさを示す。要求の種類（読取、書込、外部連携）によって意味が変わるため、測定対象を明確にして集計することが重要である。負荷を上げると増加し続けるとは限らず、飽和や性能劣化が起きる境界を見つけることが目的になる。
1.1.3 計算資源とコスト（CPU・メモリ・I/O）
計算資源の消費は、同じ処理性能でも費用に差が出る要因になる。CPU負荷、メモリ利用量、ディスクやネットワークの入出力などを並行して観測し、どの資源が律速になっているかを判断する。特にメモリ増大やI/O待ちの増加は、長時間運用での安定性やコストの予測に直結する。
1.2 対象範囲
1.2.1 アプリケーション層
アプリケーション層では、API処理、画面遷移、バッチ処理などが対象になる。データアクセスの頻度、外部サービス呼び出し、暗号化や圧縮などの周辺処理も含めて評価する。実装上の変更がどの経路に影響するかを把握するため、エンドポイントや業務フロー単位で観測点を設計する。
1.2.2 輸送・通信層
通信層では、プロトコル処理、暗号化オーバーヘッド、接続確立、転送遅延などが測定対象になる。ロードバランサやゲートウェイを挟む構成では、経路ごとの遅延やキューイングを切り分ける必要がある。タイムアウト設定や再送挙動も性能に影響するため、通信仕様を前提として評価する。
1.2.3 基盤・インフラ層（サーバ、クラウド、ネットワーク）
基盤・インフラ層では、計算基盤、仮想化やコンテナ、オートスケール挙動、ストレージ特性、ネットワーク帯域が関わる。クラウド環境ではメトリクスが複数のレイヤに分散するため、相関を取って理解することが必要である。性能だけでなく、費用面での最適化判断もこの層の観測に支えられる。
1.3 テストの前提条件
1.3.1 目標値（SLO/SLA、許容範囲）
性能テストは合否判定のための目標値が不可欠である。SLOやSLAの考え方に基づき、許容レイテンシ、最大エラー率、処理能力の下限などを数値で定める。目標値は現実の運用要件に合わせて調整し、測定指標との対応関係を明確にしておくことで、後日の解釈ブレを抑える。
1.3.2 設定・環境の再現性
同等性が担保されないテスト結果は意思決定に使いにくい。サーバ性能、ミドルウェアのバージョン、タイムアウト、同時実行数、キャッシュの初期状態など、差分になりやすい要素を記録する。再現性を高めるため、可能な範囲で構成を固定し、変化する要素は事前に管理計画を立てる。
1.3.3 データ・状態の管理
データの内容や偏り、参照する件数、関連テーブルの整合性は性能へ影響する。テスト用データの生成方法や更新手順を定義し、テスト前の状態が揃うようにする。キャッシュやセッションなど状態を伴う仕組みがある場合は、ウォームアップ手順と測定区間を分離して扱う。
2 種類と手法
2.1 負荷テスト
2.1.1 定常負荷での限界確認
負荷テストは、一定の条件のもとで段階的に負荷を上げ、目標を満たす範囲と限界を探る。負荷の上昇に対してレイテンシやエラー率がどう変化するかを観測し、飽和点を特定するのが中心課題になる。結果は容量計画や性能要件の再設計に利用される。
2.1.1.1 スケール特性（水平・垂直）
スケール特性は、台数やリソースの増減により性能がどの程度改善するかを示す。水平スケーリングでは追加インスタンスへの分配や共有資源の競合が効くため、スケール効率が理想通りにならないことがある。垂直スケーリングではCPUやメモリ増により改善する余地がある一方、上限に近づくと伸びが止まる。両者を比較して、どの方向の投資が有効かを判断する。
2.2 ストレステスト
2.2.1 破綻点と回復挙動
ストレステストは、意図的に高い負荷や異常に近い条件を与え、どこで破綻するか、破綻後に復旧するかを確認する。単に故障の発生だけでなく、エラーの種類、再試行での挙動、サービス復帰までの時間を観測する。これにより運用時の対応手順や安全機構（サーキットブレーカ等）の妥当性を評価できる。
2.3 耐久（スパイク・長時間）テスト
2.3.1 メモリリーク・劣化検知
耐久テストは、長時間の稼働による劣化を見つけることに重点がある。メモリ使用量の単調増加、応答時間の漸増、ガベージコレクション頻度の変化などを監視し、リークや断片化の兆候を検知する。スパイクを組み合わせる場合は、急変後に性能が元に戻るかも検証対象になる。
2.4 スパイクテスト
2.4.1 急激な変動への耐性
スパイクテストは、短時間に負荷を急増させ、瞬間的な処理能力と保護機構の動作を確認する。キューの増加、タイムアウト、再送による雪だるま効果などが起こり得るため、負荷変動の時間幅を揃えて測る。急増に耐えられる設計か、あるいは制御（レート制限やバックプレッシャ）が適切かを判断する。
2.5 設計比較・ベンチマーク
2.5.1 実装差分の影響評価
ベンチマークは、比較対象の実装（アルゴリズム、データモデル、ミドルウェア構成など）ごとに性能差を定量化する。変更点以外の条件を極力揃え、統計的なばらつきも考慮しながら評価する。結果の解釈では、同じ平均性能でも分位点やコストが異なる場合があるため、多面的に見ることが重要である。
3 テスト設計
3.1 シナリオ設計
3.1.1 ユーザー操作・APIシーケンス
シナリオ設計では、実利用に近い操作手順やAPI呼び出しの流れを定義する。単発のリクエストのみでは、認証状態やキャッシュヒット、後続処理の連鎖などを再現できない。経路が複数ある場合は、成功率や分岐確率を取り込むことで現実度が高まる。
3.1.2 代表業務（主要フロー）の選定
代表業務は、利用頻度や重要度、導線の中心となる処理を優先して選ぶ。全機能を同じ重みで試験すると実施コストが膨らむため、影響範囲を見極めながら重点化する。主要フロー以外にリスクの高い例外処理を加えることで、性能劣化が起きやすい箇所を補完できる。
3.2 テストデータ準備
3.2.1 規模と分布（アクセス集中、偏り）
データ準備では、件数だけでなく分布を合わせることが重要になる。アクセス集中のあるキーやホットデータが存在すると、キャッシュやロック競合の発生が変わる。偏りを無視すると、本番での律速要因を見誤るため、利用統計に基づく再現や感度分析が有効である。
3.2.2 準実運用データの扱い
準実運用データを使う場合、品質と整合性の検証が必要である。個人情報を含む可能性があるため、匿名化やマスキングを適用し、要件に沿って扱う。テストの目的が性能であっても、データの欠損や参照整合の崩れはエラー率を不自然に押し上げ、解釈を歪める。
3.3 メトリクス設計
3.3.1 アプリ指標（遅延、失敗率）
アプリ指標としては、処理時間の分布、成功・失敗の割合、要求あたりのリソース消費などを収集する。失敗率は原因別に分解し、例えば検証エラー、外部依存のタイムアウト、内部例外などを分ける。これにより、性能問題がアプリ内部の遅さなのか、外部要因なのかを早期に判断できる。
3.3.2 システム指標（飽和、キュー）
システム指標では、CPU使用率だけでなく、待ち行列の長さ、スレッド枯渇、コネクション枯渇、ストレージ待ちなどを含める。飽和の兆候を早期に検知することで、どの部位が限界に達したかを推定できる。指標はアプリ観測点と対応づけ、時間軸上で相関を取る設計が望ましい。
3.3.3 監視・ログの関連付け
監視は、メトリクスとログの関連付けが前提になる。リクエスト単位のトレースや相関IDにより、遅延がどの処理段階で発生したかを追跡できる。ログは量が増えると観測そのものが負荷になるため、保存方針やサンプリング率の設計も含めて管理する。
3.4 合否基準（判定）
3.4.1 目標達成条件
合否基準は、SLOに基づく閾値を具体化する。例えば、特定分位点が目標内であること、エラー率が上限を超えないこと、一定期間の安定性が維持されることなどを定める。判定は一度の測定で決めず、計測のばらつきを考慮して複数回の試行や条件の再現性を確認する。
3.4.2 異常時の扱い（再実行、除外ルール）
異常が発生した場合の扱いを事前に定めることで、恣意的な除外を避ける。テスト装置の故障、ネットワーク断、監視基盤の停止など外部要因は除外対象になり得る。再実行の条件として、原因の切り分け結果や最低限の安定測定が揃ったかをルール化すると、判断の透明性が上がる。
4 実行と分析
4.1 試験環境の構築
4.1.1 本番同等性と差異の記録
環境構築では、可能な範囲で本番と同じ構成を再現する。差異が存在する場合は、性能への影響が出やすい項目（ストレージ種別、CPU世代、ネットワーク遅延、タイムアウト設定など）を記録する。記録がなければ比較の意味が薄れるため、試験報告書に明示する。
4.1.2 ネットワーク条件の再現
ネットワーク条件は性能に直結するため、遅延や帯域、パケットロスをできるだけ再現する。仮想ネットワークやローカル環境では現実と乖離することがあるため、測定対象に応じて調整する。再現に失敗している場合は、結果の解釈を過度に一般化しない姿勢が必要になる。
4.2 実行計画（スケジュール）
4.2.1 ウォームアップと測定区間
ウォームアップは初期化やキャッシュ形成の影響を測定に混ぜないために行う。測定区間は一定条件が維持された時間帯に限定し、その開始条件を揃える。スケジュールの一貫性は比較の前提になるため、計画書にタイミングと負荷手順を明記する。
4.2.2 併走負荷の管理
併走負荷を伴う場合、どのサービスが同時に稼働しているかを明確にする。テスト対象外の要因で競合が発生すると、ボトルネックが判別しにくくなる。必要なら分離環境を用意し、少なくとも負荷配分と同時性の設計を記録する。
4.3 結果の可視化
4.3.1 レイテンシ分布（平均・中央値・分位）
可視化では分布を重視する。中央値は典型的な体験を示し、分位点は遅延の尾を表す。平均だけに依存すると外れ値の影響を見落とすため、箱ひげ図やヒストグラム、分位線を用いて理解を促進する。
4.3.2 スループット推移
スループット推移は時間軸で追い、負荷段階との整合を確認する。増加が頭打ちになる時点は、内部資源や外部依存が限界に達している可能性がある。レイテンシと同時に見ることで、単なる遅さか、能力低下かを切り分けやすくなる。
4.3.3 エラー要因の特定
エラー要因は、ステータスコードや例外種類、外部呼び出しの失敗理由に分解する。発生タイミングが負荷上昇と同期しているか、ある閾値を超えて急増するかも重要である。原因を分類できると、修正の優先度を付ける根拠になる。
4.4 ボトルネック解析
4.4.1 リソース飽和の読み解き
リソース飽和は、特定指標の急激な増加や横ばいによって示される。CPUは余裕があるのにレイテンシが伸びる場合、待ち行列やロック、I/O待ちが関与していることがある。指標を段階的に重ね、律速箇所の仮説を形成していく。
4.4.2 ボトルネックの切り分け手順
切り分けは、再現性のある観測点から段階的に進める。まず対象フローの中で遅い区間を特定し、次に外部依存と内部処理を分ける。さらに統計情報やトレースを用いて、どのデータアクセスやコード経路が寄与しているかを絞り込む。仮説検証として設定変更やサンプル実験を行うことで、確度を高める。
4.5 改善サイクル
4.5.1 チューニング方針（設定、キャッシュ、並列化）
改善では、変更コストと効果のバランスを取る。設定調整ではタイムアウト、スレッド数、コネクション管理などが対象になり、キャッシュではヒット率と一貫性の要件が鍵になる。並列化は性能向上の余地がある一方で、共有資源の競合が増える可能性があるため、計測に基づく段階的導入が望ましい。
4.5.2 再テストと効果検証
再テストは、改善の効果が目標達成につながったかを確認する工程である。比較は同一のシナリオと指標で行い、分布の変化や失敗率の低下も含めて評価する。改善が部分的にしか効いていない場合は、別の律速箇所が顕在化した可能性を検討し、次の仮説へ進む。
5 よくある課題と対策
5.1 測定の落とし穴
5.1.1 監視自体の負荷
監視やログ収集は性能に影響し得る。大量の同期書き込みや、詳細トレースの常時取得はレイテンシを押し上げるため、計測オーバーヘッドを見積もり、必要な粒度に調整する。メトリクスはサンプリングや集約を活用し、精度と負荷の均衡を取る。
5.1.2 タイミング依存の誤解
結果が特定の時刻やウォームアップ直後に強く依存している場合、測定設計の問題である可能性がある。測定区間の切り方、負荷投入の間隔、キャッシュ状態の揃え方が不適切だと、比較が崩れる。タイムラインに基づいて再評価し、定常状態かどうかを確認する。
5.2 データと条件の不一致
5.2.1 テストデータの偏り
データ分布が現実と異なると、キャッシュ挙動やインデックス利用状況が変わり、性能像が置き換わる。特定キーへの集中、更新頻度、参照の連鎖などが一致していないと、律速要因が別物になる。利用統計やDB実査に基づき、偏りの程度を合わせる努力が必要である。
5.2.2 環境差（容量、タイムアウト）
テスト環境の容量が不足すると、本番で存在しない制約が出現する。ストレージ速度やネットワーク設定、タイムアウトの差も結果に影響する。差異は単なる注記ではなく、性能に与える方向性を理解したうえで補正の余地を検討する。
5.3 指標の解釈ミス
5.3.1 平均値のみでの判断
平均値は分布の形を覆い隠しやすく、利用者が感じる遅延の増加を見逃すことがある。長い尾を持つ場合は分位点の方が実態に近い。平均と分布を組み合わせ、設計判断に足る根拠を確保する。
5.3.2 エラー率の見落とし
失敗は全体性能を損なうだけでなく、再試行やフォールバックによって追加負荷を生む。エラー率が低く見えても、特定エンドポイントや特定条件で局所的に悪化している場合がある。成功・失敗を内訳で追い、原因別の傾向を確認する。
5.4 失敗から学ぶ運用
5.4.1 再現性確保
失敗が偶発的なものか、設計上の問題かを判断するには再現性が必要になる。環境差やデータ更新の有無、負荷ジェネレータの条件を固定し、同じ手順で結果が出るか検証する。再現に成功しない場合は、観測の信頼度を下げない形で追加情報を集める。
5.4.2 学習事項の記録と共有
学習事項は、原因仮説、検証手段、改善結果、次回の注意点として整理する。文章だけでなく、指標の変化や構成変更の対応関係を残すと再利用性が高まる。共有により同種の誤りを減らし、性能テストの成熟度を継続的に引き上げる。
6 運用・自動化・ガバナンス
6.1 CI/CDへの統合
6.1.1 変更点に応じたテスト選択
CI/CDでは全ての性能試験を毎回実行するとコストが大きい。変更領域（データアクセス層、APIハンドラ、インフラ設定など）に応じて、軽量な回帰から段階的に重い試験へ割り当てる。選択ルールを明文化することで、速度と品質の両立を図る。
6.1.2 回帰性能テスト
回帰性能テストは、過去の基準から性能が劣化していないかを確認する役割を持つ。比較には同一シナリオと指標を用い、閾値超過時には差分の解析へ進める。成功条件は平均ではなく、分位点やエラー内訳も含めて定めることが望ましい。
6.2 自動化の設計
6.2.1 シナリオ管理とバージョン
自動化ではシナリオの管理が重要である。負荷手順やデータ前提、観測設定がバージョンとして追跡されていないと、過去結果との比較が崩れる。テストコードと設定を連携させ、変更履歴が追える形に整備する。
6.2.2 レポート自動生成
レポートは合否だけでなく、主要指標の推移と分布、主要エラー分類、関連ログへの参照を含める。自動生成により作業が定型化され、レビューの速度も上がる。出力フォーマットを統一すると、過去の案件との比較が容易になる。
6.3 責任分界と報告
6.3.1 誰が何を決めるか
責任分界は、測定設計の承認、目標値の設定、合否判断の最終責任などを明確化する。性能要件は技術だけでなく事業判断にも関わるため、意思決定者と技術担当を区別し、判断プロセスを可視化する。曖昧さが残ると、手戻りや対立の原因になる。
6.3.2 意思決定に必要な情報の整理
意思決定には、数値だけでなく前提条件と解釈の根拠が必要である。環境差、測定区間、データ分布、異常時の扱いなどを揃えたうえで、改善の提案とリスクを添える。情報の粒度が適切であれば、次の投資判断が迅速になる。
6.4 機密情報の取り扱い
6.4.1 個人情報・秘匿データの扱い
テストでは個人情報や機密情報が混入しないよう設計する。準実データを扱う場合はマスキングや匿名化を行い、復元可能性を排除する方針を取る。アクセス制御と保管期間の管理も含めて、法令や社内規程に沿って運用する。
6.4.2 ログ保護と匿名化
ログには要求パラメータや識別子が含まれやすく、漏えいリスクがある。保存前に秘匿対象をマスクし、相関用の識別子は権限の範囲内でのみ参照できるようにする。監視基盤から外部参照へ出す場合は、匿名化の度合いと用途を整理し、必要最小限の情報だけを残す。