데이터의 현재 상태만 저장하는 대신 추가 전용 저장소를 사용하여 해당 데이터에 수행된 전체 작업을 기록합니다. 이렇게 하면 데이터 모델과 비즈니스 도메인을 동기화할 필요가 없고 성능, 확장성 및 응답성이 향상되므로 복잡한 태스크를 간소화할 수 있습니다. 또한 트랜잭션 데이터에 일관성을 제공하고 보정 작업에 사용할 수 있는 전체 감사 추적 및 기록을 유지할 수 있습니다.
기존 CRUD를 이용한 접근 방법
대부분의 응용 프로그램은 데이터로 작업하며, 일반적인 방법은 사용자가 작업할 때 데이터를 업데이트하여 데이터의 현재 상태를 유지 관리하는 것입니다. 예를 들어 기존의 CRUD(Create, Read, Update, Delete) 모델에서 일반적인 데이터 프로세스는 저장소에서 데이터를 읽고 일부 수정한 다음 데이터를 잠그는 트랜잭션을 사용하여 데이터의 현재 상태를 새 값으로 업데이트하는 것입니다.
- CRUD 시스템은 데이터 저장소에 대해 직접 업데이트 작업을 수행합니다. 이러한 작업은 성능과 응답이 느려질 수 있으며 오버헤드로 인해 확장성이 제한 될 수 있습니다.
- 많은 동시 사용자가 접근하는 공동 작업 도메인에서 데이터 업데이트 충돌은 대체로 업데이트 작업이 단일 데이터 항목에서 수행되기 때문에 발생합니다.
- 별도의 로그에 각 작업의 세부 정보를 기록하는 Audit 메커니즘이 없다면 기록이 손실됩니다.
이벤트 소싱 패턴을 이용한 접근 방법
이벤트 소싱 패턴은 각각 추가 전용 저장소에 기록되는 일련의 이벤트에 의해 구동되는 데이터 작업 처리 방법을 정의합니다. 애플리케이션 코드가 데이터에서 수행된 각 작업을 명확하게 설명하는 일련의 이벤트를 이벤트 저장소로 보내며, 이벤트는 여기에 저장됩니다.
- 이벤트는 변경할 수 없으며 추가 전용 작업을 사용하여 저장할 수 있습니다. 이벤트를 시작한 사용자 인터페이스, 워크플로 또는 프로세스를 잠금 상태 없이 계속해서 사용할 수 있으며 이벤트를 처리하는 작업을 백그라운드에서 실행할 수 있습니다. 이 프로세스는 트랜잭션을 처리하는 동안 경합이 없다는 사실과 결합되어 사용자 인터페이스의 성능과 확장성을 크게 향상할 수 있습니다.
- 이벤트 소싱을 사용하면 데이터 저장소의 개체를 직접 업데이트하지 않아도 되기 때문에 동시 업데이트로 인한 충돌을 방지할 수 있습니다. 그러나 도메인 모델이 상태 불일치를 초래할 수 있는 요청으로부터 보호되도록 디자인해야 합니다.
- 추가 전용 이벤트 스토리지에서 제공하는 감사 추적을 사용하면 데이터 스토리지에 대해 수행된 작업을 모니터 할 수 있습니다. 언제든지 이벤트를 재생하여 현재 상태를 구체하된 뷰 또는 프로젝션으로 다시 생성하고, 시스템 테스트 및 디버깅을 지원할 수 있습니다.
- 이벤트 저장소는 이벤트를 발생하고, 태스크는 이러한 이벤트에 대한 응답으로 작업을 수행합니다. 이렇게 태스크와 이벤트를 분리하면 유연성과 확장성이 제공됩니다.
이벤트 소싱 패턴의 장단점
장점
- 상태가 아니라 트랜잭션을 기록
- 모든 히스토리를 기록
- 언제든지 특정 상태로 변경 가능
- CQRS와의 높은 친화력
단점
- 이벤트를 저장하는 거대한 저장소가 필요
- 최종 결과를 얻으려면 매번 재생이 필요
- 이벤트 버전 업데이트 이후에 이전 이벤트와의 정합성 문제
- 이벤트가 부분적으로 누락된 경우 반환 불가
'프로그래밍' 카테고리의 다른 글
| 우매함의 봉우리. 더닝 크루거 효과(Dunning-Kruger Effect) (2) | 2023.05.23 |
|---|---|
| Ubuntu 프로세스 실행 시 nohup과 &에 대해서 (26) | 2023.05.12 |
| Elo를 적용해서 레이팅 포인트 계산하는 예제 (0) | 2023.03.13 |
| GUID를 향한 여정 - 트위터가 만든 Twitter Snowflake (0) | 2023.02.24 |
| 프로그래밍 공부 방법에 대해서 (0) | 2023.02.06 |
댓글