HDFS のスケーラビリティを考察する _1

Scalability of the Hadoop Distributed File System _1 

Yahoo! Developer Network Blog
May 5, 2010
http://developer.yahoo.net/blogs/hadoop/2010/05/scalability_of_the_hadoop_dist.html?

In his fictional story "The Library of Babel", Jorge Luis Borges describes a vast storage universe composed of all possible manuscripts uniformly formatted as 410-page books. Most are random meaningless sequences of symbols. But the rest excitingly forms a complete and an indestructible knowledge system, which stores any text written in the past or to be written in the future, thus providing solutions to all problems in the world. Just find the right book.

ホルヘ・ルイス・ボルヘス (Jorge Luis Borges) の作である「バベルの図書館」では、410ページの本として共通のフォーマットを持つ書籍で構成された、巨大なストレージの世界を表現している。そして、その 大部分が、無意味なシンボルの羅列となる。 しかし、残りの部分は完全で破壊されることのない知識システムを形成し、過去に記述され将来に記述されるあらゆるテキストをストアする。 したがって、世界におけるすべての問題に対するソリューションを提供する。 まさに、必要な本を探し出せる。

The same characteristic fascinates us in modern storage growth: The aggregation of information directly leads to proportional growth of new knowledge discovered out of it. A skeptic may doubt that further reward in knowledge mining will not justify the effort in information aggregation. What if by building sophisticated storage systems we are chasing the 19th century’s horse manure problem, when at the dawn of the automobile era the scientific world was preoccupied with the growth of the horse population that threatened to bury the streets of London nine feet deep in manure?

近代的なストレージが成長してきたいま、それと同じ特質が私たちを魅惑する。 つまり、情報のアグリゲーションから発見される、均衡のとれた新しい知識のダイレクトな成長が導かれることになる。 懐疑的な人々は、ナレッジ･マイニングにおける更なる報いは、正当な情報アグリゲーションを破壊すると言うだろう。しかし、洗練されたストレージ･システムを構築することで、19世紀における馬糞の問題を取り除けるなら、どうなるかと考えるべきだろう。 つまり、自動車の時代が始まろうとしているのに、London の街が 9フィートの深さまで馬糞で埋まると脅す馬喰たちに、科学の世界は屈してはならないのだ。

The historical judgment will turn one way or another. In the meantime, we want to know how far we can go with existing systems even if only out of pure curiosity. In my USENIX ;login: article “HDFS Scalability: the Limits to Growth,” I studied scalability and performance limitations imposed on a distributed file system by the single-node namespace server architecture. The study is based on experience with largest deployments of the Hadoop Distributed File System (HDFS) currently in production at Yahoo!.

歴史における審判は、一様なものではなく、揺れ動く。 そうこうしている間に、たとえ純粋な好奇心を失うにしても、既存システムを用いて、どこまで行けるかを知りたがる。 私は USENIX ; login: article “HDFS Scalability: the Limits to Growth” において、シングル･ノードの名前空間サーバー･アーキテクチャにより、何らかの分散ファイル･システムを割り当てられた際の、スケーラビリティとパフォーマンス限界を調査した。 この調査は、Yahoo! で運用中の Hadoop Distributed File System（HDFS）における、最も大規模なディプロイメント･エクスペリエンスに基づいている。

The first part of the study focuses on how the single name-server architecture limits the number of namespace objects (files and blocks) and how this translates to the limitation of the physical storage capacity growth.

この研究における最初のパートでは、単一のネームサーバー・アーキテクチャが名前空間オブジェクト（ファイルとブロック）の数を制限する様子と、それにより、物理ストレージの容量的な成長が妨げられる点にフォーカスする。

The second part explores the limits for linear performance growth of HDFS clusters bound by natural performance restrictions of a single namespace server. As the cluster grows, the linear increase in the demand for processing resources puts a higher workload on the single namespace server. When the workload exceeds a certain threshold, it saturates the server, turning it into a single-node bottleneck for linear scaling of the entire cluster.

