AWSの分散負荷テストソリューション ワークショップをやってみた
はじめに
先日行われた「秋のobservability祭り」に参加して、負荷テストをAWSでマネージドに行うことができるサービスが、ワークショップで公開されているということを知ったので、そちらを実践しながらサービスの詳細と使ってみての感想など簡単にまとめていければと思います。
参加レポートも記事にしているので、よければ読んでください！
ワークショップはこちらです。
分散負荷テストソリューションとは
そもそも「分散負荷ソリューション」とは、負荷テストを実行する環境を分散させる(複数ホストから実行する)ことによって、実行環境自体がテストの負荷に耐えられない状態になることを防ぐためのソリューションです。
通常JMeterなどの負荷テストツールを実行する場合に、EC2などにインストールしてシナリオを定義し実行するかと思いますが、このシナリオの負荷にJMeter実行用のEC2が耐えられるかどうかが、課題になり得ます。この課題を解決するのが、分散負荷ソリューションと言えます。JMeter実行環境がスケーリングし、負荷テスト時の実行クライアントの考慮を減らすというのが一番大きなメリットです。
負荷分散ツールとして有名なものでは、JMeter、K6などがありますが、現在DLT(Distributed Load Testing on AWS)ではJMeter(Taurusがラッパーしている)が利用可能となっています。(2024/11時点ではK6もロードマップには入っているそうです。)
このDLTは、GUIでテストシナリオを定義するとS3に定義が配置され、それを元にFargateをベースにテスト実行環境が立ち上がるというものになります。この実行タスク数や同時実行数などもGUIで簡単に設定できるので、AWSに慣れていなくてもテスト実行が可能となっています。
さらに嬉しいのが、実行環境構築は基本的にCloudFormationのテンプレートで構築でき、任意のVPCを指定することでVPC内のリソースに対してもテスト実行が可能になるという点や、テンプレート内にCLoudWatchのダッシュボードも含まれているので、テストに必要なメトリクスの取得にも困りません。
必要に応じて時系列データベースであるInfluxDBをJMeterメトリクスのデータストアにしてテストを実行することで、時系列データとして保管するしながらダッシュボード化することも可能となっています。
DLTソリューションのCloudFormationテンプレートはこちらから利用できます。
Workshopをやってみる
環境準備編
環境準備は基本的にCDKデプロイやCloudFormationテンプレートをデプロイするだけです。はまりポイントもほぼなく、かなりスムーズにできるWorkshopになっていると思います。
構築する環境ですが、負荷をかけられる(試験対象)システムとして、ECSとDynamoを用いたTODO WEBアプリと、負荷をかける(試験実施環境)として、DLTおよびデプロイ環境としてのSageMakerStudioです。
なお、構築する環境は東京かバージニアが動作確認済みですので、どちらをを利用するようにしましょう。なお、DLTとしては複数リージョンから実行するという使い方もできるので、グローバル展開しているサービスなどはさらに細かく負荷試験を実施できるのがすばらしいところです。
CDKを初めて触る方やCloudFormationに慣れていない方は、若干出力や構成をイメージしにくいかもしれませんが、ワークショップ冒頭の以下構成を理解して進めると、全体を把握しやすいかと思います。
ワークショップより引用
負荷試験編
単一URL
まずはJMeterのシナリオではなく、DLTのGUI上で設定できる単一URLに対しての負荷試験を行います。
設定画面では、負荷を発生させるECSタスク数やスレッド数、実行リージョン、負荷をかける時間などを簡単に設定できます。
必要事項を記入した後にRUN NOWを押下すると数分後にはECSタスクが立ち上がり、画面に統計が表示されてきます。
ここまででも試験開始までの準備などのスピード感は非常に早くなっていると感じます。そして結果は非常に綺麗なグラフを出力してくれるので試験結果が一目瞭然です。
さらにCloudWatchダッシュボードも同時に用意してくれるので、そちらでの確認も可能です。DLTコンソールの方がリアルタイム性は高いので、必要に応じて利用を分けると良いと思います。
ワークショップでは、2回実施します。2回目はタスク数を増やした状態で実行するため、エラーが発生しやすくなっていると思います。
簡単に負荷を調整しながらも実行側の管理がほぼ不要で、負荷試験に集中できるというのがここまででわかります。
また、同じテストシナリオを複数回実行した場合、履歴も残すことができるので比較も簡単に簡単に見ることが出来るのが非常にありがたいポイントだと思いました。
複数URL
次にJMeterシナリオを用いた複数URLに対しての負荷試験を実施します。
JMeterシナリオを作るためにはJMeterをインストールしたり、多少手順が必要になりますが、そこさえクリアできれば実行時の管理は不要になるので、ローカルにJMeterをインストールするだけでも十分になります。ありがたい。
先ほどと同様のタスク数設定などに加えて、作成したJMeterシナリオ(jmx)ファイルをアップロードするだけでユーザーシナリオベースの負荷試験が実行できます。
また、ここでinfluxDBを用いて時系列データをDBに保存するような形式も取れます。さらに、influxDBにダッシュボードテンプレートを適用すると、登録されたデータを特に作業手間なくビジュアライズできるので、とっても便利だなあと感じました。
実行結果は以下のようになります。（実行結果は必ずしも一致しません。）
influxDBのダッシュボードも以下のようになります。このダッシュボードはテンプレートをダウンロードして適用しているので、一切手を加えていない状態です。
この結果から、徐々にレスポンスが悪くなり、最終的には一部エラーも出てしまう状態が見受けられます。
結果を分析するためにJMeterの出力結果をS3からダウンロードすることも可能で、CSVで出力されているのでこのファイルをビジュアライズツールを使ってグラフ化するということもできるようになっています。
ワークショップにはJupyter Notebookでの分析用テンプレートも付いているので、こちらを使えば1リクエストごとの分析ができるので、詳しくない人でもすぐに結果分析ができるようになります。
ちなみに、２度目の結果はこのようになりました。
分析編
ここまでで負荷試験の実施は完了しました。試験をした後には必ず分析が必要です。
先ほどのようにJupyter Notebookでの分析なども手法の一つですが、そこまで簡単なものでもありません。ロジックを書いたり手間のかかる作業です。
そんな分析に対してもAWSはサービスを提供しており、それがDevOps Guruです。
DevOps Guruについては過去記事にしておりますので、そちらもご覧いただければと思います。
これの素晴らしいところは、CloudFormationスタックで構築していない既存のアプリケーションに対しても導入可能な点です。
どのように導入するかというと実行基盤(ECSやEC2など)に対して特定のタグを設定するだけで、そのリソースベースのアプリケーションの統合的な問題点を分析することが可能になります。
現状手動で設定しているが、今後の改善を見据えてDevOps Guruを使ってみたいという方は上記の手法を取ってみると良いかもしれません。
また、DevOps Guruを使うにあたっては、内部で機械学習のエンジンが動いているため、平常時のメトリクスが必要になります。
そのため、負荷試験を行う前に一定期間稼働させておくと、より精緻な負荷試験でも問題点の抽出ができるようになるとのことです。運用後もコスト的に許す(そこまで高価なものではない)のであれば、利用した上で迅速に問題点の洗い出しができる状態にしておくのが良い使い方とされています。
最後に
先日の秋のオブザーバビリティ祭りに出席して、非常に面白そうなソリューションを見せていただいたので、実際に触ってみての感想でした。
構築するのも実際にテストを行うのも簡単で、価値のあるもの(アプリケーションなど)に集中できる環境作りを第一に考えるAWSらしい素晴らしいソリューションだったかと思います。
今後のK6対応などロードマップを注視して、実際に現場でのユースケースや利用普及を目指していきたいと思います。
Discussion