# 마이크로 서비스 데이터 설계

서비스당 데이터베이스

이점

각 서비스 간 느슨한 결합으로 의존성을 낮추고 서비스 특성에 맞는 데이터베이스를 자유롭게 선택 가능하다.

문제점 및 해결방법

1. 여러 데이터베이스를 통해 조인해야 하는 쿼리

• 이벤트 소싱
• API 구성
• CQRS(명령/조회 책임 분리)

2. 여러 데이터베이스에 걸친 트랜잭션

• 사가현 패턴

1-1. 이벤트 소싱 (Event Sourcing)

이벤트 소싱이란, 이벤트를 위주로 비즈니스 로직을 구현하고, 애그리거트를 event store에 저장하는 것을 의미한다.

✅ 애그리거트: DDD에 기반한 설계에서 하나의 도메인에서 필요한 객체들을 하나의 군집으로 묶은 것

데이터를 가진 서비스가 직접 데이터를 조작하게 하지 않고, 서비스는 이벤트를 발생시키고 해당 이벤트는 event store에 저장만 한다.
그리고 이벤트 컨슈머가 해당 이벤트를 처리하도록 한다.

이벤트 소싱은 클라우드 환경에서의 메시지 중심의 분산 시스템에 적합하다.

이벤트 소싱은 쓰기에 적합하지만 읽기에 매우 비효율적인 구조를 가진다. 따라서 CQRS(Command Query Responsibility Segregation)를 적용하면 읽기 성능을 높일 수 있다.

이벤트 소싱 + CQRS

1. Command가 발생하면 Command API에 요청 전달
2. Command를 처리하는 서비스는 event store에 API 처리 결과를 저장
3. 이벤트가 처리된 후 이벤트 브로커로 결과 전송
4. 이벤트는 queries API로 전달되면 view store에 저장된다.
5. 이후 client로부터 query가 요청되면 view store에 동기화된 데이터를 조회하게 된다.

이벤트 소싱 단점

1. 높은 학습 곡선
2. 어플리케이션의 복잡도 증가
3. 애그리커트의 이력 보존이 주요 목표인만큼 데이터 삭제의 어려움

1-2. API 구성

API 컴포지션 패턴은 데이터를 소유하고 있는 각 서비스를 호출한 다음 결과를 조합하여 쿼리 작업을 구현하는 것을 의미한다.

장점

높은 학습 곡선 없이 MSA에서 데이터를 쿼리하는 가장 편리한 방법

단점

경우에 따라 대규모 데이터의 비효율적인 조인이 발생할 수 있다.

1-3. CQRS 패턴

CQRS의 주요 목표는 문제를 분리하는 것이다.

• 생성, 수정 및 삭제 작업은 명령 모듈에 의해 구현된다.
• 조회 작업은 쿼리 모듈에 의해 구현된다.
• 명령 모듈에서 생성된 이벤트는 쿼리 모듈이 전달받고 항상 동기화된 상태를 유지한다.

이점

1. MSA에서 쿼리를 효율적으로 구현할 수 있음
2. 이벤트 소싱 기반 응용 프로그램에서 쿼리를 가능하게 함
3. 서비스의 명령 및 쿼리 측면을 별도의 코드와 스키마로 분리함

단점

1. 더 복잡한 아키텍처
   : 개발자가 쿼리쪽 서비스를 따로 또 작성해야 하고 Application에서 다양한 유형의 DB를 사용할 수 있으므로 개발자와 DevOps 모두 복잡성이 증가
2. 복제 지연 발생
   이벤트가 명력측에서 게시되는 시점과 쿼리측에서 처리되는 시점 사이에 업데이트 지연이 발생

2-1. 사가 패턴(Saga Pattern)

사가 패턴을 사용하면 분산 트랜잭션을 사용하지 않고도 MSA에서 데이터 일관성을 유지할 수 있다.

트랜잭션의 관리 주체가 DBMS가 아닌 서비스이다. 따라서 사가 패턴은 보상 트랜잭션 처리도 해줘야 한다.

• 보상 트랜잭션: 사가의 n번째 트랜잭션이 실패했을 때, 이전 n-1 번째 트랜잭션부터 수행된 모든 로컬 트랜잭션을 역순으로 롤백하는 것

Choreography 방식

각 서비스 간 이벤트를 주고 받는 Event Pub/Sub 방식이다. 메시지 큐를 통해 비동기 방식으로 전달하는 것도 가능하다.

1. 메인이 되는 서비스에서 관련 서비스의 로컬 트랜잭션을 호출한다.
2. 트랜잭션이 실패하면 취소된 서비스로부터 보상 이벤트를 발생시켜 보상 트랜잭션을 처리한다.

장점

1. 단순성
   : 비즈니스 개체가 생성, 수정, 삭제되면 서비스는 이벤트를 게시만 하면 된다.
2. 느슨한 결합
   : 이벤트를 통해 처리되므로 각 서비스가 누군지 알 필요가 없다.

단점

1. 각 서비스는 자신에게 영향을 미치는 모든 이벤트를 항상 구독하고 있어야 한다.
2. 개별 트랜잭션들이 공통된 공유ID를 정의해야하고, 이벤트 추적, 디버깅 어려움, 새로운 스텝 추가시 복잡도 증가

Orchestration 방식

Orchestrator를 중심으로 한 Invoke/Reply 방식이다.

1. 트랜잭션에 참가하는 각 서비스들의 로컬 트랜잭션은 Orchestrator에 의해 호출되고 상태값이 설정된다.
2. 참가하는 모든 트랜잭션이 처기가 된다면 메인 서비스의 상태가 변경된다.
3. 참가하는 서비스 중 하나라도 트랜잭션 실패하면 Orchestrator는 보상 트랜잭션을 수행한다.

장점

1. 서비스의 복잡도가 감소한다.
2. 느슨한 결합
   : 서비스는 Orchestrator가 호출하는 API를 구현하므로 이벤트에 대해 알 필요가 없다.
3. 관심사의 분리를 통해 비즈니스 논리를 단순화 한다.

단점

1. Orchestrator에서 너무 많은 비즈니스 로직을 중앙 집중화할 위험이 존재한다.

참고사이트