Kubernetes 上で Kafka を実行するのは適切でしょうか?

導入

Kubernetes は、ステートレス ワークロードを実行するためにゼロから設計されました。これらのワークロードは通常、マイクロサービス アーキテクチャを使用して構築され、軽量で、水平方向にスケーラブルであり、12 要素アプリに準拠しており、サーキット ブレーキングやランダム モンキー テストを処理できます。

一方、Kafka は本質的に分散データベースです。つまり、マイクロサービスよりも重い状態を処理する必要があるということです。 Kubernetes はステートフル ワークロードをサポートしていますが、Kelsey Hightower が最近の 2 つのツイートで指摘したように、慎重に扱う必要があります。

では、Kubernetes 上で Kafka を実行すべきでしょうか?私の反対の質問は、Kafka はそれがなくてもより良く動作するかということです。そのため、Kafka と Kubernetes がどのように相互に補完し合うのか、また、どのような落とし穴に陥る可能性があるのか​​を指摘したいと思います。

ランタイム

まずは基本、つまりランタイム自体から始めましょう。

プロセス

Kafka ブローカーは CPU に優しいです。 TLS によってオーバーヘッドが発生する可能性があります。 Kafka クライアントが暗号化を使用する場合、より多くの CPU が必要になりますが、ブローカーには影響しません。

メモリ

Kafka ブローカーは大量のメモリを消費します。 JVM ヒープは通常 4 ～ 5 GB に制限されますが、Kafka はページ キャッシュを多用するため、十分なシステム メモリも必要です。 Kubernetes では、コンテナ リソースの制限とリクエストをそれに応じて設定できます。

ストレージ

コンテナ内のストレージは一時的なものであり、再起動するとデータが失われます。 Kafka データに emptyDir ボリュームを使用することもできますが、同じ効果があり、停止後にブローカーのデータが失われます。メッセージは他のブローカーでもコピーとして引き続き利用可能です。したがって、再起動後、障害が発生したブローカーはすべてのデータを複製する必要があり、これは時間のかかるプロセスになる可能性があります。

これが永続ストレージを使用する必要がある理由です。 XFS または ext4 を使用した非ローカルの永続ブロック ストレージの方が適しています。警告します: NFS を使用しないでください。 NFS v3 も v4 も動作しません。つまり、NFS の「愚かな名前変更」問題によりデータ ディレクトリを削除できないため、Kafka ブローカーは自動的に終了します。それでもまだ信じられないなら、このブログ投稿を注意深く読んでください。 Kubernetes が再起動または再配置されたときに別のノードをより柔軟に選択できるように、ストレージは非ローカルである必要があります。

ネットワーク

ほとんどの分散システムと同様に、Kafka のパフォーマンスは、ネットワークの遅延が少なく、帯域幅が広いことに大きく依存します。すべてのブローカーを同じノードに配置しないでください。可用性が低下します。 Kubernetes ノードに障害が発生すると、Kafka クラスター全体に障害が発生します。 Kafka クラスターをデータセンター間で拡張しないでください。 Kubernetes クラスターにも同じことが当てはまります。異なる可用性ゾーンは適切なトレードオフです。

構成

リスト

Kubernetes の Web サイトには、マニフェストを使用して ZooKeeper を設定する方法に関する非常に優れたチュートリアルが掲載されています。 ZooKeeper は Kafka の一部であるため、ここではどの Kubernetes の概念が適用されているかについてある程度の洞察が得られます。一度理解すれば、同じ概念を Kafka クラスターでも使用できます。

• Pod: Pod は Kubernetes でデプロイ可能な最小の単位です。クラスター内のプロセスを表すワークロードが含まれます。 Pod は 1 つ以上のコンテナーで構成されます。アンサンブル内の各 ZooKeeper サーバーと Kafka クラスター内の各 Kafka ブローカーは、個別の Pod で実行されます。
• StatefulSet: StatefulSet は、調整が必要な複数のステートフル ワークロードを処理する Kubernetes オブジェクトです。 StatefulSets は Pod の秩序性と一貫性を保証します。
• ヘッドレス サービス:サービスは論理名を通じてポッドをクライアントから分離します。 Kubernetes が負荷分散を処理します。ただし、ZooKeeper や Kafka などのステートフル ワークロードの場合、クライアントは特定のインスタンスと通信する必要があります。ここでヘッドレス サービスが役立ちます。クライアントとして論理名を取得することはできますが、ポッドに直接アクセスする必要はありません。
• 永続ボリューム:前述のように、非ローカルの永続ブロック ストレージを構成する必要があります。

Yolean は、Kubernetes 上で Kafka を使い始めるのに役立つ包括的なチェックリスト セットを提供します。

ヘルムチャート

Helm は、yum、apt、Homebrew、Chocolatey などの OS パッケージ マネージャーに似た、Kubernetes 用のパッケージ マネージャーです。 Helm Charts に記述された定義済みパッケージをインストールできます。適切に設計された Helm Charts は、Kubernetes 上で Kafka を実行するためにすべてのパラメータを正しく構成するという複雑なタスクを簡素化します。 Kafka には、開発中の公式チャート、Confluent のチャート、Bitnami のチャートなど、いくつかのチャートが用意されています。

