それっぽい分散テストツールっぽいものをいくつか

短期間にブラウザのタブがたまってきたのでここいらでひとつまとめておこうと思う。

なにより驚いたのはChaos Monkeyというやつである(via forbes.com)。日本では知名度は低いが、NetflixはインターネットTV(というと分かりやすいかな?)の米国最大手でCassandraやAmazon EC2のビッグユーザーである。最近だと何やらオープンな形でCDN事業に参入しようとしているとか、まあひかりTVなどをやろうとしているNTTからみると協力なライヴァルではいぱーじゃいあんとである。
そのNetflixが、分散システムのテストでCassandraプロセスをわざと強制終了して常に障害耐性をテストしていると言っていたが、ついにそのソースコードが公開された。残念ながらバージャーでGradleという私からは最も遠い世界なのでソースコードは全く目を通せていないが、サービスを運用するためにはこの種のツールは必要だろう。まあ実際に物理サーバーをDCに入れて運用すると割といい頻度で故障はするので、やはり故障がみえにくいEC2ならではのメリットといったところだろうか。GitHubにWikiがあって、中身を知りたい人はここから始めるとよいだろう。

次はdtesterというものである(via @maropu)。Postgres-Rというプロジェクトでは、まあその名の通りレプリケーションをするので台数は少ないながらもレプリカは分散していなければならない。分散システムのテストは難しく副作用の塊なので、既存のユニットテストフレームワークを組み合わせるだけでは簡単には作れない…というところは普段から体感して分かっているつもりだが、とはいえリンクされているふたつのサンプルをみたもののEvent Drivenなテストしか書かれておらずよく分からなかった。興味ある人は調べてほしい。たとえば未来の俺とか。

SysTestはErlangerには多分うれしい。Distributed Application(つまりFailoverとかTakeoverするやつ)のテストが書けるらしいのだが、どうもプロセスをKillしたりとかrpcでリモートのノードを操作したりとかそういったこともできるようで、単なるcommon_testの拡張というか類似製品ではなさそうだ。僕もその昔そういうものがほしいと思ってレポジトリだけ作ったが本当に何もしなかった(結局いらなくなった)ので、実に素晴らしいことである。ドキュメントがまだ揃ってないんだーと作者も言っているので、興味ある人はソースを読んだり、スレの流れを追ってみてほしい。たとえば未来の俺とか。

次がsuma先生のdtestである。PFIのインターンで作ったもののようで、この記事をよめばいかによく考えられて作ったものであるかが分かる。リモートマシンで動いてくれないかなあ。いやしかしRubyだしなあ…

最後にひとつ、思いだしたので。古橋君のChukanは先駆者的な存在で、こっちは本当にリモートのマシンでコマンドを実行できるようになっているというスグレモノだ。ただし作者が今は使っていないらしく、ソースコードのメンテナンスは3年前で止まっている。惜しい…が、結局本当に必要な人は少数だし頑張ったところできることが限られているから、みんなあまりやらないのだろうな。

ひとくちに分散テストといってもいろいろあって、

  1. クライアントからの機能テスト(一直線)
  2. 複数クライアントからの機能テスト(タイミング依存でチェックが必要)
  3. 故障が起きたときなどの準正常系のテスト(フェイルオーバーするよね?とか)
  4. タイミング依存でのデータ破壊がないかの負荷テスト(ぐるぐる回す)

などなど、まあ分類は適当だがこの類のことを開発しながらバグを潰しながらCIするのは非常に難しい問題で、どこかで時間をとって手をつけてみるしかないのだろうなあと思っている。