Agile Cat — in the cloud

Facebook の 超絶 Web パフォーマンス : その秘密を解析する

Posted in .Selected, Big Data, Facebook, Strategy by Agile Cat on August 2, 2013

Facebook Secrets of Web Performance
http://wp.me/pwo1E-6rT

April 23, 2013
http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html

_ highscalability

This is a repost of part 1 of an interview I did for the Boundary blog.

Boundary: What is Facebook’s secret for managing what’s got to be the biggest Big Data project, if you will, on the Web?

Boundary: Web 上で最大の Big Data プロジェクトになるために、Facebook が用いている、マネージメントのための秘密のソースは何なのだろう?

Hoff: From several presentations we’ve learned what Facebook insiders like Aditya Agarwal and Robert Johnson, both former Directors of Engineering, consider their secret sauce:

Hoff: いくつかのプレゼンテーションから、私たちが学んだものがある。 それらは、 Aditya AgarwalRobert Johnson などの Directors of Engineering 経験者が指標とする、いくつかの秘密のソースのことである:

  • Scaling Takes Iteration. Solutions often work in the beginning, but you’ll have to modify them as you go. PHP, for example, is simple to use at first, but is not a good choice when you have tens of thousands of web servers.
  • Scaling Takes Iteration. ソリューションとは、多くの場合において、未成熟な状況にある。 したがって、プロジェクトが進むにつれて、それらを修正する必要性が生じてくる。 たとえば PHP は、容易に導入できるが、何万という Web サーバーを用いるときには、良い選択肢にはならない。
  • Scaling Takes Iteration. You can say that again.
  • Scaling Takes Iteration. スケーリングにはイテレーションが必要だと、もう一度、心に刻み込んでほしい。
  • Don’t Over-Design. Just use what you need 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.
  • Don’t Over-Design.  あなたのシステムをスケール・アウトするために、必要なものだけを用いるべきだ。ソリューションにおける反復および、何かの最適化、そして、スタック内における完璧な構築に、必要とされるものを理解すべきだ。
  • Choose the Right Tool for the Job. Realize that any choice comes with overhead. If you really need to use Python then go ahead and, we’ll try to help you succeed. Yet with that choice there is overhead, usually across deployment, monitoring, ops, and so on.
  • Choose the Right Tool for the Job.  あらゆる選択枝には、オーバーヘッドが含まれると理解しよう。あなたが本当に、Python を用いる必要があり、さらに先へ進みたいと言うなら、それが成功するよう支援するだろう。 しかし、考えて欲しいのは、デプロイメント/モニタリング/オペレーションにまたがるオーバーヘッドが、その選択に含まれていないのかという点である。
  • Get the Culture Right. Build an environment internally which promotes building the right thing first and fixing as needed. Stop worrying about innovating, about breaking things, thinking big and thinking about what is the next thing you need to build after the building the first thing. Isolate the part of the culture that you value and want to preserve. It doesn’t happen automatically.
  • Get the Culture Right. チーム内で構築すべき環境は、最初に適切なものを構築し、必要に応じて、それを修正していける環境となる。大発見や野心的な発想、そして、将来における構築といった、イノベーションについて考え過ぎないようにすべきだ。 大切な事柄と保持すべき事柄で構成されるカルチャーを、明確に分離すべきだ。それは、自動的には行われない。
  • Move Fast. Get to market first. It’s OK if you break things. For example, Facebook runs their entire Web tier on HipHop which was developed by three people. This is a risky strategy. It brings the site down regularly (out of memory, infinite loops), but there’s a big potential payoff as they figure out how to make it work.
  • Move Fast.  製品化を急ぐべきだ。 あなたに発見があるなら、それで OK だ。Facebook を走らせる全体的な Web 階層は、HipHop の上に展開されるが、それ自身は 3人のエンジニアが開発したものである。 それは、リスキーなストラテジーである。それにより、一定の期間でサイトが停止するが(out of memory, infinite loops)、その動作を理解するにつれて、きわめて大きなポテンシャルがもたらされている。
  • Empower Small Teams. Small teams can do great things. Facebook Search, photos, chat and HipHop were all the result of small teams. Get the right set of people, empower them and let them work.
  • Empower Small Teams.  小規模なチームが、偉大な結果を達成する。 Facebook における、Search/Photo/Chat/HipHop の全てが、小さなチームの成果としてもたらされている。適切な人々でチームを構成し、権限を与え、作業を進めさせるべきだ。
  • People Matter Most. It’s people who build and run systems. The best tools for scaling are an engineering and operations teams that can handle anything.
  • People Matter Most.  システムの構築と運用に、人々は携わるべきである。スケーリングのための最適は手段は、1つのエンジニアリング・チームと、複数のイペレーション・チームが、あらゆるものに対処することである。
  • Scale Horizontally. Handling exponentially growing traffic requires spreading load arbitrarily across many machines.
  • Scale Horizontally.  指数関数的に成長するトラフィックの処理では、大量のマシンをまたいで、負荷を適宜分散していくことが要求される。
  • Measure Everything. Production is where the really useful data comes from. Measure both system and application level statistics to know what’s happening.
  • Measure Everything.  プロダクション環境とは、ほんとうに有益なデータで構成される環境である。システムとアプリケーションのレベルを、統計的に把握することで、そこで起っていることが理解される。
  • Gives Teams Control and Responsibility. Responsibility requires control. If a team is responsible for something they must also control it.
  • Gives Teams Control and Responsibility.  責任を持たせるためには、権限を与えなければならない。なんらかのチームが、なんらかの責任を持つなら、それに相応しい権限も持つべきだ。

All these principles work together to make a self-reinforcing virtuous circle. You can’t move fast unless you have small teams who have control and responsibility. You can’t know how your changes are working unless you get those changes into production and measure results. You can’t move code into production unless people feel responsible for moving out working code. You can’t handle the scale unless you figure out how to scale horizontally, move fast and measure everything– that all comes down to good people.

これらすべての原則は、協調しながら、好循環を自ら強化することで達成される。あなたが、権限と責任を有する小さなチームを持たない限り、迅速な行動は取れないだろう。また、プロダクション環境を変更し、そこで測定された結果を取得しない限り、その作用と影響について把握することが出来ないだろう。人々の作業の結果であるコードを、プロダクション環境へ移動するには、それがもたらす変化について、必ず責任を持たなければならない。そして、スケールを取り扱うためには、水平方向への拡散と、迅速な対応、そして、すべての測定について、あなたは理解しなければならない。さらに言えば、すべての事柄はが、適切な人々に受け継がれるという、必要性も生じる。

But the above is not the whole of the story. Not so obvious is the role of opportunity. A pattern we often see is that companies on the leading edge see problems before everyone else, so they solve those problems before everyone else. We see a blast wave of innovation coming from technological hotspots like Google, Netflix, Twitter and Facebook.

しかし、ここまでに述べたものが、すべてのストーリーを語るわけではない。頻繁に見受けられるパターンは、それらの先進的な企業が誰よりも早く、一連の問題に直面することであり、また、それらの問題を、誰よりも早く解決しているという事実である。私たちは、Google/Netflix/Twitter/Facebook といった、テクノロジー・ホットスポットから到来する、イノベーションの爆風を確認すべきだ。

