はじめに

クラウド環境上に構築しているWebサービスに対する負荷テストが手間だと思ったことはないでしょうか。
負荷テストは特性上高性能な処理用サーバが必要となるだけでなく、システムに負荷を与えるので作業ミスがあると他のシステムにも影響が発生する等考慮が多く大変です。過去はAzure上でも負荷テストを行う前にはMicrosoft社に申請をする等の必要がありました。
しかし、2022年10月にAzure Load Testing と言う負荷テストサービスがパブリックプレビューでリリースされました。
この記事では負荷テストが楽になると信じていろいろ調査・検証した結果を共有し、今後本サービスをお使いになる方の一助になればと思います。

 

 

Azure Load Testingとは

Load Testingとは、Azure上から簡易的にWebサービスへの負荷テストを実施可能なサービスです。
過去の負荷テスト時に必要であった申請などは不要で、Azureポータル上では、Web閲覧のHTTPアクセス頻度によるテストのみとなりますが、JMeterスクリプトを使うことでログイン処理やファイルダウンロード等の動的処理を含む負荷テストも実施可能となります。
2022年12月現在日本のリージョンではリリースされていませんが、海外のリージョンでLoad Testingリソースを構築し、日本国内のWebサイトを対象にすることも可能なので日本国内でもサービス自体は利用可能です。

 

 

価格

LoadTestingは２種類の費用が発生します。
①Load Testingが存在することで発生するコスト
②Load Testingでテストを実施した時間と性能で発生するコスト
VMで言うディスクとVM稼働時間に伴うコスト、とイメージ頂けるとわかりやすいかと思います。
ただしVMと違いテストの稼働時間だけでなく同時に行うユーザー数（スレッド数）に応じて金額は上がるため、注意してご利用ください。
例えば1ユーザーで30分テストする場合と、30ユーザーで1分テストする場合は金額としては同じとなります。

 

 

Load Testingのメリット

高い性能の負荷テストが手間なくできる

多くのユーザーのアクセスを疑似的に発生させる場合、高い性能のサーバが必要となります。
クラウドならまだしもオンプレミスなどではそれだけの為にリソース調達が出来ません。
また、クラウド環境で行う場合も、大量アクセスの仕組みを有したVMの構築も手間となります。
Load Testingであれば基盤の構築が不要なため、テストスクリプトさえあれば直ぐにテストが実行可能です。

 

単純なHTTPアクセスの負荷テストであればGUIで対応可能

LoadTestingは単純なHTTPアクセスの負荷テストであれば、宛先（FQDN or IP）、アクセスするユーザー数、アクセス数を入力すればテストが可能です。
ログイン処理等動的な処理を含むテストにおいてはJMeterのテストスクリプトが必要です。

 

JMeterのスクリプトが流用可能

先にも記載している通り、HTTPアクセス以外の処理のテストを行いたい場合、JMeterのスクリプトを用いてテストが実施されます。そのため、これまでJMeterを使ってVMからテストを行っていた場合、そのスクリプトをそのままLoad Testingで実行できるため、テスト基盤の移行がスムーズにできるかと思います。

 

 

Load Testingの注意点

Dos攻撃対応等のセキュリティは除外しましょう

Load Testingでテストを行うと、Microsoft社の単一IPからの大量アクセスを制御するツールなどは除外しないと、テストの通信をブロックしてしまう可能性があるため事前に確認し、必要に応じて除外しておきましょう。もちろんテスト後に元に戻すことも忘れずにしましょう。

 

負荷によるダウン後は復旧しましょう

当然ですがLoad Testingによってサイトがダウンした場合、Load Testing側で復旧などはしないので復旧はユーザー側で行う必要があります。
テストと言う認識でダウンしたまま放置しないよう正常な状態に戻しましょう。

 

スクリプト作成時に使うJMeter領域はサポート範囲外

当然と言えば当然ですが、テストスクリプトを作成するためにJMeterを用いるケースも多いと思いますが、
AzureサポートとしてはJMeterはサポート範囲外となるため、JMeterでのスクリプト作成についてはある程度自力での対応が必要となります。

 

 

クイックテスト（単純なHTTPアクセステスト）手順

１．まずはポータル上からAzure Load Testingで検索し、表示されるAzure Load Testingをクリックします。

２．[作成]をクリックします。

３．「サブスクリプション」「リソースグループ名」「テストリソース名」「場所（リージョン）」を入力し、[Review＋create]をクリックします。

４．作成されたリソースをクリックし[quickTest]をクリックします。

５．以下情報を入力し、[Run test]をクリックします。
・Test URL（アクセス先、IP or FQDN））
　処理を行う対象のサイトです。

・Number of virtual users（ユーザー数）
　同時に処理を行うユーザー数（≒スレッド数）です。

・Test duration（テスト時間、単位は秒）

・Ramp-up time（ランプアップタイム、単位は秒）
　上記で設定したユーザー数になる時間です。
　このLoad Testingではテスト開始時から上記ユーザー数になるのではなく、
　段階的にユーザー数を増加させる事が出来ます。
　負荷を段階的に上げた際の影響を確認したい方などはランプアップタイムを設定すると良いでしょう。

６．テスト完了後、結果が表示されるため、内容をもとに評価してください。

・Virtual Users

ユーザー数の推移です。

・Response time

成功した応答の応答時間です。

・Reequests
HTTPのリクエスト応答数です。なお、このリクエスト数にエラーのリクエスト数も含まれます。

・Errors
HTTP404等の応答エラーの発生数です。
こちら各種の数値と比較検討し、いつ頃から、どの程度のユーザーアクセスがあったタイミングでエラーが発生したか等を確認すると良いでしょう。

 

 

JMeterスクリプトを用いた負荷テスト

１．クイックテスト手順の１～３を実施します。

２．作成されたリソースをクリックし[create]をクリックします。

３．「テスト名」「説明」を入力し「Next: Test plan >」をクリックします。

４．ファイルの選択からJMeterスクリプトファイル（JMeterにおける”テスト計画”をエクスポートしたjmxファイル）をアップロードし、「Review + create」をクリックします。

５．テストが作成されると合わせて実行され、結果が表示されます。結果の確認はクイックテストと同様です。

 

 

FAQ

Q.WebAppsのFreeプランなどの共有リソースに対してLoadTestingを実行してもよいですか？
A.問題ありません、申請も不要です。

 

Q.Load Testingの通信元は固定ですか？
A.通信元は固定で、単一IPからの通信となります。
　そのため、テスト対象サイトに同一IPからの連続する通信をブロックするような制御を入れている場合、除外しておきましょう。

 

Q.JMeterを使う場合のテスト時間、ユーザー数、ランプアップタイムはどこで設定しますか？
A.JMeterのスクリプト上で設定します。

 

Q.JMeterでのスクリプト作成方法が分かりません。
A.JMeterのアプリケーションをローカルに配置し、自身の端末上でテストとなる動作をブラウザで行い、その動作をキャプチャしてスクリプト化ができます。
　この記事では詳細割愛しますが、”JMeter シナリオ作成”等で検索すると多くのページがHitするので参照してください。

 

Q.JMeterスクリプトがエラーで失敗してしまいます。
A.Azureサポートに相談しましょう、テストIDやスクリプトファイルを送付し調査いただけます。
　自分でできる対応としては、スクリプトファイル内で文字化けがしていないか等を確認してみてください。

 

 

おわりに

本日はAzure Load Testingについて紹介しました。
まだプレビューの機能ながら実務への活用は十分できると感じました。
これからのGA、日本リージョンへのリリースなどを期待して待ちたいと思います。