Вызначаем прыдатны памер для кластара Kafka у Kubernetes

Заўв. перав.: У гэтым артыкуле кампанія Banzai Cloud дзеліцца прыкладам выкарыстання яе спецыяльных утыліт для палягчэння эксплуатацыі Kafka у рамках Kubernetes. Прыводныя інструкцыі ілюструюць, як можна вызначыць аптымальны памер інфраструктуры і наладзіць саму Kafka для дасягнення патрабаванай прапускной здольнасці.

Apache Kafka - размеркаваная стрымінгавая платформа для стварэння надзейных, якія маштабуюцца і высокапрадукцыйных струменевых сістэм рэальнага часу. Яе ўражальныя магчымасці можна пашырыць з дапамогай Kubernetes. Для гэтага мы распрацавалі Open Source-аператар Kafka і інструмент пад назвай Супертрубы. Яны дазваляюць запускаць Kafka у Kubernetes і выкарыстоўваць яе розныя функцыі, такія як тонкая настройка канфігурацыі брокера, маштабаванне на аснове метрык з рэбалансоўкай, rack awareness (дасведчанасць аб апаратных рэсурсах), "мяккае" (graceful) выкочванне абнаўленняў і г.д.

Паспрабуйце Supertubes у сваім кластары:

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

Або звернецеся да дакументацыі. Таксама можна пачытаць аб некаторых магчымасцях Kafka, праца з якімі аўтаматызавана з дапамогай Supertubes і Kafka operator. Пра іх мы ўжо пісалі ў блогу:

• Oh no! Yet another Kafka operator for Kubernetes;
• Monitor and operate Kafka заснавана на Prometheus metrics;
• Kafka rack awareness on Kubernetes;
• Running Apache Kafka over Istio - benchmark;
• User authenticated and access controlled clusters with the operator;
• Kafka rolling upgrade and dynamic configuration on Kubernetes;
• Envoy protocol filter для Kafka, meshed.

Вырашыўшы разгарнуць кластар Kafka у Kubernetes, вы напэўна сутыкнецеся з праблемай вызначэння аптымальнага памеру базавай інфраструктуры і неабходнасцю тонкай падладкі канфігурацыі Kafka для задавальнення патрабаванняў да прапускной здольнасці. Максімальная прадукцыйнасць кожнага брокера вызначаецца прадукцыйнасцю кампанентаў інфраструктуры ў яго аснове, такіх як памяць, працэсар, хуткасць дыска, прапускная здольнасць сеткі і т.д.

У ідэале канфігурацыя брокера павінна быць такой, каб усе элементы інфраструктуры выкарыстоўваліся на максімуме сваіх магчымасцяў. Аднак у рэальным жыцці такая настройка вельмі складаная. Больш верагодна, што карыстачы будуць наладжваць канфігурацыю брокераў такім чынам, каб максымізаваць выкарыстанне аднаго ці двух кампанентаў (дыска, памяці ці працэсара). Наогул кажучы, брокер паказвае максімальную прадукцыйнасць, калі яго канфігурацыя дазваляе задзейнічаць самы павольны кампанент "па поўнай праграме". Так мы можам атрымаць прыкладнае ўяўленне аб нагрузцы, з якой здольны справіцца адзін брокер.

Тэарэтычна, мы таксама можам прыкінуць лік брокераў, неабходнае для працы з зададзенай нагрузкай. Аднак на практыку варыянтаў налады на розных узроўнях гэтак шмат, што ацаніць патэнцыйную прадукцыйнасць нейкай канфігурацыі вельмі складана (калі не немагчыма). Іншымі словамі, вельмі складана спланаваць канфігурацыю, адштурхваючыся ад нейкай зададзенай прадукцыйнасці.

Для карыстальнікаў Supertubes мы звычайна ўжываем наступны падыход: пачынаем з некаторай канфігурацыі (інфраструктура + налады), затым вымяраем яе прадукцыйнасць, карэктуем налады брокера і паўтараем працэс яшчэ раз. Гэта адбываецца да таго часу, пакуль патэнцыял самага павольнага кампанента інфраструктуры не будзе поўнасцю задзейнічаны.

Такім спосабам мы атрымліваем больш дакладнае ўяўленне аб тым, колькі брокераў неабходна кластару, каб справіцца з пэўнай нагрузкай (колькасць брокераў таксама залежыць ад іншых фактараў, такіх як мінімальная колькасць рэплік паведамленняў для забеспячэння ўстойлівасці, колькасць partition-лідэраў і да т.п.). Акрамя таго, мы атрымліваем уяўленне аб тым, для якога інфраструктурнага кампанента пажадана маштабаванне па вертыкалі.

У гэтым артыкуле гаворка пойдзе аб кроках, якія мы робім для таго, каб "выціснуць усё" з самых павольных кампанентаў у пачатковых канфігурацыях і вымераць прапускную здольнасць кластара Kafka. Высокаўстойлівая канфігурацыя патрабуе наяўнасці па меншай меры трох працуючых брокераў (min.insync.replicas=3), разнесеных па трох розных зонах даступнасці. Для наладкі, маштабавання і маніторынгу інфраструктуры Kubernetes мы выкарыстоўваем уласную платформу кіравання кантэйнерамі для гібрыдных аблокаў. Трубаправод. Яна падтрымлівае on-premise (bare metal, VMware) і пяць тыпаў аблокаў (Alibaba, AWS, Azure, Google, Oracle), а таксама іх любыя спалучэнні.

Думкі наконт інфраструктуры і канфігурацыі кластара Kafka

Для прыкладаў, прыведзеных ніжэй, мы абралі AWS у якасці пастаўшчыка хмарных паслуг і EKS у якасці дыстрыбутыва Kubernetes. Аналагічную канфігурацыю можна рэалізаваць з дапамогай PKE - Дыстрыбутыва Kubernetes ад Banzai Cloud, сертыфікаванага CNCF.

дыск

Amazon прапануе розныя тыпы тамоў EBS. У аснове gp2 и io1 ляжаць SSD-дыскі, аднак для забеспячэння высокай прапускной здольнасці gp2 спажывае назапашаныя крэдыты (I/O credits), таму мы аддалі перавагу тып io1, Які прапануе стабільную высокую прапускную здольнасць.

Тыпы інстансаў

Прадукцыйнасць Kafka моцна залежыць ад старонкавага кэша аперацыйнай сістэмы, таму нам патрэбныя інстансы з дастатковай колькасцю памяці для брокераў (JVM) і старонкавага кэша. Інстанс c5.2xвялікі - нядрэнны пачатак, паколькі мае 16 Гб памяці і аптымізаваны для працы з EBS. Яго недахопам з'яўляецца тое, што ён здольны забяспечваць максімальную прадукцыйнасць на працягу не больш за 30 хвілін кожныя 24 гадзіны. Калі працоўная нагрузка патрабуе максімальнай прадукцыйнасці на працягу больш працяглага прамежку часу, варта дагледзецца да іншых тыпаў інстансаў. Мы менавіта так і зрабілі, спыніўшыся на c5.4xвялікі. Ён забяспечвае максімальную прапускную здольнасць у 593,75 Мб/с. Максімальная прапускная здольнасць тома EBS io1 вышэй, чым у інстансу c5.4xвялікі, таму самы павольны элемент інфраструктуры, па ўсёй бачнасці, гэта прапускная здольнасць I/O гэтага тыпу інстансу (што таксама павінны пацвердзіць вынікі нашых нагрузачных тэстаў).

сетка

Прапускная здольнасць сеткі павінна апынуцца досыць вялікай у параўнанні з прадукцыйнасцю інстанса VM і кружэлкі, у адваротным выпадку сетка становіцца вузкім месцам. У нашым выпадку сеткавы інтэрфейс c5.4xвялікі падтрымлівае хуткасць да 10 Гб/з, што значна вышэй прапускной здольнасці I/O інстанса VM.

Разгортванне брокераў

Брокеры павінны разгортвацца (планавацца ў Kubernetes) на выдзеленыя вузлы, каб пазбегнуць канкурэнцыі з іншым працэсамі за рэсурсы працэсара, памяці, сеткі і дыска.

Версія Java

Лагічным выбарам з'яўляецца Java 11, паколькі яна сумяшчальная з Docker у тым сэнсе, што JVM правільна вызначае працэсары і памяць, даступныя кантэйнеру, у якім працуе брокер. Ведаючы, што ліміты па працэсарам важныя, JVM унутрана і празрыста ўсталёўвае колькасць струменяў GC і струменяў JIT-кампілятара. Мы выкарыстоўвалі вобраз Kafka banzaicloud/kafka:2.13-2.4.0, які ўключае версію Kafka 2.4.0 (Scala 2.13) на Java 11

Калі вы жадаеце падрабязней пазнаць аб Java/JVM на Kubernetes, звернеце ўвагу на наступныя нашы публікацыі:

• Why my Java application is OOMKilled;
• How to correctly size containers for Java 10 applications.

Налады памяці брокера

Існуе два ключавых аспекта ў наладзе памяці брокера: налады для JVM і для pod'а Kubernetes. Мяжа памяці, усталяваны для pod'а, павінен быць больш, чым максімальны heap size, каб у JVM заставалася месца для метапрасторы Java, якое знаходзіцца ва ўласнай памяці, і для старонкавага кэша аперацыйнай сістэмы, які Kafka актыўна выкарыстоўвае. Мы ў сваіх тэстах запускалі брокеры Kafka з параметрамі -Xmx4G -Xms2G, а мяжа памяці для pod'а складаў 10 Gi. Звярніце ўвагу, што настройкі памяці для JVM можна атрымліваць аўтаматам з дапамогай -XX:MaxRAMPercentage и -X:MinRAMPercentage, зыходзячы з ліміту памяці для pod'а.

Працэсарныя наладкі брокера

Наогул кажучы, можна падняць прадукцыйнасць, падвысіўшы паралелізм за рахунак павелічэння ліку струменяў, выкарыстоўваных Kafka. Чым больш працэсараў даступныя для Kafka, тым лепш. У нашым тэсце мы пачалі з ліміту ў 6 працэсараў і паступова (ітэрацыямі) паднялі іх лік да 15. Акрамя таго, мы ўсталявалі num.network.threads=12 у наладах брокера, каб павялічыць колькасць патокаў, якія прымаюць дадзеныя з сеткі і пасылаюць іх. Адразу выявіўшы, што брокеры-паслядоўнікі не могуць атрымліваць рэплікі дастаткова хутка, паднялі num.replica.fetchers да 4, каб павялічыць хуткасць, з якой брокеры-паслядоўнікі рэплікавалі паведамленні ад лідэраў.

Інструмент генеравання нагрузкі

Варта пераканацца, што патэнцыял абранага генератара нагрузкі не вычарпаецца да таго, як кластар Kafka (бенчмарк якога праводзіцца) дасягне сваёй максімальнай нагрузкі. Іншымі словамі, неабходна правесці папярэднюю адзнаку магчымасцяў прылады генеравання нагрузкі, а таксама абраць для яго тыпы instance'ов з дастатковай колькасцю працэсараў і памяці. У гэтым выпадку наша прылада будзе прадукаваць больш нагрузкі, чым здольны пераварыць кластар Kafka. Пасля мноства доследаў, мы спыніліся на трох экземплярах. c5.4xвялікі, у кожным з якіх быў запушчаны генератар.

Бенчмаркінг

Вымярэнне прадукцыйнасці - ітэратыўны працэс, які ўключае наступныя стадыі:

• настройка інфраструктуры (кластара EKS, кластара Kafka, інструмента генеравання нагрузкі, а таксама Prometheus і Grafana);
• генераванне нагрузкі на працягу вызначанага перыяду для фільтрацыі выпадковых адхіленняў у збіраных паказчыках прадукцыйнасці;
• падладка інфраструктуры і канфігурацыі брокера на аснове назіраных паказчыкаў прадукцыйнасці;
• паўтарэнне працэсу датуль, пакуль не будзе дасягнуты патрабаваны ўзровень прапускной здольнасці кластара Kafka. Пры гэтым ён павінен быць стабільна ўзнаўляльным і дэманстраваць мінімальныя варыяцыі прапускной здольнасці.

