Skip to content
Published on

플랫폼 아키텍처 의사결정 가이드: 모놀리스와 마이크로서비스 사이

Authors
  • Name
    Twitter
플랫폼 아키텍처 의사결정 가이드: 모놀리스와 마이크로서비스 사이

문제 정의

Event-Driven/Saga와 플랫폼 아키텍처 결정은 “분리하면 확장된다”라는 단순 구호로는 실패한다. 트랜잭션 경계·복구 비용·조직 성숙도를 같이 봐야 한다.

아키텍처/원리

  • 강결합 도메인은 모놀리스가 총비용이 낮을 수 있다.
  • 분산 트랜잭션 대신 Saga 보상 설계를 표준화해야 한다.
  • 이벤트 계약은 버전드 스키마와 소비자 호환 정책이 필수다.

구현 예시 1

saga:
  steps:
    - reserve_credit
    - reserve_inventory
    - create_shipment
  compensations:
    - release_inventory
    - refund_credit

구현 예시 2

def run_saga(steps):
    completed=[]
    try:
        for s in steps:
            s.execute(); completed.append(s)
    except Exception:
        for s in reversed(completed):
            s.compensate()
        raise

구현 예시 3

SELECT saga_id, step, status, count(*)
FROM saga_log
WHERE created_at >= now()-interval '1 day'
GROUP BY saga_id, step, status;

구현 예시 4

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: order-events.v1
spec:
  partitions: 12
  config:
    retention.ms: 604800000
    cleanup.policy: compact,delete

운영 팁

  • ADR에 “왜 분리/비분리했는지”를 수치로 남긴다.
  • 보상 트랜잭션 실패율을 별도 SLI로 관리한다.
  • 이벤트 스키마 호환 검사를 CI 단계에서 강제한다.

트러블슈팅

  1. 중복 이벤트 처리: idempotency key + outbox 패턴 적용.
  2. 보상 실패 누적: dead-letter queue와 수동 복구 런북 마련.
  3. 서비스 경계 모호: 팀 책임 경계와 데이터 소유권 재정의.

체크리스트

  • 도메인 경계/소유권 문서화
  • saga 보상 절차 자동화
  • outbox + idempotency 구현
  • 이벤트 스키마 버전 정책
  • 장애 복구 훈련

결론

아키텍처는 유행이 아니라 비용 함수다. Event-Driven/Saga 채택은 복잡도를 감당할 조직 준비가 있을 때만 이득을 준다.

참고 자료