前置き
Loader.ioに引き続き負荷テストネタです。
ちなみにLoader.ioネタはこちら。
Loader.io で負荷テストしてみた
https://qiita.com/furu8ma/items/fb7a45388bfe323b46c1
負荷テストをやると必ずある疑心暗鬼にとらわれる、そんなことはないでしょうか？
私はあります。
つまり
これで、本物の負荷に、本当に耐えられるんだろうか?🤔
払拭するには、テスト手段を増やすしかありません。
とはいえ、Jmeterでクラスタを構築するフォースパワーは(以下略
そんな時、同僚にApache Benchで気軽にクラスタを組んで負荷をかけられるツールの存在を聞いたので試してみることにしました。
使い方はこちらが詳しいです。
AWS と Bees with Machine Guns で静的コンテンツの負荷テストを実施する
http://www.s-arcana.co.jp/blog/2014/12/16/2430
なんというか非常にパッションを感じる記事です。
本家の方に簡単なインストール方法が試してみたのですが、エラったので、日本語の記事の方を参考にしています。
日本語の記事は本当によくまとまっており、2014年の記事ですが、ばっちり2018年でも問題なく通用したので、そのまま実行していただければと思います。
というわけで、例によって注意事項のみ
注意点
- ApacheBenchをインストールしたAMIを用意しておいたほうが楽
上記例ではクラスタをあげたあとpsshでApacheBenchを遠隔インストールしていましたが、私が利用したAmazonLinux2LTSではyumで入れられませんでした。またAMIをとること自体はAWSユーザーなら空気を呼吸するようなもんだと思いますので、さっくりyum で Apache Benchをインストール(yum install httpd-tools)し、すかさずとったAMIをbees up時に指定した方が楽だと思います。
- bees!を落とす時はAWSコンソールからではなく、bees downで。
bees upであがった攻撃用(?)EC2は当然AWSコンソールでも見えるので、そこからでもterminateできるのですが、やってしまうとその後beesコマンドが謎のエラーを吐き続け使い物にならなくなります。
どうやらこういったイレギュラーケースは想定されていないらしく、beesに関する操作は全てbeesコマンドで行ったほうがトラブルになりません。
ちなみにこういった事態に陥った場合にはHOMEディレクトリに.bees.リージョン名、例: .bees.ap-northeast-1cというファイルができるので、それを削除するとクラスタがない状態にリセットされ、エラーも消えます。
- attackはCtrl+Cでは止まらない。強制的に止める場合はbeesクラスタをAWSコンソールから落とす。
hurlなしでbeesを運用している場合、タイムアウトを指定できません。なので場合によってはテスト完了までめっちゃ時間がかかり中断したくなる場合があります。が、SIGTERMを送るべくCtrl+Cしてもbees attackは謎のエラーを吐くだけで停止しません。業をにやしてプロセスをkillしても、親EC2上でのbees attackコマンドが停止するだけでbeesクラスタからの攻撃はとまりません。止めるにはAWSコンソールからNameにbee!が設定されているEC2をかたっぱしからterminateするしかありません。
ほんとイレギュラーに弱い。。
いろいろ書いてしまいましたが、最初のインストールさえ済ませてしまえば、さっくりクラスタを組んでApache Benchによる負荷をかけられるのでいいツールだと思います。
Loader.ioほどの手軽さはありませんが、その代わりある程度の設定もできます。日本リージョンからの攻撃もできますし、攻撃の規模にも上限はありません。
ちょうど、Loader.ioとJmeterクラスタの間に位置する負荷テストソリューションといえます。
負荷テストの際にはぜひご検討ください。