DLT_Course_All.pdf

Transcript

1. AWS Distributed Load Testing 大規模負荷テスト完全マスター 〜数千〜数万同時接続をサーバーレスで〜 コース紹介 1
2. DLT の概要とアーキテクチャ CloudFormation でのデプロイ（約15 分） Web コンソールでテスト作成・実行 JMeter スクリプトの活用 テスト結果の分析 コスト最適化テクニック このコースで学ぶこと 2
3. Web アプリの負荷テストをしたい方 AWS の基本操作ができる方 JMeter を使ったことがある/ 興味がある方 本番リリース前のパフォーマンス検証をしたい方 こんな方におすすめ 3
4. Before After 負荷テスト環境の構築が大変 15 分でデプロイ完了 数台のサーバーで限界 数千〜数万同時接続 結果の分析が難しい パーセンタイル・グラフで可視化 コストが読めない 使った分だけ課金 コース終了後にできること 4
5. ハンズオン形式 → 一緒に手を動かしながら進めます サンプルスクリプト公開 → JMeter スクリプトを提供 Q&A サポート → 質問はQ&A セクションへ コースの進め方 5
6. サービス 費用 Fargate (10 タスク/1 時間) 〜$1.5 Lambda / API Gateway 無料枠内 DynamoDB / S3 〜$0.5 合計 約$2 〜3/ テスト ※使い終わったらスタック削除でOK AWS 費用の目安 6
7. 次のレクチャー → DLT とは何か？アーキテクチャ解説 それでは始めましょう！ 7
8. AWS Distributed Load Testing AWS が提供する負荷テストソリューション DLT とは 1
9. サーバーレス ECS Fargate で負荷生成、サーバー管理不要 スケーラブル タスク数を増やすだけで数千〜数万同時接続 JMeter 対応 既存スクリプトをそのまま使用可能 Web コンソール付き テスト作成・実行・結果確認がGUI で完結 DLT の特徴 2
10. ┌─────────────────────────────────────────────────────┐ │ ユーザー │ └─────────────────────┬───────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ CloudFront → S3 (Webコンソール) │ └─────────────────────┬───────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ API Gateway → Lambda (テスト管理) │ │ ↓ │ │ DynamoDB (設定・結果保存) │ └─────────────────────┬───────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │ Step Functions → ECS Fargate (負荷生成) │ │ (Taurus/JMeter) │ └─────────────────────────────────────────────────────┘ DLT アーキテクチャ 3
11. サービス 役割 CloudFront + S3 Web コンソールホスティング API Gateway + Lambda API バックエンド DynamoDB テスト設定・結果の保存 Step Functions テスト実行オーケストレーション ECS Fargate 負荷生成タスク実行 CloudWatch ログ・メトリクス収集 使用するAWS サービス 4
12. 項目 従来 DLT 環境構築 数日〜数週間 15 分 サーバー管理 必要 不要 スケール 手動で増設 タスク数変更のみ コスト 常時稼働 使った分だけ 従来の負荷テスト vs DLT 5
13. DLT はAWS 公式の負荷テストソリューション サーバーレスでスケーラブル JMeter スクリプトがそのまま使える Web コンソールで簡単操作 次のレクチャー → デプロイの準備 まとめ 6
14. CloudFormation でDLT をデプロイ 約15 分で環境構築完了 デプロイ準備 1
15. 1. AWS アカウント 管理者権限が必要 2. VPC とサブネット インターネットアクセス可能なサブネット パブリックサブネット or NAT Gateway 付きプライベート 3. メールアドレス ログイン用（一時パスワードが届く） 事前に必要なもの 2
16. インターネット ↓ ┌────────────────────────────────────┐ │ VPC │ │ ┌─────────────────────────────┐ │ │ │ パブリックサブネット │ │ │ │ → そのまま使える │ │ │ └─────────────────────────────┘ │ │ ┌─────────────────────────────┐ │ │ │ プライベートサブネット │ │ │ │ → NAT Gateway必須 │ │ │ └─────────────────────────────┘ │ └────────────────────────────────────┘ VPC/ サブネット要件 3
17. 推奨: ターゲットシステムに近いリージョン リージョン 用途 ap-northeast-1 ( 東京) 日本向けシステム us-east-1 ( バージニア) 北米向けシステム eu-west-1 ( アイルランド) 欧州向けシステム ※マルチリージョンテストも可能 リージョンの選択 4
18. 項目 コスト 1 時間テスト (10 タスク) 約$3 〜5 週1 回テスト 約$15 〜20/ 月 コスト削減Tips 学習後はスタック削除 → コストゼロ Fargate Spot → 約70% オフ コストの目安 5
19. ☐ AWS アカウントにログイン可能 ☐ VPC ID をメモ ☐ サブネット ID （2 つ、異なるAZ ）をメモ ☐ 受信可能なメールアドレスを用意 次のレクチャー → 実際にデプロイ！ 準備完了チェックリスト 6
20. ハンズオン CloudFormation でデプロイ 1
21. URL: aws.amazon.com/solutions/implementations/ distributed-load-testing-on-aws/ 「View in AWS Console 」をクリック → CloudFormation 画面に遷移 ソリューションページ 2
22. パラメータ 設定値 スタック名 distributed-load-testing AdminEmail your-email@example.com ExistingVPCId vpc-xxxxxxxx ExistingSubnetA subnet-xxxxxxxx (AZ-a) ExistingSubnetB subnet-yyyyyyyy (AZ-c) パラメータ設定 3
23. 1. パラメータ確認 → 「次へ」 2. スタックオプション → デフォルトのまま 3. IAM 確認 → 3 つのチェックボックスすべてON 4. 「スタックの作成」クリック スタック作成 4
24. ステータス: CREATE_IN_PROGRESS → CREATE_COMPLETE 約15 分待機 確認ポイント: リソースタブで作成状況を確認 Lambda, API Gateway, DynamoDB, ECS... デプロイ中... 5
25. 出力タブを確認: キー 値 ConsoleUrl https://xxxxxxxx.cloudfront.net メールを確認: 差出人: no-reply@verificationemail.com 内容: 一時パスワード デプロイ完了！ 6
26. 次のレクチャー → Web コンソールにログイン → 最初のテストを作成！ 次のステップ 7
27. ハンズオン Web コンソールへのログイン 1
28. 1. CloudFormation 出力のConsoleUrl にアクセス 2. メールアドレス入力（AdminEmail ） 3. 一時パスワード入力（メールで届いたもの） 4. 「サインイン」クリック ログイン手順 2
29. 要件: 8 文字以上 大文字・小文字・数字・記号を含む 例: MyTest@2024! パスワード変更 3
30. 左メニュー: メニュー 説明 Dashboard 概要とクイックアクション Create Test 新規テストの作成 Test History 過去のテスト結果 ダッシュボード 4
31. 次のレクチャー → 最初のテストを作成・実行！ 次のステップ 5
32. ハンズオン シンプルなテストの作成と実行 1
33. 左メニュー → 「Create Test 」 テスト作成画面 2
34. 項目 設定値 Name my-first-load-test Description 初めての負荷テスト 基本情報 3
35. 項目 設定値 説明 Task Count 1 Fargate タスク数 Concurrency 10 1 タスクあたり同時接続数 Ramp Up 30 秒 負荷を上げる時間 Hold For 60 秒 最大負荷維持時間 → 1 タスク × 10 同時接続 = 10 同時ユーザー テスト設定 4
36. 項目 設定値 HTTP Method GET Target URL https://httpbin.org/get ※httpbin.org = テスト用の公開API ターゲット設定 5
37. 1. 「Run Test 」クリック 2. 確認ダイアログで「Confirm 」 3. ステータス: Running Fargate タスク起動まで少し待機 テスト実行 6
38. メトリクス 意味 Avg Response Time 平均レスポンスタイム Requests per Second 秒間リクエスト数 Success Rate 成功率 (100% = 全成功) 結果確認 7
39. 次のレクチャー → 結果の詳細な分析方法 最初のテスト完了！ 8
40. 重要なメトリクスの読み方 テスト結果の分析 1
41. メトリクス 説明 Average Response Time 平均レスポンスタイム p50 (Median) 50% のリクエストがこの時間内 p90 90% のリクエストがこの時間内 p99 99% のリクエストがこの時間内 主要メトリクス 2
42. 平均: 100ms でも... 99%のリクエスト: 50ms 1%のリクエスト: 5000ms (5秒!) → 100人に1人が5秒待たされる p99 を監視することが重要！ なぜパーセンタイルが重要？ 3
43. メトリクス 説明 Requests per Second スループット（処理能力） Success Count 成功リクエスト数 Error Count エラーリクエスト数 Bandwidth データ転送量 その他のメトリクス 4
44. レスポンスタイム推移 負荷増加に伴う変化を確認 急上昇ポイント = システムの限界 エラー率推移 エラー発生タイミングを特定 限界を超えた負荷を把握 グラフの見方 5
45. 「Download Results 」でCSV ダウンロード → Excel / Google Sheets で詳細分析 結果のエクスポート 6
46. p99 が許容範囲内か エラーが発生していないか 負荷増加時の傾向 ボトルネックの特定 次のレクチャー → JMeter スクリプトでより高度なテスト 結果分析のポイント 7
47. より複雑なテストシナリオを作成 JMeter スクリプトの概要 1
48. Web コンソールの限界: 単純なHTTP リクエストのみ 単一エンドポイント JMeter が必要なケース: ログイン → 操作のシナリオ 複数API の連続呼び出し 動的パラメータの変化 なぜJMeter を使うのか？ 2
49. Apache JMeter オープンソースの負荷テストツール 1998 年〜 の長い歴史 世界中で広く使用 特徴: GUI でテスト設計可能 HTTP, DB, FTP など多様なプロトコル対応 プラグインで機能拡張 JMeter とは 3
50. Test Plan └── Thread Group (仮想ユーザー設定) ├── Config Element (共通設定) │ └── HTTP Header Manager ├── Sampler (リクエスト) │ ├── HTTP Request 1 │ └── HTTP Request 2 └── Listener (結果収集) ※DLTでは不要 JMeter の基本構成 4
51. 要素 役割 Test Plan テスト全体の設定 Thread Group ユーザー数・繰り返し設定 Sampler 実際のリクエスト定義 Config Element 共通ヘッダー・変数など Listener 結果表示（DLT では不要） 各要素の役割 5
52. 1. JMeter GUI でスクリプト作成（.jmx ） 2. DLT にスクリプトをアップロード 3. Task Count / Concurrency を設定 4. テスト実行 DLT でのJMeter 使用フロー 6
53. 次のレクチャー → 実際にJMeter スクリプトを作成！ 次のステップ 7
54. ハンズオン JMeter スクリプトの作成 1
55. 1. Apache JMeter 公式サイトへアクセス 2. 「Download Releases 」から最新版をダウンロード 3. Zip を展開 4. bin/jmeter.bat (Windows) を実行 JMeter インストール 2
56. Test Plan を右クリック → Add → Threads (Users) → Thread Group 設定: 項目 値 Number of Threads 1 Ramp-up period 1 Loop Count Forever ※実際の設定はDLT 側で行う Thread Group 作成 3
57. Thread Group を右クリック → Add → Sampler → HTTP Request 設定: 項目 値 Protocol https Server Name api.example.com Method GET Path /api/users HTTP Request 追加 4
58. Thread Group を右クリック → Add → Config Element → HTTP Header Manager ヘッダー追加: Name Value Content-Type application/json Authorization Bearer your-token-here HTTP Header Manager 追加 5
59. File → Save Test Plan as ファイル名: api-load-test.jmx スクリプト保存 6
60. Test Plan └── Thread Group ├── HTTP Header Manager │ ├── Content-Type: application/json │ └── Authorization: Bearer xxx └── HTTP Request └── GET https://api.example.com/api/users 作成したスクリプト構成 7
61. 次のレクチャー → DLT でJMeter スクリプトを実行！ 次のステップ 8
62. ハンズオン JMeter スクリプトの実行 1
63. 1. DLT Web コンソール → Create Test 2. Test Type: JMeter を選択 3. Upload Script → api-load-test.jmx を選択 スクリプトアップロード 2
64. 項目 設定値 結果 Name jmeter-api-test - Task Count 5 5 タスク Concurrency 20 ×20 同時接続 Ramp Up 60 秒 - Hold For 300 秒 (5 分) - → 5 × 20 = 100 同時ユーザー テスト設定 3
65. テスト 同時ユーザー 前回（シンプル） 10 今回（JMeter ） 100 10 倍の負荷をかけてシステムの挙動を確認 負荷の比較 4
66. 1. 「Run Test 」クリック 2. 「Confirm 」で確定 3. 5 つのFargate タスクが起動 4. リアルタイムでメトリクス表示 テスト実行 5
67. 100 ユーザーでのレスポンスタイム推移 p99 の値は許容範囲内か エラーは発生していないか 10 ユーザーとの比較 結果確認ポイント 6
68. 次のセクション → トラブルシューティング → コスト最適化 次のステップ 7
69. よくある問題と解決方法 トラブルシューティング 1
70. 原因と対策: 原因 確認・対策 サブネット設定 インターネットアクセス可能か NAT Gateway プライベートサブネットの場合必須 セキュリティグループ アウトバウンド443 許可 確認方法: CloudWatch Logs → /ecs/distributed-load-testing 問題1: テストが開始されない 2
71. 原因と対策: 原因 確認・対策 タスクリソース不足 CFn パラメータでサイズ変更 ターゲット側の制限 WAF/API Gateway スロットリング確認 ネットワーク帯域 大量データ転送時の制約 問題2: 負荷が上がらない 3
72. 原因と対策: 原因 対策 システムの限界 正常 → 改善ポイント特定 タイムアウト設定 JMeter でタイムアウト値調整 スクリプトのバグ URL/ ヘッダー設定を確認 問題3: エラー率が高い 4
73. CloudWatch Logs: ロググループ: /ecs/distributed-load-testing 確認内容: - エラーメッセージ - 接続失敗の原因 - タイムアウト発生 ログ確認方法 5
74. 1. まずログを見る → エラーメッセージに原因あり 2. 小さく始める → 1 タスク/ 少ユーザーで動作確認 3. 設定を見直す → VPC/ サブネット/SG トラブルシューティングのコツ 6
75. 次のレクチャー → コスト最適化テクニック 次のステップ 7
76. DLT を賢く使う コスト最適化 1
77. 主なコスト: ECS Fargate 構成 東京リージョン/ 時間 2 vCPU / 4GB 約$0.10 〜0.15 10 タスク × 1 時間 = $1 〜1.5 その他（Lambda, DynamoDB 等）は通常無視できるレベル DLT のコスト構造 2
78. Fargate Spot を使う 通常 vs Spot: タイプ コスト 通常 $0.10/ 時間 Spot $0.03/ 時間 (70% オフ) ※中断リスクあり（負荷テストなら問題なし） CFn パラメータで有効化可能 コスト削減テクニック① 3
79. 適切なタスク数 NG: 最初から100 タスク OK: 少数から始めて必要に応じて増加 1タスク → 5タスク → 10タスク → ... 必要十分なタスク数を見極める コスト削減テクニック② 4
80. テスト時間の最適化 目的 推奨時間 動作確認 1 〜2 分 基本性能測定 5 分 詳細分析 15 〜30 分 耐久テスト 1 時間以上 目的に応じた時間設定で無駄を削減 コスト削減テクニック③ 5
81. 使わないときはスタック削除 削除のメリット: コストがゼロに 再デプロイで同じ環境が復元可能 注意: 過去のテスト結果も削除される 必要な結果は事前にダウンロード リソース削除 6
82. パターン 月額コスト 週1 回, 1 時間, 10 タスク 約$8 〜10 毎日, 15 分, 5 タスク 約$8 〜10 学習のみ ( 都度削除) 数百円 コスト試算例 7
83. 次のレクチャー → コースまとめと次のステップ 次のステップ 8
84. お疲れさまでした！ コースまとめと次のステップ 1
85. セクション 内容 1. 概要 DLT とは、アーキテクチャ 2. デプロイ CloudFormation で15 分構築 3. テスト実行 Web コンソールで簡単テスト 4. JMeter 複雑なシナリオ作成・実行 5. 運用 トラブルシューティング、コスト最適化 コースの振り返り 2
86. 15 分でデプロイ完了 CloudFormation で簡単セットアップ サーバー管理不要 Fargate でフルマネージド スケーラブル タスク数を増やすだけ JMeter 対応 既存資産を活用 コスト効率 使った分だけ、Spot ならさらに安く DLT を使うメリット 3
87. 1. 自分のシステムでテスト → 実際のアプリで負荷テスト実施 2. CI/CD への組み込み → デプロイ後に自動テスト実行 3. 定期的なパフォーマンス監視 → 週次/ 月次でテスト、推移を監視 4. 高度なJMeter スクリプト → ログインフロー、ファイルアップロード 次のステップ 4
88. DLT のデプロイと設定 Web コンソールでのテスト実行 テスト結果の分析（パーセンタイル） JMeter スクリプトの作成と実行 トラブル対応とコスト最適化 できるようになったこと 5
89. 最後までご視聴いただき ありがとうございました 質問は Q&A セクション へ 頑張ってください！ Thank You! 6