Event Sourcing(1)
- Event Sourcing(이벤트 소싱) 일주일 공부하고 정리한 글
이 글은 이벤트 소싱에 대해서 지난주부터 공부한 내용을 아주 간략하게 정리한 글입니다. 저는, 이벤트 소싱으로 프로젝트를 진행해본 적도 없고, 이벤트 소싱 패턴의 개념에 대해서 100% 알지 못합니다. 그러므로, 제 글에 잘못된 내용이 있을 수 있으니 주의 부탁드립니다. 제 글이 너무 기초적인 내용이라서 쉽게 느껴지신다면 지난 2017년 스프링 캠프 영상을 참고하길 바랍니다. by eddy.kim 2018-11-27 퇴근 후 집에서 후딱 작성
https://www.youtube.com/watch?v=TDhknOIYvw4
https://www.youtube.com/watch?v=12EGxMB8SR8
Event Sourcing & CQRS
Event Sourcing 과 CQRS 에 대해서 간략하게 필자의 예시를 바탕으로 소개한다.
Event Sourcing(이벤트 소싱)
Event Sourcing(이벤트 소싱)이란 소프트웨어 또는 애플리케이션의 이벤트 로그(상태에 대한 변경사항)을 모두 저장하는 개발 아키텍처 패턴이다. 기본 개발 방법으로는 현재 상태만 확인할 수 있었지만, 이벤트 소싱 패턴을 적용한다면 모든 갱신 이력(이벤트 로그)를 저장하고 해당 로그를 추적하여 과거 상태로 재구성 할 수 있다. 간단한 예로, 온라인 포털에서 뉴스 기사를 서비스 하는 프로세스를 생각해보자.
포털에서 뉴스 기사를 서비스하기 위해서는 언론사로 부터 뉴스 메타 데이터를 전달 받아야 한다. 이 글의 예시에서는 언론사에서 XML 데이터로 전달해준다고 가정해보자. XML 데이터를 그대로 웹서비스 할 수 없기 때문에, 데이터를 가공하는 과정이 필요하다.(실무에서는 파싱 이라는 용어를 사용한다.) 가공된 데이터는 저장소에 저장되고, 웹서비스에서는 해당 저장소를 조회하여 사용자에게 제공한다. 하지만, 해당 기사의 상태에 대한 변경이 필요한 경우에 CMS(컨텐츠 관리 툴) 에서 상태를 변경한다. 예를 들어서 사용자에게 노출되면 안되는 기사인 경우에는 CMS 에서 비활성화(INACTIVE) 처리를 할 수 있다. 또는, 언론사로부터 받은 데이터가 깨져서 나온다면, CMS 에서 깨진 데이터를 수정하여 저장소에 저장할 수도 있다.
참고로 필자의 예시는, 가상의 환경으로 매우 심플하게 이해할 수 있는 구조이다. 하지만, 실제로 실무에서는 좀 더 복잡한 구조로 되어 있다. 물론, 캐싱 및 방어로직이 잘 적용된 시스템으로 고가용성으로 구축이 되어있을 것이다. 이벤트 소싱을 설명하기 위한 샘플 예시임을 알아두길 바란다.
뉴스 기사를 여러 번 변경을 했다고 가정해보자. 변경사항을 현재 구조에서 다 알 수 없고, 최종 데이터만 확인 할수가 없다. 만약, 실수로 관리자가 데이터를 잘못 변경했다면 어떻게 될까? 변경 전 데이터를 알 수 없다면 전 상황으로 되돌릴 수가 없게 될 것이다.
이벤트 소싱 패턴으로 개발한다면, 모든 이벤트 로그를 저장소에 저장한다. 즉, 비즈니스 이벤트 흐름을 모두 저장하는 것이다. 아래 필자의 허접한 그림을 참고하자.
뉴스 id 가 1인 기사에 대한 이벤트 로그는 아래와 같다.
언론사로부터 수신(Read) --> 포털서비스에 맞게 가공(파싱, Process) --> 데이터 편집(Update) ...
이벤트 로그를 저장하는 저장소는 매우 심플한 스키마로 구성되어 있다.
뉴스 기사를 식별할 수 있는 article id
어떤 이벤트 타입인지 확인 할 수 있는 event type
해당 이벤트에 필요한 데이터로서 event data
자... 이제 웹서버에서 1번 기사를 사용자에게 보여주기 위해서는 어떻게 하면 될까? 아주 쉽다. article id 가 1인 이벤트 로그를 전부 조회한 다음에, 해당 이벤트 순서를 참고해서 만든 최종 뉴스 기사를 사용자에게 보여주면 된다.
근데 뭔가 이상하다. 이벤트 로그를 저장하는 저장소에 겁나게 많은 쌓여 있는 상황이다. 또한 조회하고 싶은 1번 뉴스 기사를 수십번 변경했다고 가정하자. 수십번 변경한 모든 이벤트 로그를 가져와서 최종 뉴스 기사를 만드는 작업이 너무 비효율적이다. 모든 로그를 가져오는 것이 너무 비효율적이니, 중간중간에 로그를 쌓아놓은 정보를 조회하는 것이 훨씬 빠를 것이다. 이벤트 소싱에서는 SNAPSHOT(스냅샷) 라는 용어를 사용한다.
근데...그래도 뭔가 찝찝하다. 이벤트 로그는 정말 미친듯이 많이 쌓여있을 것이다. 실서비스 환경으로 구축하기에는 너무 부담스럽기는 하다. 그래서 나오는 개념이 CQRS 이다. 이벤트 소싱 패턴에 거의 항상 같이 따라오는 패턴이다.
CQRS
CQRS 패턴은 명령과 쿼리를 분리, 즉 데이터를 업데이트 하는 작업과 데이터를 읽는 작업을 분리하는 패턴이다. 시스템의 성능을 향상시키고, 확장성 및 보안을 극대화 할 수 있다. 높은 유연성을 통해 시간이 지남에 따라 시스템이 진화하도록 지원하고, 업데이트 명령으로 인해 도메인 수준에서 병합 충돌이 발생하지 않도록 방지한다... 라고 MSDN 에 설명이 잘 되어있다. 꼭 읽어보자.
https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs
아래 MSDN 에 그림을 참고해서 보자.
https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs참고로 읽기 저장소 와 쓰기 저장소는 전혀 다른 구조일 수도 있다. 비즈니스 환경에 따라서 적절하게 구축하면 된다. 그럼, 필자의 예시를 바탕으로 CQRS 패턴을 이벤트 소싱 패턴에 적용해보자. 이벤트 로그는 그대로 쌓아두고, 구조화된(?) 데이터를 별도의 저장소에 저장을 하자.
필자는 NoSql 에 Json Document 타입으로 저장을 하였다. 웹서비스에서는 article id 를 쿼리로 조회하면 된다. 이벤트 로그를 매번 조회할 필요 없이, 이미 만들어져 있는 구조화된 데이터를 조회하여 사용하면 되는 것이다.
여기까지 내용은 인터넷 자료와 발표 영상 등을 참고해서 객관적인 시각으로 작성한 글이다. 필자는 이벤트 소싱에 대해서 대략적인 개념은 이해가 되었지만, 실제로 구현을 어떻게 해야하는지는 잘 모르겠다. 아직은 너무 어려운 이벤트 소싱 패턴 ㅠㅠ
글 대충 마무리...
급하게 글을 마무리 하려고 한다. 필자의 지극히 개인적인 생각을 정리 중인데, 생각에 대한 검증이 필요한데... 주변에 이벤트 소싱에 대해서 알고 있는 개발자가 단 1명도 없어서 좀 많이 어렵다.
개인적으로 최근에 봤던 아키텍처 중에서 이벤트 소싱에 제일 어려운 것 같다... ㅠㅠ
메시지 이벤트 기반 아키텍처
필자는 메시지 이벤트 기반 아키텍처에 관심이 많은 편이데, 실제로 실무에 도입한 사례는 몇 번없다. 메시지 패턴 아키텍처를 잘못 구현하면 시스템 복잡도가 배로 증가한다. 또한, 트랜잭션 처리 및 모니터링, 분산 환경 로그 모니터링 등 개발 난이도가 꽤 높은 편이다. 마이크로서비스 환경에서 메시지 패턴을 도입하는 설계를 몇달 동안 고민해왔는데, 해결하지 못한 숙제가 있었다. 바로, 분산 시스템 환경에서 복잡한 비즈니스 로직에 대한 프로세스 매니징을 어떻게 할지에 대해서다. 필자가 처음에 생각했던 아키텍처는 아래와 같다.
기업통합패턴 376 page메시지 패턴 아키텍처에서, 프로세스 관리자를 중앙에 두는 아키텍처이다. 프로세스 관리자의 주요 기능은 메시지들 사이의 상태를 유지하는 것이다. 물론 해당 아키텍처가 항상 정답은 아니다. 반드시 시스템 환경과 비즈니스 요구사항에 잘 맞아야 한다. 해당 아키텍처를 고민중에, 이벤트 소싱을 도입하면 좋겠다는 생각을 하게 되었다. 마이크로서비스 환경에서 분산된 애플리케이션(컴포넌트) 또는 도메인 기반으로 나눠진 마이크로 서비스 에서 실행하는 모든 이벤트 로그를 저장하고 관리할 수 있다면, 프로세스 관리자로서의 역할을 이벤트 소싱 패턴으로 구현할 수도 있을 것 같다는 생각이다. 지극히 필자의 개인적인 생각이다.
어쨋든 너무 어려운 주제이고, 지금 이 글을 쓰고 있는 지금, 너무 시간이 늦었고 출근해야 하기 때문에 이만 급하게 글을 마무리 하려고 한다. 다음 돌아오는 주말에는 이벤트 소싱 패턴을 도입할 수 있는 프레임워크를 알아보려고 한다. Lagom Framework , Axon Framework 등 실무에서 사용 가능한 오픈소스 프레임워크를 알아보고, 스프링 환경에 통합이 가능한지 함께 알아볼 예정이다. 끝...
