Facebookがログストレージ用分散データストアのLogDeviceをオープンソースとして公開

Facebookは、社内使用していた分散ログストレージプロジェクトのLogDeviceを、オープンソースとして公開した。レプリケーションを使用した書き込み機能、堅牢なログストレージ、障害回復機能を提供する。

ログを行うFacebookのアプリケーションの多くは、高い書き込み可用性、堅牢なログストレージを必要とし、パフォーマンスやレイテンシに関する要件もさまざまだ。もうひとつの重要な要件が、ハードウェア障害に耐えられることだ。以前から使用されているScribeというプロジェクトでは、中央ストレージにログを集約することに重点が置かれていたため、データの損失が発生する可能性があった。現在のScribeは、ログストレージバックエンドとしてLogDeviceを使用している。

FacebookではLogDeviceを、自社のデータセンタで、ストリーム処理パイプライン、データベースインデックス更新の配信、マシンラーニングパイプライン、レプリケーションパイプライン、耐久性を持ったタスクキューなどの目的で運用しており、毎秒1TB以上のデータを取り込んでいる。FacebookではLogDeviceクラスタ管理のために、多くのオープンソースツールを構築しているが、現時点では基本的なツールセットを除いて、オープンソースとしては公開されていない。コマンドラインからクラスタ管理が可能なLDShellや、クラスタの統計情報の表示に使用可能な補完的ツールのLDQueryなどが使用されている。

LogDeviceでは、個々のログイベントを画定するために“ログレコード”という概念を使用している。各レコードには、LSN(Log Sequence Number)と呼ばれる、ユニークなIDが割り当てられる。LSNは、“Sequencer”というツールがエポック番号をベースに生成する。エポック番号はZooKeeperに保存されている。ログストアは書き込み専用である。つまり、一度書き込んだレコードは変更できない。多くのログストレージシステムと同様に、LogDeviceは“トリム”、すなわち、時間や領域ベースのポリシに基づいたログのローテーションを行う。オンデマンドでトリムを行うことも可能だ。これ以外、ログの保存期間に関する制限はない。

LogDeviceは、個々のログレコードのコピーを異なるマシンに格納することで、高可用性、特に書き込み時の高可用性を実現している。各レコードは、20～30台のストレージノードに複製することができる。しかしながら、ひとつのログへの書き込み数がスパイクすると、そのコピーを保持するマシンの一部が遅かったり、あるいは使用できないような場合には、それによってスループットが制限されることになる。LogDeviceには、ダウンしているノードを自動的に検出して、新たなレコードの書き込み対象から除外する機能が備えられている。このようなレプリケーションに加えて、消失したコピーを可能な限り早く“再構築”することにより、ハードウェア障害の影響を最小限に抑えている。この再構築では、“障害によって影響を受ける全レコードを毎秒5～10GBの速度で処理可能なレプリケーションファクタ”を実現している。下位ストレージとしてRocksDBを使用するこのキーバリューストアも、Facebookによってオープンソースとして公開されている。

さらに、LogDeviceのユーザが数時間ないし数日前のデータを要求するという、バックフィルを実行していることが明らかになったため、LogDeviceのチームはそのような課題にも対象しなければならなかった。この処理はLogDeviceからログをコンシュームするダウンストリームサービスによって起動されるが、これらのサービスが障害から復帰してログを再処理する必要がある場合に、バックフィルが発生する。このような読み取りスパイクには、特定のレコードを格納するノード群である“ノードセット”のメンバに、読み取り負荷を分散することによって対処している。

LogDeviceは、Apache BookKeeperやApache Kafkaといった、他のログストレージシステムと比較される。Kafkaとの大きな違いとしてあげられるのは、LogDeviceではFacebookのスケールを処理可能にするため、演算処理とストレージが分離されていることだ。LogDeviceはC++で記述されており、GitHubにホストされている。