MSA와 EDA 이해하기: 분산 아키텍처 기본 개념 정리

TL;DR

최근 MSA와 EDA에 대해 공부하면서 정리한 내용입니다. MSA는 큰 애플리케이션을 작은 서비스들로 나누는 방식이고, EDA는 이벤트를 중심으로 시스템을 설계하는 패턴이라는 것을 배웠습니다. 두 개념이 함께 사용되면 더 유연한 시스템을 만들 수 있다고 합니다.

---

MSA(Microservices Architecture)란?

모놀리식에서 마이크로서비스로

모놀리식 아키텍처

┌─────────────────────────────────┐
│      단일 애플리케이션               │
├─────────────────────────────────┤
│  - User Management              │
│  - Order Processing             │
│  - Payment                      │
│  - Inventory                    │
│  - Notification                 │
└─────────────────────────────────┘
         ↓
    [단일 데이터베이스]

 

마이크로서비스 아키텍처

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│   User   │ │  Order   │ │ Payment  │ │Inventory │
│ Service  │ │ Service  │ │ Service  │ │ Service  │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
     ↓            ↓            ↓            ↓
  [User DB]   [Order DB]  [Payment DB] [Inventory DB]

MSA의 정의

MSA는 소프트웨어를 작고 독립적으로 배포 가능한 서비스들의 집합으로 구성하는 아키텍처 스타일입니다. 각 서비스는:

• 특정 비즈니스 기능을 담당
• 독립적으로 개발, 배포, 확장 가능
• 자체 데이터 저장소 보유
• API를 통해 다른 서비스와 통신

---

MSA의 핵심 원칙과 특징

1. 서비스 자율성 (Service Autonomy)

각 서비스의 독립성:
┌─────────────────────────┐
│     Order Service       │
├─────────────────────────┤
│ • 독립적인 코드베이스        │
│ • 자체 데이터베이스          │
│ • 독립적인 배포 주기         │
│ • 자체 기술 스택 선택        │
└─────────────────────────┘

2. 비즈니스 중심 설계 (Business Capability)

도메인 기반 서비스 분리:

전자상거래 시스템
├── 상품 도메인 → Product Service
├── 주문 도메인 → Order Service
├── 결제 도메인 → Payment Service
└── 배송 도메인 → Delivery Service

3. 분산 데이터 관리 (Decentralized Data Management)

공유 데이터베이스 안티패턴:
┌─────────┐ ┌─────────┐
│Service A│ │Service B│
└────┬────┘ └────┬────┘
     └──────┬─────┘
         [공유 DB]

서비스별 데이터베이스:
┌─────────┐ ┌─────────┐
│Service A│ │Service B│
└────┬────┘ └────┬────┘
     ↓           ↓
   [DB A]      [DB B]

4. 장애 격리 (Failure Isolation)

모놀리식: 하나의 기능 장애 → 전체 시스템 다운
MSA: 하나의 서비스 장애 → 해당 기능만 영향

Circuit Breaker 패턴:
정상 → 임계치 초과 → Open(차단) → Half-Open(테스트) → 정상

5. API를 통한 통신

서비스 간 통신 방식:

동기 통신 (REST API):
Service A --[HTTP Request]--> Service B
         <--[HTTP Response]--

비동기 통신 (Message Queue):
Service A --[Publish]--> Message Broker --[Subscribe]--> Service B

---

MSA 도입 시 고려사항

서비스 경계 정의

DDD(Domain-Driven Design) 기반 경계 설정:

┌─────────────────────────────────────┐
│         Bounded Context             │
├─────────────────────────────────────┤
│  Order Context:                     │
│  - Order, OrderItem                 │
│  - OrderService, OrderRepository    │
├─────────────────────────────────────┤
│  Payment Context:                   │
│  - Payment, PaymentMethod           │
│  - PaymentService, PaymentGateway   │
└─────────────────────────────────────┘

데이터 일관성 문제

분산 트랜잭션의 어려움:

Service A: 주문 생성 ✓
Service B: 재고 차감 ✓
Service C: 결제 처리 ✗ (실패!)

해결 방안:
- Saga 패턴
- 이벤트 소싱

운영 복잡성

관리 대상 증가:
- 모놀리식: 1개 애플리케이션
- MSA: N개 서비스 × M개 인스턴스

---

EDA(Event-Driven Architecture)란?

기본 개념

EDA는 시스템의 상태 변화(이벤트)를 중심으로 설계된 아키텍처 패턴입니다. 이벤트의 생성, 감지, 소비를 통해 느슨하게 결합된 시스템을 구축합니다.

