콘텐츠로 바로가기
HY_TECH_BASE

Event-Driven & Reactive Systems

상태 변화를 이벤트로 전파하는 비동기 통신 모델과 시스템 부하에 유연하게 대응하는 반응형 프로그래밍 역학을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

이벤트 기반 및 반응형 시스템(Event-Driven & Reactive Systems, ERS)은 명령 중심의 동기식 통신을 탈피하여, '무슨 일이 일어났음(Event)'을 알리고 이에 독립적으로 반응하는 느슨한 결합의 시스템을 설계하는 기술을 다룹니다.

현대 시스템은 실시간성과 대규모 비동기 처리를 요구합니다. 학습자는 이벤트 발행/구독(Pub-Sub) 모델의 물리적 구조, 시스템 간의 속도 차이를 완충하는 메시지 큐(Message Queue)의 역할, 그리고 역압(Backpressure) 조절을 통해 과부하 상황에서도 무너지지 않는 반응형 매니페스토의 원칙을 학습합니다. 이를 통해 실시간성이 보장되면서도 장애 탄력성이 뛰어난 '살아있는 시스템'을 구축합니다.

2. Scope & Boundaries

In-Scope

  • EDA Basics: Producer, Consumer, Event Channel의 물리 배치 및 상호작용
  • Asynchronous Patterns: Request-Response vs Fire-and-forget, 이벤트 소싱(Event Sourcing) 기초
  • Reactive Principles: 응답성(Responsive), 회복성(Resilient), 유연성(Elastic), 메시지 구동(Message Driven)
  • Message Semantics: At-least-once, At-most-once, Exactly-once 전달 물리와 중복 제거

Out-of-Scope

  • 구체적인 메시지 브로커(Kafka, RabbitMQ) 운영 상세 (08-04 Distributed Messaging 영역으로 위임)
  • 순수 GUI 이벤트 루프 처리 (12. HCI & Graphics 영역으로 위임)

Boundaries

  • ERS vs. Distributed Messaging: 08-04(DM)가 '메시지 이동 프로토콜과 브로커 인프라'에 주력한다면, ERS는 '이벤트를 통한 아키텍처 구성과 반응형 로직 설계 원론'에 집중합니다.

3. Counterexample

  • 단순히 비동기 함수(async/await)를 쓰는 것은 ERS 학습이 아닙니다. 여러 마이크로서비스 간에 이벤트가 꼬이거나 유실되었을 때 발생하는 분산 상태 불일치 문제를 해결하기 위해 어떻게 멱등(Idempotent) 처리를 설계하고, 소비자의 처리 속도가 생산자를 못 따라올 때 시스템 전체가 마비되는 현상을 방지하는 Backpressure 기법을 논할 수 있어야 합니다.

4. Prerequisites

  • 프로세스 및 동시성 매카니즘 (Basic): 스레드, 비차단 I/O(Non-blocking) 개념이 반응형 학습의 토대입니다. (03. PCM)
  • 기초 및 아키텍처 패턴 (Recommended): 관심사 분리와 결합도에 대한 아키텍처적 이해가 필요합니다. (07. FAP)

5. Learning Map

  1. Breaking Synchrony: 즉각적인 응답을 기다리지 않고 작업을 던지는 비동기 사고방식을 익힙니다.
  2. Buffering Life: 시스템 간의 충격을 완화하고 가용성을 높여주는 메시지 채널의 물리적 역할을 이해합니다.
  3. The Reactive Flow: 데이터의 흐름(Stream)을 제어하고 장애를 독립적으로 고립시키는 전파 논리를 배웁니다.
  4. Consistency through Events: 분산 환경에서 이벤트로 결국 데이터 정합성을 맞추는 고수준 패턴을 실습합니다.

6. Learning Topics

Basic

Core: 이벤트 기반 아키텍처와 Pub-Sub (EDA & Pub-Sub)

  • Why to Learn: 서비스 간의 직접적 의존성을 끊어 시스템의 변경과 확장을 자유롭게 하기 위함입니다.
  • What to Learn:
    • 이벤트(Event) vs 메시지(Message)의 물리적 속성 차이
    • 발행/구독(Publish-Subscribe) 모델: 토픽(Topic)과 구독자의 물리적 매핑
    • 시간적 제약(Temporal Coupling)의 해소 원리
  • How to Learn:
    • 동기식 API 호출 시스템을 메시지 큐를 둔 비동기 시스템으로 재설계하며 의존성 그래프의 변화 관측
    • 생산자가 메시지를 던지고 즉시 종료해도 소비자에게 전달되는 과정 실습
  • Implement: 이벤트 버스를 이용해 정보를 브로드캐스팅하는 단순 애플리케이션 아키텍처

Core: 반응형 프로그래밍과 역압 (Reactive & Backpressure)

  • Why to Learn: 데이터가 몰리는 상황에서도 시스템이 멈추지 않고 유연하게 대처하기 위해서입니다.
  • What to Learn:
    • 리액티브 매니페스토(The Reactive Manifesto)의 4대 원칙
    • 옵저버(Observer) 패턴의 확장과 데이터 스트림(Stream) 처리 물리
    • 역압(Backpressure): 소비자의 한계를 생산자에게 알리는 신호 메커니즘
  • How to Learn:
    • 처리량을 초과하는 데이터를 보냈을 때 메모리 부족(OOM)이 발생하는 상황을 역압 설정을 통해 해결하는 실습
    • RxJS나 Project Reactor와 같은 라이브러리의 핵심 연산자(Filter, Map, Zip) 동작 물리 분석
  • Implement: 역압 조절 기능이 포함된 실시간 데이터 스트리밍 처리 파이프라인

