Kubernetes дахь Кафка кластерт тохирох хэмжээг тодорхойл

Анхаарна уу. орчуулга.: Энэ нийтлэлд Banzai Cloud нь Кафкаг Кубернетес дотор ашиглахад хялбар болгохын тулд өөрийн тохируулсан хэрэгслүүдийг хэрхэн ашиглаж болох жишээг хуваалцаж байна. Дараах зааврууд нь дэд бүтцийнхээ оновчтой хэмжээг хэрхэн тодорхойлж, Кафка-г шаардлагатай дамжуулах чадварыг хангахын тулд хэрхэн тохируулахыг харуулсан болно.

Apache Kafka нь найдвартай, өргөтгөх боломжтой, өндөр хүчин чадалтай бодит цагийн урсгалын системийг бий болгох түгээх стриминг платформ юм. Түүний гайхалтай чадварыг Kubernetes ашиглан өргөжүүлж болно. Үүний тулд бид боловсруулсан Нээлттэй эхийн Кафка оператор гэж нэрлэдэг хэрэгсэл Супер хоолой. Эдгээр нь Кафка-г Kubernetes дээр ажиллуулж, брокерын тохиргоог нарийн тааруулах, хэмжүүрт суурилсан масштабыг дахин тэнцвэржүүлэх, тавиурын мэдлэг, "зөөлөн" гэх мэт төрөл бүрийн функцуудыг ашиглах боломжийг танд олгоно. (сайхан) шинэчлэлтүүдийг нэвтрүүлэх гэх мэт.

Кластер дээрээ Supertubes-ийг туршиж үзээрэй:

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

Эсвэл холбоо барина уу баримт бичиг. Та мөн Supertubes болон Kafka оператор ашиглан автоматжуулсан Кафкагийн зарим боломжуудын талаар уншиж болно. Бид тэдний тухай блог дээр аль хэдийн бичсэн:

• Өө үгүй ​​ээ! Kubernetes-ийн өөр нэг Кафка оператор;
• Prometheus хэмжүүр дээр үндэслэн Кафкаг хянаж, ажиллуул;
• Кубернетес дээрх Кафкагийн талаархи мэдлэг;
• Apache Kafka-г Istio дээр ажиллуулж байна - жишиг;
• Кафка операторын тусламжтайгаар хэрэглэгч баталгаажуулж, хяналттай кластерт хандах боломжтой;
• Kubernetes дээрх Кафкагийн эргэлдэж буй сайжруулалт ба динамик тохиргоо;
• Кафкагийн элч протокол шүүлтүүр, торон.

Та Кафка кластерийг Kubernetes дээр байрлуулахаар шийдсэн үед үндсэн дэд бүтцийн оновчтой хэмжээг тодорхойлох, дамжуулах чадварын шаардлагад нийцүүлэн Кафкагийн тохиргоогоо нарийн тааруулах шаардлагатай тулгарах болно. Брокер бүрийн хамгийн дээд гүйцэтгэл нь санах ой, процессор, дискний хурд, сүлжээний зурвасын өргөн гэх мэт үндсэн дэд бүтцийн бүрэлдэхүүн хэсгүүдийн гүйцэтгэлээр тодорхойлогддог.

Брокерын тохиргоо нь бүх дэд бүтцийн элементүүдийг хамгийн дээд хэмжээнд ашиглах боломжтой байх ёстой. Гэсэн хэдий ч бодит амьдрал дээр энэ тохиргоо нь нэлээд төвөгтэй байдаг. Хэрэглэгчид нэг эсвэл хоёр бүрэлдэхүүн хэсэг (диск, санах ой эсвэл процессор) ашиглахыг нэмэгдүүлэхийн тулд брокеруудыг тохируулах нь илүү магадлалтай юм. Ерөнхийдөө брокер нь тохиргоо нь хамгийн удаан бүрэлдэхүүн хэсгийг бүрэн хэмжээгээр ашиглах боломжийг олгодог бол хамгийн их гүйцэтгэлийг харуулдаг. Ингэснээр бид нэг брокерын ачааллыг барагдуулах боломжтой.

