이벤트 소싱(Event Sourcing) 개념

이벤트 소싱 혹은 CQRS라는 말을 SNS에서 자주 보게 되었어요. 비슷한 시기에 번역을 의뢰받아서 진행하게 되었어요. 아카(Akka) 관련 책인데 약속했던 마감일보다 늦어지고 있습니다. 이유는, 아카 및 스칼라(Scala) 외에 새로운 개발 패턴 개념이 많이 녹아있었고, 경험이 약한 내가 번역하는게 맞는 건가 의구심이 들어서 평소보다 속도가 더디게 진행되었죠. 날 더디게 했던 패턴 중 2가지가 이벤트 소싱과 CQRS였습니다.

그러던 중 지인분들이 운영하고 있는 SPRING CAMP 2017의 프로그램 목록을 보게 되었고, 평소 신뢰와 존경하고있던 이규원님과 심천보님이 이벤트 소싱 이론부 & 실습부를 진행하신다는 것을 확인했어요. 망설임없이 표를 구걸해서 SPRING CAMP 2017에 참여하게 되었습니다.

훌륭한 세션을 듣고, 꼭 잊지 말아야 할 개념에 대해서만 간단하게 정리하려고 합니다. (규원님과 천보님의 발표 자료를 기반으로 작성했어요.)

이벤트 소싱 개념

기존의 데이터 저장 방식

사용자가 온라인 서점에서 책을 주문한다고 가정해 볼게요. 1번 책을 구매하고 싶어서 주문을 생성하고, 2번 책도 한번에 주문하려고 추가하게 되었어요. 다시 생각해보니 1번 책은 구매할 필요가 없어서 주문에서 삭제하게 되었죠. 이 상황에서 기존의 데이터 저장 방식이라면, 최종적으로 주문하게 되는 2번 책만 최종 값으로 저장하게 됩니다.

이벤트 저장 방식

같은 상황에서 이벤트 소싱은, 이벤트 자체를 데이터로 저장하게 됩니다. “사용자가 1번 책을 추가하여 주문을 생성한다.”, “2번 책을 주문에 추가한다”, “1번 책을 주문에서 삭제한다.” 라는 이벤트 자체가 저장되는 방식이죠. 그래서 이벤트 소싱에서는 UPDATE 혹은 DELETE의 개념이 없어요.

스냅샷

그래서 스냅샷의 개념을 도입합니다. 1000번째 이벤트가 발생할 때 스냅샷으로 저장해 두면 결국 최종 값은 1001번째 이벤트부터 재생해서 얻을 수 있겠죠?

CQRS

2번 책만 주문한 사용자 리스트를 반환해 주세요!

상상만해도 이벤트를 모두 재생해서 2번 책만 주문한 사용자 리스트를 반환하는 일이 오래걸릴 것 같다는 느낌이 들죠? 그래서 CQRS는 이벤트 소싱과 궁합이 좋다고 하네요.

CQRS(Command and Query Responsibility Segregation)는 상태를 변경하는 Command와 조회를 담당하는 Query를 Object 혹은 시스템 단위로 분리시키는 것을 말합니다.

결론

TODO

  • 샘플 프로젝트를 구현 w/ Scala

참고자료

--

--

programming x writing

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store