負荷テスト手法

目的: 年末セールで通常の10倍のアクセスが見込まれる。システムが耐えられるか事前検証。

シナリオ設計: 本番ログから分析。60%が商品閲覧、25%がカート操作、15%が決済。k6でスクリプト化。

テスト結果:

• 通常負荷（500 RPS）: p99 150ms、エラー率 0.01% → OK
• 想定ピーク（5,000 RPS）: p99 800ms、エラー率 0.5% → 許容範囲ギリギリ
• 限界テスト（8,000 RPS）: p99 5秒超、エラー率 15% → DBの接続プールが枯渇

改善: DB接続プール拡大 + 商品一覧のキャッシュ導入 → 再テストで10,000 RPSまで p99 300ms で安定。セール当日のピーク7,000 RPSを問題なくさばけた。

状況: 本番環境で週に1回、APIサーバーが応答しなくなりOOM Killerで強制終了。通常の負荷テストでは再現しない。

耐久テスト実施: 本番同等の負荷（200 RPS）を24時間連続投入。

発見: 8時間経過後からメモリ使用量が線形に増加。12時間後にp99が3秒を超過。原因はHTTPクライアントの接続プールが正しくクローズされておらず、リクエストごとにソケットがリークしていた。

修正: HTTPクライアントのdefer resp.Body.Close()漏れを修正。再テストで24時間後もメモリ使用量が安定（1.2GB→0.4GBで安定）。週次のOOM Killerが完全に解消。

状況: TV CMの放映後にアクセスが瞬間的に20倍になることが予想される。ECSのオートスケーリングが間に合うか検証。

スパイクテスト: 通常負荷（300 RPS）→ 30秒で6,000 RPSに急増 → 5分維持 → 300 RPSに戻す。

結果: スケールアウト開始まで90秒。その間にp99が8秒に悪化し、エラー率12%。CMの視聴者がアクセスする最初の90秒間にユーザーが離脱する問題。

対策: CM放映15分前にPre-warmでタスク数を事前に3倍に増加する運用ルールを策定。再テストでスパイク時もp99 400ms、エラー率0.1%以下を達成。