전통적인 요청-응답 방식:
Client → Service A → Service B → Service C
       ←           ←           ←

이벤트 기반 방식:
Service A → [Event] → Event Bus → Service B
                               ↘ Service C
                                ↘ Service D

이벤트의 종류

1. 도메인 이벤트

비즈니스적으로 의미 있는 사건:
- OrderPlaced (주문 완료됨)
- PaymentCompleted (결제 완료됨)
- UserRegistered (사용자 가입됨)

 

2. 시스템 이벤트

시스템 레벨의 사건:
- ServiceStarted
- DatabaseConnectionLost
- CacheExpired

 

3. 통합 이벤트

시스템 간 통합을 위한 이벤트:
- ExternalAPICallCompleted
- FileUploadedToS3
- EmailSent

---

EDA의 구성 요소와 패턴

핵심 구성 요소

┌──────────────────────────────────────┐
│            Event Producer            │ → 이벤트 생성
├──────────────────────────────────────┤
│            Event Router              │ → 이벤트 라우팅
│         (Message Broker)             │
├──────────────────────────────────────┤
│           Event Consumer             │ → 이벤트 처리
└──────────────────────────────────────┘

주요 패턴

1. Pub/Sub (Publish-Subscribe)

Publisher가 특정 Topic에 발행:
                 ┌─→ Subscriber A
Publisher → Topic├─→ Subscriber B
                 └─→ Subscriber C

2. Event Streaming

연속적인 이벤트 스트림 처리:
Event Stream: [E1][E2][E3][E4][E5]...
                ↓
         Stream Processor
                ↓
         Processed Output

3. Event Sourcing

상태 변화를 이벤트로 저장:
초기상태 → Event1 → Event2 → Event3 → 현재상태

예시:
계좌잔액: 0 → 입금(100) → 출금(30) → 입금(50) → 잔액: 120

 

---

MSA와 EDA의 결합

시너지 효과

MSA + EDA 아키텍처:

┌─────────────┐   Event    ┌─────────────┐
│   Order     │ ─────────→ │   Event     │
│   Service   │            │   Broker    │
└─────────────┘            └──────┬──────┘
                                  ↓
                     ┌────────────┼────────────┐
                     ↓            ↓            ↓
              ┌──────────┐ ┌──────────┐ ┌──────────┐
              │Inventory │ │ Payment  │ │Shipping  │
              │ Service  │ │ Service  │ │ Service  │
              └──────────┘ └──────────┘ └──────────┘

장점

1. 느슨한 결합

• 서비스 간 직접적인 의존성 제거
• 이벤트를 통한 간접 통신

2. 확장성

• 독립적인 서비스 스케일링
• 이벤트 기반 비동기 처리

3. 복원력

• 일시적 장애 시 이벤트 큐잉
• 장애 전파 방지

4. 유연성

• 새로운 Consumer 추가 용이
• 기존 시스템 영향 최소화

---

장단점 분석

MSA의 장단점

장점:

• 독립적인 배포와 확장
• 기술 스택 다양성
• 장애 격리
• 팀 자율성

단점:

• 분산 시스템 복잡성
• 네트워크 통신 오버헤드
• 데이터 일관성 문제
• 운영 복잡도 증가

EDA의 장단점

장점:

• 느슨한 결합
• 확장성과 유연성
• 실시간 처리
• 복원력

단점:

• 이벤트 순서 보장 어려움
• 디버깅 복잡성
• 이벤트 스키마 관리
• 최종 일관성

---

마무리: 언제 사용해야 하는가?

MSA가 적합한 경우

적합:
- 대규모 개발 조직
- 빈번한 기능 변경
- 서비스별 다른 확장 요구사항
- 다양한 기술 스택 필요

부적합:
- 소규모 팀/프로젝트
- 단순한 CRUD 애플리케이션
- 빠른 프로토타이핑
- 강한 트랜잭션 일관성 필요

EDA가 적합한 경우

적합:
- 실시간 데이터 처리
- 여러 시스템 간 통합
- 이벤트 기반 워크플로우
- 높은 확장성 요구

부적합:
- 단순한 요청-응답 패턴
- 강한 일관성 요구
- 이벤트 순서가 중요한 경우
- 팀의 EDA 경험 부족

---

느낀 점

• MSA가 만능은 아니다 (복잡성과 트레이드오프)
• 작은 프로젝트에는 오히려 과도할 수 있다
• 팀의 역량과 준비가 중요하다
• 점진적으로 도입하는 것이 현실적일 것 같다