先週 Facebook が分散ログ管理システムの共有を決定したことを受けて、大量のログの管理に苦労しているシステム管理者は、新しい「友達」に「いいね！」をしたいと思うかもしれません。
1 つのサイトだけを運営している場合、Zucker の「LogDevice」コードは適していない可能性があります。これは、Facebook が 10 か所のデータ センターを管理する方法であり、何か問題が発生した場合に The Social Network™ がそれらのログを同期させる方法も含まれます。
おそらく最も印象的な数字はその操作です。Facebook は、障害発生後、LogDevice がログを再構築して「影響を受けるすべてのレコードのレプリケーション係数を 5 Gbps ～ 10 Gbps で完全に復元できる」と主張しています。
投稿で説明されているように、大規模なログ記録には、レコード ストレージの可用性と耐久性を高めながら、「それらのレコードの繰り返し可能な全体的な順序」を維持するという、特に厄介な 2 つの問題があります。
これを実現するために必要な仕様は次のとおりです。
- LogDevice はレコード指向であり、バイトではなく、ログに書き込まれる最小の分割できない単位である完全なレコードです。同社によれば、これにより「障害発生時の書き込み可用性が向上する」とのことです。
- ログは追加のみ可能であり、ログ レコードを変更することはできません。
- ログ サイズを管理するために、ファイルは時間ベースまたはスペースベースの保持ポリシーに従ってトリミング可能です。
Facebook が必要とするスケールを実現するための鍵の 1 つは、ログ シーケンスをレコード自体から切り離すことです。つまり、シーケンサーは、ストレージ ノード上または独自のノード上で、別のプロセスとして実行されます。
シーケンス自体は単一のデータではなく、エポックとエポック内のオフセットを含むタプルです。「エポックストアは、ログごとに1つずつ、めったに増加せず、決して後退しないことが保証された永続的なカウンターのリポジトリとして機能します。現在、LogDeviceのエポックストアとしてApache Zookeeperを使用しています。」
LogDeviceはシーケンス処理とオブジェクトストレージを分離します
ログ オブジェクトのストレージに関しては、LogDevice はレコードをストレージ ノードにランダムに割り当てます。そのため、たとえば、特定のサーバーからのログがすべて同じディスクに保存されることはなく、ディスクに障害が発生してもすべてが失われることはありません。
高速な再構築が重要なのは、まさにこの点です。もしレコードが復元を待っている状態で2度目の障害が発生したらどうなるでしょうか？5Gbpsから10Gbpsへの再構築は、このような事態を回避するために設計されています。
当然のことながら、集中化されたログ記録はすべて、まずローカルログから取得されます。そのため、LogDevice は LogDB と呼ばれる書き込み最適化ストアを導入しています。投稿には、「ディスクシーク回数を最小限に抑え、制御された状態に保ち、ストレージデバイス上の書き込みと読み取りの IO パターンをほぼシーケンシャルに保つように設計されています」と記載されています。
Facebook は、最終目標は LogDevice を今年中にオープンソース化することだと述べている。®
