Apache Samza 아파치 삼자 사용사례 - Slack
Slack이 하루 수십억 건의 로그를 배치 없이 near real-time으로 처리하기 위해 Apache Samza를 도입한 과정을 정리합니다. Router-Processor-Converter 3단 파이프라인과 A/B 테스트 실시간 측정 사례를 다룹니다.

Slack은 전 세계 기업들이 업무 협업에 사용하는 클라우드 기반 메시징 플랫폼입니다. 수백만 명의 사용자가 매일 메시지를 주고받는 만큼, 서비스 상태를 능동적으로 감지하고 문제가 발생하면 즉시 대응할 수 있는 모니터링 인프라가 필수적이었습니다.
Slack 엔지니어링 팀이 처음에는 배치 처리 방식으로 로그를 집계하고 분석했습니다. 그런데 배치 주기 안에서 발생한 장애는 배치가 끝날 때까지 감지가 되지 않는다는 문제가 있었습니다. 수십억 건의 이벤트가 오가는 환경에서 분 단위 지연조차 허용하기 어려웠습니다. 이 요건을 충족시키기 위해 Apache Samza를 활용한 실시간 스트리밍 파이프라인을 구축했습니다.
Slack 엔지니어링 팀의 요건
- 문제를 즉시 감지할 수 있는 near real-time 수준의 경보 기능
- 데이터 스트림의 장애 허용(fault tolerance)을 지원하는 처리 기능
- 메트릭과 로그에서 수십억 건의 이벤트를 처리하고 애플리케이션 상태를 파악하는 기능
- 다른 팀이 그 위에 자신만의 애플리케이션을 구축할 수 있도록 쉽게 확장 가능한 구조

3단 파이프라인: Router - Processor - Converter
Slack의 모든 서비스는 로그를 정해진 형식으로 내보내며, 이 데이터는 Kafka 클러스터로 유입됩니다. 여기서부터 Samza 작업 세 종류가 순서대로 처리를 이어받습니다.
첫 번째 단계인 Router는 Kafka에서 로그 이벤트를 받아 역직렬화(deserialize)하고, 성능 모니터링을 위한 인스트루먼테이션 정보를 추가한 뒤 다음 단계로 넘깁니다. 두 번째 단계인 Processor는 Router에서 받은 데이터를 Samza의 상태 저장소(state-store)를 활용해 집계합니다. Samza의 로컬 파티션 상태와 changelog 메커니즘 덕분에 애플리케이션당 수백 TB 규모의 상태도 처리할 수 있습니다. 마지막 단계인 Converter는 처리된 결과를 Druid에 연결해 분석과 쿼리가 가능하게 만들고, 비정상적인 성능이 감지되면 Slackbot을 통해 경보를 트리거합니다.
이 구조 덕분에 Slack은 확장 가능한 데이터 플랫폼을 구축했고, 사내 다른 팀들이 이 파이프라인 위에 자신만의 애플리케이션을 얹을 수 있게 되었습니다.
A/B 테스트 실시간 측정
Samza 파이프라인의 또 다른 활용 사례가 실험 프레임워크입니다. A/B 테스트 결과를 near real-time으로 측정해야 하는 요건이 있었는데, 배치 방식으로는 결과 확인에 시간이 너무 걸렸습니다. Samza 파이프라인을 활용해 성능 관련 메트릭과 사용자가 속한 실험 정보를 실시간으로 결합하면서, 각 실험이 전체 고객 경험에 어떤 영향을 미치는지 즉각적으로 파악할 수 있게 됐습니다.
이 파이프라인에서 활용한 Samza의 핵심 기능은 Stateful processing, Join, Windowing 세 가지입니다.
면접에서 이 사례를 쓰는 법
시스템 디자인 면접에서 실시간 스트리밍 처리가 주제로 나올 때, 배치 방식과의 트레이드오프를 먼저 설명하고 Samza 도입 배경을 연결하면 구체성을 높일 수 있습니다. 특히 "왜 Kafka Streams나 Flink가 아니라 Samza인가"라는 질문이 나올 수 있는데, Samza의 로컬 상태 저장 방식이 수백 TB 규모에서 유리하다는 점과 Kafka와의 통합이 긴밀하다는 점을 들면 됩니다. 3단 파이프라인(Router → Processor → Converter) 구조를 도식화해 설명하면 아키텍처 이해도를 보여주기에 좋습니다.