AWSで負荷テスト環境を簡単に構築出来るようなので試してみます。
構成
公式から。
フロントにAmplifyが用いられテストシナリオを作成するコンソール画面が提供されます。
実際に負荷をかける環境はECSによって管理されたコンテナから実行されます。コンテナイメージにはコンテナイメージにはTaurusというテストツールが使用されているようです。
コスト
負荷テストの実行時間に応じたFargateの従量課金分が多くを占め、維持コストはほぼかかりません。
仮にEC2にテスト環境を構築した場合、厳密にテスト時間だけ起動するという運用は困難ですし、コスト面でも優秀なのではないでしょうか。
使ってみる
こちらのデプロイガイドを参照しながら進めていきます。
CloudFormationスタックの作成
デプロイガイドに下記の記載がありますので、マネジメントコンソールにログインした状態でソリューションの起動をクリックします。
CloudFormationの画面が開きます。
デフォルトだとリージョンがバージニア北部になっているので東京に変更しました。
スタックの詳細の指定です。
Console Administrator Name とConsole Administrator Emailの欄だけ入力しました。
負荷テストのコンソールへログインするユーザー名の指定と、ログインパスワードが通知されるメールアドレスを記載します。
確認画面に遷移します。
IAMリソース作成への同意にチェックをする必要がありますので、チェックをしてスタックを作成します。
テストコンソールからのテスト実行
スタック作成が完了すると、パラメータとして入力したメールアドレス宛に、ログインパスワード、ログインURLが記載されたメールが送られてきます。
テストシナリオを作成していくのですが、その前にテスト対象の環境を用意します。
今回はとりあえずhttpリクエストを受けられれば良いので、apacheがインストールされているAMIからEC2インスタンスを起動しただけの雑な環境をテスト対象としました。
ちなみに、AWSで負荷テストや侵入テストを実施する場合、シナリオによってはAWSへ事前連絡が必要となる事があるのですが、ガイドによると「本ソリューションでネットワークトラフィックが1Gbps未満の場合は連絡不要」との事です。
詳細についてはこちらに書いてあるようなので、AWSで本格的な負荷テストを行う際は確認しておいた方が良いでしょう。
さて、テストシナリオの作成に戻ります。
テストコンソール上部の[CREATE TEST]をクリックします。
シナリオの設定を入力する画面となるので、要件に応じて記載して実行します。
画面下部欄の[Amazon CloudWatch Metrics Dashboard]をクリックすると、リアルタイムに状況をウォッチする事が出来るようです。
テスト対象はしょぼいインスタンスタイプで用意したのでまぁまぁエラーがでてますね。
単体で作成できるテストシナリオはシンプルなものに限られますが、シナリオ作成時[Test Type]にJmeterを選択する事ができ、既存のJmeterの定義を読ませる事ができるようです。
簡単に、従量課金でコスト最適化されたテスト実行環境が構築出来るのは、かなり良いのではないでしょうか。