こんにちは。アメーバでアプリケーションエンジニアをしている寺本と申します。

2012年11月7日～9日まで、QCon San Francisco 2012に参加してきましたのでレポートさせていただきます。QConは、ソフトウェア開発者向けの世界的なカンファレンスで、年4～5回、世界各地で開催されています。

今回はサンフランシスコのハイアットリージェンシーホテルが会場で、参加者は複数のテーマに沿って同時並行で行われるセッションの中から興味のあるものを選択して聴講していきます。3日間のカンファレンス期間を通じて、延べ18セッション程度を聞いた形になります。

全てを紹介することはできませんが、今回は興味深かったセッションについて、前編、後編に分けていくつか紹介させていただきます。前編は、私、寺本がお送りします。

なお、当日の発表資料は、こちらからダウンロードできます(2012年11月末時点)ので、興味の有る方は是非どうぞ。

それでは、早速セッションの紹介に移りたいと思います。私は、Twitter、Facebook、Googleの中の人のセッションを紹介します。長文ではありますが、とても興味深い内容だと思いますので、是非最後までご覧ください。

Twitterは、世界で最大級のタイムライン配信システムを運用しています。通常状態において、ツイート、ソーシャルグラフの変更、ダイレクトメッセージなど、秒間数千ものイベントを受け取っていて、これらは、Disk、インメモリのタイムライン、email、モバイルデバイスに配信される必要が有ります。これらを捌くためのインフラを構築、管理、デバッグするのは、Twitterエンジニアの大きな挑戦です。このセッションでは、Twitterのアーキテクチャを理解するため、ユーザーのツイートの裏で行われる処理とアーキテクチャの説明がありました。

現在のTwitterは、1.5億人以上のアクティブユーザーがいます。生半可なタイムラインアーキテクチャでは簡単に破綻するため、如何に効率よく、スケールするアーキテクチャを構築できるかが、彼らの技術的チャレンジとなります。

ユーザーのツイートにより、Write APIが呼び出されると、Fanoutと呼ばれる処理が行われます。Fanout処理では、ユーザーのフォロー情報を元にして、適切なユーザーのタイムラインにツイートを配信していきます。タイムラインは、メモリ上のみに存在しているとのことで、実際にはツイートID、ユーザーIDなどから構成されるID文字列をRedisに格納しているとのことでした。

個人的に業務でタイムライン型のアプリケーションを扱っていたこともあり、Twitterのアーキテクチャについてはこれまでにも資料を見たことがありましたが、KVSはMemcachedを使っているという認識でした。現在はRedisを使っているということで、どこかで移行した模様です。また、Redisは、格納するデータの型に様々な種類があるのが特徴ですが、TwitterではList型を使っているようです。 

なお、現在のツイートの量は約4億ツイート/日で、平均すると5,000～7,000ツイート/秒、大きなイベントがあると、1万2,000ツイート/秒を超えてくるそうです。これに対し、これらのツイートにより発生するタイムラインへの配信件数は300億配信/日、30万配信/秒です。

つまり、秒間5,000～12,000程度のツイートの裏で、Fanout処理により秒間30万のRedisへの書き込みが発生しているということになります。30万/秒の書き込みですから、相当なものです。

一般的にフォロー関係の存在するタイムライン形式のアプリケーションでは、多数の人間にフォローされている人間が投稿すると、全てのフォロワーのタイムラインに書き込みが発生するため、処理に時間を要します。Twitterでも、オバマ大統領、Lady GaGaといった多数のフォロワーを抱えるセレブリティのツイートに関しては、Fanout処理に時間がかかるとのことで、彼等にTwitter上で頻繁に会話されるととんでもないことになると冗談まじりに話していたのが印象的でした。

ツイートをリアルタイムで検索できるようにするための仕組みとして、Earlybird、Blenderが紹介されていました。

Earlybird、Blenderについては、Twitter社のエンジニアブログで記事になっていますので、興味のある方は是非ご覧ください。

また、Krikorian氏は、片手にリモコン(?)を持ち、必要最小限の文字で構成された資料に対して、終始滑らかな語りでプレゼンを展開していくというカッコいいものでした。同僚の佐野氏も、プレゼン無双だと絶賛しておりました 笑

サービスの成功に伴ってエンジニアが急増していく状況のFacebookにおいて、エンジニア1人当たりの生産性を維持・もしくは向上させるための試みについてのお話です。エンジニアリングマネージャーのMortenson氏が大きく3つのチャレンジについて話してくれました。

Facebook社では、サービスの成長とともに急激にエンジニアが入社していました。2008年頃には、100人前後だったエンジニアリングチームは、2012年には1,000人を超えています。毎月入社してくるエンジニアが一人前のパフォーマンスをするようになるでは、一定の時間がかかり各チームはこれらのエンジニアを成長させることにたくさんの時間を使っていました。

これに対するソリューションとして、新入社員に対して6週間程度のブートキャンプを実施するようにしたとのことです。

ブートキャンプのゴールは以下です。

Mortenson氏によると、実際の内容は以下のようなものだそうです。

Mortenson氏は、ブートキャンプの成果について以下の様にまとめました。

弊社サイバーエージェントもこの数年目覚ましい速度でエンジニアが増えており、Facebookでの取り組みは非常に参考になるものでした。

以下の理由に基づき、開発のあらゆる作業における待ち時間を、最大限短縮するための努力を行っているとのことでした。

