Fix: Restore unified Topics folder and reorganize specialized category folders
This commit is contained in:
Antigravity Agent
@@ -1,46 +1,69 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-EDA
|
||||
title: "이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["EDA", "이벤트 주도 설계", "비동기 메시징", "메시지 기반 아키텍처"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Scalability"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Messaging, Microservices, Async]
|
||||
title: Event-Driven Architecture (EDA)
|
||||
description: 시스템 컴포넌트 간의 비동기적 이벤트를 통해 느슨한 결합과 높은 확장성을 구현하는 아키텍처 패러다임
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)]]
|
||||
# Event-Driven Architecture (EDA)
|
||||
|
||||
## 1. 개요
|
||||
이벤트 기반 아키텍처(EDA)는 시스템의 상태 변화를 '이벤트(Event)'라는 메시지로 표현하고, 이를 비동기적으로 주고받으며 상호작용하는 아키텍처 스타일이다. 생산자(Producer)와 소비자(Consumer)가 서로의 존재를 직접 알 필요가 없는 느슨한 결합(Loose Coupling)을 통해 고도로 확장 가능하고 탄력적인 시스템을 구축할 수 있다.
|
||||
## 📌 Brief Summary
|
||||
**이벤트 주도 아키텍처(Event-Driven Architecture, EDA)**는 시스템의 상태 변화(Event)를 감지하고, 이를 비동기적으로 전파하여 관련 컴포넌트들이 반응하게 만드는 설계 방식입니다. 서비스 간의 직접적인 호출(Request-Response) 대신 메시지 브로커를 통한 **발행-구독(Publish-Subscribe)** 모델을 사용함으로써, 시스템 간의 결합도를 낮추고 대규모 트래픽 처리에 적합한 탄력성과 확장성을 확보합니다.
|
||||
|
||||
## 2. 핵심 구성 요소
|
||||
- **이벤트 생산자 (Event Producers)**: 상태 변화를 감지하고 이벤트를 생성하여 발행하는 주체.
|
||||
- **이벤트 브로커 (Event Broker)**: 생산자와 소비자 사이에서 이벤트를 수집, 저장, 라우팅하는 중계 인프라 (예: Kafka, RabbitMQ).
|
||||
- **이벤트 소비자 (Event Consumers)**: 브로커를 구독(Subscribe)하고 있다가 특정 이벤트가 발생하면 비즈니스 로직을 실행하는 주체.
|
||||
- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리에 실패한 이벤트를 격리하여 분석 및 재처리를 가능하게 하는 보관소.
|
||||
---
|
||||
|
||||
## 3. 실전 적용 가치
|
||||
- **유연한 확장성**: 특정 소비자의 처리 성능이 부족할 경우, 생산자나 다른 소비자에게 영향을 주지 않고 해당 소비자만 수평 확장(Scale-out) 가능.
|
||||
- **실시간 반응성**: 주식 가격 변동, 결제 완료 알림, IoT 센서 데이터 처리 등 즉각적인 반응이 필요한 도메인에 최적화.
|
||||
- **시스템 복원력**: 특정 컴포넌트가 일시적으로 중단되어도 이벤트 브로커에 메시지가 보관되므로 시스템 전체의 데이터 유실 방지.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **운영 복잡도**: 분산 시스템 특유의 트랜잭션 관리(Saga 패턴 등), 이벤트 순서 보장, 메시지 유실 방지 등을 위한 고도의 운영 역량 필요.
|
||||
- **멱등성 (Idempotency) 보장**: 네트워크 장애나 재시도로 인해 동일한 이벤트가 여러 번 전달될 수 있으므로, 소비자는 중복 처리에 대한 방어 로직을 반드시 갖춰야 함.
|
||||
- **디버깅 및 추적의 어려움**: 직접적인 호출 스택이 존재하지 않으므로 분산 추적(Distributed Tracing) 도구 없이는 문제 발생 시 원인 파악이 힘듦.
|
||||
### 1. 핵심 메커니즘: 비동기 통신
|
||||
* **이벤트 생산자(Producer):** 상태 변화가 발생하면 이벤트를 생성하여 메시지 브로커에 발행합니다. 누가 이 이벤트를 받을지 알 필요가 없습니다.
|
||||
* **메시지 브로커(Message Broker):** 발행된 이벤트를 저장하고 관심 있는 소비자에게 라우팅합니다. (예: Apache Kafka, RabbitMQ, AWS EventBridge)
|
||||
* **이벤트 소비자(Consumer):** 자신에게 필요한 이벤트를 구독하여 비즈니스 로직을 수행합니다. 생산자의 상태나 위치를 알 필요가 없습니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Microservices_Architecture]]: EDA가 서비스 간 통신을 위해 가장 흔히 채택되는 아키텍처 환경.
|
||||
- [[CQRS_Pattern]]: 상태 변경 후 조회 모델을 업데이트하기 위해 EDA가 핵심 통신 수단으로 사용됨.
|
||||
- [[Event_Storming]]: EDA의 핵심인 도메인 이벤트를 도출하기 위한 설계 기법.
|
||||
### 2. 주요 설계 패턴
|
||||
* **발행-구독 (Pub-Sub):** 일대다 통신으로, 하나의 이벤트가 여러 소비자에게 전달됩니다.
|
||||
* **이벤트 소싱 (Event Sourcing):** 시스템의 현재 상태를 저장하는 대신, 발생한 모든 이벤트를 순서대로 저장하여 상태를 재구성합니다.
|
||||
* **CQRS:** 명령(상태 변경)과 조회(상태 반환)를 분리하고, 비동기 이벤트를 통해 두 모델 간의 동기화를 수행합니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 비동기 워크플로우와 고가용성 시스템 구축을 위한 현대적 분산 아키텍처의 핵심 패러다임 정립.
|
||||
### 3. 실전 고려 사항
|
||||
* **멱등성 (Idempotency):** 동일한 이벤트가 중복 전달되더라도 결과가 같아야 합니다.
|
||||
* **순서 보장 (Ordering):** 이벤트가 발생한 순서대로 처리되어야 하는 경우, 브로커의 파티셔닝 전략이 중요합니다.
|
||||
* **최종 일관성 (Eventual Consistency):** 분산 시스템 특성상 데이터가 즉시 일치하지 않을 수 있음을 전제로 설계합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **느슨한 결합 (Loose Coupling):** 서비스 간 의존성이 제거되어 독립적인 배포와 확장이 가능합니다.
|
||||
* **높은 확장성:** 소비자(Worker)를 늘려 처리량을 쉽게 조절할 수 있습니다.
|
||||
* **내결함성:** 특정 소비자가 다운되더라도 브로커가 메시지를 보관하므로 데이터 유실을 방지할 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **디버깅 및 추적:** 분산된 비동기 흐름으로 인해 장애 발생 시 전체 실행 경로를 추적하기 어렵습니다.
|
||||
* **운영 복잡성:** 메시지 브로커 인프라 관리에 추가 비용과 전문 지식이 필요합니다.
|
||||
* **데이터 정합성:** 분산 트랜잭션 구현이 까다로우며, 최종 일관성 모델에 대한 이해가 필수적입니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[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*
|
||||
|
||||
Reference in New Issue
Block a user