8_3.MSA 데이터 설계 전략 실습

학습내용

1. 데이터베이스 분리와 설계 전략
2. 데이터 동기화 전략

---

학습정리

1. 데이터베이스 분리와 설계 전략

• 각 서비스가 독립적인 데이터베이스 스키마를 소유하고 데이터 독립성을 유지

• Database per Service 패턴

  서비스A
     └── DB-A (주문 데이터)
  
  서비스B
     └── DB-B (상품 데이터)
  
  서비스C
     └── DB-C (결제 데이터)

  • 각 시스템에 더욱 적합한 데이터베이스 선택가능 (MySQL, PostgreSQL, MongoDB, Redis 등등)

• 장단점

  • 장점
    • 서비스 간의 데이터 독립성 보장
    • 각 서비스에 맞는 데이터베이스 유형 선택 가능
    • 각 서비스가 자신의 데이터 모델을 최적화 가능
    • 장애 격리
  • 단점
    • 데이터 중복 가능성
    • 서비스 간 데이터 일관성 유지 어려움
    • 운영 복잡도 증가

2. 데이터 동기화 전략

• Eventual Consistency
  • MSA에서 데이터 일관성을 유지하는 전략
  • 즉각적인 데이터 동기화 (Strong Consistency)가 아닌 시간 지나면서 최종적으로 일관성 유지하는 전략
  • 유지전략

    전략	설명	예제
    Event-Driven Architecture	Kafka, RabbitMQ 등을 활용하여 이벤트 기반 데이터 동기화	주문 생성 시, 결제 시스템에 이벤트 전송
    SAGA 패턴	서비스 간 상태 변경을 트랜잭션 단위로 수행하고, 실패 시 보상 트랜잭션 실행	결제 실패 시 주문을 자동 취소
    Retry & Compensation Mechanism	장애 발생 시 재시도를 수행하고, 복구 불가능한 경우 보상 트랜잭션 수행	재고 업데이트 실패 시 일정 시간 후 재시도

• Event-Driven Architecture
  • 메시징 시스템
    • 분산 시스템에서 서비스 간 데이터를 주고 받는 방식
    • 비동기 처리, 데이터 스트리밍, 이벤트 기반 아키텍처에 필수
    • 주요 개념
      • 프로듀서(Producer) : 메시지 생성 역할
      • 브로커(Broker) : 메시지를 저장하고 전달하는 중간 매개체
      • 컨슈머(Consumer): 메시지 소비 역할
      • 큐 (Queue) & 토픽 (Topic) : 메시지 저장 방식
    • Kafka vs RabbitMQ

      비교 항목	Kafka 🦁	RabbitMQ 🐰
      메시징 모델	로그 기반 (Pub/Sub, Stream Processing)	큐 기반 (Producer-Consumer, Message Queue)
      메시지 저장	디스크(로그) 저장, Consumer가 여러 번 읽을 수 있음	메모리 또는 디스크 큐에 저장, Consumer가 읽으면 삭제됨
      메시지 순서 보장	✅ (Partition 내에서 순서 보장)	✅ (FIFO Queue 사용 시)
      사용 사례	이벤트 스트리밍, 로그 수집, 실시간 데이터 처리	비동기 작업 처리, 백그라운드 작업, 요청-응답 메시징
      확장성	높음 (분산형 아키텍처, 수평 확장 가능)	제한적 (Cluster 구성 가능하지만 Kafka보다 어려움)
      처리 속도	매우 빠름 (고속 데이터 스트리밍 최적화)	빠름 (하지만 Kafka보다는 느림)
      메시지 보관 기간	설정 가능 (장기 보관 가능)	단기 (기본적으로 메시지를 소비하면 삭제됨)
      운영 관리	복잡 (Zookeeper 필요, 클러스터 운영 필요)	쉬움 (간단한 설정, 작은 규모에서도 사용 가능)
      트랜잭션 지원	❌ (일부 기능 제공하지만 완벽하지 않음)	✅ (메시지 보장 및 트랜잭션 지원)
      주요 프로토콜	TCP 기반, 독자적인 Kafka 프로토콜	AMQP(Advanced Message Queuing Protocol) 지원
      적합한 사용처	실시간 이벤트 스트리밍, 대용량 데이터 처리	비동기 작업 큐, 메시지 브로커 역할

• SAGA 패턴
  • 분산 트랜잭션을 관리하는 패턴
  • 여러 마이크로서비스에서 하나의 트랜잭션을 처리할 때, 단일 트랜잭션이 아니라 개별 서비스에서 작은 로컬 트랜잭션을 실행하고 보상(compensation) 로직을 수행하는 방식
  • 동작 방식 (2가지 구현 방식)
    • Choreography (코레오그래피) 방식
      1. 서비스들이 이벤트 기반으로 서로 트랜잭션을 조정
      2. 특정 서비스에서 이벤트를 발생시키면, 관련된 서비스들이 이벤트를 구독하고 응답
      3. 장점: 중앙 조정자가 없어 관리가 쉬움
      4. 단점: 서비스 간 결합도가 높아지고, 복잡한 이벤트 흐름 관리 필요
    • Orchestration (오케스트레이션) 방식**
      1. 중앙에서 SAGA Coordinator(조정자)가 각 서비스의 트랜잭션을 조율
      2. 조정자가 서비스 호출 및 보상 트랜잭션을 관리
      3. 장점: 서비스 간 결합도를 줄이고, 중앙에서 흐름을 제어 가능
      4. 단점: 중앙 집중식이기 때문에 Coordinator가 병목이 될 가능성 있음
  • 장점
    • 마이크로서비스 간 트랜잭션 일관성 유지 가능
    • 서비스 간 독립성 유지 (각 서비스는 자신의 로컬 트랜잭션만 관리)
    • 비동기 이벤트 처리 가능 → 성능 최적화
  • 단점
    • 오류 발생 시 보상 트랜잭션을 잘 설계해야 함
    • 복잡한 분산 시스템 환경에서는 디버깅이 어려움
    • 이벤트 순서 관리가 필요
• Event Sourcing
  • 데이터의 현재 상태를 저장하는 대신, 변경 이력을 이벤트 형태로 저장하는 방식
  • 모든 변경 사항이 이벤트 로그로 남아 있어 시점 복원(재구성)이 가능
  • 동작 방식
    1. 사용자의 요청이 들어오면 이벤트(event)를 생성
    2. 이벤트를 저장소(Event Store)에 저장
    3. 필요할 때 이벤트를 다시 읽어 상태를 재구성
  • 장점
    • 모든 변경 이력이 남아 있어 데이터 복구 및 감사(audit) 용이
    • 이벤트 재생 가능 → 과거 특정 시점으로 시스템 상태를 복원 가능
    • 이벤트 스트리밍 시스템(Kafka 등)과 결합해 실시간 데이터 처리 가능
  • 단점
    • 기존의 RDBMS 기반 트랜잭션 처리보다 구현이 복잡
    • 이벤트 저장소가 커질 경우 이벤트 리플레이 성능 저하 가능

참고자료

• 8_1.MSA와 모놀리틱 아키텍처 비교와 MSA 장단점 및 도입 시 고려사항