정산 시스템 실전 구축: MASS의 기술 선택과 아키텍처

들어가며

이전 글에서 MASS 정산 시스템의 설계 원칙(멱등성, 결정적 계산)을 다룬 데 이어, 본 글에서는 실제 기술 선택과 구조를 통한 구현 과정을 상세히 설명합니다.

멱등성을 전제로 한 이벤트 처리

• 핵심: 이벤트 재시도(Retry)와 격리(DLT)를 분리하고, 트랜잭션 식별자로 서비스 레벨 멱등 갱신을 통해 장애 상황에서도 안전한 재처리 기반 마련.
• DLT 처리: DLT 발생 시 즉시 알림, 원본 컨텍스트 유지 저장, 원인 분석 및 재처리 기준 수립.
• 운영 현황: DLT 발생 비율 0.001% 미만으로, 결과 정합성이 중요한 도메인에서 설계 의도 유지.

MASS 모듈 구성

• mass-consumer: Kafka로 이벤트 수신, 멱등 저장, 정산 원천 데이터 저장 (진입점).
• mass-batch: 일/월 정산, 집계, 마감, 리포트 생성 (재처리와 복구 전제).
• mass-api: 운영자/파트너 대상 REST API 제공 (조회 및 관리).

재처리와 복구를 전제로 한 실행 구조

• 정산 상태 관리: PENDING → PROCESSING → COMPLETED 상태 전이를 통한 배치 실행 흐름 관리.
• 배치 실행: 시작 시 대상 데이터 마킹(PENDING→PROCESSING), chunk 단위 처리, 완료 시 상태 변경(COMPLETED).
• 실패 시 롤백: 중간 실패 시 PROCESSING → PENDING으로 롤백하여 전체 정산 대상 기준으로 재처리.
• 재시도 방식: 이전 실행 결과 불필요, 재마킹 후 멱등성 기반 upsert 방식으로 재수행하여 항상 동일한 결과 보장.
• 사례: 재고 스냅샷 이슈 시 12월 3일 데이터만 롤백 후 재처리하여 정합성 유지.

이벤트 + 배치 하이브리드 구조

• 이벤트 기반: 실시간 데이터 반영 위한 원천 데이터 수집 및 멱등 저장 (빠른 수집 초점).
• 배치 기반: 안정성 및 재현성 높은 정산 확정 및 마감, 리포트 생성, 복구용 배치 운영 (안정성 우선).
• 목적: 실시간 데이터 가시성과 회계 마감의 안정성 동시 만족.

기술 선택 및 배경

• 핵심 기준: 정합성, 재처리 가능성, 운영 안정성.
• 기술 스택: JVM(Kotlin), Spring Boot/Batch, Kafka, MySQL, Kubernetes(EKS), Argo Workflow.

Kafka (원천 데이터 수신)

• 비동기 적재, 데이터 유실 방지, 재처리 용이성.
• "빨리 처리"보다 "언제든 다시 처리 가능"해야 하는 정산 데이터 특성에 적합.

Spring Batch (정산 처리)

• 실시간성 < 명확한 실행 시점, 재처리/복구 구조, 감사 가능성.
• Kubernetes 환경에서 Argo Workflow를 통한 외부 제어 방식으로 배치 실행 및 복구 관리.
• Job Parameter 기반 실행으로 기준별 이력 추적 용이.
• Chunk 단위 처리, 실패 시 재실행 제어 기능으로 안정적 운영 지원.

MySQL (데이터베이스)

• 트랜잭션 처리가 명확한 RDB를 Source of Truth로 선택.
• 정산 결과 정합성, 트랜잭션 관리, 멱등성 갱신 보장.

운영 / 모니터링 체계

• 목표: 장애 빠른 인지, 영향 범위 통제.
• 구성: 배치 실행 상태/로그 모니터링, DLT/실패 알림 연계, 에러/Latency/인프라 지표 모니터링, 주 단위 시스템 점검.
• 결과: 사전 신호 감지 및 선제적 조치 운영 방식.

마치며

MASS는 Kafka, Spring Batch 등을 활용하여 실패와 재실행을 자연스럽게 받아들이는 구조로 정산을 안정적으로 구현했습니다. 다음 글에서는 시스템 오픈 및 운영 성과를 다룹니다.