•
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
