분산 트랜잭션의 은폐된 실패를 밝히다: In-Doubt 상태 감지 및 보상을 Python으로 검증하기

마이크로서비스 아키텍처에서 명시적인 오류가 가장 위험한 실패인 경우는 드뭅니다. HTTP 500 상태 코드, 포착되지 않은 예외(uncaught exception), 또는 실패한 gRPC 단언문은 접근 로그에 흔적을 남기고, 에러율 지표를 증가시키며, 경고를 발생시키고, 온콜 엔지니어들을 깨웁니다.

진정한 운영상의 악몽은 **조용한 데이터 불일치(silent data inconsistency)**입니다. 이는 처리되지 않은 예외가 발생하지 않음에도 불구하고, 부분적인 네트워크 타임아웃, 고아가 된 분산 상태(orphaned distributed states), 또는 손실된 보상 명령으로 인해 분산 상태가 점진적으로 동기화에서 벗어나는 경우를 말합니다.

이 글은 네트워크 타임아웃이 어떻게 서비스 경계를 가로질러 트랜잭션을 'In-Doubt' 상태에 빠지게 하는지 분석하고, 보상 트랜잭션 실패의 메커니즘을 검토하며, Python, Pydantic, orjson으로 구현된 엔드투엔드 조정(reconciliation) 도구를 상세히 설명하여 서비스 간 불일치를 감지하고 감사합니다.

1. 실패 해부학: 타임아웃이 분산 In-Doubt 상태를 만드는 방법

order-svc (주문 서비스)와 payment-svc (결제 서비스)가 관련된 다단계 결제 파이프라인을 가정해 봅시다. 중앙 집중식 2단계 커밋(two-phase commit, 2PC) 코디네이터가 부족한 일반적인 디커플링 아키텍처에서는, 서비스들이 코레오그래피(choreography) 또는 오케스트레이션 기반의 Saga 패턴에 의존합니다.

sequenceDiagram
    autonumber
    participant Client as "API Gateway / Client"
...

파티션의 해부학

1. 단계 1: order-svc는 로컬 주문 기록을 상태 COMMITTED로 영속화(persists)하고 커밋합니다.
2. 단계 2: order-svc는 payment-svc로 동기식 청구 요청을 디스패치합니다.
3. 단계 3 (네트워크 오류): 연결이 끊어지며, 이는 payment-svc가 트랜잭션을 수락하거나 시작한 이후 또는 리버스 프록시(reverse proxy)가 표준 5,000ms 임계값을 초과하여 타임아웃될 때 발생합니다.
4. 단계 4: order-svc는 소켓 타임아웃(ReadTimeoutError)을 감지하고 롤백 또는 보상 호출(compensation call)을 실행합니다.
5. 단계 5: 파티션 또는 라우팅 실패로 인해 보상 지시가 손실되거나 거부됩니다. order-svc는 오류를 플래그하지만, payment-svc는 불확실한 STARTED 또는 IN_DOUBT 상태로 남아 있습니다.

이 시점에서 표준 애플리케이션 성능 모니터링(APM) 도구들은 종종 분산된 추적 기록을 남깁니다. 상관관계 ID(correlation_id / X-Trace-Id)를 사용하여 서비스 전반에 걸쳐 수 기가바이트의 구조화된 로그에서 개별 스팬(span)을 추적하는 것은 오류가 발생하기 쉽고, 노동 집약적이며, 사고 후 분류 작업(post-incident triage) 중에는 확장성이 떨어집니다.

2. 서비스 간 불일치에 대한 기술 아키텍처 (Technical Architecture of Cross-Service Inconsistency)

재조정 메커니즘(reconciliation mechanisms)이 어떻게 작동하는지 이해하려면, 독립적인 영속 저장소(persistence stores) 전반의 트랜잭션 상태 수명 주기(transaction state lifecycle)를 공식화해야 합니다.

flowchart TD
    subgraph OrderCluster [클러스터: order-svc]
        O1[로컬 DB: Orders]
...

노드 전반의 트랜잭션을 평가할 때:

• 일관된 커밋 (Consistent Committed): order-svc와 payment-svc 모두 COMMITTED 상태에 도달합니다.
• 일관된 중단 (Consistent Aborted): order-svc는 ROLLED_BACK이고 payment-svc도 ROLLED_BACK입니다.
• 분산 불일치 (Divergent Inconsistency) (In-Doubt): 한 서비스는 COMMITTED를 기록하는 반면, 다운스트림(downstream) 서비스는 IN_DOUBT, STARTED를 기록하거나 보상 기록이 누락됩니다.

