Kafkaのアーキテクチャと高可用性メカニズムの図、アリババとテンセントはどちらもそれを使用しています。わからない場合は私に聞いてください

[[282170]]

今日はまずKafkaについてお話しましょう。 Hbase に注目している人はあまり多くないようですから、Hbase については割愛して、みんなが一番気に入っているものについてお話ししたいと思います。

1. Kafka アーキテクチャ図

Kafka アーキテクチャには、複数のプロデューサー、複数のブローカー、および複数のコンシューマーが存在します。各プロデューサーは複数のトピックに対応できますが、各コンシューマーは 1 つの ConsumerGroup にのみ対応できます。

Kafka アーキテクチャ全体は ZK クラスターに対応しており、クラスター構成の管理、リーダーの選出、コンシューマー グループの変更時の再バランス調整を行います。

複雑な分散システムの場合、豊富な経験と強力なアーキテクチャ能力がなければ、システムをシンプルで保守しやすいものにすることは困難です。ソフトウェアのライフサイクルの 70% は事後メンテナンスにかかっていることは周知の事実であり、システムの保守性は極めて重要です。 Kafka はビッグデータ分野で事実上の標準になる可能性がありますが、その大きな理由は、操作と保守が非常に便利で簡単であることです。今日は、Kafka がどのように運用と保守を簡素化するかを見ていきます。

Kafka は、メッセージが失われないように複数のコピーを使用します。複数のコピーには、Kafka のレプリケーション メカニズムが関係します。非常に大規模なクラスターでは、ある時点でディスクに障害が発生したり、別の時点で CPU 負荷が高くなったりして、さまざまな問題が発生することがあります。複数のコピー間のレプリケーションのフォールト トレランスを完全に自動化する場合は、いくつかの考慮事項とトレードオフを行う必要があります。運用と保守で直面する複雑さを説明するために例を見てみましょう。 Kafka には ISR セットがあることは誰もが知っています。まずこの概念について説明しましょう。

Kafka は完全に同期でも完全に非同期でもなく、ISR メカニズムです。

1. リーダーは、基本的に自分と同期しているレプリカのリストを維持します。このリストは ISR (同期レプリカ) と呼ばれます。各パーティションには ISR があり、リーダーによって動的に管理されます。

2. フォロワーがリーダーより大幅に遅れている場合、または一定期間データ複製要求を開始しない場合、リーダーはフォロワーを ISR から削除します。

3. ISR 内のすべてのレプリカがリーダーに ACK を送信すると、リーダーはコミットします。そうして初めて、プロデューサーはリクエスト内のすべてのメッセージがコミットされたとみなすことができます。

このメカニズムでは、プロデューサーが 1 つのリクエストで送信するメッセージが多すぎて、フラワーがリーダーより大幅に遅れてしまったらどうなるでしょうか。フォロワーが ISR に出入りし続けると、パフォーマンスに影響しますか?このような状況に警報を追加すると、警報集中砲火が発生する可能性があります。アラームを追加しないと、ブローカーがハングアップしたり、IO パフォーマンスや GC の問題によりブローカーがスタックしてリーダーから大幅に遅れをとったりする場合、アラームが本当に必要なこの状況ではどうすればよいでしょうか。

今日は、Kafka が、運用と保守におけるこの種の頭痛の種を完全に回避するようにどのように設計されているかを見ていきます。

2. Kafkaのレプリケーションメカニズム

Kafka の各パーティションは、順番に追加される不変のメッセージ シーケンスで構成され、各メッセージにはその位置を示す一意のオフセットがあります。

Kafka のレプリケーション メカニズムは、パーティションの粒度でレプリケートします。 Kafka でトピックを作成するときに、パーティションのレプリカの数を決定するレプリケーション係数を設定できます。リーダーに障害が発生した場合、Kafka はパーティション マスター ノードを他のレプリカ ノードにフェイルオーバーし、このパーティションのメッセージが利用可能であることを保証します。リーダー ノードはプロデューサーからのメッセージを受信する役割を担い、他のレプリカ ノード (フォロワー) はマスター ノードからメッセージをコピーします。

Kakfa ログ レプリケーション アルゴリズムによって提供される保証は、メッセージがプロデューサー側でコミットされたと見なされた後、リーダー ノードに障害が発生した場合でも、他のノードがリーダー ノードとして選出された後でもメッセージを消費できるということです。

この場合、リーダーが選出されるときは、ISR セットからのみ選出できます。セット内の各ポイントはリーダー メッセージと同期されている必要があります。つまり、遅延はありません。パーティションのリーダーは ISR セット リストを管理します。ポイントがあまりにも遅れている場合は、ISR セットから除外されます。

プロデューサーがリーダー ノードにメッセージを送信した後、リーダーは、ISR 内のすべてのレプリカ ノードがリーダーに ACK を送信してメッセージを確認した場合にのみコミットします。そうして初めて、プロデューサーはメッセージがコミットされたとみなすことができます。このため、Kafka クライアントの書き込みパフォーマンスは、メッセージを受信する ISR セット内の最も遅いブローカーのパフォーマンスに依存します。ポイントのパフォーマンスが低すぎる場合は、パフォーマンスの問題を回避するために、できるだけ早くそのポイントを識別し、ISR セットから除外する必要があります。

3. レプリカがリーダーのレプリカに追いつくことができるとはどのように考えられますか?

