[스터디] Kafka와 Redis를 활용한 대규모 실시간 시청자 수(CCU) 집계 시스템 설계

오늘은 스터디에서 "실시간 시청자 수를 어떻게 대규모 환경에서 안전하게 집계할 것인가"를 주제로 공부함. 개인적으로 분산 처리나 전문 용어에 익숙해지기 위해, 논의되었던 핵심 설계 포인트들을 기록용으로 정리

1. 단순 입/퇴장 로그 방식의 한계와 보완

처음엔 사용자가 들어올 때(Join)와 나갈 때(Leave) 로그를 남겨서 그 차이를 구하면 된다고 생각했음. 하지만 실무에서는 비정상 종료(앱 강제 종료, 네트워크 단절) 시 '퇴장' 로그가 남지 않는 문제가 치명적임.

이를 해결하기 위해 하트비트(Heartbeat) 개념을 도입함. 클라이언트가 주기적으로 "나 아직 보고 있어"라는 신호를 보내고, 서버는 이 신호가 끊기면 유효시간(TTL) 만료로 판단해 자동으로 인원수에서 제외함.

2. 고가용성을 위한 데이터 처리: 핫패스와 콜드패스

데이터의 목적에 따라 두 가지 경로로 나누어 처리하는 '람다 아키텍처'적 접근이 필요함.

• 핫패스(Hot Path): 실시간성이 최우선. 0.5~1초 간격으로 UI에 즉시 숫자를 업데이트함. 약간의 오차는 허용함.
• 콜드패스(Cold Path): 정확성과 기록이 최우선. 방송 종료 후 전체 로그를 대조하여 봇(Bot)이나 중복 데이터를 필터링하고 정밀한 통계를 산출함.

3. 부하 분산을 위한 핵심 기술 (샤딩, 폴딩, Lua)

시청자가 수십만 명일 때, 특정 데이터(Key) 하나에만 업데이트가 몰리면 병목 현상이 생김.

• 카운터 샤딩(Counter Sharding): 하나의 카운터를 여러 개의 '샤드(Shard)'로 쪼개어 쓰기 부하를 분산함.
• 폴딩(Folding): 쪼개진 샤드들의 값을 주기적으로 다시 합쳐서 최종 합계를 구하는 과정임.
• Lua Script: Redis 내부에서 여러 샤드의 값을 읽고 합산하는 로직을 '원자적(Atomic)'으로 한 번에 처리하기 위해 사용함. 네트워크 지연을 줄이고 데이터 일관성을 보장함.

4. 웹소켓과 팬아웃 (실시간 전파)

업데이트된 숫자를 사용자에게 전달하는 과정임.

• 웹소켓(WebSocket): HTTP와 달리 한 번 연결하면 유지되는 양방향 통로임. 서버가 클라이언트에게 실시간으로 데이터를 밀어줄 수 있음(Push).
• 팬아웃(Fan-out): 하나의 메시지를 수많은 접속자에게 동시에 뿌려주는 구조를 말함.

5. 엔터프라이즈급 하이브리드 설계 (Kafka + Redis)

단순 구현을 넘어 대규모 서비스에서 사용하는 범용적인 구조는 아래와 같음.

1. Gateway → Kafka: 모든 사용자 이벤트를 Kafka로 던져서 완충 작용을 함.
2. Kafka Streams: 스트림 데이터를 실시간 집계함. 이때 EOS(Exactly-Once Semantics)를 활용해 중복 카운팅을 원천 차단함.
3. Redis & Fan-out: 집계된 최종 값은 초저지연 조회를 위해 Redis에 캐싱하고, 웹소켓을 통해 사용자들에게 팬아웃함.

6. 추가 정리: 파티셔닝 vs 샤딩

• 파티셔닝: 한 대의 서버 안에서 테이블을 쪼개는 것.
• 샤딩: 여러 대의 서버로 데이터를 나누어 저장하는 것. (수평적 확장)

---

학습 소감:

• 단순히 숫자를 세는 작업도 대규모 환경으로 가면 분산 처리와 데이터 정합성 보장을 위해 이렇게나 복잡한 아키텍처가 필요
• 특히 Kafka의 EOS나 Redis Lua Script 같은 도구들이 왜 필수적인지 이해할 수 있었음.