Brain💡 핵심 인사이트 스트림 처리(Stream Processing)는 "끊임없이 생성되는 데이터 이벤트 스트림을 실시간으로 수집, 처리, 분석하는" 패러다임입니다. 배치 처리(Batch Processing)가 "정해진 시간에 정해진 양의 데이터를 처리"한다면, 스트림 처리는 "데이터가 도착하는 즉시 처리하고 결과를 내보내는" 것이 특징입니다. Kafka, Flink, Spark Streaming 등의 기술이 대표적이며, IoT 센서 데이터, 금융 트랜잭션, SNS 실시간 분석, 웹 클릭스트림 등 지연 시간에 민감한 환경에서 필수적입니다.
Ⅰ. 배치 처리와 스트림 처리의 근본적 차이
전통적인 데이터 처리는 배치 처리(Batch Processing) 방식이었습니다.
[배치 처리 vs 스트림 처리: 시간적 관점]
배치 처리:
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 시간 ───────────────────────────────────────────────────────> │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Batch 1 │ │ Batch 2 │ │ Batch 3 │ │
│ │ 09:00까지 │ │ 12:00까지 │ │ 18:00까지 │ │
│ │ 데이터 │ │ 데이터 │ │ 데이터 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ - 데이터가 모이기를 기다림 (latency: 수시간) │
│ - 한번에 대량 처리 (throughput: 높음) │
│ - 중간 결과 없음, 전체 완료 후 결과 │
│ │
└─────────────────────────────────────────────────────────────────┘
스트림 처리:
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 시간 ───────────────────────────────────────────────────────> │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ │
│ Event Event Event Event Event Event Event Event Event Event │
│ ───────────────────────────────────────────────────────────> │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ [처리] [처리] [처리] [처리] [처리] [처리] │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ 결과 결과 결과 결과 결과 결과 │
│ │
│ - 데이터가 도착하는 즉시 처리 (latency: 수초~수밀리초) │
│ - 유입량에 따라 유연하게 스케일링 │
│ - 각 이벤트에 대한 즉각적인 반응/집계 가능 │
│ │
└─────────────────────────────────────────────────────────────────┘
핵심 차이점:
- latency: 배치 처리(수시간) vs 스트림 처리(수초~수밀리초)
- 触发方式: 시간 기반(배치) vs 이벤트 기반(스트림)
- 데이터 범위: 유한 데이터셋(배치) vs 무한 스트림(스트림)
Ⅱ. 스트림 처리의 핵심 개념: Event, Window, State
1. Event (이벤트)
스트림 처리의 기본 단위입니다. "키워드 검색, 사용자 클릭, 센서 측정값, 거래 발생" 등 모든 데이터 변경이 이벤트가 됩니다.
// Kafka 이벤트 메시지 예시
{
"event_type": "purchase",
"user_id": "U12345",
"product_id": "P9876",
"amount": 29900,
"timestamp": "2024-01-15T10:30:00.123Z",
"location": "Seoul"
}
2. Window (윈도우)
끊임없이 유입되는 무한 스트림을 유한한 집합으로 묶어 처리하기 위한 개념입니다.
[윈도우 유형]
1. Tumbling Window (테umbling 창)
- 고정 크기의 겹치지 않는 창
- [0-5초], [5-10초], [10-15초]...
- 각 이벤트는 하나의 창에만 소속
2. Sliding Window (슬라이딩 창)
- 고정 크기, 겹침
- [0-5초] + [2-7초] + [4-9초]...
- 부드러운 이동
3. Session Window (세션 창)
- 특정 이벤트 간격(세션 타임아웃) 기반
- [클릭1 - 3초 - 클릭2 - 10초(타임아웃) - 클릭3]
- 사용자 세션별 집계에 유용
3. State (상태)
이전 이벤트와의 **관계/집계**를 유지하기 위해 필요한 메모리 내 상태입니다.
[State 예시: 5분 윈도우 내 매출 집계]
Flink 코드 스니펫 (의사 코드):
stream
.keyBy("product_id")
.window(SlidingEventTimeWindows.of(Time.minutes(5)))
.reduce((a, b) -> {
// State: 해당 product_id의 현재 윈도우 매출 합계
return new SaleRecord(
product_id = a.product_id,
amount = a.amount + b.amount, // 누산
count = a.count + 1
)
})
Ⅲ. 스트림 처리 아키텍처: Kafka와 Flink
[스트림 처리 시스템 구성]
┌─────────────────────────────────────────────────────────────────┐
│ 스트림 처리 아키텍처 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 데이터 소스 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ IoT │ │ 웹앱 │ │ 모바일 │ │ 외부 API │ │
│ │ Sensors │ │ Backend │ │ App │ │ │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └──────────────┼──────────────┼──────────────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Apache Kafka │ │
│ │ (Event Store) │ │
│ │ │ │
│ │ ┌───────────┐ │ │
│ │ │ Topic: │ │ │
│ │ │ purchases │ │ │
│ │ │ orders │ │ │
│ │ │ clicks │ │ │
│ │ └───────────┘ │ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Apache Flink │ │
│ │ (Stream │ │
│ │ Processor) │ │
│ │ │ │
│ │ - Transform │ │
│ │ - Aggregate │ │
│ │ - Join │ │
│ │ - Window │ │
│ └───────┬───────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Dashboard │ │ Data Lake │ │ Downstream│ │
│ │ (Real-time│ │ (S3/ │ │ Services │ │
│ │ Reports) │ │ ADLS) │ │ │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Apache Kafka:
- 분산 이벤트 스트리밍 플랫폼
- Topic 기반 메시지 저장 (분산 로그)
- 높은 내구성(Durability): 메시지 디스크 저장, 복제
- 높은 처리량(Throughput): 초당 수백만 이벤트 처리 가능
- 낮은 지연(Latency): 수 밀리초 수준
Apache Flink:
- 상태적 스트림 처리 엔진
- Exactly-once 처리 의미론: 이벤트 손실/중복 없음
- _ Event Time 처리_: 데이터 도착 시간ではなく событие 실제 시간 기준 처리
- 强大的 상태 관리: 수 테라바이트规模的 상태 관리 가능
Ⅳ. 스트림 처리의 활용 사례
1. 실시간 대시보드와 모니터링
[활용: 실시간 매출 모니터링]
이벤트:Purchase → Kafka → Flink(5분 윈도우 집계) → Dashboard
Dashboard 표시:
┌─────────────────────────────────────────────┐
│ 📊 실시간 매출 현황 (05분 단위 갱신) │
├─────────────────────────────────────────────┤
│ │
│ 전체 매출: ₩127,450,000 ▲ +3.2% (전년比) │
│ 주문건수: 4,521건 ▲ +5.1% │
│ 평균주문: ₩28,200 ▼ -1.8% │
│ │
│ 실시간 매출 추이: │
│ [████████████████████░░░░░] 진행중 │
│ │
└─────────────────────────────────────────────┘
2. 이상検知/알림 시스템
[활용: 금융 사기検知 (Fraud Detection)]
이벤트 흐름:
1. 카드 거래 이벤트 발생
2. Flink가 계좌 ID로 스트림 조인
3. 최근 10분간 거래 패턴 분석:
- 거래 횟수 > 5회?
- 총 거래금액 > 평균의 3배?
- 기존과 다른 지역에서의 거래?
4. 이상 패턴 감지 → 즉각적 SMS/푸시 알림
5. 결과: 수초 내 카드 사용 중지 가능
Ⅴ. 스트림 처리의 한계와 📢 비유
한계:
- 상태 관리의 복잡성: 유한 상태 머신(FSM)을 설계하고 관리하는 것이 복잡
- 이벤트 시간 처리 어려움: 네트워크 지연, 순서 바뀜 등 지연 데이터(Late Data) 처리가 까다로움
- 정확한 1회 처리의 어려움: 장애 복구 시 exactly-once语义 구현이 엔지니어링적으로 도전적
- _ thérapeutische 도구 부족_: 배치 처리처럼 **SQL로 분석**하기 어려운 면이 있음 (Flink SQL로 개선 중)
📢 섹션 요약 비유: 스트림 처리는 **"급류의 물 관리에 비유"**할 수 있습니다. 배치 처리가 "강의물을 받는다(모이기를 기다린다), 저수지에泵으로 끌어올린다(대량 처리), 시민에게配給한다(결과 활용)"라면, 스트림 처리는 "빗물이 땅에 닿는 순간 Soil에浸透시키고, 초목이 필요한 만큼만送去하고, 多余的 물은 지하수로排出하는" 것과 같습니다. 물이 흐르는 즉시(수 밀리초) 반응하며,每个人에게 맞춤형으로(이벤트별 처리) 제공합니다. 다만 "홍수 시 어떻게 처리할 것인가(과도한 트래픽)", "물 순서가 바뀌었을 때(이벤트 순서 역전)" 등 엔지니어링적 난제가 존재합니다.