Raft アルゴリズムの原理と CMQ への応用 (パート 2)

CMQにおけるラフトの応用

初期には、rabbitmqをベースにスケーラブルなメッセージミドルウェアCRMQ1.0を構築していました。rabbitmqのGM同期アルゴリズムはパフォーマンスなどの面でボトルネックがあったため、raftアルゴリズムとTencent Cloud CMQをベースにした独自の社内バージョンCRMQ2.0を開発しました。強力な一貫性と高い信頼性を確保しながら、パフォーマンスと可用性が大幅に向上しました。実装では、メッセージが失われないように、プロダクション Confirm + 消費 Ack メカニズムを採用しています。Confirm メカニズムと Ack メカニズムの両方が raft によって保証されています。生成されたメッセージは Raft を通じてエントリに変換され、ほとんどのノードに同期されて送信されます。完了すると、各ノードのステート マシンがエントリを適用し、メッセージの内容をディスクに書き込みます。その後、リーダー ノードは、メッセージが正常に生成されたことを示す Confirm でクライアントに応答します。消費時に、クライアントはリーダー ノードからメッセージをプルします。消費が完了すると、メッセージが消費され、削除できることが Ack コマンドを通じてサーバーに通知されます。Ack 要求が Raft によって同期されると、各ノードが要求を適用し、メッセージは削除され、再度配信されなくなります。詳細なプロセスは以下のとおりです。

製造工程:

1) プロデューサーは、リーダーの Raft モジュールにメッセージを生成する要求を送信します。

2) Raft モジュールはエントリの作成と同期を完了します。

3) ほとんどのノードで永続化され、正常に返された後、エントリはコミット済みとしてマークされます。

4) すべてのノードのステート マシンはログを適用し、実際の生成要求を取得し、メッセージの内容をディスクに書き込み、ApplyIndex を更新します。このステップではブラッシングは必要ありません。

5) リーダーは「確認」でクライアントに返信し、制作が成功したことを通知します。

6) 後でマシンを再起動すると、確認済みのメッセージが失われないように、ラフト ログを通じて生成メッセージが復元されます。

消費プロセス:

1) コンシューマーはリーダーノードからメッセージをプルします。

2) リーダーはメッセージを受信した後、削除されていないメッセージをディスクからロードし、クライアントに配信します。

3) クライアントは処理を完了すると、Ack メッセージを送信し、サーバーにメッセージを削除するように通知します。

4) Ack 要求は、Raft によって同期された後、コミット済みとしてマークされます。

5) 各ノード ステート マシンはログを適用し、メッセージに対応するビットを設定し、それを削除済みに設定して ApplyIndex を更新します。

6) 削除が成功したことをクライアントに通知します。

7) マシンが再起動されると、削除されたメッセージが再度配信されないように、Raft ログを通じて Ack 要求が復元されます。

スナップショット管理:

スナップショット管理はビジネスと密接に関係しています。さまざまなシステムのスナップショットを作成するコストは大きく異なります。CMQ のスナップショットの内容は非常に軽量です。スナップショットの作成には数ミリ秒かかり、平均 5 分ごとに作成されます。各ノードは独立してスナップショットを完了します。実際には、動的スナップショットはメモリ内に保持されます。スナップショットを作成すると、まず動的スナップショットのコピーがコピーされます。次に、処理フローは動的スナップショットの更新を継続し、コピーされたコピーを使用して、実際の処理フローに影響を与えることなくスナップショット ファイルを作成します。スナップショットには以下が含まれます。

1) 用語: スナップショットに対応するエントリの用語 (アルゴリズムを参照)

2) インデックス: スナップショットに対応するエントリのインデックス (アルゴリズムを参照)

3)node_info: エントリー時のクラスタ構成情報。

4) トピック情報: キューごとに 1 つの項目。 CMQ の同じキューで生成されたメッセージは順番に書き込まれ、シャードに保存されるため、最後のシャードのステータス (シャード ファイル名、ファイル オフセット) のみを記録する必要があります。

5)キュー情報: キューごとに 1 つの項目。 CMQ はビットマップを使用してメッセージの削除ステータスを記録し、それをメモリ内に保持し、スナップショットを作成するときにスナップショット ファイルにダンプします。

信頼性: 業界で統一された測定基準は RPO (Recovery Point Objective) であり、これは障害発生時のデータ復旧の整合性の指標を反映します。コミットされたログのみがステート マシンに適用され、raft ログは書き込み時に強制的にディスクにフラッシュされるため、障害の再起動後にスナップショット + raft ログを通じてデータを損失することなくシステムを復元でき、RPO = 0 になります。ただし、セクション 2.7 で説明したように、リーダーに障害が発生すると重複データが生成される可能性があり、この問題は冪等性の保証または重複排除メカニズムによって解決する必要があります。

可用性: 業界の統一された測定標準は RTO (目標復旧時間) であり、これは障害発生時のビジネス復旧の適時性を反映します。フォロワーの障害はシステムに影響を与えません (RTO=0)。リーダーに障害が発生すると、他のノードが自発的に新しいリーダーを選択します。さらに、CMQ のフロントエンドには自動再接続機能があります。接続が切断されると、自動的に新しいリーダーを検索し、システムの非使用時間を大幅に短縮します。現在、CMQ で設定されている選出タイムアウトは 2 秒から 4 秒です。選出の競合を考慮しない場合、RTO の上限は 4 秒です。

