負荷テスト

負荷テストとは

負荷テスト (Load Testing) は、システムに大量のリクエストを送り、性能限界やボトルネックを特定するテスト手法である。本番トラフィックを模擬し、レスポンスタイム、スループット、エラー率を測定する。

テストの種類

テストの種類を以下にまとめる。

種類	目的	パターン
負荷テスト	想定負荷での性能確認	一定の負荷を維持
ストレステスト	限界値の特定	負荷を段階的に増加
スパイクテスト	急激な負荷増への耐性	突然の負荷急増
耐久テスト	長時間稼働の安定性	一定負荷を長時間維持

k6 での負荷テスト

k6 での負荷テストのコード例を示す。

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

export const options = {
  stages: [
    { duration: '1m', target: 50 },   // 1分で50ユーザーまで増加
    { duration: '3m', target: 50 },   // 3分間50ユーザーを維持
    { 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://api.example.com/users');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

ツール比較

主なツールを以下にまとめる。

ツール	言語	特徴
k6	JavaScript	軽量、CI/CD 統合が容易
Artillery	YAML/JS	AWS Lambda での分散実行
Locust	Python	リアルタイムダッシュボード
JMeter	Java	プロトコル対応が豊富、テスト計画を GUI で組める

JMeter は公式に「GUI はテスト計画の作成にだけ使い、負荷テストの実行は CLI (非 GUI) モードで行う」と明示している。GUI で走らせると JMeter 自身が処理を食って測定値が歪むため、実行は CLI、結果は終了後の HTML レポートで見るのが正しい使い方である。

Lambda + API Gateway の負荷テスト

確認すべき項目は、コールドスタート (初回リクエストのレイテンシ)、同時実行数 (リージョンあたり既定 1,000・引き上げ申請で数万まで広げられる)、API Gateway スロットリング (429 エラーの発生率)、DynamoDB スロットリング (ProvisionedThroughputExceededException) である。

必要な同時実行数は「秒間リクエスト数 × 1 リクエストの平均実行時間 (秒)」でおおよそ見積もれる。平均 200 ms の関数に 1,000 req/s を流すなら約 200 の同時実行で足りるが、実行時間が 2 秒に伸びれば 2,000 になり既定枠を突き抜ける。負荷テストで見るべきは「捌けたか」だけでなく、レイテンシの悪化が同時実行数を押し上げて枠に当たる連鎖である。

よくあるボトルネック

DB 接続数の枯渇はタイムアウトとして現れ、RDS Proxy やコネクションプーリングで対策する。Lambda 同時実行の上限は 429 エラーを引き起こし、上限引き上げ申請で対応する。DynamoDB の書き込み容量不足はスロットリングを起こす。オンデマンドモードは容量の見積もりを不要にするが、スロットリング自体はなくならない。パーティション 1 つが出せる上限は読み込み 3,000 ユニット/秒・書き込み 1,000 ユニット/秒でモードによらず共通であり、テーブル単位でもオンデマンドの既定枠は読み書きそれぞれ 40,000 リクエストユニット/秒 (引き上げ可) である。負荷テストで特定のキーに集中したスロットリングが出るなら、モード変更ではなくパーティションキーの偏りを直すのが解である。API Gateway のスロットリングは設定の調整で対応する。

理論と実装の両面から学ぶなら関連書籍が参考になる。

サイト情報