Boundary: What other major websites do you think are doing a great job of scaling with demand, keeping users happy and response times high?

Boundary: その他の要求に応じたスケーリングと、顧客に提示する満足度、そして、高度な応答時間という観点で、どのような主要 Web サイトが上手く機能しているだろうか?

Hoff: We have a great industry. People are constantly willing to share their experiences, share their code and talk about what works. My wife is a tax accountant and they definitely don’t have the same vibe which is a little sad. There are a lot of unbelievably smart and passionate people in this field and total quality only rises the more people talk about how to build great stuff.

Hoff: 私たちは、偉大な産業に属している。人々は、自身の経験を共有し、また、そのコードを共有し、その作業について話し合うよう、常に心がけている。私の妻は税理士であるが、悲しいかな、そのような雰囲気が存在する世界ではない。このフィールドには、数多くの信じられないほどスマートで情熱的な人々が存在し、また、どのようにして素晴らしいものが構築されるのかという議論が促進されることで、全体的な品質が常に向上している。

It’s also pretty obvious to me that having a quality site and willingness to share are linked. There are many companies I could list that fall into this category, but these stand out: Twitter, Etsy, Facebook, Google, Netflix, Amazon and StackExchange. Some other important contributors include: Airbnb, Tumblr, Instagram, TripAdvisor, Heroku, Prismatic, 37signals, Pinterest and Yahoo.

つまり、私から見ると、高品質のサイトと共有への意欲が、明らかに共鳴しているように思える。相当数の企業が、このカテゴリに分類されると思うが、その中でも突出しているのは、Twitter/Etsy/Facebook/Google/Netflix/Amazon/StackExchange である。そして、重要なコントリビュータとしては、 Airbnb/Tumblr/Instagram/TripAdvisor/ Heroku/Prismatic/37signals/Pinterest/Yahoo などが含まれる。

There are literally hundreds of others that could be mentioned, but these companies have continually and enthusiastically contributed to advancing the state of the art in Web performance. I feel bad already, however, because I know I’m missing some.

他にも、文字通り、何百もの企業が挙げられるべきであり、それらの企業は継続的に、Webパフォーマンスの最先端で、情熱的なコントリビューションを継続している。 そのすべてを思い出せずにいることを、申し訳なく思う。

ーーーーー

TAG index久々の、 Todd Hoff さんです。 このインタビューは、Boundary blog での Hoff さんのインタビューを、High Scalability に転載したものとのことです。いろいろなブロガーがいますが、Facebook のスケール感覚に、いち早く注目し、その考え方を伝えてくれたのが、この Hoff さんであり、Agile_Cat も大ファンなのです :)  たくさん並べてしまいましたが、よろしければ、以下の(3年前くらいからの)リンク集も ご覧くださ~い! image

ーーーーー

<関連>

Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook における 1300万/秒 クエリーの秘密
Facebook を 1.8 倍速に、WordPress を 2.7 倍速にする、HipHop とは ?
Facebook は 20分間で、2.7M Photo/10.2M Comment/4.6M Messageを処理!
Google Megastore – 1日で 30億 Write/200億 Read のトランザクションを実現
MySpace を殺したのは Microsoft ソフトウェア・スタックなのか?
Facebook は正攻法で、Billion 単位のメッセージを処理していく
Google の 3つの世代を振り返る – Batch, Warehouse, Instant
Facebook Timeline は、データの非正規化という破壊力で誘う

 

Facebook にストアされた 100 Peta Byte イメージ・データは、写真に換算すると 6,660 億枚になる!

Posted in .Selected, Big Data, Data Center Trends, Facebook, Hadoop, Open Compute by Agile Cat on June 1, 2012

Why 900M isn’t the only number that matters to Facebook
http://wp.me/pwo1E-4gQ

By
Derrick Harris May. 17, 2012
http://gigaom.com/cloud/why-900m-isnt-the-only-number-that-matters-to-facebooks-success/

_ Gigaom

You’ve no doubt heard or read in the past few weeks that Facebook’s hyperinflated valuation heading into its IPO has everything to do with its promise, and very little to do with its actual profits. That much is true.

この数週の間に、IPO へと突き進む Facebook のハイパー・インフレ資産価値について、きっと何かを読んだり聞いたりしてきただろう。しかし、そこに含まれるものは、目論見を実現していくという目標のみであり、また、現実的な利益に関しては、僅かな約束だけがある状況だ。 それは、たしかに、そうなのだ。  

But apart from the fact that it has more than 900 million users, a lot of other important numbers never get mentioned. Here are some numbers we know about Facebook’s infrastructure that also speak to its promise as a company that could generate a lot of money.

しかし、Facebook が 9億人以上のユーザーを有しているという事実を別として、その他の重要な数字について言及される機会は、きわめて少ない。 そして、私たちが Facebook のインフラについて知っている若干の数字は、同社における背景を、つまり、莫大な利益を生み出す構造を物語ってくれるのだ。

  • 100 Peta Bytes のユーザー Photo/Video。 その全てを写真として換算すると、6,660 億枚になる。
  • 30 Petra Bytes 以上の Hadoop クラスタ・データ。巨大な、データ・ウェアハウスとして利用されている。
  • $1.6–$1.8 billionの、2012年に費やされる予定のインフラ予算。 Google の場合は、$2 billion ~ $4 billion を年間で投資しているが、同社における 2011年の売上は、Facebook の 10倍に達する。
  • 2011年における全体的なサーバー市場は、$52.3 billion だと見積もられている。 そして、Facebook の Open Compute Project は、Web スケールを達成するサーバー・ビジネスを再定義することで、このマーケットの向かう先を切り替えようとしている。
  • Facebook は、自社で運用しているカスタム・ビルド・サーバーの台数を明らかにしていない。しかし、2010年の時点で、60,000 台以上だと指摘されている。
  • Prinveville, Oregon のデータセンターが開所したとき、Facebook は30日以内で、数万台のサーバーをプロビジョニングし、オンラインに接続している。

Is Facebook actually worth $100 billion? Who knows. But it’s a company with so much data and with its finger on the pulse of how web infrastructure works. Managed properly, there’s an awful lot there to work with as Facebook tries to figure out new ways to make a dollar.

実際のところ、Facebook に $100 billion の価値があるのだろうか? 誰が、分かるのだろう。 しかし、Facbeook は膨大なデータを保有している企業であり、また、Web インフラストラクチャの発する鼓動を、その指先で聞き取れる企業でもある。 そこには、適切な管理がある。 そして、Facebook が $1 を稼ぎ出すための、新しい方法を身に付けようするように、とても多くの、取り組むべき課題がある。

Related research and analysis from GigaOM Pro:

ーーーーー

TAG index久々の、Facebook ウルトラ・スケール話しです。 Oregon の立ち上げに際して、30 P Bytes の Hadoop クラスタが引越ししたというニュースをポストしましたが、フォト+ビデオで 100 P Bytes になるとは、新しい驚きです。 また、文中にもあるように、Open Compute というハードウェアとデータセンターのためのオープンソースを介して、このインフラ・レイヤを刷新しようとする動きも見逃せません。 この IT のコストを大幅に引き下げ、ノウハウを開示し、エコシステムを構築していこうとする、Facebook の試みには大賛成です! ーーー ac-stamp-232

