Event-Driven Architecture (EDA)

📌 Brief Summary

**이벤트 주도 아키텍처(Event-Driven Architecture, EDA)**는 시스템의 상태 변화(Event)를 감지하고, 이를 비동기적으로 전파하여 관련 컴포넌트들이 반응하게 만드는 설계 방식입니다. 서비스 간의 직접적인 호출(Request-Response) 대신 메시지 브로커를 통한 발행-구독(Publish-Subscribe) 모델을 사용함으로써, 시스템 간의 결합도를 낮추고 대규모 트래픽 처리에 적합한 탄력성과 확장성을 확보합니다.

📖 Core Content

1. 핵심 메커니즘: 비동기 통신

이벤트 생산자(Producer): 상태 변화가 발생하면 이벤트를 생성하여 메시지 브로커에 발행합니다. 누가 이 이벤트를 받을지 알 필요가 없습니다.
메시지 브로커(Message Broker): 발행된 이벤트를 저장하고 관심 있는 소비자에게 라우팅합니다. (예: Apache Kafka, RabbitMQ, AWS EventBridge)
이벤트 소비자(Consumer): 자신에게 필요한 이벤트를 구독하여 비즈니스 로직을 수행합니다. 생산자의 상태나 위치를 알 필요가 없습니다.

2. 주요 설계 패턴

발행-구독 (Pub-Sub): 일대다 통신으로, 하나의 이벤트가 여러 소비자에게 전달됩니다.
이벤트 소싱 (Event Sourcing): 시스템의 현재 상태를 저장하는 대신, 발생한 모든 이벤트를 순서대로 저장하여 상태를 재구성합니다.
CQRS: 명령(상태 변경)과 조회(상태 반환)를 분리하고, 비동기 이벤트를 통해 두 모델 간의 동기화를 수행합니다.

3. 실전 고려 사항

멱등성 (Idempotency): 동일한 이벤트가 중복 전달되더라도 결과가 같아야 합니다.
순서 보장 (Ordering): 이벤트가 발생한 순서대로 처리되어야 하는 경우, 브로커의 파티셔닝 전략이 중요합니다.
최종 일관성 (Eventual Consistency): 분산 시스템 특성상 데이터가 즉시 일치하지 않을 수 있음을 전제로 설계합니다.

⚖️ Trade-offs & Caveats

✅ Benefits

느슨한 결합 (Loose Coupling): 서비스 간 의존성이 제거되어 독립적인 배포와 확장이 가능합니다.
높은 확장성: 소비자(Worker)를 늘려 처리량을 쉽게 조절할 수 있습니다.
내결함성: 특정 소비자가 다운되더라도 브로커가 메시지를 보관하므로 데이터 유실을 방지할 수 있습니다.

⚠️ Challenges

디버깅 및 추적: 분산된 비동기 흐름으로 인해 장애 발생 시 전체 실행 경로를 추적하기 어렵습니다.
운영 복잡성: 메시지 브로커 인프라 관리에 추가 비용과 전문 지식이 필요합니다.
데이터 정합성: 분산 트랜잭션 구현이 까다로우며, 최종 일관성 모델에 대한 이해가 필수적입니다.

🔗 Knowledge Connections

Microservices_Architecture: 마이크로서비스 간의 통신을 최적화하는 핵심 패턴입니다.
Message_Broker: EDA를 가능하게 하는 인프라스트럭처 도구입니다.
Saga_Pattern: 분산 시스템에서 여러 서비스에 걸친 트랜잭션을 이벤트로 관리하는 방식입니다.
Dead_Letter_Queue: 처리 실패한 이벤트를 격리하여 관리하는 메커니즘입니다.

Practical Application Contexts

Real-time Processing: 주식 거래, IoT 센서 데이터 등 즉각적인 반응이 필요한 시스템에 활용됩니다.
Complex Workflows: 전자상거래 주문-결제-배송으로 이어지는 긴 프로세스를 비동기로 처리합니다.

💡 Adjacent Topics

Domain_Driven_Design: 도메인 이벤트를 식별하여 EDA 설계의 기반으로 삼습니다.
Cloud_Native_Architecture: 클라우드 환경에서 서버리스(Lambda)와 결합하여 효율적인 확장을 구현합니다.
CQRS: 상태 변경과 조회를 분리하는 아키텍처와 시너지를 냅니다.

Last updated: 2026-05-02

4.4 KiB Raw Blame History