이벤트 소싱 & CQRS(Command Query Responsiblity Segregation)
이벤트 소싱은 2005년에 Martin Fowler가 자신의 홈페이지에서 언급한 용어인데, 한 마디로 정의하자면 데이터를 저장하는 새로운 패턴이다.(새로운 패턴이지만 오래됐다)
이 방식은 어플리케이션의 모든 상태 변화를 순서대로 이벤트로 보관하여 처리하는데, 이렇게 모든 상태를 이벤트의 흐름으로 처리하므로서 어플리케이션 개발을 간소화(?)하고 분산 환경에 적절이 대응할 수 있는 개념이다.
MSA(Microservice Architecture) 방식으로 구현된 각 서비스들은 별도의 저장소를 사용하는 경우가 많은데, 필요에 따라 분산돼있는 데이터를 일치시키거나 한 개의 요청에 대해 여러개의 서비스가 연동되어 동작해야되는 경우가 많다.
이는 곧 Transaction 문제로 귀결되게 된다.
거대한 분산 시스템에 모놀리틱 시스템처럼 Strong Consistency를 지닌 Transcation을 사용하는 것은 불가능
그래서 등장한 것이 Eventually Consistency
당장은 아니지만 언젠가는 일관성이 유지되는 것을 뜻함
대부분의 경우에서 바로바로 일관성이 유지되는 Strong Consistency를 필요로 한다고 생각할 수 있지만, Strong Consitency를 주로 사용하는 모놀리틱 시스템도 요청 시점과 결과 View 시점의 데이터가 완전하게 동일하다고 보장할 수 없음
ex) Master DB에 게시물 등록 -> Slave DB에서 게시물 조회 -> 아직 Replicate 되지 않아서 등록한 게시물이 보이지 않음
Eventually Consistency는 어쩔 수 없는 상황에서의 선택이기 때문에, Strong Consitency와 장단점을 비교하는 것은 무의미함
Eventually Consistency를 유지하는 방식
재시도: 서비스 수행 도중 특정 서비스에서 작업을 실패했을 경우, 해당 정보를 보관하고 있다가 재시도(주로 쓰임)
전체 작업 실패: 작업을 실패한 서비스 뿐 만 아니라 일관성이 유지돼야하는 이전 작업 수행 서비스들도 모두 실패로 처리(실패 처리는 재시도보다 매우 복잡함)
위의 일관성을 유지하기 위해서는 모든 작업을 하나의 단위로 정의해야하고, 그 단위를 기반으로 Service 환경을 구축해야함
이벤트 소싱(Event Sourcing) 소개
이벤트 소싱 & CQRS(Command Query Responsiblity Segregation)
이벤트 소싱은 2005년에 Martin Fowler가 자신의 홈페이지에서 언급한 용어인데, 한 마디로 정의하자면 데이터를 저장하는 새로운 패턴이다.(새로운 패턴이지만 오래됐다) 이 방식은 어플리케이션의 모든 상태 변화를 순서대로 이벤트로 보관하여 처리하는데, 이렇게 모든 상태를 이벤트의 흐름으로 처리하므로서 어플리케이션 개발을 간소화(?)하고 분산 환경에 적절이 대응할 수 있는 개념이다.
Aggregate란 무엇인가?(아래 링크 문서에서 자꾸 언급되는 개념) 이벤트 소싱 & CQRS에 대한 심천보님의 스프링 캠프 발표 자료
Event Driven Microservices
MSA(Microservice Architecture) 방식으로 구현된 각 서비스들은 별도의 저장소를 사용하는 경우가 많은데, 필요에 따라 분산돼있는 데이터를 일치시키거나 한 개의 요청에 대해 여러개의 서비스가 연동되어 동작해야되는 경우가 많다. 이는 곧 Transaction 문제로 귀결되게 된다.
참고