ツール

負荷テストツールLocust(イナゴ 175)のインストールと実行

先日、負荷テストの話題になって聞き慣れないツールの名前が出たので調べてみました。

負荷テストのツールと言えば、簡易的なもので「Apache Bench」、もう少し凝ったことをやろうとして「JMeter」というイメージでした。

今回は、Python のコードでシナリオが記述できる「Locust」のインストール手順と実行方法を紹介します。

イナゴ?バッタ?の大群が襲ってくる負荷テストツール

「負荷試験にイナゴを使ってみたいんだよね」

そんな一言がこの話題の発端でした。

知らない人は「イナゴ」てググっていいのか、「175」でググるべきなのか迷うところですが、後者はもしかすると 175R を知ってる世代だけでしょうか。

要は「Locust」のことなのですが、「ローカスト」や「ルーカスト」などと呼んでいる人がいるようです。
(まあ、純粋に英語ですよね)

結局、無知だった自分・・・。

Locustの特徴

冒頭にもチラっと書きましたが、以下の特徴を持った負荷試験ツールです。

シナリオがPythonで書ける

分散テストができる

WebのUIから負荷試験ができる

そういえば、数年前に Web の UI を持った負荷試験ツールを触ったことがあるような記憶が蘇ってきました。

もしかすると見たことのある UI かもしれないと早く画面が見たくなりますが、まずは試してみます。

Locustのインストール

Python のツールなので、pip コマンドでインストールをします。

pipコマンドの確認

pip コマンド自体は Lets’ Encrypt を同じサーバで利用しているので既に入っていました。

インストール実行

早速、locust のインストールです。

最後に警告が出ましたが、pip のバージョンってこんなに差異があるの?

アップグレードして Let’s Encrypt の証明書更新ができなくなるのが嫌なので別のサーバで試みます。

別サーバでpipのアップグレード

無理にアップグレードする必要はないかもしれませんが、気になるので pip のアップグレードをしてから locust のインストールをすることにします。

アップグレードが完了してバージョンが 18.0 になりました。

再度Locustのインストール実行

そのまま pip をアップグレードしたサーバで locustio をインストールします。

警告なしでスムーズにいくかなと期待しましたが、今度は 6 個のエラーが出力されましたorz

この時点で、無理にアップグレードするんじゃなかったと少々の後悔・・・。

仕方ないので足りないパッケージのインストールをして、chardet のエラーを解決してから再度 locustio のインストールをします。

まずは、パッケージのインストールから。以下の 5 つのパッケージをインストールします。

最後にエラーの内容通り chardet を手動で削除します。

今度はエラーなくインストール完了です。

バージョンを確認すると 0.8.1 となっています。まだ 1 を超えないのか・・・。

Locustの実行

早速、使ってみたいと思いますが、Locust の Web UI の画面は8089 番ポートで待ち受けます。

AWS のセキィリティグループを触ってポートを開けるのが嫌だったので、nginx でリバースプロキシすることにしました。

ざっくり、こんな感じで設定ファイルを作って適当なドメインを振っておきます。
(何かのサブドメインとかでも)

気休めで Basic 認証でもしておきます。

Locust の設定ファイルは「locustfile.py」というファイル名にしておくとデフォルトの設定ファイルとして読み込んでくれます。

設定内容は、トップページとリンク先のページに順番にアクセスする単純な画面遷移とします。

これで Locust を起動して待ち受けてみます。

簡単に上記コマンドを説明すると、-H オプションで負荷を掛けたい相手先のホストを指定しています。

詳しくはヘルプを見てください。locustfile.py 以外の設定ファイルを使いたい場合は -f で指定します。

Locustの画面にアクセスしてテスト開始

では、nginx で設定した locust.example.org にアクセスしてみます。

問題がなければ、以下の設定が表示されます。

f:id:chatoracat:20181031012109j:plain

やはりこのツール、何年か前に Python 好きなエンジニアの人が使っていて紹介されたものでした。

このシンプルな画面は見覚えがあります。

ちなみに、設定項目は以下の通りです。

Number of users to simulate:クライアントの数

Hatch rate:クライアントの生成速度

今回はシンプルに 1 ユーザから始め、1 秒ごとに 1 ユーザずつ増加させていくことにしました。

f:id:chatoracat:20181031012120j:plain

これだと平均のレスポンス時間も短いですね。しかも、サイト側は nginx のキャッシュ利かせていますからね。

Max(ms)が 115 になっているアクセスはキャッシュが効いていない初回アクセスだったのかも。

f:id:chatoracat:20181031012132j:plain

設定を変更して負荷を上げる

画面上部の赤いストップボタンで停止し、ステータス付近の「New test」からユーザ数や増加数を変更してテストが開始できます。

今度は、5 ユーザから始まり毎秒 5 ユーザ増やしてみます。

f:id:chatoracat:20181031012213j:plain

やはりワードプレス相手でもキャッシュが効いていると速いですね。

この程度なら余裕で捌けます。

そして「100 / 100」で設定して秒間 100 にしても全く問題ありません。

キャッシュしちゃってるだけに、静的なページが返るだけですからね。

でもワードプレスの負荷軽減にページキャッシュは大きく貢献していることがわかります。

「500 / 500」の設定から、ある程度アクセスを捌けてはいるものの、徐々にロードアベレージが増加してきました。

f:id:chatoracat:20181031012228j:plain

まとめ

Locust をサーバにセットアップして、簡単な負荷を特定のサイトにかけてみました。

実は今回、同じサーバのサイトに対して行ったので、実際はもう少し状況は変わってくるハズです。

本来ならリモートからやらないとあまり意味もないですしね。

また、シナリオが Python で書けるので、もっと凝ったシナリオも作れそうです。