アプリケーションは 10 人のユーザーに対して完全に動作します。 1万個の場合、発売日には何が起こるでしょうか？ 負荷テストとストレス テストでは、これに答えるための 2 つの異なる方法について説明しています。これらを混同すると、テストが行​​うと考えられていることが証明されないことになります。

このガイドでは、それぞれが何を示すか、関連するテストの種類、結果の見方について説明します。シミュレートされた数値を使用して、Python 3.13 で以下の小さなパーセンタイルの計算を実行しました。 k6 スクリプトは説明のための例であり、私たちが実行したものではありません。ユーザー数とターゲットは作成されたものであるため、独自のものに置き換えてください。大量のトラフィックは攻撃のように見え、実際の停止を引き起こす可能性があるため、これらのテストは自分が所有するシステムまたはテスト権限のあるシステムに対してのみ実行してください。

短い答え

負荷テストでは、予想されるトラフィックを処理でき、実行中に目標を達成できるかどうかが問われます。 ストレス テストでは、失敗する前にどれだけ耐えられるか、どのように失敗するか、そしてどれくらい早く回復するかが問われます。

橋を思い浮かべてください。負荷テストでは、予想される数のトラックを走行させ、問題がないことを確認します。ストレス テストでは、その限界を知るために重みを追加し続け、最初に警告を発するかどうかを確認します。幸いなことに、ソフトウェアは橋を壊すよりも安価に壊れます。

負荷テストとストレス テストを並べて実行する

負荷テストとは何ですか?

負荷テストは、予想される現実的なトラフィックをシミュレートし、システムがどのように動作するかを測定します。たとえば、「同時ユーザー 500 人の場合、チェックアウト リクエストの 95% が 800 ミリ秒以内に完了し、エラーは 1% 未満である」などのテスト対象が必要です。

これが k6 スクリプトとしてどのように見えるかを次に示します。 k6 テストは JavaScript で記述されており、thresholds ターゲットを合格または不合格の結果に変換します。

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleepが重要です。考える時間もなく、各仮想ユーザーは継続的にサーバーにアクセスし、同じ数の実際の人間が発生するよりもはるかに多くのトラフィックを生成します。

ストレステストとは何ですか?

ストレステストは意図的に予想レベルを超えます。あなたは通過しようとしているわけではありません。次のような質問に対する答えが必要です。

• どのレベルからパフォーマンスが低下し始めますか?
• データベース、アプリケーション サーバー、またはサードパーティの呼び出しのうち、どのコンポーネントが最初に失敗しますか?
• 明らかなエラーが発生して正常に失敗しますか? それともクラッシュしてデータが失われますか?
• トラフィックが減少した場合、自動的に回復しますか?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

最後の回復段階は忘れられがちですが、最も価値のある段階である可能性があります。障害には適切に対処できても、手動で再起動しないとシステムが回復しない場合でも、誰かが夜中に修理しなければならないシステム停止が発生することになります。理想的には、極度の負荷の下では、システムは制御された方法で作業を中断し、タイムアウトするのではなく明確な 503 応答 を返す必要があります。

スパイク、ソークなどの種類

負荷テストとストレス テストは、より広範なパフォーマンス テストに属します。

ソーク テストは、ショート テストでは決して検出されない問題を検出します。小規模なメモリ リークは、20 分間は無害に見えますが、サービスがダウンするのは 2 日後です。スパイク テストは、フラッシュ セールなど、トラフィックが徐々に増加しないイベントに適しています。

重要な指標

平均値が誤解を招く理由

平均値は、実際の人々が不満を抱いている遅いリクエストを隠します。これを示すために、100 件の応答時間をシミュレートし、95 件が高速 (80 ～ 200 ミリ秒)、5 件が非常に遅い (2.5 ～ 4 秒) ものとし、一般的な統計を計算しました。

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

その数字をよく見てください。平均 302 ミリ秒では、誰も記述されていません。一般的なリクエストには約 150 ミリ秒かかりましたが、遅いリクエストには 3 秒以上かかりました。 p95 でさえ 199 ミリ秒では正常に見えますが、p99 だけが問題を明らかにします。 p95 のような数字は、リクエストの 95% がこの速度以上であることを意味します。

そしてリクエストの 1% は珍しいことではありません。ページが 50 件のリクエストを行う場合、p99 が遅いとページビューの大部分に影響を与えます。自分にとって重要なパーセンタイルに目標を設定し、複数のパーセンタイルを一緒に検討します。

ツール

これらのいずれでも、負荷テストとストレス テストの両方を実行できます。機能リストを追いかけるのではなく、チームのスキルに合ったものを選択してください。パイプラインで使用するには、CI/CD とはを参照してください。

テストを計画する方法

1. 目標を設定します。 実際の分析を使用してピーク時のトラフィックを見つけ、目標を定義します。
2. ジャーニーを選択します。 閲覧、検索、チェックアウトなどの現実的なユーザー行動を現実的な比率でモデル化します。ホームページにアクセスするだけでは、ほとんど意味がありません。
3. 現実的な環境を使用します。 小さなステージング サーバーでは本番環境を予測できません。相違点がある場合は注意してください。
4. データを準備します。 100 行で高速なクエリは 1,000 万行でクロールされる可能性があるため、現実的なボリュームを使用します。
5. 人々に警告します。 運用チームおよび第三者に通知し、誤って決済プロバイダーの負荷テストを行わないでください。必要に応じて外部サービスをモックします。
6. 小規模から始めます。 まず小規模なスモーク テストを実行して、スクリプトが機能することを確認します。
7. すべてを監視します。 サーバー指標がなければ、速度が低下したことはわかりますが、なぜはわかりません。
8. 繰り返します。 修正するたびに再度実行し、比較するベースラインを保持します。

結果を読む

データベースが一般的なボトルネックとなるため、クエリが問題となっている場合は、SQL クエリの最適化 に関するガイドをお読みください。テーブルの最後の行は重要な罠です。負荷を生成しているマシンの健全性も常にチェックしてください。

よくある間違い

• ユーザーとリクエストを混同する。 ターゲットが同時ユーザーを意味するのか、1 秒あたりのリクエストを意味するのかを明確にしてください。
• 思考時間を省きます。これによりトラフィックが増大し、誤解を招く結果が生じます。
• テストが遅すぎます。 発売の 1 週間前になると、アーキテクチャの問題を修正する時間がありません。
• 単一エンドポイントの使用。 実際のトラフィックには、読み取り、書き込み、検索が混在します。
• キャッシュによりすべてが隠蔽されます。 同じリクエストを繰り返してもキャッシュがテストされるだけの可能性があるため、データを変更してください。
• テストは 1 回のみ。 リリースごとにパフォーマンスが変化するため、定期的にテストを実行します。

まとめ

負荷テストを実行して、予想されるトラフィックを処理できることを確認し、ストレス テストを実行して、処理できない場合に何が起こるかを確認します。小規模から始めます。最も重要なユーザー ジャーニーを選択し、明確な目標を 1 つ設定し、モニタリングをオンにしてステージングに対して短いテストを実行します。通常、最初の実行で何かを学び、そこから構築することができます。

よくある質問

学び続ける