3. 빠르고 타입 안전한 검증 엔진 설계 (Designing a Fast, Type-Safe Verification Engine)

재조정 스캐너(reconciliation scanner)를 구축하려면 세 가지 실질적인 분산 로깅 제약 조건(distributed logging constraints)을 해결해야 합니다:

1. 타임스탬프 드리프트 및 형식 불일치: 노드들은 일관되지 않은 UTC 표기법(Z vs +00:00 vs 네이티브 타임스탬프)을 가진 타임스탬프를 자주 출력합니다.
2. 데이터 처리량 (Data Throughput): 로그 집계 스트림은 수백만 개의 행(row)을 방출합니다. 표준 Python의 json.loads 오버헤드는 병목 현상을 일으키므로, orjson을 사용한 빠른 직렬화가 필수적입니다.
3. 스키마 유효성 검사 (Schema Validation): 형식이 잘못된 JSON 라인이나 불완전한 로그 항목이 처리 루프를 멈추게 해서는 안 됩니다.

전체 Python 구현

다음 도구는 다중 서비스 로그 항목을 처리하고, 트랜잭션 식별자(correlation_id)별로 상태를 그룹화하며, ISO 8601 타임스탬프를 검증하고, 불완전하거나 불확실한 상태에 갇힌(trapped) 트랜잭션을 식별합니다.

import orjson
import logging
import sys
...

💡 즉시 배포용: 이 아키텍처의 전체 소스 코드 스위트 (ZIP)는 Gumroad에서 $0+ (원하는 만큼 지불)로 이용 가능합니다.

4. 아키텍처적 완화 전략 (Architectural Mitigation Strategies)

로그 파싱 및 조정(reconciliation)을 통해 불일치를 감지하는 것은 필수적인 안전망이지만, 복원력 있는 아키텍처는 또한 런타임에서 In-Doubt 상태가 전파되는 것을 방지하기 위한 패턴들을 구현합니다:

1. Transactional Outbox Pattern: 다운스트림 서비스에 동기식 HTTP/gRPC 호출을 데이터베이스 트랜잭션 경계 내에서 직접 실행하는 대신, 도메인 엔티티와 OutboxEvent를 동일한 데이터베이스에 원자적으로(atomically) 기록합니다. 비동기 릴레이(Debezium을 통한 CDC 또는 폴링 워커)가 아웃박스를 읽어 지속 가능한 브로커(Apache Kafka 또는 RabbitMQ)로 이벤트를 발행합니다.
2. Idempotency Keys: 다운스트림 소비자(예: payment-svc)가 고유성 토큰(X-Idempotency-Key)을 저장하도록 보장해야 합니다. 네트워크 시간 초과로 인해 이미 시작된 작업이 재시도될 경우, 서비스는 실패하거나 중복 트랜잭션을 생성하는 대신 기존 결과를 반환합니다.
3. Dead Letter Queues (DLQ) & Compensating Workflows: 보상 엔드포인트에 대한 재시도가 지수 백오프(exponential backoff) 임계값에 도달한 후에도 실패할 경우, 페이로드를 자동화된 조정 큐로 전달합니다. 백그라운드 재조정기(reconciler)가 이 DLQ를 읽고 데이터베이스 전반의 현재 상태를 평가하며, 수정적인 도메인 작업을 실행합니다.

요약

분할(partitions)이 발생할 때 신뢰할 수 없는 네트워크 전반에 걸쳐 엄격한 제로 손실 분산 일관성(distributed consistency)을 달성하는 것은 CAP 정리(CAP theorem) 하에서 수학적으로 불가능합니다. 하지만 시스템은 **멱등 사가 실행(idempotent Saga execution)**과 **자동화된 조정 스캐너(automated reconciliation scanners)**를 결합하여 높은 복원력(resilience)을 달성합니다. 분산 트랜잭션 텔레메트리(telemetry)를 수집하고 상태 차이(state differentials)를 명시적인 불일치 모델(discrepancy models)로 구문 분석함으로써, 엔지니어링 팀은 조용한 손상(silent corruption)이 프로덕션 워크로드에 영향을 미치기 전에 데이터 무결성을 지속적으로 검증하고 복구할 수 있습니다.

만약 이 엔지니어링 로그가 귀하의 프로덕션 서버(그리고 정신 건강)를 구했다면, GitHub Sponsors에서 저희 아키텍처를 지원하는 것을 고려해 주십시오.