Quartz 4

MSA 분산 트랜젝션 - 완전 가이드

22 min read

🎯 MSA 분산 트랜젝션 완전 가이드

작성 시간: 2025-11-30 15:16 KST

📑 목차

1. 분산 트랜젝션 기본 개념

핵심 개념

분산 트랜젝션은 여러 개의 독립적인 시스템이나 데이터베이스에서 일관성을 보장하면서 데이터를 조작하는 트랜젝션입니다.

💡 ACID 특성과 분산 환경의 한계

🤔 질문: “단일 시스템의 ACID가 분산 환경에서는 왜 보장하기 어려울까?”

📋 ACID 특성 분석

단일 vs 분산 환경 비교

  1. Atomicity: 단일 DB에서는 롤백 가능, 분산에서는 부분 실패 발생
  2. Consistency: 각 서비스의 비즈니스 규칙이 다름
  3. Isolation: 네트워크 지연으로 Lock 관리 복잡
  4. Durability: 각 시스템의 백업/복구 정책이 상이

💻 CAP 정리와의 관계

# 📊 CAP 정리 적용 예시
분산_시스템_특성:
  일관성(Consistency):
    - 모든 노드가 동일한 데이터를 가짐
    - Strong Consistency vs Eventual Consistency
  
  가용성(Availability):
    - 시스템이 항상 응답 가능
    - 부분 장애시에도 서비스 지속
  
  분할내성(Partition tolerance):
    - 네트워크 분할시에도 동작
    - 필수적으로 지원해야 함

📊 분산 트랜젝션 복잡성 비교

측면단일 시스템분산 시스템
일관성 보장데이터베이스 엔진애플리케이션 로직
장애 처리자동 롤백보상 트랜젝션
성능빠름네트워크 오버헤드
복잡성낮음매우 높음

2. MSA 환경에서의 도전과제

주요 문제점들

네트워크 파티션, 부분 실패, 데이터 일관성 문제가 동시에 발생할 수 있습니다.

💡 네트워크와 부분 실패 문제

🤔 질문: “주문 처리 중 결제 서비스만 실패하면 어떻게 될까?”

📋 전형적인 장애 시나리오

이커머스 주문 처리 장애

  1. 주문 생성: 성공 (Order Service)
  2. 재고 차감: 성공 (Inventory Service)
  3. 결제 처리: 실패 (Payment Service)
  4. 배송 준비: 대기 상태 (Shipping Service)

문제: 주문과 재고는 변경되었으나 결제는 실패한 불일치 상태

💻 분산 환경의 장애 패턴

// 🚨 분산 트랜젝션 실패 시나리오
interface TransactionStep {
  service: string;
  action: string;
  status: 'success' | 'failed' | 'timeout';
  compensationAction?: string;
}
 
const orderTransaction: TransactionStep[] = [
  { service: 'order', action: 'createOrder', status: 'success', compensationAction: 'cancelOrder' },
  { service: 'inventory', action: 'reserveStock', status: 'success', compensationAction: 'releaseStock' },
  { service: 'payment', action: 'processPayment', status: 'failed' },  // 여기서 실패
  { service: 'shipping', action: 'scheduleShipping', status: 'timeout' }
];

📊 장애 유형별 대응 전략

장애 유형특징대응 방안
네트워크 지연일시적 응답 지연재시도 + 타임아웃
부분 실패일부 서비스만 실패보상 트랜젝션
네트워크 분할서비스 간 통신 단절이벤트 저장 + 재처리
데이터 불일치서로 다른 상태최종 일관성 + 조정

3. 분산 트랜젝션 패턴들

패턴 선택 기준

비즈니스 요구사항, 일관성 수준, 성능 요구사항에 따라 적절한 패턴을 선택해야 합니다.

💡 Two-Phase Commit (2PC) 패턴

🤔 질문: “강한 일관성이 필요할 때 2PC를 어떻게 구현할까?”

📋 2PC 동작 과정

2PC 단계별 처리

