分散システムの中核 - ログ

ログとは何ですか?

ログは、時系列順に追加された、完全に順序付けられたレコードのシーケンスです。実際、それは特別なファイル形式です。ファイルはバイト配列であり、ログはデータの記録です。ただし、ファイルに対して、各レコードは相対的な時系列順に並べられます。ログは最も単純なストレージ モデルであると言えます。一般的には左から右へ読みます。たとえば、メッセージ キューは通常、ログ ファイルに線形に書き込まれ、コンシューマーはオフセットから順番に読み取ります。

[[212153]]

ログ自体の固有の特性により、レコードは左から右に順番に挿入されます。つまり、左側のレコードは右側のレコードよりも「古い」ことになります。つまり、システムクロックに依存する必要はありません。この機能は分散システムにとって非常に重要です。

ログの適用

データベースにおけるログの適用

ログがいつ表示されたかはわかりません。おそらく概念が単純すぎるためでしょう。データベース分野では、MySQL の REDO ログなど、システムがクラッシュしたときにデータとインデックスを同期するためにログがより多く使用されます。 REDO ログは、システムがクラッシュしたときにデータの正確性と整合性を確保するために使用されるディスクベースのデータ構造です。先行書き込みログとも呼ばれます。たとえば、トランザクションの実行中は、最初に REDO ログが書き込まれ、その後に実際の変更が適用されます。これにより、クラッシュ後にシステムが回復したときに、REDO ログに従って再生してデータを復元できます (初期化プロセス中は、この時点ではクライアント接続はありません)。基本的にすべてのデータベース操作レコードがログに書き込まれているため、ログを使用してデータベース マスターとスレーブを同期することもできます。マスターとスレーブの同期を実現するには、ログをスレーブに同期し、スレーブで再生するだけです。他の多くの必要なコンポーネントもここで実装できます。 REDO ログをサブスクライブすることですべてのデータベースの変更を取得できるため、監査、キャッシュ同期などのカスタマイズされたビジネス ロジックを実装できます。

分散システムにおけるログの応用

分散システム サービスは本質的に状態の変化に関するものであり、これは状態マシンとして理解できます。一貫した入力が与えられた 2 つの独立したプロセス (システム クロック、外部インターフェイスなどの外部環境に依存しない) は、一貫した出力を生成し、最終的に一貫した状態を維持します。ログは、その固有の順序性により、システム クロックに依存せず、順序立った変更の問題を解決するために使用できます。

この機能を使用することで、分散システムで発生する多くの問題を解決できます。たとえば、RocketMQ では、プライマリ ブローカーがクライアントからのリクエストを受信し、ログを記録し、それらをスレーブにリアルタイムで同期します。スレーブはそれらをローカルで再生します。マスターに障害が発生した場合、スレーブは書き込み要求を拒否し、読み取り要求の処理を継続するなど、要求の処理を継続できます。ログはデータを記録するだけでなく、SQL ステートメントなどの操作を直接記録することもできます。

ログは一貫性の問題を解決するための重要なデータ構造です。ログは操作シーケンスのようなもので、各レコードは命令を表します。たとえば、広く使用されている Paxos プロトコルと Raft プロトコルは、ログ上に構築された一貫性プロトコルです。

メッセージキューでのログの適用

ログはデータの流入と流出を処理するのに便利に使用できます。各データ ソースは独自のログを生成できます。データ ソースは、イベント ストリーム (ページのクリック、キャッシュ更新リマインダー、データベース バイナリ ログの変更) など、さまざまな側面から取得できます。ログをクラスターに保存できます。サブスクライバーは、オフセットに従ってログの各レコードを読み取り、各レコードのデータと操作に基づいて独自の変更を適用できます。

