AB180의 카프카 도입 및 실시간 아키텍처 개선 사례
1. Airbridge 서비스 소개
•
데이터 처리 순서가 중요한 실시간 워크로드
•
실시간 처리 결과 제공 필요
2. 기존 아키텍처의 문제점
1.
컨슈머 간 파티션 처리 불균형
2.
워크 로드 운영 중 특정 파티션으로의 데이터 치우침(skewing) 현상
a.
파티션 키를 이용해서 consume
b.
비상식적으로 많은 이벤트가 발생 시 특정 파티션으로의 데이터 치우침(skewing) 현상 발생
c.
파티션을 계속 늘릴 수록 카프카 브로커의 부담이 생김
i.
처리해야할 파티션 증가
ii.
배치 처리 성능 저하
3.
컨슈머 간 시스템 리소스 사용량 편차 발생
a.
이로 인해 consumer마다 system resource 사용량 편차가 심해지는데 ECS 환경에서는 scale up에 한계도 존재함
4.
python 구현체 한계
a.
consumer python 구현체에서는 멀티 프로세싱 사용 → ipc로 인한 성능 저하
b.
ECS는 최대 10vcpu만 한계
3. 새로운 아키텍처 검토
3.1 고려된 방안
1.
Spark Streaming과 같은 드라이버-익스큐터 모델
2.
Kafka 컨슈머와 애플리케이션 서버 분리 모델
3.2 선택: Kafka 컨슈머와 애플리케이션 서버 분리 모델
•
선택 이유:
1.
Spark 운영 환경 구축의 복잡성 회피
2.
기존 ECS 환경에서 인프라 변경 없이 마이그레이션 가능, 코드 레벨 수정 적음
4. 새로운 아키텍처 구현
1.
비즈니스 로직을 애플리케이션 서버로 분리
a.
컨슈머 프록시 클러스터 및 노드들
•
컨슈머 프록시
◦
Go 언어로 재구현되어 멀티코어 활용도를 높였습니다.
◦
Kafka에서 메시지를 읽어오는 역할에 집중합니다.
◦
메시지의 순서를 관리하고, 배치 단위로 처리합니다.
◦
서비스 디스커버리를 통해 가용한 애플리케이션 서버를 찾아 gRPC로 통신합니다.
◦
처리 결과에 따라 Kafka 오프셋을 관리합니다
b.
컨슈머 서비스 (애플리케이션 서버)
•
기존 Python 코드베이스를 활용하여 비즈니스 로직을 처리합니다.
•
gRPC 서버로 구현되어 컨슈머 프록시로부터 요청을 받습니다.
2.
컨슈머 앱과 애플리케이션 서버는 따로 운영
3.
컨슈머와 애플리케이션 서버 간 gRPC 통신 구현
통신 흐름
1.
컨슈머 프록시가 Kafka에서 메시지 배치를 가져옴
2.
메시지를 순서대로 처리하기 위해 배치 내에서 정렬
3.
서비스 디스커버리를 통해 사용 가능한 애플리케이션 서버 확인
4.
gRPC를 통해 애플리케이션 서버로 메시지 전송
5.
애플리케이션 서버에서 비즈니스 로직 처리 및 결과 저장
6.
처리 결과를 컨슈머 프록시에 반환
7.
컨슈머 프록시는 처리 완료된 메시지의 오프셋을 커밋
5. 새 아키텍처 적용 시 고려사항
1.
네트워크 비용 최소화: 서비스 디스커버리 활용 (로드 밸런서는 네트워크 비용 과다)
2.
데이터 처리 순서 보장: 컨슈머의 배치 윈도우 내 순서 고려하여 app server 호출
3.
무중단 운영: 애플리케이션 서버 무중단 배포 구현
6. 구현 과정에서의 기술적 어려움
1.
Python + gRPC에서의 멀티 코어 활용
a.
Python에서 직접 gRPC server를 실행할 경우 multi thread 환경이 되어 multi core 활용이 잘 되지 않음
•
해결: Envoy를 사이드카로 활용
2.
서비스 디스커버리
•
ECS 환경에서 포트 레벨 구분 필요
•
AWS Cloud Map을 사용하고 있어서 grpc-go의 resolver interface에 맞춰서 Cloud Map API를 사용하는 resolver 구현
•
이 부분은 나중에 service connect로 해결되었을 것 같음
7. 새 아키텍처 적용 후 결과
1.
카프카 클러스터 부하 감소
•
partition 수를 적게 유지할 수 있으므로 kafka producer는 batch produce를 효율적으로 하게 되고, 전체 kafka cluster의 부하도 줄어듬
2.
유연한 스케일링
•
consumer는 partition 수의 약수만큼 띄워서 skew 되지 않게 하고, application server는 traffic에 따라 유연하게 scaling 할 수 있게 됨
3.
scale up에 대한 고민이 사라짐
•
스테이트리스 설계로 유연한 스케일링 가능
8. 향후 개선 계획
•
네트워크 비용 추가 최적화: 존 인식(Zone awareness) 기반 교차 존 네트워크 비용 절감
