Agile Cat — in the cloud

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


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

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

ーーー __AC Stamp 2



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


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 利用および、大量のコンカレント・リクエスト処理において、効率化が実現される。 そして、並列化されたバックエンド・サービスで、大半のリクエストを処理するときには、レイテンシーを抑えることができる。


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 のダイレクトな接続を実現し、また、さらなるレイテンシーの低減を目指すだろう。



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 歳になりました!

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

%d bloggers like this: