1. 프롤로그

데이터 엔지니어링 직무에 관심을 가지게 된 이후 10억행 챌린지(1BRC)를 해보면서 단순히 기술들을 사용하여 대용량 데이터처리가 잘 되는지 결과만 확인했습니다.

핵심은 단순 결과가 아니라, 설계부터 시작해서 운영까지 책임지며 현재 시스템에 적합한 설정을 찾아가는 과정이 중요하다고 생각되어 역량을 기르기 위한 고민을 하였습니다.

한발 더 들어가서 데이터 엔지니어의 업무를 깊게 분석해보는 과정에서 스트리밍 데이터를 처리하는 것에 매력을 느끼고 이 시스템을 안정적이고 확장가능한 구조를 설계하고 구축하는 역량을 키워야겠다는 필요성을 느꼈습니다.

“스트리밍 데이터를 다루는 비지니스가 뭐가 있을까?” 고민 하던 중 광고 도메인의 노출 대비 클릭의 비율(CTR)의 개념 발견 하였습니다. 추후 개인화된 광고 서비스에 사용될 수 있을 것 같다는 생각에 흥미를 느껴 주제로 선정하였습니다.

1.1 기능 파악

CTR은 조회수와, 클릭의 각 데이터가 카프카 이벤트가 들어오면 서버에서 수신하고 데이터를 가공합니다.

그러나 이벤트는 항상 시간 순서대로 도착하지 않고, 네트워크 지연과 파티션 편향 문제도 존재한다는 점을 파악했습니다.

따라서 정확한 윈도우 집계, 지연 이벤트 처리, 높은 처리량·낮은 지연을 동시에 만족하는 것이 중요하다고 판단되었습니다.

1.2 아키텍처 설계

graph LR
    A[Python Producers] -->|Events| B[Kafka Cluster]
    B -->|impressions| C[Flink Stream Processing]
    B -->|clicks| C
    C -->|CTR Results| D[Redis]
    C -->|CTR Results| E[ClickHouse]
    C -->|CTR Results| F[DuckDB]
    D -->|Serve| G[FastAPI]

    style C fill:#ff6b6b
    style B fill:#4ecdc4
    style D fill:#ffe66d

1.3 프로젝트 저장소

GitHub - dev-wooyeon/ctr-pipeline: 실시간 CTR 스트림 데이터 파이프라인 연습 레포


2. 핵심 개념

2.1 CTR 계산이 스트림 처리에서 어려운 이유

  1. Impression·Click 간의 시계열 상관성이 필요하다.
  2. 이벤트가 지연되거나 순서가 뒤바뀌어 도착할 수 있다.
  3. CTR 계산은 짧은 시간 창(window) 단위로 이루어져야 한다.