K8S で Kafka を実行するのは適切でしょうか?どのような落とし穴に遭遇するでしょうか?

K8S で Kafka を実行するのは適切でしょうか?どのような落とし穴に遭遇するでしょうか?

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

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

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

1. ランタイム

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

1. プロセス

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

2. 記憶

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

3. 保管

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

これが永続ストレージを使用する必要がある理由です。 XFS または ext4 を使用した非ローカルの永続ブロック ストレージの方が適しています。警告します: NFS を使用しないでください。 NFS v3 も v4 も動作しません。

つまり、NFS の「愚かな名前変更」問題によりデータ ディレクトリを削除できないため、Kafka ブローカーは自動的に終了します。もしまだ信じられないなら、このブログ記事を注意深く読んでください[1]。 Kubernetes が再起動または再配置されたときに別のノードをより柔軟に選択できるように、ストレージは非ローカルである必要があります。

4. ネットワーク

ほとんどの分散システムと同様に、Kafka のパフォーマンスは、ネットワークの遅延が少なく、帯域幅が広いことに大きく依存します。すべてのブローカーを同じノードに配置しないでください。可用性が低下します。

Kubernetes ノードに障害が発生すると、Kafka クラスター全体に障害が発生します。 Kafka クラスターをデータセンター間で拡張しないでください。 Kubernetes クラスターにも同じことが当てはまります。異なる可用性ゾーンは適切なトレードオフです。

2. 構成

1. リスト

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

1) ポッド

Pod は Kubernetes でデプロイ可能な最小単位です。クラスター内のプロセスを表すワークロードが含まれます。 Pod は 1 つ以上のコンテナーで構成されます。アンサンブル内の各 ZooKeeper サーバーと Kafka クラスター内の各 Kafka ブローカーは、個別の Pod で実行されます。

2) ステートフルセット

StatefulSet は、調整する必要がある複数のステートフル ワークロードを処理するための Kubernetes オブジェクトです。 StatefulSets は Pod の順序と一意性を保証します。

3) ヘッドレスサービス

サービスは論理名を通じてポッドをクライアントから切り離します。 Kubernetes が負荷分散を処理します。ただし、ZooKeeper や Kafka などのステートフル ワークロードの場合、クライアントは特定のインスタンスと通信する必要があります。ここでヘッドレス サービスが役立ちます。クライアントとして論理名を取得することはできますが、ポッドに直接アクセスする必要はありません。

4) 永続ボリューム

前述のように、非ローカルの永続ブロック ストレージを構成する必要があります。

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

2. ヘルムチャート

Helm は、yum、apt、Homebrew、Chocolatey などの OS パッケージ マネージャーに似た、Kubernetes 用のパッケージ マネージャーです。 Helm Charts に記述された定義済みパッケージをインストールできます。

適切に設計された Helm Charts は、Kubernetes 上で Kafka を実行するためにすべてのパラメータを正しく構成するという複雑なタスクを簡素化します。 Kafka にはいくつかのチャートが用意されています。たとえば、開発中の公式チャート [4]、Confluent のチャート、Bitnami のチャートなどがあります。

3. オペレーター

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

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

4. パフォーマンス

Kafka インストールのベンチマークを行うには、パフォーマンス テストを実行することが重要です。問題が発生する前に、ボトルネックになる可能性のある場所がどこにあるかを把握できるようになります。

幸いなことに、Kafka にはすでに kafka-producer-perf-test.sh と kafka-consumer-perf-test.sh という 2 つのパフォーマンス テスト ツールが用意されています。頻繁に使用することを忘れないでください。参考までに、ジェイ・クレプスのブログ投稿結果[6]やステファン・マーレクのAmazon MSKのレビュー[7]を参考にすることができます。

3. 運用と保守

1. 監視

可視性は非常に重要です。そうでないと、何が起こっているのかわかりません。現在、クラウドネイティブな方法でメトリックを監視するための優れたツールがあります。 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[8]を使用したエンドツーエンドのモニタリングを通じて実現できます。

2. ログ記録

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

3. 健康チェック

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

4. ローリングアップデート

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

5. 拡張

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

6. 管理

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

7. バックアップと復元

