AWSの負荷テストソリューションを試してみた

シナリオを用いた負荷テストツールとしてJMeterやGatlingなどがございますが、AWSでも負荷テストのソリューションが用意されております。

こちらのソリューションは、Fargateで1秒あたり選択した数のトランザクションを生成する数千規模の接続ユーザーを簡単にシミュレートできます。
本エントリでは、AWSの負荷テストソリューションを使った負荷テストを紹介します。

構成要素

公式の構成図を拝借しています。

フロントエンドでは、バックエンドの負荷テストエンジンを実行するAPIと、テストシナリオの作成やモニタリングに使用するウェブコンソールが提供されています。
なお、使用するテストシナリオにはJMeterのシナリオを指定できるため、既にJMeterを使っている場合は簡単に大規模な負荷テストを行うこともできます。

バックエンドでは、負荷を生成するためのDockerイメージを作成します。イメージには負荷テストフレームワークのTaurusが使われています。イメージやテストスクリプトを変更する際は、S3から更新します。
フロントエンドのAPIで負荷テストを実行すると、Lambdaから各タスクが起動され、負荷テストが開始されます。

制限

• 最大負荷は10,000の同時リクエスト（デフォルト）
  • Fargateで起動できるデフォルトのタスク数は50、タスクごとに最大で200の同時接続を生成します
  • 同時リクエストを増やす場合、タスク数の上限緩和申請します
• テストの最大実行時間は4時間

コスト

ソリューションを使用することにコストはかかりませんが、使用したAWSサービス自体のコストは発生します。
サービスのコストは発生しますが、サーバレスな構成のためほとんど発生しません。

やってみた

前提

検証の構成です。ALBを前段にもつWebサーバを用意し、5つのタスクから同時接続して負荷かけます。

負荷テストのシナリオでネットワークトラフィックが1Gbpsを超える場合、AWSへ負荷テスト申請が必要です。負荷テスト実施の際は、Amazon EC2 Testing Policy を事前に確認します。

デプロイ/テスト

CloudFormation テンプレートを元にソリューションをデプロイします。

• CloudFormationテンプレート
• ソースコード

パラメータ設定では、コンソールにログインするためのユーザ名と初期PWメールアドレスを入力します。VPCネットワークはデフォルト値をそのまま使用します。

デプロイが完了後、コンソールURLと初期PWが入力したメールアドレス宛に通知されるので、ログインします。

上部の [CREATE TEST] をクリックし、負荷テストの設定を行います。ここでは、3分間で同時リクエスト数1000に達し、最大同時接続の負荷が5分間継続するように設定しています。

一般設定

シナリオ設定

各設定項目を入力し、[SUBMIT] をクリックすると、テストが開始されます。

しばらくすると、STATUSがCOMPLETEとなり、テストが完了しました。

平均応答時間、平均レイテンシー、平均接続時間といったテスト結果を得ることができました。Taurus のテスト結果の詳細については、Taurus のユーザーマニュアルから確認できます。

CloudWatch側も確認してみます。ALBのRequest Countから、3分間で同時接続数MAXに達して、5分間継続して負荷がかかっているということを確認できました。

さいごに

AWSの負荷テストソリューションを使って、負荷テストをやってみました。
簡単に大規模な負荷テストを低コストで行えること、使い慣れたJMaterのシナリオを流用できること、テスト用のコンテナやスクリプトのメンテナンスが容易であることは嬉しい点と思います。
負荷テストを実施する際には検討してはいかがでしょうか。

参考

• AWS での分散負荷テスト