Kafka 기술 블로그 최신 글

Batch Runner 를 만들다 (Event-Driven + Scheduled Batch 아키텍처)

WORXPHERE 통합 서버에서 하이브리드 아키텍처로의 진화 [Batch Runner] 들어가며 잡코리아 메인 페이지에서는 다양한 형태의 CPT(Cost Per Time) 상품을 제공하고 있습니다. 주문 상품, 테마관, 슈퍼기업관 등 각기 다른 특성을 가진 상품들이 사용자에게 노출되는데요. 이러한 상품들의 데이터를 조회하고 HTML 데이터를 생성하는 작업은 초기에 Windows 스케줄러를 통해 5분마다 배치 API를 호출하고, 같은 서버에서 사용자 서비스도 함께 제공하는 방식으로 구현되어 있었습니다. 하지만 서비스가 성장하면서 개선이 필요한 부분들이 명확해졌습니다. 매번 전체 데이터를 조회하는 Full Scan의 부담, 서비스 서버와 배치 서버의 분리 필요성, 트래픽 증가에 대한 탄력적 대응의 어려움 등이었습니다. 이 글에서는 초기 배치 시스템을 개선하고, Event-Driven + Scheduled Batch 하이브리드 아키텍처로 어떻게 진화시켰는지, 그 과정에서의 의사결정과 구현 방식을 소개하겠습니다. 개선이 필요했던 이유 초기 구조 초기 구조는 API 서버와 배치 처리가 하나로 통합된 서버에서, Windows 스케줄러를 통해 5분마다 배치 API를 호출하여 모든 CPT 상품 데이터를 Full Scan으로 조회하고 HTML 데이터를 생성하는 방식이었습니다. [Windows 스케줄러] → (5분마다) → [통합 서버] ├─ 배치 API 호출 ├─ Full Scan 데이터 조회 ├─ HTML 데이터 생성 └─ 사용자 요청 처리 초기 구조의 강점 구현이 단순함: 매번 전체 데이터를 조회하기 때문에 실패해도 다시 실행하면 됨 데이터 정합성: 항상 최신 상태의 전체 데이터를 기준으로 처리 빠른 출시: 단순한 구조로 초기 서비스를 빠르게 런칭할 수 있었음 개선이 필요했던 포인트 서비스가 성장하면서 다음과 같은 개선 포인트가 명확해졌습니다. 비효율적인 조회 방식: 변경되지 않은 데이터까지 매번 Full Scan으로 조회하여 불필요한 DB 부하가 발생했습니다 서버 역할 분리 필요: 배치 처리 서버와 사용자 서비스 서버가 같은 서버이다 보니, 배치 장애 발생 시 서비스 전체에 영향을 줄 수 있었습니다 탄력적 확장의 어려움: 트래픽 증가 시 배치 처리와 서비스 처리를 독립적으로 스케일링하기 어려웠습니다 배치 윈도우 초과: 주문이 몰리는 날에는 5분 배치 주기 내에 데이터 처리를 완료하기 어려워 지연이 누적되었습니다 전환의 계기 서비스가 성장하면서 배치 처리와 사용자 서비스의 분리 필요성이 더욱 명확해졌습니다. 또한 주문이 많은 날에는 주문 데이터를 빠르게 처리해야 한다는 요구사항이 강해졌습니다. 기존 Full Scan 방식으로는 지연이 발생해 처리가 어려웠습니다. 새로운 아키텍처 설계 요구사항 문제를 해결하기 위해 새로운 아키텍처가 갖춰야 할 요구사항을 정리했습니다. 서비스 독립성 : 배치 서버 장애가 사용자 서비스에 영향을 주지 않아야 함 탄력적 확장 : 트래픽 증가 시 API 서버만 스케일 아웃 가능해야 함 실시간 반영 : 주문 상품은 결제 즉시 메인에 노출되어야 함 효율적인 조회 : 전체 데이터가 아닌 변경된 데이터만 조회해야 함 데이터 유실 방지 : 서버 장애 시에도 처리할 데이터가 유실되지 않아야 함 중복 방지 : 동일한 데이터가 중복 처리되어서는 안 됨 변경된 아키텍처 새로운 구조는 배치 서버, Data Express, Display API 서버로 역할을 분리하고, 주문 상품은 Kafka Event로 실시간 처리하며, 테마관/슈퍼기업관은 스케줄 기반으로 Full/Incremental 처리하는 방식으로 설계되었습니다. 새로 변경된 아키텍처 BatchRunner 모든 배치를 동일한 방식으로 처리할 필요는 없다. 상품 특성에 맞는 최적의 처리 방식을 선택하자. 왜 하이브리드 구조인가? 모든 상품을 동일한 방식으로 처리하지 않고, 상품 특성에 따라 서로 다른 처리 방식을 선택한 이유는 명확합니다. 주문 상품 → Event-Driven (Kafka) 주문 상품은 사용자가 결제하는 순간 주문 이벤트가 발생하므로, 이를 즉시 처리

