04 MSA 데이터 정합성

1. Note

• 당연한 것들에 대한 정의
  • 데이터는 당연히 일치해야하고,
  • 안정성을 유지해야하는데
  • 그 방법들에 대한 정의를 함.
• 데이터 정합성이라는 개념이 있고
  • 이것을 해결하기위한 여러가지 방법들이 있는데,
  • MSA고 Database per Service라서 정합성 맞추기가 조금더 복잡해진 상황
  • 특별한 패턴만을 고집해서 사용하지는 않고
  • 여러 패턴을 활용해서 필요한 것들을 작업함.
  • 디자인패턴과 비슷한 느낌으로 파악!

2. 데이터 정합성

1. 데이터 정합성(Data Consistency)

• 시스템 전체 데이터가 논리적으로 올바르고 서로 모순되지 않는 상태
• 여러 서비스와 데이터베이스에 데이터가 분산되어 있더라도
• 비즈니스적으로 올바른 상태가 유지되는가

2. 데이터 정합성의 불일치

• 기술적인 오류를 넘어서 실제 비즈니스 장애로 이루어짐
  • 결제는 완료했는데, 주문은 실패함
  • 주문 실패했는데 재고는 차감됨
  • 결제 실패했는데 포인트 차감
• 비즈니스 자체의 비즈니스 신뢰 문제가됨.

3. 데이터 정합성 문제

1. 모놀리식과 MSA 정합성 문제

1. 모놀리식 환경

• 하나의 애플리케이션이 하나의 데이터베이스를 공유
  • User/Order/Payment/Inventory -> Single Database
  • 모든 작업이 하나의 DB 트랜잭션 내부에서 수행
• 모두 성공하거나 모두 실패(All-or-Nothing)하는 결과

2. MSA 환경

• Database-per-Service 구조를 사용

  Order Service      → Order DB
  Payment Service    → Payment DB
  Inventory Service  → Inventory DB
  

  • 하나의 비즈니스 요청이 여러 서비스에 걸쳐 수행
• 하나의 트랜잭션으로 묶을 수 없고, 서비스별 트랜잭션에 의존해야함.

2. MSA 발생하는 문제

• 분산 트랜잭션 문제
  • 여러 DB를 하나처럼 관리하기 어려움
  • Order DB, Payment DB, Inventory DB가 각각 분리되어 있어, 하나의 트랜잭션으로 묶지 못함.
• 데이터 불일치
  • 일부 성공하고 일부 실패하는 현상
  • 사용자는 결제를 완료했지만 재고는 반영에서 장애가 나서 시스템 데이터가 서로 맞지 않는 상태
• 즉시 롤백 불가능
  • 이미 완료된 작업 되돌리기 어려움
  • 이미 완료된 결제를 직접 취소(환불)하는 별도 로직이 필요
• 서비스 간 상태 불일치
  • 주문 상태와 결제 상태가 다를 수 있음
  • 이벤트 전달 지연 또는 실패로 인해 서로 다른 상태를 바라보는 문제가 발생

4. 정합성 모델 (무엇을 목표로 하는가)

1. Strong Consistency (강한 정합성)

• 데이터 변경 직후 모든 시스템이 즉시 동일한 값을 바라보는 정합성 모델

• 흐름

  데이터 변경
  - 즉시 모든 곳에 반영
  - 항상 같은 데이터 조회
  

• 특징
  • 즉시 데이터 일치
  • 데이터 불일치 허용 X
  • 강한 트랜잭션 기반
  • 주로 단일 DB 환경에서 사용

• 장단점

  구분	내용
  장점	항상 정확한 데이터 보장 데이터 불일치 최소화 금융/결제 시스템에 적합
  단점	성능 저하 가능성 서비스 간 강한 결합 분산 환경 확장 어려움

2. Eventual Consistency (최종 일관성)

• 데이터가 즉시 일치하지 않더라도 시간이 지나면 결국 일관된 상태가 되는 모델
• 흐름

  데이터 변경
  → 잠시 불일치 가능
  → 일정 시간 후 동기화
  → 최종적으로 일치
  

• 특징
  • 즉시 정합성 보장 X
  • 비동기 이벤트 기반
  • 분산 시스템 친화적
  • 확장성과 가용성 우수

• 장단점

  구분	내용
  장점	높은 확장성 장애 격리 우수 서비스 독립성 향상
  단점	순간적인 데이터 불일치 허용 구현 복잡도 증가 정합성 보장 로직 필요

