Scale Out | Agile Cat --- in the cloud

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/

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 petabytes of users’ photos and videos. If it were all photos, that would be more than 666 billion of them.
30-plus petabytes of user data in its Hadoop cluster, which is used as a giant data warehouse.
$1.6–$1.8 billion on planned infrastructure spending in 2012. Google usually spends between $2 billion and $4 billion a yea r, but bought in more than 10 times Facebook’s revenue in 2011.
The overall server market was estimated at $52.3 billion in 2011, and Facebook’s Open Compute Project is trying to turn that market on its head by redefining how servers are built and sold at webscale.
Facebook doesn’t disclose the number of custom-built servers it runs, but by this point it’s far more than the 60,000 estimated in 2010.
It took Facebook less than 30 days to provision and bring online tens of thousands of servers when it fired up its Prinveville, Ore., data center.

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:

ーーーーー

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

ーーーーー

Tagged with: 100 petabytes, Data Center, Facebook, OCP, Open Compute, Scale Out

1 comment

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

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 」に書き記したアーキテクチャが、検討すべき適切なサンプルになるだろう。

Although 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 のためのサンプルであり、小規模なサイトには当てはまらないと思うだろう。しかし、それは違う。つまり、ノン･クラウド･アーキテクチャにも適した、数多くの特質を示す、きわめて正統的なサンプルとなっているのだ：

Layered – components are independent and isolated.
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.
Distributed – layers are transparently distributed across clusters of machines
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.
Stateless – State is kept in a database tier, caching tier, or other services, not in applications or stuffed in local pockets.
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.
Full Stack Ops – Tools were developed to manage, monitor, identify performance issues and upgrade the entire service, up, down and across the stack.
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.

階層化 – コンポーネントは、独立し分離されている。
Service/API ドリブン – それぞれの階層は、対象となるサービスにアクセスするための、唯一のエントリーポイントとなる明瞭なインターフェイスを介して接続される。それにより、扱い難く複雑な相互依存性が排除される。クライアントは、アプリケーション API の背後に隠れる。そして、アプリケーションはデータ･アクセス層を利用することになる。
分散 – 複数のマシンで構成されるクラスターをまたいで、透過的に分散される階層。
アプリケーション･ロジックの分離 – アプリケーション･ロジックは、API エンドポイントを提供するアプリケーション･サーバー内にカプセル化される。アプリケーション･ロジックは、他のサービスのために実装される。さらに、このアプリケーション･サーバー･ティアは、ユーザーデータの書込み／検索が行われる、唯一の場所としての、ライト･スルー･キャッシュを隠す。それにより、キャッシュのための完璧なスポットができあがる。
ステートレス – ステートは、データベース･ティアおよび、キャッシュ･ティア、あるいは他のサービス内に保持され、アプリケーション･ティアやローカルなポケットに詰め込まれない。
スケーラブルなコンポーネント･サービス – このサービスを実装するために、スケールと可用性を自身で達成する、サービス群が用いられる。メッセージにおいては、Memcache および、ユーザー･インデックス･サービス、 HayStack も用いられる。
フル･スタック操作 – ツールに関しては、管理／監視および、パフォーマンス問題の識別のために開発される。また、サービス全体のアップグレードや、対象となるスタックの UP/DOWN/ACROSS にも対応する。
セル – メッセージは、複数のマシンによるクラスターと、セルと呼ばれるサービス群を、システムの基本的なビルディング･ブロックとして有する。そして、より以上のパワーを必要とする場合は、逐次的な形態でセルを追加できる。このセルは、ZooKeeper コントローラーおよび、アプリケーション･サーバー･クラスタ、メタデータ･ストアにより構成される。リクエストを処理するストレージとアプリケーションの容量が、他のセルから独立するにつれて、セルによる分離が提供されていく。セルが失敗すると、アップグレードが行われ、データセンターをまたいだ分散が実施され、セル間の独立性が確保されていく。

Qualities 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.

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

ーーーーー

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

ーーーーー

Tagged with: Big Data, Facebook, Messages, Prashant Malik, Scale Out, Zookeeper

leave a comment

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

ーーー