オペレーター

Helm にはいくつかの制限があるため、Kubernetes Operators という別のツールが非常に人気になりました。オペレーターは、Kubernetes 用のソフトウェアをパッケージ化するだけでなく、Kubernetes 用のソフトウェアをデプロイおよび管理します。

Kafka の高評価オペレーターのリストには 2 つのオペレーターが記載されており、そのうちの 1 つが Strimzi です。 Strimzi を使用すると、ほとんど構成を必要とせずに数分で Kafka クラスターを簡単に起動でき、クラスター間のポイントツーポイント TLS 暗号化などの便利な機能も追加されます。 Confluent は、新しい Operator がまもなく利用可能になることも発表しました。

パフォーマンス

Kafka インストールのベンチマークを行うには、パフォーマンス テストを実行することが重要です。問題が発生する前に、ボトルネックになる可能性のある場所がどこにあるかを把握できるようになります。幸いなことに、Kafka にはすでに kafka-producer-perf-test.sh と kafka-consumer-perf-test.sh という 2 つのパフォーマンス テスト ツールが用意されています。頻繁に使用することを忘れないでください。参考として、Jay Kreps のブログの結果、または Amazon MSK の Stéphane Maarek のレビューを使用できます。

オペレーション

モニター

可視性は非常に重要です。そうでないと、何が起こっているのかわかりません。現在、クラウドネイティブな方法でメトリックを監視するための優れたツールがあります。 Prometheus と Grafana は 2 つの人気のあるツールです。 Prometheus は、JMX エクスポーターから直接、すべての Java プロセス (Kafka、ZooKeeper、Kafka Connect) のメトリックを収集できます。 cAdvisor メトリックを追加すると、Kubernetes リソースの使用状況に関する追加情報が提供されます。

Strimzi は、Kafka 用の Grafana ダッシュボードの優れた例を提供します。複製されていないパーティションやオフラインのパーティションなどの主要なメトリックを非常に直感的な方法で視覚化します。これらのメトリックは、リソース使用量、パフォーマンス、安定性の指標で補完されます。基本的な Kafka クラスター監視を無料で入手しましょう。

出典: https://strimzi.io/docs/master/#kafka_dashboard

これは、クライアント側の監視 (コンシューマーとプロデューサーのメトリック)、Burrow を使用したラグ監視、および Kafka Monitor を使用したエンドツーエンドの監視を通じて実現できます。

ログ記録

ログ記録ももう一つの重要な部分です。 Kafka インストール内のすべてのコンテナが stdout と stderr にログを記録していることを確認し、Kubernetes クラスターがすべてのログを Elasticsearch などの中央ログ機能に集約していることを確認します。

健康チェック

Kubernetes は、活性プローブと準備プローブを使用して、Pod が正常かどうかを判断します。ライブネスプローブが失敗した場合、Kubernetes はコンテナを終了し、再起動ポリシーが適切に設定されていれば自動的に再起動します。準備プローブが失敗した場合、Kubernetes はサービスを通じてリクエストを処理する Pod を削除します。つまり、この場合、人間の介入は不要になり、これは大きな利点です。

ローリングアップデート

StatefulSets は自動更新をサポートしています。ローリング更新戦略では、一度に 1 つの Kafka Pod を更新します。このようにして、ゼロダウンタイムを実現できます。これは、Kubernetes がもたらすもう 1 つの大きな利点です。

拡張機能

Kafka クラスターのスケーリングは簡単ではありません。ただし、Kubernetes を使用すると、Pod を特定の数のレプリカに簡単に拡張できるため、必要な数の Kafka ブローカーを宣言的に定義できます。難しいのは、セクションを拡大または縮小する前に再割り当てすることです。繰り返しになりますが、Kubernetes はこのタスクの達成に役立ちます。

管理

Pod でシェルを開くと、既存のシェル スクリプトを使用して、トピックの作成やパーティションの再割り当てなどの Kafka クラスターの管理タスクを完了できます。これはあまり良い解決策ではありません。 Strimzi は、別の Operator を使用してテーマを管理することをサポートしています。改善の余地があります。

バックアップと復元

現在、Kafka の可用性は Kubernetes の可用性にも依存しています。 Kubernetes クラスターに障害が発生すると、最悪の場合、Kafka クラスターにも障害が発生します。マーフィーの法則によれば、あなたにも同じことが起こり、データが失われることになります。このリスクを軽減するには、バックアップのアイデアを用意しておく必要があります。 MirrorMaker は 1 つのオプションであり、Zalando のブログ投稿で説明されているように、接続されたバックアップに S3 を活用することも別の可能性として考えられます。

結論は

小規模から中規模の Kafka クラスターの場合、柔軟性が高く、操作が簡素化されるため、Kubernetes を選択することをお勧めします。レイテンシやスループットに関して非機能要件が非常に高い場合は、別のデプロイメント オプションの方が有利な場合があります。