Одређивање одговарајуће величине за Кафка кластер у Кубернетесу

Белешка. трансл.: У овом чланку Банзаи Цлоуд дели пример како се његови прилагођени алати могу користити да Кафка буде лакша за коришћење у Кубернетес-у. Следећа упутства илуструју како можете одредити оптималну величину своје инфраструктуре и конфигурисати саму Кафку да постигне потребну пропусност.

Апацхе Кафка је дистрибуирана платформа за стриминг за креирање поузданих, скалабилних и високих перформанси система за стриминг у реалном времену. Његове импресивне могућности могу се проширити помоћу Кубернетеса. За ово смо се развили Кафка оператер отвореног кода и алат тзв Супертубес. Они вам омогућавају да покренете Кафку на Кубернетес-у и користите његове различите функције, као што је фино подешавање конфигурације брокера, метричко скалирање са ребалансом, свест о рацк-у, „меко“ (грациозан) увођење ажурирања итд.

Испробајте Супертубес у свом кластеру:

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

Или контактирајте документација. Такође можете прочитати о неким могућностима Кафке, чији је рад аутоматизован помоћу Супертубес и Кафка оператера. О њима смо већ писали на блогу:

• О, не! Још један Кафка оператер за Кубернетес;
• Надгледајте и управљајте Кафком на основу Прометејеве метрике;
• Кафка рацк свест на Кубернетес;
• Покретање Апацхе Кафке преко Истио-а - бенцхмарк;
• Кориснички аутентификовани и контролисани кластери са Кафка оператором;
• Кафка надоградња и динамичка конфигурација на Кубернетесу;
• Филтер протокола изасланика за Кафку, испреплетен.

Када одлучите да примените Кафка кластер на Кубернетес-у, вероватно ћете се суочити са изазовом одређивања оптималне величине основне инфраструктуре и потребом да фино подесите своју Кафка конфигурацију како би задовољила захтеве пропусности. Максималне перформансе сваког брокера одређују се перформансама основних инфраструктурних компоненти, као што су меморија, процесор, брзина диска, пропусни опсег мреже итд.

У идеалном случају, конфигурација брокера треба да буде таква да се сви инфраструктурни елементи користе до својих максималних могућности. Међутим, у стварном животу ово подешавање је прилично сложено. Вероватније је да ће корисници конфигурисати брокере да максимизирају употребу једне или две компоненте (диск, меморија или процесор). Уопштено говорећи, брокер показује максималне перформансе када његова конфигурација дозвољава да се најспорија компонента користи у највећој мери. На овај начин можемо добити грубу представу о оптерећењу које један брокер може да поднесе.

Теоретски, такође можемо проценити број брокера потребних за руковање датим оптерећењем. Међутим, у пракси постоји толико много опција конфигурације на различитим нивоима да је веома тешко (ако не и немогуће) проценити потенцијалне перформансе одређене конфигурације. Другим речима, веома је тешко планирати конфигурацију засновану на неким датим перформансама.

За кориснике Супертубеса обично користимо следећи приступ: почињемо са неком конфигурацијом (инфраструктура + подешавања), затим меримо њен учинак, прилагођавамо подешавања брокера и поново понављамо процес. Ово се дешава све док се најспорија компонента инфраструктуре у потпуности не искористи.

На овај начин добијамо јаснију представу о томе колико брокера кластер треба да поднесе одређено оптерећење (број брокера зависи и од других фактора, као што је минимални број реплика порука да би се обезбедила отпорност, број партиција лидери итд.). Поред тога, добијамо увид у то које компоненте инфраструктуре захтевају вертикално скалирање.

Овај чланак ће говорити о корацима које предузимамо да бисмо максимално искористили најспорије компоненте у почетним конфигурацијама и измерили пропусност Кафка кластера. Веома отпорна конфигурација захтева најмање три покренута брокера (min.insync.replicas=3), распоређених у три различите зоне приступачности. Да бисмо конфигурисали, скалирали и надгледали Кубернетес инфраструктуру, користимо сопствену платформу за управљање контејнерима за хибридне облаке - Цевовод. Подржава он-премисе (голи метал, ВМваре) и пет типова облака (Алибаба, АВС, Азуре, Гоогле, Орацле), као и сваку њихову комбинацију.

Размишљања о инфраструктури и конфигурацији Кафка кластера

За примере испод, изабрали смо АВС као добављача облака и ЕКС као Кубернетес дистрибуцију. Слична конфигурација се може имплементирати помоћу ПКЕ - Кубернетес дистрибуција из Банзаи Цлоуд-а, сертификована од стране ЦНЦФ-а.

диск

Амазон нуди разне ЕБС типови запремине. У језгру гпКСНУМКС и иоКСНУМКС постоје ССД дискови, међутим, како би се осигурала висока пропусност гпКСНУМКС троши нагомилане кредите (И/О кредити), па смо преферирали тип иоКСНУМКС, који нуди константну високу пропусност.

Типови инстанци

Кафкине перформансе у великој мери зависе од кеша страница оперативног система, тако да су нам потребне инстанце са довољно меморије за брокере (ЈВМ) и кеш странице. Инстанце ц5.2кларге - добар почетак, пошто има 16 ГБ меморије и оптимизован за рад са ЕБС-ом. Његов недостатак је што је способан да пружи максималне перформансе само за не више од 30 минута свака 24 сата. Ако ваше радно оптерећење захтева врхунске перформансе током дужег временског периода, можда ћете желети да размотрите друге типове инстанце. Управо то смо и урадили, зауставивши се на ц5.4кларге. Пружа максималну пропусност 593,75 Мбпс. Максимална пропусност ЕБС запремине иоКСНУМКС виши од инстанце ц5.4кларге, тако да ће најспорији елемент инфраструктуре вероватно бити И/О пропусност овог типа инстанце (што би наши тестови оптерећења такође требало да потврде).

Мрежа

Пропусност мреже мора бити довољно велика у поређењу са перформансама ВМ инстанце и диска, иначе мрежа постаје уско грло. У нашем случају, мрежни интерфејс ц5.4кларге подржава брзине до 10 Гб/с, што је знатно веће од И/О пропусности ВМ инстанце.

Брокер Деплоимент

Брокери би требало да буду распоређени (планирани у Кубернетес-у) на наменским чворовима како би се избегло такмичење са другим процесима за ресурсе процесора, меморије, мреже и диска.

Јава верзија

Логичан избор је Јава 11 јер је компатибилан са Доцкер-ом у смислу да ЈВМ исправно одређује процесоре и меморију доступне контејнеру у којем брокер ради. Знајући да су ограничења ЦПУ-а важна, ЈВМ интерно и транспарентно поставља број ГЦ нити и ЈИТ нити. Користили смо Кафкину слику banzaicloud/kafka:2.13-2.4.0, који укључује Кафка верзију 2.4.0 (Сцала 2.13) на Јави 11.

Ако желите да сазнате више о Јави/ЈВМ на Кубернетес-у, погледајте наше следеће постове:

• Зашто је моја Јава апликација ООМКиллед;
• Како правилно одредити величину контејнера за Јава 10 апликације.

Подешавања меморије брокера

Постоје два кључна аспекта за конфигурисање брокерске меморије: подешавања за ЈВМ и за Кубернетес под. Ограничење меморије постављено за под мора бити веће од максималне величине хрпе тако да ЈВМ има простора за Јава метапростор који се налази у сопственој меморији и за кеш странице оперативног система који Кафка активно користи. У нашим тестовима смо покренули Кафка брокере са параметрима -Xmx4G -Xms2G, а ограничење меморије за под је било 10 Gi. Имајте на уму да се подешавања меморије за ЈВМ могу добити аутоматски користећи -XX:MaxRAMPercentage и -X:MinRAMPercentage, на основу ограничења меморије за под.

Подешавања процесора брокера

Уопштено говорећи, можете побољшати перформансе повећањем паралелизма повећањем броја нити које Кафка користи. Што је више процесора доступно за Кафку, то боље. У нашем тесту смо почели са ограничењем од 6 процесора и постепено (кроз итерације) повећавали њихов број на 15. Поред тога, поставили смо num.network.threads=12 у подешавањима брокера да повећате број нити које примају податке са мреже и шаљу их. Одмах откривши да брокери пратиоци не могу довољно брзо да добију реплике, подигли су num.replica.fetchers до 4 да би се повећала брзина којом су брокери пратилаца реплицирали поруке од лидера.

Алат за генерисање оптерећења

Требало би да обезбедите да изабрани генератор оптерећења не остане без капацитета пре него што Кафка кластер (који се мери) достигне своје максимално оптерећење. Другим речима, потребно је извршити прелиминарну процену могућности алата за генерисање оптерећења, као и одабрати типове инстанци за њега са довољним бројем процесора и меморије. У овом случају, наш алат ће произвести више оптерећења него што Кафка кластер може да поднесе. После много експеримената, одлучили смо се за три примерка ц5.4кларге, од којих је сваки радио генератор.

Бенцхмаркинг

Мерење учинка је итеративни процес који укључује следеће фазе:

• постављање инфраструктуре (ЕКС кластер, Кафка кластер, алат за генерисање оптерећења, као и Прометеј и Графана);
• генерисање оптерећења за одређени период за филтрирање случајних одступања у прикупљеним индикаторима учинка;
• прилагођавање инфраструктуре и конфигурације брокера на основу уочених показатеља учинка;
• понављање процеса док се не постигне потребан ниво пропусности Кафка кластера. Истовремено, мора бити доследно поновљив и да показује минималне варијације у пропусности.

Следећи одељак описује кораке који су изведени током процеса бенчмаркинга тест кластера.

Алат

Следећи алати су коришћени за брзо постављање основне конфигурације, генерисање оптерећења и мерење перформанси:

• Банзаи Цлоуд Пипелине за организовање ЕКС кластера из Амазона в Прометеј (за прикупљање Кафкиних и инфраструктурних метрика) и Графана (да визуализујете ове метрике). Искористили смо предност интегрисани в Цевовод услуге које обезбеђују удружено надгледање, централизовано прикупљање евиденције, скенирање рањивости, опоравак од катастрофе, безбедност на нивоу предузећа и још много тога.
• Сангренел — алат за тестирање оптерећења Кафка кластера.
• Графана контролне табле за визуелизацију Кафкиних метрика и инфраструктуре: Кубернетес Кафка, Ноде Екпортер.
• Супертубес ЦЛИ за најлакши начин за постављање Кафка кластера на Кубернетес-у. Зоокеепер, Кафка оператер, Енвои и многе друге компоненте су инсталиране и правилно конфигурисане за покретање Кафка кластера спремног за производњу на Кубернетес-у.
  • За уградњу супертубес ЦЛИ користите дата упутства овде.

ЕКС кластер

Припремите ЕКС кластер са наменским радничким чворовима ц5.4кларге у различитим зонама доступности за подове са Кафка брокерима, као и наменским чворовима за генератор оптерећења и инфраструктуру за праћење.

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

Када се ЕКС кластер покрене, омогућите његову интегрисаност служба праћења — она ће распоредити Прометеја и Графану у кластер.

Компоненте Кафка система

Инсталирајте компоненте Кафка система (Зоокеепер, кафка-оператор) у ЕКС користећи супертубес ЦЛИ:

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

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

ЕКС подразумевано користи ЕБС волумене типа гпКСНУМКС, тако да морате да креирате засебну класу складиштења на основу волумена иоКСНУМКС за Кафка кластер:

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 произвођача, и сви они шаљу поруке у Кафка кластер.

Праћење здравља кластера

Током тестирања оптерећења Кафка кластера, такође смо пратили његово здравље како бисмо осигурали да нема рестартовања модула, реплика које нису синхронизоване и максималне пропусности уз минималне флуктуације:

• Генератор оптерећења пише стандардне статистике о броју објављених порука и стопи грешке. Стопа грешке треба да остане иста 0,00%.
• Цруисе Цонтрол, који је применио кафка-оператор, обезбеђује контролну таблу на којој такође можемо да пратимо стање кластера. Да бисте видели овај панел, урадите следеће:

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

• ИСР ниво (број „синхронизованих“ реплика) скупљање и ширење једнаки су 0.

Резултати мерења

3 брокера, величина поруке - 512 бајтова

Са партицијама равномерно распоређеним на три брокера, успели смо да постигнемо учинак ~500 Мб/с (приближно 990 хиљада порука у секунди):

Потрошња меморије ЈВМ виртуелне машине није прелазила 2 ГБ:

Проток диска је достигао максималну пропусност И/О чвора на све три инстанце на којима су брокери радили:

Из података о коришћењу меморије по чворовима произилази да су баферовање и кеширање система заузели ~10-15 ГБ:

3 брокера, величина поруке - 100 бајтова

Како се величина поруке смањује, пропусност опада за приближно 15-20%: време утрошено на обраду сваке поруке утиче на њу. Поред тога, оптерећење процесора се скоро удвостручило.

Пошто брокерски чворови још увек имају неискоришћена језгра, перформансе се могу побољшати променом Кафка конфигурације. Ово није лак задатак, па је за повећање пропусности боље радити са већим порукама.

4 брокера, величина поруке - 512 бајтова

Можете лако повећати перформансе Кафка кластера једноставним додавањем нових брокера и одржавањем равнотеже партиција (ово осигурава да је оптерећење равномерно распоређено између брокера). У нашем случају, након додавања брокера, пропусност кластера се повећала на ~580 Мб/с (~1,1 милиона порука у секунди). Показало се да је раст мањи од очекиваног: то се углавном објашњава неравнотежом партиција (не раде сви брокери на врхунцу својих могућности).

Потрошња меморије ЈВМ машине је остала испод 2 ГБ:

На рад брокера са дисковима утицала је неравнотежа партиција:

Налази

Итеративни приступ који је горе представљен може се проширити тако да покрије сложеније сценарије који укључују стотине потрошача, поновно партиционисање, ажурирања у току, рестартовање модула итд. Све ово нам омогућава да проценимо границе могућности Кафкиног кластера у различитим условима, идентификујемо уска грла у његовом раду и пронађемо начине за борбу против њих.

Дизајнирали смо Супертубес да брзо и лако применимо кластер, конфигуришемо га, додамо/уклонимо брокере и теме, одговоримо на упозорења и осигурамо да Кафка уопште ради исправно на Кубернетес-у. Наш циљ је да вам помогнемо да се концентришете на главни задатак („генерисање“ и „потрошња“ Кафка порука), а сав напоран рад препустимо Супертубесу и Кафка оператеру.

Ако сте заинтересовани за Банзаи Цлоуд технологије и пројекте отвореног кода, претплатите се на компанију на ГитХуб, ЛинкедИн или Twitter.

ПС од преводиоца

Прочитајте и на нашем блогу:

• «Једна прича са Редис оператером у К8с и мини-преглед услужних програма за анализу података из ове базе података";
• «Беспрекорна миграција РаббитМК-а на Кубернетес";
• «зетцд из ЦореОС-а: Замена ЗооКеепер-а са...етцд складиштем'.

Извор: ввв.хабр.цом