ーーーーー

<関連>

Facebook Timeline は、データの非正規化という破壊力で誘う
Facebook が $1 Billion を費やす、データセンター連携の規模を探る
Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?
Facebook が推進する Open Compute Project は、離陸できるのだろうか?
オープンなハードウェアは、データセンターに地殻変動を起こせるのか?

 

Facebook は正攻法で、Billion 単位のメッセージを処理していく

Posted in .Selected, Big Data, Facebook by Agile Cat on May 26, 2011

Facebook: An Example Canonical Architecture for Scaling Billions of Messages
Tuesday, May 17, 2011 at 9:18AM
http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html

_highscalability

What should the architecture of your scalable, real-time, highly available service look like? There are as many options as there are developers, but if you are looking for a general template, this architecture as described by Prashant Malik, Facebook’s lead for the Messages back end team, in Scaling the Messages Application Back End, is a very good example to consider. 

スケーラブルでリアルタイム性と可用性を充たすサービスのアーキテクチャは、どのようになるべきなのだろうか? デベロッパーの数だけ選択肢があるが、汎用的なテンプレートを探しているなら、Facebook の Messages バック・エンド・チームのリーダーである Prashant Malik が、「 Scaling the Messages Application Back End 」に書き記したアーキテクチャが、検討すべき適切なサンプルになるだろう。

facebook_logoAlthough Messages is tasked with handling 135+ billion messages a month, from email, IM, SMS,  text messages, and Facebook messages, you may think this is an example of BigArchitecture and doesn’t apply to smaller sites. Not so. It’s a good, well thought out example of a non-cloud architecture exhibiting many qualities any mom would be proud of:

Facebook におけるメッセージは、Email/IM/SMS/Text Message/Facebook Messageなどによる、1350億のメッセージを 1ヶ月間に処理するため、BigArchitecture のためのサンプルであり、小規模なサイトには当てはまらないと思うだろう。 しかし、それは違う。 つまり、ノン・クラウド・アーキテクチャにも適した、数多くの特質を示す、きわめて正統的なサンプルとなっているのだ:

  1. Layered – components are independent and isolated. 
  2. Service/API Driven – each layer is connected via well defined interface that is the sole entry point for accessing that service. This prevents nasty complicated interdependencies. Clients hide behind an application API. Applications use a data access layer.
  3. Distributed – layers are transparently distributed across clusters of machines
  4. Separate Application Logic – Application logic is encapsulated in application servers that provide an API endpoint. Application logic is implemented in terms of other services. The application server tier also hides a write-through cache as this is the only place user data is written or retrieved, it is the perfect spot for a cache.
  5. Stateless – State is kept in a database tier, caching tier, or other services, not in applications or stuffed in local pockets.
  6. Scalable Component Services – Other services that themselves are scalable and highly available are used to implement this service. Messages also uses: Memcache, User index service, and HayStack.
  7. Full Stack Ops – Tools were developed to manage, monitor, identify performance issues and upgrade the entire service, up, down and across the stack.
  8. Celled – Messages has as the basic building block of their system a cluster of machines and services called a cell. If you need more power captain, then cells are added in an incremental fashion. A cell consists of ZooKeeper controllers, an application server cluster, and a metadata store. Cells provide isolation as the storage and application horsepower to process requests is independent of other cells. Cells can fail, be upgraded, and distributed across datacenters independent of other cells.
  1. 階層化 – コンポーネントは、独立し分離されている。
  2. Service/API ドリブン – それぞれの階層は、対象となるサービスにアクセスするための、唯一のエントリーポイントとなる明瞭なインターフェイスを介して接続される。 それにより、扱い難く複雑な相互依存性が排除される。 クライアントは、アプリケーション API の背後に隠れる。 そして、アプリケーションはデータ・アクセス層を利用することになる。
  3. 分散 – 複数のマシンで構成されるクラスターをまたいで、透過的に分散される階層。
  4. アプリケーション・ロジックの分離 – アプリケーション・ロジックは、API エンドポイントを提供するアプリケーション・サーバー内にカプセル化される。 アプリケーション・ロジックは、他のサービスのために実装される。さらに、このアプリケーション・サーバー・ティアは、 ユーザーデータの書込み/検索が行われる、唯一の場所としての、ライト・スルー・キャッシュを隠す。 それにより、キャッシュのための完璧なスポットができあがる。
  5. ステートレス – ステートは、データベース・ティアおよび、キャッシュ・ティア、あるいは他のサービス内に保持され、アプリケーション・ティアやローカルなポケットに詰め込まれない。
  6. スケーラブルなコンポーネント・サービス – このサービスを実装するために、スケールと可用性を自身で達成する、サービス群が用いられる。 メッセージにおいては、Memcache および、ユーザー・インデックス・サービス、 HayStack も用いられる。
  7. フル・スタック操作 – ツールに関しては、管理/監視および、パフォーマンス問題の識別のために開発される。 また、サービス全体のアップグレードや、対象となるスタックの UP/DOWN/ACROSS にも対応する。
  8. セル – メッセージは、複数のマシンによるクラスターと、セルと呼ばれるサービス群を、システムの基本的なビルディング・ブロックとして有する。 そして、より以上のパワーを必要とする場合は、逐次的な形態でセルを追加できる。 このセルは、ZooKeeper コントローラーおよび、アプリケーション・サーバー・クラスタ、メタデータ・ストアにより構成される。 リクエストを処理するストレージとアプリケーションの容量が、他のセルから独立するにつれて、セルによる分離が提供されていく。 セルが失敗すると、アップグレードが行われ、データセンターをまたいだ分散が実施され、セル間の独立性が確保されていく。

imageQualities 1-7 are well known and fairly widely acknowledge and deployed in some form or another. The cell idea isn’t as widely deployed as it ratchets up the abstraction level to 11.

特質 1-7 は広く認識されて、また、広範囲で受け入れられ、別の形態でもディプロイされている。 しかし、セルの考え方は、その抽出レベルを 11 に高める割には、広範囲でディプロイされていない。

Salesforce has a similar idea called a pod. For Salesforce each pod consists of 50 nodes, Oracle RAC servers, and Java application servers. Each pod supports many thousands of customers.We’ve seen other products bundle shards in a similar way. A shard would consist of a database cluster and storage that hides a master-slave or a master-master configuration into a highly available and scalable unit. Flickr is an early and excellent example of this strategy.

Salesforce は、pod と呼ばれる同種の考え方を持っている。 Salesforce における個々の pod は、50 個のノードおよび、Oracle RAC サーバー、Java アプリケーション・サーバーにより構成されている。 そして、それぞれの pod により、数千人の顧客がサポートされる。  このような別種のプロダクトが、同種の方式により、共有を達成している状況を確認している。 こうした共有は、データベース・クラスタとストレージで構成され、マスター・スレーブあるいはマスター・マスターのコンフィグレーションを、スケーラブルで高可用性なユニットの中に隠すだろう。 Flickr は、このストラテジーを早期に実施し、また、優秀な事例を提供している。

