Agile Cat — in the cloud

Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!

Posted in Asia, Facebook, Mobile by agilecat.cloud on January 23, 2015
Why Facebook Forces A Bunch Of Its Engineers To Use Terrible, Low-End Phones
http://wp.me/pwo1E-8e2 
Jillian D’Onfro – Dec. 7, 2014
http://www.businessinsider.com/facebook-low-end-phones-bad-network-conditions-2014-12
 
_ Business Insider
 
You might not expect to find many flip phones in the high-tech and free-food laden Facebook offices, but your expectations would be wrong.
 
ハイテクとフリー・ランチが自慢の Facebook オフィスで、数多くのフリップ・フォン(折りたたみ)を見かけるなんて想像もしないだろうが、それは間違った思い込みだ。
 
Facebook is creating a special lab filled with low-end Android smartphones,”crappy old flip phones,” and weak networking to help the company study the computing conditions in parts of the world like rural India that either have limited internet or none at all.
 
Facebook が立ち上げた特別なラボは、ローエンドの Android スマホと、安くて古いフリップ・フォン、そして、脆弱なネットワーキングで構成されているのだ。それにより、たとえばインドの農村のような、インターネットが供給されるにしても、きわめて制約が多いという世界における、コンピューティングの条件を調査することが可能になる。
 
Facebook with old Android
Not actually
Facebook employees
 
Developers have to try to use Facebook’s apps on super-old versions of Android so they can understand what it’s like for people in areas without good network connection.
 
ここでの開発者たちは、きわめて古いバージョンの Android で、Facebook アプリを使用しなければならない。したがって、条件の整ったネットワークに接続できない地域の人々のために、何をすれば良いのかを理解できるようになる。
 
“It’s easy to not have empathy for what the experience is for the majority of people in the world,” Facebook CEO Mark Zuckerberg told Time’s Lev Grossman of Facebook’s employees.
 
「 この世界の大多数の人々のために、どのようなエクスペリエンスを持つべきかと言っても、それに対して容易には共感してもらえない」と、Facebook の CEO である Mark Zuckerberg が、一人の従業員である Lev Grossman に語った。
 
So, the team manufactures empathy.
 
そして、このチームは、その共感を作り出すことになった。
 
“I force a lot of the guys to use low-end phones now,” Javier Olivan, Facebook’s head of growth, says. “You need to feel the pain.”
 
Facebook の Head of Growth である Javier Olivan は、「 私の役割は、より多くの従業員にローエンド・スマホを持たせることだ。 そうすれば、痛みを共有できる」と発言している。
 
And Facebook employees aren’t the only ones getting the terrible-phone treatment.
 
そして、いまでは、そんな旧式フォンの面倒を見るのが、Facebook の従業員だけではなくなってきている。
 
“We brought in some phones, like very low-end Android, and we invited guys from the Valley here—the eBay guys, the Apple guys,” Olivan says. “It’s like, ‘Hey, come and test your applications in these conditions! Nothing worked.”
 
Olivan は、「 私たちは、このラボに、きわめてローエンドの Android などの、いくつかのフォンを持ち込んでいる。 そして、eBay や Apple の、つまりシリコンバレーの仲間たちを招待している。ここに来れば、そこらじゃ有り得ない、特殊な条件でアプリをテストできるという感じで誘っている 」と述べている。
 
That pain is of one of the things motivating Zuckerberg’s work on Internet.org, an initiative which aims to bring internet access to everyone in the world. Facebook recently released apps in Zambia and Tanzania with content like Wikipedia, Google Search, and AccuWeather that local people can get and use for free.
 
ここで言う痛みとは、Zuckerberg が Internet.org を立ち上げた、動機の1つでもあるのだ。 この組織は、世界のすべての人にインターネット・アクセスを提供することを目標としている。 最近のことだが、Facebook は Zambia と Tanzania の人々に、Wikipedia/Google Search/AccuWeather などを使用できるアプリをリリースしている。 そして、それらの地域の人々は、それらを無償で利用できるのだ。
 
