마이크로 서비스 패턴 #6 이벤트 소싱(비즈니스 로직 설계)

이벤트 소싱

이벤트 발행 및 관리에 대해서 저장을 어떻게 할 것인가?

이에 대해 MSA는 이벤트 소싱이라는 패턴을 활용한다.

 

이벤트 소싱이란 이벤트 저장소에 해당 이벤트를 순차적으로 저장해서 관리하는 것이다.

 

https://www.slideshare.net/madvirus/event-source

 

즉, 이벤트의 최종 결과값이 아닌 전체 순서를 모두 저장하여 관리하는 형태이다. 이러한 이벤트들을 개체에 차례로 적용시켜서 따라가면 최종 결과값을 얻게 된다.

 

기존 흔히 사용하는 영속화 모델과 비교한다면 이미 정형화된 모델에 상태를 저장하는 과정에서 나타나는 문제를 해결할 수 있다. 영속화 모델에서는 지나간 작업 목록에 대해 기록을 찾기 어렵다(ex. 삭제했던 데이터 전부 가져오기). 계속해서 최신 상태의 개체에 상태를 업데이트 하기 때문이다. 그 외에도 문제점들이 있는데 정리하면 다음과 같다.

 

영속화 모델의 문제점

• 객체-관계의 부정합
• 애그리거트 이력관리 불가
• 감사 로깅 구현 어려움
• 이벤트 발행로직이 비즈니스 로직에 추가됨

 

그러나 이벤트 소싱 패턴은 이처럼 이벤트를 계속하여 저장하고 있다는 점에서 다양한 작업들이 가능하다. 그리고 그 이벤트의 대상은 애그리거트(aggregate)가 되면서 이력관리 뿐 아니라 위의 단점들을 극복할 수 있다.

---

이벤트 소싱 특징

 

동시 업데이트 : 낙관적 잠금

이벤트 번호 등을 버전번호로 관리하며 Race condition과 같은 문제를 해결할 수 있다(업캐스팅 최신 버전 관리).

 

스냅샷을 통한 성능 개선

이벤트를 계속해서 저장하면 용량 관리가 안되지 않을까? 

이를 스냅샷을 통해 해결할 수 있다. 주기적으로 애그리거트 상태의 스냅샷을 저장하여 그 스냅샷 이후의 이벤트만 가져오는 식으로 애그리거트 상태를 복원할 수 있다.

 

멱등한 메세지 처리

메세지 브로커가 동일한 메세지를 여러 번 전송하더라도 메세지 컨슈머는 멱등하게 처리한다.

중복 메세지를 솎아 내서 처리할 수 있도록 해야 하는데 이는 RDBMS 인지 NoSQL 인지에 따라 다르다.

 

RDBMS의 경우 메세지 ID와 이벤트를 각기 다른 테이블에 삽입하는 트랜잭션 일부로 처리한다.

NoSQL 은 트랜잭션 모델이 제한적이라 메세지 ID를 기록할 목적으로 가짜 이벤트를 발행해서 처리한다.

 

이벤트 소싱의 장점

• 도메인 이벤트를 확실하게 발행
• 애그리거트 이력 관리
• 객체-관계 임피던스 불일치 문제 방지
• 개발자에게 타임머신 제공

 

 

이벤트 소싱의 단점

• 프로그래밍 모델 이해 어려움
• 메시징 기반 애플리케이션 복잡도
• 이벤트 개량하기 어려움
• 데이터 삭제 어려움
• 이벤트 저장소 쿼리하기 어려움

---

사가와 이벤트소싱

코레오그래피 사가 구현: 이벤트 소싱

이벤트 소싱은 이벤트가 모든것을 주도하므로 코레오그래피 사가 구현 수월하다.

 

애그리거트 업데이트 > 사가 이벤트 발생 > 이벤트 핸들러들은 이벤트 소비 후 애그리거트 업데이트 > 프레임워크는 각이벤트 핸들러에 대해 멱등하게 처리

 

그러나 이벤트의 목적이 이원화된다.

이벤트 소싱: 상태 변화 / 사가  코레오그래피: 사가 참여자 간 작업처리

따라서 오케스트레이션 사가 활용 적절할 수도 있다.

 

오케스트레이션 사가 구현 이벤트 소싱

사가 오케스트레이터에서 다음의 두 가지 원칙을 지키며 설계

• 커맨드 메세지를 확실하게 전송
• 응답을 꼭 한번만 처리