Онолын хувьд бид өгөгдсөн ачааллыг даван туулахад шаардагдах брокеруудын тоог бас тооцоолж болно. Гэсэн хэдий ч практик дээр янз бүрийн түвшний тохиргооны сонголтууд маш олон байдаг тул тодорхой тохиргооны боломжит гүйцэтгэлийг үнэлэхэд маш хэцүү (хэрэв боломжгүй бол). Өөрөөр хэлбэл, өгөгдсөн гүйцэтгэл дээр үндэслэн тохиргоог төлөвлөх нь маш хэцүү байдаг.

Supertubes хэрэглэгчдийн хувьд бид ихэвчлэн дараах хандлагыг баримталдаг: бид зарим тохиргооноос (дэд бүтэц + тохиргоо) эхэлж, дараа нь түүний гүйцэтгэлийг хэмжиж, брокерын тохиргоог тохируулж, үйл явцыг дахин давтана. Энэ нь дэд бүтцийн хамгийн удаан бүрэлдэхүүн хэсгийг бүрэн ашиглах хүртэл тохиолддог.

Ийм байдлаар бид кластерт тодорхой ачааллыг даах шаардлагатай хэдэн брокер шаардлагатай талаар илүү тодорхой ойлголттой болно (брокерын тоо нь уян хатан чанарыг хангахын тулд мессежийн хуулбарын хамгийн бага тоо, хуваалтын тоо гэх мэт бусад хүчин зүйлээс хамаарна. удирдагчид гэх мэт). Нэмж дурдахад бид ямар дэд бүтцийн бүрэлдэхүүн хэсгүүдэд босоо масштабтай байх шаардлагатай талаар ойлголттой болсон.

Энэ нийтлэлд эхний тохиргоонуудын хамгийн удаан бүрэлдэхүүн хэсгүүдээс хамгийн их ашиг хүртэх, Кафка кластерын нэвтрүүлэх чадварыг хэмжихийн тулд хийх алхамуудын талаар ярих болно. Өндөр уян хатан тохиргоонд дор хаяж гурван брокер ажиллах шаардлагатай (min.insync.replicas=3), гурван өөр хүртээмжтэй бүсэд тархсан. Kubernetes-ийн дэд бүтцийг тохируулах, масштаблах, хянахын тулд бид эрлийз үүлэнд зориулсан өөрийн контейнер менежментийн платформыг ашигладаг. Дамжуулах хоолой. Энэ нь газар дээрх (нүцгэн металл, VMware) болон таван төрлийн үүл (Alibaba, AWS, Azure, Google, Oracle) болон тэдгээрийн аль ч хослолыг дэмждэг.

Кафка кластерын дэд бүтэц, тохиргооны талаархи бодол

Доорх жишээнүүдийн хувьд бид үүлэн үйлчилгээ үзүүлэгчээр AWS, Kubernetes түгээлтээр EKS-ийг сонгосон. Үүнтэй төстэй тохиргоог ашиглан хэрэгжүүлж болно P.K.E. - CNCF баталгаажуулсан Banzai Cloud-аас Kubernetes түгээлт.

диск

Амазон олон төрлийн санал болгодог EBS дууны төрлүүд. Гол нь gp2 и io1 Гэсэн хэдий ч өндөр дамжуулах чадварыг хангахын тулд SSD хөтчүүд байдаг gp2 хуримтлагдсан зээлийг зарцуулдаг (Оролт/гаралтын кредит), тиймээс бид төрлийг илүүд үзсэн io1, энэ нь тогтвортой өндөр дамжуулах чадварыг санал болгодог.

Инстанцийн төрлүүд

Кафкагийн гүйцэтгэл нь үйлдлийн системийн хуудасны кэшээс ихээхэн хамаардаг тул бидэнд брокер (JVM) болон хуудасны кэш хангалттай санах ойтой жишээ хэрэгтэй. Жишээ c5.2x том - сайн эхлэл, учир нь энэ нь 16 ГБ санах ойтой бөгөөд EBS-тэй ажиллахад оновчтой болгосон. Үүний сул тал нь 30 цаг тутамд 24 минутаас илүүгүй хугацаанд хамгийн их гүйцэтгэлийг хангах чадвартай байдаг. Хэрэв таны ажлын ачаалал удаан хугацаанд дээд зэргийн гүйцэтгэлийг шаарддаг бол та бусад төрлийн жишээнүүдийг авч үзэхийг хүсч болно. Бид яг ийм зүйл хийсэн, зогссон c5.4x том. Энэ нь хамгийн их дамжуулах чадварыг өгдөг 593,75 Mb/s. EBS эзлэхүүний хамгийн их дамжуулах чадвар io1 жишээнээс өндөр байна c5.4x том, тиймээс дэд бүтцийн хамгийн удаан элемент нь энэ төрлийн инстанцийн оролт/гаралтын дамжуулалт байх магадлалтай (бидний ачааллын туршилт ч үүнийг батлах ёстой).

