Nangtukeun ukuran anu pas pikeun klaster Kafka di Kubernetes

Catetan. narjamahkeun.: Dina artikel ieu, Banzai Cloud babagi conto kumaha parabot custom na bisa dipaké sangkan Kafka gampang dipaké dina Kubernetes. Parentah di handap ieu ngagambarkeun kumaha anjeun tiasa nangtukeun ukuran optimal infrastruktur anjeun sareng ngonpigurasikeun Kafka sorangan pikeun ngahontal throughput anu diperyogikeun.

Apache Kafka mangrupikeun platform streaming anu disebarkeun pikeun nyiptakeun sistem streaming real-time anu tiasa dipercaya, skalabel sareng kinerja tinggi. Kamampuhan anu pikaresepeun tiasa diperpanjang nganggo Kubernetes. Pikeun ieu kami geus dimekarkeun Open Source Kafka operator jeung alat disebut Supertubes. Aranjeunna ngidinan Anjeun pikeun ngajalankeun Kafka on Kubernetes tur ngagunakeun rupa fitur na, kayaning fine-tuning konfigurasi calo, skala dumasar métrik kalawan rebalancing, kasadaran rak, "lemes" (anggun) rolling kaluar apdet, jsb.

Coba Supertubes dina klaster anjeun:

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

Atawa kontak dokuméntasi. Anjeun ogé tiasa maca ngeunaan sababaraha kamampuan Kafka, karya anu otomatis nganggo operator Supertubes sareng Kafka. Kami parantos nyerat ngeunaan aranjeunna dina blog:

• Oh henteu! Acan operator Kafka sejen pikeun Kubernetes;
• Ngawas sareng ngoperasikeun Kafka dumasar kana métrik Prometheus;
• Kafka rak kasadaran on Kubernetes;
• Ngajalankeun Apache Kafka leuwih Istio - patokan;
• Pamaké dioténtikasi sareng ngaksés klaster anu dikontrol sareng operator Kafka;
• Kafka rolling pamutahiran sarta konfigurasi dinamis dina Kubernetes;
• Filter protokol utusan pikeun Kafka, meshed.

Nalika anjeun mutuskeun pikeun nyebarkeun klaster Kafka dina Kubernetes, anjeun kamungkinan bakal disanghareupan tangtangan pikeun nangtukeun ukuran optimal infrastruktur dasar sareng kabutuhan pikeun nyaluyukeun konfigurasi Kafka anjeun pikeun nyumponan syarat throughput. Kinerja maksimum unggal calo ditangtukeun ku kinerja komponén infrastruktur dasar, kayaning memori, processor, speed disk, rubakpita jaringan, jsb.

Ideally, konfigurasi calo kedah sapertos nu sakabeh elemen infrastruktur dipaké pikeun kamampuhan maksimum maranéhanana. Nanging, dina kahirupan nyata setelan ieu rada rumit. Éta langkung dipikaresep yén pangguna bakal ngonpigurasikeun calo pikeun maksimalkeun panggunaan hiji atanapi dua komponén (disk, mémori, atanapi prosesor). Umumna disebutkeun, calo nembongkeun kinerja maksimum lamun konfigurasi na ngamungkinkeun komponén slowest dipaké pikeun extent na fullest. Ku cara ieu urang tiasa nampi ide kasar ngeunaan beban anu tiasa ditanggung ku hiji calo.

Téoritis, urang ogé bisa estimasi jumlah calo diperlukeun pikeun nanganan beban dibikeun. Nanging, dina prakna aya seueur pilihan konfigurasi dina tingkat anu béda-béda éta hésé pisan (upami teu mungkin) pikeun ngira-ngira kinerja poténsial tina konfigurasi tinangtu. Kalayan kecap séjén, éta hésé pisan rencana a konfigurasi dumasar kana sababaraha kinerja dibikeun.

Pikeun pamaké Supertubes, urang biasana nyokot pendekatan handap: urang mimitian ku sababaraha konfigurasi (infrastruktur + setélan), lajeng ngukur kinerja na, nyaluyukeun setelan calo tur ngulang prosés deui. Ieu lumangsung nepi ka komponén slowest tina infrastruktur geus garapan pinuh.

