실시간 데이터 & Kafka 이해: 스트리밍 플랫폼의 기초
[1단계] 실시간 데이터 & Kafka 이해: 스트리밍 플랫폼의 기초
실시간 데이터 처리의 패러다임을 이해하는 것은 현대 데이터 아키텍처 설계의 첫걸음입니다. 단순히 “빠른 데이터 처리”를 넘어, 데이터가 ‘정지된 상태(Data at Rest)’가 아닌 ‘흐르는 상태(Data in Motion)’로 취급될 때 어떤 변화가 일어나는지 심층적으로 학습해 보겠습니다.
1. 실시간 데이터(Streaming Data)의 핵심 특성
실시간 데이터는 전통적인 데이터베이스에 저장된 데이터와는 다른 3가지 고유한 물리적/논리적 특성을 가집니다.
① 불변성 (Immutability)
- 개념: 한 번 발생한 이벤트는 절대 수정되거나 삭제되지 않습니다.
- 이유: 과거에 일어난 사실(Event)은 변하지 않기 때문입니다. 예를 들어, “A 사용자가 상품을 클릭했다”는 사실 자체는 수정 대상이 아닙니다. 만약 실수가 있었다면, “잘못된 클릭 취소”라는 새로운 이벤트를 발행하여 상태를 보정합니다.
② 순서 보장 (Ordering)
- 개념: 이벤트가 발생한 시간 순서대로 처리되는 것이 매우 중요합니다.
- 중요성: 주식 주문에서 ‘매수’ 후 ‘매도’가 일어나야 하는 것처럼, 인과관계를 파악하기 위해 발생 순서는 데이터의 무결성을 결정짓는 핵심 요소입니다.
③ 무한성 (Unboundedness)
- 개념: 데이터의 시작은 있지만 끝이 없습니다.
- 차이점: 배치(Batch) 처리는 “오늘 하루치 데이터”라는 경계(Bound)가 있지만, 스트리밍 데이터는 서비스가 운영되는 한 24시간 내내 끊임없이 밀려드는 데이터의 강물과 같습니다.
2. Kafka가 단순 메시지 큐(MQ)를 넘어서는 이유
전통적인 메시지 큐(예: RabbitMQ, ActiveMQ)와 Kafka는 설계 철학부터 다릅니다. 왜 Kafka를 ‘스트리밍 플랫폼’이라 부르는지 3가지 관점에서 비교합니다.
① 소비 방식의 차이: Push vs Pull
- 일반 MQ (Push): 브로커가 소비자에게 데이터를 밀어넣습니다. 소비자가 처리 중이면 브로커가 기다려야 하거나 부하가 걸릴 수 있습니다.
- Kafka (Pull): 소비자가 자신이 처리할 수 있는 속도에 맞춰 데이터를 가져옵니다. 이로 인해 소비자의 처리 성능에 따라 시스템 전체가 느려지는 현상을 방지합니다.
② 데이터의 영속성 (Durability)
- 일반 MQ: 메시지를 읽어가면 큐에서 즉시 삭제됩니다.
- Kafka: 메시지를 읽어가도 설정된 기간(Retention Period) 동안 디스크에 안전하게 저장됩니다.
- 이점: 장애 발생 시 과거 데이터를 다시 읽어와 복구(Replay)할 수 있고, 새로운 서비스가 투입되었을 때 과거 데이터부터 학습을 시작할 수 있습니다.
③ 대규모 확장성 (Scalability)
- 일반 MQ: 확장이 어렵거나 성능 저하가 큽니다.
- Kafka: ‘파티션(Partition)’이라는 개념을 통해 여러 대의 서버에 데이터를 분산 저장하고 병렬로 처리합니다. 수천 대의 서버로 확장해도 성능 손실이 거의 없습니다.
3. Kafka의 핵심 철학: “Log 기반 아키텍처”
Kafka의 모든 디자인은 ‘Append-only Log’ 파일 구조에서 시작됩니다.
- 구조: 데이터는 파일의 끝에 차례대로 추가만 됩니다. (수정 불가)
- 성능 비밀: 디스크의 랜덤 액세스가 아닌 순차 쓰기(Sequential Write)를 사용하기 때문에 디스크 기반임에도 메모리에 필적하는 놀라운 속도를 냅니다.
- 오프셋(Offset): 각 메시지는 파티션 내에서 고유한 번호(Offset)를 가집니다. 소비자는 “어디까지 읽었는지” 번호표만 관리하면 되므로 관리 비용이 매우 낮습니다.
4. 정리 및 학습 포인트
| 구분 | 단순 메시지 큐 (Legacy MQ) | Kafka 스트리밍 플랫폼 |
|---|---|---|
| 데이터 보관 | 전송 후 즉시 삭제 | 설정 기간 동안 디스크 보존 |
| 처리 방식 | 일회성 전달 목적 | 실시간 분석, 로그 통합, 이벤트 소싱 |
| 유연성 | 특정 소비자만 데이터 수령 | 여러 소비자 그룹이 독립적으로 재사용 가능 |
| 처리량 | 낮음 (수만 건/초) | 매우 높음 (수백만 건/초 이상) |
[1단계 핵심 질문]
- 사용자 로그 데이터에서 ‘불변성’이 깨지면 어떤 문제가 발생할까요?
- Kafka 브로커가 데이터를 디스크에 저장함에도 불구하고 성능이 빠른 이유는 무엇인가요?
- 이미 읽어간 데이터를 다시 읽어야 하는 상황(Replay)은 실무에서 언제 발생할까요?
위 질문들에 대해 스스로 답을 내려보시면 Kafka의 기초 철학을 완벽히 이해하신 것입니다. 다음 단계인 [Docker 기반 클러스터 구축]을 통해 이 이론들이 어떻게 실제로 구현되는지 확인해 보겠습니다.