Сүлжээ

Сүлжээний нэвтрүүлэх чадвар нь VM жишээ болон дискний гүйцэтгэлтэй харьцуулахад хангалттай том байх ёстой, эс тэгвээс сүлжээ нь гацах болно. Манай тохиолдолд сүлжээний интерфейс c5.4x том 10 Гб/с хүртэлх хурдыг дэмждэг бөгөөд энэ нь VM жишээний оролт/гаралтын чадвараас хамаагүй өндөр юм.

Брокерын байршуулалт

Брокеруудыг CPU, санах ой, сүлжээ болон дискний нөөцийн хувьд бусад процессуудтай өрсөлдөхөөс зайлсхийхийн тулд тусгай зангилаанууд дээр (Кубернетес дэх хуваарьтай) байрлуулах хэрэгтэй.

Java хувилбар

Логик сонголт нь Java 11 юм, учир нь энэ нь JVM нь брокер ажиллаж байгаа контейнерт байгаа процессорууд болон санах ойг зөв тодорхойлдог гэсэн утгаараа Docker-тэй нийцдэг. CPU-ийн хязгаарлалтууд чухал гэдгийг мэдэж байгаа тул JVM нь GC thread болон JIT thread-ийн тоог дотооддоо болон ил тод байдлаар тохируулдаг. Бид Кафкагийн зургийг ашигласан banzaicloud/kafka:2.13-2.4.0, үүнд Java 2.4.0 дээрх Кафка хувилбар 2.13 (Scala 11) багтсан.

Хэрэв та Kubernetes дээрх Java/JVM-ийн талаар илүү ихийг мэдэхийг хүсвэл манай дараах бичлэгүүдийг үзээрэй.

• Яагаад миний Java програм OOMKilled вэ?;
• Java 10 програмын савны хэмжээг хэрхэн зөв хийх вэ.

Брокерын санах ойн тохиргоо

Брокерын санах ойг тохируулах хоёр үндсэн тал байдаг: JVM болон Kubernetes pod-ийн тохиргоо. Pod-д зориулсан санах ойн хязгаар нь хамгийн их овоолгын хэмжээнээс их байх ёстой бөгөөд ингэснээр JVM нь өөрийн санах ойд оршдог Java мета орон зай болон Кафкагийн идэвхтэй ашигладаг үйлдлийн системийн хуудасны кэштэй байх ёстой. Туршилтын үеэр бид параметр бүхий Кафка брокеруудыг ажиллуулсан -Xmx4G -Xms2G, мөн pod-ийн санах ойн хязгаар байсан 10 Gi. JVM-ийн санах ойн тохиргоог ашиглан автоматаар авах боломжтой гэдгийг анхаарна уу -XX:MaxRAMPercentage и -X:MinRAMPercentage, pod-ын санах ойн хязгаарт үндэслэсэн.

Брокерын процессорын тохиргоо

Ерөнхийдөө Кафкагийн ашигласан хэлхээний тоог нэмэгдүүлэх замаар параллелизмыг нэмэгдүүлэх замаар гүйцэтгэлийг сайжруулах боломжтой. Кафкагийн процессор хэдий чинээ олон байна төдий чинээ сайн. Туршилтдаа бид 6 процессорын хязгаартай байсан бөгөөд аажмаар (давталтаар) тэдний тоог 15 хүртэл нэмэгдүүлсэн. Үүнээс гадна бид тогтоосон num.network.threads=12 брокерын тохиргоонд сүлжээнээс өгөгдөл хүлээн авч илгээх урсгалын тоог нэмэгдүүлэх. Дагагч брокерууд хуулбарыг хангалттай хурдан хүлээн авах боломжгүй гэдгийг тэр даруй олж мэдээд тэд өсгөв num.replica.fetchers 4 хүртэл дагагч брокерууд удирдагчдын мессежийг хуулбарлах хурдыг нэмэгдүүлэх.

