負荷テスト on AWS のすすめ (AWS Summit Japan 2024 - Ministage session)

© 2024, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 負荷テスト on AWS のすすめ⾺渕俊介 M I N I S E S S I O N アマゾンウェブサービスジャパン合同会社エンタープライズ技術本部サービスグループトラベル・交通・物流ソリューション部ソリューションアーキテクト

rights reserved. ⾃⼰紹介名前︓⾺渕俊介 (Shunsuke Mabuchi) 所属︓エンタープライズ技術本部サービスグループトラベル・交通・物流ソリューション部ソリューションアーキテクト経歴︓・国内 SIer で性能専⾨の技術⽀援部隊に所属し、多数システムで性能テスト・性能問題解決を担当（〜2020/11）・AWS にてソリューションアーキテクトとして交通系のお客様を担当好きな AWS サービス : Amazon CloudWatch 好きな AWS ソリューション : Distributed Load Testing on AWS ︓@mabuchsss

rights reserved. 本セッションの対象者と前提知識本セッションの想定聴講者 • システムの開発・運⽤に関わるエンジニアの⽅ • システムの発注に関わる、事業会社の情報部⾨の⽅ • SRE・テストエンジニアの⽅前提知識 • AWS の基本的なサービスについて知っていること • システム開発のサイクルの概要を理解していること

rights reserved. Key takeaways : 負荷テストのつらいところを、AWS サービスやソリューションで軽減できる環境 Instance Scheduler IaC DB 複製負荷ツール Distributed Load Testing Timestream for InfluxDB 監視ツール Observability on AWS

rights reserved. イントロダクション

rights reserved. Q. 負荷テストについて、どういう印象を持っていますか︖ 「つらい」「⼤変」「やりたくない」「やったことないけど⼤変そう」と思っている⽅、挙⼿をお願いします 👋 👋

rights reserved. Q. 負荷テストについて、どういう印象を持っていますか︖ 環境やデータの準備が⼤変負荷ツールがネックにならないように⽤意するのが⼤変想定ケースのシナリオ作りが難しいリソース情報からボトルネックを分析するのが困難 CI/CD の中でどうやるべきか悩ましい

rights reserved. Q. 負荷テストについて、どういう印象を持っていますか︖ 環境やデータの準備が⼤変負荷ツールがネックにならないように⽤意するのが⼤変想定ケースのシナリオ作りが難しいリソース情報からボトルネックを分析するのが困難 CI/CD の中でどうやるべきか悩ましいつらいけど避けては通れない

rights reserved. 本セッションの⽬的と全体像本セッションの⽬的 • 負荷テストのつらい部分を、AWS の活⽤でどう軽減できるかを知る本セッションでお話すること • 負荷テストの全体像の説明 • 負荷テストの主要ファクターについて、つらい部分と、AWS での解決⽅法について説明本セッションでお話しないこと • 性能⽬標やシナリオの検討⽅法 • オンライン処理の負荷テストを対象とし、バッチ処理性能には触れない • システム開発サイクルにおける、負荷テストの⽴ち位置（例 : アジャイル開発における実施タイミング、etc）

rights reserved. Agenda • イントロダクション • 負荷テストの全体像 • 負荷テストのつらいところと、AWS での解決 • まとめ & Call to action

rights reserved. 負荷テストの全体像 ① 計画全体像を決める • 負荷量 • シナリオ • テスト環境 • 負荷ツール • 監視ツール ② 準備環境・ツールを実装する ③ 実施実験を繰り返す ④ 評価結果を合意し、 Next Action を決定する準備実⾏チューニング分析

rights reserved. • 負荷量 • シナリオ • テスト環境 • 負荷ツール • 監視ツール

rights reserved. 負荷テストの主要ファクター • 負荷量 • シナリオ • テスト環境 • 負荷ツール • 監視ツール ③ 実施実験を繰り返す準備実⾏チューニング分析実施サイクルの QCD に直結

rights reserved. 負荷テストの主要ファクター • 負荷量 • シナリオ • テスト環境 • 負荷ツール • 監視ツールここについては、builders.flash 記事シリーズ「負荷テストのすすめ」をご参照ください本⽇のフォーカス対象

rights reserved. Agenda • イントロダクション • 負荷テストの全体像 • 負荷テストのつらいところと、AWS での解決 • テスト環境 • 負荷ツール • 監視ツール • まとめ & Call to action

rights reserved. テスト環境の検討事項とアンチパターン検討事項 • どこに構築するか • どのサイズで構築するか • どうやって構築するか • 外部接続先をどうするか • DB のデータをどうするかアンチパターン • 独⽴していない • 専⽤環境を構築せず、他環境と相乗り • AWS アカウントが他環境と同居 ※ Quota 到達のリスク • 本番環境が再現されていない • コスト削減のために、縮⼩版環境で実施 • 外部接続先に関連するシナリオを省略 • DB のデータの量・偏りを再現しない