レプリカがリーダー ノードに「追いつく」ことができない場合、ISR セットから追い出される可能性があります。 「追いつく」、つまりリーダー ノードとメッセージを同期する、ということが何を意味するのかを説明するために例を見てみましょう。

下の図は、Kafka の単一パーティション トピック (foo)、レプリケーション係数 3、パーティション分散、リーダーとフォロワーを示しています。現在、ブローカー 2 と 3 はフォロワーであり、ISR セット内にあります。 replica.lag.max.messages を 4 に設定します。フォロワーがリーダーより 3 メッセージ以上遅れていない限り、リーダーに追いつくことができれば追い出されることはありません。 replica.lag.time.max.ms を 500 ミリ秒に設定します。これは、フォロワーが 500 ミリ秒ごとにフェッチ要求を送信する限り、フォロワーはデッドとは見なされず、ISR セットから除外されないことを意味します。

ここで、プロデューサーはオフセット 3 のメッセージを送信します。この時点で、次の図に示すように、ブローカー 3 で GC が発生します。

ブローカー 3 は現在 ISR セット内にあるため、ブローカー 3 がメッセージをプルしてオフセット 3 と同期するか、ブローカー 3 が ISR セットから追い出されます。そうでない場合、メッセージはコミットされません。 replica.lag.max.messages=4 は 4 なので、ブローカー 3 は 1 メッセージだけ遅れており、ISR セットから除外されることはありません。この時点でブローカー 3 が 100 ミリ秒間 GC を実行し、GC が終了してからオフセット 3 でメッセージをプルすると、リーダーと再び完全に同期されます。次の図に示すように、プロセス全体が ISR セットに含まれています。

4. レプリカはいつ ISR セットから除外されますか?

レプリカが ISR セットから除外される理由はいくつかあります。

• レプリカは一定期間リーダー ノードに追いつくことができませんでした。つまり、リーダー ノードとのギャップが replica.lag.max.messages よりも大きくなっています。通常、IO パフォーマンスが追いつかないか、CPU 負荷が高すぎるため、ブローカーはリーダー メッセージの受信速度よりも遅い速度でディスクにメッセージを追加します。
• ブローカーは、長時間 (replica.lag.time.max.ms を超える時間) にわたってリーダーにフェッチ要求を送信していません。これは、ブローカーの GC がいっぱいになっているか、他の理由でクラッシュしたためである可能性があります。
• たとえば、同じブローカー ID を持つ新しいブローカー ノード、ディスクに障害が発生する、新しいマシンが交換される、またはパーティションが新しいブローカー ノードに再割り当てされるなどの場合は、パーティション リーダーにある現在の最も古いメッセージから同期を開始します。

そのため、Kafka バージョン 0.8 以降では、2 つのパラメータが設定されます。replica.lag.max.messages は、一貫してパフォーマンスが低いノードを識別するために使用され、replica.lag.time.max.ms は、スタックしたノードを識別するために使用されます。

5. ノードが実際に遅れるのはいつですか?

上記の状況からすると、2 つのパラメータで十分であると思われます。レプリカが replica.lag.time.max.ms を超えてフェッチ同期要求を送信していない場合、レプリカ ノードがスタックして追い出されたと考えられます。しかし、考慮されていない特殊な状況があります。

上記のテキストでは、replica.lag.max.messages を 4 に設定しています。これを 4 に設定する理由は、プロデューサーが毎回送信するメッセージ数が 4 未満であることが既にわかっているためです。パラメーターが複数のトピックに適用される場合、プロデューサーが送信するメッセージの最大数を推定することは困難です。つまり、交通渋滞が頻繁に発生すると何が起こるのでしょうか?例を使って説明してみましょう。

トピックのプロデューサーである foo がトラフィック ジッターのために 4 つのメッセージを含むリクエストを送信し、replica.lag.max.messages を 4 に設定すると、遅延メッセージの数が超過するため、すべてのフォロワーが ISR セットから除外されます。

すると、フォロワーは正常であるため、次のフェッチ要求でリーダーに追いつき、このときに再び ISR セットに参加します。ジッタが頻繁に発生すると、ISR セット内外が絶えず移動し、アラーム集中攻撃に頭を悩ませることになります。

ここでの中心的な問題は、トピックが大量であったり、トラフィックのジッタが頻繁に発生したりする場合には、トピック プロデューサーが毎回送信するメッセージの数について想定することができないため、適切な eplica.lag.max.messages 値を決定するのが容易ではないことです。

6. 1つの設定ですべて完了

実際には、異常な状況は 2 つしかありません。1 つはスタック、もう 1 つはフォロワーのパフォーマンスが遅いことです。フォロワーがリーダーからどれだけ遅れているかに基づいて ISR セットからフォロワーを削除するかどうかのみを判断する場合は、トラフィックの予測推定を行う必要があります。このような信頼性の低い推定値を避けるにはどうすればよいでしょうか?

Kafka が提供するソリューションは次のとおりです。

replica.lag.time.max.ms 構成の意味が強化されました。以前と同様に、フォロワーがフェッチ要求を送信せずにこの時間を超えてスタックした場合、ISR セットから追い出されます。新しく強化されたロジックでは、フォロワーがリーダーより eplica.lag.max.messages メッセージ以上遅れている場合、ISR セットからすぐには追い出されず、replica.lag.time.max.ms 以上遅れ続ける場合にのみ追い出されます。これにより、次のフェッチでフォロワーがリーダーに追いつくため、トラフィック ジッターによって発生する運用および保守の問題を回避でき、トピックの書き込み速度を推定する必要がなくなります。