Read the rest of Time’s profile of Zuckerberg and Internet.org here.
ーーーーー
facebookタイトルには「アジア」キーワードを使ってしまいましたが、それ以外にも、南米やアフリカのマーケットもあります。 低品質のネットワーク環境で、Facebook を使う貧しい人々のことを考えると、Menlo Park のキャンパスで、こうした取り組みが進められていることが、とても嬉しく思えてきます。 そして、以前にポストした「Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!」や、「Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!」といった抄訳を読み返すと、心から拍手を送りたくなってしまうのです。_AC Stamp
ーーーーー
<関連>
Facebook と Mark の途上国戦略:Coca-Cola スタイルの長期スパンで考えていく
Zuck が Cook に 一発かました:もっと Apple は、自分の顧客を大切にすべきだ!
iOS から Android へ : Facebook は優先順位を切り替えるのか?
2012年:ネイティブの Facebook App for Android が、最終テストの段階らしい!
2012年:Droid フードって Cat フードよりも 不味いの? Facebook さん・・・
2014 Agile Cat:大人になった Facebook の マトメ

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

Facebook が発表した Folly は、宝石のような オープンソース C++ ライブラリなのだ!

Posted in .Selected, Big Data, Facebook by Agile Cat on June 6, 2012

Facebook unveils Folly, a treasure trove of open-source C++ gold
http://wp.me/pwo1E-4hA

Jolie O’Dell – June 2, 2012 3:00 PM
http://venturebeat.com/2012/06/02/facebook-folly/

_ VB Dev

“Facebook’s Folly” — sounds like a mid-life-crisis-type watercraft, doesn’t it? But it’s actually a huge bundle of C++ utilities focused on speed, ease of use, and interoperability with other C++ libraries you already use.

Facebook の Folly(愚行)って、中年の危機みたいな名前をヨットにつけるようで、なかなかイカしていない? しかし、それは、スピードと使い易さを考慮し、また、既存の C++ ライブラリとのインターオペラビリティも実現する、大規模な C++ ユーティリティーなのである。

Gemenacom, Shutterstock ⇒ 

The collection of reusable C++ library artifacts was developed in-house at Facebook to meet the needs of Facebook’s engineers. As they have done in the past with other open-source projects like Cassandra, HipHop, and Thrift, Facebook’s developers have now placed Folly into the realm of open-source software.

この、再利用が可能な C++ ライブラリのコレクションは、Facebook エンジニアの要求を満たすために、インハウスで開発されたものである。これまでに、Cassandra/HipHop/Thrift などをオープンソース化してきたように、Facebook のデベロッパーたちは、この Folly をオープンソース・ソフトウェアの領域に置いた。

“The development of [Folly] was fueled by the desire to create complementary utilities that allowed us to move fast and not reinvent any wheels,” a Facebooker told VentureBeat last night in an email. “We worked to make this library as fast and easy-to-use as possible.”

「 この Folly の開発は、補足的なユーティリティーを作成したいという要求により促進された。それは、私たちにスピードを与え、また、煩わしさを取り除いてくれた。 このライブラリを、可能な限り高速であり、また、使い易いものにするために、私たちは作業してきた」と、昨夜のことだが、ある Facebooker が VentureBeat にメールを送ってくれた。

The rep noted that Folly is obviously going to be useful for developers of large-scale, distributed apps with significant performance challenges. But he said the library is also “of general utility” for other types of C++-using developers, as well.

この代表者は、パフォーマンスという大きな課題を持つ、ラージ・スケールの分散アプリケーションに取り組むデベロッパーにとって、Folly は明らかに有用であると指摘した。そして、このライブラリは、他の C++ を使用するデベロッパーのための、「一般的なユーティリティ」にもなると付け加えている。

“Folly also contains state-of-the-art work-alikes for two common C++ standard library utilities (std::string and std::vector), which may be useful for anyone who does not have access or a license to a quality C++ standard library, or who might want to use those classes in an embedded setting where they are avoiding most of the rest of the standard library for code size reasons,” he said.

「さらに Folly には、2つのコモン C++ スタンダード・ライブラリー・ユーティリティー(std::string と std::vector std)に似た、最新のテクノロジーが取り込まれている。まず、高品質な C++ スタンダード・ライブラリにアクセスするための、ライセンスを有していない開発者に有用だろう。あるいは、コードサイズの理由から、スタンダード・ライブラリを避けたいエンベディッド設定で、それらのクラスを使う開発者にも有用だろう」と、彼は発言している。