실패한 메시지는 어디로 가야 할까?- Kafka Retry/DLT 설계와 운영에서 밟은 3가지 함정

Grafana Mimir에 Kafka를 도입하기 전 미리 알았다면

partition 1대1 결합과 Mimir Kafka의 운영 포인트

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

들어가며: 왜 Kafka 종단 간 암호화인가?LINE 메신저에서는 매일 수십억 건의 메시지가 오갑니다. 이 방대한 데이터는 다양한 시스템으로 전달되며, 그중에는 개인 정보와 같이 ...

운영하지 않는 Kafka, EasyQueue를 소개합니다

 # 운영하지 않는 Kafka, EasyQueue를 소개합니다 Kafka를 직접 띄워보신 적 있으신가요. 처음에는 "이거 그냥 `docker compose up` 하면 되는 거 아냐?"로 가볍게 시작합니다. 그러다 운영 환경으로 옮기는 순간 일이 달라지죠. 브로커는 몇 대로 띄울지, 디스크는 어떻게 잡을지, 복제본 수와 리텐션은 얼마로 잡을지, 백업·모니터링·알람은 또 어떻게 붙일지로 일주일이 사라집니다. 어느새 본업은 Kafka 운영이 되어 있습니다. 그렇다고 클라우드의 관리형 서비스로 도망치자니, 이번엔 다른 고민이 시작됩니다. 기존 Kafka 클라이언트 코드는 그대로 쓸 수 있는지, 토픽 설정은 직접 손댈 수 있는지, 컨슈머 Lag 같은 운영 지표는 어떻게 볼 것인지.

카프카 파티션 개수 산정식 설계 여정

Broker 특성, Latency, Peak traffic, Backfill catch-up을 모두 고려한 과정

45분 배치에서 준실시간으로! 다수 도메인 데이터를 Kafka로 통합한 전환기

…

주문 트래픽 20배를 견디는 재고 처리 구조 만들기

lock 경합을 걷어내고 Redis·Kafka로 재고 처리를 다시 설계한 이야기

Kafka에서 S3로 실시간 데이터 수집 파이프라인 설계와 구축기