ーーーーー

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 の待ち時間が排除された。

DISPATCHING 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 でコメントいただきました。おかげさまで、とても多くの方が注目するアーキテクチャなのだと、実感することができました。ーーー

ーーーーー

Tagged with: Asynchronous, Big Data, Blender, DAG, Java, Ruby on Rails, Scala, Scale Out, Twitter

leave a comment

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 をお先にど～ぞ。三部作になっています。

ーーー

ーーーーー

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ですか。まさにクラウド型のアーキテクチャです。要チェックですな』とのことです。なる！ーーー

ーーーーー

Tagged with: Asynchronous, Big Data, Blender, DAG, Java, Ruby on Rails, Scala, Scale Out, Twitter

2 comments

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

ーーーーー

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

ーーー

ーーーーー

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 倍に引き上げる能力を持つに至った。それにより、以前と同じだけのリクエスト量を、より少ないサーバー台数で処理することが可能となり、フロントエンド･サーバーに関するコストも低減できるようになった。

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 により、以下の問題に取り組んでいる：

Creating a fully asynchronous aggregation service. No thread waits on network I/O to complete.
Aggregating results from back-end services, for example, the real-time, top tweet, and geo indices.
Elegantly dealing with dependencies between services. Workflows automatically handle transitive dependencies between back-end services.

完全な、非同期アグリゲーション･サービスの構築。ネットワーク I/O の終了を、スレッドが待たない方式。
バックエンド･サービスからの結果をアグリゲート。たとえば、リアルタイムや、トップ･ツイート、地理インデックスなど。
サービス間の依存性を、エレガントに取り扱う。 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 に整理しています。ーーー

ーーーーー

Tagged with: Asynchronous, Big Data, DAG, Java, Ruby, Ruby on Rails, Scala, Scale Out, Twitter

leave a comment

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

ーーーーー

＜元ネタです＞

ーーーーー

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.

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 に抑えられたことを発表できて嬉しい。そして、今後の数ヶ月のうちに、複数のサーチ機能について、迅速なイテレーションが可能となる。

Does 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 の失速も、開発のための環境やツールを、使いこなせる人材の確保の難しさが原因とのことであり、ハイ･スケーラビリティの難しさを感じさせてくれます。ーーー

ーーーーー

Tagged with: Big Data, Java, Ruby, Ruby on Rails, Scala, Scale Out, Twitter

leave a comment

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

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

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

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?

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

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:

Myspace didn’t have programming talent capable of scaling the site to compete with Facebook.
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.
Their system had ” “hundreds of hacks to make it scale that no one wants to touch,” which hamstrung their ability to really compete.
Because of their infrastructure MySpace can’t change their technology to make new features work or make dramatically new experiences.
Firing a lot of people nose dived morale and made hiring tough. (duh)
Los Angeles doesn’t have startup talent capable of producing a scalable social network system.
Facebooks’ choice of the LAMP stack allowed them to hire quicker and find people who knew how to scale.

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

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

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

ーーーーー

Tagged with: .NET, Big Data, Facebook, Innovation, LAMP, Microsoft, MySpace, Scale Out, Social Network, Twitter

leave a comment

Facebook は 20分間で、2.7M Photos／10.2M Comments／4.6M Messages を処理する！

Posted in .Selected, Big Data, Facebook by Agile Cat on January 3, 2011

Facebook in 20 Minutes: 2.7M Photos, 10.2M Comments, 4.6M Messages
Friday, December 31, 2010 at 7:37AM
http://highscalability.com/blog/2010/12/31/facebook-in-20-minutes-27m-photos-102m-comments-46m-messages.html

このポストは、以下のリンクにある『 A Snapshot of Facebook in 2010 』のデータを元にしているようです。そちらを見ると『 Most Liked Celebrities 』もあり、『 Lady Gaga ： 24,712,169 people like 』というデータなども参照できます。ーーー A.C.

ーーーーー

To celebrate the new year Facebook has shared the results of a little end of the year introspection. It has been a fecund year for Facebook:

Facebook は新年を祝うために、その内部情報の一部を提供してくれた。 2010 年は、Facebook にとって、実り多き年だったことが分かる：