Facebookのエンジニアリングのブログ(source)上で、ソフトウェアエンジニアであるEugene Letuchy氏が最近、Facebook Chatの背景にあるエンジニアリングに関する決定(source)について詳細を書いた。
機能のユーザベースが実際には一晩で0から7000万になる場合、最初からスケーラビリティを考えておく必要がある。
Eugene氏はそのサイズのユーザベースに対する多くの課題を 特定した。
ユーザがオンラインであろうと、オフラインであろうと、すべての友達に通知を送信するという単純な実装は1秒につきO(平均的な友達リストサイズ*ピーク ユーザ * チャーン率)メッセージという最悪のケースをはらんでいる。ここでチャーン率は、1秒ごとのイベントでユーザがオンラインとオフラインになるユーザの周波 数のことである。ユーザごとの平均的な友達の数が百単位で計測され、サイトのピーク時の並行ユーザの数が数百万であることを考慮すると、このことは広く受 け入れがたいとは言えない。
もう1つの課題は、リアルタイムでメッセージを送ることであった。Facebookは、CometのXHR Long Polling Process(source)と同様な方法をとっている、クライアントがサーバから更新を引き出すテクニックを選択している。
われわれが選択した、1人のユーザからテキストを取得し他のユーザに渡すそのメソッドには、各Facebookページでiframeをロードし、その ifameの Javascriptをそのクライアントのデータをサーバが保持している限り、返さないHTTP GET要求にする。
Eugene氏は続けて「長時間実行中の同時要求が大量にあると、標準LAMPのApacheの部分が疑わしい実装の選択を溜め込んでしまう」と語る。
FacebookはC++およびErlangを選択し、 クラスター化およびパーティション化されたサブシステムを実装する。C++モジュールがチャットメッセージの記録に使用される一方で、Erlangが「オ ンラインユーザの会話をメモリー内に保持し、 長時間ポーリングされたHTTP要求に対処する」。Linux 2.6で導入されている新しいシステムコールは、Erlangモジュールの駆動に使用された。Eugene氏は、Erlangでおこなうことに決めた理由 を以下のように述べている。
つまり、問題のドメインがグローブのようにErlangとぴったり合う。Erlangは機能的な並行性指向の言語であり、極めて軽量なユーザスペース「プ ロセス」、 share-nothingメッセージパッシングセマンティクス、内蔵型ディストリビューションを装備し、大規模なソフトリアルタイム稼動システムでの 20年間にわたるデプロイメントによって証明された「クラッシュおよびリカバー」の考えを固持している。
「スケーラブルなクロス言語サービス開発」向けのオープンソースフレームワークであるThrift(source)(昨年のエイプリルフールにFacebookに よってリリースされた)は、Facebook Chatで使用されているさまざまなテクノロジーを結束させるために使用された。今は、Erlangのバインディングを特色としている。
かつて興味深いアプローチは、いわゆる「dark launch」と呼ばれるサービスのロールアウトであった。
ユーザが一晩で0から7000万になる秘密は、すべてを一挙にするのを避けることである。われわれは「dark launch」期間、多くのマシンを叩いているリアルユーザの影響をシミュレーションすることにした。「dark launch」では、Facebookページがチャットサーバと関連づいて、情報の照会をし、ページに描かれた単一UIエレメントなしでメッセージ送信を シミュレートする。
FacebookエンジニアによるErlangの選択は、その言語にとって重要な承認である。 ErlangのエバンジェリストであるYariv Sadan氏(source)は、以下のように述べている。
この発表によって、Erlangがスケーラブルなリアルタイム(aka Comet)アプリケーションを構築するための *the*プラットフォームであることに対するあらゆる疑いを取り除くに違いない。
原文はこちらです：http://www.infoq.com/news/2008/05/facebookchatarchitecture