이벤트 소싱 정리

이벤트 소싱이란?

이벤트의 발행 순서를 지키지 않으면 예상치 못한 결과가 발생하는 경우가 존재합니다. 그러한 경우 메시지 브로커를 통해 메시지 처리 순서를 보장할 수도 있지만 이벤트 소싱을 사용하여 순서를 보장할 수 있습니다. 이벤트 소싱은 애플리케이션 상태에 대한 모든 수정 사항이 이벤트로 순차적으로 저장되는 고유한 시스템 설계 패턴입니다. 각 상태 변경을 트랜잭션 로그에 기록한다는 점에서 트랜잭션 데이터베이스 시스템의 작동 방식과 유사합니다. 그러나 이벤트 소싱의 맥락에서 '이벤트'는 '알림'보다 '상태 변경'을 의미합니다.

 

이벤트 소싱의 핵심 구성 요소는 이벤트의 순서가 보존되는 특수 저장 공간인 이벤트 저장소입니다. 이 시스템은 이전 이벤트를 새 이벤트로 덮어쓰지 않습니다. 대신 새 이벤트를 시퀀스에 추가하여 상태 변경에 대한 완전한 기록 기록을 유지합니다.

 

이벤트 소싱과 이벤트 드리븐 아키텍처의 차이

목표

이벤트 소싱은 모든 상태 변경에 대한 기록 유지라는 특정 목표를 가진 디자인 패턴입니다. 이 패턴은 일반적으로 단일 애플리케이션이나 시스템 내에서 사용되며, 크든 작든 모든 상태 변경을 저장하여 향후에 사용할 수 있도록 합니다. 즉, 신뢰할 수 있고 정확한 기록 기록을 생성하는 것을 목표로 합니다.

 

이벤트 중심 아키텍처는 더 넓은 범위와 다른 목표를 가지고 있습니다. 이 설계 패턴은 여러 애플리케이션이나 시스템에서 사용되며 환경 변화에 신속하게 대응하는 확장성이 뛰어난 프레임워크를 구축할 수 있습니다. 민첩성, 유연성, 실시간 응답성이 핵심입니다.

 

중앙화 vs 분산

이벤트 소싱에는 통합 데이터베이스 역할을 하는 중앙 이벤트 스토어가 있습니다. 이 데이터베이스는 모든 이벤트를 기록하여 시간 순서대로 저장합니다. 마치 시스템의 상태 변경 이력을 기록하는 책과 같습니다.

 

이벤트 중심 아키텍처는 다른 접근 방식을 취합니다. 데이터 저장소는 일반적으로 다양한 구성 요소 또는 이벤트 프로세서에 분산되어 있습니다. 각 구성 요소에는 자체 저장소가 있어 데이터 처리 방식에 독립성과 유연성을 더합니다. 그럼에도 불구하고 이들은 서로 통신하여 원활한 작동을 보장합니다.

 

기록 vs 실시간

이벤트 소싱은 기록 추적이 필요하거나 복잡한 비즈니스 워크플로우가 필요한 상황에서 특히 유용합니다. 이벤트 소싱은 단순한 감사 및 디버깅 이상의 기능을 수행하는 강력한 도구입니다. 또한 과거 데이터를 사용해 미래 예측을 위한 모델을 학습시키는 예측 분석에도 도움이 됩니다.

 

반면 이벤트 중심 아키텍처는 실시간 응답을 제공하는 데 중점을 둡니다. 실시간 모니터링, 애플리케이션 간의 데이터 공유 또는 이벤트 스트리밍 애플리케이션의 통합에 이상적이며, 시스템이 변경 사항에 즉시 대응할 수 있도록 합니다.

 

이벤트 소싱 적용이 유리한 경우

• 기록을 유지해야할 때
  • 애플리케이션에서 모든 상태 변경에 대한 자세한 설명을 저장해야 하는 경우 이벤트 소싱을 사용하면 이러한 목적을 효과적으로 달성할 수 있습니다.
  • eg. 장바구니에 품목 추가, 수량 변경, 쿠폰 사용, 결제하기
• 감사가 필요한 경우
  • 높은 수준의 감사 가능성이 필수인 금융이나 헬스케어와 같은 분야에서는 이벤트 소싱이 탁월한 선택이 될 수 있습니다.
  • eg. 은행 입금, 출금, 이체 등 모든 거래
