負荷試験の計画書｜業務シナリオ・合格条件・中止条件の決め方

負荷試験の計画は、ツール名や同時接続数を決める前に、どの業務を、どの条件で、どこまで処理できればよいかを言葉にするところから始まります。「アクセスが増えても問題ないこと」だけでは、試験担当者と業務担当者が同じ合否を判断できません。

この記事は、クラウド上の業務システムで負荷試験を依頼・調整する担当者向けです。実行コマンドや特定サービスの推奨台数ではなく、計画書に残す条件と、結果から判断できる範囲を整理します。

負荷の単位を、実際の操作へ分解する

「利用者1,000人」は、そのまま毎秒1,000リクエストを意味しません。ログイン済みでも画面を読んでいる人と、一括登録を実行している人では、サーバーに届く処理が異なります。

まず対象期間を決め、実際の利用ログや業務予定から、操作の種類・頻度・集中する時間帯を整理します。資料がなければ仮定と明記し、観測値と混ぜません。

AWSの負荷試験ガイドでも、目的・シナリオ・監視を定め、本番に近い条件で結果を評価する考え方が示されています。AWS Well-Architected

合格条件と中止条件は別に書く

合格条件は「業務要件を満たしたか」の判定です。中止条件は「これ以上、試験を続けてよいか」の判定です。応答が遅くなっただけで終了する試験もあれば、合意した範囲で限界まで調べる試験もあります。目的を混ぜずに計画してください。

合格条件には、対象処理、計測区間、応答時間の指標、許容する失敗、必要な処理量を組み合わせます。平均値だけでは遅い応答を見落とす場合があるため、分位点を使うなら、どの割合を見るのかも揃えます。たとえば95パーセンタイルは、計測した応答の95%がその値以下となる位置を表します。失敗した要求を集計から外すかどうかも明記します。

中止条件には、試験対象外への影響、データ破損のおそれ、合意した費用・時間の超過などを記します。停止操作を行う担当と、停止後に確認する担当も必要です。共有基盤や外部連携先へ負荷が届くなら、対象範囲と実施可否を事前に確認します。

仮例：月初に集中する帳票出力を調べる

次は計画書の記入例です。実測結果や一般的な推奨値ではありません。

「月初の帳票作成を、指定した時間帯内に終えたい」という要望に対し、最初に帳票の種類と対象データ量を固定します。同じ帳票名でも、対象期間や行数が異なると比較が難しくなるためです。

1. 通常の帳票と大きい帳票を分け、各データ条件を記録する。
2. 少ない同時実行数から、合意した上限まで段階的に増やす。
3. 完了までの時間、成功・失敗件数、待ち行列、関連リソースを同じ時間帯で記録する。
4. 完了判定には、処理終了だけでなく帳票が必要な内容で生成されたことを含める。
5. 合格条件を満たさない場合、どの条件から変化したかを調べる。

この例でCPUだけを見て増強を決めると、待機の原因が外部連携や別の共有資源にある場合、判断材料が足りません。計画時点で「どの観測があれば原因候補を絞れるか」を担当者と相談します。

本番と異なる条件を、結果に添える

試験環境を本番へ近づけても、台数、データ量、接続先、キャッシュ、ネットワークなどに差が残ることがあります。差を隠さず、どの結論に影響するかを書き添えます。

負荷生成側の能力が不足すれば、想定した負荷を対象へ与えられていない可能性もあります。送信した量、受け付けた量、完了した量を区別すると、結果の読み違いを減らせます。

計画書を渡す前の確認

対象版・構成、業務シナリオ、負荷とデータの条件、合否と中止の基準、結果の保存先を一組で渡します。試験用データは機密性にも配慮し、AWSのガイドが挙げる合成データや機密情報を除いたデータなど、目的に適したものを選んでください。

費用の前提はクラウド費用の見積もり、継続的な通知条件は監視アラートの設計で別に整理できます。性能面で何を確認すべきか迷う場合は、対象業務と現在分かっている条件をまとめ、インフラ・クラウド支援の相談材料にしてください。