소개

CQRS로 쓰기 측과 읽기 측을 나누었을 때에 읽어들이는 쪽을 최신으로 유지하는 방법에 대해 고찰해 보겠습니다.

참고 사이트

The unfinished guide to Event-Sourcing, CQRS and DDD [Unreleased, RAW] + notes about Uber

Choosing an architecture

Event Sourcing - Projections

Some thoughts on using CQRS without Event Sourcing

Tackling Complexity in CQRS

고찰의 기초가 되는 CQRS의 다이어그램

Tackling Complexity in CQRS에서 인용
아래 그림의 Projection Engines 부분에 대한 고찰입니다.

Pub/Sub 패턴으로 최신으로 유지

Projection Engines가 Pub/Sub 기능을 가지는 가나가카스를 구독하고 있고, 발행되면 로드측에 투영합니다.
쓰기 측에 Pub/Sub 기능이 있으면 그것을 사용하고,
RDBMS와 같이 Pub/Sub 기능이 없는 경우Google Cloud Pub/Sub, Amazon SQS, Azure Service Bus 등의 Pub/Sub 서비스를 이용하거나 혹은 자체적으로 준비해야 합니다.

EventStore용 DB인 EventStore에는 Pub/Sub 기능이 붙어 있으므로 추천합니다.

기입측을 이벤트 베이스로 구현하고 있는 경우는, read측에 필요한 이벤트만을 구독해 투영할 수가 있습니다.
기입측을 상태 기반(State Based Projections) 로 구현하고 있는 경우는, read측에 필요한 집계만을 구독해 투영할 수가 있습니다.

Pub/Sub 패턴 뿐이라고 메시지가 발행되지 않았던 경우, read측이 최신이 되지 않기 때문에 다른 방법으로도 감시할 필요가 있습니다.

Polling에서 최신으로 유지

Projection Engines는 쓰기 측을 정기적으로 확인하여 필요한 정보가 업데이트되면 로드 측에 투영합니다.

업데이트되었는지 여부의 표시가 되는 정보는

기입측을 이벤트 베이스로 구현하고 있는 경우는, 이벤트 마다 인크리먼트 되는 EventNumber( EventStore 라고)

작성자를 상태 기반(State Based Projections)으로 구현하는 경우 SQL Server에서 rowversion 또는 해당 행의 업데이트 날짜 및 시간 열

사용할 수 있을까 생각합니다.
Polling만이라면 쓰기 측의 정보량에 따릅니다만, read측에의 반영이 늦을지도 모릅니다.

2 계통 준비로 최신으로 유지

읽기측을 주, 부의 2계통 준비합니다.
주님이 일하는 동안 부를 버리고

기입측을 이벤트 베이스로 구현하고 있는 경우는, 모든 이벤트를 리플레이 하는 것으로 최신 상태로 합니다

쓰기 측을 상태 기반(State Based Projections)로 구현하고 있는 경우는, 필요한 집계의 정보를 취득해 최신 상태로 합니다

주와 부를 전환합니다.

이것을 반복하는 것으로 읽기 측을 최신으로 유지할 것 같습니다.
가용성을 높이기 위해서 2계통 준비하고 있어도, 막상이라고 할 때 동작할지는 불안하기 때문에 평소부터 사용하는 운용으로 하면 안심할 수 있는 생각이 듭니다.

요약

2계통 준비하는 이야기는 무리한 생각은 하고 있습니다.
다른 유효한 투영 방법이 있으면 알려주세요.

CQRS로 쓰기 측과 읽기 측을 분할하는 장점 단점으로 항상 고민합니다.
(결국은 앱의 규모감에 달려 있다고 생각합니다만. 쓰기와 읽기가 동일해도 CQRS 자체는 할 수 있고)

장점

읽는 쪽이 별로 DB가 아니어도 좋다 (파일이나 BLOB에 써내 항상 덮어쓰거나)

읽기 측의 확장 성이 향상됩니다.

마이크로 서비스로의 첫 걸음

단점

Projection Engines라는 투영을위한 메커니즘을 준비해야합니다

결과 무결성을 허용해야 함