１つの例として、開発環境のページロード時間の短縮の取り組みについて話をしてくれました。また、その他の重要なエリアとして、以下のようなものを挙げてくれました。

エンジニアとして開発をしていると、待ち時間が如何に開発の集中力を削ぐものであるかは実感を持って理解できます。特に開発で繰り返し実行する上記のような作業については、少しでも待ち時間が短くなる努力をすべきだなと感じました。

2008年頃までは、Facebookのコードは比較的シンプルで理解しやすいものだったようです。変更が引き起こすバグの可能性についてもある程度予測できたため、テストは開発者が個人のサンドボックス環境で行っていたとのことです。

しかし、2009年頃には、以下のような理由で、他のエンジニアの作業を阻害したり、本番環境にリリースされるバグが増え始めたようです。

そこで、以下のようにして自動テストが導入されたとのことです。

これによって最初の３年で3000程度のテストが書かれ、テストがカバーしている領域における不具合や、ユーザーに影響を与える欠陥は減少しました。しかし、その後テストの増加に伴い、失敗するテスト数も増加していきました。最も悪い時期で、5,000程度のテストに対して、100程度のテストが失敗しています。彼らは失敗するテスト数の0に近づけるために、以下のような努力をしています。

これにより、一回のテスト実行で失敗するテストの数を40～50程度に減少させることに成功したようですが、さらに減少させるためにPhabricatorという開発者向けのコミュニケーションツールを使っています。Phabricatorは、Facebookが開発したオープンソースのツールで、コードレビューツールから、バグトラッキングシステムまで様々な機能が搭載されています。

これらの複合的な努力と工夫の結果、現在では9,000以上のテストに対して、失敗するテストの数を20程度に抑えることに成功しています。

テストを書くのは大事なことで、自分のチームでも単体テストを書きますが、Facebookでの事例と同様に、気を抜くとたまに失敗するテストが出てきます。しかしながら、サービスが成長し、コードの規模が大きくなっても彼らのように全てのテスト成功することに執着する姿勢は忘れないようにしたいものです。

最後に、これらの取り組みは当初の目的であるエンジニアの生産性向上に照らし合わせて、結局のところうまくいったのかについて、Mortenson氏はコードベースへのコミット数を使って説明してくれました。エンジニアの増加と共に、コミット数も順調に伸びていて、当初の生産性を維持・もしくは向上させていることが分かります。

The Mobile Web Developer's Tool Belt
～Google スマートフォンディベロッパー向けのツール群紹介～

Pete LePage, Developer Advocate, Google

スマホディベロッパー向けの有用なツール群や、Tipsをたくさん紹介してくれました。
こちらのプレゼンについては、下記のページでも公開されていますので、是非ご覧ください。
http://goo.gl/kIfUe

ここではいくつか気になったものをご紹介します。

Sublime Text 2
最近話題のSublime Text 2ですが、LePage氏も一押ししていました。とにかくベタ褒めしていた印象です。Webディベロッパーの方は是非試してみてはいかがでしょうか。


www.mobile-patterns.com
モバイル向けのUIについてインスピレーションを得るためのサイトとして紹介されていました。様々なUIパターンが登録されていて、UIカタログの様に使えそうです。

pttrns.com    
こちらは、iOS向けアプリのUIカタログのようです。

JSConsole
スマホ実機でデバッグができるようになるサービスです。

HammerJS
タップ、ダブルタップ、スワイプなどのマルチタッチジェスチャーを用意に使えるようにしてくれるライブラリです。

Lawn Chair
インデックスDB、WebSQL、ローカルストレージなどに対して、それぞれのサービスの実装を抽象化して、シンプルなAPIを提供してくれるライブラリです。

他にも本当にたくさんのツールやTipsが紹介されており、とにかく実践的な内容のセッションでした。是非、オリジナルの資料を確認してみてください。きっと何かしら有用な情報があると思います。



QCon 全般について
個人的には、エンジニアとしていつか本場に行って、一流のエンジニアリングの世界を肌で感じてみたいという漠然とした夢がありました。プレゼンをしているエンジニアは世界でも一流の方々ばかりで、話している内容も素晴らしかったですし、プレゼンも極めて上手な方が多かったです。

英語のリスニング力が不足しているせいで、細部の情報を相当聞き漏らしているため、かなりもったいないことをしたと悔しい想いで一杯ではありますが、本当に良い刺激をもらい、少しでも彼らに近づきたいとモチベーションが向上しました。日々の業務に意識高く取り組むことで成長し、いつかまたこのような場に参加したいと思います。

さて、次回は後編として、QConに一緒に参加したインフラエンジニアの佐野さんからレポートをお届けします。お楽しみに！


（おまけ）
カンファレンスの後、週末を使ってシリコンバレーまで足を伸ばしてみました。
佐野氏と一緒に、Apple、Google、Facebookの本社を見て回ることができました。


こちらはクパチーノにあるApple本社。本当はここのAppleストア限定のAppleロゴ入りグッズが色々と買えるはずだったのですが、週末ということで閉まっていました。無念orz

こちらはマウンテンビューにあるGoogle本社。とんでもなく広大な敷地に、無数の建物が有りました。マウンテンビューは一つの街なのですが、半分がGoogleらしいです。

パロアルトにあるFacebook本社。本社前にはこんな看板が有ります。観光客が何人かいて、この前でいいね！のポーズをしてました。僕らももちろんやりましたが 笑