Ачаалал үүсгэх хэрэгсэл

Кафка кластер (шалгаж байгаа) хамгийн их ачаалалдаа хүрэхээс өмнө сонгосон ачааллын генераторын хүчин чадал дуусахгүй байх ёстой. Өөрөөр хэлбэл, ачаалал үүсгэх хэрэгслийн чадавхийн урьдчилсан үнэлгээг хийж, хангалттай тооны процессор, санах ойтой жишээний төрлийг сонгох шаардлагатай. Энэ тохиолдолд манай хэрэгсэл Кафка кластерын дааж чадахаас илүү ачаалал өгөх болно. Олон туршилт хийсний дараа бид гурван хувь дээр тогтсон c5.4x том, тус бүр нь генератор ажиллаж байсан.

Бенчмаркинг

Гүйцэтгэлийн хэмжилт нь дараах үе шатуудыг багтаасан давтагдах үйл явц юм.

• дэд бүтцийг бий болгох (EKS кластер, Кафка кластер, ачаалал үүсгэх хэрэгсэл, түүнчлэн Prometheus, Grafana);
• цуглуулсан гүйцэтгэлийн үзүүлэлтүүдийн санамсаргүй хазайлтыг шүүх тодорхой хугацаанд ачаалал үүсгэх;
• ажиглагдсан гүйцэтгэлийн үзүүлэлтүүд дээр үндэслэн брокерын дэд бүтэц, тохиргоог тохируулах;
• Кафка кластерын дамжуулах чадварын шаардлагатай түвшинд хүрэх хүртэл процессыг давтах. Үүний зэрэгцээ, энэ нь байнга давтагдах боломжтой байх ёстой бөгөөд дамжуулах чадварын хамгийн бага өөрчлөлтийг харуулах ёстой.

Дараагийн хэсэгт туршилтын кластерын жишиг үнэлгээний явцад хийгдсэн алхмуудыг тайлбарлана.

Хэрэгсэл

Суурь тохиргоог хурдан байршуулах, ачаалал үүсгэх, гүйцэтгэлийг хэмжихийн тулд дараах хэрэгслүүдийг ашигласан:

• Банзай үүл дамжуулах хоолой Amazon-аас EKS кластер зохион байгуулахад зориулж c Prometheus (Кафка болон дэд бүтцийн хэмжүүрүүдийг цуглуулах) болон Графана (эдгээр хэмжүүрүүдийг дүрслэн харуулахын тулд). Бид давуу талыг ашигласан нэгдсэн в Дамжуулах хоолой нэгдсэн хяналт, төвлөрсөн бүртгэл цуглуулах, эмзэг байдлын сканнердах, гамшгаас хамгаалах, аж ахуйн нэгжийн түвшний аюулгүй байдал болон бусад олон үйлчилгээг үзүүлдэг үйлчилгээ.
• Сангренел — Кафка кластерын ачааллыг шалгах хэрэгсэл.
• Кафкагийн хэмжүүр болон дэд бүтцийг дүрслэн харуулах Графана хяналтын самбар: Кубернетес Кафка, Зангилаа экспортлогч.
• Supertubes CLI нь Kubernetes дээр Кафка кластер үүсгэх хамгийн хялбар арга юм. Zookeeper, Kafka operator, Envoy болон бусад олон бүрэлдэхүүн хэсгүүдийг суулгаж, Kubernetes дээр үйлдвэрлэхэд бэлэн Кафка кластер ажиллуулахын тулд зөв тохируулсан.
  • Суулгахын тулд supertubes CLI өгсөн зааврыг ашиглана уу энд.

EKS кластер

Зориулалтын ажилчдын зангилаа бүхий EKS кластер бэлтгэх c5.4x том Кафка брокеруудтай pods, түүнчлэн ачаалал үүсгэгч болон хяналтын дэд бүтцэд зориулсан тусгай зангилаануудыг ашиглах боломжтой өөр өөр бүсэд.

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

EKS кластер ажиллаж дууссаны дараа түүний нэгдсэнийг идэвхжүүлнэ үү хяналтын үйлчилгээ - тэр Прометей, Графана хоёрыг кластерт байрлуулах болно.