ここでのログはメッセージ キューとして理解でき、非同期分離と電流制限の役割を果たすことができます。なぜデカップリングするのですか?なぜなら、消費者と生産者にとって、両者の役割の責任は非常に明確だからです。誰がダウンストリームまたはアップストリームであるかを気にすることなく、メッセージの作成と消費を担当します。データベースからの変更ログであろうと、イベントであろうと、どちらか一方を気にする必要はまったくありません。関心のあるログとログ内のすべてのレコードにのみ注意を払う必要があります。

データベースの QPS は一定であり、上位層アプリケーションは一般的に水平方向に拡張できることがわかっています。このとき、ダブル 11 などの突然のリクエスト シナリオが発生した場合、データベースは処理できなくなります。次に、メッセージ キューを導入し、データベースの各操作をログに書き込むことができます。これらのログ レコードを消費し、データベースに適用する役割は別のアプリケーションが担います。データベースがダウンした場合でも、復元されると最後のメッセージの位置から処理を続行できます (RocketMQ と Kafka はどちらも Exactly Once セマンティクスをサポートしています)。プロデューサーの速度がコンシューマーの速度と異なっていても、影響はありません。ここでログはバッファリングの役割を果たします。すべてのレコードをログに保存し、定期的にスレーブ ノードに同期できます。この方法では、ログの書き込みがマスターノードによって処理されるため、メッセージバックログ容量が大幅に向上します。ここでは 2 種類の読み取り要求があります。 1 つはテール読み取りで、消費速度が書き込み速度に追いつくことを意味します。この種の読み取りはキャッシュに直接実行できますが、もう 1 つは書き込み要求に遅れをとるコンシューマーです。この種の読み取りはスレーブ ノードから読み取ることができます。このように、IO 分離と、ページキャッシュやキャッシュの事前読み取りなど、オペレーティング システムに付属するいくつかのファイル戦略により、パフォーマンスを大幅に向上させることができます。

水平スケーラビリティは分散システムにおいて非常に重要な機能です。機械を追加することで解決できる問題は、問題ではありません。では、水平方向に拡張できるメッセージ キューをどのように実装すればよいのでしょうか?単一マシンのメッセージ キューの場合、トピックの数が増えるにつれて、IO、CPU、帯域幅などが徐々にボトルネックになり、パフォーマンスが徐々に低下します。では、ここでパフォーマンスを最適化するにはどうすればよいでしょうか?

1. トピック/ログのシャーディング。基本的に、トピックに書き込まれるメッセージはログ レコードです。書き込み回数が増えると、1 台のマシンが徐々にボトルネックになります。このとき、1 つのトピックを複数のサブトピックに分割し、各トピックを異なるマシンに割り当てることができます。このように、大量のメッセージを持つトピックはマシンを追加することで解決でき、一方で、少量のメッセージを持つトピックは同じマシンに割り当てるか、分割しないようにすることができます。

2. グループコミット。たとえば、Kafka のプロデューサー クライアントがメッセージを書き込む場合、最初にローカル メモリ キューに書き込み、次に各パーティションとノードに従ってメッセージを集約し、バッチで送信します。サーバー側またはブローカー側では、この方法を使用して、最初にページキャッシュに書き込み、その後定期的にディスクをフラッシュすることもできます。業務に応じて洗浄方法を決定することができます。たとえば、金融ビジネスでは同期フラッシュ方式を採用する場合があります。

3. 無駄なデータのコピーを避ける

4.IO分離

結論

ログは分散システムで非常に重要な役割を果たし、分散システムのさまざまなコンポーネントを理解するための鍵となります。理解が深まるにつれ、Zookeeper、HDFS、Kafka、RocketMQ、Google Spanner など、多くの分散ミドルウェアがログに基づいて構築されていることがわかります。Redis、MySQL などのデータベースでも、マスターとスレーブはログの同期に基づいています。共有ログシステムを利用することで、ノード間のデータ同期、データ順序の問題（一貫性の問題）の同時更新、永続性（システムがクラッシュしたときに他のノードを通じてサービスを継続する機能）、分散ロックサービスなど、多くのシステムを実装できます。実践と多くの論文を読むことで、より深い理解が得られると信じています。