Kubernetes の Kafka クラスターの適切なサイズを決定する

ノート。 翻訳。: この記事では、Banzai Cloud が、カスタム ツールを使用して Kubernetes 内で Kafka を使いやすくする方法の例を紹介します。 次の手順では、インフラストラクチャの最適なサイズを決定し、必要なスループットを達成するために Kafka 自体を構成する方法を示します。

Apache Kafka は、信頼性が高く、スケーラブルで高性能なリアルタイム ストリーミング システムを作成するための分散ストリーミング プラットフォームです。 その優れた機能は、Kubernetes を使用して拡張できます。 このために私たちは開発しました オープンソースの Kafka オペレーター と呼ばれるツール スーパーチューブ。 これにより、Kubernetes 上で Kafka を実行し、ブローカー構成の微調整、リバランスを伴うメトリックベースのスケーリング、ラック認識、「ソフト」などのさまざまな機能を使用できるようになります。 （優雅に） アップデートの展開など。

クラスター内で Supertube を試してください。

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

または連絡してください ドキュメンテーション。 また、Kafka の機能の一部について読むこともできます。この作業は、Supertube と Kafka オペレーターを使用して自動化されます。 それらについてはすでにブログで書きました。

• なんてこった！ Kubernetes 用のもう XNUMX つの Kafka オペレーター;
• Prometheus メトリクスに基づいて Kafka を監視および操作する;
• Kubernetes での Kafka ラックの認識;
• Istio 上で Apache Kafka を実行 - ベンチマーク;
• Kafka オペレーターによるユーザー認証およびアクセス制御されたクラスター;
• Kafka のローリング アップグレードと Kubernetes での動的構成;
• Kafka の Envoy プロトコル フィルター、メッシュ化.

Kafka クラスターを Kubernetes にデプロイすることにした場合、基盤となるインフラストラクチャの最適なサイズを決定し、スループット要件を満たすように Kafka 構成を微調整する必要があるという課題に直面する可能性があります。 各ブローカーの最大パフォーマンスは、メモリ、プロセッサ、ディスク速度、ネットワーク帯域幅など、基盤となるインフラストラクチャ コンポーネントのパフォーマンスによって決まります。

理想的には、ブローカー構成は、すべてのインフラストラクチャー要素がその機能を最大限に活用できるようにする必要があります。 ただし、実際には、この設定は非常に複雑です。 ユーザーは、XNUMX つまたは XNUMX つのコンポーネント (ディスク、メモリ、またはプロセッサ) を最大限に使用するようにブローカーを構成する可能性が高くなります。 一般に、ブローカーは、最も遅いコンポーネントを最大限に使用できる構成になっている場合に最大のパフォーマンスを発揮します。 このようにして、XNUMX つのブローカーが処理できる負荷の大まかなアイデアを得ることができます。

理論的には、特定の負荷を処理するために必要なブローカーの数を見積もることもできます。 ただし、実際には、さまざまなレベルで非常に多くの構成オプションがあるため、特定の構成の潜在的なパフォーマンスを評価することは (不可能ではないにしても) 非常に困難です。 言い換えれば、特定のパフォーマンスに基づいて構成を計画することは非常に困難です。

Supertubes ユーザーの場合、私たちは通常、次のアプローチを採用します。まず、いくつかの構成 (インフラストラクチャ + 設定) から開始し、次にそのパフォーマンスを測定し、ブローカー設定を調整して、プロセスを再度繰り返します。 これは、インフラストラクチャの最も遅いコンポーネントが完全に利用されるまで発生します。

このようにして、クラスターが特定の負荷を処理するために必要なブローカーの数をより明確に把握できます (ブローカーの数は、回復性を確保するためのメッセージ レプリカの最小数、パーティションの数などの他の要素にも依存します)リーダーなど）。 さらに、どのインフラストラクチャ コンポーネントが垂直方向のスケーリングを必要とするかについての洞察が得られます。

この記事では、初期構成で最も遅いコンポーネントを最大限に活用し、Kafka クラスターのスループットを測定するために実行する手順について説明します。 復元力の高い構成には、少なくとも XNUMX つのブローカーを実行する必要があります (min.insync.replicas=3)、XNUMX つの異なるアクセシビリティ ゾーンに分散されています。 Kubernetes インフラストラクチャの構成、拡張、監視には、ハイブリッド クラウド用の独自のコンテナ管理プラットフォームを使用します。 パイプライン。 オンプレミス (ベアメタル、VMware) と XNUMX 種類のクラウド (Alibaba、AWS、Azure、Google、Oracle)、およびそれらの任意の組み合わせをサポートします。

