본문 바로가기
IT

[MSA] MSA 에서의 데이터 동기화

by 뽀리님 2023. 12. 18.

문득 고도화를 하다보니

DB 를 각각 나누어서 진행하였는데,

가끔, 데이터의 동기화가 필요한부분도 있을 수 있다는 생각이 문득들었다.

 

젤 좋은건 동기화가 필요하지 않도록 설계하는 것이라고 하는데 뭐 그게 사실 쉽지 않다.

 

어떻게 하면 동기화를 할 수 있을까 생각해봤다.

 

1. 반드시 신뢰성 있는 데이터 업데이트가 필요하다면 CDC 방식으로 구현

 

트랜잭션 로그감지(Mostly used)

데이터베이스의 트랜잭션 로그를 기반으로 변경 사항을 감지한다다. 트랜잭션 로그에는 데이터베이스에 대한 모든 변경 사항이 기록되어 있으며, 이를 분석하여 변경을 감지

장애가 발생하더라도 복구될 때까지 반복 수행하면서 기필코 반영한다.

 

2. SAGA 패턴

SAGA 패턴은 애플리케이션 개발자가 보상 트랜잭션을 잘 정의하고 누락되지 않도록 구성할 책임

스프링 부트(Spring Boot) 카프카(Kafka) 활용하여 각각의 방식을 구현

 

움 이것도 힘들어보인다.

 

주로 어떻게 하면 좋을까 생각하던 찰나...CQRS 라는 개념을 발견했다.

 

CQRS??

영어 뜻 그대로 CQRS

  • 명령(시스템의 데이터 변경) 역할을 수행하는 구성 요소와
  • 쿼리(시스템 데이터 조회) 역할을 수행하는 구성 요소를 나누는 것을 의미한다.

명령 모델과 쿼리 모델을 나누면 문제가 해결될까?

시스템의 복잡도에 따라 모든 문제가 해결되지는 않겠지만 어느 정도는 해결될 것이다.

 

1. 다루는 데이터가 다르다.

 

조회와 명령의 로직을 생각해보자.

 

CRUD를 많이 해본 사람이라면 명령과 쿼리는 다루는 데이터가 다르다는 것을 금방 알 수 있을 것이다. 

일반적으로 명령은 한 영역의 데이터, 쿼리는 여러 영역의 데이터를 다룬다.

 

예를 들어 주문 취소 명령 order orderline 다룬다
주문 목록 조회 같은 기능은 주문, 회원, 상품 영역의 데이터를 사용하게 된다.

 

 

2. 명령과 쿼리는 코드 변경 빈도, 사용자가 다르다.

 

읽기 모델의 변경

  • 응용 프로그램의 읽기 모델(쿼리)은 고객에게 정보를 제공하는 데 중점을 두고 있다.
  • 따라서 UI의 요구 사항에 따라 빈번하게 변경될 수 있다.

 

쓰기 모델의 변경

  • 쓰기 모델(명령)은 비즈니스 로직에 더 초점을 맞추고 있다.
  • 따라서 비즈니스 규칙이 변경될 때만 변경이 필요하게 된다.

ㅡ> 서로 다른 이유로 코드를 변경하게 된다.

 

읽기 모델의 사용자

  • 대형 쇼핑몰 웹사이트를 예로 들어 보자.
  • 웹사이트 관리자는 새로운 상품을 추가하거나 가격을 변경하는 등의 명령(쓰기) 작업을 주로 수행한다.

쓰기 모델의 사용자

  • 반면에, 고객들은 상품 정보를 보거나 리뷰를 확인하는 등의 쿼리(읽기) 작업을 주로 수행한다.

> 사용자 그룹에 맞게 코드를 작성할 필요가 있다.

 

 

 

* 결론 *

결국은 중간 매체로 메시지 큐나 카프카를 써서 적절히 연결 시켜줘야한단 소리다.

요청이 들어오면 CQRS 를 통해 적절히 DB를 나눠 구성하여 비교적 요청수가 많은 조회용은 엘라스틱서치를 쓰거나 하면 더 빠르고,

명령쪽은 RDBMS 를 쓴다고 하더라도 중간에 연결 고리는 메시지 큐와 카프카를 써서 이벤트를 통해 구현하면 될 것 같다.

신뢰성있는 데이터가 필요하다면 CDC 방식으로 구현해야 하는거고!!

결론은... 정말 어렵다ㅡㅡ