CMQ では、リーダーはハートビートによってフォロワーとのパーティション化されているかどうかを判断します。パーティションが検出されると (ほとんどのノードの最後のハートビート応答時間が現在から 2 秒以上後)、フロントエンドの接続がアクティブに切断されます。フロントエンドが検出されると、自動的に新しいリーダーを探します。この期間中、クライアントのリクエストはタイムアウトになります。新しいリーダーに接続した後、クライアントは以前にタイムアウトしたタスクを再試行し、後続のリクエストは通常​​の状態に戻ります。

4つのRaftアルゴリズムのパフォーマンス最適化

Raft アルゴリズムのパフォーマンスのボトルネックには、主に次の 2 つの側面があります。

1) 各ログが書き込まれた後、成功を返すためにディスクをフラッシュする必要があり、ディスクのフラッシュは比較的時間のかかる操作です。

2) アルゴリズムの制限により、すべてのリクエストはリーダーによって処理され、すべてのノードがサービスを提供することはできません。

上記の 2 つの問題に対処するために、次の最適化を行いました。

1) バッチ処理: リクエストの数が多い場合、すべてのログ エントリがディスクにフラッシュされるわけではありません。代わりに、一定量のログが蓄積され、バッチでディスクにフラッシュされるため、フラッシュの回数が減ります。同様に、Follower に同期するときにもバッチ同期が使用されます。ログを受信した後、Follower はログをバッチでディスクに書き込みます。

2) マルチ Raft: プロセス内で複数の Rafft インスタンスが同時に実行され、マシン間で複数の Rafft グループが形成されます。クライアント要求は異なるグループにルーティングされるため、マルチマスターの読み取りと書き込みが実現され、同時実行パフォーマンスが向上します。リーダーを異なるマシンに分散することで、システム全体の使用率が向上します。

3) 非同期 RPC: ログ同期プロセスでは同期 RPC が使用されます。一方が処理中の場合、もう一方は待機することしかできず、パフォーマンスが低下します。リーダーが送信し、フォロワーが同時に処理できるように、非同期アプローチを使用します。送信処理中、リーダーは送信ウィンドウを維持します。確認する RPC の数が上限に達すると、送信が停止します。ウィンドウ値の上限は次のとおりです。

信頼性も高い RabbitMQ (マルチコピー同期ディスクフラッシュ) とのパフォーマンス比較では、同じストレス テスト シナリオでは CMQ は RabbitMQ よりも約 4 倍高速です。

メッセージ サイズが 1 KB の場合の TS60 マシンのパフォーマンス データは次のとおりです。

テストでは、CMQ は単一の Raft グループを使用してテストの公平性を確保します。監視により、CPU、メモリ、ネットワーク カードがボトルネックに達していないことが示されています。システムのボトルネックはディスク IO です。iostat は、w_await が svctm よりもはるかに大きいことを示しています。主な理由は、ディスクのフラッシュに時間がかかり、書き込み操作が待機状態になるためです。

実際の運用環境 CMQ では、ラフト グループとディスクをバインドして、ラフト グループ間のディスク分離を実現します。これにより、ディスクの連続的な読み取りと書き込みが保証される一方で、マシンの CPU、メモリ、ネットワーク カードなどのリソースが最大限に活用されます。

5つの汎用Raftライブラリ

CMQ は Raft アルゴリズムを完全に実装し、多くの詳細な問題を解決します。分散システム設計の複雑さを考慮すると、開発者が業務関連部分のみに集中すれば、開発の難易度は大幅に下がり、システムの品質も向上します。そこで、CMQのラフト部分をライブラリとして分離し、ユーザーがそれを使って強固な一貫性と高可用性を備えた分散システムを構築できるようにしました。現在、ライブラリのベースラインバージョンが開発され、部門で使用されています。検証後、徐々により多くの企業に公開される予定です。

VI. 結論

メッセージミドルウェアは通常、高信頼性バージョンと高性能バージョンの 2 種類に分けられます。 CMQ は、金融グレードの信頼性の高い分散メッセージ ミドルウェアであり、raft を使用してメッセージの信頼性と損失の防止を保証します。同時に、競合製品と比較してパフォーマンスと使いやすさが大幅に向上しています。さらに、当社が独自に開発した高性能バージョンのメッセージミドルウェア ckafka も Tencent Cloud でリリースされており、kafka バージョン 0.09～0.10 クライアントと完全に互換性があります。CKafka の詳細な技術紹介については、以降の技術記事にご注目ください。

Raft アルゴリズムはリーダーのステータスを重視し、選出とログの同期はすべてリーダーを中心に行われます。リーダーはすべてのリクエストを処理する責任があり、システムの強力な一貫性を保証します。リーダー選出とログ同期アルゴリズムは、損失のないデータの信頼性を保証します。さらに、上記の手順では大部分の通常の接続のみが必要であるため、システムの可用性が大幅に向上し、少数のマシン障害の影響を受けません。ただし、すべてのリクエストはリーダーによって処理され、スレーブノードのリソースは十分に活用されていません。現在、Google の Spanner はスレーブノードからの読み取りをすでにサポートしており、この点については今後さらに調査を進めていく予定です。 Raft アルゴリズムは理解しやすく、設計も簡単なので、将来的にはさらに多くの分散システムで使用されるようになると思います。

オリジナルリンク: https://cloud.tencent.com/community/article/937437

[この記事は51CTOコラムニスト「テンセントクラウドテクノロジーコミュニティ」によるオリジナル記事です。転載の許可を得るには51CTOを通じて原作者に連絡してください]

この著者の他の記事を読むにはここをクリックしてください