Event-Driven Architecture(EDA) — 개요
Source: Dev.to
위에 제공된 소스 링크만으로는 번역할 본문이 포함되어 있지 않습니다. 번역이 필요한 텍스트(본문)를 알려주시면 한국어로 번역해 드리겠습니다.
Source: …
Event‑Driven Architecture (EDA)란?
Event‑Driven Architecture는 확장 가능한 시스템으로, 분산 환경에서 사용자 활동을 실시간으로 처리하도록 설계되었습니다. 이는 이벤트를 사용하여 구성 요소들을 분리하는 소프트웨어 설계 패턴으로, 확장성, 모듈성 및 응답성을 향상시킵니다.
아키텍처 스타일
이벤트‑드리븐 아키텍처는 일반적으로 다음을 사용합니다:
- Publish‑Subscribe 모델
- Event‑Streaming 모델
시스템은 이벤트 브로커를 통해 비동기적으로 통신합니다. 애플리케이션은 이벤트가 어디에서 게시되거나 소비되는지 알 필요가 없습니다. 이벤트는 상태 변화 또는 사용자 행동(예: 주문이 접수됨, 사용자가 회원 가입함)을 나타냅니다.
주요 구성 요소
| 구성 요소 | 설명 |
|---|---|
| 이벤트 프로듀서 | 데이터를 생성하고 퍼블리시(발행)합니다. 구독자가 누군지, 데이터가 어떻게 처리될지 알지 못하므로, 소비자에 의해 차단되지 않고 고볼륨을 처리할 수 있습니다. |
| 이벤트 브로커 | 프로듀서와 소비자 사이의 미들웨어입니다. 이벤트를 수신, 저장, 라우팅합니다(주제, 큐, 필터 기반). 퍼블리시‑서브스크라이브 및 포인트‑투‑포인트와 같은 전달 모델을 지원하고, 내구성(재시도, 영속성, 데드레터 큐)을 보장하며 수평 확장이 가능합니다. 예시: Apache Kafka, RabbitMQ, AWS EventBridge. |
| 이벤트 컨슈머 | 브로커를 통해 이벤트에 구독하고 비동기적으로 처리합니다. 각 컨슈머는 특정 이벤트 유형을 처리하며, 프로듀서를 알지 못합니다. 여러 컨슈머 인스턴스가 이벤트를 병렬로 처리할 수 있습니다. |
커뮤니케이션 모델
퍼블리시‑서브스크라이브 모델
- 생산자는 소비자를 알지 못한 채 이벤트를 발행합니다.
- 소비자는 자신이 관심 있는 이벤트를 구독합니다.
- 생산자와 소비자는 독립적으로 동작하여 느슨한 결합을 구현합니다.
이벤트‑스트리밍 모델
- 이벤트 데이터는 지속적으로 생성되며 실시간으로 처리됩니다.
- 이벤트는 레코드 스트림을 형성하며, 생성되는 즉시 처리, 저장 및 분석됩니다.
- 실시간 분석 및 모니터링이 필요한 애플리케이션에 이상적입니다.
이벤트‑드리븐 아키텍처를 사용할 때
- 사용자 행동에 대한 즉각적인 응답이 필요합니다.
- 시스템은 고량의 이벤트를 성능 저하 없이 처리해야 합니다.
- 독립적으로 업데이트하거나 추가할 수 있는 분리된 서비스가 필요합니다.
- 트래픽 급증이나 일시적인 장애 상황에서도 애플리케이션이 신뢰성 있고 유연하게 유지되어야 합니다.
장점
- 향상된 확장성 및 신뢰성
- 더 빠른 응답성
- 시간에 따라 시스템의 진화가 더 간단해짐
시스템이 실시간으로 반응하고, 무거운 트래픽을 원활히 처리하며, 기존 기능을 깨뜨리지 않고 진화해야 한다면, EDA가 강력한 선택이 됩니다.
Use‑Case: 온라인 음식‑배달 플랫폼 (예: UberEats)
음식‑배달 앱에서는 고객, 레스토랑, 드라이버 모두 실시간 업데이트가 필요합니다. 이벤트‑드리븐 설계를 사용하면 각 구성 요소가 독립적으로 동작하면서도 동기화를 유지할 수 있습니다.
주요 구성 요소 및 이벤트 흐름
| 서비스 | 역할 | 발행 / 구독 이벤트 |
|---|---|---|
| Order Service | 고객 주문을 수신합니다. | OrderPlaced 를 발행 (고객, 결제, 주문 상세 정보 포함). |
| Restaurant Service | 주문 준비를 담당합니다. | OrderPlaced 를 구독하고, 음식이 준비되면 OrderReady 를 발행합니다. |
| Payment Service | 결제를 처리합니다. | OrderPlaced 를 구독하고, 결제가 성공하면 PaymentSuccessful 를 발행합니다. |
| Delivery Service | 드라이버 할당 및 배달 추적을 관리합니다. | PaymentSuccessful 를 구독하고 DriverAssigned 를 발행; 또한 OrderReady 를 구독하고 OrderOutForDelivery 를 발행합니다. |
| Notification Service | 사용자에게 푸시/이메일/SMS 알림을 보냅니다. | OrderPlaced, OrderReady, DriverAssigned, OrderOutForDelivery 등과 같은 이벤트를 구독하고 관련 당사자에게 알립니다. |
Notification Service
이 서비스는 모든 이벤트 OrderPlaced, PaymentSuccessful, DriverAssigned, OrderReady, 및 OrderOutForDelivery 를 수신하고 주문에 대한 실시간 업데이트를 고객에게 전송합니다.
Tracking Service
실시간 추적에 사용됩니다. 모든 이벤트를 캡처하고 관련 정보를 Notification Service로 전달합니다.
도전 과제
디버깅 및 모니터링
비동기 통신은 데이터 흐름을 추적하기 어렵게 만들어 테스트와 디버깅을 복잡하게 합니다.
일관성
이벤트가 순서대로 도착하지 않을 수 있어, 적절히 처리하지 않으면 서비스 간 일관성 문제가 발생합니다.
중복
네트워크 문제나 재시도로 인해 동일한 이벤트가 여러 번 수신될 수 있으며, 애플리케이션은 중복을 정상적으로 처리해야 합니다.
운영 오버헤드
브로커(Kafka, RabbitMQ, AWS EventBridge 등)를 설정하고 유지 관리하는 것은 운영 복잡성을 증가시킵니다. 부적절한 스케일링은 성능 저하와 비용 증가를 초래할 수 있습니다.
오류 처리
비동기 오류는 다른 서비스에 영향을 주지 않도록 관리해야 하며, 강력한 재시도 또는 보상 메커니즘이 필요합니다.
보안 및 접근 제어
이벤트에는 종종 민감한 데이터(결제 정보, 개인 식별 정보)가 포함됩니다. 무단 소비를 방지하려면 적절한 인증 및 인가가 필수적입니다.
이벤트 손실
실패, 네트워크 문제 또는 구성 오류로 인해 이벤트가 손실될 수 있습니다. 이 위험을 완화하려면 신뢰할 수 있는 전달 보장과 모니터링이 필요합니다.