About HaystackTomohiro MITSUMUNE

2009/11/26

2009年12月2日水曜日

Agenda

• about Facebook

• Old Photo Store system

• Haystack Store system

2009年12月2日水曜日

Facebook

• 世界最大のSNS(ユーザ数: 250,000,000)

• 来年1月から日本法人

2009年12月2日水曜日

Photo App in Facebook• 150億枚以上の写真がアップロード

• アップロードされた写真から4種類のサムネイルを生成する

• 計600億枚、1.5PB

• 1週間の増加率は2億2千万、25TB

• ピーク時には秒間550,000枚がアップ

2009年12月2日水曜日

Old Facebook System

2009年12月2日水曜日

NFS Photo Infrastructure• Upload

• ユーザのアップロード写真を受けとり、縮小、NFSに保存

• Photo serving

• 写真へのHTTPリクエストを受け取り、NFS

から引っ張ってくる

• NFS storage

• 業務用ストレージの上の構築2009年12月2日水曜日

NFS Photo Infrastructure

• 画像は独立したファイルとして保存

• ディレクトリの名前空間やiノードに起因して、莫大なメタデータが発生

• NFSのキャッシュ能力を遙かに超えてるため、リクエストがmultiple I/O

Operationになる

2009年12月2日水曜日

NFS Photo Infrastructure

• そのため、NFSのメタデータのオーバーヘッドがインフラ全体のボトルネックとなる

• だからCDNに依存してた

2009年12月2日水曜日

Additonal Optimization• Cachr

• Facebookのプロフィール画像をキャッシュするサーバ層

• NFS file handle cache

• NFSでオーバーヘッドの原因となるメタデータのいくつかを削除して、photo servingにデプロイ

2009年12月2日水曜日

New Facebook System

2009年12月2日水曜日

Haystack Photo Infrastructure

• photo serving と storage を1層にマージ

• HTTPベースの写真サーバ

• オーバーヘッドとなる不必要なメタデータを削除

• リードI/Oを実ファイルのみにする

2009年12月2日水曜日

Haystack Photo Infrastructure

• HTTP Server

• Photo Store

• Haystack Object Store

• Filesystem

• Storage

2009年12月2日水曜日

Storage

2009年12月2日水曜日

Storage

• 一般的な2Uのブレードサーバ

• 2 x quad-core CPUs

• 16GB - 32GB メモリ

• ハードウェアRAIDコントローラ(256MB

- 512MBのNVRAM cache付き)

• 12 + 1 TB SATA HDD

2009年12月2日水曜日

Storage• 利用可能容量は1サーバ約10TB

• RAID-6

• ストレージコストを下げたまま、冗長性と読み込み性能が得られる

• 書き込みはNVRAM上のwrite-backキャッシュでカバー

2009年12月2日水曜日

Storage

• 読み込みはほとんどがランダムアクセスなのでNVRAMキャッシュは完全に書き込みに回せる

• ディスクキャッシュは無効

• クラッシュや停電時、データ一貫性を保証するため

2009年12月2日水曜日

Filesystem

2009年12月2日水曜日

Filesystem

• 10TB上に1つのファイルシステムを構築

• inode構成

• ファイルシステム構成は2種類

• ブロックベース

• エクステントベース

• HaystackはエクステントベースのXFS2009年12月2日水曜日

Block based filesystem

• 大きいファイルだと、複数のアドレスブロックを横断して実ファイルにアクセスすることになる

• シングルリードでも複数リードに

2009年12月2日水曜日

Extent based filesystem

• 近接する範囲のブロック間のマッピングを保持

• ファイルが分断され、ブロック構成が近接していないとブロックマップが肥大化

• あらかじめ十分な領域を割り当てることでフラグメンテーションが緩和

2009年12月2日水曜日

Haystack Object Store

2009年12月2日水曜日

Haystack Object Store• Needleという保存されたオブジェクトを表示するオブジェクトストアで構成されたシンプルなログデータ

• 2ファイルから構成

• Haystack Store file (実ファイル)

• インデックスファイル

2009年12月2日水曜日

Haystack Store File

・最初の8KBはスーパーブロック・その下にニードルがあり、ヘッダ・データ・フッタで構成