現在、Kafka の可用性は Kubernetes の可用性にも依存しています。 Kubernetes クラスターに障害が発生すると、最悪の場合、Kafka クラスターにも障害が発生します。

マーフィーの法則によれば、あなたにも同じことが起こり、データが失われることになります。このリスクを軽減するには、バックアップのアイデアを用意しておく必要があります。 MirrorMakerは1つの選択肢であり、Zalandoのブログ投稿[9]で説明されているように、接続されたバックアップにS3を使用するという別の可能性もあります。

IV.結論

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

>>>>

参考リンク

[1]https://engineering.skybettingandgaming.com/2018/07/10/kafka-nfs/

[2]https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/

[3]https://github.com/Yolean/kubernetes-kafka

[4]https://github.com/helm/charts/tree/master/incubator/kafka

[5] https://strimzi.io/

[6]https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines

[7]https://medium.com/@stephane.maarek/an-honest-review-of-aws-managed-apache-kafka-amazon-msk-94b1ff9459d8

[8]https://github.com/linkedin/kafka-monitor

[9]https://jobs.zalando.com/tech/blog/backing-up-kafka-zookeeper/

オリジナルリンク: https://blog.usejournal.com/kafka-on-kubernetes-a-good-fit-95251da55837

<<:  分散メッセージングシステムの設計ポイント

>>:  平安金融クラウドがインターネット金融業界の発展に新たな推進力を注入

推薦する

マルチクラウドでクラウドへの野望を挫折させないでください

今日、人々は新興技術の焦点の変化に慣れてきており、クラウド コンピューティング技術も例外ではありませ...

スキルギャップが拡大する中、クラウド時代の企業は主導権を握らなければならない。

「クラウドコンピューティングの人材不足をどう解決するか?」これは多くの IT リーダーにとって重要な...

ecvps5.95USD/月512MB RAM 完全管理型 VPS

ecvpsは2009年に設立されたVPS事業です。社長は香港出身です。ネットユーザーによると、社長は...

1人のSEOが独立してウェブサイトの最適化をサポートできますか?

今日、QQグループで、a5の毎日のQ&Aから「SEOを行う小さな会社で、1人だけで対応できま...

電子商取引は価格検索エンジンを生み出した

価格検索エンジンは、オンラインショッピングをする消費者層にサービスを提供するウェブサイトです。10年...

ウェブサイトを最適化するときは冷静さを保つことが重要です。

ウェブサイト運営者、特に中小企業やウェブマスターはウェブサイトのランキングを毎日チェックしており、少...

現象を通して本質を見極める:制御可能なSEOを行う

著者はずっと Guoping 先生の記事を読むのが好きでした。Guoping 先生の記事はすべて、一...

サイトマップを使用して検索ランキングを向上させる方法は?

ウェブサイトの構造は、検索エンジンのランキングにおいて重要な役割を果たします。サイトの構造が非常に複...

企業はWeiboをどのように活用して精密マーケティングを実現できるか:需要に基づいてコンテンツを決定する

ソーシャル化された電子商取引は、Facebook 上で非常に有望なビジネス モデルであることが徐々に...

「Baidu ホームページに追加」の背後にあるもの: 従来の Web サイトナビゲーションへの影響。

2012年、Baidu検索はよりパーソナライズされ、人間的になったようです。今回は、Baiduのもう...

年末レビュー: 草の根ウェブマスターのためのトップ 10 ニュース

2012年も終わりに近づいていますが、伝説の「世界の終わり」は予想通りには来ませんでした。私たちの生...

インターネット ユーザーのニーズについての講演: ユーザーのニーズとは何でしょうか?

私は記録として、あるいは探求として、このような記事をずっと書きたいと思っていました。もちろん、もっと...

ユーザーエクスペリエンスと収益性の調和とバランスを実現する方法

ウェブサイトで優れたユーザー エクスペリエンスを提供することは、検索エンジンの高要件ですが、ウェブサ...

K8s のアップグレードにより Didi が 12 時間停止したのですか?

みなさんこんにちは。ジュン兄です。少し前に起きた Didi の障害については、皆さんご存知だと思いま...

sharktech (シャークデータセンター) - 40G の高防御、すべての VPS が 50% オフ、史上最低価格

Sharktech の VPS は特別なことをしています。すべての VPS が 50% オフという前...