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.
この記事は、きわめて適切に記述され、また、数多くの詳細を取り込んでいる。つまり、読む価値は充分にある。 とりわけ、自身のサービスにおける構造を理解したい場合に、お薦めできるだろう。
Related Articles
- Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
- ZooKeeper – A Reliable, Scalable Distributed Coordination System
- Facebook Articles on HighScalability
- A Look Inside the Force.com Infrastructure by Claus Moldt
ーーーーー
ひさびさの、Facebook スケールアウトに関する記事でした。 Facebook に関する、この種の記事は面白いですね。 いつも、初めて耳にする概念が登場してきます。 今回は Cell で、Salesforce には同種の Pod があるとのことです。 う～ん、スゴイ！ ーーー 
ーーーーー
＜関連＞
Facebook の HBase は、毎月 1350億 メッセージを処理する！
Facebook における 1300万／秒 クエリーの秘密
Facebook のメッセージング･インフラを、再構築する立役者は HBase だ！
Facebook は 20分間で、2.7M Photos／10.2M Comments／4.6M Messages を処理する！
Apache ZooKeeper による分散並列キューの構築
Analysts said the deal makes sense. TweetDeck has "some great technology" and a lot of users, said Wedbush Morgan’s Lou Kerner.
Proponents of OpenStack and other open cloud technologies argue that the open development model is the only way to create and define much needed cloud computing standards.