2番目のパートでは、単一の名前空間サーバーにおける自然なパフォーマンス制約により、HDFS クラスタのリニアなパフォーマンス向上が妨げられる限界を探究する。 クラスタが成長するにつれて、リソース処理の要求に関するリニアな増加が、単一の名前空間サーバー上のワークロードを押し上げる。 ワークロードが一定の閾値を超えるとき、そのサーバーは飽和することになり、クラスタ全体のリニアなスケーリングに対する、シングル・ノード・ボトルネックへと変様する。

In 2006, the Hadoop group at Yahoo! formulated long-term target requirements for HDFS and outlined a list of projects intended to bring the requirements to life. Table 1 summarizes the targets and compares them with the current achievements:

Yahoo! の Hadoop グループは 2006年に、 HDFS に対する長期的な目標の要件を規定し、それらの要件を活性化する意図を持つ、いくつかのプロジェクトのリストをまとめた。 それらのターゲットを Table 1 に要約し、現時点の到達点と比較する：

The bottom line is that we achieved the target in Petabytes and got close to the target in the number of files. But this is done with a smaller number of nodes and the need to support a workload close to 100,000 clients has not yet materialized. The question now is whether the goals are feasible with the current system architecture.

結論として、私たちは Petabytes オーダーの目標を達成し、ファイル数においても目標に近づいたといえる。 しかし、これらの結果は少数のノードを用いて達成されており、100,000 クライアントに近いワークロードを、サポートしていくという必要性は、まだ実現していない。 そして、私たちのゴールが、現在のシステム・アーキテクチャを用いて実現できるのかという疑問が残っている。

Namespace Limitations

HDFS is based on an architecture where the namespace is decoupled from the data. The namespace forms the file system metadata, which is maintained by a dedicated server called the name-node. The data itself resides on other servers called data-nodes.

HDFS は、名前空間がデータから分離されるアーキテクチャに基づいている。 この名前空間は、Name-Node という専用サーバーにより維持される、ファイル･システムのメタデータを形成する。 そして、データ自身は、Data-Node という他のサーバー上に配置される。

The namespace consists of files and directories. Files are divided into large (128 MB) blocks. To provide data reliability, HDFS uses block replication. Each block by default is replicated to three data-nodes. Once the block is created its replication is maintained by the system automatically. The block copies are called replicas.

この名前空間は、ファイルとディレクトリで構成される。 そして、それらのファイルは、大きなブロック（128MB）に分けられる。 データの信頼性を確保するために、 HDFS はブロック･リプリケーションを使用する。 それぞれのディフォルト･ブロックは、3 つのデータノードにリプリケートされる。 それらのブロックが作成された後に、システムにより自動的に、リプリケーションの管理が行われる。 このブロックされたコピーのことを、レプリカと呼ぶ。

The name-node keeps the entire namespace in RAM. This architecture has a natural limiting factor: the memory size; that is, the number of namespace objects (files and blocks) the single namespace server can handle.

そして、Name-Node により、すべての名前空間が RAM 上に保持される。 当然のこととして、このアーキテクチャは制約の要因を伴う。 つまり、メモリのサイズであり、単一の名前空間サーバーが取り扱う、名前空間オブジェクト（ファイルとブロック）の数が制限されることになる。

Estimates show that the name-node uses less than 200 bytes to store a single metadata object (a file inode or a block). According to statistics on Y! clusters, a file on average consists of 1.5 blocks. Which means that it takes 600 bytes (1 file object + 2 block objects) to store an average file in name-node’s RAM

シングル･メタデータ･オブジェクト（a file inode or a block）をストアするために、200 Bytes 以下を使用する Name-Node を見積もってみよう。 Yahoo! クラスタにおける統計値では、ファイルの平均サイズは 1.5 ブロックに相当する。 つまり、Name-Node の RAM 内に、平均的なサイズのファイルをストアするために、600 Bytes（1 file object + 2 block objects）が必要となる。

To store 100 million files (referencing 200 million blocks), a name-node should have at least 60 GB of RAM.

1億のファイルをストアするためには、Name-Node は最低でも 60GB の RAM を必要とする。

＜続く＞

おそらく、3回くらいに分けてのポストになると思います。 ーーー A.C.

＜関連＞
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
ーーーーー
Hadoop DFS _ Introduction
NoSQL Ecosystem とは？ _1

 

ワールドカップとインターネット･アクセス

FIFA.com のトラフィックを coｍScore が調査

今夜はオランダ戦ということで、日本中の人々がテレビにかじり付くのでしょうが、お馴染みの comScore が FIFA.com へのアクセスについて調べてくれましたので、それをご紹介します。

まず、その１ は、インターネット全体のトラフィックと、FIFA.com のトラフィックの比較です。 調査期間は 5月1日～31日の 1ヶ月間であり、その間に、インターネット全体の 0.1% から 0.2% へと、FIFA のトラフィックは増加しています。 6月 1日以降、とりわけ開幕以降の比率が、どのように増加しているのか、その辺りも知りたいですね。

その 2 は、世界のどの地域から、どれだけのインターネット･アクセスがあるのかというデータです。 これも、全世界と FIFA.com を対比することで、とても面白い結果を導き出しています。 FIFA.com 側のグラフを見ていきますが、まず、北米が半減して、アフリカが倍増、南米にいたっては4倍増、ヨーロッパははやや減で、アジアは約 1/4 に縮減という結果です。

新聞や TV を見ていると、日本の盛り上がりも大したものだと思ってしまいますが、アジア全体のデータを見ると、世界で一番 盛り上げに欠けている地域となってしまいます。 アジアが冷めていて、南米が熱狂しているのかと、そのような結果に見えますが、実は FIFA.com の言語対応にも問題があるのです。

つまり、よくよく見ると、FIFA.com では 日本語も、ハングルも、中国語もサポートされていないのです。 そんな状況なのに、新聞も TV も異を唱えないというのは、ちょっと変ですよね。 穿った見方をすれば、サッカー･ファンがインターネットに流れていかないこの状況を、喜んでいるかのように思えます。 たとえば、なんらかの国際会議の会場で、日本語の案内だけが抜けていても、何も文句を言わないのでしょうかね？ 知ってて知らんぷりなら、ジャーナリズムとしての質を疑われ、知らなかったのなら能力を疑われるという感じです ･･･ orz。

まぁ、いまさらマスコミを突っついても仕方ないので、何はともあれ今夜はオランダ戦を楽しみましょう。 それと、comScore では引き続き、ワールドカップとインターネット･アクセスというテーマで調査していくようですので、それも楽しみにしていきましょう。ーーー A.C.

 

Hadoop で スマートグリッドを、図とデータで見る！

GPA の OpenPDC とは、いったい何ものなのか？

先月（5月）にテネシーへ出張してきましたが、そのメインの目的は、Hadoop でスマート･グリッドに取り組んでいる GPA 社とのミーティングでした。日本へ帰ってきて、少しずつ情報を整理していますが、その概要がまとまりましたので、以下に ご紹介します。 ーーー A.C.

まず、この領域における Google の動向ですが ･･･   Ggoogle の子会社として設立され、電力の卸売を行う Google Energy については、さまざまな憶測があります。 その中で一番に挙げられるのは、再生可能エネルギーへのアクセスを実現することで、Google の大規模データセンターを支援していくという可能性でしょう。

つまり、Google Energy の電力売買権を用いれば、たとえば風力発電会社から一度買い取ってから、Google に転売することができます。 そして、もし、Google が独自の更新可能エネルギーを保有するなら、その風力発電会社からの電力は、契約が切れたあとでもオープンなマーケットに提供されることになります。

それに加えて、2000社以上にのぼると言われる、大手や中小で構成されるアメリカの電力卸売業界を、その資本力を用いて再編していくことも予測されます。その意味で、Google は IT の世界から、スマートグリッドの世界に向けてアプローチを開始していて、その尖兵となるのが Google Energy であると捉えることができます。

そして OpenPDC ですが ･･･  その一方で、 NERC（North American Electric Reliability Corporation）、TVA（Tennessee Valley Authority）、GPA（Grid Protection Alliance）が共同で推進しているスマート･グリッド･プロジェクトは、PMU（phasor measurement unit） データを収集し、保存し、処理するための、OpenPDCと呼ばれるものです。 このプロジェクトは、アメリカの電力業界の中から生じているものであり、Google とは反対に、電力の世界からスマート･グリッド（IT）の世界にアプローチするものです。