The really interesting bits of the article is how cluster management within a cell is handled and how the management of the cells as a unit is handled. That’s the hard part to get right.

この記事における興味深い視点は、セル内でクラスター・マネージメントを実施する方式と、ユニットとしてのセル・マネージメントの方式である。 それを正確にするのは、決して容易ではない。

In a cluster of machines, nodes and thus the services on those nodes can twinkle in and out of existence at any time. Configuration can change also change at any time? How do you keep all systems in the cell coordinated? ZooKeeper. ZooKeeper is used for high availability, sharding, failover, and services discovery. All essential features for a cluster of fallible machines. Within a cell application servers form a consistent hash ring and users are shard across these servers.

複数のマシンで構成されるクラスターにおいて、ノードおよび、そのノード上のサービスは、その存在を、いつでも ON/OFF できる。 コンフィグレーションにより、いつでも変更できるのだろうか? 対象となるセル内の、すべてのシステムを、どのように調和させるのだろうか? そのために、ZooKeeper がある。 ZooKeeper は、高可用性および、Sharding、Failover、Services Discovery のために用いられる。 すべての本質が、誤りを犯しがちなマシン・クラスタのためのに提供されている。 セル・アプリケーションにおいて、サーバーは安定したハッシュ・リングを形成し、また、それらのサーバーを横断したかたちでユーザーは共有される。

What about cross cell operations, how are they handled? Messages has a Discovery Service that is a kind of User DNS, it sits above the cells and maintains a user to cell mappings. If you want to access user data you have to find the correct cell first using the service.  In the cell adistributed logic client acts as the interface to the Discovery Service and processes ZooKeeper notifications.

クロス・セル・オペレーションについては、どのように処理すべきなのだろうか? メッセージは、ある種の User DNS である Discovery Service を有するが、それはセル上に配置され、ユーザーとセルのマッピングを維持する。 ユーザー・データにアクセスする場合には、そのサービスを最初に用いて、正しいセルを見つけだす必要がある。  つまり、そのセルにおいて、分散ロジック・クライアントは、Discovery Service のインターフェイスおよび、ZooKeeper ノーティファケーションを処理するプロセスとしての、役割を担うことになる。

The article is very well written and has a lot of detail. Well worth reading, especially if you are trying to figure out how to structure your own service.

この記事は、きわめて適切に記述され、また、数多くの詳細を取り込んでいる。つまり、読む価値は充分にある。 とりわけ、自身のサービスにおける構造を理解したい場合に、お薦めできるだろう。

Related Articles

ーーーーー

ひさびさの、Facebook スケールアウトに関する記事でした。 Facebook に関する、この種の記事は面白いですね。 いつも、初めて耳にする概念が登場してきます。 今回は Cell で、Salesforce には同種の Pod があるとのことです。 う~ん、スゴイ! ーーー __AC Stamp 2

ーーーーー

<関連>

Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook における 1300万/秒 クエリーの秘密
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
Apache ZooKeeper による分散並列キューの構築

Twitter サーチを 3倍速にする新アーキテクチャとは? _3

Posted in Big Data, Twitter by Agile Cat on April 17, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

ーーーーー

これは、三部作の最終回です。初めての方は、1 と 2 をお先に ど~ぞ。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

MULTIPLEXING INCOMING REQUESTS

Because workflows are mapped to Netty pipelines in Blender, we needed to route incoming client requests to the appropriate pipeline. For this, we built a proxy layer that multiplexes and routes client requests to pipelines as follows:

このワークフローは、Brender における Netty パイプラインにマップされるため、Incoming リクエストを、適切なパイプラインに送る必要があった。 そのため、以下のようなマルチプレックスのプロキシー・レイヤを構築し、パイプラインにクライアント・リクエストをルーティングしている:

  • When a remote Thrift client opens a persistent connection to Blender, the proxy layer creates a map of local clients, one for each of the local workflow servers. Note that all local workflow servers are running inside Blender’s JVM process and are instantiated when the Blender process starts.
  • When the request arrives at the socket, the proxy layer reads it, figures out which workflow is requested, and routes it to the appropriate workflow server.
  • Similarly, when the response arrives from the local workflow server, the proxy reads it and writes the response back to the remote client.
  • リモート Thrift クライアントから Blender に、永続的なコネクションをオープンするときに、このプロキシー・レイヤがローカル・クライアントを作成し、それぞれのローカル・ワークフロー・サーバーにマップしていく。 注意すべきことは、すべてのローカル・ワークフロー・サーバーが、Bernder の JVM プロセス内で実行され、また、Brender プロセスがスタートするときにインスタンス化される点である。
  • それらのリクエストがソケットに到着するとき、プロキシー・レイヤによる読み込みが行われ、求められるワークフローの種類が理解され、適切なワークフロー・サーバーへのルーティングが行われる。
  • それと同様に、それらのローカル・ワークフロー・サーバーからレスポンスが戻ったとき、対象となるプロキシーによる読み込みが行われ、リモート・クライアントへのレスポンスの書込みが完了する。

We made use of Netty’s event-driven model to accomplish all the above tasks asynchronously so that no thread waits on I/O.

それら全てのタスクを非同期化するために、Netty のイベント駆動型モデルを利用することで、I/O の待ち時間が排除された。

imageDISPATCHING BACK-END REQUESTS

Once the query arrives at a workflow pipeline, it passes through the sequence of service handlers as defined by the workflow. Each service handler constructs the appropriate back-end request for that query and issues it to the remote server. For example, the real-time service handler constructs a realtime search request and issues it to one or more realtime index servers asynchronously. We are using the twitter commons library (recently open-sourced!) to provide connection-pool management, load-balancing, and dead host detection.

ワークフロー・パイプラインに到着したクエリーは、対象となるワークフローで定義さたとおりに、サービス・ハンドラーのシーケンスを通過していく。 続いて、それぞれのサービス・ハンドラーが、対象となるクエリーに適したバックエンド・リクエストを構成し、リモート・サーバーへ向けて送り出す。 たとえば、リアルタイム・サービス・ハンドラーは、リアルタイム・サーチ・リクエストを構成し、複数のリアルタイム・インデックス・サーバーへ向けて、そのリクエストを非同期で発行する。私たちは、コネクション・プール管理および、ロード・バランシング、デッド・ホスト検出を提供するために、 Twitter コモン・ライブラリ(最近オープンソース化された!)を使用している。

The I/O thread that is processing the query is freed when all the back-end requests have been dispatched. A timer thread checks every few milliseconds to see if any of the back-end responses have returned from remote servers and sets a flag indicating if the request succeeded, timed out, or failed. We maintain one object over the lifetime of the search query to manage this type of data.

すべてのバックエンド・リクエストがディスパッチされると、そのクエリーを処理している I/O スレッドが解放される。 タイマー・スレッドは、数ミリ秒ごとにチェックを行い、リモート・サーバーから返されたバックエンド・レスポンスを確認し、トリガーとなったリクエストに対して、succeeded/timed out/failed といったフラグをセットしていく。 私たちのシステムでは、この種のデータを管理するために、サーチ・クエリーのライフタイムをカバーするよう、そのオブジェクトを保持している。