У наступным раздзеле апісаны крокі, якія выконваліся ў працэсе бенчмарку тэставага кластара.

Інструменты

Для хуткага разгортвання базавай канфігурацыі, генерацыі нагрузкі і вымярэнні прадукцыйнасці выкарыстоўваліся наступныя прылады:

• Banzai Cloud Pipeline для арганізацыі кластара EKS ад Amazon c Праметэй (для збору метрык Kafka і інфраструктуры) і Графана (Для візуалізацыі гэтых метрык). Мы скарысталіся інтэграванымі в Трубаправод сэрвісамі, якія забяспечваюць федэратыўны маніторынг, цэнтралізаваны збор логаў, сканіраванне ўразлівасцяў, аднаўленне пасля збояў, бяспека карпаратыўнага ўзроўня і шматлікае іншае.
• Sangrenel - інструмент для нагрузачнага тэсціравання кластара Kafka.
• Панэлі Grafana для візуалізацыі метрык Kafka і інфраструктуры: Kubernetes Kafka, Node Exporter.
• Supertubes CLI для максімальна просты налады кластара Kafka ў Kubernetes. Zookeeper, Kafka operator, Envoy і мноства іншых кампанентаў устаноўлены і належным чынам сканфігураваны для запуску гатовага да production кластара Kafka у Kubernetes.
  • Для ўстаноўкі supertubes CLI скарыстайцеся інструкцыямі, прыведзенымі тут.

Кластар EKS

Падрыхтуйце кластар EKS з выдзеленымі працоўнымі вузламі c5.4xвялікі у розных зонах даступнасці для pod'аў з брокерамі Kafka, а таксама выдзеленыя вузлы для генератара нагрузкі і маніторынгавай інфраструктуры.

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

Калі кластар EKS запрацуе, уключыце яго інтэграваную службу маніторынгу - Яна разгорне Prometheus і Grafana ў кластар.

Сістэмныя кампаненты Kafka

Усталюйце сістэмныя кампаненты Kafka (Zookeeper, kafka-operator) у EKS з дапамогай supertubes CLI:

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 і разгарніце pod'ы брокераў на вузлах у трох розных зонах даступнасці:

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 - мінімальнаму рэкамендаванаму значэнню для высокадаступных production-сістэм.

Інструмент генеравання нагрузкі

Мы запускалі тры асобнікі генератара нагрузкі (кожны пісаў у асобны топік). Для pod'ов генератара нагрузкі неабходна прапісаць node affinity, каб яны планаваліся толькі на вылучаныя для іх вузлы:

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 байт і публікуе іх у Kafka партыямі па 500 паведамленняў.
• З дапамогай аргумента -required-acks=all публікацыя прызнаецца паспяховай, калі ўсе сінхранізаваныя рэплікі паведамлення атрыманы і пацверджаны брокерамі Kafka. Гэта азначае, што ў бенчмарку мы вымяралі не толькі хуткасць працы лідэраў, якія атрымліваюць паведамленні, але і іх паслядоўнікаў, якія рэпліцыруюць паведамленні. У задачу дадзенага тэста не ўваходзіць ацэнка хуткасці чытання спажыўцамі (consumers) нядаўна прынятых паведамленняў, якія пакуль застаюцца ў старонкавым кэшы АС, і яе параўнанне са хуткасцю чытання паведамленняў, якія захоўваюцца на дыску.
• Генератар нагрузкі раўналежна запускае 20 worker'ов (-workers=20). Кожны worker утрымоўвае 5 producer'ов, якія сумесна выкарыстаюць падлучэнне worker'а да кластара Kafka. У выніку кожны генератар налічвае 100 producer'ов, і ўсе яны адпраўляюць паведамленні ў кластар Kafka.

Назіранне за станам кластара

Падчас нагрузачнага тэставання кластара Kafka мы таксама сачылі за яго здароўем, каб пераканацца ў адсутнасці перазапускаў pod'аў, рассінхранізаваных рэплік і максімальнай прапускной здольнасці з мінімальнымі флуктуацыямі:

• Генератар нагрузкі піша стандартную статыстыку аб колькасці апублікаваных паведамленняў і ўзроўні памылак. Працэнт памылак павінен заставацца ў значэнні 0,00%.
• Круіз-кантроль, разгорнуты kafka-operator'ам, падае панэль маніторынгу, на якой мы таксама можам назіраць за станам кластара. Для прагляду гэтай панэлі выканайце:

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

• Узровень ISR (колькасць рэплік "in-sync") shrink і expansion роўны 0.

Вынікі вымярэнняў

3 брокера, памер паведамленняў - 512 байт

З partition'амі, раўнамерна размеркаванымі па трох брокерам, нам удалося дасягнуць прадукцыйнасці ~500 Мб/с (прыкладна 990 тыс. паведамленняў у секунду):

Спажыванне памяці віртуальнай машынай JVM не перавысіла 2 Гб:

Прапускная здольнасць дыска дасягнула максімальнай прапускной здольнасці I/O вузла на ўсіх трох інстансах, на якіх працавалі брокеры:

З дадзеных аб выкарыстанні памяці вузламі вынікае, што сістэмная буферызацыя і кэшаванне занялі ~10-15 Гб:

3 брокера, памер паведамленняў - 100 байт

З памяншэннем памеру паведамленняў прапускная здольнасць падае прыкладна на 15-20%: адбіваецца час, які затрачваецца на апрацоўку кожнага паведамлення. Акрамя таго, нагрузка на працэсар вырасла амаль удвая.

Паколькі на вузлах брокераў па-ранейшаму маюцца ядры, якія не выкарыстоўваюцца, прадукцыйнасць можна павысіць за кошт змены канфігурацыі Kafka. Гэта няпростая задача, таму для павелічэння прапускной здольнасці лепш працаваць з паведамленнямі большага памеру.

4 брокера, памер паведамленняў - 512 байт

Можна лёгка павялічыць прадукцыйнасць кластара Kafka, проста дадаючы новыя брокеры і захоўваючы баланс partition'ов (гэта забяспечвае раўнамернае размеркаванне нагрузкі паміж брокерамі). У нашым выпадку пасля дадання брокера прапускная здольнасць кластара ўзрасла да ~580 Мб/с (~1,1 млн паведамленняў у секунду). Рост аказаўся меншым, чым чакалася: пераважна гэта тлумачыцца дысбалансам partition'аў (не ўсе брокеры працуюць на піку магчымасцяў).

Спажыванне памяці машынай JVM засталося ніжэй за 2 Гб:

На працы брокераў з назапашвальнікамі адбіўся дысбаланс partition'аў:

Высновы

Прадстаўлены вышэй ітэратыўны падыход можа быць пашыраны для ахопу больш складаных сцэнарыяў, якія ўключаюць сотні consumer'аў, repartitioning, накатваюцца абнаўленні, перазапускі pod'аў і г.д. Усё гэта дазваляе нам ацаніць межы магчымасцяў кластара Kafka у розных умовах, выявіць вузкія месцы ў яго працы і знайсці спосабы барацьбы з імі.

Мы распрацавалі Supertubes для хуткага і лёгкага разгортвання кластара, яго канфігуравання, даданні/выдаленні брокераў і топікаў, рэагаванні на абвесткі і забеспячэнні правільнай працы Kafka у Kubernetes у цэлым. Наша мэта - дапамагчы сканцэнтравацца на асноўнай задачы («генераваць» і «спажываць» паведамленні Kafka), а ўсю цяжкую працу падаць Supertubes і Kafka operator'у.

Калі вам цікавыя тэхналогіі і Open Source-праекты Banzai Cloud, падпісвайцеся на кампанію ў GitHub, LinkedIn або Twitter.

PS ад перакладчыка

Чытайце таксама ў нашым блогу:

• «Адна гісторыя з аператарам Redis у K8s і міні-агляд утыліт для аналізу дадзеных гэтай БД»;
• «Няпростая міграцыя RabbitMQ у Kubernetes»;
• «zetcd ад CoreOS: Замяняючы ZooKeeper на… сховішча etcd.

Крыніца: habr.com