facebook_logoAlso, because it breaks dependencies on Facebook’s internal code, Folly will allow Facebook to open-source even more of its homebrewed software — an exciting prospect, given the caliber of engineer the company hires.

さらに、そこでは Facebook のインターナル・コードへの依存性が断ち切られているため、Folly は Facebook に対してさえ、自家製のソフトウェア以上のオープンソースを提供する。 つまり、同社が採用するエンジニアの力量を前提とした、エキサイティングな展望が開けてくる。

The company announced the library today during the C++ conference at its Menlo Park headquarters.

今日のことだが、Menlo Park HQ で開催された C++ カンファレンスにおいて、このライブラリが発表された。

“This is code that runs on thousands of servers doing work on behalf of 900 million users every day,” wrote Facebook software engineer Jordan DeLong today on the company blog. “The over-arching theme for all of the components is high performance at scale.”

「これは、9億人のユーザーをサポートする、何千というサーバー上で実行されるコードある。これら全てのコンポーネントにおけるテーマは、大規模スケールでのパフォーマンスである」と、Facebook のソフトウェア・エンジニアである Jordan DeLong は、今日のブログにポストしている。

DeLong said that Folly was built for comfort as well as speed, meaning it’s easier to use and faster to work with than other alternatives. He also said Folly plays well with others (other C++ libraries of quality, that is). “We have a low tolerance for “Not Invented Here” syndrome,” he said.

DeLong は Foolly について、快適さだけではなく、その実行スピードも考慮しているため、それらの点で他のライブラリより優れる、と発言している。 さらに、Folly は、その他のソフトウェア(他の 高品質 C++ ライブラリ)とも協調できる。 「 私たちは、Not Invented Here シンドロームに耐えられないのだ」と、彼は付け加えている。

You can check out Folly for yourself on Facebook’s Gitub page.

Facebook の Gitub ページ で、Folly を確認して欲しい。

ーーーーー

TAG indexちょうど 1年ほど前のことですが、High Scalability  Todd Hoff さんの記事である「MySpace を殺したのは Microsoft ソフトウェア・スタックなのか? いや、それは違うだろう」を訳しました。 そこでは、「Myspace には、Facebook と競合するために、自身のサイトをスケールしていくだけの、プログラミングに関する能力が備わっていなかった」、「Microsoft スタックの選択は、Facebook と競合するために必要な、人材の確保を困難にした」、「Facebook の選択である LAMP スタックは、スケーラブルを知っている人材の確保を容易にし、それを迅速に実現する」といった指摘がなされていました。 この Folly の発表を見て、そんなことを思い出しました。 ーーー ac-stamp-232

ーーーーー

<関連>

Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook Billion 単位のメッセージを処理していく
Facebook は、毎月 1350億メッセージを処理する!
Facebook における 1300万/秒クエリーの秘密
Facebook 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!

Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _3

Posted in Facebook by Agile Cat on July 9, 2010

Exploring the software behind Facebook, the world’s largest site _3
Posted in
Main on June 18th, 2010
by Pingdom
http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/

image_thumb2

いよいよ最終回です。 前回は Facebook が利用しているソフトウェアをリストアップしていましたが、そこには含まれなかった運用に関するノウハウを、今回は紹介してくれます。 スケールという視点からして、参照できる事例のない Facebook としては、道なき道を切り開いていかざるを得ないわけです。 したがって、他では聞くことのできない貴重な情報が、たっぷりと含まれている記事となっています。 楽しんでくださ~~~い。 ーーー A.C.

ーーーーー

Other things that help Facebook run smoothly

We have mentioned some of the software that makes up Facebook’s system(s) and helps the service scale properly. But handling such a large system is a complex task, so we thought we would list a few more things that Facebook does to keep its service running smoothly.

ここでは、Facebook のシステムを構築し、サービスのスケールを適切に支援する、いくつかのソフトウェアを説明してきた。 ただし、このような大規模システムの取り扱いには、複雑なタスクがつきものだ。 したがって、Facebook がサービスを円滑に提供するために用いている、いくつかの事柄についてリストアップしておく。

