reinforce:wikify - Batch 11: Modern Architecture Patterns (5 artifacts)
This commit is contained in:
Antigravity Agent
@@ -4,11 +4,11 @@ title: "이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)"
|
||||
category: "10_Wiki/🏗️ Topics_Arch"
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["EDA", "이벤트 기반 설계", "비동기 메시징"]
|
||||
aliases: ["EDA", "이벤트 주도 설계", "비동기 메시징", "메시지 기반 아키텍처"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Loose_Coupling"]
|
||||
tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Scalability"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
@@ -17,29 +17,30 @@ github_commit: ""
|
||||
# [[이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)]]
|
||||
|
||||
## 1. 개요
|
||||
Event-Driven Architecture (EDA)는 시스템 컴포넌트 간의 통신을 '이벤트(Event)'의 발행과 소비를 통해 비동기적으로 수행하는 아키텍처 패러다임이다. 직접적인 함수 호출 대신 상태 변화나 사건 발생을 알리는 메시지를 주고받음으로써 시스템 간의 느슨한 결합(Loose Coupling)을 실현한다.
|
||||
이벤트 기반 아키텍처(EDA)는 시스템의 상태 변화를 '이벤트(Event)'라는 메시지로 표현하고, 이를 비동기적으로 주고받으며 상호작용하는 아키텍처 스타일이다. 생산자(Producer)와 소비자(Consumer)가 서로의 존재를 직접 알 필요가 없는 느슨한 결합(Loose Coupling)을 통해 고도로 확장 가능하고 탄력적인 시스템을 구축할 수 있다.
|
||||
|
||||
## 2. 핵심 구성 요소
|
||||
- **이벤트 생산자 (Producer)**: 특정 사건 발생 시 이벤트를 생성하여 브로커에 발행.
|
||||
- **이벤트 브로커 (Broker)**: 발행된 이벤트를 수신하여 관심 있는 소비자에게 라우팅 (예: Kafka, RabbitMQ).
|
||||
- **이벤트 소비자 (Consumer)**: 수신한 이벤트에 반응하여 비즈니스 로직을 실행.
|
||||
- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리 실패한 이벤트를 격리하여 사후 분석 및 재처리를 지원.
|
||||
- **이벤트 생산자 (Event Producers)**: 상태 변화를 감지하고 이벤트를 생성하여 발행하는 주체.
|
||||
- **이벤트 브로커 (Event Broker)**: 생산자와 소비자 사이에서 이벤트를 수집, 저장, 라우팅하는 중계 인프라 (예: Kafka, RabbitMQ).
|
||||
- **이벤트 소비자 (Event Consumers)**: 브로커를 구독(Subscribe)하고 있다가 특정 이벤트가 발생하면 비즈니스 로직을 실행하는 주체.
|
||||
- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리에 실패한 이벤트를 격리하여 분석 및 재처리를 가능하게 하는 보관소.
|
||||
|
||||
## 3. 실전 설계 원칙
|
||||
- **멱등성 (Idempotency) 보장**: 동일한 이벤트가 중복 처리되어도 시스템 상태가 일관되게 유지되도록 소비자 로직 설계 필수.
|
||||
- **비동기 오케스트레이션**: 마이크로서비스 간의 복잡한 워크플로우를 직접 호출 없이 이벤트 흐름으로 조정.
|
||||
- **장애 격리**: 특정 서비스의 장애가 전체 시스템으로 전파되지 않도록 브로커를 통한 완충 지대 형성.
|
||||
## 3. 실전 적용 가치
|
||||
- **유연한 확장성**: 특정 소비자의 처리 성능이 부족할 경우, 생산자나 다른 소비자에게 영향을 주지 않고 해당 소비자만 수평 확장(Scale-out) 가능.
|
||||
- **실시간 반응성**: 주식 가격 변동, 결제 완료 알림, IoT 센서 데이터 처리 등 즉각적인 반응이 필요한 도메인에 최적화.
|
||||
- **시스템 복원력**: 특정 컴포넌트가 일시적으로 중단되어도 이벤트 브로커에 메시지가 보관되므로 시스템 전체의 데이터 유실 방지.
|
||||
|
||||
## 4. 트레이드오프
|
||||
- **장점**: 높은 확장성, 유연한 시스템 변경, 실시간 데이터 처리 능력.
|
||||
- **단점**: 시스템 복잡도 증가, 분산 추적(Distributed Tracing)의 어려움, 결과적 일관성(Eventual Consistency) 관리 비용.
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **운영 복잡도**: 분산 시스템 특유의 트랜잭션 관리(Saga 패턴 등), 이벤트 순서 보장, 메시지 유실 방지 등을 위한 고도의 운영 역량 필요.
|
||||
- **멱등성 (Idempotency) 보장**: 네트워크 장애나 재시도로 인해 동일한 이벤트가 여러 번 전달될 수 있으므로, 소비자는 중복 처리에 대한 방어 로직을 반드시 갖춰야 함.
|
||||
- **디버깅 및 추적의 어려움**: 직접적인 호출 스택이 존재하지 않으므로 분산 추적(Distributed Tracing) 도구 없이는 문제 발생 시 원인 파악이 힘듦.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Microservices_Architecture]]: EDA가 가장 활발하게 적용되는 시스템 구조.
|
||||
- [[Domain_Driven_Design]]: 도메인 이벤트(Domain Events)를 도출하여 EDA 설계를 이끄는 방법론.
|
||||
- [[Message_Broker_Selection]]: 시스템 특성에 맞는 브로커(Kafka vs RabbitMQ) 선택 전략.
|
||||
- [[Microservices_Architecture]]: EDA가 서비스 간 통신을 위해 가장 흔히 채택되는 아키텍처 환경.
|
||||
- [[CQRS_Pattern]]: 상태 변경 후 조회 모델을 업데이트하기 위해 EDA가 핵심 통신 수단으로 사용됨.
|
||||
- [[Event_Storming]]: EDA의 핵심인 도메인 이벤트를 도출하기 위한 설계 기법.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 현대적 분산 시스템의 탄력성과 확장성을 위한 핵심 아키텍처 패턴 정립.
|
||||
- **검토 이유**: 비동기 워크플로우와 고가용성 시스템 구축을 위한 현대적 분산 아키텍처의 핵심 패러다임 정립.
|
||||
|
||||
Reference in New Issue
Block a user