about haystack
DESCRIPTION
Facebookが開発した写真ストレージ "Haystack" の説明プレゼンです。本家の説明文を和訳してるだけです。ソースURL: http://www.facebook.com/note.php?note_id=76191543919TRANSCRIPT
About HaystackTomohiro MITSUMUNE
2009/11/26
2009年12月2日水曜日
Agenda
• about Facebook
• Old Photo Store system
• Haystack Store system
2009年12月2日水曜日
• 世界最大の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日水曜日