Gradual releases and dark launches

Facebook has a system they called Gatekeeper that lets them run different code for different sets of users (it basically introduces different conditions in the code base). This lets Facebook do gradual releases of new features, A/B testing, activate certain features only for Facebook employees, etc.

Facebook は、それぞれのユーザーのグループに対して、異なるコードを実行させる、Gatekeeper というシステムを持っている(基本的にコードベースに異なる条件を導する)。 それにより Facebook は、新しい機能の段階的なリリースや、A / B テスト、従業員に限定した特定機能のアクティベーションなどを実現している。

Gatekeeper also lets Facebook do something called “dark launches”, which is to activate elements of a certain feature behind the scenes before it goes live (without users noticing since there will be no corresponding UI elements). This acts as a real-world stress test and helps expose bottlenecks and other problem areas before a feature is officially launched. Dark launches are usually done two weeks before the actual launch.

さらに Gatekeeper は、Facebook における運用前の機能を、“Dark Launche” と呼ばれる仕組みの中で実施していく(そのための UI は存在しないため、ユーザーは気付かない)。それは、現実世界のストレス・テストの役割を担い、また、対象となる機能が公開される前に、ボトルネックなどの問題点を明らかにしていく。Dark Launche には通常、公開前の 2週間が費やされる。

Profiling of the live system

Facebook carefully monitors its systems (something we here at Pingdom of course approve of), and interestingly enough it also monitors the performance of every single PHP function in the live production environment. This profiling of the live PHP environment is done using an open source tool called XHProf.

Facebook はシステム(ここで Pingdom が取り上げている)を慎重にモニターする。 そして、きわめて興味深いことに、実運用環境における全ての PHP 機能にいたるまで、そのパフォーマンスルをモニターする。PHP 運用環境のためのプロファイリングは、XHProf と呼ばれるオープンソース・ツールを用いて実施される。

Gradual feature disabling for added performance

If Facebook runs into performance issues, there are a large number of levers that let them gradually disable less important features to boost performance of Facebook’s core features.

Facebook はパフォーマンスの問題に遭遇すると、そのコア機能の性能を引き上げるために、それほど重要ではない機能を段階的に停止する、たくさんのレバーを持っている。

The things we didn’t mention

We didn’t go much into the hardware side in this article, but of course that is also an important aspect when it comes to scalability. For example, like many other big sites, Facebook uses a CDN to help serve static content. And then of course there is the huge data center Facebook is building in Oregon to help it scale out with even more servers.

この記事では、あまりハードウェアについて取り上げていない。 しかし、もちろん、スケーラビリティの話になると、それも重要な局面となる。 たとえば、他の大規模サイトのように、スタティック・コンテントのサービスを促進するために、Facebook も CDN を活用している。 それに加えて、Facebook は Oregon に巨大データセンターを構築しており、さらに多くのサーバーを用いたスケールアウトを促進していく。

And aside from what we have already mentioned, there is of course a ton of other software involved. However, we hope we were able to highlight some of the more interesting choices Facebook has made.

また、ここで取り上げてきた内容とは別に、もちろん Facebook は膨大なソフトウェアを活用している。 とは言え、Facebook の興味深い選択に、スポットライトを当てることができたと信じている。

Facebook’s love affair with open source

We can’t complete this article without mentioning how much Facebook likes open source. Or perhaps we should say, “loves”.

この記事では、どれほど Facebook がオープンソースを好むのかという点を、充分に説明することができなかった。 それについては、『 Love 』と言うべきかもしれない。

Not only is Facebook using (and contributing to) open source software such as Linux, Memcached, MySQL, Hadoop, and many others, it has also made much of its internally developed software available as open source.

Facebook は、Linux や、Memcached、MySQL、Hadoop などを単に利用するだけではなく、オープンソースとして利用できるソフトウェアを、その内部で開発している。

Examples of open source projects that originated from inside Facebook include HipHop, Cassandra, Thrift and Scribe. Facebook has also open-sourced Tornado, a high-performance web server framework developed by the team behind FriendFeed (which Facebook bought in August 2009).