Phase 1 (Prepare):

  1. 코디네이터가 모든 참여자에게 “Prepare” 요청
  2. 각 참여자가 트랜젝션 준비 상태 확인
  3. “Yes” 또는 “No” 응답

Phase 2 (Commit/Abort):

  1. 모든 참여자가 “Yes”면 “Commit” 명령
  2. 하나라도 “No”면 “Abort” 명령
  3. 참여자들이 최종 커밋 또는 롤백 실행

💻 2PC 구현 예시

// 📊 2PC 코디네이터 구현
class TwoPhaseCommitCoordinator {
  private participants: TransactionParticipant[] = [];
  private transactionId: string;
 
  async executeTransaction(operations: TransactionOperation[]): Promise<boolean> {
    this.transactionId = generateTransactionId();
    
    try {
      // Phase 1: Prepare
      const prepareResults = await Promise.all(
        this.participants.map(participant => 
          participant.prepare(this.transactionId, operations)
        )
      );
      
      if (prepareResults.every(result => result === 'YES')) {
        // Phase 2: Commit
        await Promise.all(
          this.participants.map(participant => 
            participant.commit(this.transactionId)
          )
        );
        return true;
      } else {
        // Phase 2: Abort
        await Promise.all(
          this.participants.map(participant => 
            participant.abort(this.transactionId)
          )
        );
        return false;
      }
    } catch (error) {
      await this.handleCoordinatorFailure();
      return false;
    }
  }
 
  private async handleCoordinatorFailure(): Promise<void> {
    // 코디네이터 실패시 복구 로직
    // 로그 기반으로 상태 복구
  }
}

📊 2PC 장단점 분석

측면장점단점
일관성강한 일관성 보장블로킹 프로토콜
성능예측 가능한 동작높은 대기 시간
가용성데이터 정합성 우선코디네이터 SPOF
적용금융, 핵심 업무고성능 요구사항 부적합

💡 Saga 패턴

🤔 질문: “롱런닝 트랜젝션을 어떻게 관리할까?”

📋 Saga 패턴의 두 가지 구현 방식

Choreography vs Orchestration

Choreography (이벤트 기반):

  • 각 서비스가 독립적으로 다음 단계 결정
  • 이벤트 발행/구독으로 연결
  • 분산된 제어, 느슨한 결합

Orchestration (중앙 제어):

  • 중앙 오케스트레이터가 전체 플로우 관리
  • 명시적인 제어 흐름
  • 집중된 비즈니스 로직

💻 Saga Orchestration 구현

// 📊 Saga 오케스트레이터 구현
class OrderSagaOrchestrator {
  private steps: SagaStep[] = [
    { service: 'order', action: 'createOrder', compensation: 'cancelOrder' },
    { service: 'payment', action: 'processPayment', compensation: 'refundPayment' },
    { service: 'inventory', action: 'reserveStock', compensation: 'releaseStock' },
    { service: 'shipping', action: 'scheduleShipping', compensation: 'cancelShipping' }
  ];
 
  async executeSaga(orderData: OrderData): Promise<SagaResult> {
    const sagaId = generateSagaId();
    const executedSteps: SagaStep[] = [];
    
    try {
      for (const step of this.steps) {
        const result = await this.executeStep(step, orderData);
        if (result.success) {
          executedSteps.push(step);
        } else {
          // 실패시 보상 트랜젝션 실행
          await this.executeCompensation(executedSteps.reverse());
          return { success: false, error: result.error };
        }
      }
      return { success: true, sagaId };
    } catch (error) {
      await this.executeCompensation(executedSteps.reverse());
      throw error;
    }
  }
 
  private async executeCompensation(stepsToCompensate: SagaStep[]): Promise<void> {
    for (const step of stepsToCompensate) {
      if (step.compensation) {
        try {
          await this.callService(step.service, step.compensation);
        } catch (compensationError) {
          // 보상 실패시 로깅 및 수동 개입 필요
          await this.logCompensationFailure(step, compensationError);
        }
      }
    }
  }
}

📊 Saga 패턴 비교

특성ChoreographyOrchestration
제어분산형중앙집중형
복잡성이벤트 추적 어려움단일 지점 관리
결합도낮음중간
디버깅어려움상대적 용이
성능병렬 처리 가능순차적 처리

