Jmeterでの負荷テストの備忘録

なんか依頼いただいてやってみたので軽く備忘録を。

・環境構築
つかったのはjmeter4です。
なんか同僚の方がslaveの台数指定すると勝手に作られるpowershellスクリプト書いてくれてポチっとしただけで楽をしたのですが以下リンク先のような感じでできるっぽいですかね。
https://dev.classmethod.jp/etc/jmeter-master-slave/

jmeter本体とスレーブから負荷をかける対象の環境にアクセスできるようにSecurityGroup的なものを開けます（リリース前で開いてない前提）。ポート80と443など。slaveを消して作り直しても大丈夫なようにStaticなIPを確保して作り直したら付け直すみたいな感じにしておいたりなど。（あんまり間が空くようならリリースしたほうが経済的ではあります）

・テストシナリオ
開発した環境のことがわかってる人が作るのが筋がよいですねということでシナリオは作ってもらいました。どんな処理でどのくらいの同接に耐えたいのかも指定いただいたりと更新系の処理につかうテストアカウントとかお任せしたほうがという。画面遷移でシナリオ作れるようです。
https://www.casleyconsulting.co.jp/blog/engineer/901/

・スレッドグループの設定
編集＞追加＞Users＞スレッドグループ
スレッド数は実際耐えたい同接をスレーブの台数で割るとそれぞれのスレーブが割った数を実行する感じです。
RumpUPは各スレッドの最初のテスト実行までにかかる時間らしい。
つまり0だとすべてのスレッドが同時にアクセス行く感じ。
シナリオを一回実行してみてその実行結果秒数を指定するといいのでは説。
ループ回数はスレッド数分何回負荷かけるのかというやつですがどのくらいの時間耐えられるか見たいようなときは無限ループにして危うくなったら停止という感じに。
http://naoberry.com/jmeter/word/

DelayThread creation until needed：メモリを徐々に使うやつ（最初にどばっと確保するのではなく）にチェックを入れるとJmeterが落ちるという心配がある場合によさそう。

・リスナーの設定
編集＞追加＞リスナー＞サマリーでcsvに出力
スレッドグループにポインタして追加して、
でsummaryとツリー形式のやつを追加しておきました。リスナーは負荷かける前に先に追加しとかないとデータ取れないです。
負荷テスト中はツリーのほうのScroll automaticallyをチェックして最新が表示されるのを
眺めつつエラー出ないかと出た時間などをザックリみとくなど。

・プロキシ無効化
シナリオ作成時に使ってたプロキシを無効化してからでないとつながらないという。
https://laboradian.com/proxy-setting-of-win10/

・実行する前に
各種モニタリングできるようなダッシュボードを作っておいたり、ログが一か所で見られるようにしておいたり、実環境にログインしてdstat流しておいたりなど何らかの判断指標となる情報をとれるようにしておいたほうがいいです。
あとは、フロントエンドなら[オートスケーリング](https://qiita.com/smallpalace/items/6c289fc252e52175caaf)仕込んでおいたり、スペックに合わせて設定変えるのが手間なら[起動スクリプトでAnsibleが勝手に計算して設定かわるようにしとく](https://qiita.com/smallpalace/items/d331e65d1e4b57e1c973#%E8%B5%B7%E5%8B%95%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%A7%E3%83%91%E3%83%A9%E3%83%A1%E3%83%BC%E3%82%BF%E8%AA%BF%E6%95%B4)とか楽でよかったかな～と思います。オートスケーリングは台数の増減自体が指標になっていいかもなあと。

今回GCPでそんなに大げさな台数でもなかった（聞いた話だと100台くらいが限界らしい）のでstackdriverでモニタリングとログ集約をしました。割と手軽にオートスケーリングでも自動で追随してくれるかんじでした。ダッシュボードも直感的にポチポチしてたらなんかできてたしタグでフィルタリングとかできるの便利だなと思いました。
https://cloud.google.com/stackdriver/
(タグのフィルタ処理って重いのかzabbix4.0のセミナにいったとき改善中とききました。ぜひがんばってーと思いました。）

ちなみにGCPは負荷テストの事前申請とかいらないから勝手にどうぞって感じと聞きました。ロードバランサの暖気申請も不要。
AWSだと先に負荷も暖気も申請が要る気がします（大量でないなら不要という返事もらった人も）。
https://qiita.com/Nacht/items/3fd3c98ff82be641f9ba
Azureは負荷は申請不要なようです。
セキュリティチェック的な侵入テストは~~AWSと~~Azureは申請が要るっぽいですが

→AWSはペネトレテストもものによっては事前申請不要なポリシーが載ってるページをおしえてもらったので追記
https://aws.amazon.com/jp/security/penetration-testing/

GCPは自分のとこに限定なら申請不要で何か見つけたら報奨金制度があると。
http://tigerszk.hatenablog.com/entry/2017/06/20/202335

・実行する
実行＞すべて開始リモート
終了するとslaveが終了しちゃうので環境設定かえて再開したいときは停止がいいみたいです
https://symfoware.blog.fc2.com/blog-entry-2226.html

・実行して起こった事件と対応など
IPアドレスとCPUのクォータの上限緩和をする必要があったので一応かいておきます。（IAM＞割り当て、から広げる申請ができます）
https://cloud.google.com/compute/docs/resource-quotas?hl=ja&_ga=1.181298212.2042940000.1483498197
あとはディスクのサイズ次第でIOPSも違ってくるようでした。（ふやした）
https://cloud.google.com/compute/docs/disks/performance?hl=ja

他にやったことと言えばインスタンスサイズ上げたりを普通にしました。
（mpmまわりとかの調整はインスタンスサイズでかわる搭載メモリ量で起動スクリプトで勝手に変わるAnsibleを仕込んでおきました）
ただまあ事前にこんなもんでどうかなという調整をしてあってそのあとどうするみたいなのを推考してくには時間がたらなかったというか。負荷テスト直後にs-inみたいなのでもいいかもしれないですが、[pgpool-Ⅱのキャッシュ追加したらよさそう](http://www.pgpool.net/docs/pgpool-II-3.4.3/doc/tutorial-memqcache-ja.html)とか構成の変更は言い出しづらいかもしれない。

あとGCPって、モニタリングしてるとそれをもとに適切なこのサイズに変えるとおいくらお得でっせ画面で「適用する」ボタンが出てくる（インスタンスの再起動はしますと断りはかいてある）みたいなのがあって、実際あけてからアクセスがアレだったら節約するボタンを押すと経済的なようです。（イベントの前後にメンテ入れてサイズ変えるかんじがいいのかな）

・ほかのツールのまた聞き情報
おしえてもらっただけで試してないのでよくわかってないですが貼っておきます。
好みとか流派とか宗教的なアレで選択しがあるのかなという感じですが私の周囲にはJMeter派閥が多かったようです。

loader.io
https://qiita.com/furu8ma/items/fb7a45388bfe323b46c1

LOCUST（エンドツーエンド）
 pythonツール
https://qiita.com/yamionp/items/17ffcc465272ad83c490

1ページならGolangのvegeta(abのかわり）なども
https://github.com/tsenart/vegeta

Windowsの負荷試験にRPA
https://www.celf.biz/rpa/