Ku cara kieu, urang nampi ide anu langkung jelas ngeunaan sabaraha calo anu kluster kedah nanganan beban anu tangtu (jumlah calo ogé gumantung kana faktor sanés, sapertos jumlah minimum réplika pesen pikeun mastikeun ketahanan, jumlah partisi. pamingpin, jsb). Salaku tambahan, urang kéngingkeun wawasan ngeunaan komponén infrastruktur mana anu peryogi skala vertikal.

Tulisan ieu bakal nyarioskeun léngkah-léngkah anu urang lakukeun pikeun ngamaksimalkeun komponén anu paling laun dina konfigurasi awal sareng ngukur throughput tina klaster Kafka. Konfigurasi anu pohara tahan banting merlukeun sahenteuna tilu calo ngajalankeun (min.insync.replicas=3), disebarkeun ka tilu zona aksés anu béda. Pikeun ngonpigurasikeun, skala sareng ngawas infrastruktur Kubernetes, kami nganggo platform manajemén wadahna sorangan pikeun awan hibrid - pipa. Ieu ngarojong on-premise (logam bulistir, VMware) jeung lima jenis awan (Alibaba, AWS, Azure, Google, Oracle), kitu ogé sagala kombinasi aranjeunna.

Pikiran ngeunaan infrastruktur klaster Kafka sareng konfigurasi

Pikeun conto di handap, kami milih AWS salaku panyadia awan sareng EKS salaku distribusi Kubernetes. Konfigurasi anu sami tiasa dilaksanakeun nganggo P.K.E. - Distribusi Kubernetes ti Banzai Cloud, disertipikasi ku CNCF.

cakram

Amazon nawarkeun rupa-rupa Jenis volume EBS. Dina inti gp2 и io1 aya SSD drive, kumaha oge, pikeun mastikeun throughput tinggi gp2 meakeun sks akumulasi (Kredit I/O), janten urang langkung milih jinisna io1, nu nawarkeun throughput tinggi konsisten.

Jenis conto

Kinerja Kafka gumantung pisan kana cache halaman sistem operasi, ku kituna urang peryogi conto kalayan mémori anu cukup pikeun calo (JVM) sareng cache halaman. Contona c5.2x badag - mimiti alus, saprak éta boga 16 GB memori sareng dioptimalkeun pikeun gawé bareng EBS. Karugianna nyaéta ngan ukur tiasa nyayogikeun pagelaran maksimal henteu langkung ti 30 menit unggal 24 jam. Upami beban kerja anjeun peryogi kinerja puncak dina waktos anu langkung lami, anjeun panginten hoyong mertimbangkeun jinis conto anu sanés. Éta kahayang urang ngalakukeun, eureun di c5.4x badag. Eta nyadiakeun throughput maksimum dina 593,75 Mb/s. throughput maksimum hiji volume EBS io1 leuwih luhur ti conto c5.4x badag, janten unsur anu paling laun tina infrastruktur sigana mangrupikeun throughput I / O tina jinis conto ieu (anu ogé kedah dipastikeun ku tés beban urang).

jaringan

The throughput jaringan kudu cukup badag dibandingkeun kinerja conto VM na disk, disebutkeun jaringan jadi bottleneck a. Dina kasus urang, panganteur jaringan c5.4x badag ngarojong speeds nepi ka 10 Gb / s, nu nyata leuwih luhur ti I / O throughput hiji conto VM.

Panyebaran calo

Calo kedah disebarkeun (dijadwalkeun dina Kubernetes) ka titik khusus pikeun nyegah bersaing sareng prosés séjén pikeun CPU, mémori, jaringan, sareng sumber disk.

Vérsi Java

Pilihan logis nyaéta Java 11 sabab cocog sareng Docker dina harti yén JVM leres-leres nangtukeun prosesor sareng mémori anu sayogi pikeun wadah dimana calo dijalankeun. Nyaho yén wates CPU penting, JVM sacara internal sareng transparan netepkeun jumlah benang GC sareng benang JIT. Kami nganggo gambar Kafka banzaicloud/kafka:2.13-2.4.0, nu ngawengku Kafka vérsi 2.4.0 (Scala 2.13) dina Java 11.