2009年12月2日水曜日

Needles

2009年12月2日水曜日

Needles

• <Needle Offset, Key, Alternate Key, Cookie>の組で一意に識別できる

• Offsetはhaystack storeの中でのニードルオフセット

• Keyは重複OK

2009年12月2日水曜日

Index

2009年12月2日水曜日

Index• 各ニードルごとに対応するインデックスファイルがある

• 特定ニードルを探すための最小限のメタデータを持つ

• 大きなhaystack store fileを横断することなしにメモリからニードルのメタデータをロードを可能にする

2009年12月2日水曜日

Haystack Write Operation

• 書き込みはNeedleがStore fileに追加されるのに同調して動作

• Needleがコミットされた後、インデックスレコードが書き込まれる

• パフォーマンス重視のためインデックス書き込みは非同期

2009年12月2日水曜日

Haystack Write Operation

• インデックスファイルはトラブル時のリカバリー範囲を限定するため、定期的にflush

• 上書き禁止なので修正は同じ<Key,

Alternate Key, Cookie>の組でデータ追記

• Needleのオフセットを見て最新を取得

2009年12月2日水曜日

Haystack Read Operation

• Needle offset, Key, Alternate Key, Cookie, Data sizeがパラメータ

• KeyとAlaternate KeyとCookieが一致すれば読み込み成功

2009年12月2日水曜日

Haystack Delete Operation

• フラグフィールドに ‘deleted’ ビットをセットするだけ

• 削除されたNeedle領域は再利用されない

• 再利用するには圧縮する必要がある

2009年12月2日水曜日

Photo Store

2009年12月2日水曜日

Photo Store

• HTTPリクエストの受付

• 受け付けたリクエストに対応するHaystack Store Objectを読み込み / 書き込み

2009年12月2日水曜日

Photo Store

• 写真取得時のI/O量を最小にするため、すべての写真のインデックスのオフセットをインメモリで持つ

• 写真を探すためのメタデータのみで構成する

• オープンソースのGoogle Sparse Hashを使ってインデックスを小さく

2009年12月2日水曜日

Photo Store

• 写真がアップされると64bitのIDが割り当てられ、4種類のサイズに縮小

• 縮小された写真は同じCookieと64bit

キーを持つ

• 論理イメージサイズ(large, medium, small,

thumbnail)はAlternateキーへ

2009年12月2日水曜日

in-memory Index

2009年12月2日水曜日

Photo Store Write/Modify Operation

• haystack に写真データを書き込み、インメモリインデックスの更新

• 同じキーを持つレコードがあるなら写真の変更とインデックスのオフセットを変更した写真の場所を示すように

2009年12月2日水曜日

Photo Store Read Operation

• haystack id, photo key, サイズ, cookieがパラメータとして渡される

• photo keyをベースにインメモリインデックスを探しNeedleオフセット取得

2009年12月2日水曜日

Photo Store Delete Operation

• Haystack Delete Operationが呼ばれた後、インメモリインデックスは写真の削除を示すためオフセット値を0に設定

2009年12月2日水曜日

Compaction

• 削除・重複(同じキーを持つ)したNeedle

に使われている領域を再利用するための操作

• 対象ニードルをコピーすることで新しいhaystackを作成

2009年12月2日水曜日

HTTP Server

2009年12月2日水曜日

HTTP Server

• libeventを使ったシンプルなevhttpサーバ

• 各スレッドが1度に1リクエストを扱うマルチスレッド

• 負荷は大半がI/O boundなので気にするほどでない

2009年12月2日水曜日

まとめ• HTTPベースのオブジェクトストア

• 膨大なファイルを凝集することで生じるメタデータのオーバーヘッドを削除

• メタデータを小さくし、インメモリインデックスへ各オブジェクトの場所を保存することで実現

2009年12月2日水曜日

Thank you for your kind attention

2009年12月2日水曜日

References

• http://www.facebook.com/note.php?note_id=76191543919

• http://www.niallkennedy.com/blog/2009/04/facebook-haystack.html

• http://perspectives.mvdirona.com/2008/06/30/FacebookNeedleInAHaystackEfficientStorageOfBillionsOfPhotos.aspx

2009年12月2日水曜日