💡 Event Sourcing 패턴

🤔 질문: “상태가 아닌 이벤트로 시스템을 어떻게 구축할까?”

📋 Event Sourcing 핵심 개념

이벤트 기반 상태 관리

  1. 상태 저장 안 함: 현재 상태 대신 변경 이벤트만 저장
  2. 상태 재구성: 저장된 이벤트들을 순서대로 재생하여 현재 상태 계산
  3. 불변성: 이벤트는 한번 저장되면 변경되지 않음
  4. 완전한 감사: 모든 변경 이력이 보존됨

💻 Event Sourcing 구현

// 📊 Event Store 및 Aggregate 구현
interface DomainEvent {
  eventId: string;
  aggregateId: string;
  eventType: string;
  eventData: any;
  timestamp: Date;
  version: number;
}
 
class OrderAggregate {
  private orderId: string;
  private status: OrderStatus;
  private items: OrderItem[];
  private version: number = 0;
  private uncommittedEvents: DomainEvent[] = [];
 
  // 이벤트 적용
  apply(event: DomainEvent): void {
    switch (event.eventType) {
      case 'OrderCreated':
        this.handleOrderCreated(event);
        break;
      case 'OrderItemAdded':
        this.handleOrderItemAdded(event);
        break;
      case 'OrderCancelled':
        this.handleOrderCancelled(event);
        break;
    }
    this.version = event.version;
  }
 
  // 비즈니스 로직
  addOrderItem(item: OrderItem): void {
    if (this.status === OrderStatus.Cancelled) {
      throw new Error('Cannot add item to cancelled order');
    }
    
    const event: DomainEvent = {
      eventId: generateEventId(),
      aggregateId: this.orderId,
      eventType: 'OrderItemAdded',
      eventData: item,
      timestamp: new Date(),
      version: this.version + 1
    };
    
    this.apply(event);
    this.uncommittedEvents.push(event);
  }
 
  getUncommittedEvents(): DomainEvent[] {
    return [...this.uncommittedEvents];
  }
 
  markEventsAsCommitted(): void {
    this.uncommittedEvents = [];
  }
}
 
class EventStore {
  async saveEvents(aggregateId: string, events: DomainEvent[], expectedVersion: number): Promise<void> {
    // 낙관적 동시성 제어
    const currentVersion = await this.getAggregateVersion(aggregateId);
    if (currentVersion !== expectedVersion) {
      throw new ConcurrencyError('Aggregate version mismatch');
    }
    
    // 이벤트 저장
    await this.persistEvents(events);
  }
 
  async getEvents(aggregateId: string, fromVersion?: number): Promise<DomainEvent[]> {
    return await this.loadEvents(aggregateId, fromVersion);
  }
}

📊 Event Sourcing 장단점

측면장점단점
감사성완전한 변경 이력복잡한 쿼리
복구특정 시점 복원 가능스냅샷 필요
성능쓰기 최적화읽기 성능 고려
확장성이벤트 기반 확장스키마 진화 복잡

4. 실제 구현 전략

실무 적용 가이드

패턴을 조합하고 도구를 활용하여 실제 프로덕션에서 사용할 수 있는 구현 방안을 제시합니다.

💡 Outbox 패턴과 CDC

🤔 질문: “데이터베이스 업데이트와 이벤트 발행을 원자적으로 어떻게 처리할까?”

📋 Outbox 패턴 구현

트랜잭션 보장 메시징

  1. 로컬 트랜젝션: 비즈니스 데이터와 Outbox 이벤트를 같은 트랜젝션에서 저장
  2. CDC 감지: Change Data Capture로 Outbox 테이블 변경 감지
  3. 이벤트 발행: 별도 프로세스가 이벤트를 메시지 브로커로 전송
  4. 중복 제거: 멱등성 키로 중복 처리 방지

💻 Outbox 패턴 구현 코드

