Facebookのストレージ技術者：家族のスナップ写真を精査して「温かいBLOB」を見つける

Facebook は、ニアライン ストレージの RAID とレプリケーションを廃止し、代わりに分散消去コーディングを使用して「ウォーム BLOB」と呼ぶものを分離しました。

翻訳をお願いします:

• BLOB — Binary Large OBject — Facebook ユーザーの写真、ビデオなど。
• ウォームデータ — 保存する必要があり、ホットデータよりもアクセス頻度は低いものの、アーカイブデータやコールドデータよりもアクセス頻度が高いデータです。通常、保存から1週間以上経過したデータです。もちろん、ホットBLOBはより頻繁にアクセスされます。
• 消失訂正符号 — 計算されたパリティ値（リード・ソロモン符号）をバイト列に追加することで、エラーによって文字列の一部が削除または歪んだ場合でも、文字列を復元できるようにします。通常、RAIDよりもデータ保護の効率が高く、使用するスペースも少なくなります。

Facebook特有の問題は、ユーザーデータが主に3種類あり、それぞれにメタデータが付随しているため、膨大なストレージ容量を必要とすることです。Facebookの主要かつ最もアクセス数の多いデータセットは、ユーザーのタイムラインに1週間以内に投稿された最新の投稿です。これらの投稿は、ユーザーの「友達」から頻繁にアクセスされます。

このデータには Haystack ストレージ システムが使用されます。このシステムは、トリプル レプリケーションを使用してデータを保護し、メタデータの計算が実行されると、可能な限り単一のディスク アクセスで、常にデータにアクセスでき、迅速にアクセスできるようにします。

データは古くなるにつれてアクセス頻度が減り、ホットからホットへと変化しますが、実際に必要な時には依然として高速アクセスが求められます。問題は、これらのデータがどんどん増え続けることです。例えば、今年1月末の時点で、Facebookは4000億枚以上の写真を保存していました。

テラバイトあたりの IO 数を計算すると、その IO 密度はホット データよりもはるかに低いことがわかります。つまり、トリプル リピート スキームを使用せずに保存でき、ディスク、ホスト、ラックの障害から保護されながら、許容できるほど高速なアクセスが可能です。

Facebookのエンジニアたちは、この一連のWarm BLOBを保存するために、新しいストレージシステム「f4」を構築しました。エンジニアによる論文では、「f4は、Warm BLOBの実効レプリケーション係数を下げながらも、フォールトトレランスを維持し、低いスループット要求にも対応できる新しいシステムです」と説明されています。

Facebookのエンジニアはこう語る。

[f4]はリード・ソロモン符号を使用し、ブロックを複数のラックに配置することで、単一データセンター内のディスク、マシン、ラックの障害に対する耐性を確保します。また、広域ではXOR符号を使用することで、データセンターの障害に対する耐性を確保しています。f4はFacebookで19ヶ月以上稼働しており、現在65PBを超える論理データを保存し、53PBを超えるストレージ容量を節約しています。

BLOBは、集約されたファイルシステムメタデータとともに約100GBの論理ボリュームに集約されます。BLOBは、データファイル、インデックスファイル、ジャーナルファイルで構成されます。インデックスファイルは、ストレージマシンのメモリ内検索構造のスナップショットです。ボリュームがいっぱいになると、ロックされ、作成は許可されません。

ボリュームは1つのデータセンターとセルに保存されます。セルは15台のホストからなるラック14台で構成され、ホストあたり4TBドライブ30台を搭載しています。各ボリューム／ストライプ／ブロックは、異なる地理的リージョンにあるバディボリューム／ストライプ／ブロックとペアになっています。Facebookは、バディボリューム／ストライプ／ブロックのXORを第3のリージョンに保存します。この仕組みにより、3つのリージョンのいずれかに障害が発生した場合でも保護されます。

企業は一般的に、ニアラインデータをこのようなストレージ方式に移行する必要があるでしょうか？Facebookほどのデータ量、成長速度、不変性を備えているわけではないため、その必要性は低いでしょう。

Facebook の Mr BLOBby f4 スキームの詳細については、こちら (17 ページの PDF) をご覧ください。®