Distributed Load Testing on AWS で大量トラフィックを生成し、Auto Scaling のスケールアウトを観察する
Distributed Load Testing on AWS（DLT）は、Amazon ECS（Fargate）上でTaurus / JMeter / k6 / Locust を分散実行し、Web アプリケーションや API に対して大規模な負荷を生成する AWS 公式ソリューションです。このハンズオンでは DLT をデプロイし、ALB + Auto Scaling 配下のシステムへ負荷をかけて、スケールアウトと応答時間の変化を観察します。
| 項目 | 内容 |
|---|---|
| 対象サービス | Distributed Load Testing on AWS（ECS Fargate、API Gateway、Lambda、Cognito、CloudFront/S3）、ALB、Auto Scaling、CloudWatch |
| 主な学習内容 | ソリューションのデプロイ・テストシナリオ作成・負荷実行・結果分析・スケールアウト観察 |
| 所要時間 | 60〜75 分（デプロイ待ち約 15 分を含む） |
| 難易度 | ★★★☆☆（中級者向け） |
| 前提知識 | ALB・Auto Scaling・CloudFormation の基礎知識 |
| 費用目安 | 約 2〜5 USD（Fargate タスク・対象 EC2 のスケールアウト分。テスト時間に依存） |
「高負荷の最中にインスタンス障害が起きても耐えられるか？」を確認するには、本ハンズオンの負荷生成と AWS FIS ハンズオン の障害注入を組み合わせると、よりリアルなレジリエンス検証になります。
DLT が Fargate タスクから負荷を生成し、対象システム（ALB + Auto Scaling）へリクエストを送ります。
DLT は実際に大量のトラフィックを生成します。必ず自分が所有・管理する検証用エンドポイントを対象にしてください。第三者のサイトへの負荷テストは規約違反・攻撃とみなされます。
AWS CLI・Git・Docker などのインストールと初期設定は 環境セットアップガイド にまとめています。初めての方は先にご確認ください。
DLT のデプロイ自体は小さい構成ですが、テスト中は Fargate タスクと、スケールアウトした対象 EC2 に課金されます。タスク数・並列数・実行時間を欲張らないこと。作業リージョンは ap-northeast-1（東京） に固定し、終了後は必ずクリーンアップしてください。
AWS 公式ソリューションを CloudFormation で 1 クリック展開します（所要約 15 分）。
ブラウザで「Distributed Load Testing on AWS」の実装ページ（aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/）を開き、「Launch in the AWS Console」 をクリックします。CloudFormation のスタック作成画面が開きます。
主なパラメータは次のとおりです（既定値のままで問題ないものは省略）。
Web コンソールのホスティングは既定の CloudFront + S3 でOKです。
「機能と変換」で IAM リソース作成の承認（CAPABILITY_IAM 等）にチェックを入れ、スタックの作成をクリックします。CREATE_COMPLETE になるまで約 15 分待ちます。
スタックの 出力（Outputs） タブに表示される ConsoleURL（CloudFront の URL）が、負荷テスト用 Web コンソールの入口です。
デプロイ完了後、入力したメールアドレス宛に Amazon Cognito からユーザー名と仮パスワードが届きます。件名は「Welcome to Distributed Load Testing」等です。
ステップ 1 の ConsoleURL を開き、メールのユーザー名・仮パスワードでサインインします。初回はパスワードの変更を求められるので、新しいパスワードを設定します。
ログイン後、DLT のダッシュボード（テスト一覧画面）が表示されれば成功です。
シナリオ作成は「一般設定 → シナリオ定義 → トラフィックシェイプ → レビュー」の 4 ステップです。
ダッシュボードで 「Create test」 をクリックします。
テストタイプは Single HTTP Endpoint を選びます（JMeter/k6/Locust スクリプトのアップロードも可能）。
必要に応じて Request Header（例: Content-Type: application/json）や Body を追加できます。
負荷の形を決めます。最初は小さめから始めましょう。
1 タスク（既定 2 vCPU / 4 GB）あたりの適正な並列数は、CloudWatch の Container Insights で Fargate タスクの CPU/メモリを見ながら少しずつ増やして調整します。まず 200 ユーザー以下で様子を見るのが安全です。
設定内容を確認し、「Run Now（または Submit）」 でテストを開始します。
テスト詳細画面でステータスが Running になり、Fargate タスクが起動して負荷が始まります。Live data を有効にしていれば、平均応答時間・仮想ユーザー数・成功/失敗リクエスト数が 1 秒間隔で更新されます。
テスト完了後、結果サマリーに以下が表示されます。
| 指標 | 意味 |
|---|---|
| Avg Response Time | 平均応答時間（小さいほど良い） |
| p90 / p95 / p99 | パーセンタイル応答時間（外れ値・テール遅延の把握） |
| Requests Per Second | 処理できた秒間リクエスト数（スループット） |
| Failed Requests / Errors | 失敗数・エラー率（限界を超えると増える） |
負荷をかけている間、対象システム側で Auto Scaling が反応する様子を別タブで確認します。
EC2 → Auto Scaling グループ → 対象グループ → アクティビティ。CPU 使用率の上昇によりスケーリングポリシーが発動し、インスタンスが追加起動されるログを確認します。
RequestCount、TargetResponseTime、HTTPCode_Target_5XX_CountCPUUtilization（平均）と InService インスタンス数負荷 → CPU 上昇 → インスタンス増加 → 応答時間が回復、という一連の流れを確認できれば、スケーリング設計が機能しています。
healthy になるまでのタイムラグFargate タスクやスケールアウトした EC2 が残ると課金が続きます。以下を漏れなく削除してください。
Running の場合は Cancel で停止する
handson-load-testing スタックを削除。S3 バケットや ECR が空でなく削除に失敗する場合は、中身を空にしてから再削除する
DELETE_COMPLETE（または一覧から消えた）| 習得したスキル | 実践内容 |
|---|---|
| 負荷テスト基盤の構築 | Distributed Load Testing on AWS を CloudFormation でデプロイ |
| テストシナリオの設計 | エンドポイント・タスク数・並列数・Ramp Up / Hold For の設定 |
| 性能指標の読み取り | RPS・平均/パーセンタイル応答時間・エラー率の分析 |
| スケーリングの検証 | 負荷と Auto Scaling・ALB メトリクスの相関の観察 |