Axon Framework이 Postgres, MySql, Mongodb 대신 Axon Server를 쓰는 이유

 

 

개요

Axon Framework을 쓴다고 하면 Event Store로 Axon Server만 써야 한다고 생각 할 수 있습니다.

 

하지만 Axon Framework는 Event Store로 Postgres, MySql등 RDB와 Mongodb 와 같은 NoSql도 지원 합니다.

 

그럼에도 불구하고 Axon Server를 Event Store로 쓰는 이유에 대해 알아보겠습니다.

 

Event Store의 요구사항

표면적으로는 Event Store에 대한 요구 사항이 비교적 간단해 보입니다.

• 이벤트 스트림에 이벤트 추가
• 쓰기 순서로 이벤트 읽기

이렇게 두가지 기능만 있으면 Event Store로 문제가 없을 것 같다고 생각할 수 있습니다. 하지만 막상 Event Sourcing을 구현 하려고 하면 더 많은 기능이 필요하다는 것을 알 수 있습니다.

 

 

Aggregate 시퀀스 번호 유효성 검사 - 집계  에 대한 이벤트 작성 순서 번호가 순서대로 증가하고 Aggregate에 대해 동일한 시퀀스 번호를 가진 두 개의 이벤트가 없는지 확인해야 합니다. 이는 ACID의 Consistancy와 관련이 있습니다.

 

한 번에 여러 이벤트 추가 -  아래 이미지와 같이 발행된 Command(CreateOrderCommand)는 여러 이벤트를 생성할 수 있습니다. 여러개의 이벤트가 모두 발행되거나 어떠한 이벤트도 발행되지 않도록 해야 합니다.

 

 

커밋된 이벤트만 읽기 -  트랜잭션이 저장소에 커밋된 후에만 저장된 이벤트를 읽을 수 있도록 합니다(격리).

 

손실로부터 보호되는 커밋된 이벤트 -  데이터베이스의 가치는 Commit된 이후의 데이터는 손실되더라도 복구 할 수 있어야 합니다.(내구성)

 

스냅샷 -  단일 Aggregate에는 엄청난 수의 이벤트가 있을 수 있습니다. 이벤트 저장소에서 Aggregate 재생 시 명령 실행이  느려질 수 있습니다. Axon Server는 Aggregate의 스냅샷을 생성 하고 스냅샷 이후 이벤트만 로드하고 재구성하는 것입니다.

 

특정 시점 이후의 이벤트 읽기 및 새 이벤트 푸시 - 새 이벤트에 응답하는 고성능 프로세서는 가능한 한 빨리 이벤트를 푸시해야 합니다.

 

스토리지 크기에 따른 일정한 성능 -  우리는 오랜시간에 걸쳐 초당 수천 개의 이벤트가 발생하며, 몇년 동안 시스템에 쌓여 있습니다. 즉, Event Store에는 수십억 개의 이벤트가 쌓여있을 수 있습니다. 이벤트 저장소가 이러한 이벤트로 가득 차서 느려지면 전체 시스템의 성능이 크게 저하됩니다.

 

최근 이벤트에 최적화 -  스냅샷을 사용하는 경우 가장 최근 이벤트에만 반응하도록 되어있습니다. 따라서 이벤트를 더 빨리 검색할 수 있도록 이벤트 저장소를 최적화해야 합니다.

 

위와 같은 기능이 Event Sourcing System을 구축하는데 필요한 기능 입니다. 하지만 이 기능들이 Kafka, Mysql, Mongodb에서 모두 지원 하지는 않기 때문에 Axon Server를 선택 하게 됩니다.

 

 

 

참고

https://www.axoniq.io/blog/why-would-i-need-a-specialized-event-store