5. 정합성 해결 전략

1. 강한 정합성 전략

1. 2PC (Two-Phase Commit) 전략

• 특징
  • 여러 서비스와 데이터베이스를 하나의 트랜잭션처럼 처리하는 방식
  • 모든 참여 서비스(Participant)의 상태를 확인한 후 최종 Commit 또는 Rollback을 결정
• 적합한 컨텍스트 유형
  • 금융 시스템
  • 절대 데이터 오류가 허용되지 않는 환경
  • 강한 정합성이 필요한 경우

• 흐름

  1단계: Prepare
  Order DB 준비 완료
  Payment DB 준비 완료
  Inventory DB 준비 완료
    
  2단계: Commit
  전체 Commit
  

• 장단점

  구분	내용
  장점	- 강한 정합성 보장 - All-or-Nothing 트랜잭션 가능 - 데이터 불일치 최소화
  단점	- Coordinator 장애 시 전체 중단 가능 - Commit 전 Lock 유지로 성능 저하 가능 - 서비스 간 강한 결합 발생 - MSA 확장성과 독립성 저하

2. 분산 트랜잭션 전략

1. Saga Pattern

• 특징
  • 하나의 큰 비즈니스 트랜잭션을 여러 개의 로컬 트랜잭션(Local Transaction)으로 분리하는 방식
  • 각 서비스는 자신의 DB에 대해 독립적으로 Commit 수행
  • 중간 실패 발생 시, 이전 작업을 취소하는 보상 트랜잭션(Compensation Transaction) 수행
  • DB Rollback 대신 비즈니스 Rollback 방식 사용
  • MSA 환경에서 가장 널리 사용되는 분산 트랜잭션 패턴
• 적합한 컨텍스트 유형
  • 일반적인 MSA 환경
  • 서비스 독립성이 중요한 시스템
  • Event-Driven Architecture 기반 구조
  • 높은 확장성이 필요한 서비스

• 흐름

  주문 생성 성공
  - 결제 성공
  - 재고 차감 실패
  ↓ (보상 트랜잭션 진행)
  결제 취소
  주문 취소
  

• 장단점

  구분	내용
  장점	- 서비스 독립성 유지 - 높은 확장성 - 장애 격리 우수 - MSA 친화적
  단점	- 즉시 정합성 보장 어려움 - 보상 트랜잭션 구현 필요 - 상태 관리 복잡성 증가 - 일시적 데이터 불일치 가능

2. TCC (Try-Confirm-Cancel) 전략

• 특징
  • 실제 처리 전에 임시 예약(Try) 상태를 두고 최종 확정(Confirm)하는 분산 트랜잭션 방식
  • Try → Confirm → Cancel 3단계로 동작
  • 실패 시 DB Rollback 대신 Cancel 로직으로 예약 상태를 취소
  • Saga보다 강한 정합성을 제공하지만 구현 복잡도가 높음
  • 서비스별로 Try / Confirm / Cancel API 구현 필요
• 적합한 컨텍스트 유형
  • 좌석 예약 시스템
  • 재고 선점이 필요한 주문 시스템
  • 결제 예약/승인 시스템
  • 즉시 정합성이 상대적으로 중요한 경우
• 흐름

  Try
  재고 임시 예약
  결제 승인 대기
    
  #Confirm
  결제 성공
  재고 최종 차감
  주문 확정
    
  # Cancel
  재고 예약 취소
  주문 취소
  

• 장단점

  구분	내용
  장점	- Saga보다 강한 정합성 제공 - 자원 선점 가능(재고/좌석) - 부분 실패 대응에 유리
  단점	- 구현 난이도 높음 - 서비스별 Try/Confirm/Cancel API 필요 - 상태 관리 복잡성 증가 - 개발 비용 증가

3. 이벤트 기반 정합성 전략

1. Outbox Pattern 전략

• 특징
  • 데이터 저장(DB Commit)과 이벤트 발행(Event Publish) 간 정합성을 보장하기 위한 패턴
  • 비즈니스 데이터 저장과 이벤트 정보를 Outbox Table에 함께 저장
  • 하나의 트랜잭션으로 처리하여 데이터 저장 성공 후 이벤트 유실 문제 방지
  • 이후 별도 프로세스가 Outbox 데이터를 읽어 이벤트(Kafka 등)를 발행
  • Event-Driven Architecture에서 자주 사용됨
