Twitterのパフォーマンス対策

IT

@IT:秒間120万つぶやきを処理、Twitterシステムの“今”
最近Twitter重い時があると思ったら700req/secもあるんだ。イベント時には2,000req/secあるってことだし、それに対する処理も加えると1,200,000req/secということで、相当なパフォーマンスチューニングが必要だよね。TwitterはそもそもシンプルなWebサービスなだけに、立ち上げ当初のデータ管理は、素直な作りになってる。そこから現在のサービスに成長するまでの、試行錯誤のパフォーマンス対策が書かれていて興味深い。その対策を挙げると、、、

  1. memcachedによる高速化　・・・　メモリキャッシュサーバにより、RDBMSの負荷を軽減。これは定石。
  2. 時系列のパーティショニング　・・・　「なぜ時間をキーに？」と思ったが「Twitterの特殊性：ほとんどのクエリは、より新しい情報へのバイアスがかかっている」より、ほとんどのクエリが最新のパーティションに対するクエリでだけで完結する為とのこと。
  3. fan out　・・・　タイムラインの高速表示を実現する仕組み。受信箱を作成し、そこにフォローするユーザーのつぶやきを定期的に登録していく非同期のオフライン処理。(が、遅延は数秒程度を上限としたもの）
  4. フォローと被フォローの関係をそれぞれ別にデータに持つ　・・・　非正規化。それぞれのデータテーブルの同期を取る必要はあるものの、クエリを特定パーティションへのアクセスで完結できる。

Twitterはまだまだ課題がある(例：検索インデックスについても時系列のパーティショニングを行っており、検索される頻度が低い単語などでは最新パーティションにインデックスがないため何もヒットしないということが起こる)が、様々な案が検討されているとのこと。
読んでいて興味深かったのは、Webサービスのパフォーマンスチューニングについて（もちろん構築・運用についても）、アドホックに対応しなければならない部分。つまり試行錯誤が大事ってことで、結局それに合う手法はアジャイルってことに落ち着く。この辺は経験則になるので、現場を知らない管理職には説明が難しい部分でもある。