Message Brokers & Stream Processing

1. Overview

메시지 브로커 및 스트림 처리(Message Brokers & Stream Processing, MBS)는 시스템 간의 소통을 '즉시' 대화에서 '기록된' 흐름으로 변환하여 병목을 없애는 분산 시스템의 혈류입니다.

학습자는 메시지를 저장하고 전달하는 **브로커(Broker)**의 물리적 저장 방식(Index vs Log)의 차이를 배웁니다. 특히, 정적인 데이터를 넘어 끊임없이 흐르는 데이터를 실시간으로 변환, 집계하는 **스트림 프로세싱(Stream Processing)**의 수리적 사상과 **윈도잉(Windowing)**의 물리적 동작을 익힙니다. 이를 통해 수백만 개의 이벤트를 유실 없이 수용하고, 밀리초 단위로 비즈니스 인사이트를 도출하는 하이엔드 이벤트 인프라 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Broker Topologies: RabbitMQ(Queue), Kafka(Log-based)의 물리적 저장 구조 차이
• Message Semantics: At-most-once, At-least-once, Exactly-once 전달 수리 모델
• Stream Processing Mechanics: Stateless vs Stateful 연산의 물리적 차이
• Windowing Strategies: Tumbling, Sliding, Session 윈도우 기반 수치 집계 물리학
• Backpressure in Queues: 생산자가 소비자보다 빠를 때의 하드웨어 부하 분산

Out-of-Scope

• 개별 메시지 브로커의 대시보드 UI 및 설치 상세 (인프라 조립 영역으로 위임)
• 배치 프로세싱(Hadoop 등)의 오프라인 데이터 처리 (06-04-04 영역에서 분담)

Boundaries

• MBS vs. Pub-Sub: Pub-Sub(07-04-02)이 '소통 모델'에 집중한다면, MBS는 그 메시지를 '저장하고 실시간 처리하는 물리적 엔진'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "메시지 보내기"라 설명하는 것은 MBS 학습이 아닙니다. 왜 **로그 기반 브로커(Kafka)**가 파일 시스템의 순차 I/O를 활용하여 물리적 고성능을 내는지 하드웨어적으로 증명할 수 있어야 하며, **장애 상황(Consumer Down)**에서 오프셋(Offset) 관리가 왜 분산 시스템의 정합성을 좌우하는 유일한 수리적 장치인지 분석하지 못한다면 MBS의 본질을 이해하지 못한 것입니다.

4. Prerequisites

• indexing & B-Tree Storage Mechanics (Basic): 파일 I/O와 인덱스 이해가 필수입니다. (06-01-02 IBS)
• Theorems & Consistency Dynamics (Recommended): Exactly-once 달성의 수리적 난제 이해가 권장됩니다. (07-02-01 TCD)

5. Learning Map

1. The Post Office: 서버 간에 메시지를 던지고 잊어버리는(Fire-and-forget) 물리적 기반을 닦습니다.
2. Infinite Log: 메시지를 단순 큐가 아닌 '지워지지 않는 기록'으로 남겨 재생(Replay) 가능한 물리를 구축합니다.
3. Data River: 쏟아지는 이벤트들을 하나씩 계산하지 않고 '흐름' 전체로 다루는 수리적 시야를 확보합니다.
4. Real-time Insight: 흐르는 강물 위에서 5분간의 평균값을 잡아내는 윈도잉 공학을 완성합니다.

6. Learning Topics

Basic

Core: 메시지 브로커의 유형과 물리 저장 (Broker Fundamentals)

• Why to Learn: 애플리케이션의 응답 대기 시간을 물리적으로 제거하고 시스템 간 결합을 끊기 위해서입니다.
• What to Learn:
  • Queue vs Log: 메시지를 소비하면 지우는 방식과 순차 인덱스로 저장하는 방식의 물리적 차이
  • Persistence: 메모리 기반의 속도와 디스크 기반의 안전성 사이의 수리적 중심
  • Routing Keys: 메시지의 머리말을 보고 목적지를 결정하는 물리 필터링
• How to Learn:
  • RabbitMQ와 Kafka에 동일한 양의 이벤트를 쏘고, 소비자가 죽었을 때 데이터 복구 가능 여부를 측정하는 실습
  • 메시지 영속화(Persistence) 설정에 따른 하드웨어 처리 지연 시간 관찰
• Implement: 주제(Topic)에 따라 메시지를 다른 큐로 분산하는 가상 ExchangeRouter

Recommended

Core: 전달 보장과 Exactly-once 물리학 (Delivery Semantics)