Kafka クラスターのインフラストラクチャと構成についての考え

以下の例では、クラウドプロバイダーとして AWS を選択し、Kubernetes ディストリビューションとして EKS を選択しました。 同様の構成は次を使用して実装できます。 PKE - Banzai Cloud からの Kubernetes ディストリビューション (CNCF によって認定)。

ドライブ

アマゾンではさまざまな商品が提供されています EBS ボリュームの種類。 中心部で gp2 и io1 ただし、高スループットを確保するために SSD ドライブもあります gp2 蓄積されたクレジットを消費します (I/Oクレジット), そのため、このタイプを好みました io1、一貫した高スループットを提供します。

インスタンスの種類

Kafka のパフォーマンスはオペレーティング システムのページ キャッシュに大きく依存するため、ブローカー (JVM) とページ キャッシュに十分なメモリを備えたインスタンスが必要です。 実例 c5.2xラージ - 16 GB のメモリと EBS と連携するように最適化。 欠点は、最大パフォーマンスを提供できるのが 30 時間ごとに 24 分以内であることです。 ワークロードが長期間にわたってピークパフォーマンスを必要とする場合は、他のインスタンスタイプを検討することをお勧めします。 それがまさに私たちがやったことです。 c5.4xラージ。 最大のスループットを提供します 593,75Mb/秒。 EBS ボリュームの最大スループット io1 インスタンスよりも高い c5.4xラージしたがって、インフラストラクチャの最も遅い要素は、このインスタンス タイプの I/O スループットである可能性があります (負荷テストでも確認する必要があります)。

Сеть

ネットワーク スループットは、VM インスタンスとディスクのパフォーマンスに比べて十分に大きい必要があります。そうでないと、ネットワークがボトルネックになります。 私たちの場合、ネットワークインターフェイスは c5.4xラージ は最大 10 Gb/s の速度をサポートします。これは、VM インスタンスの I/O スループットよりも大幅に高速です。

ブローカーの導入

CPU、メモリ、ネットワーク、ディスク リソースに関して他のプロセスと競合するのを避けるために、ブローカーは専用ノードにデプロイ (Kubernetes でスケジュール) する必要があります。

Java バージョン

論理的な選択は Java 11 です。これは、JVM がブローカーが実行されているコンテナーで使用できるプロセッサーとメモリーを正しく判断するという意味で Docker と互換性があるためです。 CPU 制限が重要であることを認識しているため、JVM は GC スレッドと JIT スレッドの数を内部的かつ透過的に設定します。 Kafka イメージを使用しました banzaicloud/kafka:2.13-2.4.0これには、Java 2.4.0 上の Kafka バージョン 2.13 (Scala 11) が含まれます。

Kubernetes 上の Java/JVM について詳しく知りたい場合は、次の投稿をご覧ください。

• Java アプリケーションが OOMKilled になる理由;
• Java 10 アプリケーションのコンテナーのサイズを正しく設定する方法.

ブローカーのメモリ設定

ブローカー メモリの構成には、JVM の設定と Kubernetes ポッドの設定という XNUMX つの重要な側面があります。 ポッドに設定されたメモリ制限は、JVM が独自のメモリ内に常駐する Java メタスペースと、Kafka がアクティブに使用するオペレーティング システムのページ キャッシュのためのスペースを確保できるように、最大​​ヒープ サイズより大きくする必要があります。 テストでは、パラメータを指定して Kafka ブローカーを起動しました。 -Xmx4G -Xms2G、ポッドのメモリ制限は 10 Gi。 JVM のメモリ設定は、次のコマンドを使用して自動的に取得できることに注意してください。 -XX:MaxRAMPercentage и -X:MinRAMPercentage、ポッドのメモリ制限に基づきます。

ブローカーのプロセッサ設定

一般に、Kafka で使用されるスレッドの数を増やして並列処理を増やすと、パフォーマンスを向上させることができます。 Kafka で使用できるプロセッサが多ければ多いほど良いです。 私たちのテストでは、プロセッサ数の制限を 6 つとして開始し、徐々に (反復を通じて) プロセッサ数を 15 まで増やしました。 num.network.threads=12 ブローカー設定で、ネットワークからデータを受信して​​送信するスレッドの数を増やします。 後続のブローカーがレプリカを迅速に受信できないことをすぐに発見し、彼らは、 num.replica.fetchers フォロワー ブローカーがリーダーからのメッセージを複製する速度を向上させるには、4 に増やします。