Successful responses are aggregated and passed to the next batch of service handlers in the workflow pipeline. When all responses from the first batch have arrived, the second batch of asynchronous requests are made. This process is repeated until we have completed the workflow or the workflow’s timeout has elapsed.

成功したレスポンスはアグリゲートされ、そのワークフロー・パイプライン内におけるサービス・ハンドラーの、次のバッチに受け渡される。 最初のバッチからの、すべてのレスポンスが到着したとき、非同時性のリクエストにおける 2番目のバッチが作成される。 そのワークフローが完了するまで、あるいは、ワークフローのタイムアウトが経過するまで、このプロセスは繰り返される。

As you can see, throughout the execution of a workflow, no thread busy-waits on I/O. This allows us to efficiently use the CPU on our Blender machines and handle a large number of concurrent requests. We also save on latency as we can execute most requests to back-end services in parallel.

ここまでに確認してきたように、ワークフローの実行を通じて、 I/O 上のスレッド・ビジー待ちは発生しない。つまり、Blender マシン上での CPU 利用および、大量のコンカレント・リクエスト処理において、効率化が実現される。 そして、並列化されたバックエンド・サービスで、大半のリクエストを処理するときには、レイテンシーを抑えることができる。

BLENDER DEPLOYMENT AND FUTURE WORK

To ensure a high quality of service while introducing Blender into our system, we are using the old Ruby on Rails front-end servers as proxies for routing thrift requests to our Blender cluster. Using the old front-end servers as proxies allows us to provide a consistent user experience while making significant changes to the underlying technology. In the next phase of our deploy, we will eliminate Ruby on Rails entirely from the search stack, connecting users directly to Blender and potentially reducing latencies even further.

このシステムに Blender を導入するのと並行して、高品質のサービスを保証するために、従来からの Ruby on Rails フロントエンド・サーバーをプロキシーとして利用し、Blender クラスタへ向けて Thtift リクエストを送っている。 フロントエンド・サーバーをプロキシーとして使用することで、基礎をなすテクノロジーに相当量の変更を施す間も、一貫したユーザー・エクスペリエンスの提供が実現される。 私たちの、次のディプロイ・フェーズでは、このサーチ・スタックから Ruby on Rails を完全に取り除き、ユーザーと Blender のダイレクトな接続を実現し、また、さらなるレイテンシーの低減を目指すだろう。

—@twittersearch

ACKNOWLEDGEMENTS

The following Twitter engineers worked on Blender: Abhi Khune, Aneesh Sharma, Brian Larson, Frost Li, Gilad Mishne, Krishna Gade, Michael Busch, Mike Hayes, Patrick Lok, Raghavendra Prabhu, Sam Luckenbill, Tian Wang, Yi Zhuang, Zhenghua Li.

ーーーーー

いやぁ~~~ 面白かったです。 このポストに関しては、いろいろな方から Twitter でコメントいただきました。 おかげさまで、とても多くの方が注目するアーキテクチャなのだと、実感することができました。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー
Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter サーチを 3倍速にする新アーキテクチャとは? _2

Posted in Big Data, Twitter by Agile Cat on April 15, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

ーーーーー

初めての方は、1 をお先に ど~ぞ。三部作になっています。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

BLENDER OVERVIEW

Blender is a Thrift and HTTP service built on Netty, a highly-scalable NIO client server library written in Java that enables the development of a variety of protocol servers and clients quickly and easily. We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework. To make Netty work with Thrift, we wrote a simple Thrift codec that decodes the incoming Thrift request from Netty’s channel buffer, when it is read from the socket and encodes the outgoing Thrift response, when it is written to the socket.

Blender とは、Netty 上に構築された Thrift と HTTP のサービスであり、Java で記述されたスケーラブルな NIO クライアント・サーバライブラリにより、多様なプロトコルを用いるサーバーとクライアントを、迅速かつ容易に開発していく。たとえば、Mina や Jetty なども提供されるコンペティションの中から Netty を選んだ理由としては、整理された API や、洗練されたドキュメントなどが挙げられるが、それらよりも重要なのは、Twitter ににおける他のプロジェクトが、このフレームワークを用いている点にある。 Netty と Thrift を組み合わせるために、Netty のチャネル・バッファからの incoming Thrift のリクエストをデコードする、シンプルな Thrift コーデックを記述した。それは、ソケットからの読み込みと、outgoing Thrift レスポンスをエンコードするとき、また、ソケットへの書き込みを行うときに機能する。

Netty defines a key abstraction, called a Channel, to encapsulate a connection to a network socket that provides an interface to do a set of I/O operations like read, write, connect, and bind. All channel I/O operations are asynchronous in nature. This means any I/O call returns immediately with a ChannelFuture instance that notifies whether the requested I/O operations succeed, fail, or are canceled.

Netty は、Channel と呼ばれる重要な抽象概念を定義する。それにより、read/write/connect/bind といった I/O オペレーションを設定する、インターフェイスのためのネットワーク・ソケットへの接続がカプセル化される。 すべての Channel I/O オペレーションは、本質的に非同期である。つまり、あらゆる I/O コールが、要求された I/O オペレーションが succeed/fail/canceled されたことを通知する、ChannelFuture インスタンスを直ちに返すことになる。

When a Netty server accepts a new connection, it creates a new channel pipeline to process it. A channel pipeline is nothing but a sequence of channel handlers that implements the business logic needed to process the request. In the next section, we show how Blender maps these pipelines to query processing workflows.

Netty サーバーが新しいコネクションを受け入れるとき、その処理のためお、新しいチャンネル・パイプラインが作成される。 このチャネル・パイプラインは、リクエストを処理するために必要なビジネス・ロジックを実装する、チャネル・ハンドラーのシーケンスに過ぎない。次のセクションでは、それらのパイプラインと、クエリー処理ワークフローを、Blender がマップする方式を説明する。

WORKFLOW FRAMEWORK

In Blender, a workflow is a set of back-end services with dependencies between them, which must be processed to serve an incoming request. Blender automatically resolves dependencies between services, for example, if service A depends on service B, A is queried first and its results are passed to B. It is convenient to represent workflows as directed acyclic graphs (see below).

Blender において、ワークフローとは総合に依存するバックエンド・サービスのセットのことであり、incoming リクエストを取り扱うために処理されるものとなる。 そして Blender は、それらのサービス間の依存性を自動的に解決する。 たとえば、Service A が Service B に依存している場合には、最初に A がクエリーされ、その結果が B に手渡される。このワークフローを、非環式の有向グラフを用いて表現すると解りやすい(以下を参照)。

Sample Blender Workflow with 6 Back-end Services

In the sample workflow above, we have 6 services {s1, s2, s3, s4, s5, s6} with dependencies between them. The directed edge from s3 to s1 means that s3 must be called before calling s1 because s1 needs the results from s3. Given such a workflow, the Blender framework performs a topological sort on the DAG to determine the total ordering of services, which is the order in which they must be called. The execution order of the above workflow would be {(s3, s4), (s1, s5, s6), (s2)}. This means s3 and s4 can be called in parallel in the first batch, and once their responses are returned, s1, s5, and s6 can be called in parallel in the next batch, before finally calling s2.