Facebook がオリジナルを開発したオープンソース・プロジェクトには、たとえば HipHop、Cassandra、Thrift などが含まれる。 さらに Facebook は、オープンソース化された Tornado を有している。 それは、FriendFeed(Facebook が2009年8月に買収)のチームにより開発された、ハイ・パフォーマンス Web サーバーのフレームワークである。

(A list of open source software that Facebook is involved with can be found on Facebook’s Open Source page.)

(Facebook が関連するオープンソース・ソフトウェアのリストは、Facebook’s Open Source page で参照できる)

More scaling challenges to come

Facebook has been growing at an incredible pace. Its user base is increasing almost exponentially and is now close to half a billion active users, and who knows what it will be by the end of the year. The site seems to be growing with about 100 million users every six months or so.

Facebook は、信じ難いペースで成長している。 そのユーザー数は急激に増加していて、現時点では約 5億人のアクティブ・ユーザーがいることから、この年末の状況も予想できるだろう。 このサイトでは、6カ月ごとに、約 1億人のユーザーが増えているように思われる。

Facebook even has a dedicated “growth team” that constantly tries to figure out how to make people use and interact with the site even more.

さらに Facebook は、彼らのサイトの用法と運用について、継続的な理解を促進するための、Growth Team を盛り立てている。

This rapid growth means that Facebook will keep running into various performance bottlenecks as it’s challenged by more and more page views, searches, uploaded images, status messages, and all the other ways that Facebook users interact with the site and each other.

この素早い成長が意味するのは、さらなるページビューや、検索、アップロード・イメージ、ステータス・メッセージ、そしてFacebook とユーザーの相互作用がもたらす挑戦につれて、様々なパフォーマンス・ボトルネックに、Facebook が遭遇し続けるという状況である。

But this is just a fact of life for a service like Facebook. Facebook’s engineers will keep iterating and coming up with new ways to scale (it’s not just about adding more servers). For example, Facebook’s photo storage system has already been completely rewritten several times as the site has grown.

しかし、Facebook のようなサービスにとって、それこそが生き抜いていくための現実である。 Facebook のエンジニアたちは反復を実施して、スケールを維持するための新しい方法を考え続けるだろう(単にサーバーを追加するだけではない)。 たとえば、Facebook の写真ストレージ・システムは、その成長につれて、スクラッチから何度も書き直されている。

So, we’ll see what the engineers at Facebook come up with next. We bet it’s something interesting. After all, they are scaling a mountain that most of us can only dream of; a site with more users than most countries. When you do that, you better get creative.

したがって、Facebook のエンジニアたちが、次に生み出すものに注目することになるだろう。 そこには、面白いことがあると確言する。 結局のところ、Facebook がスケールする山のようなものは、人々が夢でしか見ることのできないものであり、また、大半の国々をつなぐというより、より多くの人々をつなぐというものである。 そして、それを望む人に、さらに創造的な方式を提供する。

Data sources: Various presentations by Facebook engineers, as well as the always informative Facebook engineering blog.

ーーーーー

<関連>
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _1
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _2
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _3

ーーーーー
わずか四半期の間に、サーバー数が倍増した Facebook の事情
Facebook の HDFS クラスターは 21 PB !!!
Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2

Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _2

Posted in Facebook by Agile Cat on July 3, 2010

Exploring the software behind Facebook, the world’s largest site _2
Posted in
Main on June 18th, 2010
by Pingdom

http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/

imageいよいよ本題です。 Facebook のスケールを支えるソフトウェアたちが登場してきます。知っているものと、知らないものが混在していますが、Facebook オリジナルのオープンソースが多いことに驚きました。ーーー A.C.

ーーーーー

 Memcached

Memcached

Memcached is by now one of the most famous pieces of software on the internet. It’s a distributed memory caching system which Facebook (and a ton of other sites) use as a caching layer between the web servers and MySQL servers (since database access is relatively slow). Through the years, Facebook has made a ton of optimizations to Memcached and the surrounding software (like optimizing the network stack).