Practical

Core: 이벤트 소싱과 CQRS 기초 (Event Sourcing & CQRS)

  • Why to Learn: 데이터의 최종 상태뿐만 아니라 '어떻게 그 상태가 되었는지' 모든 이력을 물리적으로 보존하기 위함입니다.
  • What to Learn:
    • Event Sourcing: 현재 상태를 저장하는 대신 '이벤트 로그'를 저장하고 재생(Replay)하는 물리
    • CQRS (Command Query Responsibility Segregation): 명령과 조회의 저장소 분리
    • 스냅샷(Snapshot)을 통한 이벤트 재생 성능 최적화
  • How to Learn:
    • 은행 계좌 시스템을 잔액 저장이 아닌 '입출력 이벤트 로그' 저장 방식으로 설계해보기
    • 쓰기 전용 DB와 읽기 전용 DB를 분리했을 때 발생하는 데이터 가시성 지연(Replication Lag) 영향 분석
  • Implement: 이벤트 로그를 재생하여 특정 시점의 객체 상태를 복원하는 시뮬레이터

Advanced

Core: 분산 이벤트 정합성 및 가용성 (Advanced Event Logic)

  • Why to Learn: 수천 개의 이벤트가 쏟아지는 환경에서 데이터 유실이나 중복 처리를 완벽하게 막기 위해서입니다.
  • What to Learn:
    • 정교한 전달 보장: At-least-once와 Exactly-once의 물리적 구현 차이
    • 사가(Saga) 패턴 기획: 오케스트레이션을 통한 비동기 트랜잭션 흐름 제어
    • 이벤트 스키마 진화(Schema Evolution): 버전 관리를 통한 하위 호환성 유지 물리
  • How to Learn:
    • 강제로 메시지를 중복 발송하고 수신 측에서 '중복 처리 방지(Deduplication)' 로직이 작동하는지 검증
    • 비즈니스 프로세스(예: 주문-결제-배송)를 사가 패턴으로 모델링하고 실패 시나리오(보상 이벤트) 연습
  • Implement: 정확히 한 번(Exactly-once) 처리를 보장하는 분산 이벤트 결제 처리 아키텍처

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core/misused/legacy)
Asynchronous (비동기) 요청을 보낸 후 응답을 기다리지 않고 다른 다음 작업을 계속 수행하는 제어 방식입니다. 기본 제어 흐름 Non-blocking Synchronous '멀티 스레드'와 혼동함 P1:CS2023/Parallel core
Backpressure (역압) 수신측의 처리 용량을 초과하는 데이터가 들어오지 못하도록 상류(Upstream)를 제너하는 신호 전달 기법입니다. 추천 안정성 관리 Flow Control Throttle / Debounce 단순히 '데이터 삭제'로 오해 Industry Streams core
Pub-Sub 메시지를 보낸 자가 수신자를 특정하지 않고 '채널'에 게시하며, 관심 있는 이만 수신하는 구조입니다. 기본 통신 패턴 Topic / Channel Request-Response '1<1> 통신' 전용으로 오해 P1:CS2023/Distributed core
Event Sourcing 상태의 변경 사항 자체를 이벤트 스트림으로 영구 저장하여 상태를 도출해내는 방식입니다. 실무 이력 관리 CQRS / Replay CRUD DB 단순히 '로그 남기기'로 오해 Industry Fowler core

8. References

Primary References

Secondary References

  • [Enterprise Integration Patterns] Gregor Hohpe — The definitive guide to messaging.
  • [Reactive Design Patterns] Roland Kuhn — Practical reactive structures.

Industry References

  • [The Reactive Manifesto] — Foundational principles of modern reactive web.
  • [Confluent: Event Driven Architecture Guide] — Industrial scale event patterns.

9. Final Checklist

Primary Checklist

  • 동기식(Sync) 호출 방식이 서비스 간의 연쇄 장애(Cascading Failure)를 물리적으로 어떻게 유발하는지 설명 가능한가? (P1, P5)
  • '이벤트'가 발생했다는 사실만으로 어떻게 서로 다른 데이터베이스의 정합성을 결국 맞추게(Eventual Consistency) 되는지 논리를 기술할 수 있는가? (P1)

Secondary Checklist

  • 소비자의 처리 속도가 느려질 때 메시지 큐의 점유량이 시스템 메모리에 미치는 물리적 임팩트를 예측하고 있는가?
  • 멱등(Idempotent) 설계가 부재한 시스템에서 네트워크 재시도(Retry)가 발생했을 때 데이터가 중복 생성되는 시나리오를 식별 가능한가?

Industry Checklist

  • 실무 마이크로서비스 설계 시, 비즈니스 트랜잭션의 신뢰성을 위해 '아웃박스 패턴(Outbox Pattern)'의 필요성을 제안할 수 있는가? (SFIA)
  • 고성능 실시간 대시보드 구축을 위해 폴링(Polling) 대신 리액티브 스트림을 선택해야 하는 물리적 비용 근거를 제시 가능한가?

Concepts & Tags

#event-driven-architecture#reactive-programming#pub-sub#message-queues