콘텐츠로 바로가기
HY_TECH_BASE

Distributed Messaging & Event Streaming

시스템 간 비동기 결합을 위한 메시지 큐와 대규모 데이터의 흐름을 처리하는 이벤트 스트리밍 기술의 작동 물리 및 보장 수준을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

분산 메시징 및 이벤트 스트리밍(Distributed Messaging & Event Streaming, DMS)은 현대 소프트웨어 시스템이 수직적 명령 구조를 벗어나 사건(Event) 기반으로 실시간 소통하는 방식의 물리적 토대를 다룹니다.

데이터는 더 이상 요구할 때만 생성되는 것이 아니라, 끊임없이 흐르는 '로그(Log)'의 형태를 띱니다. 학습자는 송신자와 수신자를 논리적으로 분리(Decoupling)하는 메시지 브로커(RabbitMQ 등)와 고가용성 분산 로그인 이벤트 스트리밍(Kafka 등)의 본질적 차이를 배웁니다. 이를 통해 'At-most-once'부터 'Exactly-once'까지의 전송 보장 수준과 소비자 그룹(Consumer Group)의 물리적 확장성을 이해하여, 데이터 유실 없이 초당 수백만 건의 이벤트를 처리하는 아키텍처를 설계합니다.

2. Scope & Boundaries

In-Scope

  • Messaging Models: P2P(Point-to-Point) vs Pub/Sub(Publish/Subscribe) 메시징 물리
  • Event Logging: 순차적 쓰기 로그(Append-only Log)와 오프셋(Offset) 관리 역학
  • Delivery Semantics: 메시지 전송 보장 수준(At-most, At-least, Exactly-once)의 논리
  • Scalability: 파티셔닝(Partitioning), 소비자 그룹 및 부하 분산(Load Balancing) 물리

Out-of-Scope

  • 스트리밍 데이터의 복잡한 SQL 분석(Flink, Spark) 로직 (11. ML/AI 영역으로 위임)
  • 특정 메시지 브로커의 클러스터 설치 및 하드웨어 구성 (09. DevOps 영역으로 위임)

Boundaries

  • DMS vs. Web Protocols: 08-03(WAP)이 '즉각적인 응답이 필요한 동기 통신' 중심이라면, DMS는 '응답을 기다리지 않는 비동기 흐름과 데이터의 영속성'에 집중합니다.

3. Counterexample

  • 단순히 메시지 큐를 사용하여 작업을 백그라운드로 넘기는 법을 익히는 것은 DMS 학습이 아닙니다. 왜 메시징 시스템에서 **순서 보장(Ordering Guarantee)**이 물리적으로 어려운 과제인지 설명하고, 카프카와 같은 시스템이 파티션(Partition) 단위로 어떻게 순서를 강제하며 분산 커밋 로그를 통해 장애 복구를 수행하는지 그 신뢰성 매커니즘을 논할 수 있어야 합니다.

4. Prerequisites

  • 네트워크 기초 및 OSI 스택 (Basic): 소켓 통신과 비동기 I/O의 기본 개념이 필요합니다. (08. NFS)
  • 분산 시스템 원칙 및 합의 (Recommended): 분산 환경에서의 데이터 일관성 및 리더 선출 개념이 권장됩니다. (07. SADS)

5. Learning Map

  1. Async Communication: 왜 시스템들이 서로 기다리지 않고 메시지를 던져두고 가는지(Fire-and-forget) 그 이점을 배웁니다.
  2. Broker Patterns: 메시지를 안전하게 보관했다가 전달해주는 중개인(Broker)들의 다양한 작업 모델을 익힙니다.
  3. The Power of Log: 모든 사건을 영구적으로 기록하고 다시 읽을 수 있게 하는 이벤트 스트리밍의 물리 구조를 이해합니다.
  4. Reliability & Scale: 데이터가 유실되지 않도록 보장하면서 동시에 수많은 노드로 확장하는 설계 전략을 탐구합니다.

6. Learning Topics

Basic

Core: 메시지 큐와 Pub/Sub 기본 (Messaging 101)

  • Why to Learn: 시스템 간의 결합도를 낮추어 유연하고 확장 가능한 설계를 하기 위함입니다.
  • What to Learn:
    • 생산자(Producer)와 소비자(Consumer)의 논리적 분리
    • 큐(Queue) vs 토픽(Topic)의 메시지 전달 물리 차이
    • 브로커 기반 메시징의 기본 흐름(Push vs Pull 모델)
  • How to Learn:
    • 간단한 메시지 큐(예: Redis Pub/Sub)를 활용해 두 개의 독립된 프로세스가 데이터를 주고받는 실습
    • 트래픽 폭주 시 큐가 완충 작용(Buffering)을 하여 시스템 붕괴를 막는 시나리오 시뮬레이션
  • Implement: 마이크로서비스 간 비동기 메시지 교환을 표현한 아키텍처 다이어그램

