Event Sourcing 맛보기 - 이론편

안녕하세요 오늘은 이전 시간에 CQRS에 대해서 알아보는 시간에 이어서 Event Sourcing에 대해서 알아보는 시간을 가져보도록 하겠습니다.

Event Sourcing 이란 ?

이벤트 소싱이란 application의 모든 상태를 일으키는 이벤트를 순서에 맞게 저장하여 status를 만들어내는 방법입니다. 먼저 말씀 드리면 사실 일반적인 경우에 필요하진 않습니다. 아니, 대부분의 경우에는 이렇게 구현할 필요하가 없습니다. 하지만 필요한 경우가 있고 장점도 충분히 가지고 있습니다. 설계할 때 몰라서 고려하지 않는 것 보다는 알아두면 좋은 설계 테크닉 정도로 생각하시면 좋을것 같습니다.

먼저 일반적으로 어플리케이션에서 데이터 모델을 저장하는 방법은 현재 상태를 저장하는 방법을 이용합니다. 여기에는 NoSQL, RDBMS 등을 따지지 않습니다. 어떤 데이터를 어떤 모델로 저장하냐에 대한 부분입니다. 이렇게 저장했을 때는 우리는 마지막 상태값만을 알 수 있습니다. 만약 log를 남기는 테이블을 주고 snapshot을 찍었다면 우리는 지금까지 원하는 데이터의 변화되어온 상태를 알 수 있게 될 것입니다. 하지만 이러한 저장 방식으로는 현재 상태가 된 why(이유) 또는 how(방법)을 알 수 없습니다. 우리는 데이터의 상태를 알 수 있을 뿐입니다.

이벤트 소싱은 위애 정의한 듯이 데이터의 상태를 변경시키는 모든 데이터를 저장합니다. 그리고 사용할 때 이를 replay 해서 데이터의 마지막 상태값을 만들어 냅니다. 정의를 보면 이벤트를 저장한다고 했는데 이것은 제가 보기엔 상태를 만들어내는 Command를 저장한다고 보면 될 것 같습니다. 이렇게 저장했을 때의 장점은 기존 데이터 모델에서는 알 수 없었던 현재 상태가 된 why(이유)를 Event 데이터와 이를 replay했을 때 바로 알 수 있다는 것입니다.

그렇다면 아래에서 이벤트 소싱에 대해 더 자세한 이야기를 해보도록 하겠습니다.

Example of Event Sourcing

위에서 Event Sourcing에 대해서 설명했지만 좀 더 이해를 돕기 위해서 예를 하나 들어보도록 하겠습니다. 아래 예제는 Axon 사이트에서 나와있던 예제를 이미지화 한 것입니다. 일반적인 데이터 저장 방식과 이벤트 소싱 저장방식은 아래 와 같은 차이를 가집니다.

이미지에서 박스 1개가 RDBMS에서의 row 1개에 해당한다고 봐주시면 될 것 같습니다.

특이점으로 보면 2번째 콜라 선택을 했을 때와 4번째 감자튀김 제거를 했을 때 일반적인 데이터 저장 방식으로는 동일한 값을 가지는 것을 알 수 있습니다. 같은 상태를 가지지만 이는 다른 방식으로 해당 상태가 되었다는 사실을 우리는 이미지로 알 수 있습니다. 반면에 이벤트 소싱을 이용한 오른쪽 데이터를 보도록 하겠습니다. row 수는 상대적으로 많다는 것을 알 수 있습니다. 하지만 데이터를 통해 해당 상태가 된 이유를 설명할 수 있다는 장점을 가진다는 것을 이해할 수 있었습니다.

어떤 장점을 가지는가 ?

Event Sourcing의 가장 눈에 특징은 Object의 모든 상태 변화가 기록되어진다는 것에 있습니다. 그러면 이렇게 Event Sourcing 기법을 통한다면 어떠한 장점을 가질 수 있는 지 먼저 알아보도록 하겠습니다.

