大規模ウェブサイトのベストプラクティス －eBayでの事例－

分量がめちゃめちゃ多かったので、あまりメモってない ^^;

ほとんど「大規模サイト構築のノウハウ全部見せます！－全部で20以上あるよ！－」みたいなノリだったので、とても全部メモることはできなかった。プレゼン資料欲しいです。

eBayシステムのプロファイル概略

• トランザクションデータは2ペタバイト
• DWH用データは50ペタバイト
• 1日あたり48億回のSQL実行

ペタバイトとか、もう多いか少ないかもわからん。

大規模システムの原則

ということで、eBayのシステム構築の原則。

• Partition Everything
• Asynchrony Everywhere
• Automate Everything
• Remember Everything Fails
• Embrace Inconsistency

なんだか清々しいです。

Partition Everything

分割方法は、データ、負荷、使用方法の特徴など、色々なものがあげられる。分割の動機としては…

• Scalability
• Availability
• Manageability
• Cost

このような感じ。PartitionとAvailabilityとは、Partitionによって故障箇所を局所化することでAvailabilityを向上できる、という点で関連する。PartitionとCostとは、Partitionによって問題を細分化することで、price/performance比がベストの点を選択できるようになる、という点で関連する。特に、Availabilityを重視している印象を受けた。

eBayでは、いくつかの方法でシステムを分割している。

■機能による分割（処理）

• Selling
• Search
• ViewItem
• Bidding
• Checkout
• Feedback

■機能による分割（データ）

• User
• Item
• Transaction
• Product
• Account
• Feedback

■水平的な分割

• ノード分割＋ロードバランシング
• データをアクセスパスにしたがって分割（RDBのパーティションのことだと思う）

また、Partitionのため、セッションステートはアプリケーションティアに保持しないようにしている。CookieやURL、DBに持っているらしい。この辺は王道。

Asynchrony Everything

非同期化のメリットは…

• ピークロード（最大負荷）ではなくアベレージロード（平均負荷）をターゲットにリソースを配分することができる点
  
• ユーザーが許容可能な時間を越えて、リクエストを処理することができる点
  

# 他にもいくつかメリットがあったけど、個人的に重要だと思ったのだけなんとかメモ ^^;

非同期化の方法には、キューイングやマルチキャストメッセージがある。

eBayで採用しているキューでは順序性は保証していないが、メッセージ自体にはデータは入れず、イベント通知を受けた側がその時点で正しいデータを読みに行く（Read Back）ことで整合性の取れた処理を行えるようにしているらしい。

マルチキャストメッセージは、商品情報などのデータがアップデートされた際に、サーチエンジンのインデックス更新を通知する場合などに使われている。Feed Daemonというプロセスが定期的にデータ更新をポーリングしており、更新があった場合（eBayの場合、ほぼ確実にあると思うが）に各サーチエンジンにマルチキャストメッセージを送信する、という形を取っている。

Automate Everything

興味深い例として、ユーザーの振る舞い（サイト上でどのように行動したか）情報を収集し、それに応じてシステムを最適化する、という一連のアクティビティを自動化している例が紹介された。

収集したデータをもとにメタデータを更新し、システムがその振る舞いを変えるところまで自動化されているのが面白い。データ収集や、分析のネタ作りの自動化くらいまでは結構やってると思うんだけど、ここまでやっているのは珍しい。いいアイデアのヒントをもらった。

Remember Everyghint Fails

システム上のすべての変更は、すべてもとに戻せるようにしているらしい。これは、データだけではなく、システム機能に対する変更にもあてはまるようで、すべての機能はコンフィグでON/OFFが切り替えられるそうだ。データ更新に対するロールバックをどう扱っているかに興味があるが、それは次の「Embrace Inconsistency」で扱われるトピックなのだろう。

また、Graceful Degrationも可能らしい。まぁ、このレベルだとある意味当たり前と言える。

Embrace Inconsistency

ここで、満を持して（？）CAP Theoremが登場。このセミナーで3回目。はじめて、CAPの正確な定義がスライド上に登場する。が、はやすぎてメモれず ;-(

• C : all clients see the same data even if system ...
• A : all clients will get a response even if system failure exist...
• P : 時間切れ ;-(

# おそらく、AmazonのCAPの定義と大差ないはず。でも、誰か知ってたら教えてください… ;-(

さて、ここでの基本的な主張は、もうおなじみ「Consistencyは"あり"か"なし"かの2者択一ではなく、Immediate ConsistencyとNo Consistencyの間に多数のConsistencyレベルがスペクトラムのように存在する」というもの。

-----------------------------------------------------------

   Immediate <------- Eventually -------> No Consistency

 Bids/Purchase         Search Engine/            Preferences

                              Billing System

-----------------------------------------------------------

金融システムにおいてすら、必ずしもImmediate Consistencyが必要とは限らない。ちなみに、eBayでは分散トランザクションはまったく使っていない（これが噂のTransactionlessか）。そのかわり、DB操作の順序を厳密に決定することで、システム全体の整合性を高めている。

# ステートマシンを使っている、という発言もあったけど、分析に使っているんだろうか？

最後にもう一度、重要なことを繰り返す。

• Partition Everything
• Asynchrony Everywhere
• Automate Everything
• Remember Everything Fails
• Embrace Inconsistency

清々しいですね。

雑感

このセミナーで一番中身が濃かったのではないだろうか。大規模システム構築のパターンとして、本が一冊出せそうなくらいの内容だった。それだけにメモも難しく、セミナー資料の公開が待たれるところだ。

目次：
QCon Tokyo 2009に行ってきた