Кафка системийн бүрэлдэхүүн хэсгүүд

Supertubes CLI ашиглан EKS-д Кафка системийн бүрэлдэхүүн хэсгүүдийг (Zookeeper, kafka-operator) суулгана уу:

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

Кафка кластер

Анхдагч байдлаар, EKS нь EBS төрлийн төрлийн хэмжээг ашигладаг gp2, тиймээс та эзлэхүүн дээр үндэслэн тусдаа хадгалах анги үүсгэх хэрэгтэй io1 Кафка кластерын хувьд:

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 мөн гурван өөр боломжит бүсийн зангилаанууд дээр брокер подкуудыг байрлуул:

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

Сэдэв

Бид гурван ачааллын генераторыг зэрэгцүүлэн ажиллуулсан. Тэд тус бүр өөрийн сэдвээр бичдэг, өөрөөр хэлбэл бидэнд нийт гурван сэдэв хэрэгтэй болно.

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 буюу өндөр боломжтой үйлдвэрлэлийн системд санал болгож буй хамгийн бага утга юм.

Ачаалал үүсгэх хэрэгсэл

Бид ачааллын үүсгүүрийн гурван хувийг (тус бүрийг тусдаа сэдвээр бичсэн) эхлүүлсэн. Ачаалал үүсгэгч хонхорцогуудын хувьд та зангилааны хамаарлыг тохируулах хэрэгтэй бөгөөд ингэснээр тэдгээрийг зөвхөн тэдгээрт хуваарилагдсан зангилаанууд дээр хуваарилах болно.

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 мессежийн багцаар нийтэлдэг.
• Аргумент ашиглах -required-acks=all Мессежийн бүх синхрончлогдсон хуулбарыг Кафка брокерууд хүлээн авч, баталгаажуулсан тохиолдолд хэвлэлийг амжилттай гэж үзнэ. Энэ нь жишигт бид зөвхөн удирдагчдын мессеж хүлээн авах хурдыг хэмжсэн төдийгүй тэдний дагалдагчдын мессежийг хуулбарласан гэсэн үг юм. Энэхүү тестийн зорилго нь хэрэглэгчийн унших хурдыг үнэлэхэд ороогүй болно (хэрэглэгч) Саяхан хүлээн авсан мессежүүд нь үйлдлийн системийн хуудасны кэшэд хэвээр байгаа бөгөөд тэдгээрийг дискэнд хадгалагдсан мессежүүдийн унших хурдтай харьцуулсан болно.
• Ачаалал үүсгэгч нь 20 ажилчдыг зэрэгцээ ажиллуулдаг (-workers=20). Ажилчин бүр нь Кафка кластертай ажилчдын холболтыг хуваалцдаг 5 үйлдвэрлэгчийг агуулдаг. Үүний үр дүнд генератор бүр 100 үйлдвэрлэгчтэй бөгөөд тэд бүгд Кафка кластерт мессеж илгээдэг.

Кластерын эрүүл мэндэд хяналт тавих

Кафка кластерын ачааллыг турших явцад бид түүний эрүүл мэндэд хяналт тавьж, ямар ч pod дахин эхлүүлэх, синхрончлолгүй хуулбар байхгүй, хамгийн бага хэлбэлзэлтэй хамгийн их дамжуулах чадварыг баталгаажуулсан.

• Ачаалал үүсгэгч нь нийтлэгдсэн мессежийн тоо болон алдааны түвшний талаархи стандарт статистикийг бичдэг. Алдааны түвшин ижил хэвээр байх ёстой 0,00%.
• Хурд тогтоон баригч, kafka-операторын байрлуулсан бөгөөд бид кластерийн төлөвийг хянах боломжтой хяналтын самбарыг өгдөг. Энэ самбарыг үзэхийн тулд:

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

• ISR түвшин ("синк хийсэн" хуулбарын тоо) агшилт ба тэлэлт нь 0-тэй тэнцүү байна.

Хэмжилтийн үр дүн

3 брокер, мессежийн хэмжээ - 512 байт

Гурван брокер дээр жигд хуваарилагдсан хуваалтуудын ачаар бид гүйцэтгэлд хүрч чадсан ~500 Mb/s (секундэд ойролцоогоор 990 мянган мессеж):