• History : 모든 상태 변화가 기록하기때문에 이는 Application과의 상호작용(interaction) 로그(History)로써 활용
• Complete Rebuild : Object의 Event Sourcing를 처음부터 replay하면 현재 상태로 완벽하게 재현 가능
• Temporal Query : 현재 상태 뿐만 아니라 Object의 특정 시점으로 replay 가능
• Event Replay : 만약 비즈니스 로직이 잘못되어있어서 문제가 발생했다면 비즈니스 수정 후 Event를 reversing & replay하여 정상화 가능
  • 단, 외부 의존성을 판단하여 충분히 사용할 수 있고 유효한 방법일 지 확인 필요
• 애자일 방식으로 개발을 진행할 때 기존 event 데이터를 통해서 로직이 정상인지 검증 가능
• Admin 시스템 등이라면 full audit 기능이 필요하며 이 기능의 log로 활용 가능
• 경우에 따라 Write( Create / Update / Delete ) Operation의 속도의 상승으로 latency 최소화 ( Event를 저장 후 이후 후처리를 하는 방식 채택을 통해 )

어떤 단점을 가지는가 ?

장점을 알아보았으니 이번에는 단점을 알아보도록 하겠습니다.

• 현재 정확한 정보를 얻기 위해서는 Event Soucring의 Event 데이터를 replay 해야하므로 read 성능 약화
  • snapshot을 통해 어느정도 완화할 수 있지만 동일 기존 모델에 비해서는 떨어짐
• 대부분 Eventually Consistency를 기본으로 하기 때문에 유저의 write 성공한다고 바로 유저가 최신 정보를 얻을 수 없을 수 있음
• 기존 모델에 비해서 상대적으로 데이터 저장을 더 많이 하기 때문에 대용량 데이터 처리에 대한 고민이 필요
• write에 대한 고민이 줄어드는 대신 read에 대한 고민이 늘어남
  • 어떻게 데이터를 유저에게 빠르게 보여줄 수 있을 것인가 ?
  • read 모델과 write 모델의 불일치에 따른 CQRS 고민 필요

CQRS와 Event Sourcing의 관계

위의 단점에서 살짝 언급했습니다만 Event Sourcing은 read 모델과 write 모델이 다르기 때문에 CQRS의 장점과 단점을 그대로 가질 수 밖에 없습니다. 즉, Event Sourcing은 CQRS가 없이는 이루어 질 수 없다고 보시는게 좋을것 같습니다. 이에 대한 이야기는 CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편를 참고해주시면 좀 더 자세한 내용을 확인하실 수 있습니다.

사용할 수 있는 예제

Event Sourcing을 사용할 수 있고 장점을 활용할 수 있는 예제는 사실 그렇게 많지 않습니다. 활용하면 좋을것으로 보이는 예시로 아래를 들 수 있습니다.

• 어플리케이션 Object 상태 저장소 ( 상태 변화를 모두 저장해야하느 경우 )
• Audit 저장소
  • 유저의 행위를 모두 기록하는 저장소
• Event Reversing & Replay가 필요한 경우
  • Event의 재발행이 불가능한 시스템
• 재화 시스템을 만들 경우 해당 재화의 전체 흐름을 파악하기 위한 시스템
  • ex) 미국의 Sarbanes–Oxley Act 법 대응 시스템

마무리

오늘은 이렇게해서 이전 CQRS에 이어서 Event Sourcing에 대해서 알아보는 시간을 가져보았습니다.

CQRS와 마찬가지로 해당 기법 또한 일반적인 경우에는 고려대상이 아니지만 경우에 따라서 하나의 설계 할 수 있는 패로써 가지고 있으면 충분히 사고를 유연하게 할 수 있다고 생각합니다.

다음 시간에는 Spring Boot 환경에서 Event Sourcing을 간단하게 구현해보는 시간을 가져보고 구현하는데 허들이 되는 부분들을 짚어보도록 하겠습니다.

감사합니다.

참고

[1] https://www.baeldung.com/cqrs-event-sourcing-java

[2] https://www.baeldung.com/axon-cqrs-event-sourcing

[3] https://martinfowler.com/eaaDev/EventSourcing.html

[4] https://developer.axoniq.io/event-sourcing/overview

[5] https://martinfowler.com/eaaDev/EventSourcing.html