Temtokake ukuran sing cocog kanggo kluster Kafka ing Kubernetes

Cathetan. nerjemahake.: Ing artikel iki, Banzai Cloud nuduhake conto carane alat khusus bisa digunakake kanggo nggawe Kafka luwih gampang digunakake ing Kubernetes. Pandhuan ing ngisor iki nggambarake carane sampeyan bisa nemtokake ukuran infrastruktur sing optimal lan ngatur Kafka dhewe kanggo entuk throughput sing dibutuhake.

Apache Kafka minangka platform streaming sing disebarake kanggo nggawe sistem streaming wektu nyata sing dipercaya, skalabel lan kinerja dhuwur. Kapabilitas sing nggumunake bisa ditambah nggunakake Kubernetes. Kanggo iki kita wis dikembangaké Operator Open Source Kafka lan piranti diarani Supertube. Dheweke ngidini sampeyan mbukak Kafka ing Kubernetes lan nggunakake macem-macem fitur, kayata nyetel konfigurasi broker, skala basis metrik kanthi rebalancing, kesadaran rak, "alus" (anggun) nganyari nganyari, lsp.

Coba Supertubes ing kluster sampeyan:

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

Utawa kontak dokumentasi. Sampeyan uga bisa maca babagan sawetara kabisan Kafka, karya kanthi otomatis nggunakake operator Supertubes lan Kafka. Kita wis nulis babagan dheweke ing blog:

• Oh ora! Nanging operator Kafka liyane kanggo Kubernetes;
• Ngawasi lan ngoperasikake Kafka adhedhasar metrik Prometheus;
• Kafka rak kesadaran ing Kubernetes;
• Mlaku Apache Kafka liwat Istio - pathokan;
• Pangguna otentikasi lan ngakses kluster sing dikontrol karo operator Kafka;
• Kafka rolling upgrade lan konfigurasi dinamis ing Kubernetes;
• Filter protokol utusan kanggo Kafka, bolong.

Nalika sampeyan arep masang kluster Kafka ing Kubernetes, sampeyan bakal ngadhepi tantangan kanggo nemtokake ukuran optimal saka prasarana dhasar lan perlu kanggo nyetel konfigurasi Kafka kanggo nyukupi syarat throughput. Kinerja maksimal saben broker ditemtokake dening kinerja komponen infrastruktur sing ndasari, kayata memori, prosesor, kacepetan disk, bandwidth jaringan, lsp.

Saenipun, konfigurasi broker kudu kaya kabeh unsur infrastruktur digunakake kanggo kapabilitas maksimal. Nanging, ing urip nyata, persiyapan iki cukup rumit. Luwih akeh pangguna bakal ngatur makelar kanggo ngoptimalake panggunaan siji utawa rong komponen (disk, memori, utawa prosesor). Umumé, broker nuduhake kinerja maksimal nalika konfigurasi ngidini komponen sing paling alon digunakake kanthi maksimal. Kanthi cara iki, kita bisa entuk gagasan kasar babagan beban sing bisa ditangani dening broker.

Secara teoritis, kita uga bisa ngira jumlah makelar sing dibutuhake kanggo nangani beban sing diwenehake. Nanging, ing laku ana akeh opsi konfigurasi ing tingkat sing beda-beda sing angel banget (yen ora mokal) kanggo ngevaluasi kinerja potensial konfigurasi tartamtu. Ing tembung liyane, iku angel banget kanggo rencana konfigurasi adhedhasar sawetara kinerja tartamtu.

Kanggo pangguna Supertubes, kita biasane njupuk pendekatan ing ngisor iki: kita miwiti karo sawetara konfigurasi (infrastruktur + setelan), banjur ngukur kinerja, nyetel setelan broker lan mbaleni proses maneh. Iki kedadeyan nganti komponen infrastruktur sing paling alon digunakake.

Kanthi cara iki, kita entuk ide sing luwih jelas babagan pirang-pirang makelar kluster sing kudu nangani beban tartamtu (jumlah makelar uga gumantung saka faktor liya, kayata jumlah minimal replika pesen kanggo njamin ketahanan, jumlah partisi. pimpinan lsp). Kajaba iku, kita entuk wawasan babagan komponen infrastruktur sing mbutuhake skala vertikal.

Artikel iki bakal ngomong babagan langkah-langkah sing ditindakake kanggo ngoptimalake komponen sing paling alon ing konfigurasi awal lan ngukur throughput kluster Kafka. Konfigurasi sing tahan banting mbutuhake paling ora telung makelar sing mlaku (min.insync.replicas=3), disebarake ing telung zona aksesibilitas sing beda. Kanggo ngatur, skala lan ngawasi infrastruktur Kubernetes, kita nggunakake platform manajemen wadah dhewe kanggo awan hibrida - Pipeline. Ndhukung on-premise (bare metal, VMware) lan limang jinis awan (Alibaba, AWS, Azure, Google, Oracle), uga kombinasi apa wae.