Core: 전송 보장과 장애 복구 (Delivery Semantics)

  • Why to Learn: 데이터의 중요도에 따라 성능과 신뢰성 사이의 최적의 지점을 선택하기 위해서입니다.
  • What to Learn:
    • At-most-once (최대 한 번): 성능 위주, 유실 가능
    • At-least-once (최소 한 번): 중복 가능, 유실 방지
    • Exactly-once (정확히 한 번): 트랜잭션 처리를 통한 무결성 보장 물리
  • How to Learn:
    • 소비자 프로세스를 강제로 종료했을 때, 메시지 ACK(Acknowledge) 처리 방식에 따라 메시지가 유실되거나 재발행되는 현상 실험
    • 멱등성(Idempotency) 소비자를 구현하여 중복 메시지 처리 로직 작성
  • Implement: 전송 보장 수준별 설정값과 그에 따른 성능 트레이드오프 비교표

Practical

Core: 이벤트 스트리밍과 카프카 물리 (Event Streaming)

  • Why to Learn: 대지능 실시간 데이터 처리와 데이터 통합 파이프라인의 핵심인 분산 로그 시스템을 다루기 위함입니다.
  • What to Learn:
    • 토픽(Topic) 파티셔닝과 병렬 처리 확장성 물리
    • 리더와 팔로워 리플리케이션을 통한 데이터 고가용성 보장
    • 오프셋(Offset) 관리와 소비자 그룹의 재조정(Rebalancing) 역학
  • How to Learn:
    • 카프카 클러스터 환경에서 특정 파티션의 리더 노드를 다운시키고 데이터가 정상적으로 전달되는지 확인
    • 컨슈머 그룹 내의 노드 수를 늘리거나 줄이며 파티션 할당의 변화 관측
  • Implement: 대규모 로그 처리를 위한 파티션 설계 및 컨슈머 전략 보고서

Advanced

Core: 스트림 처리 및 이벤트 소싱 (Advanced Streams)

  • Why to Learn: 흐르는 데이터 위에서 실시간으로 지식을 추출하고 시스템 상태를 이벤트로 관리하기 위해서입니다.
  • What to Learn:
    • 상태 저장 스트림 처리(Stateful Stream Processing)의 논리
    • 이벤트 소싱(Event Sourcing) 패턴: 상태가 아닌 사건의 기록을 진실의 근원으로 삼기
    • CQRS 패턴과의 연계 및 최종 일관성(Eventual Consistency) 처리 물리
  • How to Learn:
    • 이벤트의 순차적 발생을 기반으로 특정 시점의 시스템 상태를 복원(Replay)하는 프로토타입 구현
    • CDC(Change Data Capture)를 활용하여 DB 변경분을 실시간 스트림으로 변환하는 파이프라인 구축
  • Implement: 이벤트 소싱 기반의 주문 관리 시스템 엔티티 및 상태 전이도 설계

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
Decoupling (탈결합) 송신자가 수신자의 존재나 상태를 몰라도 메시지를 보낼 수 있게 시스템 간 의존성을 제거하는 물리적 상태입니다. 기본 설계 가치 Async Coupling 단순히 '분리'로 오해 P2:SWEBOK core
Partitioning (파티셔닝) 하나의 토픽을 여러 물리적 단위로 나누어 저장함으로써 병렬 처리를 가능하게 하는 확장성 기법입니다. 권장 확장성 Sharding Replication 단순히 '백업'으로 오해 Industry Docs core
Consumer Group 동일한 토픽을 나누어 처리하는 소비자들의 논리적 집합으로, 메시지 부하 분산의 단위입니다. 실무 부하 분산 Offset Consumer 개별 컨슈머와 혼동 Industry Standards core
Exactly-once 분산 환경에서 네트워크 오류나 재시도가 발생하더라도 메시지가 단 한 번만 처리됨을 보장하는 최고 수준의 신뢰성 물리입니다. 심화 전송 보장 Transaction At-least-once '한 번만 전송'으로 오해 Industry Semantics core

8. References

Primary References

Secondary References

  • [Designing Data-Intensive Applications] Martin Kleppmann — Best chapter on logs and messaging.
  • [Kafka: The Definitive Guide] Gwen Shapira — Industrial standard for streaming.

Industry References

  • [RabbitMQ: AMQP Protocol] — Messaging broker standard.
  • [Apache Kafka Documentation] — The architecture of distributed logs.

9. Final Checklist

Primary Checklist

  • 동기식 호출(RPC/REST)과 비동기식 메시징의 물리적 레이턴시 및 가용성 측면에서의 트레이드오프를 설명 가능한가? (P2)
  • 메시지 브로커가 일시적으로 다운되었을 때, 생산자의 데이터 유실을 방지하기 위한 물리적 전략(Buffer, Retry)을 제시할 수 있는는가? (P2)

Secondary Checklist

  • 큐에 쌓인 메시지가 처리 속도보다 빠르게 증가할 때(Backpressure), 시스템 전체의 안정성을 위한 조절 매커니즘을 이해하는가?
  • 토픽의 파티션 개수와 컨슈머 그룹의 인스턴스 개수 사이의 상관관계와 병목 발생 원인을 식별 가능한가?

Industry Checklist

  • 실무 서비스에서 결제 완료 이벤트를 처리할 때, '정확히 한 번' 처리를 위해 데이터베이스 트랜잭션과 메시지 오프셋 관리를 어떻게 연동할지 설계 가능한가? (SFIA)
  • 대용량 로그 수집 시스템 설계 시, RabbitMQ와 Kafka의 보관 방식(Delete on ACK vs Log Retention) 차이에 근거하여 적절한 도구를 선택할 수 있는가?

Concepts & Tags

#messaging-queue#event-streaming#pub-sub-pattern#message-delivery-guarantees