rights reserved. テスト環境のベストプラクティスと、その "つらさ" ベストプラクティス • 本番同等の負荷テスト専⽤環境を、専⽤の AWS アカウントに構築する • 本番環境同等のデータを、負荷テスト環境の DB 上に再現する 😭 環境構築の⼿間が⼤変…… 😭 環境のコストがかかる…… 😭 再現度の⾼いデータ作りは⼤変……

rights reserved. テスト環境の "つらさ" 解決 ① : IaC ベストプラクティス • 本番同等の負荷テスト専⽤環境を、専⽤の AWS アカウントに構築する解決策 IaC で専⽤環境構築、負荷テストが終わったら削除可能にしておく 😭 環境構築の⼿間が⼤変…… 😭 環境のコストがかかる…… AWS CloudFormation AWS CDK 負荷テスト環境開発環境運⽤テスト環境 PJ 全体の環境構築・利⽤戦略として IaC を組み込んでおく

rights reserved. テスト環境の "つらさ" 解決 ② : Instance Scheduler ベストプラクティス • 本番同等の負荷テスト専⽤環境を、専⽤の AWS アカウントに構築する解決策 Instance Scheduler ソリューションで、テスト時間帯外のコスト削減 • 曜⽇・時間を指定して EC2 / RDS の起動停⽌スケジュールを設定 • AWS ソリューションとして公開されておりテンプレートからすぐ構築できる 😭 環境のコストがかかる……

rights reserved. AWS ソリューションとは • AWS サービス、コード、設定を組み合わせた、すぐデプロイできるソリューション＝便利な構成テンプレ集（CloudFormation） • 利⽤にかかる費⽤は、含まれる AWS サービスの費⽤のみ 21 https://aws.amazon.com/jp/solutions/ 注⽬のソリューション例︓ • ⾃動化されたセキュリティ対応 • AWS Security Hub が検出した脅威を⾃動 or ワンクリックで修復 • OpenSearch での統合ログ管理 • デプロイしてすぐに使えて、ログ収集・分析・可視化を⼀元化 • DevOps Monitoring Dashboard • CI/CD のメトリクスを収集し分析・可視化、改善の指標を提供

rights reserved. テスト環境の "つらさ" 解決 ③ : DB 複製ベストプラクティス • 本番環境同等のデータを、負荷テスト環境の DB 上に再現する解決策 RDS スナップショットを⽤いて本番 DB を複製 → マスキング 😭 再現度の⾼いデータ作りは⼤変…… 本番環境テスト環境本番DB 複製DB Snapshot Snapshot 機密情報マスクテストDB Snapshot 注意事項︓ • 暗号化の設定によっては制約事項あり

rights reserved. 負荷ツールの検討事項とアンチパターン検討事項 • どのツールを使うか • 負荷ツールを稼働させるマシンの台数・スペック • 負荷ツールの監視⽅法アンチパターン • 負荷クライアントに⼗分なスペックを⽤意しない • 負荷ツール視点のメトリクスを監視しない

rights reserved. 負荷ツールのベストプラクティスと、その "つらさ" ベストプラクティス • 負荷クライアントを、スケールアウト可能な構成で構築する • 負荷クライアント視点の状況をモニタリングする 😭 台数分の構築が⼤変…… 😭 複数台の協調が⼤変…… 😭 複数台の EC2 を⽴ち上げっぱなしにするのはコストがかかる…… 😭 スケールアウトする負荷クライアントにいちいちモニタリングの導⼊するのも⼤変……

rights reserved. 負荷ツールのベストプラクティスと、その "つらさ" ベストプラクティス • 負荷クライアントを、スケールアウト可能な構成で構築する • 負荷クライアント視点の状況をモニタリングする 😭 台数分の構築が⼤変…… 😭 複数台の協調が⼤変…… 😭 複数台の EC2 を⽴ち上げっぱなしにするのはコストがかかる…… 😭 スケールアウトする負荷クライアントにいちいちモニタリングの導⼊するのも⼤変…… 構築が簡単で簡単にスケールできて負荷実⾏時以外はコンピュートリソースを使わず負荷ツール側のメトリクスも集められる

rights reserved. 負荷ツールの "つらさ" 解決 ① : DLT ソリューションベストプラクティス • 負荷クライアントを、スケールアウト可能な構成で構築する • 負荷クライアント視点の状況をモニタリングする 😭 台数分の構築が⼤変…… 😭 複数台の協調が⼤変…… 😭 複数台の EC2 を⽴ち上げっぱなしにするのはコストがかかる…… 😭 スケールアウトする負荷クライアントにいちいちモニタリングの導⼊するのも⼤変…… 構築が簡単で簡単にスケールできて負荷実⾏時以外はコンピュートリソースを使わず負荷ツール側のメトリクスも集められる解決策︓ Distributed Load Testing (DLT) on AWS ソリューション