Facebook runs thousands of Memcached servers with tens of terabytes of cached data at any one point in time. It is likely the world’s largest Memcached installation.

Memcached は、いまではインターネット上の最も有名なソフトウェアの 1つになっている。 分散メモリ・キャッシュ・システムであり、Web サーバーと MySQL サーバーをつなぐキャッシング・レイヤとして(データベース・アクセスが遅いため)、Facebook は使用している(他の多数のサイトも)。 この何年かの間に、 Facebook はMemcached と周囲ソフトウェアに、大量の最適化を施している(ネットワーク・スタックの最適化など)。

Facebook は、いずれかのポイントに一度にキャッシュされる数 10TB のデータを、数 1000 の Memcached サーバーを走らせて処理している。おそらく、それは世界最大の Memcached 設備となる。

HipHop for PHP

HipHop

PHP, being a scripting language, is relatively slow when compared to code that runs natively on a server. HipHop converts PHP into C++ code which can then be compiled for better performance. This has allowed Facebook to get much more out of its web servers since Facebook relies heavily on PHP to serve content.

A small team of engineers (initially just three of them) at Facebook spent 18 months developing HipHop, and it is now live in production.

スクリプト言語である PHP は、サーバー上のネイティブ・コードとの比較において、その実行速度が遅い。 HipHop により PHP は C++ へとコンバートされ、さらにコンパイルされることで、パフォーマンスが向上する。 つまり、Facebook はコンテント・サービスのために PHP に大きく依存しているが、Web サーバーの概念にとらわれず、より多くの成果を得ることになる。

Facebook のエンジニアで構成される小さなチーム(最初は3人)が、18ヶ月の開発期間を HipHop に費やし、いまではプロダクション環境での運用に至っている。

Haystack

Haystack is Facebook’s high-performance photo storage/retrieval system (strictly speaking, Haystack is an object store, so it doesn’t necessarily have to store photos). It has a ton of work to do; there are more than 20 billion uploaded photos on Facebook, and each one is saved in four different resolutions, resulting in more than 80 billion photos.

Haystack は、Facebook の写真を保存/検索するための、ハイ・パフォーマンスなシステムである(厳密には、 Haystack はオブジェクト・ストアであるため、必ずしも写真に限定されない)。 それは、膨大な処理をこなしている。 つまり、Facebook 上には 200億枚以上の写真がアップロードされているが、それぞれが 4つの解像度をもつため、結果として 800億枚以上の写真となる。

And it’s not just about being able to handle billions of photos, performance is critical. As we mentioned previously, Facebook serves around 1.2 million photos per second, a number which doesn’t include images served by Facebook’s CDN. That’s a staggering number.

そして、何 10億枚という写真を、単に処理できることが重要なのではなく、パフォーマンスが重要なのだ。 前述のとおり、Facebook は 約 120万枚/秒の写真を処理しているが、そのには Facebook CDN によりサポートされるイメージは含まれない。それは、ショッキングな数字である。

BigPipe

BigPipe is a dynamic web page serving system that Facebook has developed. Facebook uses it to serve each web page in sections (called “pagelets”) for optimal performance.

For example, the chat window is retrieved separately, the news feed is retrieved separately, and so on. These pagelets can be retrieved in parallel, which is where the performance gain comes in, and it also gives users a site that works even if some part of it would be deactivated or broken.

BigPipe は、Facebook が開発した、Web ページを動的に提供するためのシステムである。 Facebook は 、最適なパフォーマンスを得るためにBigPipe を用いる。 そして、pagelets と呼ばれるセクションで、それぞれの Web ページをサポートする。

たとえば、チャット・ウインドウは別に検索され、また、ニュース・フォードも別に検索される。 これらの pagelets は、並列に検索することが可能であり、パフォーマンスが向上する。 そして、いくつかのパートが正常に機能しない場合や、破壊されている場合であっても、ユーザーには正常なサイトが提供される。

Cassandra

Cassandra

Cassandra is a distributed storage system with no single point of failure. It’s one of the poster children for the NoSQL movement and has been made open source (it’s even become an Apache project). Facebook uses it for its Inbox search.

Other than Facebook, a number of other services use it, for example Digg. We’re even considering some uses for it here at Pingdom.