// 📊 Outbox 패턴 구현
interface OutboxEvent {
  id: string;
  aggregateId: string;
  eventType: string;
  payload: any;
  createdAt: Date;
  processed: boolean;
}
 
class TransactionalEventPublisher {
  constructor(
    private db: Database,
    private eventBus: EventBus
  ) {}
 
  async publishEventsTransactionally<T>(
    businessOperation: () => Promise<T>,
    events: OutboxEvent[]
  ): Promise<T> {
    return await this.db.transaction(async (trx) => {
      // 1. 비즈니스 로직 실행
      const result = await businessOperation();
      
      // 2. 같은 트랜젝션에서 이벤트 저장
      for (const event of events) {
        await trx.table('outbox_events').insert(event);
      }
      
      return result;
    });
  }
}
 
// CDC를 이용한 이벤트 발행자
class OutboxEventProcessor {
  private isProcessing = false;
 
  async startProcessing(): Promise<void> {
    if (this.isProcessing) return;
    
    this.isProcessing = true;
    
    while (this.isProcessing) {
      try {
        const unprocessedEvents = await this.loadUnprocessedEvents();
        
        for (const event of unprocessedEvents) {
          try {
            await this.eventBus.publish(event.eventType, event.payload);
            await this.markEventAsProcessed(event.id);
          } catch (publishError) {
            await this.handlePublishError(event, publishError);
          }
        }
        
        await this.sleep(1000); // 1초 대기
      } catch (error) {
        console.error('Outbox processing error:', error);
        await this.sleep(5000); // 에러시 5초 대기
      }
    }
  }
 
  private async handlePublishError(event: OutboxEvent, error: Error): Promise<void> {
    // 재시도 로직 또는 DLQ 처리
    if (event.retryCount < MAX_RETRIES) {
      await this.scheduleRetry(event);
    } else {
      await this.moveToDeadLetterQueue(event);
    }
  }
}

💡 분산 락과 리더 선출

🤔 질문: “분산 환경에서 중복 처리를 어떻게 방지할까?”

📋 분산 락 구현 전략

Redis 기반 분산 락

  1. 락 획득: SET key value NX EX ttl 명령 사용
  2. 락 갱신: 작업이 길어질 경우 TTL 연장
  3. 락 해제: Lua 스크립트로 안전한 해제
  4. 장애 처리: TTL로 자동 해제, 하트비트로 갱신

💻 분산 락 구현

// 📊 Redis 기반 분산 락
class RedisDistributedLock {
  private lockScript = `
    if redis.call("get", KEYS[1]) == ARGV[1] then
      return redis.call("del", KEYS[1])
    else
      return 0
    end
  `;
 
  constructor(private redis: Redis) {}
 
  async acquireLock(
    lockKey: string, 
    lockValue: string, 
    ttlSeconds: number = 30
  ): Promise<boolean> {
    const result = await this.redis.set(
      lockKey, 
      lockValue, 
      'NX', 
      'EX', 
      ttlSeconds
    );
    return result === 'OK';
  }
 
  async releaseLock(lockKey: string, lockValue: string): Promise<boolean> {
    const result = await this.redis.eval(
      this.lockScript,
      1,
      lockKey,
      lockValue
    );
    return result === 1;
  }
 
  async withLock<T>(
    lockKey: string,
    operation: () => Promise<T>,
    ttlSeconds: number = 30
  ): Promise<T> {
    const lockValue = generateUniqueId();
    const acquired = await this.acquireLock(lockKey, lockValue, ttlSeconds);
    
    if (!acquired) {
      throw new Error(`Could not acquire lock: ${lockKey}`);
    }
 
    try {
      // 자동 갱신을 위한 하트비트
      const heartbeat = this.startHeartbeat(lockKey, lockValue, ttlSeconds);
      const result = await operation();
      clearInterval(heartbeat);
      return result;
    } finally {
      await this.releaseLock(lockKey, lockValue);
    }
  }
 
  private startHeartbeat(
    lockKey: string, 
    lockValue: string, 
    ttlSeconds: number
  ): NodeJS.Timeout {
    return setInterval(async () => {
      try {
        await this.redis.expire(lockKey, ttlSeconds);
      } catch (error) {
        console.error('Lock heartbeat error:', error);
      }
    }, (ttlSeconds * 1000) / 3); // TTL의 1/3마다 갱신
  }
}