rights reserved. Distributed Load Testing on AWS (DLT) とは Web コンソールから JMeter のシナリオをアップロードすると、複数の Fargate コンテナが⽴ち上がり、JMeter※ で負荷を実⾏ AWS Fargate タスク1 タスク2 タスクn … 指定⽇または定期⽇などスケジュール実⾏可能 1タスクあたりの仮想ユーザー数を指定して並列処理 Apache JMeter テストシナリオ (.jmx) S3バケット各シナリオが S3バケットから取得負荷テスト対象サービス … ※ Taurus がラッパーとなっている

rights reserved. DLT ソリューションのメリット構築スケール・コストモニタリング CloudFormation テンプレートですぐデプロイ可能負荷実⾏時だけコンテナ起動コンテナ数は Web コンソールで簡単に設定 CloudWatch Container Insightsでコンテナ状況可視化性能指標値を可視化するダッシュボード⾃動作成

rights reserved. 負荷ツールの "つらさ" 解決 ② : Amazon Timestream for InfluxDB ベストプラクティス • 負荷クライアント視点の状況をモニタリングする 😭 全部の負荷クライアントから⾒た性能ってまとめて・簡単に・リアルタイムに⾒られない…… DLT のコンソールで部分的には解決可能だが、より詳細な情報を⾒たい場合 Amazon Timestream for InfluxDB New! 2024/03

rights reserved. Amazon Timestream for InfluxDB • 時系列 DB の InfluxDB をマネージドで提供 • JMeter のリスナー設定でメトリクス送出可能 • リクエスト種別ごとのリアルタイムな数値をダッシュボードで可視化 New! 2024/03

rights reserved. 監視ツールの検討事項とアンチパターン検討事項 • どのツールを使うか • どういった情報を収集するか • どうやって可視化するか • どうやって分析するかアンチパターン • マシンリソースのメトリクスしか取得できていない • ログがリアルタイムに集約されていない • ログの検索・取得・集計であちこちツールを⾏き来する

rights reserved. 監視ツールのベストプラクティスと、その "つらさ" ベストプラクティス • オブザーバビリティが実現されている • ログ・メトリクス・トレースによりシステムの動作状況を把握できること解決策 AWS の Observability サービスの活⽤ 😭 今まで使ってきたツールだと全部はカバーできない…… 詳細は 12:10-12:25 のミニステージセッション「監視運⽤ベストプラクティス」セッションでご紹介︕

rights reserved. 監視ツールの "つらさ" 解決 : Observability on AWS Observability Collectors and SDKs Container insights Lambda insights Contributor insights Application insights Synthetics Dashboards Alarms RUM AWS X-Ray AWS native services Amazon CloudWatch ServiceLens Open-source managed services Amazon Managed Grafana Do it yourself (DIY) – AWS OSS Solutions Amazon OpenSearch Service Amazon Managed Service for Prometheus Jaeger and Zipkin Tracing Insights & ML Instrumentation Metrics CloudWatch agent AWS X-Ray agent AWS Distro for OpenTelemetry Internet monitor Logs

rights reserved. 負荷テストでのオブザーバビリティ Tips Tips • 標準メトリクス・ログより詳細なデータ収集設定例）EC2 インスタンスの詳細モニタリング、CloudWatch エージェントの導⼊、 RDS の拡張モニタリング、RDS への Performance Insights の有効化 • ダッシュボードを育てれば育てるほど負荷テストサイクルが早くなる • CloudWatch ⾃動ダッシュボードはウィジェットの宝庫 • 〇〇〇 Insights は必殺の武器 • CloudWatch 〇〇〇 Insights シリーズ (例 : Log Insights) や、 RDS Performance Insights の使い⽅を覚えておく

rights reserved. まとめ負荷テストのつらいところを、AWS サービスやソリューションで軽減できる環境 Instance Scheduler IaC DB 複製負荷ツール Distributed Load Testing Timestream for InfluxDB 監視ツール Observability on AWS

rights reserved. Call to action ⽇本語のワークショップやベストプラクティス教材で学び、実践する環境 Instance Scheduler 負荷ツール Distributed Load Testing 監視ツール Observability on AWS InstanceScheduler Workshop Distributed Load Testing Workshop One Observability Workshop AWS Observability Best Practices Happy Load Testing︕

rights reserved. Thank you! ⾺渕俊介 (Shunsuke Mabuchi) アマゾンウェブサービスジャパン合同会社エンタープライズ技術本部サービスグループトラベル・交通・物流ソリューション部ソリューションアーキテクト

負荷テスト on AWS のすすめ (AWS Summit Japan 2024 - Mini...

負荷テスト on AWS のすすめ (AWS Summit Japan 2024 - Ministage session)

More Decks by Mab

Other Decks in Technology

Featured

Transcript