이벤트 기반 아키텍처는 마이크로서비스가 이벤트라고 하는 상태 변화에 대응하는 소프트웨어 설계 패턴입니다. 이벤트는 상태(예: 상품 가격 또는 배송 주소)를 전달할 수 있으며, 또는 이벤트가 식별자(예: 주문 접수 또는 배송 알림)일 수 있습니다. 이벤트는 공통 목표를 달성하기 위해 함께 작동하는 마이크로서비스를 트리거하지만 이벤트 형식을 제외하면 서로에 대해 알 필요는 없습니다. 각 마이크로서비스는 함께 작동하지만 서로 다른 비즈니스 로직을 적용하고 자체 출력 이벤트를 내보낼 수 있습니다.
이벤트의 특성은 다음과 같습니다.
- 일어난 일의 기록입니다.
- 이는 변경하거나 삭제할 수 없는 변경 불가능한 사실을 캡처합니다.
- 이벤트 소비 시 서비스가 적용하는 로직에 관계없이 발생합니다.
- 무기한 대규모로 유지되며 필요한 만큼 사용할 수 있습니다.
이벤트 기반 시스템에서는 이벤트 제작자가 이벤트를 생성하고 이벤트 라우터(또는 브로커)에서 이벤트를 필터링한 다음 적절한 이벤트 소비자(또는 싱크)로 팬아웃합니다. 이벤트는 하나 이상의 일치하는 트리거에 의해 정의된 구독자에게 전달됩니다. 이러한 3가지 구성요소(이벤트 제작자, 이벤트 라우터, 이벤트 소비자)는 분리되어 독립적으로 배포, 업데이트, 확장 가능합니다.
이벤트 라우터는 서로 다른 서비스를 연결하며 메시지가 전송 및 수신되는 매체입니다. 이벤트 제작자가 생성한 원래 이벤트에 대한 응답을 실행하고 이 응답을 적절한 소비자에게 다운스트림으로 보냅니다. 매우 단순화된 이벤트 흐름의 다음 다이어그램과 같이 서비스가 이벤트에 반응하거나 이에 영향을 받을 때 이벤트가 비동기적으로 처리되고 결과가 결정됩니다.
이벤트 기반 아키텍처를 사용해야 하는 경우
시스템을 설계할 때 다음 용도를 고려하세요.
- 스토리지 버킷, 데이터베이스 테이블, 가상 머신 또는 기타 리소스의 이상치나 변경사항에 대한 알림을 모니터링하고 수신하는 경우
- 여러 소비자에게 단일 이벤트를 팬아웃하는 경우. 이벤트 라우터는 맞춤설정된 코드를 작성할 필요 없이 모든 적절한 소비자에게 이벤트를 푸시합니다. 그러면 각 서비스가 이벤트를 동시에 처리하면서 다르게 처리할 수 있습니다.
- 각 스택의 독립성을 유지하면서 여러 기술 스택 간의 상호 운용성을 유지하는 경우
- 여러 리전과 계정에서 운영하고 배포하는 시스템과 팀을 조정하는 경우. 마이크로서비스의 소유권을 재구성할 수 있습니다. 팀 간 종속 항목이 적고 데이터 액세스에 대한 장벽이 되는 장애에 더 빠르게 대응할 수 있습니다.
이벤트 기반 아키텍처의 이점
다음은 이벤트 기반 아키텍처를 빌드할 때의 몇 가지 이점입니다.
느슨한 결합 및 개발자 민첩성 향상
이벤트 제작자는 이벤트 소비자로부터 논리적으로 구분됩니다. 이벤트의 프로덕션과 소비가 분리되어 있으면 서비스가 상호 운용이 가능하지만, 서로 독립적으로 확장, 업데이트, 배포할 수 있습니다.
느슨한 결합으로 종속 항목을 줄이고 다양한 언어와 프레임워크로 서비스를 구현할 수 있습니다. 어느 한 서비스의 로직을 변경하지 않고도 이벤트 제작자 및 수신자를 추가하거나 삭제할 수 있습니다. 이벤트를 폴링, 필터링, 라우팅하기 위해 커스텀 코드를 작성할 필요가 없습니다.
비동기 이벤트 및 복원력
이벤트 기반 시스템에서는 이벤트가 비동기식으로 생성되며 응답을 기다리지 않고 즉시 발생할 수 있습니다. 느슨하게 결합된 구성요소는 한 서비스가 실패해도 다른 서비스가 영향을 받지 않음을 의미합니다. 필요한 경우 수신 이벤트가 장애점에서 다시 시작하거나 이전 이벤트를 재생할 수 있도록 이벤트를 로깅할 수 있습니다.
푸시 기반 메시징, 실시간 이벤트 스트림, 저렴한 비용
이벤트 기반 시스템은 내보내기 기반 메시징이 가능하며, 클라이언트는 원격 서비스에서 상태 변경을 지속적으로 폴링할 필요 없이 업데이트를 수신할 수 있습니다. 이렇게 푸시된 메시지는 즉시 데이터 처리 및 변환, 실시간 분석에 사용할 수 있습니다. 또한 폴링이 적으면 네트워크 I/O가 감소하고 비용이 절감됩니다.
간소화된 감사 및 이벤트 소싱
이벤트 라우터의 중앙 집중식 위치를 통해 감사를 간소화하고, 라우터와 상호작용할 수 있는 사용자, 데이터에 액세스할 수 있는 사용자 및 리소스를 제어할 수 있습니다. 또한 전송 중인 데이터와 저장 데이터를 모두 암호화할 수 있습니다.
또한 애플리케이션 상태의 모든 변경사항을 기록하는 아키텍처 패턴인 이벤트 소싱을 원래 적용된 순서와 동일하게 활용할 수 있습니다. 이벤트 소싱은 이전 상태를 재현하기 위해서나 비즈니스 기반 결정을 설명하는 표준 설명의 감사 목적으로 보관 가능한 변경할 수 없는 이벤트의 로그를 제공합니다.
아키텍처 고려사항
이벤트 기반 아키텍처를 사용하려면 애플리케이션 설계를 새로운 방식으로 접근해야 할 수 있습니다. 마이크로서비스 또는 분리된 구성요소를 사용하는 애플리케이션에 매우 적합하지만 다음을 고려해야 합니다.
모든 단일 이벤트를 처리해야 하는 경우 이벤트 소스가 전송을 보장할 수 있습니까?
내구성이 뛰어나고 안정적인 이벤트 소스여야 합니다.
애플리케이션에서 여러 비동기식 요청을 처리할 수 있습니까?
시스템 성능이 전역 범위 또는 비탄력적 데이터베이스에 의존하지 않아야 합니다.
이벤트 흐름을 어떻게 추적하고 싶으십니까?
이벤트 기반 아키텍처는 모니터링 서비스를 사용한 동적 추적을 지원하지만 코드 분석을 사용하는 정적 추적은 지원하지 않습니다.
이벤트 소스의 데이터를 사용하여 상태를 다시 빌드하시겠습니까?
데이터의 중복 삭제 및 순서 지정 방법을 고려해야 합니다.
다음 단계
- Eventarc가 이벤트를 처리하는 방법을 이해하려면 Eventarc 개요 참조하기
- Eventarc 트리거 만드는 방법 알아보기