💡 실무 도구 및 플랫폼

📋 주요 도구들

분산 트랜젝션 도구 스택

메시지 브로커:

  • Apache Kafka: 높은 처리량, 이벤트 스트리밍
  • RabbitMQ: 복잡한 라우팅, 트랜젝션 지원
  • Apache Pulsar: 멀티 테넌시, 지역 복제

분산 트랜젝션 매니저:

  • Atomikos: Java 기반 2PC 구현
  • Narayana: JTA 호환 트랜젝션 매니저
  • Seata: 알리바바의 분산 트랜젝션 솔루션

📊 도구별 비교

도구패턴 지원성능학습곡선적용분야
KafkaSaga, Event Sourcing높음중간대용량 스트리밍
Seata2PC, Saga중간낮음중국 클라우드
Atomikos2PC낮음높음레거시 통합
ChoreographySaga높음높음클라우드 네이티브

5. 성능 최적화 및 모니터링

운영 고려사항

프로덕션 환경에서 분산 트랜젝션의 성능과 안정성을 보장하기 위한 방법들을 다룹니다.

💡 성능 최적화 전략

🤔 질문: “분산 트랜젝션의 성능 병목은 어디에서 발생할까?”

📋 주요 최적화 포인트

성능 최적화 체크리스트

  1. 네트워크 최적화: 배치 처리, 연결 풀, 압축
  2. 동시성 제어: 낙관적 락, 버전 관리
  3. 캐시 전략: 읽기 모델 분리, 이벤트 캐시
  4. 배치 처리: 이벤트 버퍼링, 벌크 처리

💻 성능 최적화 구현

// 📊 배치 이벤트 처리
class BatchEventProcessor {
  private eventBuffer: DomainEvent[] = [];
  private readonly batchSize = 100;
  private readonly flushInterval = 5000; // 5초
 
  constructor(private eventStore: EventStore) {
    this.startBatchProcessor();
  }
 
  async addEvent(event: DomainEvent): Promise<void> {
    this.eventBuffer.push(event);
    
    if (this.eventBuffer.length >= this.batchSize) {
      await this.flushEvents();
    }
  }
 
  private async flushEvents(): Promise<void> {
    if (this.eventBuffer.length === 0) return;
 
    const eventsToProcess = [...this.eventBuffer];
    this.eventBuffer = [];
 
    try {
      // 배치로 이벤트 처리
      await this.eventStore.saveBatch(eventsToProcess);
      
      // 그룹별로 병렬 처리
      const eventGroups = this.groupByAggregate(eventsToProcess);
      await Promise.all(
        Object.values(eventGroups).map(group => 
          this.processEventGroup(group)
        )
      );
    } catch (error) {
      // 실패한 이벤트들을 다시 버퍼에 추가
      this.eventBuffer.unshift(...eventsToProcess);
      throw error;
    }
  }
 
  private startBatchProcessor(): void {
    setInterval(async () => {
      await this.flushEvents();
    }, this.flushInterval);
  }
}
 
// 읽기 모델 최적화
class OptimizedReadModel {
  private cache = new Map<string, any>();
  private readonly cacheSize = 10000;
 
  async getProjection(aggregateId: string): Promise<any> {
    // 캐시에서 먼저 확인
    if (this.cache.has(aggregateId)) {
      return this.cache.get(aggregateId);
    }
 
    // 캐시 미스시 스냅샷부터 로드
    const snapshot = await this.loadSnapshot(aggregateId);
    const eventsAfterSnapshot = await this.loadEventsAfterSnapshot(
      aggregateId, 
      snapshot?.version || 0
    );
 
    // 프로젝션 재구성
    const projection = this.rebuildProjection(snapshot, eventsAfterSnapshot);
    
    // 캐시 저장 (LRU 정책)
    this.addToCache(aggregateId, projection);
    
    return projection;
  }
 