• 적합한 컨텍스트 유형
  • Kafka 기반 이벤트 시스템
  • Event-Driven Architecture
  • 데이터 저장과 이벤트 발행의 정합성이 중요한 환경
• 흐름

  주문 생성
  ↓
  Order Table 저장
  Outbox Table 저장 
  (동일 트랜잭션)  
  ↓
  Outbox Reader (다른 프로세스 / 시스템이 아웃박스를 읽음)
  ↓
  Kafka 이벤트 발행
  

• 장단점

  구분	내용
  장점	- 이벤트 유실 방지 - DB와 이벤트 정합성 보장 - Kafka 기반 구조와 궁합 좋음
  단점	- Outbox Table 추가 관리 필요 - Polling/Consumer 구현 필요 - 운영 복잡도 증가

2. CDC (Change Data Capture) 전략

• 특징
  • 데이터베이스 변경 사항(INSERT / UPDATE / DELETE)을 감지하여 이벤트로 전송하는 방식
  • 애플리케이션 코드 수정 없이 DB 변경만으로 이벤트 생성 가능
  • 보통 Binlog(MySQL), WAL(PostgreSQL) 기반으로 동작
  • Kafka와 함께 데이터 동기화 용도로 자주 사용
  • 레거시 시스템 연동에 유리
• 적합한 컨텍스트 유형
  • 레거시 시스템 연동
  • DB 중심 데이터 파이프라인
  • 실시간 데이터 동기화 환경
  • Kafka 기반 이벤트 아키텍처
• 흐름

  Order DB 데이터 변경
  ↓
  CDC 감지
  ↓
  Kafka 이벤트 생성
  ↓
  다른 서비스 동기화
  

• 장단점

  구분	내용
  장점	- 애플리케이션 수정 최소화 - 실시간 데이터 동기화 가능 - 레거시 연동에 유리
  단점	- DB 종속성 존재 - 운영 난이도 증가 - 이벤트 순서/중복 처리 고려 필요

6. 공통 기반 개념

1. 보상 트랜잭션 (Compensation Transaction)

1. 특징

• MSA 환경에서 실패한 작업을 되돌리기 위한 비즈니스 기반 Rollback 방식
• DB Transaction의 ROLLBACK과 달리, 이미 Commit된 작업을 새로운 작업으로 취소
• Saga Pattern에서 핵심적으로 사용되는 개념
• 서비스 간 정합성을 맞추기 위해 실패 시 역방향 처리 수행

2. DB Rollback과 차이

구분	DB Rollback	Compensation Transaction
처리 시점	Commit 이전	Commit 이후
처리 방식	DB 원복	비즈니스 취소
사용 환경	Monolith	MSA / Saga

2. 멱등성 (Idempotency)

1. 특징

• 동일한 요청이 여러 번 실행되어도 결과가 항상 동일하게 유지되는 특성
• Retry(재시도), Kafka 재전송 환경에서 필수 개념
• 중복 메시지 처리로 인한 데이터 오류 방지
• 보통 Idempotency Key, Event ID 등을 활용하여 구현

2. 필요포인트

• Kafka는 메시지 중복 수신 가능
• Retry 전략은 동일 요청 재실행 가능
• 분산 환경에서는 네트워크 장애가 빈번함

3. 상태 관리 (State Management)

1. 특징

• 여러 서비스에 걸친 분산 프로세스의 진행 상태를 추적하는 방식
• Saga Pattern, Orchestration 구조에서 중요하게 사용
• 현재 어떤 단계까지 성공했는지 기록
• 실패 시 어떤 보상 트랜잭션을 실행할지 결정하는 기준이 됨

2. 흐름

• 성공 CASE

  주문 생성 완료
  - 결제 완료
  - 배송 대기
    
  # 주문번호 1001 / PAYMENT_COMPLETED
  # 주문번호 1002 / PAYMENT_COMPLETED
  

• 실패 CASE

  배송 실패
  ↓
  현재 상태 확인
  ↓
  결제 취소 실행
    
  # 주문번호 1002 / Fail 
  # 1002번은 재실행 필요
  

3. 필요 포인트

• 분산 환경에서는 전체 흐름을 한 번에 알 수 없음
• 부분 실패 시 복구 기준 필요
• Orchestrator가 프로세스 제어 시 상태 기반 처리 수행