Pikiran babagan infrastruktur lan konfigurasi kluster Kafka

Kanggo conto ing ngisor iki, kita milih AWS minangka panyedhiya maya lan EKS minangka distribusi Kubernetes. Konfigurasi sing padha bisa ditindakake kanthi nggunakake P.K.E. - Distribusi Kubernetes saka Banzai Cloud, disertifikasi dening CNCF.

disk

Amazon nawakake macem-macem Jinis volume EBS. Ing inti gp2 и io1 ana SSD drive, Nanging, kanggo mesthekake throughput dhuwur gp2 nganggo kredit akumulasi (Kredit I/O), supaya kita seneng jinis io1, sing nawakake throughput dhuwur sing konsisten.

Tipe Instance

Kinerja Kafka gumantung banget marang cache kaca sistem operasi, mula kita butuh conto kanthi memori sing cukup kanggo para makelar (JVM) lan cache kaca. Kayata c5.2x gedhe - wiwitan apik, awit wis 16 GB memori lan optimized kanggo bisa karo EBS. Kekurangane yaiku mung bisa nyedhiyakake kinerja maksimal ora luwih saka 30 menit saben 24 jam. Yen beban kerja mbutuhake kinerja puncak sajrone wektu sing luwih suwe, sampeyan bisa uga pengin nimbang jinis conto liyane. Sing persis apa kita nindakake, mandheg ing c5.4x gedhe. Iku menehi throughput maksimum ing 593,75 Mb/s. Maksimum throughput volume EBS io1 luwih dhuwur tinimbang conto c5.4x gedhe, dadi unsur paling alon saka infrastruktur kasebut bisa uga dadi throughput I/O saka jinis conto iki (sing uga kudu dikonfirmasi dening tes beban).

Jaringan

Output jaringan kudu cukup gedhe dibandhingake karo kinerja conto VM lan disk, yen ora jaringan dadi bottleneck. Ing kasus kita, antarmuka jaringan c5.4x gedhe ndhukung kecepatan nganti 10 Gb / s, kang Ngartekno luwih saka I / O throughput saka VM Kayata.

Penyebaran Broker

Broker kudu disebarake (dijadwalake ing Kubernetes) menyang node khusus supaya ora saingan karo proses liyane kanggo CPU, memori, jaringan, lan sumber daya disk.

versi jawa

Pilihan logis Jawa 11 amarga kompatibel karo Docker ing pangertèn sing JVM bener nemtokake pemroses lan memori kasedhiya kanggo wadhah kang makelar mlaku. Ngerti manawa watesan CPU penting, JVM sacara internal lan transparan nyetel jumlah benang GC lan benang JIT. Kita nggunakake gambar Kafka banzaicloud/kafka:2.13-2.4.0, sing kalebu Kafka versi 2.4.0 (Scala 2.13) ing Java 11.

Yen sampeyan pengin sinau luwih lengkap babagan Java/JVM ing Kubernetes, priksa kiriman ing ngisor iki:

• Napa aplikasi Java saya OOMKilled;
• Carane bener ukuran kontaner kanggo Java 10 aplikasi.

Setelan memori broker

Ana rong aspek penting kanggo ngatur memori broker: setelan kanggo JVM lan kanggo pod Kubernetes. Watesan memori sing disetel kanggo pod kudu luwih gedhe tinimbang ukuran tumpukan maksimum supaya JVM nduweni ruang kanggo metaspace Jawa sing manggon ing memori dhewe lan kanggo cache kaca sistem operasi sing aktif digunakake Kafka. Ing tes kita ngluncurake makelar Kafka kanthi paramèter -Xmx4G -Xms2G, lan watesan memori kanggo polong ana 10 Gi. Elinga yen setelan memori kanggo JVM bisa dipikolehi kanthi otomatis nggunakake -XX:MaxRAMPercentage и -X:MinRAMPercentage, adhedhasar watesan memori kanggo polong.

Setelan prosesor broker

Umumé, sampeyan bisa nambah kinerja kanthi nambah paralelisme kanthi nambah jumlah utas sing digunakake dening Kafka. Luwih akeh prosesor sing kasedhiya kanggo Kafka, luwih apik. Ing test kita, kita miwiti karo watesan 6 prosesor lan mboko sithik (liwat iterasi) mundhakaken nomer kanggo 15. Kajaba iku, kita nyetel num.network.threads=12 ing setelan broker kanggo nambah nomer Utas sing nampa data saka jaringan lan ngirim. Langsung nemokake yen makelar pengikut ora bisa nampa replika kanthi cepet, dheweke mundhak num.replica.fetchers kanggo 4 kanggo nambah kacepetan ing makelar pandherekipun replikasi pesen saka pemimpin.