  private addToCache(key: string, value: any): void {
    if (this.cache.size >= this.cacheSize) {
      // LRU: 가장 오래된 항목 제거
      const firstKey = this.cache.keys().next().value;
      this.cache.delete(firstKey);
    }
    this.cache.set(key, value);
  }
}

💡 모니터링 및 관찰성

🤔 질문: “분산 트랜젝션의 상태를 어떻게 추적하고 문제를 진단할까?”

📋 핵심 모니터링 지표

분산 트랜젝션 메트릭

성공률 지표:

  • Transaction Success Rate: 전체 트랜젝션 중 성공한 비율
  • Compensation Success Rate: 보상 트랜젝션 성공률
  • End-to-End Latency: 시작부터 완료까지의 전체 시간

성능 지표:

  • Service Response Time: 각 서비스별 응답 시간
  • Queue Depth: 이벤트 큐의 대기 메시지 수
  • Retry Count: 재시도 발생 횟수

💻 분산 추적 구현

// 📊 분산 추적 및 메트릭
class DistributedTransactionTracer {
  private tracer: Tracer;
  private metrics: MetricsCollector;
 
  async traceTransaction<T>(
    transactionId: string,
    transactionType: string,
    operation: () => Promise<T>
  ): Promise<T> {
    const span = this.tracer.startSpan(`transaction.${transactionType}`, {
      tags: {
        'transaction.id': transactionId,
        'transaction.type': transactionType
      }
    });
 
    const timer = this.metrics.startTimer('transaction.duration', {
      type: transactionType
    });
 
    try {
      const result = await operation();
      
      span.setTag('transaction.status', 'success');
      this.metrics.increment('transaction.success', {
        type: transactionType
      });
      
      return result;
    } catch (error) {
      span.setTag('transaction.status', 'error');
      span.setTag('error.message', error.message);
      
      this.metrics.increment('transaction.error', {
        type: transactionType,
        error: error.constructor.name
      });
      
      throw error;
    } finally {
      timer.stop();
      span.finish();
    }
  }
}
 
// 대시보드용 메트릭 수집
class TransactionMetricsCollector {
  private metrics = new Map<string, MetricValue>();
 
  collectTransactionMetrics(): TransactionDashboard {
    return {
      overview: {
        totalTransactions: this.getMetric('transaction.total'),
        successRate: this.calculateSuccessRate(),
        averageLatency: this.getMetric('transaction.latency.avg'),
        errorRate: this.calculateErrorRate()
      },
      serviceBreakdown: this.getServiceMetrics(),
      recentFailures: this.getRecentFailures(),
      compensationMetrics: {
        triggered: this.getMetric('compensation.triggered'),
        successful: this.getMetric('compensation.successful'),
        failed: this.getMetric('compensation.failed')
      }
    };
  }
 
  private calculateSuccessRate(): number {
    const total = this.getMetric('transaction.total');
    const success = this.getMetric('transaction.success');
    return total > 0 ? (success / total) * 100 : 0;
  }
}

🎯 실전 예시: 이커머스 주문 시스템

종합 구현 예시

지금까지 배운 모든 패턴을 활용하여 실제 이커머스 주문 처리 시스템을 구현해봅시다.

💻 완전한 구현 예시

// 📊 통합 주문 처리 시스템
class ECommerceOrderSaga {
  constructor(
    private orderService: OrderService,
    private paymentService: PaymentService,
    private inventoryService: InventoryService,
    private shippingService: ShippingService,
    private eventBus: EventBus,
    private tracer: DistributedTransactionTracer
  ) {}
 
  async processOrder(orderRequest: OrderRequest): Promise<OrderResult> {
    const sagaId = generateSagaId();
    const transactionId = generateTransactionId();
    
    return await this.tracer.traceTransaction(
      transactionId,
      'order.process',
      async () => {
        const saga = new OrderSagaInstance(sagaId, orderRequest);
        
        try {
          // 1. 주문 생성
          const order = await this.createOrderStep(saga);
          
          // 2. 결제 처리
          await this.processPaymentStep(saga, order);
          
          // 3. 재고 예약
          await this.reserveInventoryStep(saga, order);
          
          // 4. 배송 스케줄링
          await this.scheduleShippingStep(saga, order);
          
          // 5. 주문 확정
          await this.confirmOrderStep(saga, order);
          
          await this.publishOrderCompletedEvent(order);
          return { success: true, orderId: order.id };
          
        } catch (error) {
          await this.compensateFailedSaga(saga);
          throw error;
        }
      }
    );
  }
 
