大規模負荷試験の実施に関する記録
大規模負荷試験の手順
負荷試験といえば ab や jMeter などを用いて行うのが一般的です。
よく案件のパフォーマンス系のエビデンスとして納品を求められるケースが合ったりしますが、
この負荷試験の規模が大規模になってくるとなにかと面倒です。
大規模負荷試験といっても、いきなり大規模対応していくのではなく、
サーバのパフォーマンス、アプリケーションのパフォーマンスなどを確認しながら、
徐々にスケールUPしつつテストを実施する形になるかと思うので、
その手順なんかを共有しておきます。
apache bench
まずは簡単に実施できる apache bench などを使って、
サーバ、アプリケーションの性能チェックを行います。
$ ab -t 60 -c 100 {URL}
-
-tテストを実施する時間(秒) -
-c同時に実行するユーザ数 -
-ABasic 認証を利用する場合に-A {username}:{password}の形式で利用します。
ab では単純な URL の GET リクエストが行えます。
複雑なシナリオ付きのテストを行いたい場合は、 jmeter を利用するのが一般的です。
ab も jmeter も高度なレポート機能を備えているため、
実施したテスト結果から rps(Request per Seconds) や 90% tile / 99% tile などの情報を得ることができます。
ab も jmeter も クライアントマシンで負荷試験を実施する形の構成のため、
だいたい 同時接続ユーザ 150 くらいまでは、この規模で対応できるはずです。
jMeter Cluster
同時接続ユーザが 200 以上などになってくると、
ab や jmeter でのテスト実行が難しくなってきます。
もちろん複数PCを用意して並列化すればテストの実施は可能なのですが、
それは流石に物理的に面倒な感じになってくるので、
ここからの規模では、jMeter の Cluster 構成を利用してテストを実施するのが良いでしょう。
jMeter Cluster は分散サーバ上で、jMeter 試験を実施して結果を集計するための機能です。
jMeter Cluster 用の AWS Template が以下の Blog で公開されてたりもしますので、
比較的簡単に始めることができます。
jMeter Cluster 上での負荷試験の性能指標の測り方を確認しておきましょう。
まず同時接続ユーザ数は、 シナリオ上のスレッド数 x サーバ台数 で計算できます。
テスト実行上の rps は jmeter cluster のクライアント側実施ログから取得できる他、
テスト後に吐き出される jtl ログファイルからも取得可能です。
また jMeter Cluster 上で 生成された jtl ログファイルを、
GUI版 jMeter に読み込ませて HTML 形式の Summary Report を生成することも可能です。
$ jmeter -g my_test_result.jtl -o summary
しばらくするとエラーが発生して落ちる
ネットワークの設定等の見直しは必要ですが、
見落としがちなのがストレージの容量問題です。
大量の負荷試験を実施する場合、jMeter から膨大なログファイルが生成されるため
上記紹介したブログのAWS Template などを利用している場合、
デフォルトの EBS ボリューム 2GB は すぐさま枯竭します。
EBS の管理コンソールからボリュームを増やした後、
以下のコマンド実行で新しいボリュームサイズを適用できます。
実行後に df -h で新しいボリュームサイズが適用されていることを確認しておいてください。
sudo growpart /dev/nvme0n1 1
sudo xfs_growfs -d /
rps が上がらない
シナリオファイル上のスレッド数を上げても性能が上がらない場合には、
クラスタサーバ上のリソースが枯竭している可能性があります。
CloudWatch 等を利用して サーバリソースを確認しながら 適切なスレッド数のサイズを見つけてください。
CPU リソース等が最適な状態での試験規模のスケールは
主にサーバの台数調整で進めていきますが、
こちらもクラサバ間でのネットワークの都合で効果は逓減し、一定の規模で性能は頭打ちします。
ログファイルがでかすぎる
試験が実施できたとしても、
ログファイルが膨大過ぎて、試験の結果をサーバ環境から吸い出せない、という問題も発生しうると思います。
split コマンドで分割して吸い出すこともできますが、
上記で紹介したように、html 形式の summary report をサーバ上で生成して、
summary のみ吸い出すというのも手です。
なお、jmeter コマンドも膨大なサイズのファイルを読み込めないようなので、
summary レポートの生成でも split によるファイル分割は必須っぽいです。
Blazemeter
jMeter Cluster での負荷試験もおよそ 同時接続ユーザ 2000 くらいで頭打ちとなります。
Cluster 自体を多重化すれば、4000 / 6000 とより大きな規模の負荷試験を実施できますが、
正直ログファイルの処理も大変ですし、 Cluster 自体の多重化は手作業なので、
PC を複数用意して作業しているという最初のアイデアと変わらないような気がしてきます。
予算に余裕があるのなら、ここからは SaaS のサービスを徹底的に活用するのが良さそうです。
Blazemeter は jMeter のテストシナリオを実行できる SaaS のサービスです。
Blazemeter でのテスト実行
jMeter のテストシナリオを読み込んでテスト実行できます。
設定されているスレッド数は無視され、新たに Blazemeter上で ユーザ数の設定を行う形となります。
構成は jMeter Cluster と似たような形で、テストシナリオと、設定された User 数を、
複数のサーバ(LOAD DISTRIBUTION/Engine) に分散して処理させる形になります。
Engine は1テストあたり 10 までで、1 Engine には 最大 500 User を割り振ることができます。
が、実際に 1 Engine で 500 ユーザをさばけることは稀で、
サーバの性能上の問題で 200 ユーザでも 500 ユーザ でも同じ rps みたいなことはよくあります。
レポートの Engine health から各 Engine の CPU 利用率を確認できるので、
これを参考にしながら Per Engine の最適ユーザ数を確認すると課金額の節約に繋がります。
課金は vuh という単位で処理され、
ユーザ数(vu) と 実行時間(h) の掛け算で vuh が消費されていきます。
実行時間は切り上げで丸められるため、1.5h のテストは 2h 分の vuh が消費されます。
が、実行時間は実際の実行時間ではなく、テスト設定上の実行時間となるため、
2h で設定したテストが 実際には 2h2m とかかかったとしても vuh 消費は 2h 分で収まるみたいです。
ということで Blazemeter を利用したとしても、
1 テストで実施可能なテストは、大体 200 User x 10 Engine の 2000 User 程度にとどまります。
が、Blazemeter 上では複数のテストを並列して流せるため、
これを利用して、簡単に大規模試験を設定できる、というわけです。
利用可能な User 数や Engine 数、vuh のクレジットは、
契約のプランに寄って異なるので、詳細は公式の Pricing をご確認ください。
まとめ
同時ユーザ 100 程度の試験は手元のマシンでもなんとかなりますが、
正直それ以上になってくると諸々面倒事が増えてきます。
予算に余裕があるのなら可能な限りで Blazemeter なんかの SaaS サービスを活用するのは
時間のコストを考えても非常に有意義な出費だと思います。
Discussion