Facebook のスケール感覚に驚愕！ _2

June 16, 2010

Facebook のスケール感覚に驚愕！ _2

Filed under: Cloud Businesses,Facebook,NoSQL — Agile Cat @ 12:14 pm
Tags: Aditya Agarwal, Facebook, MySQL, NoSQL, Scale Out

The Four Meta Secrets of Scaling at Facebook
Date Thursday, June 10, 2010 at 10:42PM
http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+HighScalability+%28High+Scalability%29&utm_content=Google+Feedfetcher

The Four Scaling Meta Secrets

1. Scaling takes Iteration. Solutions of often work in the beginning, but you’ll have to modify them as you go on. What works in year one may not work later. PHP, for example, is simple to use at first, but is not a good choice when you have 10s of thousands of web servers.

1. Scaling takes Iteration. 初期において機能するソリューションであても、先へ進むにつれて修正が必要になる。最初の 1年間は機能しても、その後には機能しなくなるかもしれない。たとえば、 PHP を使い始めることは簡単でも、1 万台ものWeb サーバーを使用するのでれば、適した選択とはいえない。

Another example is photos. They currently serve 1.2 million photos a second. The first generation was build it the easy way. Don’t worry about scaling that much. Focus on getting the functionality right. Uploader stored the file in NFS and the meta-data was stored in MySQL. It worked for the first 3 months and caused a lot of sleepless nights. He would still do it the same way today. Time to market was the biggest competitive advantage they had. Having the feature was more important than making sure it was a fully thought out scalable solution.

もう1つの例として写真が挙げられる。現時点において、1秒あたり 120万枚の写真が提供される。第 1世代の Facebook では、そのための機能を安易な方式で構築していた。スケーリングについて、頭を悩まさなくてもよい。その機能が正確に機能することにフォーカスする。アップローダーによりファイルは NFS にストアされ、メタデータは MySQL にストアされる。この方式は、最初の3カ月間は機能したが、その後は眠れぬ夜をもたらした。いまもなお、同じ方式で、同じことを行っているだろう。サービスを提供するまでに費やす時間は、彼らが共同していく上で最大のアドバンテージだった。機能を持つことが、熟考されたスケーラブル･ソリューションを確認するよりも、いっそう重要な事柄だった。

The second phase was optimization. Are there different access patterns that can be optimized for? It turns out smaller images are access more frequently so those became cached. They also started using a CDN. NFS was not designed to store 80 billion small files, so all meta-data wouldn’t fit in memory, so lookups would take 2 or 3 disk IOs which was slow.

2番目のフェーズは、最適化だった。そのために最適化できる、別のアクセス･パターンはあるのだろうか？比較的に小さなイメージが頻繁にアクセスされりことが分かり、それらがキャッシュされるようになった。さらに、CDN も使い始めた。 NFS は、800億もの小さなファイルをストアするようはデザインされていない。したがって、すべてのメタデータは、イン･メモリという考え方にはフィットせず、また、２～３のディスク IO が参照され、結果として遅くなる。

The third generation is an overlay system that creates a file that is a blob stored in the file system. Images are stored in the blob and you know the offset of the photo in the blob. One IO per photo.

第 3世代では、対象となるファイル･システムにストアされる、ブロブであるファイルを作成するための、オーバーレイ･システムが採用された。イメージはブロブにストアされ、そのブロブ内で写真のオフセットが行われる。つまり、1枚の写真ごとの IO という考え方だ。

2. Don’t Over Design. Just use what you need to use as you scale your system out. Figure out where you need to iterate on a solution, optimize something, or completely build a part of the stack yourself. They spent a lot of time trying to optimize PHP, they ended up writing HipHop, a code transformer to convert PHP into C++. It generated a massive amount of memory and CPU savings. You don’t have to do this on day one, but you may have to. Focus on the product first before you write an entire new language.

2. Don’t Over Design. システムをスケールアウトするに、使用する必要のものを、的確に使用すべきだ。ソリューションにおいて反復すべき場所や、何らかの最適化を明確にし、開発者自身が意識すべきパートを完全に構築する。ある開発者のグループは、PHP の最適化に多くの時間を費やし、別のグループは HipHop の記述を受け持ち、コードは PHP から C++ に変換されていく。それにより、大量のメモリと CPU パワーが温存される。このような方式を初日から実施する必要はなくても、いずれは行わなければならないだろう。すべてのパートを新しい言語で記述する前に、つまり最初に行うべきことは、プロダクトに焦点を合わせることだ。

3. Choose the right tool for the job, but realize that your choice comes with overhead. If you really need to use Python then go ahead and do so, we’ll try to help you succeed. Realize with that choice there is overhead, usually across deployment, monitoring, ops, and so on.

3. Choose the right tool for the job, but realize that your choice comes with overhead. ほんとに Python を使う必要があるなら、そうすべきであり、また。成功へと導くように支援する。一般的にみて、ディプロイメント／モニタリング／オペレーションの至るところで、その選択からオーバーヘッドが生じることを自覚すべきだ。

If you choose to use a services architecture you’ll have to build most of the backend yourself and that often takes quite a bit of time. With the LAMP stack you get a lot for free. Once you move away for the LAMP stack how do things like service configuration and monitoring is up to you. As you go deeper into the services approach you have to reinvent the wheel.