  private async createOrderStep(saga: OrderSagaInstance): Promise<Order> {
    try {
      const order = await this.orderService.createOrder(saga.orderRequest);
      saga.addCompletedStep('createOrder', () => 
        this.orderService.cancelOrder(order.id)
      );
      return order;
    } catch (error) {
      saga.addFailedStep('createOrder', error);
      throw error;
    }
  }
 
  private async processPaymentStep(saga: OrderSagaInstance, order: Order): Promise<void> {
    try {
      const payment = await this.paymentService.processPayment({
        orderId: order.id,
        amount: order.totalAmount,
        customerId: order.customerId
      });
      
      saga.addCompletedStep('processPayment', () =>
        this.paymentService.refundPayment(payment.id)
      );
    } catch (error) {
      saga.addFailedStep('processPayment', error);
      throw new PaymentFailedException('Payment processing failed', error);
    }
  }
 
  private async compensateFailedSaga(saga: OrderSagaInstance): Promise<void> {
    const compensationSteps = saga.getCompensationSteps().reverse();
    
    for (const compensation of compensationSteps) {
      try {
        await compensation();
      } catch (compensationError) {
        // 보상 실패는 로그만 남기고 계속 진행
        console.error('Compensation failed:', compensationError);
        await this.eventBus.publish('compensation.failed', {
          sagaId: saga.id,
          step: compensation.stepName,
          error: compensationError
        });
      }
    }
  }
}
 
// Saga 인스턴스 관리
class OrderSagaInstance {
  private completedSteps: Array<{
    stepName: string;
    compensation: () => Promise<void>;
  }> = [];
  
  private failedSteps: Array<{
    stepName: string;
    error: Error;
  }> = [];
 
  constructor(
    public readonly id: string,
    public readonly orderRequest: OrderRequest
  ) {}
 
  addCompletedStep(stepName: string, compensation: () => Promise<void>): void {
    this.completedSteps.push({ stepName, compensation });
  }
 
  addFailedStep(stepName: string, error: Error): void {
    this.failedSteps.push({ stepName, error });
  }
 
  getCompensationSteps(): Array<() => Promise<void>> {
    return this.completedSteps.map(step => step.compensation);
  }
}

📊 결과 및 교훈

패턴적용 부분효과
Saga전체 주문 플로우장기 트랜젝션 관리
Outbox이벤트 발행일관성 보장
분산 추적모든 단계관찰성 향상
보상 트랜젝션실패 처리데이터 일관성 복구

📚 정리 및 권장사항

⭐ 핵심 가이드라인

  1. 패턴 선택 기준

    • 강한 일관성 필요: 2PC (단기 트랜젝션)
    • 높은 가용성 요구: Saga 패턴
    • 감사 추적 중요: Event Sourcing
    • 하이브리드 접근: 패턴 조합

  2. 성공적인 구현을 위한 핵심 요소

    • 포괄적인 모니터링 및 로깅
    • 명확한 보상 트랜젝션 전략
    • 네트워크 파티션 대응 방안
    • 성능과 일관성 간의 균형

  3. 운영 시 주의사항

    • 분산 트랜젝션은 복잡성이 높으므로 단순한 해결책부터 고려
    • 비즈니스 요구사항에 따른 일관성 수준 결정
    • 충분한 테스트와 장애 시나리오 대응 계획 수립

마지막 조언

분산 트랜젝션은 은총알이 아닙니다. 비즈니스 요구사항과 시스템 제약사항을 충분히 고려하여 적절한 패턴을 선택하고, 단계적으로 도입하는 것이 성공의 열쇠입니다.

그래프 뷰