以前にもご紹介しましたが、OpenPCD は。実時間情報を持った一連のストリーミング･データを処理するための、アプリケーション･セットです。複数の入力ソースから得られる GPS タイム･スタンプ付きの測定データをソートし、ユーザー定義されたアクションに対して提供し、カスタムな出力ディスティネーションへ向けて分散させていきます。

そして、それらのデータが測定されるとき、GPS から取得されたタイムスタンプにしたがって、それらの測定されたデータは OpenPDC へとストリーミングされていきます。 この時に用いられるデバイスは、Phasor Measurement Unit（PMU）と呼ばれるものであり、1秒間に 30回のレートでデータのサンプリングを行います。一般には、point／ signal／ events／ time-series value や measurement、そして、 temperature／ voltage／ vibration／ location／ phasor といったものが含まれるとのことです。

そこでは、高速でのデータ転送を実現するために、プロセス･コンプレックス･イベントへの対処と、動的な変化への対応が要求されれます。 つまり、PMUに添付されたタイム･スタンプに応じてイベントを処理した後に、データをタイム･スライスすることで分析が行われていきます。

アメリカの送電網は、複数の電力会社により構成されるため、円滑な電力供給を実現するためには、それらの協調が必要になります。そして、そこで取り扱われるデータは膨大なものとなるため、PMU データ･リポジトリのためのアーキテクチャとして、Hadoop が採用されています。

このプロジェクトにおける Hadoop の採用理由は、高価なマシンが不要であること、そして、分散ファイルシステムであるHDFS が使える点にあります。 つまり、送電網から取得される膨大なデータを、MapReduce を用いて分散処理するために Hadoop が用いられています。

このサンプリング･データのサイズが 128 Bytes だとすると････

3.84k Bytes ／sec 
230K Bytes ／minute 
14M Bytes ／hour 
330M Bytes ／day 
1G Bytes ／month

そして、送電網に配置される PMU が 1000 ヶ所だとすると･･･

1T Bytes／month     365T Bytes／year

さらに、10000 ヶ所だとすると･･･

10T Bytes／month   3.65P Bytes／year

･･･ となります。

ーーーーー

これだけのデータを処理するには Hadoop が必須だということが、お解りいただけると思います。スマート･グリッドと Hadoop の組み合わせというと、とてもリッチなトレンド･マッシュアップのように聞こえますが、そこには、それなりの必然性があるのだと思います。ーーー A.C.

ーーーーー

＜関連＞
Google は電力事業にも参入するのか？
スマートグリッドを Hadoop で （US 出張編_2）
スマートグリッドを Hadoop と OpenPDC で（US出張編_3）

アメリカのスマートフォン･シェアは、iPhone 4 で変化するのか？

Americans Get “Smart”: iPhone, Android and the Accelerating Adoption of Smartphones
By Stephanie Lyn Flosi – June 15, 2010
http://blog.comscore.com/2010/06/americans_smart_iphone.html

Last week was a big week in the ever-evolving world of mobile as Apple introduced the iPhone 4, its highly anticipated next generation of the popular mobile device. In the fiercely competitive and fast-growing smartphone market, the successful launch of a new product represents the opportunity to capture market share. Apple, like other manufacturers and platforms within the smartphone market, must rely heavily on brand awareness and positive word-of-mouth to sustain upward momentum in its quest for market share.

ポピュラーな次世代モバイル･デバイスを予測させる iPhone 4 を、Apple が 紹介した先週は、進化し続けるモバイルの世界にとって Big Week だった。 厳しい競合と素早い成長をもたらすスマートフォン･マーケットにおいて、新製品の投入を成功させることは、市場占有率を獲得する機会につながる。 Apple にとっても、他のスマートフォン･メーカーやプラットフォームと同様に、市場占有率の追求における上昇傾向を維持するためには、ブランドの強みと口コミに大きく依存する必要がある。