なんらかのサービス･アーキテクチャを使う場合には、その大半を自身で構築する必要性が生じ、また、一般的には、そのために大量の時間が消費される。しかし、LAMP スタックを用いることで、多くのものを自由に手にすることができる。ただし、LAMP スタックから離れた途端に、サービスのコンフィグレーションやモニタリングといった処理は、独自のものとなる。そして、そのサービスへのアプローチが深くなるに連れて、分かり切ったことをやり直す必要性が出てくる。

4. Get the culture right. Move Fast – break things. Huge Impact – small teams. Be bold – innovate. Build an environment internally which promotes building the right thing first and then fixing as needed, not worrying about innovating, not worrying about breaking things, thinking big, thinking what is the next thing you need to build after the building the first thing. You can get the code right, you can get the products right, but you need to get the culture right first. If you don’t get the culture right then your company won’t scale.

4. Get the culture right. Move Fast – break things. Huge Impact – small teams. Be bold – innovate.適正な事柄の構築を促す、内部的な環境を作成し、必要に応じてそれらを修正していく。そこでは、革新について気にする必要はなく、詳細を気にすることもない。ただし、規模について考察し、最初の構築の後に検討すべき、次の事柄について考えるべきである。たしかに、コードを得ることも、プロダクトを得ることもできるが、最初に得るべきは文化だ。それを的確に行えないなら、Facebook 自身がスケールできなくなる。それを的確に行えないなら、Facebook 自身がスケールできなくなる。

Move fast. Get to market first. It’s OK if you break things. For example, they now run their entire web tier on HipHop which was developed by three people. Very risky, it brings the site down regularly (out of memory, infinite loops), but there’s a big payoff as they figure out how to make it work. The alternative would be to have 3 month testing process for every change, it slows down everything. This is a particular instance, but the most important thing is the culture, getting people to believe that the most important thing is how quickly they can move.

Move fast. 最初に必要とされるのは、マーケットへのリーチである。そこで用いた手法を分析できるなら、何の問題も生じない。たとえば、3人の人員により開発された HipHop の上で、全体的な Web ティアを実行するとする。一般的に、このような環境はサイトのダウン（メモリ不足や無限のループ）を伴うため、きわめてリスキーであるが、それらの開発者たちに、サービスがダウンする原因を理解させるという、大きな見返りがある。すべての更新に対して、3カ月間のテストを実施するような選択肢は、すべての速度を低下させる。それは特定の事例を示すが、最も重要なことは、それらの開発者たちに、迅速に行動できるのだと信じさせる文化である。

Huge Impact. Small teams can do great things. Search, photos, chat, HipHop were all small teams doing major features. Get the right set of people, empower them, and let them work.

Huge Impact. 小さなチームでも、素晴らしい結果を残せる。サーチ／写真／チャット／HipHop などの全てが、小さなチームによる偉大な成果である。適切なチームを構成し、彼らに権限を与え、上手く機能させる。

Be bold. Don’t be afraid of failure. It’s OK to try things and fail. It’s crazy to say let’s make a new JVM, but the payoff is amazing when it works.

Be bold. 失敗を恐れてはならない。トライして、失敗することに、何の問題もない。新しい JVM を作ろうとすることは、正気の沙汰とは思えないが、それが機能するなら、大きな成果を残すことになる。

There are no product owners at Facebook. Everyone owns the product. Give people ownership of what they work on. If you give ownership to one person then the chances are nobody else will contribute to pushing it to the next level. Ideas come from users and people internally. If you can’t push responsibility down and you isolate the number of people who feel they are real owners, then the only people you’ll be able to motivate are the people who think they are the real owners. So instead why not distribute that entire responsibility?

Facebook には、特定のプロダクト･オーナーがいない。言い換えれば、全員がプロダクト･オーナーである。それらの人々が働きやすくなるような、オーナーシップを与えるべきである。誰かにオーナーシップを与えれば、他の誰もが持ち得ないチャンスが生まれ、プロダクトを次のレベルへ押し上げるコントリビューションが生じる。アイデアは、ユーザーと内部スタッフから提供される。責任の移譲が不可能なために、オーナーとしての感覚を持つ多くの人々を孤立させていまう場合もある。そうなると、あなた自身がモチベーションを持たせられる、明確な自覚を持つ人だけに、オーナーは限定されてしまう。つまり、何ゆえに、すべての責任を分散しないのかという疑問が残る。

Isolate the part of the culture that you value and want to preserve. It doesn’t happen automatically. Facebook organizes hackathons, the point of which is to show new engineers that if they come in at 8AM they can get a new feature up on the site in 12 hours. Move fast isn’t just a platitude, a company has to come up with ways to make people feel it’s a reality.

重要だと認識し、維持したいと望む、文化の部分を分離すべきである。それは、自動的には引き起こされない。 Facebook では、いくつかの Hackathon を運営している。それにより、エンジニアが午前 8時に出社した後に、12時間以内にサイトに反映できる、新しい機能などが説明される。迅速な動きとは、単に陳腐な決まり文句ではない。それは、企業が知恵を絞るべきものであり、開発者に対して現実感を提供するものである。

Related Articles

Should Startups Worry about Their Company Culture? by Audrey Watters.
Facebook Related Articles

ーーーーー

スケーラブルなプロダクトやサービスを提供するためには、こうした目的に適した組織を作り、開発者のモチベーションを高めていくための、マネージメントが必要という事なのでしょうね。先週の Twiter の話といい、今回の Facebook の話といい、スケールに対する感覚が、IT の在り方を変えていく様が、実感できますね。ーーー A.C.

ーーーーー