아래 글은 [우아콘 2023] Kafka Streams를 활용한 이벤트 스트림 처리 삽질기를 보고 정리되었습니다.
배치에서 스트림 처리로의 전환
초기에는 배치 처리를 통해 배달 데이터와 라이더 데이터를 수집하고 분석했지만, 서비스 확장과 함께 데이터량이 급격히 증가하면서 여러 문제가 발생했다.
- 배치 처리 시간의 불안정성: 평상시에는 빠르게 끝나던 배치가, 주문량이 몰리는 시간대나 주말에는 DB에 부하가 발생하여 처리 속도 문제가 발생
- 실시간 반영의 어려움: 배치 처리 주기 사이에 들어온 데이터는 실시간 반영이 불가능해 이상 탐지와 같은 작업이 지연
이러한 이유로 대량의 데이터를 실시간으로 처리할 수 있는 스트림 처리로의 전환을 결심하게 되었다고 합니다.
Kafka Streams 선택 이유
Apache Flink vs Kafka Streams
Flink도 좋은 선택지였지만, Kafka Streams는 기존 애플리케이션에 쉽게 통합할 수 있고, 별도의 클러스터 구성이 필요하지 않다는 점에서 큰 이점을 가졌습니다. 또한, 배달의 민족에서는 이미 Kafka를 사용 중이었기 때문에 Kafka Streams의 자연스러운 통합성 때문에 Kafka를 선택 했습니다.
Kafka Streams 기본 개념
- 스트림 프로세서: 카프카의 컨슈머로, 토픽(topic)으로 들어온 데이터를 분산해서 처리
도메인 요구 사항과 처리 전략
배달 이벤트
- 배달 생성, 배차 확정, 픽업 등의 이벤트 발생
라이더 이벤트
- 운행 시작, 이동, 운행 종료의 이벤트 발생
도메인 요구사항
- 배달 이벤트와 라이더 이벤트를 조합해 특정 라이더의 상황 파악
- 행정동 단위로 세분화된 지역별 현황을 집계
- 언제 어디서나 데이터 제공이 보장되도록 구성
요구사항 1: 전처리
- GPS 좌표를 이용해 행정동 단위로 변환
- 라이더 스냅샷과 배달 내역을 조인하여 스냅샷 스트림을 생성
요구사항 2: 지역별 데이터 집계
요구사항 3: 데이터 조회
- 데이터가 있을 경우: 해당 인스턴스의 상태 저장소에서 직접 조회 후 결과 제공
- 데이터가 없을 경우: 메타 데이터를 활용해 데이터 반환
- 상태 저장소에 접근할 수 없을 경우(장애 시): 백업 저장소에서 데이터를 조회하여 제공
운영 중 발생한 이슈들
1. 카프카 메시지 발행 실패
- 원인: 브로커와 클라이언트 간의 통신 실패
- 해결책:
- 브로커와 클라이언트의 설정 조정
- 토픽 파티션 수 최적화
- 토픽의 단위
- 초기 상황: 하나의 토픽에 모든 데이터 발행
- 개선 방안: 도메인 단위로 토픽 구분 (예: 주문, 배달, 라이더)
2. 리밸런싱과 LAG 문제
- 문제 상황: 배포 시 리밸런싱 과정에서 특정 스트림 프로세서에 과도한 LAG 발생
- 해결책: 컨슈머 쓰레드 수 조정
컨슈머 Lag이란?
- 토픽의 최신 메시지와 컨슈머가 처리한 메시지의 위치 차이. 즉, 컨슈머가 아직 처리하지 못하고 쌓인 메시지 양
최적화 팁:
- 서버 증설의 한계를 고려하여 파티션 수와 인스턴스 수에 맞는 적절한 쓰레드 수 설정
- 권장: 파티션 수 = 인스턴스 수 쓰레드 수(num.stream.threads)
리밸런싱(Rebalancing)이란?
- 정의: 컨슈머 그룹 내 컨슈머들에게 작업을 균등하게 분배하기 위해 파티션 할당을 조정하는 동작
- 발생 시점:
- 토픽 파티션 수 증설
- 서버 스케일링
- 컨슈머 이슈로 인한 탈락 시
- 리밸런싱 전략:
- Eager: 모든 컨슈머의 파티션 할당을 끊고 재조정
- Cooperative: 다운 타임을 최소화하지만, Eager보다 여러 번/오래 수행
-> 불필요한 리밸런싱을 방지하기 위해 적절한 설정 적용
3. 디스크 용량 부족
- 원인: 불필요한 상태 저장소 데이터가 디스크 용량 차지
- 해결책: 과거 데이터 삭제로 디스크 사용량 절반으로 감소
- 참고: 카프카는 디스크 기반으로 동작
모니터링 및 관리
- Burrow: Consumer Lag
- Monitoring with JMX: Java Spring 기반이기에 사용(마이크로미터를 이용해 쉽게 수집할 수 있도록 해줌)
- 프로메테우스&그라파나: 스트림 프로세서의 상태 메트릭화
- Service Discovery: 스트림 프로세서 상태 관리(재시작)
- CMAK(Cluster Manager for Apache Kafka, previously known as Kafka Manager): 토픽 설정 및 검증
- 카프카에 내장된 kafka-streams-application-reset tool 을 젠킨스로 wrapping: 스트림즈 리셋 기능
참고할 수 있는 다른 영상
- 클라우드 환경에서 카프카 운영기(우아콘 2022 - 김대호)
- Kafka를 활용한 이벤트 기반 아키텍처 구축(우아콘 2023 - 송인태, 임준수)
'알아두면 좋은 개발 지식 > 컨퍼런스 정리' 카테고리의 다른 글
DDD에 대해서 간단하게 정리하기 (0) | 2024.11.08 |
---|---|
[스프링캠프 2024] Spring AI: LLM에도 봄이 찾아오다 (5) | 2024.11.03 |
[인프콘 2024] 인프런 아키텍처 2024 ~ 2025 (1) | 2024.10.26 |
[인프콘 2024] 지속 성장 가능한 설계를 만들어가는 방법 (5) | 2024.10.19 |
[KCD Korea 2023] CNCF 및 Kubernetes 컨트리뷰션, 지금 여기서 시작하세요! (2) | 2024.10.13 |