テーマ:
こんにちは。アメーバでアプリケーションエンジニアをしている寺本と申します。
2012年11月7日~9日まで、QCon San Francisco 2012に参加してきましたのでレポートさせていただきます。QConは、ソフトウェア開発者向けの世界的なカンファレンスで、年4~5回、世界各地で開催されています。

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

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

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

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

Timelines at scale
~Twitter 1日4億件のツイートの裏側~

Raffi Krikorian, Senior Director of the Platform Services group, Twitter

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





Building for a Billion Users from Silicon Valley
~Facebook エンジニアの生産性向上に向けた取り組み~

David Mortenson, Engineering Manager, Facebook


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

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


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

ブートキャンプのゴールは以下です。
・カルチャー面、技術面で、彼らが早期に軌道に乗るようにキャッチアッップさせる
・コードベースのたくさんの異なるエリアを開示し、触れさせる
・彼らの情熱と能力が最も活かせるチームを見つける
・新入社員のエンジニアに、出来るだけ速く有益な仕事をしてもらう

Mortenson氏によると、実際の内容は以下のようなものだそうです。
1日目
・ブートキャンプメンバーとの顔合わせ
・開発サーバーのセットアップ
・Facebookのコードベースのコアコンセプトを学習する
・最初のタスクをこなす

1週目
・Facebookで仕事のやり方についてのトレーニングセッションに取り組む
・自分の開発環境をカスタマイズする
・ブートキャンプの仲間と一緒に過ごす
・最初のタスクを完了させ、Commitする

2~4週目
・自分の最初にした仕事がリリースされ、十億人に届く
・バックエンドService、モバイル、ネットワーク、データセンターデザインなどに関するセッション
・Facebookのスタックを横断するブートキャンプタスクの実施

4~6週目:チームの選択
・エンジニアを必要としているたくさんのチームについて学ぶ
・自分が最も興味を持っているチームのエンジニアと合う
・トップチームのための、ブートキャンプタスク
・自分の能力と情熱が最大限マッチするチームを選ぶ

Mortenson氏は、ブートキャンプの成果について以下の様にまとめました。
・約1,000人のエンジニアが卒業
・参加者からのフィードバックは一貫して素晴らしい
・これまでより速く戦力化するようになった
・エンジニアを成長させるためのコストが著しく下がった
・新エンジニアが周囲に認知され、友達を作るまでが早くなった
・Facebookのカルチャーを理解する大きな助けになった

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

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

・集中とフロー状態は、高い生産性のために極めて重要
・開発作業において待ち時間が5秒以上の作業は軽度のコンテキストスイッチを発生させる
・開発作業において待ち時間が2分以上の作業は重度のコンテキストスイッチを発生させる
・これらは生産性を著しく悪化させるもので、如何なる代価を払っても避けるべきものである

1つの例として、開発環境のページロード時間の短縮の取り組みについて話をしてくれました。また、その他の重要なエリアとして、以下のようなものを挙げてくれました。
・ソース管理
・テスト
・静的分析
・タスク/バグトラッキングシステム
・コードレビューツール
・リリース

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

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

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

・開発者がますます増加。300名程度に達した
・Gitの導入によって、並行作業がますます増えた
・コードの複雑性が一人の頭に入る限界に達した

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

・テストを書きやすくするためのフレームワークの作成
・エンジニアの作業フローに単体テストを導入
・当初は、テストを書くのを一つの重要な領域に絞った
・キーとなるチームの中に、エキスパートを育てて行った
・障害の発生を、テストを書くよう奨励する機会として活用した
・ブートキャンプ参加者への教育

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

・価値が低く、いつも失敗している数百のテストを削除した
・1週間以上失敗し続けているテストを無効化した
・断続的に失敗するテストを無効化した
・失敗しているテスト用の分析ツールを構築
・信頼できないテストを書くチームと一緒に働き改善した

これにより、一回のテスト実行で失敗するテストの数を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本社。本社前にはこんな看板が有ります。観光客が何人かいて、この前でいいね!のポーズをしてました。僕らももちろんやりましたが 笑


いいね!した人  |  リブログ(0)

サイバーエージェント 公式エンジニアブログさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

同じテーマ 「サービス・技術」 の記事