• Why to Learn: 네트워크 장애 시 메시지가 중복되거나 유실되어 비즈니스 사고가 터지는 것을 막기 위함입니다.
• What to Learn:
  • At-least-once: 유실은 없지만 중복이 물리적으로 허용되는 단계
  • Exactly-once: 중복과 유실 모두를 수리적으로 차단하는 이상적 상태 ($Transactions$ 필요)
  • Consumer Offsets: 어디까지 읽었는지 기록하는 물리적 '책갈피' 관리
• How to Learn:
  • 오프셋 기록 직전에 서버를 껐을 때, 재기동 후 메시지가 중복 처리되는 현상을 수치로 재현 실습
  • 멱등성(Idempotency) 로직이 Exactly-once에 미치는 물리적 보완 효과 분석
• Implement: 유일한 메시지 ID를 체크하여 중복 소비를 수리적으로 차단하는 DeduplicationConsumer

Practical

Core: 스트림 처리와 상태 관리 (Processing Mechanics)

• Why to Learn: 데이터를 저장한 뒤 분석하는 과거의 방식에서 벗어나 실시간 하드웨어 반응성을 얻기 위해서입니다.
• What to Learn:
  • Stateless transformation: 필터링, 매핑 등 과거 기억이 필요 없는 물리 연산
  • Stateful aggregation: 누적 합계, 랭킹 등 이전 데이터를 기억해야 하는 수리 모델
  • Checkpointing: 장애 시 상태를 복구하기 위해 하드웨어 저장소에 상태를 굽는(Persist) 절차
• How to Learn:
  • 실시간 로그에서 '에러'만 필터링하는 파이프라인과 '시간당 에러 수'를 세는 파이프라인의 하드웨어 부하 비교 실습
  • 대규모 상태값이 로컬 메모리를 압도할 때 발생하는 물리적 스와핑(Swapping) 문제 산출
• Implement: 데이터 한 건이 들어올 때마다 상태를 갱신하고 결과를 반환하는 StreamAggregator

Advanced

Core: 윈도잉과 시간 지연 물리학 (Windowing & Watermarks)

• Why to Learn: 네트워크 지연으로 뒤늦게 도착한 데이터까지 고려한 정확한 실시간 집계를 하기 위함입니다.
• What to Learn:
  • Processing Time vs Event Time: 시스템 시간과 실제 발생 시간의 물리적 괴리
  • Watermarks: "이 시점의 데이터는 다 온 것으로 간주한다"는 수리적 임계선
  • Windowing Physics: 일정 시간 간격으로 데이터를 가두어 연산하는 기법
• How to Learn:
  • 10초 늦게 도착한 결제 데이터가 윈도우 집계 결과($Total$)를 어떻게 물리적으로 뒤트는 분석 실습
  • 지연 데이터(Late data) 처리 전략(Drop vs Side Output)의 비즈니스적 가치 산출
• Implement: 이벤트 시각을 기준으로 1분 단위 합계를 계산하고 지각 데이터를 처리하는 TemporalAnalyzer

7. Terminology

8. References

Primary

• [P1] CS2023 - SF/Systems Fundamentals (Message passing and queues) — Core requirements.
• [P1] CS2023 - DM/Data Management (Stream processing and pipelines) — Detailed context.

Secondary

• [Designing Data-Intensive Applications (DDIA)] Martin Kleppmann — Chapters on Stream Processing and Derived Data.
• [Streaming Systems] Tyler Akidau — The bible of stream processing concepts (Watermarks, Windowing).

Industry

• [Confluent: What is Apache Kafka?] — Detailed architectural principles.
• [Apache Flink: Stateful Functions and Stream Processing] — Advanced operational guide.

9. Final Checklist

Primary

• '큐 기반 브로커'와 '로그 기반 브로커'의 물리적 읽기/쓰기 성능 차이가 발생하는 하드웨어적 근거를 설명 가능한가? (P1)
• 'at-least-once' 전달 방식이 보장될 때, 애플리케이션 레벨에서 '중복 처리'를 막기 위한 수리적 전략을 기술할 수 있는 가? (P1)

Secondary

• '이벤트 시간(Event Time)' 기준 처리가 왜 분산 시스템의 네트워크 지연 하에서도 정합성을 보장하는 핵심 물리가 되는지 소통 가능한가?
• 체크포인팅(Checkpointing) 주기가 시스템의 처리량($Throughput$)과 복구 시간($RTO$) 사이에서 어떤 물리적 저울질을 하는지 논증할 수 있는 가?

Industry

• 실시간 부정 결제 탐지 시스템 설계 시, '슬라이딩 윈도우'가 유발하는 하드웨어 메모리 점유율을 추산하고 대응 방안을 제안할 수 있는 가? (SFIA)
• 'Kafka'의 컨슈머 그룹 재조정($Rebalance$) 과정에서 트래픽 처리가 물리적으로 정지되는 구간을 분석하고 최적화할 수 있는 가?