JVM виртуал машины санах ойн хэрэглээ 2 ГБ-аас хэтрэхгүй байна:

Дискний дамжуулах чадвар нь брокеруудын ажиллаж байсан бүх гурван тохиолдлын хувьд оролт/гаралтын зангилааны дамжуулах чадварын дээд хэмжээнд хүрсэн:

Зангилааны санах ойн ашиглалтын өгөгдлөөс харахад системийн буфер болон кэш нь ~10-15 ГБ зарцуулсан байна.

3 брокер, мессежийн хэмжээ - 100 байт

Мессежийн хэмжээ багасах тусам дамжуулах чадвар нь ойролцоогоор 15-20% буурдаг: мессеж бүрийг боловсруулахад зарцуулсан хугацаа үүнд нөлөөлдөг. Үүнээс гадна процессорын ачаалал бараг хоёр дахин нэмэгдсэн байна.

Брокерын зангилаанууд ашиглагдаагүй цөмтэй хэвээр байгаа тул Кафкагийн тохиргоог өөрчлөх замаар гүйцэтгэлийг сайжруулж болно. Энэ бол амар ажил биш тул дамжуулах чадварыг нэмэгдүүлэхийн тулд илүү том мессежүүдтэй ажиллах нь дээр.

4 брокер, мессежийн хэмжээ - 512 байт

Та зүгээр л шинэ брокер нэмж, хуваалтын тэнцвэрийг хадгалах замаар Кафка кластерын гүйцэтгэлийг хялбархан нэмэгдүүлэх боломжтой (энэ нь брокеруудын хооронд ачааллыг жигд хуваарилах боломжийг олгоно). Манай тохиолдолд брокер нэмсний дараа кластерын дамжуулалт хүртэл нэмэгдсэн ~580 Mb/s (~1,1 сая мессеж секундэд). Өсөлт нь хүлээгдэж байснаас бага байна: энэ нь голчлон хуваалтуудын тэнцвэргүй байдалтай холбоотой (бүх брокерууд чадварынхаа оргил үед ажилладаггүй).

JVM машины санах ойн хэрэглээ 2 ГБ-аас бага хэвээр байна:

Хуваалтуудын тэнцвэргүй байдал нь хөтчүүдтэй брокеруудын ажилд нөлөөлсөн.

үр дүн нь

Дээр дурдсан давталтын аргыг олон зуун хэрэглэгч, дахин хуваах, шилжүүлэх шинэчлэлт, pod дахин эхлүүлэх гэх мэт илүү төвөгтэй хувилбаруудыг хамрахын тулд өргөжүүлж болно. Энэ бүхэн нь янз бүрийн нөхцөлд Кафка кластерийн чадавхийн хязгаарыг үнэлэх, үйл ажиллагаанд нь саад тотгор учруулах, түүнтэй тэмцэх арга замыг олох боломжийг олгодог.

Бид Supertubes-ийг кластерыг хурдан бөгөөд хялбар байрлуулах, тохируулах, брокер болон сэдвүүдийг нэмэх/хасах, сэрэмжлүүлэгт хариу өгөх, ерөнхийдөө Кафкаг Кубернетес дээр зөв ажиллуулах зорилгоор зохион бүтээсэн. Бидний зорилго бол таныг үндсэн ажилдаа ("Кафка мессеж үүсгэх", "хэрэглэх") анхаарлаа төвлөрүүлэхэд нь туслах бөгөөд бүх шаргуу ажлыг Supertubes болон Кафка операторт даатгах явдал юм.

Хэрэв та Banzai Cloud технологи, Нээлттэй эхийн төслүүдийг сонирхож байгаа бол компанид бүртгүүлнэ үү GitHub, LinkedIn буюу Twitter.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

• «K8s дээрх Redis оператортой хийсэн нэг түүх, энэ мэдээллийн сангаас өгөгдөлд дүн шинжилгээ хийх хэрэгслүүдийн талаархи бяцхан тойм.";
• «RabbitMQ-г Kubernetes руу саадгүй шилжүүлэх";
• «CoreOS-ийн zetcd: ZooKeeper-г... гэх мэт сангаар сольж байна".

Эх сурвалж: www.habr.com