Just how popular have smartphones become? According to data from comScore MobiLens, smartphone penetration in the U.S. has grown from 11 percent of mobile subscribers in April 2009 to more than 20 percent in April 2010 — nearly double in just one year. The total number of smartphone subscribers now totals more than 48 million.

スマートフォンの人気は、どれくらい上昇しているのだろうか？ comScore MobiLens のデータによると、アメリカにおけるスマートフォンの普及率は、2009年 4月の 11% から 2010年 4月の 20% へと、約2倍のペースで増え続けている。 そして、スマートフォンの利用者数は、4800万人を超えるところまできている。

･･･ 図はクリックで拡大します･･･

The biggest player in the smartphone market remains RIM with its popular Blackberry devices, currently owning more than 40 percent share of smartphone subscribers. Apple holds a firm grip on the #2 position with 25 percent share of mobile subscribers, up from 20 percent in April 2009. Despite gaining share over the long term, however, Apple’s market share has stabilized at 25 percent in recent months – perhaps the result of consumers waiting in anticipation of the new model. With the iPhone 4 announcement, we should expect to see Apple’s market share increase as it did with the introduction of previous models.

Blackberry という人気の機種を有する RIM は、現時点において 40% を超えるモバイル占有率を維持している。 2009年 4月の時点で20% の占有率を持っていた Apple は、25% へと数値を伸ばして二番手の位置にある。 しかし、その長期間にわたって維持されてきた上昇傾向は、この数ヶ月の間、25% に留まっている。 従来のモデルが投入されたときのように、iPhone 4 の発表により、Apple の市場占有率が増加すると予期するべきだ。

While iPhone was the talk of the week, however, Google’s Android platform has been the pace-setter in the smartphone market over the past several months. In April, Android captured 12 percent market share, up from just 3 percent 6 months ago. Android continues to propel itself closer to the #3 spot (currently held by Microsoft at 15 percent), and if it continues to grow at this rate it could seize that position within the next few months.

今週に iPhone がアナウンスされた一方で、この数カ月間では Google の Android プラットフォームが、スマートフォン･マーケットを引っ張ってきた。 Android の市場占有率は、6ヶ月前には 3% に過ぎなかったが、4月の時点では 12% まで上昇している。 Android は三番手のポジションに近づきつつあり、その成長率を維持できるなら、これからの数ヶ月の間に Microsoft（現時点で 15% の市場占有率）を逆転するだろう。

It will be particularly interesting to watch how the next few months play out in the smartphone market with Android continuing its fast ascent while the iPhone 4 makes a big push. Stay tuned for more on the smartphone market as it develops…

Android が急成長を維持する流れに iPhone 4 が参入指定来る、これからの数ヶ月間におけるスマートフォン･マーケットの展開は、きわめて興味深いものになるだろう。 その展開につれて、スマートフォン･マーケットの最新情報をお届けする・・・

ーーーーー

相変わらず、我が Symbian は人気がないですね。。。 アメリカでは RIM。 ヨーロッパでは Nokia という住み分けなんでしょうかね？ ーーー A.C.

ーーーーー

＜関連＞
UMPC Portal というサイト、ご存知でした？
ありがとう My Nokia Hack Friends
今朝の iPhone 4G 報道 ー アメリカのニュースより
Apple はクラウド･プロバイダーになりたくないのか？
App Store を凌駕する、Touch Screen Web サイトの成長

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

The Four Meta Secrets of Scaling at Facebook
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.

ーーーーー

＜関連＞
Facebook のスケール感覚に驚愕！ _1
ーーーーー
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか？
ロシアのハッカー Kirllos が、150万人分の Facebook アカウントを売りに出すという
Facebook と Greenpeace : Oregon のデータセンターをめぐって対峙
Office 2010 は、Docs.com で Facebook とコラボ？
ーーーーー
10億人のユーザーを目指す、Twitter の 6つの戦略とは？ _1
10億人のユーザーを目指す、Twitter の 6つの戦略とは？ _2
10億人のユーザーを目指す、Twitter の 6つの戦略とは？ _3
10億人のユーザーを目指す、Twitter の 6つの戦略とは？ _4