グリーン破壊の破壊度をアップしました
負荷試験ツール「グリーン破壊」を公開しました で紹介したグリーン破壊ですが、その後も KLab 内の案件で利用されつつ 地道に強化されています。 最近強化された点を2つ紹介します。
分散攻撃
以前紹介した時のグリーン破壊は fork して複数プロセスから攻撃する方式だったのですが、 execnet というライブラリを用いて実際に攻撃を行う外部プロセスを作成するようにしました。
execnet は fork&exec だけでなく、 ssh 経由でリモートマシン上に外部プロセスを 作ることができます。グリーン破壊もこれを利用して分散攻撃ができるようになりました。
設定ファイル (YAML) に次のようなセクションを書くと、ローカルに2プロセス、
attacker ホスト上に 4 プロセスの合計6プロセスから攻撃を仕掛けることができます。
#破壊ノード
nodes:
- host: localhost # localhost の場合は ssh ではなくて popen します
proc: 2 # この host で起動するプロセス数
- host: ghakai@attacker # ssh先
proc: 4
注意点として、外部ホスト上で攻撃プロセスを立ち上げる時も、グリーン破壊を起動したマシンと同じ ディレクトリにある Python を利用するので、グリーン破壊をインストールしたディレクトリを rsync かなにかで同期しておく必要があります。
グリーン破壊を AWS で使う場合、1インスタンス当たりの性能は物理マシンほどでない ことが多いので、 Spot Instance と組み合わせて使うのがお勧めです。
名前解決
過去のグリーン破壊は普通に、名前を問い合わせて、結果を上から順番に利用するという形で名前解決をしていました。
しかし、 Keep-Alive が無効のサービスに対して負荷試験するときに名前解決がボトルネックになったり、 AWS の ELB を利用したプロジェクトに対して負荷試験するときにローカルのDNSキャッシュのせいで 攻撃先IPアドレスが分散しなかったりすることがありました。
そこで、最初に名前解決を実行し、解決結果を全て覚えておき、接続する時は上から順ではなくて ランダムに利用するという方式に変更しました。
ただし、長時間攻撃を継続する場合、 ELB がスケールアウトしてもグリーン破壊は追従しません。 もともと可能な限り Keep-Alive する上に、接続が切れても再接続時に名前解決をしないからです。 ELB 経由で負荷試験を行う場合は、一度グリーン破壊を実行してウォームアップして ELB をスケールアウトさせてから、グリーン破壊を再実行してください。
また、思ったように負荷がかからないでレスポンスタイムが低下するときに ELB の問題と アプリの問題を切り分けるとか、 ELB のウォームアップが面倒なときのため、負荷分散を 通さず直接攻撃する機能も搭載しました。
設定ファイルに domain と addresslist の両方を定義すると、接続先は addresslist
からランダムに選ばれ、 HTTP の Host ヘッダには domain の内容が記述されます。
#攻撃先のドメイン. これ以外のドメインは攻撃しない.
# Host ヘッダにこのドメインが書かれる.
domain: "http://localhost:8889"
#接続先アドレスリスト. 省略した場合は domain を利用する.
addresslist:
- 127.0.0.1:8889
- localhost:8889
