autobench/DOS攻撃


autobenchでDOS攻撃

今回は並列クライアントによるベンチマークが実行できるautobench_adminについてだが、それよりもその前の話を中心に書こうと思う。

そもそも並列のクライアントからベンチマークを実行するということはクライアント単体のベンチマーク性能がウェブサーバの処理能力を下回っている状態であるはず。
ということは最初の数回のベンチマークによって出た値がクライアント側の性能限界なのかサーバ側の性能限界なのかを判断しなければならないのだが、これが意外と難しいことが分かった。

一応ここではまだまだいろいろとテストが足りないことは承知の上で、自分なりに調べてみた結果を備忘録的に残しておく。
正直言ってほとんど法則性が見付けられなかったのでここでの情報はあくまで参考程度。

もし考え方が間違っていることが分かった場合はこっそり笑ってもらうかご連絡下さい。
貴公のブログやtwitter等で笑いものにするのは恥ずかしいのでおやめ下さい。

では本題。
まずはautobenchでテストを数回実行してみた上での結果を見る。
実行したコマンドは以下の様な物。
# PATH=$PATH:/usr/local/httperf/bin ./autobench --single_host --host1 192.168.100.1 --uri1 /test.html \
  --low_rate 1400 --high_rate 1800 --rate_step 100 --num_conn 10000 --num_call 1 --timeout 5 --file /tmp/results.tsv

この時に出る/tmp/results.tsvには以下の様な値が記録される
1400    1399.8  1399.8  1399.3  1399.3  1399.3  0.0     1.1     3272.7  0
1500    1500.0  1500.0  1499.4  1499.4  1499.4  0.0     2.1     3506.8  0
1600    1081.5  1081.8  1536.8  1536.8  1536.8  0.0     75.6    2528.4  0.0300090027008102
1700    1116.3  1128.2  1493.2  1493.2  1493.2  0.0     136.9   2609.6  1.07135637760259
1800    854.7   901.1   358.0   924.2   1490.4  800.7   294.6   1950.2  8.11979673478214
それぞれの値は左から以下の内容
dem_req_rate    1秒あたりの接続数=実行時のrate
req_rate    1秒あたりのリクエスト数
con_rate    1秒あたりのコネクション数
min_rep_rate    1秒あたりの最小リプライ数
avg_rep_rate    1秒あたりの平均リプライ数
max_rep_rate    1秒あたりの最大リプライ数
stddev_rep_rate    リプライレートの標準偏差(ばらつき)
resp_time    リクエストを送った瞬間からレスポンスが返った瞬間までの平均時間(ms)
net_io    通信速度(KB/s)
errors    エラー:正常比率(%)
基本的にはautobench単体=httperfのテスト結果を省略して掲載しただけ。
ちなみにautobench_adminで実行するとこの形の結果しか得られないので、autobench単体と比べると情報量が落ちてしまうのが最大の欠点ではないだろうか。

さて、ここでreq/sが1500から1600の間で一番右の値であるエラー率が0でなくなっていることが分かる。
つまりサーバ、もしくはクライアントの性能限界のどちらかが1500から1600の間に存在しているということ。

ちなみにこの情報だけで判断するのは極めて難しいのだが、これ以外にもいくつか試験を行った上での結論から言うと、実はここで発生しているのはサーバ側の性能限界。
特徴はreq_rateが顕著に低下していくことと、max_rep_rateが概ね1500ぐらいで平行線を辿っていること。

反対に、クライアント側の性能限界の場合は以下の様な感じの結果になる(コマンドは省略)
同じウェブサーバに対して、xm sched-creditでCPU性能を絞ったクライアントでテストした場合の値。
100     99.9    99.9    97.6    99.9    102.4   1.3     3.4     233.5   0
200     200.0   200.0   195.3   199.9   204.8   4.4     6.4     467.6   0
300     300.0   300.0   294.5   298.8   305.4   3.6     22.5    701.3   0
400     355.7   356.5   349.3   360.3   370.2   8.0     313.3   770.6   8.45986984815618
500     347.7   375.4   114.3   284.5   342.0   96.0    761.1   637.3   39.0433815350389
こちらのケースではmax_rep_rateが300~400の間で平行線を辿るのは同じだが、req_rateもあまり変化していなことが分かる。
つまりサーバ側のボトルネックではアクセス過多による処理の低下が発生するが、クライアント側のボトルネックではそれが発生しないようだ。
ちなみにこの環境ではサーバ側のチューニングを一切していないデフォルトの状態で使っているので、きっちりチューニングした場合はこの限りではない可能性があることを考慮する必要がある。

クライアントのボトルネックであることが分かったらautobench_adminコマンドで並列実行を行っていく。

autobench_adminを使うには、まず配下となるノードでautobenchdを起動する必要がある。
PATH=$PATH:/usr/local/httperf/bin /usr/local/autobench/bin/autobenchd
バックグラウンドで動かしたい場合は&なりCtrl+Zなりして下さい。
autobenchdを起動したら、あとは任意のノードでautobench_adminを実行する。
autobench_adminを実行するノードはautobenchdが動いていても動いていなくてもどちらでも良い。
PATH=$PATH:/usr/local/httperf/bin ./autobench_admin --single_host --host1 192.168.100.1 --uri1 /test.html \
--clients 192.168.100.11:4600,192.168.100.12:4600,192.168.100.13:4600 --low_rate 100 --high_rate 500 \
--rate_step 100 --num_conn 10000 --num_call 1 --timeout 5 --file /tmp/results.tsv
オプションは基本的にautobenchと同じで、配下のノードは--clientsオプションでカンマ区切りで繋げていく。
autobenchdのポートは4600番なので、ポートを指定する必要がある。
結果はautobench_adminを実行したノードの--fileのパスに前述の形で保存される。

後はクライアントのボトルネックに従ってクライアント数を増やしながらautobench_adminを実行していくだけ・・・と言いたいところだが、autobench_adminを使って並列実行すると、台数を増やせば増やす程サーバ側のメモリ消費量が激増していく結果となり、サーバ側のボトルネックの値がどんどん下がっていくこととなった。

恐らくサーバ側のチューニングが不十分なことに起因していると思うのだが、現段階では問題がどこにあるのかはよく分からない状態。
また、autobenchではabと異なりconcurrencyがコントロールできないので、そのあたりも事態を理解しにくくしている。

時間があったらもう少し突っ込んでいきたいところだが、今の所はこのぐらいで一区切りとしておこうと思う。

  • 最終更新:2016-01-26 12:26:56

このWIKIを編集するにはパスワード入力が必要です

認証パスワード