안녕하세요, 펫프렌즈 데이터플랫폼 파트의 데이터 엔지니어 루카스입니다. 펫프렌즈의 데이터 수집과 가공은 대부분 배치 방식으로 운영되어 왔습니다. 하지만 최근 데이터의 활용 맥락이 다양해지면서 실시간 이벤트 데이터 수집 필요성이 나타났습니다. 이번 글에서는 실시간 수집 파이프라인을 도입하게된 배경과 설계 과정에서 고민했던 주요 의사결정에 대해 공유드리려 합니다. 이번 글의 구성 실시간 수집이 필요해진 이유 Connector vs Consumer 핵심 설계 실패처리 운영 모니터링 결과 앞으로의 계획 실시간 수집이 필요해진 이유 첫 번째 이유는 MariaDB Trigger 기반으로 운영되던 로그 테이블의 한계였습니다. 기존에는 상품 변경 이력을 TRIGGER 로 감지해 LOG 테이블에 적재했는데, 컬럼이 추가될 때마다 Trigger 문과 로그 테이블 스키마를 함께 수정해야 했습니다. 운영 중인 DB에서 스키마 변경이 자주 일어나다 보니 관리 부담이 커졌고, 결국 기존 로그 테이블을 유지하지 못한 채 아예 새 버전을 만들어야 하는 상황까지 이어졌습니다. 이 과정에서 “이런 로그성 데이터를 RDB에 계속 쌓는 게 맞을까?” 하는 생각이 들었습니다. 데이터량이 늘수록 스토리지와 인덱스 관리 비용이 커지고, 확장성에도 한계가 있었기 때문입니다. 그래서 Trigger 대신 CDC(Change Data Capture) 기반으로 로그 이벤트를 Kafka 토픽으로 발행하고, 이를 별도의 컨슈머가 읽어 S3에 적재하는 방향으로 전환했습니다. 펫프렌즈에는 기존에 MSK + Debezium으로 CDC 토픽을 이미 보내고 있어 이를 활용해 컨슈머를 개발하기로 했습니다. 두번째 이유는 광고 및 사용자 행동 이벤트 데이터를 장기 보관하고 분석하기 위해서입니다. 광고 노출, 클릭이나 주문 완료 같은 데이터를 수집해 광고 성과 분석이나 리포트에 활용하고자 하는 요구가 있었습니다. 이벤트 실시간으로 발생하기 때문에 Kafka 토픽을 직접 소비해 저장하는 파이프라인이 필요했습니다. 이런 요구를 충족하기 위해 데이터팀에서 레이크하우스로 운영 중인 S3 + Athena 조합을 선택했습니다. S3는 Schema-on-Read 구조를 제공하기 때문에 데이터를 원형 그대로 저장한 뒤, 필요할 때 스키마를 정의해 읽을 수 있습니다. 별도의 테이블 스키마 변경이나 컬럼 추가 작업이 필요 없어 운영 부담이 적고 확장성도 높습니다. Connector vs Consumer Kafka의 토픽 데이터를 S3에 저장할때 일반적으로 S3 Sink Connector를 사용하는 방법이 있습니다. Connector를 사용하면 큰 운영 부담없이 설정만으로 토픽의 데이터를 S3에 적재할 수 있는 장점이 있습니다. 하지만 저희는 컨슈머 애플리케이션을 직접 개발했는데 이유는 다음과 같습니다. 1) Parquet 포맷 저장을 위한 제약 Athena에서 효율적으로 쿼리하기 위해서는 열 지향 포맷(Parquet) 사용이 사실상 필수입니다. 하지만 현재 구조에서 사용하는 Debezium + S3 Sink Connector 조합은 기본적으로 JSON 포맷만 지원하고 있었습니다. Parquet으로 변환하려면 Schema Registry 등 추가 구성이 필요했지만, 이는 여러 팀의 CDC 파이프라인에 영향을 주기 때문에 도입이 어렵다고 판단했습니다. 다음 대안으로 Connector로 JSON을 저장한 뒤 Parquet으로 변환하는 별도 파이프라인을 두는 방법도 검토했습니다. 하지만 이 경우 처리 지연(latency)이 한 번 더 생기고 운영 복잡도도 올라갑니다. 또한 Connector의 파일 flush 로직이 “Rotation Flush” 방식이라 새로운 이벤트가 일정 시간 동안 없으면 파일이 닫히지 않아 S3 업로드가 지연되는 문제도 있었습니다. 2) 세부 제어와 비즈니스 로직 반영 필요 Trigger 방식에서는 특정 컬럼이 업데이트 되는 경우 제외되는 등 세부적인 조건 로직이 존재했습니다. 이런 로직을 CDC 기반으로 전환하면서도 동일하게 반영하려면 Debezium의 SMT(Single Messa

실시간 파생 데이터 생성 : Kafka + Spark로 하루를 앞당기다

SK플래닛의 Hadoop 기반 Data Integration Cluster(이하 DIC)는 서비스의 다양한 데이터를 수집하고 분석하는 데 사용합니다. 데이터의 분석을 수행할 때는 새로운 정보나 인사이트를 위해 다른 테이블과의 조인 및 변환을 통해 파생 데이터를 생성하며, 파생 데이터를 생성하는 여러 방법 중 Hive Query…