Upami anjeun hoyong langkung seueur ngeunaan Java/JVM dina Kubernetes, pariksa tulisan kami di handap ieu:

• Naha aplikasi Java abdi OOMKilled;
• Kumaha leres ukuran wadahna pikeun aplikasi Java 10.

Setélan mémori calo

Aya dua aspék konci pikeun ngonpigurasikeun mémori calo: setélan pikeun JVM sareng pod Kubernetes. Batesan mémori anu disetél pikeun pod kedah langkung ageung tibatan ukuran tumpukan maksimum supados JVM ngagaduhan rohangan pikeun metaspace Java, anu aya dina mémori sorangan, sareng pikeun cache halaman sistem operasi, anu aktip dianggo Kafka. Dina tés kami urang dibuka calo Kafka kalawan parameter -Xmx4G -Xms2G, jeung wates memori pikeun pod éta 10 Gi. Punten dicatet yén setélan mémori pikeun JVM tiasa didapet sacara otomatis nganggo -XX:MaxRAMPercentage и -X:MinRAMPercentage, dumasar kana wates memori pikeun pod.

Setélan prosésor calo

Sacara umum, anjeun tiasa ningkatkeun kinerja ku cara ningkatkeun paralelisme ku cara ningkatkeun jumlah benang anu dianggo ku Kafka. Langkung seueur prosesor anu sayogi pikeun Kafka, langkung saé. Dina uji kami, urang mimitian ku wates 6 prosesor sarta laun (ngaliwatan iterations) naek angka maranéhna pikeun 15. Sajaba ti éta, urang nyetel. num.network.threads=12 dina setélan calo pikeun ngaronjatkeun jumlah threads nu narima data ti jaringan sarta ngirimkeunana. Langsung manggihan yén calo follower teu bisa nampa réplika cukup gancang, aranjeunna diangkat num.replica.fetchers ka 4 pikeun ngaronjatkeun kagancangan nu calo follower replicated pesen ti pamingpin.

Alat Generasi Beban

Anjeun kedah mastikeun yén generator beban anu dipilih henteu béak kapasitas sateuacan klaster Kafka (anu tolok ukur) ngahontal beban maksimalna. Kalayan kecap séjén, perlu pikeun ngalakonan assessment awal tina kamampuhan alat generasi beban, sarta ogé milih tipe conto pikeun eta kalawan jumlah cukup prosesor sarta memori. Dina hal ieu, alat kami bakal ngahasilkeun langkung seueur beban tibatan klaster Kafka tiasa dicekel. Sanggeus loba percobaan, urang netep dina tilu salinan c5.4x badag, nu masing-masing miboga generator ngajalankeun.

Tolok ukur

Pangukuran kinerja mangrupikeun prosés iteratif anu kalebet tahap-tahap ieu:

• netepkeun infrastruktur (kluster EKS, kluster Kafka, alat generasi beban, ogé Prometheus sareng Grafana);
• ngahasilkeun beban pikeun periode nu tangtu pikeun nyaring simpangan acak dina indikator kinerja dikumpulkeun;
• nyaluyukeun infrastruktur calo jeung konfigurasi dumasar kana indikator kinerja observasi;
• malikan deui prosés nepi ka tingkat diperlukeun tina throughput klaster Kafka kahontal. Dina waktos anu sami, éta kedah konsistén tiasa diulang sareng nunjukkeun variasi minimal dina throughput.

Bagian salajengna ngajelaskeun léngkah-léngkah anu dilakukeun nalika prosés benchmarking klaster tés.

instrumen

Parabot di handap ieu dianggo pikeun gancang nyebarkeun konfigurasi dasar, ngahasilkeun beban, sareng ngukur kinerja:

• Banzai Cloud Pipeline pikeun ngatur hiji klaster EKS ti Amazon c Prometheus (pikeun ngumpulkeun Kafka sarta infrastruktur metrics) jeung grafana (pikeun visualize métrik ieu). Urang ngamangpaatkeun terpadu в pipa jasa anu nyayogikeun monitoring federasi, koleksi log terpusat, scanning kerentanan, pamulihan bencana, kaamanan kelas perusahaan sareng seueur deui.
• Sangrenel - alat pikeun nguji beban klaster Kafka.
• Dashboard Grafana pikeun ngabayangkeun métrik sareng infrastruktur Kafka: Kubernetes Kafka, Ékspor Node.
• Supertubes CLI pikeun cara panggampangna pikeun nyetél klaster Kafka dina Kubernetes. Zookeeper, operator Kafka, Utusan sareng seueur komponén sanésna dipasang sareng dikonpigurasi leres pikeun ngajalankeun klaster Kafka anu siap produksi dina Kubernetes.
  • Pikeun masang supertube CLI ngagunakeun parentah nu disadiakeun di dieu.

Klaster EKS

Nyiapkeun klaster EKS kalawan titik worker dedicated c5.4x badag dina zona kasadiaan anu béda pikeun pod sareng calo Kafka, ogé titik khusus pikeun generator beban sareng infrastruktur ngawaskeun.

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

Sakali klaster EKS naék sareng jalan, aktipkeun terpadu na jasa ngawaskeun - anjeunna bakal nyebarkeun Prometheus sareng Grafana kana klaster.

komponén Sistim Kafka

Pasang komponén sistem Kafka (Zookeeper, kafka-operator) dina EKS nganggo supertubes CLI:

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

Klaster Kafka

Sacara standar, EKS nganggo volume EBS tina jinis gp2, jadi Anjeun kudu nyieun hiji kelas gudang misah dumasar kana jilid io1 pikeun klaster 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

Nyetél parameter pikeun calo min.insync.replicas=3 sareng nyebarkeun pod calo dina titik dina tilu zona kasadiaan anu béda:

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

Jejer

Kami ngajalankeun tilu instansi generator beban paralel. Masing-masing nyerat kana topikna masing-masing, nyaéta, urang peryogi tilu 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

Pikeun unggal topik, faktor réplikasi nyaéta 3-nilai minimum anu disarankeun pikeun sistem produksi anu sayogi pisan.

Alat Generasi Beban

Kami ngaluncurkeun tilu salinan generator beban (masing-masing nyerat dina topik anu misah). Pikeun polong generator beban, anjeun kedah nyetél afinitas titik supados aranjeunna dijadwalkeun ukur dina titik anu dialokasikeun pikeun aranjeunna:

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

Sababaraha titik pikeun dicatet:

• Generator beban ngahasilkeun seratan panjangna 512 bait sareng nyebarkeun ka Kafka dina bets 500 pesen.
• Ngagunakeun argumen -required-acks=all Publikasi ieu dianggap suksés nalika sadaya réplika pesen anu disingkronkeun ditampi sareng dikonfirmasi ku calo Kafka. Ieu ngandung harti yén dina tolok ukur kami henteu ukur ngukur laju pamimpin nampi pesen, tapi ogé pengikutna ngulang pesen. Tujuan tina tés ieu sanés pikeun ngévaluasi kacepetan maca konsumen (konsumén) nembe nampi pesen anu masih aya dina cache halaman OS, sareng ngabandingkeunana sareng laju maca pesen anu disimpen dina disk.
• Generator beban ngajalankeun 20 pagawé paralel (-workers=20). Unggal pagawe ngandung 5 produser nu babagi sambungan worker ka klaster Kafka. Hasilna, unggal generator boga 100 produser, sarta aranjeunna sadayana ngirim pesen ka klaster Kafka.

Ngawas kaséhatan klaster

Salila nguji beban klaster Kafka, kami ogé ngawas kaséhatanna pikeun mastikeun teu aya pod restart, teu aya réplika anu teu sinkron, sareng throughput maksimal kalayan fluktuasi minimal:

• Generator beban nyerat statistik standar ngeunaan jumlah pesen anu diterbitkeun sareng tingkat kasalahan. Laju kasalahan kedah tetep sami 0,00%.
• Cruise Control, deployed ku kafka-operator, nyadiakeun dasbor dimana urang ogé bisa ngawas kaayaan klaster. Pikeun ningali panel ieu, lakukeun:

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

• tingkat ISR (Jumlah réplika "in-sync") ngaleutikan sareng ékspansi sami sareng 0.

Hasil pangukuran

3 calo, ukuran pesen - 512 bait

Kalayan partisi anu disebarkeun merata dina tilu calo, kami tiasa ngahontal prestasi ~500 Mb/s (kira-kira 990 rébu pesen per detik):

Konsumsi mémori mesin virtual JVM henteu ngaleuwihan 2 GB:

throughput disk ngahontal throughput titik I/O maksimum dina sakabéh tilu instansi nu calo ngajalankeun:

Tina data ngeunaan pamakean mémori ku simpul, éta nunjukkeun yén panyangga sistem sareng cache nyandak ~ 10-15 GB:

3 calo, ukuran pesen - 100 bait

Nalika ukuran pesen ngirangan, throughput turun kirang langkung 15-20%: waktos anu dianggo pikeun ngolah unggal pesen mangaruhan éta. Sajaba ti éta, beban processor ampir dua kali.

Kusabab titik calo masih gaduh cores anu henteu dianggo, kinerja tiasa ningkat ku ngarobih konfigurasi Kafka. Ieu sanés tugas anu gampang, janten pikeun ningkatkeun throughput langkung saé damel sareng pesen anu langkung ageung.

4 calo, ukuran pesen - 512 bait

Anjeun tiasa sacara gampil ningkatkeun kinerja hiji klaster Kafka ku saukur nambahkeun calo anyar jeung ngajaga kasaimbangan partitions (ieu ensures yén beban disebarkeun merata antara calo). Dina kasus urang, sanggeus nambahkeun calo a, throughput klaster ngaronjat nepi ~580 Mb/s (~1,1 juta pesen per detik). Tumuwuhna tétéla kirang ti diperkirakeun: ieu utamana dijelaskeun ku teu saimbangna partitions (teu sakabeh calo dianggo dina puncak kamampuhan maranéhanana).

Konsumsi memori mesin JVM tetep handap 2 GB:

Karya calo sareng drive kapangaruhan ku henteu saimbangna partisi:

papanggihan

Pendekatan iteratif anu disayogikeun di luhur tiasa dilegaan pikeun nutupan skénario anu langkung kompleks anu ngalibetkeun ratusan konsumen, partisi ulang, pembaruan ngagulung, ngamimitian deui pod, jsb. Sadaya ieu ngamungkinkeun urang pikeun meunteun wates kamampuan klaster Kafka dina sagala rupa kaayaan, ngaidentipikasi bottlenecks dina operasina sareng milarian cara pikeun meranganana.

Kami ngarancang Supertubes pikeun gancang sareng gampang nyebarkeun klaster, ngonpigurasikeunana, nambihan / ngahapus calo sareng topik, ngabales panggeuing, sareng mastikeun Kafka sacara umum tiasa dianggo leres dina Kubernetes. Tujuan kami nyaéta pikeun ngabantosan anjeun konsentrasi dina tugas utama ("ngahasilkeun" sareng "ngakonsumsi" pesen Kafka), sareng ngantepkeun sadaya kerja keras ka Supertubes sareng operator Kafka.

Upami anjeun kabetot dina téknologi Banzai Cloud sareng proyék Open Source, ngalanggan perusahaan di GitHub, LinkedIn atawa Twitter.

PS ti penerjemah

Baca ogé dina blog urang:

• «Hiji carita sareng operator Redis di K8s sareng ulasan mini ngeunaan utilitas pikeun nganalisis data tina pangkalan data ieu";
• «Seamless RabbitMQ ka migrasi Kubernetes";
• «zetcd ti CoreOS: Ngaganti ZooKeeper ku ... jsb gudang".

sumber: www.habr.com