負荷生成ツール

Kafka クラスター (ベンチマーク対象) が最大負荷に達する前に、選択したロード ジェネレーターの容量が不足しないようにする必要があります。 つまり、負荷生成ツールの機能を事前に評価し、十分な数のプロセッサとメモリを備えたインスタンス タイプを選択する必要があります。 この場合、私たちのツールは、Kafka クラスターが処理できる以上の負荷を生成します。 多くの実験を行った結果、XNUMX 部に落ち着きました。 c5.4xラージ、それぞれに発電機が稼働していました。

ベンチマーク

パフォーマンス測定は、次の段階を含む反復プロセスです。

• インフラストラクチャ (EKS クラスター、Kafka クラスター、負荷生成ツール、Prometheus および Grafana) のセットアップ。
• 収集されたパフォーマンス指標のランダムな偏差をフィルタリングするために、一定期間負荷を生成します。
• 観察されたパフォーマンス指標に基づいてブローカーのインフラストラクチャと構成を調整する。
• Kafka クラスターの必要なレベルのスループットが達成されるまで、このプロセスを繰り返します。 同時に、一貫して再現可能であり、スループットの変動が最小限であることを実証する必要があります。

次のセクションでは、テスト クラスターのベンチマーク プロセス中に実行された手順について説明します。

ツール

次のツールを使用して、ベースライン構成を迅速に展開し、負荷を生成し、パフォーマンスを測定しました。

• バンザイクラウドパイプライン Amazon c から EKS クラスターを編成するため プロメテウス (Kafka とインフラストラクチャのメトリクスを収集するため) および グラファナ (これらのメトリクスを視覚化するため)。 私たちはそれを利用しました 統合された в パイプライン 連携監視、集中ログ収集、脆弱性スキャン、災害復旧、エンタープライズ グレードのセキュリティなどを提供するサービス。
• サングレネル — Kafka クラスターの負荷テスト用のツール。
• Kafka メトリクスとインフラストラクチャを視覚化するための Grafana ダッシュボード: Kubernetes カフカ, ノードエクスポーター.
• Supertubes CLI は、Kubernetes 上で Kafka クラスターをセットアップする最も簡単な方法です。 Zookeeper、Kafka オペレーター、Envoy およびその他の多くのコンポーネントがインストールされ、Kubernetes 上で本番環境に対応した Kafka クラスターを実行するように適切に構成されています。
  • 取り付け用 スーパーチューブ CLI 提供された指示を使用してください ここで.

EKS クラスター

専用ワーカーノードを備えた EKS クラスターを準備する c5.4xラージ Kafka ブローカーを備えたポッドのさまざまなアベイラビリティ ゾーン、およびロード ジェネレーターとモニタリング インフラストラクチャの専用ノード。

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

EKS クラスターが起動して実行されたら、その統合されたクラスターを有効にします。 監視サービス — 彼女は Prometheus と Grafana をクラスターにデプロイします。

Kafka システムのコンポーネント

supertubes CLI を使用して EKS に Kafka システム コンポーネント (Zookeeper、kafka-operator) をインストールします。

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

Kafka クラスター

デフォルトでは、EKS は次のタイプの EBS ボリュームを使用します。 gp2そのため、ボリュームに基づいて別のストレージ クラスを作成する必要があります。 io1 Kafka クラスターの場合:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

ブローカーのパラメータを設定する min.insync.replicas=3 そして、XNUMX つの異なるアベイラビリティ ゾーンのノードにブローカー ポッドをデプロイします。

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

トピック

XNUMX つのロード ジェネレーター インスタンスを並行して実行しました。 それぞれが独自のトピックに書き込みます。つまり、合計 XNUMX つのトピックが必要です。

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

各トピックのレプリケーション係数は 3 です。これは、可用性の高い実稼働システムの最小推奨値です。

負荷生成ツール

ロード ジェネレーターのコピーを XNUMX つ起動しました (それぞれ別のトピックで書きました)。 ロード ジェネレーター ポッドの場合は、それらに割り当てられたノード上でのみスケジュールされるようにノード アフィニティを設定する必要があります。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

注意すべき点がいくつかあります:

