Twitter、Ruby on RailsからJVM/Scala基盤へ全面移行
急増するトラフィックにRailsが耐えられなくなったTwitterは、2009年頃からJVM上で動くScalaへの移行を進め、2012年米大統領選の記録的トラフィックを支えた。
課題
急成長でRailsのMySQL負荷や単一障害点のキューが秒間数百リクエストで限界に達した
アプローチ
DRb→Rinda→Erlangと試行錯誤しStarling採用を経てJVM上のScala基盤Blenderへ移行
効果
1サーバーあたりの処理能力が秒間200〜300から秒間1万〜2万リクエストへ向上
背景
Twitterは創業初期、ゼロから数百万ページビューへ数か月で急成長した。当初は監視やグラフ、統計といった仕組みがなく問題の特定が困難で、350,000人超のユーザー、秒間600リクエスト、秒間200〜300(ピーク時最大800)接続という規模でMySQLに過度な負荷がかかり、公開的なスケーリング問題としてたびたびサービス障害を起こしていた。
移行のプロセス
分散処理基盤の選定では複数の技術を試行錯誤した。
- まずDRb(分散Ruby)を試したが不安定で単一障害点になりやすかった
- Rindaへ移行したもののキューが永続化されず障害時にメッセージが失われる問題があった
- Erlangも検討したがドキュメント不足で断念した
- 最終的にRubyで書かれた分散キュー「Starling」を採用しMemCacheプロトコルに対応させた
その後、GCがRubyの最適化を困難にしていたことから、バックエンドをJVM上で動作するScalaへ段階的に置き換える複数年にわたる取り組みを進め、最終的にJavaベースの新バックエンド基盤「Blender」を構築した。
移行前後の変化
| 指標 | Before | After | |
|---|---|---|---|
| 1サーバーあたりの処理能力 | 秒間200〜300リクエスト | 秒間1万〜2万リクエスト |
結果
移行前は1サーバーあたり秒間200〜300リクエスト程度の処理能力だったのに対し、移行後は秒間1万〜2万リクエストまで処理能力が向上した。Blaine Cook氏は「言語変更なら10〜20%の改善だが、アーキテクチャ変更により10000%の高速化を達成した」と述べている。当時の統計は以下の通り。
- 秒間300ツイート(ピーク時)
- 平均応答時間200ミリ秒
- データベース処理時間50〜100ミリ秒
- 180のRailsインスタンス
- 16GB超のmemcached
学び
教訓として「コミュニティと対話し自分たちだけで解決しようとするな」「個別レコードでなくクエリ単位で十分キャッシュが効くのですべてをキャッシュせよ」「データベースを中心的なボトルネックにせず創造的な代替手段を検討せよ」「パフォーマンスは言語でなくアプリケーション設計から生まれる」「APIを通じてサイトをオープンなサービスにせよ」という5点を挙げている。