上記のサンプル・ワークフローには、相互に依存する 6つの Service  {s1, s2, s3, s4, s5, s6} がある。s3 から s1 へ向けられた方向性を持つエッジは、s1 をコールする前に s3 をホールする必要性を示している。 その理由は、s1 が s3 の結果を要求する点にある。 このようなワークフローを前提として、Blender フレームワークは、それぞれの Service がコールされる順番を決定するために、DAG 上でのトポロジカル・ソートを行なう。 上記のワークフローにおける実行の順序は、{(s3, s4), (s1, s5, s6), (s2)} となるはずだ。つまり、最初のバッチにより、s3 と s4 をパラレルにコールできる。続いて、それらからのリターンの後に、s1 と s5 と s6 をパラレルにバッチ処理し、最後に s2 をコールする。

Once Blender determines the execution order of a workflow, it is mapped to a Netty pipeline. This pipeline is a sequence of handlers that the request needs to pass through for processing.

Blender がワークフローの実行順序を決定した後に、Netty パイプラインとのマップが行われる。 このパイプラインは、全体的な処理を通じて、受け渡しが必要なリクエストを、処理するためのシーケンスとなる。

ーーーーー

昨日の、okachimachiorz1 ジェイムズ・ブッカー先生によりますれば、『 Blenderすか。非同期+DAG+Scalaですか。まさにクラウド型のアーキテクチャです。 要チェックですな 』 とのことです。 なる! ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー
Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter サーチを 3倍速にする新アーキテクチャとは? _1

Posted in .Selected, Big Data, Twitter by Agile Cat on April 14, 2011

Twitter Search is Now 3x Faster
Wednesday, April 6, 2011
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

clip_image001

ーーーーー

三部作になっています。続編も ど~ぞ。

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーー __AC Stamp 2

ーーーーー

In the spring of 2010, the search team at Twitter started to rewrite our search engine in order to serve our ever-growing traffic, improve the end-user latency and availability of our service, and enable rapid development of new search features. As part of the effort, we launched a new real-time search engine, changing our back-end from MySQL to a real-time version of Lucene. Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

2010年の春のことだが、 Twitter におけるサーチ・チームは、そのサーチ・エンジンを書き直し始めた。 その理由は、永遠に増大していくトラフィックに対処し、エンドユーザーにおけるレイテンシーとサービスの可用性を改善し、新しいサーチ機能の迅速な開発を可能にする点にあった。 その作業の一部として、Twitter のバックエンドを、MySQL  から Lucene のリアルタイム・バージョンに変更することで新しいリアルタイム・サーチ・エンジンを立ち上げている。 そして先週、私たちは Ruby-on-Rails のフロントエンドを、Blender という Java サーバーに置き換えた。 この変更により、サーチ・レイテンシーを 1/3 に低減し、今後の数ヶ月という短い期間において、いくつかのサーチ機能を改善していけるようになった。 このような発表ができて、とても嬉しく思う。

PERFORMANCE GAINS

Twitter search is one of the most heavily-trafficked search engines in the world, serving over one billion queries per day. The week before we deployed Blender, the #tsunami in Japan contributed to a significant increase in query load and a related spike in search latencies. Following the launch of Blender, our 95th percentile latencies were reduced by 3x from 800ms to 250ms and CPU load on our front-end servers was cut in half. We now have the capacity to serve 10x the number of requests per machine. This means we can support the same number of requests with fewer servers, reducing our front-end service costs.

Twitter サーチは、1日あたり 10億以上のクエリーをサポートするという、最も多くのトラフィックを発生させるサーチ・エンジンの 1つである。 この Blender をディプロイする前の週に、日本における #tsunami により、著しいクエリーが発生し、サーチ・レイテンシーに大きなピークが生じた。 そして、この Blender の立ち上げの後には、私たちの 95 パーセンタイル・レイテンシが、800ms から 250ms へと、約 1/3 に低減された。 さらに、フロントエンド・サーバー上の CPU 負荷は、半分にカットされた。 そして、今では、マシンごとのリクエストに関するキャパシティを、10 倍に引き上げる能力を持つに至った。 それにより、以前と同じだけのリクエスト量を、より少ないサーバー台数で処理することが可能となり、フロントエンド・サーバーに関するコストも低減できるようになった。

image

95th Percentile Search API Latencies Before and After Blender Launch

TWITTER’S IMPROVED SEARCH ARCHITECTURE

In order to understand the performance gains, you must first understand the inefficiencies of our former Ruby-on-Rails front-end servers. The front ends ran a fixed number of single-threaded rails worker processes, each of which did the following:

このパフォーマンス向上の理由を理解するには、以前の Ruby-on-Rails フロントエンド・サーバーの非効率について、最初に理解しなければならない。 このフロントエンドは、固定した数のシングル・スレッド Rails Worker プロセスを実行してており、個々のスレッドは以下の項目を処理していく:

  • parsed queries
  • queried index servers synchronously
  • aggregated and rendered results
  • パーズされたクエリー
  • クエリーされたインデックスのサーバー間同期
  • アグリゲーションとレンダリングの結果

We have long known that the model of synchronous request processing uses our CPUs inefficiently. Over time, we had also accrued significant technical debt in our Ruby code base, making it hard to add features and improve the reliability of our search engine. Blender addresses these issues by:

この同期プロセス処理のモデルが、CPU 非効率に消費していることを、私たちは以前から認識していた。 そして、長い時間を経ることで、この Ruby コードベース上にテクニカルな負債を大量に蓄積しており、サーチ・エンジンにおける信頼性の改善や、新しい機能の追加を難しくしていた。 そして、Blender により、以下の問題に取り組んでいる:

  1. Creating a fully asynchronous aggregation service. No thread waits on network I/O to complete.
  2. Aggregating results from back-end services, for example, the real-time, top tweet, and geo indices.
  3. Elegantly dealing with dependencies between services. Workflows automatically handle transitive dependencies between back-end services.
  1. 完全な、非同期アグリゲーション・サービスの構築。ネットワーク I/O の終了を、スレッドが待たない方式。
  2. バックエンド・サービスからの結果をアグリゲート。 たとえば、リアルタイムや、トップ・ツイート、地理インデックスなど。
  3. サービス間の依存性を、エレガントに取り扱う。 Workflows は、バックエンド・サービス間における、推移的な依存性を自動的に処理する。

The following diagram shows the architecture of Twitter’s search engine. Queries from the website, API, or internal clients at Twitter are issued to Blender via a hardware load balancer. Blender parses the query and then issues it to back-end services, using workflows to handle dependencies between the services. Finally, results from the services are merged and rendered in the appropriate language for the client.

以下のダイアグラムは、Twitter サーチ・エンジンのアーキテクチャを示す。  Twitter における Webサイト/API/内部クライアントからのクエリーは、ハードウェア・ロードバランサーを介して Blender に発行される。 Blender により解析されたクエリーは、サービス間に依存性を処理するワークフローを用いて、バックエンド・サービスへと発行される。最終的に、このサービスからの結果がマージされ、対象となるクライアントに適した言語でレンダリングされる。

Twitter Search Architecture with Blender

ーーーーー

