性能のテスト

負荷テストは、多くの利用者が同時に使ったときに、速さと安定が目標を満たすか、どこまで耐えられるかを確かめるテストです。k6、JMeter、Gatling、Locust などの道具でリクエストを大量に送ります。

シナリオの作り方

• 実際の使われ方に合わせる：アクセスのログや分析から、よく使われる操作とその割合を出す（例：一覧を見る 70%・詳細 25%・購入 5%）。1つの API だけを叩き続けると、キャッシュが効いて実際より良い結果になりがちです。
• 目標の量を決める：普段の最大のアクセス、セールなどの山、その何倍まで耐えるべきか。
• 種類を使い分ける（下の表）。
• 本番に近い環境で流す。データ量が少ない環境では、遅い SQL が見つかりません。外部サービス（決済など）はモックにし、本番や他社に負荷をかけないよう事前に合意します。

応答時間は平均ではなくパーセンタイルで見ます。p99 が 800ms なら「100 回に 1 回は 800ms より遅い」という意味で、平均が良くても一部の利用者は待たされていることが分かります。

負荷を少しずつ上げると、ある所から応答時間が急に伸び、エラー率が上がり、処理量（毎秒のリクエスト数）が増えなくなります。そこが限界点です。そのとき CPU・メモリ・DB の接続数・遅い SQL のどれが先に詰まったか（ボトルネック）を、監視の画面と合わせて見ます。

落とし穴：負荷をかける側のマシンが先に限界になっていないか（送る側の CPU）も確認します。

負荷試験とキャパシティ計画（SRE）

レイテンシの見方（パーセンタイルとテール）（SRE）

k6 は JavaScript でシナリオを書く負荷テストの道具です。コードで書けるので、レビューや CI への組み込みがしやすいのが特徴です。

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // 2分で100人まで増やす
    { duration: '5m', target: 100 },  // 5分保つ
    { duration: '1m', target: 0 },    // 1分で0へ
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% が 500ms 未満
    http_req_failed: ['rate<0.01'],    // 失敗が 1% 未満
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/items');
  check(res, { '200 が返る': (r) => r.status === 200 });
  sleep(1);  // 利用者が考える時間
}

負荷テストは、結果が正しく読めるかどうかが準備で決まります。また、他のシステムに迷惑をかけないよう、事前の合意が欠かせません。

結果の報告には、条件（環境・データの量・シナリオ・時間）を必ず書きます。条件がそろっていないと、前回と比べられません。

ボトルネックは、処理の流れの中で一番詰まっている所です。そこが全体の速さを決めるので、他を速くしても効果がありません。限界点に来たとき、何が先に詰まったかを監視の画面で探します。

QA が原因を直すことは少ないですが、「何人のときに、何がどうなったか」を監視の数字と一緒に報告すると、開発者や SRE がすぐ動けます。

負荷試験とキャパシティ計画（SRE）

サーバーが速くても、画面の表示が遅ければ利用者には遅く感じます。Web の画面の体感の速さは、Google が示す Core Web Vitals の3つの指標で見るのが一般的です。

テストでは、遅い端末と遅い回線（開発者ツールで CPU と通信を遅くする）でも確かめます。速い PC と社内の回線だけで見ていると、利用者の体感とずれます。