Alat Generasi Beban

Sampeyan kudu mesthekake yen generator beban sing dipilih ora entek kapasitas sadurunge kluster Kafka (sing lagi ditandhani) tekan beban maksimal. Ing tembung liyane, iku perlu kanggo nindakake Assessment pambuka saka kabisan saka alat generasi mbukak, lan uga milih jinis conto karo nomer cukup prosesor lan memori. Ing kasus iki, alat kita bakal ngasilake beban luwih akeh tinimbang sing bisa ditangani kluster Kafka. Sawise akeh nyobi, kita mapan ing telung salinan c5.4x gedhe, saben kang wis generator mlaku.

Benchmarking

Pangukuran kinerja minangka proses iteratif sing kalebu tahapan ing ngisor iki:

• nyiyapake infrastruktur (kluster EKS, kluster Kafka, alat generasi beban, uga Prometheus lan Grafana);
• ngasilake beban kanggo wektu tartamtu kanggo nyaring panyimpangan acak ing indikator kinerja sing diklumpukake;
• nyetel infrastruktur lan konfigurasi makelar adhedhasar indikator kinerja sing diamati;
• mbaleni proses nganti tingkat sing dibutuhake saka Kafka cluster throughput wis ngrambah. Ing wektu sing padha, iku kudu konsisten reproducible lan nuduhake variasi minimal ing throughput.

Bagean sabanjure nggambarake langkah-langkah sing ditindakake sajrone proses benchmarking cluster test.

Piranti

Piranti ing ngisor iki digunakake kanggo masang konfigurasi baseline kanthi cepet, ngasilake beban, lan ngukur kinerja:

• Banzai Cloud Pipeline kanggo ngatur kluster EKS saka Amazon c Prometheus (kanggo ngumpulake Kafka lan infrastruktur metrik) lan Grafana (kanggo nggambarake metrik kasebut). We njupuk kauntungan terpadu в Pipeline layanan sing nyedhiyakake pemantauan federasi, koleksi log terpusat, pindai kerentanan, pemulihan bencana, keamanan kelas perusahaan lan liya-liyane.
• Sangrenel - alat kanggo mbukak testing kluster Kafka.
• Dashboard Grafana kanggo nggambarake metrik lan infrastruktur Kafka: Kubernetes Kafka, Node Eksportir.
• Supertubes CLI kanggo cara paling gampang kanggo nyetel kluster Kafka ing Kubernetes. Zookeeper, operator Kafka, Utusan lan akeh komponen liyane diinstal lan dikonfigurasi kanthi bener kanggo mbukak kluster Kafka sing siap produksi ing Kubernetes.
  • Kanggo instalasi supertube CLI gunakake instruksi sing diwenehake kene.

Kluster EKS

Siapke kluster EKS kanthi node pekerja khusus c5.4x gedhe ing zona kasedhiyan beda kanggo pods karo makelar Kafka, uga simpul darmabakti kanggo generator mbukak lan infrastruktur ngawasi.

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

Sawise kluster EKS wis aktif, aktifake terpadu layanan ngawasi - dheweke bakal masang Prometheus lan Grafana menyang kluster.

Komponen sistem Kafka

Instal komponen sistem Kafka (Zookeeper, kafka-operator) ing EKS nggunakake supertubes CLI:

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

Kluster Kafka

Kanthi gawan, EKS nggunakake jinis volume EBS gp2, dadi sampeyan kudu nggawe kelas panyimpenan kapisah adhedhasar volume io1 kanggo kluster 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

Setel parameter kanggo makelar min.insync.replicas=3 lan pasang pod broker ing simpul ing telung zona kasedhiyan sing beda:

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

Topik

We mlayu telung kedadean generator mbukak ing podo karo. Saben wong nulis menyang topik dhewe, yaiku, total telung topik:

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

Kanggo saben topik, faktor replikasi yaiku 3-nilai minimal sing disaranake kanggo sistem produksi sing kasedhiya.

Alat Generasi Beban

We dibukak telung salinan generator mbukak (saben siji wrote ing topik kapisah). Kanggo polong generator beban, sampeyan kudu nyetel afinitas simpul supaya dijadwalake mung ing simpul sing diwenehake kanggo dheweke:

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

Sawetara poin sing kudu dicathet:

• Generator beban ngasilake pesen kanthi dawa 512 bita lan nerbitake menyang Kafka kanthi batch 500 pesen.
• Nggunakake argumentasi -required-acks=all Publikasi kasebut dianggep sukses nalika kabeh replika pesen sing disinkronake ditampa lan dikonfirmasi dening makelar Kafka. Iki tegese ing pathokan, kita ora mung ngukur kacepetan pimpinan nampa pesen, nanging uga para pengikute niru pesen. Tujuan saka tes iki ora kanggo ngevaluasi kacepetan maca konsumen (konsumen) pesen bubar ditampa sing isih tetep ing cache kaca OS, lan comparison karo kacepetan maca pesen disimpen ing disk.
• Generator beban mbukak 20 tenaga kerja paralel (-workers=20). Saben buruh ngemot 5 produser sing nuduhake sambungan buruh menyang kluster Kafka. Akibaté, saben generator wis 100 prodhusèn, lan kabeh padha ngirim pesen menyang klompok Kafka.

Monitoring kesehatan klaster

Sajrone uji coba kluster Kafka, kita uga ngawasi kesehatane kanggo mesthekake yen ora ana maneh pod, ora ana replika sing ora sinkron, lan throughput maksimal kanthi fluktuasi minimal:

• Generator beban nulis statistik standar babagan jumlah pesen sing diterbitake lan tingkat kesalahan. Tingkat kesalahan kudu tetep padha 0,00%.
• Kontrol Cruise, disebarake dening kafka-operator, menehi dashboard ngendi kita uga bisa ngawasi negara kluster. Kanggo ndeleng panel iki, tindakake:

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

• tingkat ISR (jumlah replika "in-sync") nyusut lan ekspansi padha karo 0.

Asil pangukuran

3 makelar, ukuran pesen - 512 bait

Kanthi partisi sing disebarake kanthi rata ing telung makelar, kita bisa entuk kinerja ~500 Mb/s (udakara 990 ewu pesen per detik):

Konsumsi memori mesin virtual JVM ora ngluwihi 2 GB:

Disk throughput tekan maksimal I/O node throughput ing kabeh telung kasus nalika makelar mlaku:

Saka data babagan panggunaan memori kanthi simpul, mula buffering sistem lan caching njupuk ~ 10-15 GB:

3 makelar, ukuran pesen - 100 bait

Nalika ukuran pesen suda, throughput mudhun kira-kira 15-20%: wektu sing digunakake kanggo ngolah saben pesen bakal mengaruhi. Kajaba iku, beban prosesor meh tikel kaping pindho.

Amarga node broker isih duwe inti sing ora digunakake, kinerja bisa ditingkatake kanthi ngganti konfigurasi Kafka. Iki dudu tugas sing gampang, mula kanggo nambah throughput luwih becik nggarap pesen sing luwih gedhe.

4 makelar, ukuran pesen - 512 bait

Sampeyan bisa kanthi gampang nambah kinerja kluster Kafka kanthi mung nambahake makelar anyar lan njaga keseimbangan partisi (iki njamin beban kasebut disebarake kanthi rata ing antarane makelar). Ing kasus kita, sawise nambahake makelar, throughput kluster tambah dadi ~580 Mb/s (~1,1 yuta pesen per detik). Wutah dadi kurang saka samesthine: iki utamané diterangake dening boten seimbang kalebet partisi (ora kabeh makelar bisa ing puncak kapabilitas).

Konsumsi memori mesin JVM tetep ing ngisor 2 GB:

Pakaryan makelar kanthi drive kena pengaruh ora seimbang karo partisi:

temonan

Pendekatan iteratif sing ditampilake ing ndhuwur bisa ditambahake kanggo nyakup skenario sing luwih rumit sing nglibatake atusan konsumen, partisi ulang, nganyari nganyari, miwiti maneh pod, lsp. Kabeh iki ngidini kita kanggo netepke watesan saka Kapabilitas klompok Kafka ing macem-macem kahanan, ngenali bottlenecks ing operasi lan golek cara kanggo pertempuran mau.

Kita ngrancang Supertubes kanthi cepet lan gampang nyebarake kluster, ngatur, nambah / mbusak makelar lan topik, nanggapi tandha, lan njamin Kafka umume bisa digunakake kanthi bener ing Kubernetes. Tujuane kanggo mbantu sampeyan konsentrasi ing tugas utama ("ngasilake" lan "nganggo" pesen Kafka), lan ninggalake kabeh kerja keras kanggo Supertubes lan operator Kafka.

Yen sampeyan kasengsem ing teknologi Banzai Cloud lan proyek Open Source, langganan perusahaan ing GitHub, LinkedIn utawa Twitter.

PS saka penerjemah

Waca uga ing blog kita:

• «Siji crita karo operator Redis ing K8s lan mini-review keperluan kanggo nganalisa data saka database iki";
• «Migrasi lancar saka RabbitMQ menyang Kubernetes";
• «zetcd saka CoreOS: Ngganti ZooKeeper karo ... etc".

Source: www.habr.com