[식구하자_MSA] Saga 패턴 이후의 추가 장애 대응: 신뢰성 높은 결제 시스템 구축하기 By Kafka - 1

지난 포스팅 Saga 패턴은 분산 트랜잭션 관리에 큰 도움을 주지만, 결제 시스템과 같이 높은 신뢰성이 요구되는 환경에서는 추가적인 장애 대응이 필요합니다. 오늘은 식구하자 프로젝트에서 적용한 추가 장애 대응 방안에 대해 개념 위주로 정리를 하고
각 장애 대응 방안을 구축하는 방법들은 이후 포스팅에 정리를 할 계획입니다!

👉👉SAGA 패턴 적용 포스팅
👉👉Github 참고

지난 포스팅 SAGA Choreography 적용 요약

지난 포스팅에서 MSA 환경에서의 분산 트랜잭션 제어를 위해 SAGA 패턴을 적용했습니다. 주요 내용은 다음과 같습니다!

1. 분산 트랜잭션 문제: 쿠폰 서비스와 결제 서비스가 각각 독립적인 DB를 사용하면서 발생하는 데이터 일관성 문제를 해결하고자 했습니다.

2. SAGA 패턴 선택: 여러 SAGA 패턴 중 Choreography 방식을 선택했습니다. 이는 간단한 워크플로우에 적합하고 추가 서비스 구현이 필요 없어 세팅이 간단하기 때문입니다.

3. 정상 흐름:

   • 쿠폰 사용 요청
   • 쿠폰 서비스에서 쿠폰 사용 이벤트 발행
   • 결제 서비스에서 쿠폰 사용 이벤트 구독
   • 결제 처리
   • 결제 성공

4. 보상 트랜잭션 발생 과정:

   • 결제 서비스에서 트랜잭션 실패 발생
   • 결제 서비스에서 쿠폰 사용 롤백 이벤트 발행
   • 쿠폰 서비스에서 롤백 이벤트 구독
   • 쿠폰 사용 취소 처리

🔎 문제 상황 인지

만약 결제 마이크로 서비스에서 문제가 발생했는데 보상 트랜잭션 이벤트를 발행을 하기전에 서버가 죽어버리면..?
SAGA 패턴을 적용했음에도 불구하고 분산 트랜잭션을 제어하지 못하고 말짱 도루묵이 되버립니다,,,

각 상황별 문제를 자세히 따져보고 대응 방안을 알아보도록 하겠습니다!

1. 서버 다운 시 보상 트랜잭션 문제

---

💡 문제 상황

Saga 패턴을 적용했지만, kafka에서 이벤트를 발생시키기 전에 서버가 갑자기 다운되면 보상 트랜잭션이 실행되지 않는 데이터 일관성 문제가 있을수도 있습니다

🛠 해결 방안: 트랜잭션 아웃박스 패턴 + Kafka Connect

• 트랜잭션 아웃박스 패턴: 보상 트랜잭션 이벤트를 DB의 outbox 테이블에 먼저 저장
• Kafka Connect와 CDC(Change Data Capture): outbox 테이블의 변경사항을 감지하여 자동으로 Kafka 이벤트 발행
• 장점: 서버 다운 시에도 DB에 저장된 보상 트랜잭션 이벤트 정보를 기반으로 안전하게 처리 가능

2. 멱등성 보장과 카프카 클러스터 구성

---

💡 추가 고려사항

1. 멱등성 프로듀서 설정

   • 목적: 중복 이벤트 처리 방지
   • 방식: 카프카 프로듀서의 멱등성 옵션 활성화

2. 카프카 클러스터 구성

   • 목적: 단일 브로커 장애 대비, 가용성 향상
   • 방식: 3개의 브로커로 카프카 클러스터 구성
   • 특징: 팔로워에게 복제 확인을 통한 데이터 안정성 보장

3. 신뢰성 있는 시스템 구축 단계 개요

---

1. 카프카 클러스터 구성 (3개 브로커)
2. 트랜잭션 아웃박스 패턴 구현
3. Kafka Connect 및 CDC 설정
4. 멱등성 프로듀서 설정
5. 모니터링 및 알림 시스템 구축

4. trade-off

---

• 장점: 높은 가용성과 신뢰성 확보
• 단점: 일부 지연 시간 발생
• 결론: 결제 시스템의 특성상 정확성과 신뢰성이 더 중요하다고 판단하여 채택

우선 해당 포스팅에서는 간략히 정리 해 봤고 다음 포스팅에서부터 각 장애 대응 방안의 구체적인 구현 방법과 설정, 그리고 실제 테스트 결과에 대해 더 자세히 다뤄보도록 하겠습니다. 감사합니다 🙏

참고 :

• 트랜잭션 아웃박스 패턴 알아보기
• Implementing the Outbox Pattern
• CDC 기반 마이크로서비스 간 데이터 동기화

---