競合する自己バランシングクラスタ
Kafka クラスタを以前に管理していたことがある場合、パーティションを別のブローカーに手動で再割り当てすることで、ワークロードがクラスタ全体に分散されるようにするという問題に慣れている方がよいでしょう。Kafka を大規模に導入している組織では、大容量のデータを変更するのが難しく、面倒でリスクが伴う可能性があります。特に、ミッションクリティカルなアプリケーションをクラスタの上に構築する場合、リスクが高くなります。しかし、 Kafka を使用するケースが最小であっても、処理に時間がかかり、人為的ミスが発生しやすくなります。
このラボでは、流暢な自己分散クラスタ機能をテストし、クラスタトポロジの変更や不均衡な負荷に基づいてリバランシングを自動化しました。一括リバランシングテストは、ノード障害や拡張ノードでブローカー間のデータのリバランシングが必要になった場合に、新しいブローカーを追加する時間を測定するのに役立ちます。従来の Kafka 構成では、クラスタの拡張に合わせてデータの再分散量が増える一方で、階層型ストレージでは少量のデータしかリバランシングされません。この検証に基づき、階層型ストレージのリバランシングには数秒から数分かかりますが、従来の Kafka アーキテクチャでは、クラスタの拡張に伴ってリニアに拡張されます。
セルフバランシングクラスタでは、パーティションの再調整が完全に自動化され、 Kafka のスループットが最適化され、ブローカーの拡張が高速化され、大規模なクラスタを実行する際の運用上の負担が軽減されます。安定した状態では、自己バランシングクラスタがブローカー間のデータのスキューを監視し、パーティションを継続的に再割り当てしてクラスタのパフォーマンスを最適化します。プラットフォームをスケールアップまたはスケールダウンすると、新しいブローカーが存在することを自己分散クラスタが自動的に認識したり、古いブローカーが削除されたことを確認したり、後続のパーティションの再割り当てをトリガーしたりします。これにより、ブローカーの追加や運用停止が容易になり、 Kafka クラスタの柔軟性が根本的に向上します。これらの利点は、手動操作、複雑な計算、またはパーティションの再割り当てが一般的に発生する人的ミスのリスクを必要としないことです。その結果、データのリバランシングが完了するまでの時間が大幅に短縮され、クラスタを常時監視するのではなく、価値の高いイベントストリーミングプロジェクトに集中できます。