負荷テスト案件で学んだ自動化のコツ
先月までJMeterを使って負荷テスト＋チューニングをしていました。サーバがLinuxだったこともあり、作業はシェルスクリプトを使ってある程度自動化してました。その際に学んだシェルスクリプトのコツをメモ。
出来るだけ自動化する
作業は出来るだけ自動化する。「いつも同じことしてね？」って部分は自動化する。例えば、
といった作業は自動化したが、思い返すと↓のような作業も自動化できた。
- リモートクライアントマシンへの環境構築
- リモートクライアントマシンでのjmeter-server実行
- catalina.outから例外を抽出する
「面倒だなぁ」と思ったら積極的に自動化を狙ってみる。「そもそもそのスクリプトを書くことが面倒だ！」ってときもあるだろうけど、「頑張るのは最初の一回だけ」と自分に言い聞かせてモチベーションの上げてみる。
動作確認も自動化する
負荷テスト実行後に「全ユーザー処理したか」という動作確認が甘かった。甘すぎて大変なことになってしまったし。
ログを見て確認するんだけど、毎回そんなことやってられないから、
- ログをgrepして全ユーザが処理したか
- DBをselectして登録件数が期待値と同じになっているか
- 負荷テスト実行中に例外が発生していないか
といったことを確認するスクリプトがあったら非常に良かった。
これの見返りは大きいし、何より目と手に優しい。正常だったらこの音を鳴らす、みたいな遊びを仕込んでおくといいかも。
実行するスクリプトは１つだけにする
ある目的を達成するためにコンソールから実行するスクリプトは１つだけにする。処理単位でスクリプトを分割すると思うが、それらのスクリプトを順番に手で実行していくのではなく、トップレベルのスクリプトが呼び出していくようにする。
負荷テストでは以下のようにスクリプトを分割して、トップレベルのスクリプトが順次実行していくようにした。
- 前回行った負荷テストの結果を削除
- 各APサーバの時刻を修正（時刻がずれているとログが追いづらいため）
- 負荷テスト実行
- 負荷テストが行われたときのログ（apache, tomcat）を各APサーバから収集
- 負荷テスト実行結果からレスポンスタイムの平均値を算出
当たり前だけど、これらのスクリプトを順番に実行していくのは面倒だし、きっと間違える。