• 비즈니스 엔티티의 추적이 필요한 경우
  • 추적이 필요한 복잡한 비즈니스 이벤트를 처리할 때 이벤트 소싱을 사용하면 특정 상태로 이어지는 일련의 이벤트를 추적하는 데 도움이 될 수 있습니다.
  • eg. 재고 관리 시스템
• 시간 기반 질의가 필요한 경우
  • 시스템에서 시간과 관련된 쿼리를 수행해야 하는 경우, 이벤트 소싱 패턴에서 유지되는 이벤트의 시간 순서가 이러한 요구를 충족합니다.

 

이벤트 소싱과 이벤트 드리븐 아키텍처의 조합

데이터 정합성

이벤트 소싱은 지속성 패턴으로, 모든 데이터 변경이 변경 불가능한 이벤트로 기록되도록 보장합니다. 이러한 이벤트는 시스템 상태에 대한 신뢰할 수 있는 단일 소스 역할을 합니다. 이벤트 중심 아키텍처에서는 이러한 이벤트가 느슨하게 결합된 방식으로 시스템의 다양한 부분에 전달됩니다. 이렇게 하면 모든 컴포넌트가 최신 상태 변경 사항을 최신 상태로 유지할 수 있습니다.

 

마이크로 서비스 통신

이벤트 중심 아키텍처는 마이크로서비스 기반 시스템에 이상적입니다. 각 마이크로서비스는 메시지 브로커에 이벤트를 게시할 수 있으며, 관심 있는 마이크로서비스는 해당 이벤트를 구독할 수 있습니다. 이벤트 소싱과 결합하면 마이크로서비스는 데이터 변경을 나타내는 이벤트를 수신하고 그에 따라 상태를 업데이트할 수 있습니다.

 

CQRS

이벤트 소싱은 명령(쓰기 작업)과 쿼리(읽기 작업)가 별도로 처리되는 CQRS 패턴과 밀접한 관련이 있습니다. 이벤트 소싱과 이벤트 중심 아키텍처의 조합은 이러한 분리를 자연스럽게 지원합니다. 이벤트는 상태를 업데이트하는 명령을 나타내며, 시스템의 여러 부분이 이러한 이벤트를 구독하여 읽기 작업을 효율적으로 처리할 수 있습니다.

 

복원력과 내결함성

이벤트 중심 아키텍처는 본질적으로 복원력과 내결함성이 뛰어납니다. 구성 요소가 이벤트를 처리하지 못하면 전체 시스템에 영향을 주지 않고 다른 구성 요소에서 다시 시도하거나 처리할 수 있습니다. 이벤트 소싱은 장애 발생 시 이벤트를 재생하여 시스템 상태를 재현하거나 일시적인 쿼리를 지원할 수 있기 때문에 이러한 복원력을 더욱 강화합니다.

 

이벤트 버전닝과 혁신

시간이 지남에 따라 이벤트 구조는 변화하는 비즈니스 요구 사항을 수용하기 위해 개선되어야 합니다. 이벤트 중심 아키텍처는 다양한 소비자가 다양한 이벤트 버전에 적응할 수 있으므로 이벤트 버전 관리를 처리할 수 있습니다. 이벤트 소싱은 이벤트 로그 기록을 통해 전체 시스템이 이벤트를 재생하고 이벤트 구조의 변경에도 불구하고 올바른 상태를 재현할 수 있도록 보장합니다.

 

주의 사항

이벤트 소싱과 이벤트 기반 시스템을 모두 사용할 때는 이벤트 객체를 사용하는 방식에 주의해야 합니다. 두 가지 모두에 동일한 이벤트 객체를 사용하면 애플리케이션의 내부 데이터 구조에 원치 않는 종속성이 발생할 수 있습니다. 대신 어떤 데이터가 변경되는지 명확하게 명시하는 별도의 '계약'을 만드는 것이 좋습니다. 이렇게 하면 애플리케이션 내부 데이터의 잠재적인 노출이나 유출을 방지하고 데이터 모델의 무결성과 독립성을 유지할 수 있습니다.

 

• 참고자료
  • https://estuary.dev/blog/event-driven-vs-event-sourcing/
  • https://microservices.io/patterns/data/event-sourcing.html