• ロード ジェネレーターは長さ 512 バイトのメッセージを生成し、それらを 500 メッセージのバッチとして Kafka にパブリッシュします。
• 引数の使用 -required-acks=all メッセージの同期されたレプリカがすべて受信され、Kafka ブローカーによって確認されると、パブリケーションは成功したとみなされます。 これは、ベンチマークでは、リーダーがメッセージを受信する速度だけでなく、そのフォロワーがメッセージを複製する速度も測定したことを意味します。 このテストの目的は、消費者の読書速度を評価することではありません。 (消費者) OS ページ キャッシュにまだ残っている最近受信したメッセージと、ディスクに保存されているメッセージの読み取り速度との比較。
• ロード ジェネレーターは 20 個のワーカーを並行して実行します (-workers=20）。 各ワーカーには、Kafka クラスターへのワーカーの接続を共有する 5 つのプロデューサーが含まれています。 その結果、各ジェネレーターには 100 のプロデューサーがあり、それらはすべて Kafka クラスターにメッセージを送信します。

クラスターの健全性の監視

Kafka クラスターの負荷テスト中に、ポッドの再起動がないこと、同期していないレプリカがないこと、最小限の変動で最大のスループットが確保されていることを確認するために、その状態も監視しました。

• ロード ジェネレーターは、パブリッシュされたメッセージの数とエラー率に関する標準統計を書き込みます。 エラー率は変わらないはずです 0,00%.
• クルーズコントロールkafka-operator によってデプロイされたダッシュボードは、クラスターの状態を監視することもできます。 このパネルを表示するには、次の手順を実行します。

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISRレベル (「同期」レプリカの数) 縮小と拡張は 0 に等しくなります。

測定結果

3 ブローカー、メッセージ サイズ - 512 バイト

パーティションを XNUMX つのブローカーに均等に分散することで、パフォーマンスを達成することができました。 ~500 Mb/秒 (990 秒あたり約 XNUMX 万メッセージ):

JVM 仮想マシンのメモリ消費量は 2 GB を超えませんでした。

ディスク スループットは、ブローカーが実行されていた XNUMX つのインスタンスすべてで最大 I/O ノード スループットに達しました。

ノードによるメモリ使用量のデータから、システムのバッファリングとキャッシュに約 10 ～ 15 GB かかっていることがわかります。

3 ブローカー、メッセージ サイズ - 100 バイト

メッセージ サイズが減少すると、スループットは約 15 ～ 20% 低下します。各メッセージの処理に費やされた時間が影響します。 さらに、プロセッサの負荷もほぼ XNUMX 倍になりました。

ブローカー ノードには未使用のコアがまだあるため、Kafka 構成を変更することでパフォーマンスを向上させることができます。 これは簡単な作業ではないため、スループットを向上するには、より大きなメッセージを処理する方が良いでしょう。

4 ブローカー、メッセージ サイズ - 512 バイト

新しいブローカーを追加し、パーティションのバランスを維持するだけで、Kafka クラスターのパフォーマンスを簡単に向上させることができます (これにより、ブローカー間で負荷が均等に分散されます)。 私たちの場合、ブローカーを追加した後、クラスターのスループットは次のように増加しました。 ~580 Mb/秒 (毎秒 ~1,1 万メッセージ)。 成長は予想よりも低いことが判明しました。これは主にパーティションの不均衡によって説明されます (すべてのブローカーが能力のピークで動作するわけではありません)。

JVM マシンのメモリ消費量は 2 GB 未満のままでした。

ドライブを使用するブローカーの作業は、パーティションの不均衡によって影響を受けました。

所見

上記の反復アプローチは、数百のコンシューマー、再パーティション化、ローリング アップデート、ポッドの再起動などを含むより複雑なシナリオをカバーするように拡張できます。 これらすべてにより、さまざまな状況における Kafka クラスターの機能の限界を評価し、その運用のボトルネックを特定し、それに対処する方法を見つけることができます。

Supertube は、クラスターのデプロイ、構成、ブローカーとトピックの追加/削除、アラートへの応答、一般的に Kafka が Kubernetes 上で適切に動作することを保証するために、迅速かつ簡単に設計されています。 私たちの目標は、ユーザーが主要なタスク (Kafka メッセージの「生成」と「消費」) に集中できるようにし、すべての難しい作業を Supertube と Kafka オペレーターに任せることです。

Banzai Cloud テクノロジーとオープンソース プロジェクトに興味がある場合は、次の URL で会社に登録してください。 GitHubの, LinkedIn または Twitter.

翻訳者からの追伸

私たちのブログもお読みください:

• «K8s の Redis オペレーターに関する XNUMX つのストーリーと、このデータベースのデータを分析するためのユーティリティのミニレビュー";
• «RabbitMQ から Kubernetes へのシームレスな移行";
• «CoreOS の zetcd: ZooKeeper を etcd ストレージに置き換える'。

出所： habr.com