決定方法Kafka=クラスターサイズ

Question

Kafkaクラスター上に存在するノードの数を決定する予定です。考慮すべきパラメーターについてはわかりません。係数2および1ノードの耐障害性）。

クラスターサイズとサイズへの影響を決定する際に、どのパラメーターに留意する必要があるかを教えてください。

私は次の要因を知っていますが、それがクラスタサイズにどのように定量的に影響するかわかりません。クラスターサイズに質的にどのように影響するかを知っています。クラスターサイズに影響する他のパラメーターはありますか？ 1. Replication factor (cluster size >= replication factor) 2. Node failure tolerance. (cluster size >= node-failure + 1)

すべてのパラメーターを考慮しながら、次のシナリオのクラスターサイズはどうなりますか1. There are 3 topics. 2. Each topic has messages of different size. Message size range is 10 to 500kb. Average message size being 50kb. 3. Each topic has different partitions. Partitions are 10, 100, 500 4. Retention period is 7 days 5. There are 100 million messages which gets posted every day for each topic.

誰かが私に関連ドキュメントやこれを議論するかもしれない他のブログを教えてくれませんか？私はグーグルで検索しましたが、役に立ちませんでした

user2720864 · Accepted Answer

私が理解しているように、Kafka=から良好なスループットを得るには、クラスターサイズだけに依存しません。他の構成も考慮する必要があります。できる限り共有するようにします。。

Kafkaのスループットは、お持ちのディスクの数に比例して増加するはずです。 Kafka 0.8で導入された新しい複数のデータディレクトリ機能により、Kafkaのトピックは異なるマシンに異なるパーティションを持つことができます。パーティション数が大幅に増加するにつれて、リーダーの選出プロセスが遅くなる可能性があります。消費者のリバランスにも影響します。これは考慮すべき事項であり、ボトルネックになる可能性があります。

もう1つの重要なことは、ディスクフラッシュレートです。 Kafka=は常にすべてのデータをすぐにファイルシステムに書き込みます。データがディスクにフラッシュされる頻度が高いほど、 "seek-bound" Kafkaとなり、繰り返しますが、フラッシュレートが非常に低いと、さまざまな問題が発生する可能性があり、その場合、フラッシュされるデータの量が多くなるため、正確な数値を提供することはあまり実用的ではないため、 Kafka=ドキュメントでそのような直接的な答えを見つけられません。

他の要因もあります。たとえば、コンシューマのfetchサイズ、圧縮、非同期プロデューサのバッチサイズ、ソケットバッファサイズなど。

ハードウェアとOSもこれに重要な役割を果たします。Linuxベースの環境でKafkaを使用することは、ディスクにデータを書き込むためのpageCacheメカニズムにより推奨されます。詳細についてはここ

また、実際にニーズに合わせて調整する前に、 OSフラッシュ動作が重要な役割を果たすことを考慮する方法を確認することもできます。スループットとフォールトトレランスの点で非常に効果的な設計哲学を理解することが重要だと思います。

Dig inに役立つリソース

Nithin · Answer

私は最近kafkaで働いていましたが、これらは私の観察です。

各トピックはパーティションに分割され、トピックのすべてのパーティションはkafkaブローカーに分散されます。これらのすべては、最初に単一のkafkaブローカーの容量よりも大きいトピックを保存するのに役立ちます。また、消費者の並列処理を向上させます。

信頼性と耐障害性を高めるために、パーティションの複製が行われ、コンシューマーの並列性は向上しません。経験則では、単一のブローカーはパーティションごとに1つのレプリカのみをホストできます。したがって、ブローカーの数は> =レプリカの数である必要があります

すべてのパーティションは利用可能なすべてのブローカーに分散され、パーティションの数はブローカーの数に関係なく可能ですが、パーティションの数はコンシューマグループのコンシューマスレッドの数と等しくなければなりません（最高のスループットを得るため）

クラスターサイズは、コンシューマーで達成するスループットを考慮して決定する必要があります。

ElisaLav · Answer

ブローカーあたりの合計MB /秒は次のようになります。

データ/日=（100×10 ^ 6メッセージ/日）×0.5MB =トピックあたり5TB /日

これにより、ブローカーあたり約58MB/sが得られます。メッセージがパーティション間で均等に分割されていると仮定すると、クラスター全体では、58MB/s x 3トピック=すべてのクラスターで178MB/sになります。

これで、レプリケーションのために、次のことができます。トピックごとに1つの追加レプリカ。したがって、これは58MB /秒/ブローカー着信元データ+ 58MB /秒/ブローカー発信レプリケーションデータ+ 58MB /秒/ブローカー着信レプリケーションデータになります。

これにより、ブローカーの入口ごとに約136MB/s、ブローカーの出口ごとに58MB/sが取得されます。

システムの負荷は非常に高くなりますが、これはストリーム処理を考慮していません。

システムの負荷は、ブローカーの数を増やし、トピックをより具体的なパーティションに分割することで処理できます。データが非常に重要な場合は、別の（高い）レプリケーション係数が必要になる場合があります。フォールトトレランスは、レプリケーションを決定するための重要な要素でもあります。
たとえば、パーティションを管理しているN個のアクティブなブローカー（レプリカを含む）以外に非常に重要なデータがある場合は、別の領域にスタンバイフォロワーを追加する必要があります。非常に低いレイテンシーが必要な場合は、さらにキーを追加して、パーティションをさらに増やすことができます。キーが多いほど、各パーティションに表示されるメッセージは少なくなります。低レイテンシーの場合、その特別なトピックのみを管理し、他のトピックに対して追加の計算は行われない新しいクラスター（レプリカ付き）が必要になる場合があります。トピックがそれほど重要でない場合は、その特定のトピックの複製係数を下げて、データの損失に対してより弾力的にしたい場合があります。 Kafkaクラスターを構築する場合、インフラストラクチャをサポートするマシンは同等に機能する必要があります。つまり、パーティション化はラウンドロビン方式で行われるため、各ブローカーは同じ処理を行うことができますしたがって、メッセージのサイズは重要ではありません。

ストリーム処理からの負荷も直接の影響があります。 kafka=ストリームの監視と管理に適したソフトウェアは Lenses です。これは processingリアルタイムストリーム