AWSで始める負荷テスト入門

【7/5（金）】DevelopersIO 2024 SAPPORO #devio2024
https://classmethod.connpass.com/event/319416/

Transcript

1. AWSで始める 負荷テスト⼊⾨ 2024.7.5 AWS事業本部 中川 翔太
2. Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
3. ⾃⼰紹介 中川 翔太 AWS事業本部コンサルティング部 ソリューションアーキテクト 受賞 • 2024 Japan AWS All Certifications Engineers 好きな道の駅 • ぐるっとパノラマ美幌峠、厚岸グルメパーク 3
4. 負荷テスト できてますか？ 4
5. 負荷テストでよくある課題 • 何をやったらいいかわからない • スケジュールに追われてできていない • ⼗分な負荷をかけられていない • スケールアップ/アウトだけのチューニング 5
6. 負荷テストをしないと 6 システム特性を 把握できてない運⽤ ユーザー体験への悪影響 ‧アクセス遅い ‧買うの⽌めよ ‧別サービスにしよ ‧急激にアクセス 増えてボトルネッ クを特定できない ‧サイズ⼤きくし たのに改善しない ビジネス機会の損失に繋がる
7. 本⽇話すこと • 負荷テストの概要と⽬的 • 負荷テストの進め⽅ • AWSを活⽤した負荷テスト • 実践的なTips 7
8. 負荷テストとは • 特定の条件下でシステムに負荷を与えて処理能⼒を測定 するテスト • 同時に多数のアクセスが発⽣する状況をシミュレーショ ン 8
9. 負荷テストの⽬的 システム特性を把握して改善すること 1. ユースケースに基づいた性能要件を満たしているか確認 2. ボトルネック箇所の特定して性能限界を把握 9
10. 負荷テストの種類 10 https://grafana.com/load-testing/types-of-load-testing/
11. 負荷テストの進め⽅ ‧⽬標を設定 ‧シナリオを検討 11 ‧負荷テスト⽤の環境構築 ‧負荷テストツールの選定 ‧モニタリング ‧事前の申請 ‧実施時のポイント ‧RDS/Auroraで注意事項
12. 計画 12
13. ⽬標を設定する 主にスループットとレイテンシを使⽤します • スループット：⼀定時間にどれだけリクエストがあるか ◦ 1⽇、1時間(ピーク)、 1分(ピーク) のユーザー数を定義 ▪ ピークは通常時の平常時の2〜3倍を⽤いる ◦ 1ユーザーあたりのリクエスト数と乗算してスループットを算出 • レイテンシ：リクエストからレスポンスまでどれだけかかったか ◦ 即時求められる処理、遅れが許容できる処理ごとに定義 ▪ 例）会員登録などユーザを逃す可能性のあるところは短く ◦ 実⾏数が多い処理はレイテンシ増加の影響が⼤きい ▪ 逆にレイテンシが⼤きくても実⾏数が少なければ影響は⼩さい 13
14. シナリオの検討 ユースケースを満たすためのシナリオ検討します。 • 想定しているユーザーの導線からシナリオ ◦ 例）商品⼀覧からカートに追加 → カート移動 → 決済 • 負荷が⾼くなりやすい処理が含まれているか確認 ◦ アクセス頻度が⾼い機能 ◦ DBの参照‧更新が発⽣する機能 ◦ ⽔平スケールができない機能 14
15. 準備 15
16. 負荷テストの準備 • 負荷テスト⽤の環境構築 • 負荷テストツールの選定 • モニタリング • AWSへの事前申請 16
17. 負荷テスト⽤の環境構築 • IaCで管理する • 本番と同じ構成にする • 外部連携している場合はモック化する • 実環境相当のデータを⽤意する 17
18. 負荷テストツールの選定 ワークロードやチーム‧組織にあったツールを選定します。 18
19. 分散負荷テストソリューション 19 https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/
20. 分散負荷テストソリューション 20
21. 分散負荷テストソリューション 21
22. 分散負荷テストソリューション 22 https://catalog.us-east-1.prod.workshops.aws/workshops/401f5147-738e-45 d9-be9f-fed9c42a60b0/ja-JP ワークショップも公開されています。
23. モニタリング 23 Amazon CloudWatch AWS X-Ray Amazon DevOps Guru AWSのモニタリング サービス。メトリクス 収 集、ログ管理、 アラー ト機能提供。 分散トレーシング サー ビス。リクエスト追跡 ‧分析を提供。 機械学習を使⽤して異 常な動作パターンを検 出。運⽤上の問題を特 定。
24. モニタリング 24 RDS/AuroraではPerformance Insights を有効化します
25. AWSへの事前申請 • 上限緩和申請 ◦ AWSの各サービスのリソースにデフォルトで設定され ている上限値を超えて使⽤する場合に申請 • （必要に応じて）ELB 暖気申請 ◦ 急激なリクエスト増加に対応するための事前申請 • （必要に応じて）ネットワーク負荷テスト申請 ◦ 1分以上の1 Gbps または 1Gppsを超えるトラフィック を⽣成する場合に申請 25
26. 実施‧評価 26
27. 負荷テスト実施時のポイント • 最⼩構成で最⼩負荷から性能を確認すること • 負荷の並列数は徐々にあげること • 試験ごとに複数のパラメータを同時に上げないこと • 負荷テストごとに同じデータを使⽤していること ◦ Auroraを使っている場合はBacktrack機能が便利 • 暖気にはRamp-Up機能（⼀定時間かけて最⼤並列数に） ◦ 実際にありえないコネクション⽣成が問題となる場合 27
28. RDS/Auroraで注意事項 28 事象 注意事項 対策（上から検討） 読み込みクエリがボトル ネックのとき ☐ インデックスの有無を確認（SQLに EXPLAIN をつけて実行計画を取得） ☐ COUNT で多数のレコードが対象と なっていないか、多用していないか • インデックスを作成 • COUNT() を多用しないように • 非同期に処理できるか検討 • バッファプールの最適化（メモリ最適化） • リーダーノードを追加 • キャッシュレイヤを追加 書き込みクエリがボトル ネックのとき ☐ 複数レコード更新に BULK INSERTを 使っているか ☐ 非同期にできるクエリがあるか • (非同期な処理が可能な場合) キューを挟む • クエリのチューニング • スロットリングを挟む • クエリ負荷のピークを分散 • インスタンスサイズを上げる • シャーディング ※1 読み込みも書き込みもボ トルネックのとき ☐ 負荷が大きすぎていないか、シナリオ が適切か確認する • 実際のアクセスパターンに近づける(wait追加) 期待するパフォーマンスが出ないときに確認します ※1 https://aws.amazon.com/jp/blogs/news/sharding-with-amazon-relational-database-service/
29. まとめ • 負荷テストはシステム特性を把握しするために⾏います • 計画、準備、実施の各段階ごとに進めましょう • AWSサービスを活⽤して、効果的に負荷テストを⾏いま しょう ◦ 負荷テストツールに迷った場合、まずは「分散負荷テ ストソリューション」がおすすめ 29
30. 参考 • 負荷テスト on AWS のすすめ ◦ https://aws.amazon.com/jp/builders-flash/202308/distributed-test-on-aws/ • 第三⼗五回 ちょっぴりDD - ⼈気番組の新作配信を安定起動させた、サーバーレスな AWS 分散負荷試験 ソリューション「Distributed Load Testing」を使った負荷試験の仕組み ◦ https://www.youtube.com/watch?v=8qfj-klSdBU • Types of load testing ◦ https://grafana.com/load-testing/types-of-load-testing/ • 負荷テストとは？⽬的や種類ごとの観点、実施の流れについて解説 ◦ https://service.shiftinc.jp/column/9503/ • 書籍「Amazon Web Services負荷試験⼊⾨―クラウドの性能の引き出し⽅がわかる」 ◦ https://amzn.asia/d/06N58UQp 30