大好評だった、昨日のポスト 『 Twitter における、Ruby から Java への回帰とは? 』の元ネタは、この Twitter Blog の記事です。 長いので、とりあえず Part_1 としてポストします。なお、Twitter で頂いたコメントは、Facebook Page に整理しています。 ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3
ーーーーー
Blenderに近いアーキテクチャになっているMessage Pack RPCのJava版の実装
Talk about Scala – SlideShare ( @yasushia さんより)
Twitter における、Ruby から Java への回帰とは?
ーーーーー

Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

Twitter における、Ruby から Java への回帰とは?

Posted in Big Data, Twitter by Agile Cat on April 13, 2011

Once Again, Twitter Drops Ruby for Java
By
Alex Williams / April 11, 2011 4:00 PM
http://www.readwriteweb.com/cloud/2011/04/twitter-drops-ruby-for-java.php

_ Read Write

ーーーーー

<元ネタです>

Twitter サーチを 3倍速にする新アーキテクチャとは? _1
Twitter サーチを 3倍速にする新アーキテクチャとは? _2
Twitter サーチを 3倍速にする新アーキテクチャとは? _3

ーーーーー

Twitter has now moved its entire search stack from Ruby-on-Rails to Java. That’s a big shift. Twitter moved its back end message que from Ruby to Scala, a Java platform in the 2008-2009 time frame. The move was attributed to issues with reliability on the back-end. This latest move makes the shift pretty much complete. At Twitter, Ruby is out of the picture.

Image(28)

Twitter のサーチ・スタック全体が、Ruby-on-Rails から Java に移行された。 まさに、大きな変更である。 具体的に言うと、Twitter のバックエンド・メッセージ・キューが Ruby から、2008-2009 タイムフレームにおける Java プラットフォームである、Scala に移行したことになる。 この変化は、バックエンドにおける信頼性の問題に起因すると思われる。 この、最近に実施された変更は、その大方を完了し、Twitter からは Ruby が消えることになる。

Twitter explains the change on its engineering blog:

Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

Twitter の engineering blog では、この変更について、以下のように説明されている:

Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months.

先週のことだが、Ruby-on-Rails によるフロントエンドを、Blender と呼ぶ Java サーバーに置き換えた。 この変更により、サーチのレイテンシーが 1/3 に抑えられたことを発表できて嬉しい。 そして、今後の数ヶ月のうちに、複数のサーチ機能について、迅速なイテレーションが可能となる。

imageDoes this mean that Java is better than Ruby for services with heavy loads?

つまり、大きな負荷を伴うサービスに関しては、Ruby よりも Java の方が適しているのだろうか?

Ganeshji Marwaha, director at Triomatrix Webservices, says it all depends:

Wow, that is quite an achievement. Could this mean that Java is a better platform than Rails for high scalability needs? Even if that is the case, for simpler scenarios, the beauty of RoR out-weighs Java’s performance.

They say that this change will enable them to rapidly iterate on search features in the coming months. That along with the news that Twitter has hired 25 more employees kinda tells that Java’s code base is practically more maintainable than equivalent Ruby code – at least when the code base is huge and the team size is large. Or that could mean that this time they really put a lot of thought into designing a maintainable system than when they started out. But for smaller team size and code base, RoR is still an unbeaten champion.

Triomatrix Webservices のディレクターである Ganeshji Marwaha は、すべてが依存すると発言している:

Wow ! それは、なかなかの成果だ。 それにより、高度なスケーラビリティの要求において、Java が Rails よりも優れたプラットフォームであると、捉えられるのだろうか? たとえ、そのようなケースであるにしても、よりシンプルなシナリオにおいては、RoR の美しさが Java のパフォーマンスに勝る。

Twitter は、今後の数ヶ月のうちに、複数のサーチ機能について、迅速なイテレーションが可能になると言っている。 この、Twitter が 25人の技術者を採用したというニュースによると、Java と Ruby のコードを比較して、Java の方がメンテナンスしやすいと捉えられる。少なくとも、そのコードベースが巨大である、さらにチームの規模が大きいときには、そうなる。 また、今回の変更においては、Twitter がスタートしたときと比べて、さらにメンテナンスが容易になる、たくさんの新しいアイデアが投入されたのかもしれない。 しかし、小規模なコードベースとチームを前提にするなら、依然として RoR が無敵のチャンピオンである。

You can read the full account about the new search capabilities with Java on the Twitter blog post. It goes into detail about the changes and the benefits that it is seeing with the switch.

なお、Twitter のブログ・ポストで、Java を用いた新しいサーチ機能に関する、詳細な記述が読める。 そこでは、今回の切り替えにおける、変更とメリットに関する細部が述べられている。

ーーーーー

先日の 『 MySpace を殺したのは Microsoft ソフトウェア・スタックなのか? いや、それは違うだろう 』 では、Twitter においても RoR を、そのまま使っていることなどあり得ないと、Todd Hoff さんが説明していました。そして、今回の変更は、Java への回帰という、とても興味深いものになっています。 MySpace の失速も、開発のための環境やツールを、使いこなせる人材の確保の難しさが原因とのことであり、ハイ・スケーラビリティの難しさを感じさせてくれます。ーーー __AC Stamp 2

ーーーーー

<関連>

Twitter は 毎日、46万ユーザーを増やし、1億 4000万ツイートを発信する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!
10億人のユーザーを目指す、Twitter の 6つの戦略とは?
日本の大震災で証明された Twitter と Facebook の SOS パワー
Twitter が、新しいデータセンターへの移行を完了
Happy Birthday Twitter – 5 歳になりました!

MySpace を殺したのは Microsoft ソフトウェア・スタックなのか? いや、それは違うだろう。

Posted in .Selected, Big Data, Facebook by Agile Cat on April 6, 2011

Did The Microsoft Stack Kill MySpace?
transparentFRIDAY, MARCH 25, 2011
http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html

_highscalability

Robert Scoble wrote a fascinating case study, MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft, where he reports MySpace insiders blame the Microsoft stack on why they lost the great social network race to Facebook. 

Robert Scoble が書いた魅力的なケース・スタディである MySpace’s death spiral: insiders say it’s due to bets on Los Angeles and Microsoft は、Facebook とのソーシャル・ネットワーク・レースで負けた理由について、Microsoft スタックに賭けたせいだと、MySpace の関係者が責任転嫁している様子をレポートしている。

Does anyone know if this is true? What’s the real story?

それが事実であると、いったい誰か分かるのだろうか? 真実は、どこにあるのだろうか?

5558830752_4c895c0b76_m

I was wondering because it doesn’t seem to track with the MySpace Architecture post that I did in 2009, where they seem happy with their choices and had stats to back up their improvements. Why this matters is it’s a fascinating model for startups to learn from. What does it really take to succeed? Is it the people or the stack? Is it the organization or the technology? Is it the process or the competition? Is the quality of the site or the love of the users? So much to consider and learn from.

私が 2009年にポストしたとき、この問題と MySpace Architecture が関係しているとは考えなかった。 さらに、MySpace は自身の選択に満足し、その改善が促進されるように見えていただけに、私は不思議だった。 この問題は、スタートアップが学ぶべき魅力的なモデルである。だからこそ重要なのだ。 本当に成功するためには、何を行うべきなのか? それは、人々に依存すべきことなのか? それとも、ソフトウェア・スタックに依存すべきことなのか? それは、組織的なことなのか? それとも、技術的なことなのか? それは、プロセスの問題なのか? それとも、コンペティションの問題なのか? それは、サイトの品質なのか? それとも、ユーザーの好みなのか? そこには、検討し学習すべき、多くの事柄がある。

