[25.03.13] TIL - MSA 구조에서의 DB 구성

MSA 구조 프로젝트를 진행하면서 DB 구성을 어떻게 진행을 해야 좋을지 고민이 생겼다.

 

MSA 에서의 데이터베이스 접근 방식

모놀리식 구조에서는 하나의 단일 데이터베이스를 사용하여 모든 데이터를 관리한다.

반면, MSA 구조에서는 각 서비스 마다 독립적인 데이터베이스를 가질 수 있다.

 

이 때, MSA 를 사용하는 경우에 데이터베이스를 무조건 분리 하여야 하는가? 라고 한다면 반드시 분리해야 되는 건 아니다.

 

분리된 데이터베이스를 가진다면, 몇 가지 해결해야 할 문제가 발생한다.

 

---

 

분리된 데이터베이스를 가지는 경우의 문제점

1. JOIN 불가

단일 데이터베이스에서는 주문 서비스에서 고객 DB를 가져올 때 그냥 접근해서 가져오면 된다.

SELECT * FROM 고객 
JOIN 주문 ON 고객.아이디 = 주문.고객아이디;

 

분리된 데이터베이스에서는 직접 접근해서 가져오는게 아니라, 레지스트리 나 API 게이트웨이 같은 거를 통해서 가져와야 한다.

• API 게이트웨이를 통해 GET → lamda 사용 (AWS 환경)
  • 주문 서비스 → HTTP 요청 → 유저 서비스 API에 접근
• 레지스트리를 통해 GET → Eureka & FeignClient 사용
  • 주문 서비스 → FeignClient → 유저 서비스 사용
• 이벤트 기반 아키텍처를 통해 GET → Kafka, RabbitMQ 사용 (Message Queue)
  • 주문 생성하는 이벤트 발생 → 메세지 브로커(Kafka, RabbitMQ) → 유저 서비스에서 해당 이벤트 구독하여 데이터 업데이트

이런 경우 정합성의 문제가 발생한다.

 

2. 데이터 정합성 유지의 문제

데이터 정합성 이란? 어떤 데이터들이 값이 서로 일치하는 것

예시 : 주문 테이블에서 유저 아이디를 A에서 B로 변경했지만, 유저 테이블에서는 유저 아이디 을 변경하지 않았을 경우 ( → 데이터 값 불일치 )

 

https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/cqrs-pattern.html

데이터를 생성하는 서비스는 Write DB만 사용하고, 조회하는 서비스는 Read DB만 사용한다.

그래서 두 DB의 정합성을 맞춰주려면, 동기화 하는 메커니즘이 필요하다.

이때, 동기화를 Event 기반으로 한다.

Event 는 MSA에서 데이터 일관성을 보장하는 방식으로 언젠가 데이터 정합성이 맞으면 된다.

여기서 ‘언젠가’는 Real time 이 아니라, Eventually 이다.

따라서 실시간 반영을 해야하는 업무는 분리된 DB를 사용하는 MSA 구조가 어려울 수 있다.

 

3. 트랜잭션 관리의 어려움

트랜잭션 이란? 데이터베이스 상태를 변화시키려고 수행하는 작업 단위

MSA 분산 DB환경에서 2phase-Commit 어렵다 (추가 공부 필요)

 

대체로 분리된 데이터 베이스를 사용하게 되면, 기존에서는 DB레이어에서 끝날 일들을 App레이어에서 해야 한다.

 

---

어떤식으로 구성하면 좋을까?

https://techinterviewblog.com/1227/

일반적 기업에서는 필요에 따라 데이터베이스를 분리하거나 공유할 수 있다.

왜냐하면 빅테크 기업처럼 효율성, 성능, 엄청난 속도의 업데이트가 중요한 상황은 아니기 때문이다.

 

개인적 생각으로는 JOIN을 자주 사용해야 하는 경우에는 공유 데이터베이스를 사용하고, 확장성이 중요한 경우에는 데이터베이스 분리를 하는게 좋지 않을까 싶다.