Twitter Tokyo Open House に行ってきた
Twitter 社のひとが (API の使い方とかではなく) Twitter の裏側について話す Twitter Tokyo Open House というイベントがあったので行ってきた。
Rob Benson - Twitterの今を支えるアーキテクチャ
はじめは Engneering Director の Rob Benson さん。Twitter の前は VMWare, その前は Sun で働いていた Rob さんは今は Twitter のバックエンド側の偉い人である。
- Twitter は大きく4層にわかれている。
(RBB TODAY に スライドの写真 がある)
- ストレージ: Timeline, Tweet, Social Graph, User
- モデル: Timeline, Tweet, User
- Composition: API, Web インターフェース
- HTTP フォワードプロキシ
- モデルと Composition をまたぐ Twitter App
- Composition に Web インターフェスがあるので、正直いうと、これが何を指すのかはよくわからなかった...
- Twitter の特徴: concurrency の高さ、IO の量、persistent なものが少ないこと
- 高い workload をさばけて mature な concurrency モデルをもつものとして Java VM を、そこで動く柔軟性の高い言語として Scala を使っている。
- 分散システムのパフォーマンスを測るのは簡単ではない。社内には Google の Dapper のようなトレーシングシステムがある。
ここからが ongoing だという仮想化のはなし。といっても1台を複数に割るのではなく、沢山の台数を1台にするはなしです。
- いまは Apache Mesos をつかって沢山の台数のマシンをまとめて、ひとつの計算クラウドとして扱えるようにしようとしている。(これも RBB TODAY の写真 を参照)
- サービスは特定のホストではなく、クラウドに対してデプロイされる。
- クラウドのどこかのホストにデプロイされたサービスは ZooKeeper に「このホストにこのサービスが立ち上がりましたよ」というプレゼンスを通知する。
- フォワードプロキシも同様に ZooKeeper から制御される。
ここは Morrita さんの Google+ に詳しく書いてある のでそちらを参照してください。
山本 裕介 - Twitterとオープンソース
つぎは山本裕介さんのオープンソースまわり、というか主に Hogan.js の話。
- Twitter では様々なオープンソースソフトウェアを公開している。たとえば Bootstrap は GitHub で最も fork されているレポジトリ である。
- 一番上の octocat/Spoon-Knife は Help.GitHub とかに出てくる、いわば example.com みたいなものなのでカウントしない
- 今回紹介するのは Hogan.js というテンプレートエンジン。
- Mustache の JavaScript 実装 としては mustache.js があるけどそれよりも速い。
発表では Hogan.compile で関数がつくれるところが強調されていたけど、mustache.js も去年の12月に Parser rewrite が入って、関数はつくれるようになっているみたい。
ただ、サーバーサイドでテンプレートをコンパイルして、クライアントサイドにはその実行に必要な最小の部分を置く、というのは mastache.js には出来ない。これができる Mastache 互換の JavaScript 実装には、Hogan.js と (Ember でも使われている) Handlebars がある。(Handlebars は Morrita さんに教えてもらいました)
蓑輪 太郎 - Twitterエンジニアの1日
フロントエンド側をやっている蓑輪さんは Twitter 社の仕事の流れについての話。
- 所属は International Enginnering Team
- チームは本社にも日本にもメンバーがいる。
- 仕事は RTL な言語のあつかいから、日本の (i-mode とかの世代の) 携帯電話対応まで幅広い。
- 開発者が手元でつかうマシンはすべてが Mac に統一されている。
- 使っているソフトウェア
- 課題管理: JIRA
- Wiki: Confluence
- コミュニケーション: Google Chat など
- バージョン管理システム: Git
- コードレビュー: Review Board
Review Board を使っているのはやや意外で、JIRA, Confluence と Atlassian のソフトウェアがそろったら Crucible にいくか、あるいは Git なので Gerrit というのかと思っていた。
- チケットができてからリリースまで (RBB TODAY のスライドの写真) は最短で24時間くらい。
- 書くものは主に Rails まわりと JavaScript, いまは後者が大体70%を占めている。
- コードレビュー
- make review と打つとコードレビューの依頼的なものがつくられる。
- コードレビューは2人のレビュアーからのレビューが必要。
- レビュアーは「別の開発者」のことで、WebKit のようにする人しない人が分かれてはいない。
- だれがレビューするかは、自分で選ぶことも、プロジェクトマネージャーが選ぶことも、あるいはこの部分に詳しいあのひと、ということもある。
- テスト
- いわゆる単体テストと、Selenium をつかったテストとがある。
- テスト専門職の人によるテストはない。開発者がテストする。
開発者がテストするというのは GTAC 2011 の Keynote でも少しふれられていたし、流行ってるなあ。仕様が複雑じゃなければできるものなんだろうか。