예를 들어, 모두가 자신의 일을 하고 있는 큰 파티를 생각해보세요. 서로를 계속 확인하는 대신, 그들은 "케이크가 준비됐어" 또는 "댄스 파티가 시작돼"와 같은 중요한 것들을 알리기 위해 종을 사용합니다. 그 종은 Event-Driven Architecture의 "이벤트"와 같습니다. 기술 세계에서는 컴퓨터 시스템의 다양한 부분이 중요한 일이 발생할 때 메시지를 보내서 통신합니다. 각 부분은 자신의 일에 집중할 수 있으며, 주의가 필요할 때 종을 울립니다(이벤트를 보냅니다).
System Design에서 Event-Driven Architecture(EDA)의 중요성
Event-Driven Architecture (EDA)는 여러 가지 이유로 시스템 설계에서 상당한 중요성을 가집니다:
유연성과 반응성: EDA 덕분에 시스템은 변화하는 상황에 빠르게 적응할 수 있습니다. 시스템은 이벤트를 기반으로 작업을 시작하여 새로운 정보에 동적으로 적응할 수 있으므로 민첩성과 반응성을 보장합니다.
확장성: EDA는 확장 가능하므로 현재 구성에 영향을 주지 않고 컴포넌트를 추가하거나 제거할 수 있습니다. 유연성 때문에 변화하는 요구 사항에 대응하여 시스템을 수정하기가 더 쉽습니다.
실시간 처리: EDA는 실시간 처리가 필요한 시나리오에 이상적입니다. 이벤트는 발생할 때 처리되므로 시스템이 시간에 민감한 작업을 효율적으로 관리할 수 있습니다.
분산 통신: 컴포넌트는 직접 연결이 아닌 이벤트를 통해 통신하므로 지점 간 상호작용의 필요성이 줄어듭니다. 이 분산 접근 방식은 신뢰성을 향상시키고 시스템 유지보수를 단순화합니다.
Event-Driven Architecture의 예
아래는 전자상거래 사이트의 Event-Driven Architecture 예시입니다. 이 아키텍처는 수요가 많은 기간에 웹사이트가 여러 소스의 변화에 응답할 수 있게 하면서도 애플리케이션이 충돌하지 않도록 합니다.
event-driven-architecture-of-e-commerce-site
전자상거래 사이트의 Event-Driven Architecture
Event-Driven Architecture(EDA)의 이벤트
이벤트는 중요한 이벤트나 시스템 수정을 나타내는 Event-Driven Architecture (EDA)의 중요한 구성 요소입니다. 이들은 컴포넌트 간의 통신을 촉진하여 실시간 반응을 제공합니다. 다음은 EDA의 이벤트에 대한 주요 포인트입니다:
표현: 이벤트는 특정 정보를 전달하는 메시지 또는 신호로 표현됩니다.
트리거: 사용자 작업이나 데이터 변경과 같은 다양한 소스가 이벤트를 트리거할 수 있습니다.
비동기성: EDA는 종종 비동기 통신을 사용하여 컴포넌트가 독립적으로 병렬로 작동할 수 있도록 합니다.
Publish-Subscribe 모델: Publish-Subscribe 모델을 사용하여 이벤트를 관리하며, 이벤트를 생성하는 사람들이 이를 발행하고 관심 있는 당사자들이 이를 구독합니다.
이벤트 유형: 이벤트는 목적에 따라 "UserLoggedIn" 또는 "OrderPlaced"와 같이 그룹화됩니다.
페이로드: 이벤트는 종종 컨텍스트를 제공하는 추가 정보 또는 페이로드를 포함합니다(예: "PaymentReceived" 이벤트는 결제 금액을 상세히 설명할 수 있습니다).
이벤트 처리: 컴포넌트는 이벤트에 대한 응답 방식을 지정하는 특정 핸들러를 가집니다.
실시간 처리: 이벤트는 변화에 대한 즉각적인 반응을 가능하게 하므로 EDA는 빠른 반응성이 필요한 시나리오에 이상적입니다.
Event-Driven Architecture(EDA)의 컴포넌트
Event-Driven Architecture (EDA)는 통신을 촉진하고 이벤트에 응답하는 데 도움이 되는 여러 핵심 요소를 가지고 있습니다. 다음은 Event-Driven Architecture의 주요 컴포넌트입니다:
Event Source
이는 이벤트를 생성하는 모든 시스템 또는 컴포넌트를 의미합니다. 예시로는 사용자 인터페이스, 센서, 데이터베이스 및 외부 시스템이 있습니다.
Event Source는 전체 아키텍처를 주도하는 정보 흐름을 시작하므로 중요합니다.
Event
EDA의 핵심 통신 단위로, 중요한 발생 사항이나 상태 변화를 나타냅니다.
이벤트는 소스에서 발행되며 다양한 유형의 정보를 캡슐화할 수 있으며, 다양한 컴포넌트가 통신하는 주요 수단으로 작용합니다.
Event Broker/Event Bus
중앙 허브로 작동하며, Event Broker 또는 Event Bus는 이벤트 배포, 필터링 및 라우팅을 처리하여 다양한 컴포넌트 간의 통신을 촉진합니다. 이벤트가 올바른 구독자에게 도달하도록 보장하여 시스템 내에서 효율적인 상호작용을 촉진합니다.
Publisher
이 컴포넌트는 이벤트를 생성하고 Event Bus로 보냅니다.
Publisher는 특정 조건이나 작업이 발생할 때 이벤트를 발행하는 책임이 있으며, 시스템의 변화를 응답을 트리거할 수 있는 실행 가능한 메시지로 효과적으로 변환합니다.
Subscriber
특정 이벤트 유형에 관심을 보이고 이를 구독하는 컴포넌트입니다. Subscriber는 Event Bus에서 관련 이벤트를 수신하고 그에 따라 조치를 취합니다.
이를 통해 컴포넌트가 변화에 동적으로 반응하는 반응형 아키텍처가 가능합니다.
Event Handler
이는 Subscriber에 연결된 코드 또는 로직으로, 수신된 이벤트를 처리하는 방법을 정의합니다.
Event Handler는 이벤트에 대응하여 취해야 할 정확한 단계를 결정하므로 시스템의 반응성에 필수적입니다.
Dispatcher
일부 EDA 구현에서는 Dispatcher를 사용하여 이벤트를 적절한 Event Handler로 라우팅합니다.
이 부분은 이벤트가 시스템을 통해 어떻게 이동하는지를 제어하여 처리를 위해 적절한 위치로 라우팅되도록 합니다.
Aggregator
Aggregator는 여러 관련 이벤트를 결합하여 더 중요한 단일 이벤트를 만듭니다.
이는 많은 개별 이벤트의 관리를 단순화하여 복잡성을 줄이고 Subscriber가 관련 정보를 더 쉽게 처리할 수 있도록 합니다.
Listener
Event Bus를 적극적으로 모니터링하고 이벤트에 반응하는 컴포넌트입니다.
Listener는 종종 특정 이벤트 유형에 맞춤화되어 자신의 기능과 관련된 변화에 신속하게 응답하도록 합니다.
Event-Driven Architecture를 사용할 때
Event-Driven Architecture (EDA)는 여러 시나리오에서 훌륭한 선택입니다. 다음은 이를 사용하는 것을 고려할 수 있는 몇 가지 상황입니다:
실시간 애플리케이션: 애플리케이션이 사용자 작업이나 데이터 변화에 즉시 반응해야 하는 경우, EDA는 필요한 반응성을 제공할 수 있습니다.
확장성 필요: 시스템이 성장하고 증가하는 수의 이벤트를 처리할 것으로 예상되는 경우, EDA는 더 나은 확장성을 가능하게 합니다. 컴포넌트를 추가하거나 수정할 수 있으며 전체 시스템을 방해하지 않습니다.
분리된 컴포넌트:모듈식 설계를 촉진하려는 경우, EDA는 컴포넌트가 직접 호출이 아닌 이벤트를 통해 통신할 수 있도록 하여 도움이 됩니다. 이를 통해 시스템의 일부를 더 쉽게 업데이트하거나 교체할 수 있습니다.
복잡한 이벤트 처리: 여러 이벤트를 처리하고 이로부터 인사이트를 도출해야 하는 애플리케이션의 경우, EDA는 이러한 복잡한 시나리오의 처리를 단순화할 수 있습니다.
다양한 시스템의 통합: 통신해야 하는 다양한 시스템이나 서비스로 작업하는 경우, EDA는 다양한 기술 간의 유연한 통신을 가능하게 하여 더 효과적으로 통합하는 데 도움이 될 수 있습니다.
Event-Driven Architecture(EDA)의 이점
다음은 Event-Driven Architecture의 이점입니다:
유연성과 민첩성: 컴포넌트를 분리함으로써 EDA는 시스템이 변화하는 요구 사항에 쉽게 적응할 수 있도록 합니다. 전체 시스템에 영향을 주지 않고 새로운 기능을 추가하거나 변경할 수 있습니다.
확장성: EDA는 컴포넌트가 독립적으로 작동할 수 있도록 함으로써 확장성을 지원합니다. 시스템은 더 많은 컴포넌트나 리소스를 추가하여 증가된 부하나 증가하는 데이터셋을 처리할 수 있습니다.
실시간 반응성: EDA는 실시간 처리를 가능하게 하여 일이 발생할 때 처리되도록 합니다. 이는 금융 거래나 빠른 응답이 필요한 Internet of Things 앱과 같은 애플리케이션에 필수적입니다.
느슨한 결합: Event-Driven 시스템의 컴포넌트는 느슨하게 연결되어 있으므로 서로에게 많이 의존하지 않습니다. 이는 자립성을 장려하고 개별 부분의 유지보수를 더 간단하게 만듭니다.
향상된 모듈성: EDA는 모듈식 설계를 장려하여 복잡한 시스템을 관리 가능한 컴포넌트로 분해합니다. 이 모듈식 구조는 개발, 테스트 및 유지보수를 단순화합니다.
Event-Driven Architecture(EDA)의 과제
Event-Driven Architecture (EDA)는 많은 이점이 있지만 고려할 가치가 있는 몇 가지 과제도 함께 제공됩니다. 다음은 몇 가지 주요 과제입니다:
증가된 복잡성: 더 많은 이벤트와 컴포넌트가 추가되면 EDA 시스템은 복잡해질 수 있습니다. 이벤트 흐름을 관리하고 모든 것을 조정하는 것이 어려울 수 있습니다.
이벤트 순서 및 일관성: 이벤트를 올바른 순서로 유지하고 시스템이 일관성을 유지하도록 하는 것은 까다로울 수 있습니다. 순서가 맞지 않게 들어오는 이벤트를 처리하거나 작업이 그룹으로 완료되도록 보장하려면 추가 노력이 필요할 수 있습니다.
디버깅 및 추적: 분산되고 비동기적인 설정에서 문제를 찾고 수정하는 것은 기존 시스템보다 어려울 수 있습니다. 문제를 추적하는 데 더 많은 시간이 걸릴 수 있습니다.
이벤트 지연: 이벤트가 개별적으로 처리되므로 이벤트가 발생할 때와 이에 응답할 때 사이에 지연이 있을 수 있습니다. 이 지연은 빠른 반응이 필요한 상황에서 문제가 될 수 있습니다.
Event-Driven Architecture(EDA)의 사용 사례
다음은 Event-Driven Architecture의 사용 사례입니다:
금융 서비스: EDA는 거래의 실시간 처리, 사기 탐지 및 시장 데이터 업데이트를 위해 금융 시스템에서 유용합니다. 거래 실행, 결제 승인 및 시장 변동과 같은 이벤트는 즉각적인 응답을 트리거할 수 있습니다.
전자상거래: EDA는 주문 배치, 재고 변경 및 결제 처리를 포함한 작업을 전자상거래 플랫폼에서 처리할 수 있습니다. 실시간 주문 모니터링, 재고 관리 및 외부 서비스와의 원활한 연결을 모두 가능하게 합니다.
Internet of Things (IoT): 장치가 많은 이벤트를 생성하는 Internet of Things 애플리케이션의 경우 EDA가 완벽합니다. 센서 데이터의 실시간 처리, 원격 모니터링 및 변화하는 환경 조건에 대한 빠른 반응을 가능하게 합니다.
통신: EDA는 네트워크 컴포넌트 간의 Event-Driven 통신, 네트워크 모니터링 및 통신 산업의 실시간 호출 처리를 촉진합니다. 동적 네트워크 상황 관리 및 부하 적응을 용이하게 합니다.
온라인 게임: 온라인 게임에서 EDA는 플레이어 간의 실시간 상호작용, 게임 내 이벤트 처리 및 게임 상태 업데이트를 지원합니다. 플레이어 작업 및 게임 이벤트에 대한 동적 적응을 가능하게 합니다.
Event-Driven Architecture(EDA)의 구현
Event-Driven Architecture (EDA)를 구현하려면 Event Source, Event Bus 및 Subscriber를 포함한 여러 컴포넌트가 필요합니다. 여기서는 Python과 기본 이벤트 처리 메커니즘을 사용한 단순화된 예제를 구현합니다.
온라인 주문 시스템의 시나리오를 고려해봅시다. 여기서 우리는 주문이 배치될 때 사용자에게 알림을 주고 싶습니다. Publisher, Event Bus 및 Subscriber를 사용하여 간단한 EDA 시스템을 구현합니다.
다음은 위의 예제 구현입니다:
# Event Bus
classEventBus:
subscribers = {}
@classmethod
defsubscribe(cls, event_type, subscriber):
if event_type notin cls.subscribers:
cls.subscribers[event_type] = []
cls.subscribers[event_type].append(subscriber)
@classmethod
defpublish(cls, event_type, data=None):
if event_type in cls.subscribers:
for subscriber in cls.subscribers[event_type]:
subscriber.handle_event(event_type, data)
# Event Subscriber
classOrderNotificationSubscriber:
defhandle_event(self, event_type, data=None):
if event_type == 'OrderPlaced':
print("Notification: Your order with ID {} has been placed!".format(data['order_id']))
Notification: Your order with ID 123 has been placed!
위의 코드에 대한 설명:
Event Bus:
EventBus 클래스는 이벤트를 처리하기 위한 중앙 허브로 작동합니다. 컴포넌트가 특정 이벤트 유형을 구독하고 Subscriber에게 알리기 위해 이벤트를 발행할 수 있도록 합니다.
Event Subscriber:
OrderNotificationSubscriber 클래스는 'OrderPlaced' 이벤트를 처리하는 Subscriber의 예입니다. 실제 시나리오에서 이 Subscriber는 알림, 이메일 또는 기타 작업을 트리거할 수 있습니다.
Event Publisher:
OrderService 클래스는 주문을 배치하는 책임이 있는 서비스를 나타냅니다. 주문을 배치한 후 EventBus를 사용하여 'OrderPlaced' 이벤트를 발행하고 Subscriber에게 알립니다.
예제 사용:
예제 사용 섹션에서 Subscriber와 Publisher의 인스턴스를 생성합니다. Subscriber는 EventBus.subscribe 함수를 사용하여 'OrderPlaced' 이벤트에 등록합니다. order_service.place_order를 사용하여 주문이 배치될 때 Subscriber의 handle_event 메서드가 호출되고 이벤트가 발행됩니다.
Event-Driven vs. Message-Driven Architecture
다음은 Event-Driven Architecture와 Message-Driven Architecture의 차이점입니다:
측면
Event-Driven Architecture (EDA)
Message-Driven Architecture (MDA)
정의
중요한 발생 사항이나 상태 변화를 나타내는 이벤트에 초점을 맞춥니다.
종종 Message Broker를 사용하여 컴포넌트 간의 메시지 교환을 중심으로 합니다.
통신
컴포넌트는 이벤트를 통해 통신합니다.
통신은 메시지 교환을 포함하며, 이는 이벤트보다 더 광범위한 범위를 가질 수 있습니다.
데이터 흐름
이벤트 흐름이 작업을 트리거하는 것을 강조합니다.
데이터 흐름은 컴포넌트 간의 메시지 교환을 기반으로 합니다.
분리
컴포넌트 간의 느슨한 결합을 촉진합니다.
메시징 미들웨어에 의존하여 분리를 목표로 합니다.
트리거 메커니즘
이벤트는 종종 시스템의 특정 발생 사항이나 변화에 의해 트리거됩니다.
메시지는 통신하는 컴포넌트의 필요에 따라 전송 및 수신됩니다.
예시
주문 배치, 센서 데이터 업데이트가 작업을 트리거
Message Queue, Publish-Subscribe 시스템, Request-Reply 패턴
이벤트 처리
컴포넌트는 특정 이벤트에 응답하기 위한 이벤트 핸들러를 가집니다.
컴포넌트는 들어오는 메시지를 처리하기 위한 메시지 핸들러 또는 Listener를 가질 수 있습니다.