Cassandra は、シングル・ポイント・フェイルを排除した分配ストレージ・システムである。 Cassandra は、NoSQL ムーブメントを代表する 1つであり、オープンソースとして提供されている(Apache プロジェクトでもある)。 Facebook は、それを Inbox サーチのために利用している。

Facebook 以外にに、たとえば Digg などの、数多くのサービスがも Cassandra は利用されている。 実は、この Pingdom でも利用を検討している。

Scribe

Scribe is a flexible logging system that Facebook uses for a multitude of purposes internally. It’s been built to be able to handle logging at the scale of Facebook, and automatically handles new logging categories as they show up (Facebook has hundreds).

Scribe は柔軟なログ・システムであり、Facebook の内部において、多様な目的のために使用されている。 Scribe は、Facebook スケールでのログ処理ために構築され、また、新しいカテゴリ(Facebook には何100とある)が現われるときに、新しいログ・カテゴリを自動的に処理する。

Hadoop and Hive

Hadoop Logo

Hadoop is an open source map-reduce implementation that makes it possible to perform calculations on massive amounts of data. Facebook uses this for data analysis (and as we all know, Facebook has massive amounts of data). Hive originated from within Facebook, and makes it possible to use SQL queries against Hadoop, making it easier for non-programmers to use.

Both Hadoop and Hive are open source (Apache projects) and are used by a number of big services, for example Yahoo and Twitter.

Hadoop は、オープンソースの MapReduce 実装であり、大量のデータの計算を実現する。 Facebook では、Hadoop をデータ分析(Facebook が大量のデータを有していることは周知の事実)に利用している。もともと、Hive は Facebook で開発されたものであり、Hadoop に対する SQL のクエリーの使用を可能にすることで、ノン・プログラマによる容易な利用を実現する。

Hadoop と Hive は、どちらもオープンソース(Apache プロジェクト)であり、たとえば Yahoo や Twitter などの、数多くの大規模サービスにおいて利用されている。

Thrift

Facebook uses several different languages for its different services. PHP is used for the front-end, Erlang is used for Chat, Java and C++ are also used in several places (and perhaps other languages as well). Thrift is an internally developed cross-language framework that ties all of these different languages together, making it possible for them to talk to each other. This has made it much easier for Facebook to keep up its cross-language development.

Facebook has made Thrift open source and support for even more languages has been added.

Facebook は、それぞれのサービスのために、何種類かの言語を使用している。 PHP はフロント・エンドのために使われ、また、Erlang は Chat に使われ、Java と C++ も各所で使われている(おそらく、それ以外も言語も)。 Thrift は、それら全ての言語を接続する、インターナルなクロス言語フレームワークであり、その結果として、各言語が相互に交信できるようになる。 それにより、Facebook におけるクロス言語での開発が、きわめて容易に維持されることになった。

Facebook は Thrift をオープンソースにしており、また、そこに加えられた言語までもサポートしている。

Varnish

Varnish

Varnish is an HTTP accelerator which can act as a load balancer and also cache content which can then be served lightning-fast.

Facebook uses Varnish to serve photos and profile pictures, handling billions of requests every day. Like almost everything Facebook uses, Varnish is open source.

Varnish は、ロード・バランサとして振舞う HTTP アクセラレータであり、また、瞬時にコンテントを提供するためのキャッシュでもある

Facebook は、通常の写真と、プロファイル用の写真を提供するために Varnish を使用し、数10億のリクエストを、毎日処理している。 Facebook で用いられる、ほとんど全てのソフトウェアと同様に、Varnish もオープンソースである。

ーーーーー

すばらしい好循環が実現されている ・・・ という感じです。一言で、『 圧巻 』 ですなぁ。 ーーー A.C.

ーーーーー

<関連>
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _1
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _2
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか _3
ーーーーー
わずか四半期の間に、サーバー数が倍増した Facebook の事情
Facebook の HDFS クラスターは 21 PB !!!
Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
Facebook で Office ドキュメントを共有する Docs.com を触ってみた
Microsoft TownHall : Windows Azure と Facebook の連携が始まった!
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?

%d bloggers like this: