About AB180
home
AB180 Culture
home

Kafka Lag 없는 실시간 데이터 파이프라인을 위한 아키텍처 개선기

5 more properties
Airbridge 서비스와 Workload 소개
데이터 처리 순서가 중요한 workload
실시간 처리 결과 제공
기존 아키텍처의 문제점
consumer마다 처리하는 partition 수가 달라질 수 있는 불균형 문제
Workload에 의해 특정 partition에 데이터가 skewing 될 수 있는 문제
이로 인해 consumer마다 system resource 사용량 편차가 심해지는데 ECS 환경에서는 scale up에 한계도 존재함
새로운 아키텍처
1안: Spark streaming과 같은 driver, executor model
2안: Kafka consumer와 application server decouple model
2안을 선택한 이유
Spark streaming의 경우 Spark 실행 환경을 구축하고 운영하기 위한 어려움이 존재
기존 application server들을 운영하던 환경이 ECS였는데 2안의 경우 infra 변경 없이 migration 가능
Kafka consumer와 application server decouple model 아키텍처
기존 consumer application의 비즈니스 로직을 application server로 분리
consumer와 application server는 gRPC interface로 통신
새로운 아키텍처에서의 고려 사항
네트워크 비용 최소화: load balancer를 따로 둘 경우 네트워크 비용이 중복되므로 service discovery를 활용
데이터 처리 순서: consumer가 batch window 내에서 순서를 고려하여 application server 호출
무중단 운영: application server를 무중단으로 배포할 수 있도록 처리
경험한 어려움
Python + gRPC에서 multi core 활용
Python에서 직접 gRPC server를 실행할 경우 multi thread 환경이 되어 multi core 활용이 잘 되지 않음
Envoy를 sidecar로 붙여서 해결
Service Discovery SRV record 활용
ECS에서는 동일한 EC2 instance에 여러 container를 실행하므로 port level로 구분이 필요한데 A record는 IP level까지만 명시됨
consumer에서 gRPC library로 grpc-go 를 사용하는데 기본 DNS load balancer가 grpclb 라는 이름만 지원함
AWS Cloud Map을 사용하고 있어서 grpc-go의 resolver interface에 맞춰서 Cloud Map API를 사용하는 resolver 구현
새 아키텍처 적용 후 결과
partition 수를 적게 유지할 수 있으므로 kafka producer는 batch produce를 효율적으로 하게 되고, 전체 kafka cluster의 부하도 줄어듬
consumer는 partition 수의 약수만큼 띄워서 skew 되지 않게 하고, application server는 traffic에 따라 유연하게 scaling 할 수 있게 됨
scale up에 대한 고민이 사라짐
앞으로 더 시도해봐야 할 것
네트워크 비용 더 최소화: zone awareness로 cross zone network 비용 절감
ᴡʀɪᴛᴇʀ
Juhong Jung @toughrogrammer Backend Software Engineer
유니콘부터 대기업까지 쓰는 제품. 같이 만들어볼래요? 에이비일팔공에서 함께 성장할 다양한 직군의 동료들을 찾고 있어요! → 더 알아보기