この記事はチラ裏です。僕の頭の中を整理するためだけの記事です。

寒いなぁ…寒いなあ…
卒論を提出して2/6にはパワポとレジュメを作成して発表です。

 

負荷をかけるツールはいっぱいある

便利な世の中なので負荷ツール（Load test tool）はたくさんあります。
ここでどれを使うかを選定しないといけないわけですがいくつか候補を挙げてみたいと思います。

  • JMeter（有名、高機能、リクエストがいっぱい出せる、知見多）
  • ab（シンプル、知見多、手軽）
  • httpperf（手軽、リクエストがいっぱい出せる）
  • vegeta（リクエストがいっぱい出せる）
  • hey（手軽）
  • siege（使ったことない）
  • goad（Lambdaから負荷をかけれる、色んなリージョンからアクセスできる、JSONのPOSTのやり方分からず、手軽）
  • Locust（分散して負荷をかけれる、Web GUIがある）

分散しないで負荷をかける vegeta や hey では家のネットワークとか、１台のマシンだけじゃサーバー側のリソースを使い切ってくれないため除外。
JMeterは設定がダルい、勉強するのは少し面倒。

Locust は Qiita 等で取り上げられてるので知見は結構あります。
JMeter のようなシナリオを Python で書き、負荷をかけるサーバーも簡単に実行することができる。
ドキュメントもきちんと整備されているので今回は Locust を使ってみました。

 

 

Locust を使ってみる

インストールも簡単です。
pip install locustio
これだけです。

実行は
locust -H host --master

Slaveは
locust -H host --slave --master-host=masterip

Master は実際に負荷をかけず、集計や Web GUI を担当し、Slaveが実際の負荷を行います。
今回は c4.large のインスタンスを6つ建てて 1Master 6Slave で負荷をかけました。

負荷試験中は、LB(Nginx), API, DBのリソース状況、各サーバーのログを表示しておき、
Nginx のコネクション数や、FD数などは Nginx Amplify を表示しておくと便利です。

 


今回は 10万ユーザーを作成し、秒間1万ユーザーずつ増加していく方法を取りました。

 


Charts には数値がグラフ化されています。
この図を見るだけで、RPSは最大3200、ユーザー数が増えるごとにレスポンスタイムが増えていっていることが分かります。

 


失敗したリクエストは Failures にまとめられています。
先程の図から推測すると、何らかの要因でレスポンスタイムがどんどん増えていき、サーバーがコネクションを切ってしまったんだと思います。

 

 

4: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped overrun mcast
57485179142 196642925 0       17386   0       8741
TX: bytes  packets  errors  dropped carrier collsns
59179387970 196281286 0       0       0       0

ルーターのネットワークインターフェースを見てみると
LB, API, DB が載ってるサーバーからのパケットで、いくつかドロップされてるパケットがあります。
CDN に Cloudflare を挟んでいるのですが原因は Cloudflare ではなく完全にこちら側ってことが分かります。

 

 


コンテナで動かしているAPIサーバーに16スレッドを割り当ててますがうまいこと全部のスレッドを使っているようです。Go はメモリが全然消費されなくてすごいですねぇ
ここを見ている限り、平均70%のCPU負荷で %iowait もそこまで高くないため（そもそもディスクの読み書きがないようなAPI）、LBかDBのような感じもします。

 


LBは2段あって、3段目にAPIがあるわけですがこの画像には写って無くて申し訳ないですが（画像は最上段LB）、最上段LBは HTTP Error が発生していましたが、2段目のLBでは HTTP Error が発生していませんでした。

DBは Slow Query はないけど、%iowait が少し高かった。

ということで原因は最上段LBか、DBか、ルーター or スイッチかもしれません。
はたまた違うかもしれない。次はルーターのバッファの拡張と、DBをチューニングして再挑戦しよう。
FDもリソースも余裕があるように見えるけどまだ解決はできてない。難しいけど楽しい。