分散ログストレージシステム - LogDevice

序文

分散システムに取り組んだことがある人なら誰でも、大規模クラスターで高同時実行トランザクションを処理するときに、CAP (一貫性、可用性、およびパーティション耐性) を同時に満たすことは理論的に不可能であることを知っています。もちろん、Google が最近そのような分散システムを実装したと聞いていますが、一般的には確かに非常に困難です。ソーシャルメディアの膨大なログファイルについても、高可用性の確保、継続的なデータ書き込み、レコード順にデータを返すという3つの要件を掲げれば、実現できると思いますか？ FaceBook の LogDevice がそれを実現しました。

[[206398]]

ログとは何か

ログは、一連のシリアル化されたシステム動作を記録する情報です。信頼できる場所に保存できるようにする必要があります。アプリケーションの場合、ログには通常、トラブルシューティングとプログラムの実行状態の表示という 2 つの機能があります。適切なログ記録方法は、問題を特定するための十分な根拠を提供します。データベースなどの一部の複雑なシステムでは、ログをデータのバックアップと同期に使用できます。多くの分散データベースでは、ノード データが同期されるときに、ログ ファイルを通じてデータを復元するために「先行書き込み」ソリューションが使用されます。

ログには一般的に 3 つの特性があります。

1. レコード指向: ログに書き込まれる内容は、バイトではなく、独立した行である必要があります。ログは本質的に問題の最小単位であり、ユーザーはログの全行を読む必要があります。原則として、ログは LSN (ログシーケンス番号) に従って順番に保存されますが、これは必ずしも必要なわけではないため、ログ システムは高い書き込み要件を優先し、書き込みの失敗を許容することができます。

2. ログは本質的に増分的です。つまり、ログは変更されません。つまり、ログ システムの設計は、更新操作によるデータの一貫性の問題を気にすることなく、書き込みと読み取りのターゲットを高く設定する必要があります。

3. ログの保存期間は長く、1 日、1 か月、さらには 1 年になることもあります。つまり、ログ削除ルールは一般的に時間や空間に応じて設定され、固定されたルールを持っています。

仮定してみましょう

分散ログストレージシステムを設計したい場合、どのように設計しますか?

ログ情報を送信して保存する必要があります。安定したデータ交換を実現するために、メッセージミドルウェアとして Kafka を使用できます。

Kafka は実際にはメッセージの公開およびサブスクリプション システムです。

プロデューサーはトピックにメッセージを公開し、コンシューマーはトピックのメッセージをサブスクライブします。トピックに関する新しいメッセージがあると、ブローカーはそのメッセージをサブスクライブしているすべてのコンシューマーに渡します。 Kafka では、メッセージはトピックごとに整理され、各トピックは複数のパーティションに分割されるため、データの管理と負荷分散が容易になります。同時に、負荷分散のために Zookeeper も使用します。

ディスク上の Kafka のストレージコストは O(1) です。通常のサーバーでも、1 秒あたり数十万件のメッセージを処理できます。さらに、分散アーキテクチャであり、Hadoop へのデータの並列ロードをサポートします。

上の図は、ログ データ交換にメッセージ ミドルウェアを使用する典型的なシステム設計アーキテクチャですが、データ ストレージは実装されておらず、データが抽出されて Kafka に送信される方法も説明されていません。

データストレージを実装し、内部処理フローを明確に記述したい場合、どのようなログ処理システムアーキテクチャを採用できますか?ここで私がお勧めするのは、Facebook 内で広く使用されているオープンソースのログ収集システムである FaceBook の Scribe です。さまざまなログ ソースからログを収集し、中央ストレージ システム (NFS、分散ファイル システムなど) に保存して、集中的な統計分析と処理を容易にすることができます。

Scribe の最も重要な機能は、優れた耐障害性です。バックエンド ストレージ システムがクラッシュすると、Scribe はデータをローカル ディスクに書き込みます。ストレージ システムが正常に戻ると、Scribe はログをストレージ システムに再ロードします。

Scribe のアーキテクチャは比較的シンプルで、Scribe Agent、Scribe、ストレージ システムという 3 つの主要部分で構成されています。 Scribe Agent は実際には Thrift Client です。 Scribe は Thrift Client からデータを受信し、構成ファイルに従ってさまざまなトピックからさまざまなオブジェクトにデータを送信します。ストレージ システムは、実際には Scribe の Store です。現在、Scribe は多数のストアをサポートしています。

市場にはすでに多くの分散ログ収集システムが存在しているようですが、なぜ FaceBook が LogDevice を立ち上げる必要があるのでしょうか?そして、FaceBook にはすでに Scribe があるのに、なぜ LogDevice の設計を続けるのでしょうか? Scribe は主にログデータの収集を実装しているためです。完全なログ処理、保存、読み取りサービスではありません。システム設計も比較的堅牢で、ストレージは HDFS に大きく依存しています。使用の過程で、それ自体のニーズを満たすことができない状況が必ずあるはずです。オープンソースの分散ログ収集システムの場合、さまざまなオープンソース コンポーネントを統合して、ログ ストレージ システムの設計要件を共同で満たすことが重要です。 FaceBook のエンジニアたちは、常にイノベーションの精神に取り組んできました。 Apache Cassandra について考えてみましょう。実は当時、HBase などの成熟した NoSQL データベースはすでに存在していましたが、中央ノードなどの設計上の制限が多かったため、FaceBook は新しい分散型設計アーキテクチャを開発しました。初期には疑問視されていたものの、その後も継続的に改良されていきました。これまでのところ、Cassandra はまさに黄金時代を迎えています。