Event Sourcing and CQRS pattern

CQRS pattern은 Event Sourcing pattern과 함께 자주 사용됩니다. CQRS 기반 시스템은 별도의 읽기 및 쓰기 데이터 모델을 사용하며, 각 모델은 관련 작업에 맞게 조정되고 종종 물리적으로 분리된 저장소에 있습니다. Event Sourcing 패턴과 함께 사용할 때 이벤트 저장소는 쓰기 모델이며 공식 정보 소스입니다. CQRS 기반 시스템의 읽기 모델은 데이터의 구체화된 보기(일반적으로 고도로 비정규화된 보기)를 제공합니다. 이러한 보기는 애플리케이션의 인터페이스 및 디스플레이 요구 사항에 맞게 조정되어 디스플레이 및 쿼리 성능을 모두 최대화하는 데 도움이 됩니다

특정 시점의 실제 데이터가 아닌 쓰기 저장소로 이벤트 스트림을 사용하면 단일 집계에서 업데이트 충돌을 방지하고 성능과 확장성을 최대화할 수 있습니다. 이벤트는 읽기 저장소를 채우는 데 사용되는 데이터의 구체화된 보기를 비동기식으로 생성하는 데 사용할 수 있습니다. 이벤트 저장소는 공식적인 정보 소스이므로 시스템이 발전하거나 읽기 모델을 변경해야 할 때 구체화된 뷰를 삭제하고 모든 과거 이벤트를 재생하여 현재 상태의 새로운 표현을 생성할 수 있습니다. 구체화된 뷰는 사실상 데이터의 내구성 있는 읽기 전용 캐시입니다.

명령 버스와 이벤트 버스 간의 연결은 게시에 적합한 변경 로그를 유지하는 이벤트 소싱 패턴 의 적용으로 용이해집니다 . 이벤트 소싱은 데이터의 현재 상태뿐만 아니라 현재 상태에 도달한 방법에 대한 기록도 유지합니다. 명령 버스의 각 명령에 대해 쓰기 모델은 다음 작업을 수행하여 명령을 처리합니다.

• 변경 사항을 기록합니다.

• 변경 사항으로 데이터베이스를 업데이트합니다.

• 변경 사항을 설명하는 업데이트 이벤트를 생성하고 이벤트 버스에 게시합니다.

쓰기 모델을 지원하는 하나와 쿼리를 지원하는 여러 개의 다른 마이크로 서비스인 두 개의 개별 마이크로 서비스를 나타냅니다

쿼리 부분은 변경 로그 이벤트를 사용하고 향후 쿼리에 대한 프로젝션을 작성하는 별도의 프로세스입니다. "쓰기" 부분은 SQL에서 유지될 수 있는 반면 읽기는 강력한 인덱싱 및 쿼리 기능이 있는 문서 지향 데이터베이스를 사용할 수 있습니다. 또는 메모리 내 데이터베이스 또는 분산 캐시를 사용하십시오. 동일한 언어 일 필요는 없습니다. CQRS 및 ES를 사용하면 예측이 소급 적용됩니다. 새 쿼리는 새 프로젝션을 구현하고 시작 시간 또는 최근 커밋된 상태 및 스냅샷에서 이벤트를 읽는 것과 같습니다. 읽기 및 쓰기 모델은 강력하게 분리되어 있으며 독립적으로 발전할 수 있습니다. 'Command' 부분은 ID로 주문하기 또는 조인을 포함하지 않는 쿼리와 같은 기본 키 기반의 간단한 쿼리를 여전히 처리할 수 있다는 점에 유의하는 것이 중요합니다.

이벤트 백본은 pub/sub 모델을 사용하며 Kafka는 구현 기술로 좋은 후보입니다.

이 구조를 사용하면 Read model마이크로 서비스는 여러 주제의 이벤트를 사용하여 해당 데이터 스트림 조인을 기반으로 데이터 프로젝션을 구축할 가능성이 높습니다. 신선 식품 주문 배송에서 콜드 체인이 준수되었는지 평가하기 위한 쿼리는 이 질문에 답할 수 있도록 항해, 컨테이너 메트릭 및 주문으로 이동합니다. CQRS가 빛나는 곳입니다.

API 게이트웨이에서 API 정의와 관리를 분리할 수 있습니다.

주문 마이크로서비스

고려해야 할 몇 가지 구현 항목:

• 일관성 (각 데이터 트랜잭션에 대해 데이터 제약 조건이 준수되는지 확인)

  • 이벤트 소싱이 없는 CQRS는 데이터 및 이벤트를 유지하는 데 사용되는 데이터베이스와 동일한 일관성을 보장합니다. 이벤트 소싱을 사용하면 쓰기 모델과 읽기 모델에 대해 일관성이 다를 수 있습니다. 쓰기 모델에서 강력한 일관성은 시스템의 현재 상태가 올바른지 확인하는 데 중요하므로 트랜잭션, 잠금 및 샤딩을 활용합니다. 읽기 측면에서는 대부분 오래된 데이터에서 작동하므로 일관성이 덜 필요합니다. 읽기 작업에서 데이터를 잠그는 것은 적절하지 않습니다.

• 확장성

  • 두 개의 서로 다른 마이크로 서비스로 읽기와 쓰기를 분리하면 고가용성이 가능합니다. 읽기 수준의 캐싱을 사용하여 성능 응답 시간을 높일 수 있으며 여러 독립 실행형 인스턴스(Kubernetes의 포드)로 배포할 수 있습니다. 다른 서비스 간에 쿼리 구현을 분리하는 것도 가능합니다. 서비스/서버리스로서의 기능은 복잡한 쿼리를 구현하기 위한 좋은 기술 선택입니다.

