AWS EC2 Worker と SQS ストレステスト手順ガイド（Part 2）
本記事（Part 2）では、実際にストレステストを実施するための
JMeter 設定、AWS 側監視ポイント、結果分析方法を整理します。
1. テストシナリオの詳細
Case 1：500 threads / 60 秒
- Throughput：8.3 req/s
- Success：100%
- 平均応答：227ms
- 最大応答：307ms
- Worker CPU：60〜70% 程度
- SQS：バックログなし
- RDS：接続枯渇なし
これにより中負荷で十分安定していると評価できます。
追加シナリオ例（推奨）
より実践的な検証のため、次のような追加シナリオも有効です。
- Burst Test：短時間で大量メッセージ投入
- Degrade Test：DB の接続数を意図的に低下
- Long Duration：1〜3時間の長期連続テスト
- Thread Variations：Worker の Thread 数を変化させて最適値を探索
2. JMeter 設定手順
Thread Group の構成
Thread Group:
Number of Threads: 500
Ramp-up Period: 60
Loop Count: 1
HTTP Request の設定
POST https://{api-id}.execute-api.{region}.amazonaws.com/prod/push
Body:
{
"messageId": "${__UUID()}",
"payload": "${__RandomString(32,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890)}",
"timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
}
Headers:
Content-Type: application/json
x-api-key: ${API_KEY}
非 GUI モードで実行
jmeter -n -t HTTPRequest_500_60_001.jmx -l results.csv -JAPI_KEY=xxxx
負荷をより現実的にするためには：
- Stepping Thread Group の利用
- CSV Data Set で payload を変化
- Timer でランダムディレイを挿入
なども効果的です。
3. CloudWatch の監視ポイント
テスト中に確認すべきメトリクスと理由は次の通りです。
| メトリクス | 意味 | 重要性 |
|---|---|---|
| QueueDepth | 未処理メッセージ数 | Worker 遅延の指標 |
| OldestMessageAge | 最古メッセージ滞留時間 | バックログの発生 |
| CPUUtilization | Worker の負荷 | Thread 設定を最適化 |
| MemoryUtilization | メモリ使用率 | 予期せぬ OOM を防ぐ |
| DBConnections | 接続数 | Connection Pool 枯渇対策 |
| Error Count | Worker の例外数 | 処理失敗の早期検知 |
4. 結果分析方法
ストレステストの分析では、以下を複合的に見ます。
● QueueDepth が増え続ける場合
→ Worker が処理に追いついていない
対策：Thread 増加 / EC2 スケールアウト / DB 改善
● CPU が 100% 張り付き
→ Worker がボトルネック
対策：コード最適化 / インスタンスサイズ変更
● DLQ にメッセージが増える
→ 処理失敗 or 処理遅延
対策：Retry ポリシー見直し、例外ログ調査
● Throughput が頭打ち
→ JMeter・SQS・ネットワークいずれかが制限
対策：JMeter の負荷生成能力や API Gateway の制限も確認
5. まとめ（Part 2）
Part 2 では、
- JMeter を用いたテスト手順
- CloudWatch の監視要点
- 実行結果の分析方法
を解説しました。
Part 1 と合わせて読むことで、
AWS 非同期基盤におけるストレステストの全体像を把握できる内容になっています。
(https://qiita.com/philai/items/c5ff74c5c232957777a7)