11/28 - TIL : 이벤트 소싱과 CQRS

이벤트 소싱과 CQRS에 대해 알아보자.

 

이벤트 소싱과 CQRS를 사용하면, 데이터 저장과 조회를 분리하여 시스템의 성능과 확장성을 향상시키는 데 도움을 준다고 한다. 

 

| 이벤트 소싱

이벤트 소싱은 데이터 상태를 변경할 때, 변경된 최종 상태만 저장하는 것이 아니라, 변경 과정을 기록한 이벤트(Event)를 저장하는 방식이다. 

• 데이터 상태 변화를 이벤트로 기록하고, 해당 이벤트들을 순차적으로 재생하여 현재 상태를 파악하는 방법이다. 
• 이벤트 소싱에서는 데이터 변경 자체가 아닌 변경 이벤트(상태 변화)를 저장한다. 
  • 주문 생성: 사용자가 주문을 생성했다는 기록.
  • 결제 완료: 사용자가 결제를 완료했다는 상태 변화.
  • 주문 취소: 사용자가 주문을 취소했다는 기록.

 

이벤트 소싱에서 사용되는 개념들은 다음과 같다. 

• 이벤트(Event) : 데이터의 상태 변화를 나타내는 기록 
• 이벤트 스토어(Event Store) : 이벤트를 저장하는 저장소, 전통적인 데이터베이스 대신 이벤트를 순서대로 저장하는 스토리지이다. 이는 이벤트의 불변성과 순차성을 보장한다. 
• 애그리게이트(Aggregate) : 관련된 이벤트를 모아 현재 상태를 재현할 수 있는 엔티티이다. 애그리게이트는 도메인 모델의 일부분으로, 이벤트를 적용하여 상태를 변화시킨다. 
• 커맨드(Command) : 애그리게이트에 특정 동작을 지시하는 명령어이다. 커맨드는 이벤트를 생성하는 트리거 역할을 한다. 
• 프로젝션(Projection) : 이벤트를 읽기 모델로 변환하여 조회 성능을 최적화하는 방식이다. 이벤트를 기반으로 읽기 전용 데이터베이스를 업데이트한다. 

 

이벤트 소싱의 장점은 데이터 변경 이력 추적, 복구 및 재생, CQRS와의 자연스러운 통합이 있다. 

• 데이터 변경 이력 추적 : 모든 상태 변화를 이벤트로 기록하므로, 데이터 변경 이력을 완벽하게 추적할 수 있다. 
• 복구 및 재생 : 이벤트를 재생하여 시스템의 현재 상태를 복구할 수 있다. 
• CQRS와의 자연스러운 통합 : 이벤트 소싱은 CQRS와 잘어울린다. 명령과 조회를 분리하여 성능과 확장성을 최적화할 수 있다. 

 

이벤트 소싱의 단점은 시스템 설계와 구현의 복잡성 증가(이벤트 모델링과 이벤트 스토어 관리)와 읽기 성능 저하(이벤트를 재생하여 현재 상태를 계산)가 있다. 

 

 

이벤트 소싱의 장점을 알아볼 때, 이벤트 소싱은 CQRS와 잘 어울린다고 하였다. 이는 이벤트 소싱의 단점인 읽기 성능 저하를 CQRS를 활용하여 해결할 수 있기 때문이다.

 

| CQRS (Command Query Responsibility Segregation)

CQRS는 명령과 조회의 책임을 분리하는 소프트웨어 디자인 패턴이다. 

• 읽기 작업과 쓰기 작업을 서로 다른 모델로 분리하여, 각 작업에 최적화된 구조를 사용할 수 있도록 한다. 
• CQRS는 시스템의 성능, 확장성, 유지보수성을 향상시키는데 도움이 된다. 

 

CQRS에서 사용되는 주요 개념은 다음과 같다. 

• 명령(Command) : 데이터를 변경하는 작업이다. 명령은 데이터베이스에 대한 쓰기 작업이다. 명령 모델은 데이터의 상태 변경을 담당하기 때문에 데이터의 무결성을 보장하기 위해 트랜잭션을 사용한다. 
• 조회(Query) : 데이터를 조회하는 작업이다. 조회는 데이터베이스에 대한 읽기 작업이다. 조회 모델은 읽기 전용 데이터베이스 또는 캐시를 사용하여 빠른 응답을 제공한다.

 

CQRS는 읽기와 쓰기를 분리했기 때문에 다음과 같은 장점이 있다. 

• 각 작업에 최적화된 데이터 저장소와 인프라를 사용할 수 있다. 예를 들어, 조회 성능을 높이기 위해 읽기 전용 데이터베이스를 사용하거나, 캐시를 활용할 수 있다.
• 또한, 읽기와 쓰기를 독립적으로 확장할 수 있다. 
• 비즈니스 로직이 명령 모델에 집중되므로, 복잡한 상태 변경 로직을 관리하기 쉽다. 
• 위에서 보았던 것처럼 CQRS는 이벤트 소싱과 잘 어울린다. 이벤트 소싱을 통해 데이터 상태 변경 이벤트를 기록하면, 이벤트를 재생하여 현재 상태를 유지할 수 있다. 따라서, 데이터의 일관성이 보장된다. 

 

하지만, 읽기와 쓰기를 분리했기 때문에, 시스템 설계와 구현의 복잡성이 증가하고 명령 모델과 조회 모델 간의 데이터 동기화가 필요하다. 

 

 

 

*이벤트를 재생한다는 의미는 저장된 이벤트들을 순서대로 처리하여 현재 시스템의 상태를 복원하는 과정을 의미한다. 

 

 

그럼, 이벤트 소싱과 CQRS를 어떻게 활용할 수 있을까? 

 

활용 예시도 살펴보자. 

| 이벤트 소싱과 CQRS의 활용

이벤트 소싱을 살펴보았을 때, 이벤트 소싱은 변경 이벤트를 저장하기 때문에, 데이터 변경 이력이 중요한 곳에 유용하게 쓰일 수 있다는 것을 알 수 있다. 

 

그리고, CQRS는 읽기와 쓰기를 분리하는 특징을 통해, 읽기와 쓰기의 요구사항이 다를 때 유용하게 활용될 수 있다. 특히, 읽기 작업이 빈번하거나, 읽기와 쓰기 작업이 모두 많아 대규모 트래픽에서 확장성이 중요한 경우에 효과적으로 적용할 수 있다.

 

이벤트 소싱의 상황에서는 모든 거래 기록이 중요하고, 변경 내역을 추적해야 하는 금융 거래 시스템이 될 수 있다.

CQRS의 상황에서는 사용자 피드 업데이트(쓰기)와 피드 조회(읽기) 작업이 구분된 소셜 네트워크가 될 수 있다. 

 

 

애플리케이션 요구 사항에 따라 적절히 선택을 하는 것이 중요한 것 같다.