[요약] Optimising Kafka Consumers with Kubernetes and KEDA:Lessons from the Trenches

• reference (KubeDay Singapore 2023 - Optimising Kafka Consumers withKubernetes and KEDA:Lessons from the Trenches)

https://static.sched.com/hosted_files/kubedaysingapore2023/29/Optimizing%20Kafka%20Consumers%20with%20Kubernetes%20and%20KEDA.pdf

 

하루에 수 천개의 카프카 토픽으로 유입되는 수 백만건의 레코드의 컨슈머 최적화 사례 발표

 

• 기존 방식1

  - VPA (vertical pod autoscailing) ??

  - peak 시간대에 load 발생하나 전체적으로는 22% 의 평균 CPU 사용률을 보이는 문제

• 기존 방식2

  - HPA based on CPU, MEMs

  - off-peak에서는 pod가 줄어드니 비용은 절감됨

  - pod 간의 불균형적인 부하 분산 문제 -> 편차평균 계산이 필요해짐

  - 높은 consumer lag 발생해서 SLA 충족 불가

  - 지속적인 리소스 튜닝 필요

 

• KEDA

   - 복잡한 scailing rule 구현 가능해짐

   - datadog과의 원할한 연계

   - application level의 매트릭(consumer 지연 같은..) 과 인프라 level 의 매트릭 (CPU, Memory) 을 함께 사용

           

 

그러나 KEDA를 쓰더라도 유기적인 트래픽 변화에 따라 deployment의 resizing은 불가, 플랫폼 사용자를 위한 리소스 configuration 추상화의 문제(운영이 어렵다는 것) 가 있음

 

• CRD (Custom Resource Definition)

    - 스케쥴러, 데이터수집기, 추천기, 업데이터를 포함하는 Resource Advisor CRD 사용

    - off-peak 시간대에 스케쥴 실행 -> datadog 의 커스텀 매트릭에서 데이터 수집 -> application 매트릭 기반 scailing condition check -> 수집 데이터 기반 (리소스)추천 -> 추천 근거한 resizing 

 

• 결과

- 일일 CPU 사용량을 15 ~ 57% 절감

- 일일 비용절감 55%

- 리소스 튜닝 시간 -> 업무 집중

- data freshness and completeness SLA 준수

 

• 향후계획

- pod 간 불균형 부하 분산의 문제 해결. - 어플리케이션 레벨에서의 비율 제한과 같은 구현 필요

- 복잡한 custom metric 구현으로 보다 복잡한 비즈니스 요구사항(스케일링) 해결

 

 

 

 

 

• 리뷰소감

- 기본 HPA 는 CPU/Memory 에 기반하는것으로 알고 있었고, topic consuming lag 를 통해서도 가능하다고 접하였었음

- KEDA가 어떤 장단이 있는지에 대해 실사례로 간접 체험

- Resource Advisor 와 같은 역할을 하는 application 필요할 것으로 보이나 왜 CRD로 구현해야하는지에 대한 의문이 남음

- k8s Resource Advisor로 검색하면 나오는 git 이 있어 메모

  https://github.com/elisasre/kubernetes-resource-advisor

GitHub - elisasre/kubernetes-resource-advisor