3分でわかる初めての負荷テスト
🧪 3分でわかる初めての負荷テスト
―― 家計簿アプリを例に、プロジェクトマネージャーでも理解できる負荷テスト設計
📘 1. SLOとp95を理解しよう
負荷テストとは、アプリが「どの程度の負荷まで快適に動作するか」を確認するテスト。
「遅い・落ちる・詰まる」を防ぐために、性能を数値で保証するのが目的です。
✅ SLO（Service Level Objective）
サービス品質の目標値。
例：
画面が開くまで300ms以内を95％のアクセスで達成する
✅ p95（95th percentile）
全リクエストのうち95％がこの時間以内に処理されるという指標。
平均よりも実際のユーザー体験に近い指標として使われます。
💡 家計簿アプリのSLO例
| 機能 | 指標 | 目標値 |
|---|---|---|
| 明細登録API | p95 | 300ms以内 |
| ダッシュボード表示 | p95 | 800ms以内 |
| CSV取込 | 処理時間 | 5秒以内に受付完了 |
「この速さを守れたらOK」という明確な基準を設けることが、負荷テスト設計の出発点です。
📗 2. どんな条件でテストするか（RPSとR/W比）
負荷テストでは、現実に近い利用状況＝ワークロードを再現します。
✅ RPS（Requests Per Second）
1秒あたりのリクエスト数。
サーバがどのくらいの頻度でアクセスを処理できるかを示します。
✅ R/W比（Read/Write比）
データの読み込み（Read）と書き込み（Write）の割合。
家計簿アプリでは、日々の入力作業（登録）が多く、閲覧やレポート表示は補助的な操作が中心となる。
💡 家計簿アプリのワークロード例
| 操作 | 割合 |
|---|---|
| 新規登録 | 60% |
| 明細閲覧 | 25% |
| 編集 | 10% |
| 集計 | 5% |
✅ テストパターン例
| 状況 | RPS | 説明 |
|---|---|---|
| 通常時 | 800 | 平常運用を想定 |
| スパイク時 | 2,400 | 給料日などアクセス集中 |
| ストレステスト | 3,000〜 | システムの限界を確認 |
これにより、「どこで遅くなるか」「どの時点でサーバが悲鳴を上げるか」を測定します。
📙 3. 負荷テストで見るべき数値と注目ポイント
負荷テストは“実施”よりも“観察と分析”が本番です。
代表的な指標とその意味を、PM視点でも理解できるよう整理します。
✅ レイテンシ（Latency）
リクエスト送信からレスポンス受信までの時間。
短いほど快適。p95やp99などの分位数で評価します。
✅ キュー（Queue）
処理待ちの行列。
アクセス集中時に処理が詰まると、レスポンスが遅延します。
（例：CSV取込を一斉実行したときに登録が進まない）
✅ GC（Garbage Collection）
不要なメモリ領域を自動で解放する仕組み。
頻発すると処理が一時停止し、ユーザー体験を悪化させます。
✅ ボトルネック（Bottleneck）
処理全体を遅らせている要因。
データベースの遅延、キャッシュの欠如、ネットワーク遅延などが典型です。
💡 負荷テスト後の分析ポイント
- p95の応答時間がどの機能で悪化したか
- CPUやメモリ使用率が限界に達した箇所はどこか
- データベースクエリの遅延が発生していないか
🎯 まとめ：数字で語る品質保証へ
負荷テストは「勘」ではなく「データ」で品質を保証するための工程。
プロジェクトマネージャーがSLO・p95・RPSなどの言葉を理解しておくだけで、
開発者との議論が圧倒的にスムーズになります。
数字で説明できるプロジェクトは、強い。
負荷テストは、その“数字の言語化”プロセスです。
📖 参考書籍
『プロジェクトマネジメントの基本が全部わかる本
交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』
#PR
Discussion