원문 : https://martinfowler.com/eaaDev/EventSourcing.html

마틴 파울러 님은 번역에 대한 별다른 제제를 두지 않으셨습니다.

참고용 및 공유 용으로 번역해서 포스팅합니다.

모든 이미지는 마틴 파울러님의 원문으로 부터 가져왔습니다.

(번역에 대한 링크: https://martinfowler.com/faq.html)

이번 자료는 추가적인 예제 코드(C#)가 있으니 궁금하신 분은 원문을 참조하시면 좋습니다.

[] 표기는 각 표현에 대한 링크입니다.

Event Sourcing

이벤트 소싱은 2000년대 중반에 작성한 Further Enterprise Application Architecture development의 일부이다.

유감스럽게도, 그 이후로 신경쓸 것들이 많아졌기 때문에, 이것과 관련된 작업들을 하거나, 변화들을 예측하는데 충분한 시간을 쓸 수 없었다.

그렇기 때문에, 이 자료들은 충분한 시간이 생길 때 까지는 수정 및 업데이트 하지 않고 초안 상태로 있을 예정이다.

우리는 현재 상태를 알기위해 애플리케이션의 상태를 조회 할 수 있는데, 조회 결과는 많은 질문에 대한 답을 해준다.

하지만, 우리는 단순히 지금의 상태만 알고 싶은 것이 아니라, 어떻게 현재 상태가 됐는지 알고 싶은 경우도 있다.

이벤트 소싱을 통해 애플리케이션 상태의 모든 변경 사항은 일련의 이벤트로 저장되고, 이러한 이벤트를 조회만 하는 것이 아니라, 이벤트 로그를 통해 과거의 상태를 재구성 하거나 이전 상태에 대한 변경을 자동으로 적용하기 위한 토대로 사용할 수 있다.

이벤트 소싱( Event Sourcing )의 작동 방식

이벤트 소싱의 기본 개념은 애플리케이션 상태의 모든 변경사항이 이벤트 객체에 저장되고, 애플리케이션의 상태와 동일한 생명주기를 가지고 적용된 순서대로 저장된다는 것이다.

해운 배송에 대한 알림에 대한 간단한 예시를 들어보자.

많은 배가 바다에 나가있고 우리는 배들이 어디에 있는지 알 필요가 있다.

이 예시를 해결하는 간단한 방법은 배의 출항과 도착을 알려주는 기능을 가진 추적 애플리케이션을 만드는 것이다.

1: 선박운행 추적을 위한 간단한 인터페이스

이런 경우에 Tracking 서비스는 호출되는 시점에 연관있는 배들을 찾고 배의 위치를 업데이트 한다.

Ship 객체는 현재 업데이트된 ship의 상태를 저장한다.

이벤트 소싱을 사용하면, 위의 프로세스에 단계가 추가된다.

이제 Tracking 서비스는 배의 상태를 업데이트 하고 변경 사항을 저장하기 위한 이벤트 객체를 생성한다.

2: 변화를 감지하기 위해 이벤트를 사용하는 경우

프로세스만 보면, 단순히 불필요한 간접 계층을 추가한 것으로 보인다.

흥미로운 차이점은 프로세스가 아니라, 애플리케이션에 몇번의 연속된 변경 사항이 발생한 경우이다.

간단한 변경사항들을 상상해보자

‘King Roy’ 선박은 샌프란시스코에서 출항했다.
‘Prince Trvor’ 선박은 LA 에 도착했다.
‘King Roy’ 선박은 홍콩에 도착했다.

최초의 Tracking 서비스를 사용하면, ship 객체에 마지막 상태만 기록돼있다는 것을 알 수 있다.

이런 상태를 애플리케이션의 상태라고 표현해보자.

3: 몇번의 운항을 진행한 애플리케이션 상태(이벤트 소싱을 적용하지 않음)

이벤트 소싱을 사용하면, 각 이벤트를 저장할 수 있다.

영속성 저장소를 사용하는 경우 ship 객체와 같이 이벤트도 영속성을 가지게된다. 이런 경우 영속성으로 저장되는 두 가지를 애플리케이션의 상태와 이벤트 로그로 나누어서 표현하는 것이 더 유용하다.

4:몇번의 운항을 진행한 애플리케이션 상태(이벤트 소싱을 적용)

이벤트 소싱을 사용하면 변경 사항들에 대한 로그를 가질 수 있게 된다.

단순히 선박의 현재위치를 아는 것이 아니라, 어떤 경로로 현재 위치에 왔는지도 알 수 있다는 의미다.

하지만, 이건 아주 작은 부분이다.

이벤트 소싱을 사용하지 않더라도 Ship 객체에 지나온 항구에 대한 이력을 남기거나, 선박이 이동하는 시점에 로그를 남기기만 해도 상태의 변화를 알기에 충분한 이력을 가질 수 있다.

이벤트 소싱의 핵심은 이벤트 객체를 통해서 도메인 객체의 모든 변경사항이 발생한다는 점이다.

이로 인해 이벤트 로그를 기반으로 여러 기능을 추가하는 것이 가능해진다.

Complete Rebuild:
기존 애플리케이션 상태를 완전하게 버리고 비어있는 애플리케이션에서 이벤트 로그에 남아있는 이벤트를 다시 실행하는 것만으로 발생한 이벤트 들을 재구성 할 수 있다.
Temporal Query:
애플리케이션의 상태를 어느 시점이든 관계 없이 변경 할 수 있다. 아무것도 없는 상태로부터 특정시점의 상태 또는 특정 이벤트까지 다시 실행하는 개념으로 작동한다. 버전 관리 시스템과 같이 여러 시간대를 고려해 발전 시킬 수 있다.
이벤트 재실행:
과거의 이벤트가 잘못된 것을 발견하는 경우, 잘못된 이벤트와 이후에 발생한 이벤트를 되감고 새로운 이벤트와 이후에 발생한 이벤트를 재생해서 결과를 계산 하거나 애플리케이션의 현재 상태를 버리고 올바른 순서로 모든 이벤트를 재생할 수 있다.
비동기 메세지 시스템을 사용할 때 이벤트를 잘못된 순서로 받아서 생기는 문제도 같은 방법으로 해결 할 수 있다.

이벤트 소싱을 사용하는 애플리케이션의 일반적인 예시는 버전 관리 시스템이다.

이런 시스템은 Temporal Query를 꽤나 자주 사용한다.

서브 버젼은 사용자가 덤프나 복원을 사용해 저장소 파일간에 항목을 이동할 때마다 완전히 재 구축하는 방식을 사용하는데 특별한 관심을 가지지 않게된 정보들에 대해 이벤트 재생을 하는지는 모른다.

이벤트 소싱을 하는 엔터프라이즈 애플리케이션은 드물지만, 일부 애플리케이션은 부분적으로 또는 전체적으로 사용하기도 한다.

애플리케이션 상태 저장소

이벤트 소싱을 사용하는 가장 단순한 예시는 애플리케이션 상태에 대한 요청을 받았을 때 아무것도 없는 상태부터 요청한 상태까지 이벤트를 적용하는 방법이다.

그렇기 때문에 이런 처리가 느리게 이뤄지는 이유를 (특히 이벤트가 많은 경우) 쉽게 알 수 있다.

많은 애플리케이션에서 가장 최근 애플리케이션 상태를 요청하는 것이 일반적이다.

그렇다면, 더 빠른 대안은 현재 상태를 저장하고 이벤트 소싱에서 제공하는 특수한 기능이 요구되는 요청에 추가적인 기능을 더하는 것이다.

애플리케이션 상태는 disk와 메모리 모두에 저장될 수 있다.

애플리케이션 상태를 이벤트 로그로 추측할 수 있다면 어디에 캐싱 해도 상관 없다. 업무 일에 사용하는 시스템은 업무 시작 시간에 야간 스냅샷에서 시작해서 현재 애플리케이션 상태까지 메모리에 유지 하고 충돌이 발생하는 경우 야간에 저장된 이벤트들을 다시 실행할 수 있다.

업무 시간이 끝날때 해당 시점의 상태를 기준으로 새로운 스냅샷을 만든다. 새로운 스냅샷은 실행중인 애플리케이션을 중단하지 않고 언제든 동시에 만들 수 있다.

애플리케이션의 현재 상태나 이벤트 로그 모두 시스템의 공식적인 기록일 수 있다.

만약 현재 애플리케이션 상태가 데이터베이스에 유지된다면 이벤트 로그는 특별한 처리나 변경 사항을 기록하기 위해서만 사용하게 된다. 이벤트 로그가 공식적인 기록이 된다면 데이터베이스는 자료가 필요한 어떤 때라도 재구축 될 수 있다.

이벤트 핸들링 로직의 설계

이벤트를 헨들링하는 로직을 어떤 곳에 놓을지 여러 선택지가 있다.

주로 선택하는 방식은 트랜잭션 스크립트 또는 도메인 모델에 넣는 것이다.

[트랜잭션 스크립트: Transaction Scripts]
[도메인 모델: Domain Model]

일반적으로 단순한 로직에는 트랜잭션 스크립트가, 복잡해지는 경우에는 도메인 모델이 더 나은 방법이 된다.

일반적으로 이벤트나 커맨드를 통해 변경 사항을 발생시키는 경우 트랜잭션 스크립트를 사용하는 경향이 있는데, 일부 사람들은 이벤트 소싱을 사용하는 시스템이 반드시 이런 방식을 사용해야 한다고 믿는다.

하지만 그건 환상에 불과하다.

더 나은 문제 해결방식은 두 가지의 책임이 포함되어 있다고 생각하는 것이다. 도메인 로직의 처리(Processing Domain Logic)는 애플리케이션을 조작하는 비즈니스 로직이고, 조회 로직의 처리(Processing Selection Logic)는 들어오는 이벤트에 따라 처리해야 하는 도메인 로직의 처리들을 결정하는 것이다.

두 가지의 책임을 한곳에 묶어 낼 수 있는데, 근본적으로 이런 방식이 트랜잭션 스크립트의 접근 방식이다.

또한 이벤트 처리 시스템에 조회 로직을 처리하는 부분을 넣고 도메인 로직을 처리하는 메소드를 가진 도메인 모델을 호출하는 것을 통해 두 책임을 분리할 수 있다.

책임을 분리하는 방식을 사용하기로 결정하고 나면 이벤트 객체에 조회 로직의 처리를 삽입하거나 별도의 이벤트 처리 객체를 만들지 결정해야 한다.

다만 별도의 이벤트 처리 객체를 사용하게 되면 이벤트 타입별로 다른 로직을 수행해야 하는데 이런 타입 변경은 객체지향이 추구하는 방식에서 혐오스럽게 생각하는 방식이라는 문제가 있다.

모든 것이 동일하다면 이벤트 자체에 조회 로직의 처리를 하고자 하는데, 이로 인해서 이벤트 처리의 타입이 달라진다. 물론 모든것이 언제나 같을 수는 없다.

별도의 처리 객체를 생성하는게 납득가능한 한 가지 예시는 이벤트 객체가 이벤트 내부에 코드를 작성하는 걸 금지해주는 자동화 방식을 통해 직렬화 되고 역직렬화 되는 DTO인 경우다.

[ DTO]

이런 경우 이벤트에 대한 조회 로직을 처리할 방법을 찾을 필요가 있다. 나는 가능한한 이런 상황을 피하려고 하는 경향이 있는데 어쩔 수 없는 경우라면 DTO를 이벤트의 숨겨진 데이터 홀더로 다루고 이벤트는 일반적인 다형성 객체로 다루자.

이런 경우에는 직렬화된 이벤트 DTO들을 설정 파일을 사용하거나 더 나은 네이밍 컨벤션을 통해 이벤트와 일치시키는 것이 현명하다.

이벤트를 되돌릴 필요가 없는 경우 이벤트 로그와 무관한 도메인 모델을 만들기 쉽다.

리버싱 로직을 사용해야 하는 경우 도메인 모델은 이전 상태를 저장/조회 하게 되면서 복잡해지는데, 이로 인해서 도메인 모델이 이벤트 로그에 의존성을 가지게 되는 상황이 쉽게 일어난다.

이벤트 되돌리기

이벤트는 앞으로 진행될 이벤트만이 아니라 이벤트를 되돌리는 것에도 유용하다.

되돌리기가 가장 쉬운 상황은 이벤트가 차이점을 기록하는 형식일 때이다.

예를 들어보자.

‘Martin의 계좌에 10$를 더한다’

반대로 ‘Martin 의 계좌에 110$를 저장한다’

첫 번째 경우에는 $10을 빼는 것만으로 되돌 릴 수 있지만, 두 번째 경우에는 계좌의 이전 상태에 대한 충분한 정보가 없다.

만약 들어오는 이벤트가 차이점을 남기는 방식이 아니라면, 이벤트를 되돌리기 위해서는 처리되는 과정의 모든 것들이 저장돼야 한다.

이런 상황에서는 어떤 값이던 변경된 모든 값의 이전 값을 저장하거나, 이벤트에 차이점 들을 계산하고 저장하는 방법을 사용할 수 있다.

이런 저장을 위한 요구조건은 도메인 모델에 처리로직이 있고 내부 상태를 변경하는 방법이 이벤트 객체의 처리에 노출 되지 않아야 한다는 중요한 결과를 발생시킨다.

이런 경우 도메인 모델에게 이벤트의 이전 상태 정보를 저장하는 목적으로 이벤트를 노출시키는 방식이 가장 좋은 설계이다.

다만, 과거의 스냅샷으로 되돌리고 일련의 이벤트를 다시 실행하는 것으로도 이벤트를 되돌리는 것과 같은 기능을 할 수 있다는 것을 기억하자.

결론적으로 되돌리기는 기능상 절대적으로 필요한 것은 아니지만, 몇몇 이벤트를 되돌리는 것이 많은 이벤트를 재생 하는 것보다 효율적이다.

외부 업데이트 (External Update)

이벤트 소싱의 복잡한 부분중 한가지는 같은 방식을 사용하지 않는 외부 시스템과 소통하는 방법이다. 그리고 대부분 같은 방식을 사용하지 않는다.

외부 시스템에게 변경 메세지를 보내고 다른 시스템에게 조회 메세지를 받는 경우 문제가 발생한다.

이벤트 소싱의 많은 이점은 이벤트의 재생이 자유롭다는 것에서 시작되는데, 이런 이벤트들이 업데이트 메세지를 외부 시스템에게 전송하는 경우 외부 시스템이 다시 재생하는 것과 실제 처리를 구분하지 못하기 때문에 많은 부분들이 잘못될 수 있다.

이런 상황을 해결하기 위해서는 외부 시스템들을 게이트웨이로 묶어야 한다.

[게이트웨이: Gateway]

이 방식은 번거롭지도 않고 어떤 경우에든 좋은 아이디어다.

게이트웨이를 이벤트 소싱에서 수행하는 재 실행 처리와 함께 사용하기 위해서는 조금 더 복잡해질 필요가 있다.

재구축이나 임시쿼리는 재실행 처리중에 게이트웨이를 비활성화 할수 있는것으로 충분하다. 아마도 이런 처리를 도메인 로직은 모르게 처리하고 싶을것이다.

예를 들어 도메인 로직이 PaymentGateway.send 함수를 호출하면 재 실행 중인 상태와는 무관하게 작동하길 바란다.

게이트 웨이는 이벤트 처리자에 대한 정보를 기반으로 외부와 연결하기 전에 현재 상태가 재 실행 모드인지 아닌지 판단한다.

외부 업데이는 소급 이벤트 와 함께 사용하면 더 복잡해지는데 자세한 내용은 링크를 참조하자.

[소급 이벤트 : Retroactive Event]

외부 시스템을 다루는 다른 전략은 외부에 대한 알림에 시간단위로 버퍼링을 넣는 것이다.

외부 알림을 바로 생성하지 않는 대신에 월말에만 알림을 생성 하면 된다.

이런 경우에는 알림을 보내는 시간이 되기 전까지 한층 더 자유롭게 재 실행을 처리할 수 있다. 또한 두 방법 모두를 사용해서 외부로 전송되는 메세지를 배포되는 시점까지 게이트웨이에 저장하거나, 알림을 바로 발송하는 대신 알림 도메인 이벤트를 통해 외부로 전송되는 메세지가 발행되게 할 수 있다.

외부 쿼리

외부 쿼리의 주된 문제는 외부 쿼리를 통해 가져오게 되는 데이터는 제어하고 있는 이벤트의 결과에 영향을 미치게 된다는 것이다.

예를 들어 12월 5일에 환율을 요청하고 12월 20일에 해당 이벤트를 다시 실행 하면 가장 최근의 환율이 아니라 12월 5일의 환율이 필요하다.

물론 이전의 특정한 날짜와 함께 외부 시스템에 요청하면 알맞은 값을 돌려줄 것이다.

그리고 이게 가능하다면 이런 방식을 사용해 일관된 리플레이를 보장할 수 있다.

또한 변경 이력을 유지하면 이벤트 콜라보레이션을 사용할 수 있다.

만약 이런 단순한 계획들을 적용 할 수 없는 경우에는 뭔가 좀 더 필요하다.

한 가지 접근 방법은 외부 시스템에 대해 쿼리에 대한 응답 결과를 저장하고 리플레이에 사용할 수 있게 하는 게이트웨이를 설계하는 것이다.

좀 더 명확하게 말하자면 모든 외부 쿼리에 대한 응답은 기억될 필요가 있다.

만약 외부의 데이터가 천천히 변한다면 값이 변경된 경우에만 저장하는 것이 합리적이다.

외부와의 상호 작용

이벤트 소싱을 사용하면서 외부 시스템에 쿼리, 업데이트를 하는 건 많은 복잡성을 발생시킨다. 쿼리와 업데이트 모두를 수행하는 상호 작용은 최악의 상황을 만든다.

예를 들면 배송에 대한 주문을 제출하고 주문에 대한 배송 정보를 반환하는 경우와 같이 외부 시스템에 쿼리를 통해 결과를 가져오고 상태를 변경시키는 상호 작용이 그러하다.

코드의 변경

지금까지 한 논의 에서는 이벤트를 처리하는 애플리케이션이 동일하게 유지했지만 실제로 그렇지 않는다.

이벤트는 데이터 변경을 제어한다. 그렇다면 코드의 변경은 어떨까?

신규 기능, 기간에 따른 로직 그리고 버그 수정 이렇게 3가지 정도로 코드 변경의 이유를 생각해 볼 수 있다.

신규 기능은 시스템에 새로운 기능을 추가하지만 이전에 있었던 상황들을 검사하지 않는데, 이런 사항들은 언제든 꽤나 자유롭게 추가할 수 있다.

신규 기능의 영향을 오래된 이벤트가 받았으면 한다면, 단순히 이벤트를 재 실행 하고 새로운 결과들을 수용하면 된다.

신규 기능을 도입한 뒤에 재 실행하는 경우 일반적으로 외부 게이트웨이를 꺼야 할 것이다.

예외적인 상황은 신규 기능에 이런 게이트웨이가 포함된 경우다.

아무리 이전 이벤트 들을 알리지 않고 싶어도 이런 경우에는 최초로 이전 이벤트들을 재 실행 할 때 특별한 처리가 필요하다.

약간 더러워 보이기도 하지만 딱 한 번만 필요하다.

버그 수정은 이전의 처리가 잘못되었다는 것을 알게 될 때 발생한다. 내부의 버그는 수정하기 매우 쉽다. 버그를 수정하고 이벤트를 다시 처리하면 된다.

이제 애플리케이션의 상태는 원래 올바른 상태로 돌아왔다. 대부분의 경우에 이런 방식이 가장 좋다.

하지만 외부 시스템 게이트 웨이는 일을 복잡하게 만든다.

게이트 웨이는 필수적으로 버그가 있을 때 발생한 결과와 온전한 상태일 때 발생하는 결과 사이의 차이점을 알아야 한다.

작동 방식에 대한 아이디어는 소급 이벤트를 사용할 때와 유사하다.

실제로 다시 처리 할 때 고려사항이 많아지는 경우 버그가 있는 이벤트가 올바른 이벤트처럼 되돌릴 수 있는지 확인하고 소급 이벤트의 메커니즘을 사용해 버그가 있는 이벤트를 수정된 이벤트로 대체하는 것이 좋다.

3 번째 경우는 “11월 18일 이전에는 $10을 청구하고 이후에는 $15를 청구한다”와 같이 시간에 따라 로직이 변하는 경우다.

이런 종류는 도메인 모델 내부로 들어가야 한다. 도메인 모델은 언제나 올바른 규칙을 기반으로 이벤트를 처리할 수 있어야 한다. 조건부 로직을 사용해서 이런 상황을 해결 할 수는 있지만 많은 시간 기준에 따른 로직이 생기면 금세 엉망이 되버린다.

더 나은 방식은 chargingRules.get(adata).process(anEvent) 와 같은 형식으로 전략 객체를 시간적 속성(Temporal Property)에 연결하는 것이다.

이런 형식에 대한 추가적인 정보는 Agreement Dispatcher 링크를 확인해보자

[시간적 속성: Temporal Property]

오래된 이벤트가 버그가 있는 코드를 통해 처리됐다면 시간에 따른 로직과 버그를 해결하는 방법 사이에는 겹치는 부분이 있을 가능성이 있다. 이런 상황에서는 두 가지 시간선을 따라 행동하는 경우가 있을 수 있는데 예를 들면 특정 이벤트를 10월 1일에 있었던 8월 1일의 규칙으로 되돌리고, 현재 가지고 있는 8월 1일에 대한 규칙으로 대체 하는 경우가 있을 수 있다. 하지만 이런 방식을 사용하게 되면 지나치게 복잡해지거나 더러워지기 때문에 꼭 필요한 경우가 아니라면 사용하지 않는 것을 추천한다.

이런 이슈 가운데 일부는 데이터 내부에 코드를 넣는 것으로 해결할 수 있다. 객체의 설정을 통해 처리하는 동적 객체 모델(Adaptive Object Model)을 사용하는 것은 이런 문제를 해결하는 하나의 방법이다.

또 다른 방법은, 자바 애플리케이션 내부에 JRuby를 삽입하는 것처럼 데이터 내부에 컴파일 필요하지 않은 스크립트 언어를 데이터 내부에 담는 것이다.

물론 적합한 설정을 지속적으로 제어해줘야 한다는 위험성이 있다. 다만, 스크립트를 통해서 처리되는 모든 변경사항은 다른 업데이트 들과 마찬가지로 이벤트를 통해 처리 되는 것이 좋다.

(하지만 나는 여전히 관찰과 추측 사이에서 혼란을 겪고 있다.)

이벤트와 계좌 (Event And Accounts)

역자: 정확한 의미를 위해 Account 링크를 참조 해주세요

이벤트 소싱과 그에 따른 패턴에 대해 강조되는 예시는 계좌 시스템에서 찾아볼 수 있다.

이 두 가지는 요구 사항 (특히 계좌 시스템에서 중요한 이력) 과 구현 에서 좋은 시너지를 보인다.

여기서 가장 중요한 부분은 도메인 이벤트의 모든 거래 결과가 Accounting Entrys를 만들고 이런 엔트리를 원래 이벤트에 링크할 수 있도록 정렬이 가능하다는 것이다.

[도메인 이벤트: Domain Event]

[ Accounting Entrys]

이런 방식은 변경 사항을 추적하고 되돌리는 등의 작업을 할때 좋은 기반이 되어주고, 특히 조정을 해야 하는 많은 부분들을 단순화 해줄 수 있다.

그렇기 때문에 계좌 거래에 대한 하나의 접근 방식은, Accounting Entys 는 Account 에 대한 모든 변경사항들을 기록하는 로그이고 Account 자체는 이벤트 소싱에 대한 하나의 예제라고 보는 것이다.

언제 사용해야 하는가?

애플리케이션의 모든 변경 사항을 이벤트로 묶는 것은 모두가 편해하지도 않고 많은 경우에 이상한 점을 찾을 수도 있는 방식이다.

이런 점을 보았을 때 이벤트 소싱을 선택하는 건 자연스러운 일은 아니며 사용했을 때 어떤 형식의 이점을 바란다는 의미다.

한 가지 명확한 이득은 이벤트를 Audit Log로 직렬화해서 남기기 쉽다는 점이다.

[ Audit Log]

이런 Audit trail은 이력 관리에 유용하고 별다른 충격을 주지 않고 여러가지로 활용도 가능하다.

한 번은 온라인 계좌의 상태가 이상해져서 도움을 요청하기 위해 전화를 한 사람과 얘기를 한 적이 있는데, 그는 도와주는 사람이 정확히 그가 어떤 것을 했고, 어떤 방식으로 고칠 수 있는 지 알려줬다는 것에 인상 깊었다고 한다.

이런 기능을 제공한다는 것은 서포트 그룹에게 이런 audit trail을 제공하고 사용자의 행동들을 알 수 있게 해줬다.

이벤트 소싱은 이런 것들을 할 수 있는 좋은 방법이지만, 여전히 기존의 로깅 방식으로도 동일하게 수행 할 수 있고 이런 것을 지원하기 위해 익숙하지 않은 방식을 배워가며 하지 않아도 된다.

Audit Log를 사용하는 다른 방식은 디버깅을 돕는 것이다. 물론 로그 파일을 상용 문제를 디버깅 하기 위해 사용하는 것은 오래된 방식이다. 다만 이벤트 소싱은 한 발 더 나아가 테스트 환경에서 발생한 이벤트 들을 다시 실행해 정확하게 어떤 일이 있었는지 확인하게 해주고 디버거에서 테스트를 실행할 때 처럼 중지, 되감기, 재생 기능을 제공해준다.

이런 방식은 특히 상용을 업데이트 하기 전에 평행하게 테스트 하는 방법들을 제공한다.

그렇기 때문에 정확한 이벤트들을 테스트 시스템 상에서 재생 시키고 원하는 값이 나오는지 테스트해 볼 수 있다.

이벤트 소싱은 Parallel Models 나 소급 이벤트의 토대가 된다.

[ Parallel Models]

만약 두 가지 패턴 모두를 사용하려고 하면 이벤트 소싱의 도입이 선행되어야 한다.

그래서 이벤트 소싱으로 이루어지지 않은 시스템에 두 가지 패턴을 도입 하려고 하는 경우 기존 시스템을 개조 하는 작업은 매우 어려워진다.

이런 이유는 나중에 리팩토링을 통해 이벤트 소싱을 추가하는 것은 현명하지 못한 경우 중 하나다.

이벤트 소싱은 아키텍쳐 전반에 몇가지 가능성을 만들어 내는데 특히 높은 확장성을 필요로 하는 경우에 적합하다.

최근에 이벤트 주도 아케텍쳐에 대해 상당한 관심이 있는데. 이 용어는 넓은 범위의 아이디어를 다루지만 대부분은 이벤트 메세지를 통해 통신하는 시스템을 중심으로 한다.

이런 시스템은 느슨하게 결합된 병렬 형식으로 운영돼 수평적인 확장성과 시스템 오류에 대한 탄력성을 제공한다.

많은 독자가 있고 소수의 작성자가 있는 시스템이 예시가 될 수 있다. 이벤트 소싱을 사용하게 되면 인 메모리 데이터베이스가 있는 시스템 클러스터로 제공될 수 있고 이벤트 스트림을 통해 최신 상태를 공유한다. 업데이트가 필요한 경우 업데이트를 단일 마스터 시스템 (또는 단일 데이터베이스 또는 메시지 큐 주변의 더 강력한 서버 클러스터)으로 라우팅하여 업데이트를 레코드 시스템에 적용한 다음 결과 이벤트를 더 광범위한 독자 클러스터로 브로드 캐스트 할 수 있다.

레코드 시스템이 데이터베이스에서 응용 프로그램 상태 인 경우에도 매우 매력적인 구조가 될 수 있다.

레코드 시스템이 이벤트 로그인 경우, 이벤트 로그는 최소한의 잠금(lock)이 필요한 유연한 구조이기 때문에 높은 성능을 위한 다양한 옵션이 있을 수 있다.

당연히 이런 아키텍쳐가 완벽하지는 않다. 구독 시스템은 마스터 또는 다른 작성자와 동기화가 끊어지면 이벤트의 발생과 현재 구독 시스템의 데이터 간의 시간적 차이에 의존성을 가지고 있다.

그럼에도 이런 브로드캐스팅 방식의 아키텍쳐는 사용되고, 대부분 긍정적인 평가를 한다.

이런 이벤트 스트림은 새로운 애플리케이션이 독자적인 모델을 사용하더라도 쉽게 수용가능하다.

통합에 대한 메시징 접근 방식에 매우 적합한 접근 방식이다

[번역] Event Sourcing — 마틴 파울러

댓글