대규모 시스템에서는 데이터를 일관성있게 유지시키는 것 또한 중요하다.

이커머스 웹 사이트를 생각해보자

1. 철수는 사고싶은 물건의 재고가 하나 남은것을 확인하고 장바구니에 넣은채 결제를 하려고 하고있다.

2. 그 순간 민수가 먼저 하나남은 물건을 결제해버렸다.

3. 사이트가 이 상황을 고려하지 못하고 장바구니에 반영을 못 했다면?

결제는 되고 돈은 나갔지만 물건이 없는 상황이 생길 수 있다..

일관성이 없는 데이터는 사용자에게 혼란을 야기하고 서비스에 대한 신뢰를 잃게 할 수 있다. 😡

데이터의 일관성을 유지하는 기법을 생각해본다.

---

데이터 일관성 유지

분산 트랜잭션

여러개로 분산되어있는 트랜잭션을 일관되게 관리하는 방법이다.

하나의 트랜잭션이 여러 시스템을 통과하며 업무가 처리될때, 그 트랜잭션이 완전히 본인의 업무가 완료되거나 혹은 완전히 실패함을 보장해주는 방법이다.

작업 중 한 부분이라도 오류가 발생하면 이 업무 이전의 상태로 완전히 롤백 되어야 한다.
=> 트랜잭션의 ACID 속성 중 원자성, 사가패턴

MSA 방식을 사용하게되면 트랜잭션이 여러 독립된 서비스를 타며 업무가 처리되기 때문에 MSA에서는 분산 트랜잭션이 필요하다.

Event Sourcing

보통의 데이터 저장 방식은 데이터 자체를 변경하며 이루어진다.

이벤트 소싱의 경우 데이터 자체를 변경하지 않고 변경한다는 이벤트 를 저장한다.

해당 이벤트들을 기록하고 순차적으로 재생하여 기대값을 파악하는 방법이다.

이벤트 소싱을 이용하면 일관성을 유지할 수 있을 뿐 아니라 데이터가 어디서 잘못되었는지 추적 가능성을 높일 수 있다.

복잡성이 증가할 수 있다는 단점이 있다.

CQRS

"Command and Query Responsibility Segregation"

시스템의 명령과 쿼리의 책임을 분리한다는 뜻을 가진 디자인패턴이다.

읽기 작업, 쓰기 작업을 각각 다른 모델로 분리해서 최적화된 동작을 수행하게 한다.

명령 📃

=> 데이터 변경
DB에 대해 쓰기 작업을 수행한다. (주문 생성, 결제 처리)
명령모델 : 명령모델은 데이터의 상태 변경을 담당

조회 🔍

=> 데이터 조회
DB에 읽기 작업을 수행한다. (주문 내역 조회, 계정정보 조회)
조회모델 : 조회모델은 캐시나 읽기전용DB를 사용해 빠른 응답 제공을 담당

확장성과 성능향상 면에서 장점이 있지만 명령모델과 조회모델을 따로 관리하면서 복잡성이 증가할 수 있다.