TwitterがBitTorrentで高速にデプロイしている仕組みについて

2010年7月20日

Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。

FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。

どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterのエンジニア、Larry Gadea氏による「Murder」に関するエントリ「Murder: Fast datacenter code deploys using BitTorrent」とビデオが投稿されました。Gadea氏はMurderの開発者のようです。

公開されたビデオを基に、BitTorrentがどのような仕組みでデプロイに用いられているのか、見ていくことにしましょう。

大学を卒業してTwitterに入社

Larry Gadea氏が自己紹介。私は6カ月前にカールトン大学を卒業したばかりで、そのあとTwitterにインフラストラクチャーエンジニアとして入社した。

Twitterでは大量のサーバを運用しており、それらのサーバに対してのアップデートは素早く行わなければならい。しかしGitサーバに対するアクセスによってデプロイを行うことには非常に問題があった。

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

なぜBitTorrentをベースに選んだかといえば、多くのライブラリがあることが理由の1つだ。

ほかの選択肢としてTreedistという方法もあったが、それほど高速ではなかったのと、ツリーの途中でサーバが落ちていると、それ以後に配布されないと問題があった。もちろん、修正することもできるようだが、それほど効果的な方法とは思えなかった。

さて、BitTorrentによるファイルの配布はこのような状況を想像するだろう。つまり、1人がダウンロードしてアップロードしたものを、みんながダウンロードする、という状況だ。

しかしギガビットイーサネットで接続されているわれわれのようなネットワーク環境では、1人からダウンロードし、アップロードしたらまた1人がダウンロードする、という形式のほうが効率がよい。

この場合には、チェーンが非常に長くなるけれども、ファイルはいくつかに分割されていおり、断片ごとの転送が次々に行われ、マシン間がギガビットイーサネットで接続されているために最初から最後までの転送は非常にシンプルで高速に行われる。

具体的な詳細を説明しよう。まず、1つのサーバに新しいファイルが転送される。そして「Capistrano」がRubyAPIによってすべてのサーバに対して「Trackerへ接続せよ」とシグナルを送る（注：Capistranoは、複数のサーバに同時に指令を送ることができるデプロイツール。Trackerは、BitTorrentのダウンロードサイトを教えてくれるサーバのこと）。

TrackerはBitTorrentネットワークの中央管理サーバで、どこからどこへ接続すべきかを管理している。大量のサーバからTrackerへコネクションしに行くが、短いデータを得るだけで短時間で済むため問題ない。

そうしてあるサーバが別のサーバからデータをダウンロードを開始し、全体のダウンロードが終わったら、メインプロセスはCapistranoへ次の指令を聞きに行く。このとき、プロセスはForkして30秒だけシード（ファイルを配布する役割）となる。これは、どこかのサーバが落ちていたときなどのための最適化でもある。

デプロイ用のBitTorrentには、高速なデプロイのために最適化が施されている。まず、タイムアウトまでの時間を5秒から減らし、リトライまでにかかる時間を短くしたことで全体の性能が向上した。また、暗号化をしないことでCPUの利用を減らした。DHT（分散ハッシュテーブル）による管理は停止し、Trackerだけによる管理にした。