• 가용성

  • 쓰기 모델은 가용성을 위해 일관성을 희생합니다. 이건 사실이다. 읽기 모델은 결국 일관성이 있으므로 고가용성이 가능합니다. 장애가 발생한 경우 시스템은 데이터 쓰기를 비활성화하지만 다른 데이터베이스 및 서비스에서 제공하는 데이터를 읽을 수 있습니다.

항상 고려해야 할 몇 가지 과제:

• 이벤트 구조 버전 관리를 지원하는 방법은 무엇입니까?

• 이벤트 저장소(히스토리)에 보관할 데이터의 양은 얼마입니까?

• 궁극적인 데이터 일관성을 가져오는 데이터 복제를 채택하는 방법은 무엇입니까?

Event Sourcing pattern과 결합된 CQRS를 사용할 때 고려사항

• 쓰기 및 읽기 저장소가 분리된 모든 시스템과 마찬가지로 이 패턴을 기반으로 하는 시스템은 eventually 일관성이 있습니다. 생성되는 이벤트와 업데이트되는 데이터 저장소 사이에 약간의 지연이 있습니다.

• 패턴은 이벤트를 시작 및 처리하고 쿼리 또는 읽기 모델에 필요한 적절한 뷰 또는 객체를 어셈블하거나 업데이트하기 위해 코드를 생성해야 하기 때문에 복잡성을 추가합니다. Event Sourcing 패턴과 함께 사용할 때 CQRS 패턴의 복잡성으로 인해 성공적인 구현이 더 어려워질 수 있으며 시스템 설계에 다른 접근 방식이 필요합니다. 그러나 이벤트 소싱을 사용하면 도메인을 더 쉽게 모델링할 수 있고 데이터 변경 의도가 보존되기 때문에 보기를 다시 작성하거나 새 보기를 만드는 것이 더 쉽습니다.

• 특정 엔터티 또는 엔터티 컬렉션에 대한 이벤트를 재생하고 처리하여 데이터의 읽기 모델 또는 프로젝션에서 사용할 구체화된 뷰를 생성하려면 상당한 처리 시간과 리소스 사용량이 필요할 수 있습니다. 관련된 모든 이벤트를 검사해야 할 수 있으므로 장기간에 걸쳐 값을 합산하거나 분석해야 하는 경우 특히 그렇습니다. 발생한 특정 작업의 총 수 또는 엔터티의 현재 상태와 같은 예약된 간격으로 데이터의 스냅샷을 구현하여 이 문제를 해결합니다.

쓰기 모델을 메인프레임에 유지

위의 그림에서 쓰기 모델은 메인프레임에서 현재 트랜잭션 처리를 따르고 분산된 세계에 대한 실시간 가시성을 얻기 위해 데이터 캡처 푸시 데이터를 이벤트 백본으로 변경합니다

일관성 문제

이벤트 소싱 패턴을 사용하면 신뢰의 소스는 ㅇㅟ 다이어그램과 같이 버전 제어 시스템 역할을 하는 이벤트 소스입니다.

데이터 변경 사항을 동기화하는 단계는 다음과 같습니다.

1. 쓰기 모델은 이벤트를 생성하고 게시합니다.

2. 소비자는 이벤트를 수신하고 페이로드를 추출합니다.

3. 소비자는 페이로드 데이터로 로컬 데이터 소스를 업데이트합니다.

4. 소비자가 업데이트를 처리하지 못하는 경우 오류 로그에 이벤트를 유지할 수 있습니다.

5. 로그의 각 오류를 재생할 수 있습니다.

6. 명령줄 인터페이스는 저장 작업을 재생하기 위해 이 주문 ID를 사용하여 주제에서 검색하는 관리 API를 통해 이벤트를 재생합니다.

Kafka Consumers

CQRS 및 변경 데이터 캡처

이 이중 작업 수준을 지원하는 다른 방법이 있습니다.

• Kafka를 사용할 때 Kafka Connect는 JDBC를 통해 데이터베이스를 구독할 수 있는 기능이 있어 업데이트를 위해 테이블을 폴링한 다음 Kafka에 대한 이벤트를 생성할 수 있습니다.
• 데이터베이스 트랜잭션 로그에서 변경 이벤트 추출을 기반으로 하는 오픈 소스 변경 데이터 캡처 솔루션, 데이터베이스에서 삽입, 업데이트 및 삭제 작업에 응답하고 그에 따라 이벤트를 생성하는 데 도움이 되는 Debezium이 있습니다 . MySQL, Postgres, MongoDB 등과 같은 데이터베이스를 지원합니다.
• 주문을 데이터베이스에 쓰고 동일한 트랜잭션에서 이벤트 테이블에 씁니다( "outbox pattern" ). 그런 다음 폴링을 사용하여 이 이벤트 테이블에서 Kafka로 보낼 이벤트를 가져오고 이벤트가 전송되면 테이블의 행을 삭제합니다.
• 데이터베이스 트랜잭션 로그에서 변경 데이터 캡처를 사용하고 이 로그에서 이벤트를 생성하십시오. IBM Infosphere CDC 제품은 이 패턴을 구현하는 데 도움이 됩니다.

CDC를 사용하는 CQRS 구현은 다음 다이어그램과 같습니다.

주목해야 할 중요한 점은 이벤트가 데이터 페이로드에서 유연해야 한다는 것입니다.

코드 참조

Reference

https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs

https://ibm-cloud-architecture.github.io/refarch-eda/patterns/cqrs/

https://martinfowler.com/bliki/CQRS.html