AWS EC2 Worker と SQS のストレステスト概要（Part 1）
はじめに
クラウド環境やマイクロサービスが主流となった現代では、非同期処理はシステムの拡張性と耐障害性を高めるための一般的な手法になっています。
特に API Gateway → SQS → EC2 Worker の構成は、疎結合・高可用性・スケーラビリティといった恩恵を提供するため、多くの企業システムで採用されています。
本記事（Part 1）では、この非同期処理アーキテクチャにおけるストレステストの必要性、目的、観測すべき指標、設計上の注意点について整理します。
1. 非同期アーキテクチャの特徴
非同期構成では、API がリクエストを受け取った後すぐに処理を返し、
実際の業務処理は SQS に格納したメッセージを EC2 Worker が後続で処理します。
メリット
- API のレスポンスが速く安定
- Worker の水平スケールが容易
- バーストアクセスに強い
- キューをバッファとして利用可能
デメリット / 注意点
- バックログ発生時の遅延が増える
- Worker の調整が必須（Thread Pool, CPU, Memory）
- DB や外部 API がボトルネックになりやすい
2. ストレステストの必要性
非同期システムでは、単純な API テストだけではシステムの性能を正しく測れません。
本当に重要なのは “どれだけのメッセージ流量を安定して処理できるのか” です。
ストレステストで確認すべき事項
- 1秒あたりの最大処理件数（Throughput）
- Worker が処理しきれない瞬間の挙動
- バックログが蓄積するかどうか
- SQS の可視メッセージ数の変動
- CPU / Memory / DB 接続数の推移
- 負荷減少後の回復スピード
3. 使用アーキテクチャの構成
本ストレステストでは、次の AWS アーキテクチャを対象とします。
| コンポーネント | 役割 | テスト観点 |
|---|---|---|
| API Gateway | リクエスト受付 → SQS 投入 | HTTP エラー・投入速度 |
| Amazon SQS | メッセージキュー | QueueDepth / OldestMessageAge |
| EC2 Worker | メッセージ処理（Java） | CPU / ThreadPool / 例外処理 |
| RDS | 永続化 | ConnectionPool / SlowQuery |
| CloudWatch | 監視 | 全メトリクスの可視化 |
4. テストデータの設計
テストデータは、実システムのユースケースや処理量に応じてカスタマイズします。
| テスト名 | 数量 | Ramp-up | req/s | 目的 |
|---|---|---|---|---|
| Load_500_60 | 500 | 60秒 | 約 8 req/s | 平均性能の測定 |
| Spike_2000_60 | 2000 | 60秒 | 約 33 req/s | バースト耐性 |
| Stable_10000_300 | 10000 | 300秒 | 約 33 req/s | 長期安定性 |
さらに実運用を意識するなら以下も追加できます：
- 変動する payload サイズ（1KB〜200KB）
- 正常系・異常系混合データ
- 高負荷時に DB 遅延を挿入する Chaos Test
- Worker Thread を動的に増減させるテスト
5. まとめ（Part 1）
Part 1 では、非同期システムにおけるストレステストの背景と考え方を整理しました。
Part 2 ではより実践的に、
AWS EC2 Worker と SQS ストレステスト手順ガイド
を具体的に紹介します。