데이터 정합성은 어떻게 맞추는가?

MSA 도입 전 따져봐야 할 3가지 - 투이 컨설팅
https://www.youtube.com/watch?v=X4kXKOf4AnM
위의 내용에서 발췌

Microservice Architecture를 적용하면 하나의 통합 DB는 사라진다.
데이터는 각각의 Microservice가 따로 갖는다.
각 Microservice는 다른 Microservice와 데이터를 공유하지 않는다.
스스로 업무처리의 완결성을 갖기 위해서이다. 

하지만 데이터는 중복된다.
(금융) 시스템은 데이터 값의 정확성이 매우 중요하다.(쇼핑몰의 주문과 결제 데이터는? 의료의 환자와 처방 데이터는?)
전통적 금융시스템에서는 데이터를 통합해 운영함으로써 모든 Application에서 하나의 값만 존재하도록 강제했다.
데이터의 중복이 허용되는 MSA에서는 데이터 무결성(Data Integrity)를 어떻게 보장할 수 있을까?

MSA에서 각 서비스가 다른 서비스에 영향을 받지 않고 독자적으로 수행될 수 있어야 한다.

통합 DB는 데이터 중복을 최소화하는 것이 목적이다. (모두 원본을 직접 참조)
정규화 과정을 통해서 중복 데이터를 제거한다.

MSA에서 각 서비스는 자신에게 필요한 데이터를 자신이 관리한다. (Self Contained)
하나의 사실이(데이터가) 서로 다른 Microservice에서 관리될 수 있어야 한다.
데이터 중복을 허용하지 않으면 MSA는 구현하기 어렵다.

MSA 환경에서 데이터 정합성을 유지하기 위한 방안으로 SAGA Pattern을 사용할 수 있다.

분산 되어 있는 데이터를 맞추는 방법은 두가지가 있다.
하나의 트랜잭션이 데이터 변경을 마칠 때까지 다른 트랜잭션들은 대기하는 방식이다.
이를 동기 방식이라 한다.

또 하나의 방법은 각자 트랜잭션은 다른 트랜잭션의 결과와 상관없이 일을 처리하고 나중에 비교해보는 방식이다.
이를 비동기 방식이라고 한다.

비동기 방식의 예
 - 커피 가게에서 커피 주문을 받는 것과 커피를 만드는 것은 항상 같은 상태를 유지할 필요는 없다.
 - 일단 커피 주문을 받는 일은 독자적으로 수행하고 커피 만드는 일은 주문 상태를 확인하고 만들면 된다.
 - 주문 받는 일은 커피 만드는 일과 주문 데이터를 실시간으로 공유하지 않아도 된다.
 - 커피 만드는 일은 커피를 만들기 전에 주문 데이터를 확인하면 되는 것이다.

동기방식을 적용하면 시스템을 설계하기는 쉽지만, 트랜잭션들 사이에 커플링이 생긴다.
또한 트랜잭션이 수행될 때 다른 트랜잭션이 끝날 때까지 기다려야 한다. (장애 전파)
대기하는 시간만큼 시스템 자원의 낭비가 발생한다.

비동기 방식을 적용하면 트랜잭션 사이의 커플링이 발생하지 않는다.
다른 트랜잭션을 기다리지 않고 수행될 수 있다.
하지만 비즈니스 정합성이 깨지지 않도록 설계하는 것이 어렵다.

동기방식을 적용하려면, 2 Phase Commit(2PC)기능이 DBMS또는 시스템에서 지원되어야 한다.
이는 개발자가 설계하여 구현하는 것이 아니라 시스템 제공하는 기능을 이용하는 것이기 때문이다.
2PC는 몽고DB나 카산드라와 같은 NoSQL DB, RabbitMQ나 Apache Kafka와 같은 메세지 기술들이 지원하지 않는다.
MSA에서는 동기방식을 적용하기가 어렵다.

비동기 방식으로 분산 데이터 정합성을 맞추기 위해서는 비즈니스 관점을 이해하고 업무 흐름에 맞는 설계를 해야한다.

동기 방식에서 데이터 정합성은 상당 부분 시스템이 해결해주는 반면에

비동기 방식에서는 설계자와 개발자의 몫이 된다.
데이터 흐름 설계가 잘못되면 Last Update, Dirty Read, Fuzzy Read 등의 데이터 아노말리 현상이 발생할 수 있다.

Microservice들에 분산되어 있는 데이터 정합성 설계를 위해

이벤트 주도 아키텍처(Event Driven Architecture, EDA)를 적용할 수 있다.
Event는 상태를 변화시키는 것을 뜻한다.
어떤 사건일수도 있고, 시기일 수도 있다.
비즈니스 활동은 이벤트를 감지하고, 적합한 반응을 수행하는 것이다.
EDA는 비지니스를 업무 규칙을 적용하는 것이 아니라
이벤트에 대한 반응을 수행하는 관점으로 이해하고
이를 구현하기 위한 아키텍처 방식이다.

산업에 따라 데이터 정합성을 요구하는 수준은 다르다.
상거래 회사의 경우 주문데이터에 오류가 있다고 해도 피해는 크지 않다.
금융회사의 경우 계좌 잔고, 주식 매수/주문, 보험금 지급 등의 데이터에 오류가 발생하면 피해는 매우 크다.
금융 비즈니스에서 데이터 정합성은 결코 포기할 수 없는 명제이다.

MSA를 전면 적용한다는 것은 데이터 분산을 수용한다는 것이고, 데이터 동기 방식은 포기한다는 뜻이다.

 

EDA와 SAGA패턴을 적용하는 것으로 금융회사에 요구되는 데이터 정합성을 확보할 수 있을까?
(금융) (MSA를 도입하려는 회사 또는 조직) 회사의 기술 수준에 따라 좌우될 것으로 보인다.
MSA 역량이 충분하지 않은 경우는 (금융) 코어 시스템에 MSA를 적용하는 것은 위험할 수 있다.
데이터 정합성 요구 수준이 낮은 업무 부터 적용하고, 내부 설계 역량 향상에 따라 확산하는 접근이 바람직하다.

(Strangler, 단계별 내재화, 검증)