Some conjectures from the article:

  1. Myspace didn’t have programming talent capable of scaling the site to compete with Facebook.
  2. Choosing the Microsoft stack made it difficult to hire people capable of competing with Facebook. .Net programmers are largely Enterprise programmers who are not constitutionally constructed to create large scalable websites at a startup pace. 
  3. Their system had ” “hundreds of hacks to make it scale that no one wants to touch,” which hamstrung their ability to really compete.
  4. Because of their infrastructure MySpace can’t change their technology to make new features work or make dramatically new experiences.
  5. Firing a lot of people nose dived morale and made hiring tough. (duh)
  6. Los Angeles doesn’t have startup talent capable of producing a scalable social network system.
  7. Facebooks’ choice of the LAMP stack allowed them to hire quicker and find people who knew how to scale.

この記事から、いくつかの事柄が推測できる:

  1. Myspace には、Facebook と競合するために、自身のサイトをスケールしていくだけの、プログラミングに関する能力が備わっていなかった。
  2. Microsoft スタックの選択は、Facebook と競合するために必要な、人材の確保を困難にした。.Net プログラマの大半はエンタープライズ・プログラマであり、スタートアップのようなペースで、大規模でスケーラブルな Web サイトを構築していける状況にはなかった。
  3. 彼らのシステムには、誰も触りたがらないほどの、スケールアップのためのハッキングの痕跡が残されていた。それにより、彼らの競争力が削がれていった。
  4. そのインフラストラクチャにより、新しい機能やエクスペリエンスをもたらすために、MySpace はテクノロジーを変更することが出来なかった。
  5. モラルを失った大量の従業員を解雇し、扱いにくい人々を雇うはめになった。(あたりまえ)
  6. Los Angeles という土地柄は、スケーラブルなソーシャル・ネットワーク・システムを作り出すための、スタートアップ的な人材を雇用しにくい。
  7. Facebook の選択である LAMP スタックは、スケーラブルを知っている人材の確保を容易にし、それを迅速に実現する。

Some very interesting points in the comments (from the article, email, Hacker News):

注記: 原文では、ここに 30人以上からのコメントが寄れられています。 それを踏まえた上で、以下のように Todd Hoff さんはマトメています。

Some of my observations:

Todd Hoff の視点:

  • The stack isn’t the real problem. That’s almost silly. Look at Windows, .Net, etc and they are all quite capable of scaling if used correctly. Facebook started with LAMP, but along the way they changed everything about it such that it would be hard to say they were still using LAMP in the end. Twitter went through a similar phase with RoR. You can’t exist at this scale without transforming everything you touch to meet your specific needs. Facbook also uses very small teams of people, so you don’t really need great hoards of talented people. You need some talented people backed up by the right vision, support, and a management who sets them free to solve problems.

 

  • ソフトウェア・スタックに、問題の本質があるわけではない。その大半は、思慮に欠けた行為にある。 Windows を確認してみよう。それを正しく用いれば、.Net などのスタックは、充分にスケーリングを達成する。 Facebook は LAMP から開始したが、すべてを LAMP で達成することは困難であるという考え方にしたがって、すべてを途中で切り替えた。 Twitter は、RoR(Ruby on Rails)が用いているが、同じようなプロセスを通り抜けることになった。 そのスケールにおいて、特定のニーズを充たすためには、すべての必要とされる要素を変更しなければならない。 さらに、Facebook では、きわめて小規模なチームが用いられる。 したがって、本当に才能がある人々を、大量に抱え込むことが必要というわけではない。 必要なことは、正しいビジョン/サポート/マネージメントにより、何人かの才能のある人々をバックアップし、問題を解決しやすい環境を作ることである。

 

  • The question is why wasn’t the technology used correctly? The comments point to a lot of different reasons, but they all eventually get down to people. Were they bought by a management team that didn’t value technology? That seems likely if some of the development, release, and design decisions are to be believed. Core competencies seemed to be farmed out to third parties. Technoligies like SANs were brought into to solve problems instead of dealing with the problems directly. Both are deadly. Whatever makes you a success you must own completely. Maybe being an “entertainment” company rather than a technology company fosters that sort of approach. But that again would get back to ownership and management. People seem to forget that talent can’t work in a straight jacket, unless they are magicians.

 

  • そのテクノロジーが正確に使われなかった点に、問題の本質があるのだろうか?提供されたコメントは、数多くの異なるポイントを指し示すが、その大半は人的な問題に帰結している。 それらのテクノロジーは、技術を高く評価しない経営陣により導入されたのだろうか? 開発/リリース/デザインに関する判断が、信じられる場合は、それもあり得る。 また、コア・コンピテンシーが、サードパーティに外注されていたようにも思われる。 さらに、生じてくる問題をダイレクトに取り扱う代わりに、たとえば SAN のようなテクノロジーが購入され、問題を解決していった。どちらも、命取りである。 成功したいならば、すべてを把握する必要がある。 おそらく、テクノロジーの会社であるも、エンターテイメントの会社である方が、この種のアプローチを促進する。 しかし、それもオーナーシップとマネージメントの話に戻るだろう。才能を有する人々に拘束衣を着せてしまっては、彼らがマジシャンでも無いかぎり、仕事が出来ないことを、人々は忘れがちである。

 

  • The innovation question is interesting. We see companies like Facebook, Amazon, Google, and Apple constantly innovating. How important was that in MySpace’s fate? And why wasn’t innovation important to them? 

 

  • この、イノベーションの問題は興味深い。 Facebook や、Amazon、Google、Apple といった企業が、イノベーションを継続しているのを、私たちは見ている。 MySpace の運命において、どれほどにイノベーションは重要だったのだろうか? そして、彼らにとって、イノベーションが重要ではない理由は、何処にあったのだろうか?

So, what happened? More importantly, how can new startups and groups within companies avoid this fate? We see this all the time. It’s depressing for everyone involved. Shouldn’t we be past this sort of thing by now?

そして、何が起こったのだろうか? さらに重要なことは、新しいスタートアップやグループは、どのようにして、このような運命を避けるべきなのだろうか? それは、常に繰り返されることである。 それは、すべての関係者を憂うつにさせる。 これまで、この種の問題を、私たちは見過ごしてきたのではないだろうか?

ーーーーー

MySpace の凋落(Pingdom)より ⇒

読んでみて、訳してみて、自分の中にあった漠然とした疑問が、氷解したように思えます。如何に優れたプラットフォームであっても、そのフィールドに適したカルチャーを持つ、経営者/技術者により正しく利用されないことには、対象となるサービスを成功させることはできない、、、ということなのでしょう。 以下の関連リンクですが、まだ、お読みではない方には、強くお勧めしたいと思います。 面白いですよ! ーーー __AC Stamp 2

 

ーーーーー

<関連>

Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
10億人のユーザーを目指す、Twitter の 6つの戦略とは?

 

%d bloggers like this: