PART 2 · 강의 4/4

마이크로서비스
아키텍처

MSA 패턴, 서비스 분리 전략, 다양한 통신 방식을 이해하고 적절한 아키텍처를 설계합니다.

01

마이크로서비스 아키텍처란?

작고 독립적인 서비스들의 집합

"하나의 큰 애플리케이션을 작고 독립적으로 배포 가능한 서비스들의 집합으로 구성"

각 서비스는 특정 비즈니스 기능을 담당하며, 독립적으로 개발, 배포, 확장 가능

MSA 구조 시각화 (서비스를 클릭해보세요)

🚪
API Gateway
Kong / AWS API Gateway
👤
User Service
Node.js + PostgreSQL
📦
Order Service
Java + MySQL
💳
Payment Service
Go + Redis
📊
Inventory Service
Python + MongoDB
🔔
Notification Service
Node.js + RabbitMQ
🚚
Shipping Service
Kotlin + PostgreSQL
📌 MSA의 핵심 특징
  • 독립적 배포 — 각 서비스를 개별적으로 배포 가능
  • 기술 다양성 — 서비스마다 적합한 기술 스택 선택 가능
  • 팀 자율성 — 각 팀이 담당 서비스를 독립적으로 관리
  • 장애 격리 — 한 서비스의 장애가 전체 시스템에 영향 최소화
02

서비스 분리 전략

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

Monolith

UI Layer
Business Logic
Data Access
Single Database
👤
User Bounded Context
인증, 프로필, 권한 관리
🛒
Order Bounded Context
주문 생성, 상태 관리
💰
Payment Bounded Context
결제 처리, 환불
📦
Inventory Bounded Context
재고 관리, 입출고
💡 DDD와 Bounded Context

서비스 분리는 Domain-Driven Design(DDD)의 Bounded Context 개념을 따릅니다. 각 컨텍스트는 명확한 경계를 가지며, 독립적인 도메인 모델을 유지합니다. "같은 용어도 컨텍스트마다 다른 의미를 가질 수 있다"는 것이 핵심입니다.

서비스 분리 기준

🎯

비즈니스 역량

비즈니스 도메인 기준으로 분리 (주문, 결제, 배송 등)

📈

확장성 요구

스케일링 요구사항이 다른 기능 분리

👥

팀 구조

Conway's Law: 팀 구조에 맞게 서비스 분리

🔄

변경 빈도

자주 변경되는 기능을 별도 서비스로 분리

03

서비스 간 통신 방식

REST, gRPC, Message Queue 비교

🌐

REST API

HTTP 기반의 표준 통신 방식

  • ✓ 단순하고 이해하기 쉬움
  • ✓ 다양한 클라이언트 지원
  • ✓ 캐싱 용이
  • △ 상대적으로 느린 성능
  • △ 동기식 통신

gRPC

고성능 RPC 프레임워크

  • ✓ 높은 성능 (HTTP/2, Protobuf)
  • ✓ 스트리밍 지원
  • ✓ 강력한 타입 체크
  • △ 학습 곡선 존재
  • △ 브라우저 직접 호출 제한
📨

Message Queue

비동기 메시지 기반 통신

  • ✓ 완전한 비동기 처리
  • ✓ 느슨한 결합
  • ✓ 부하 분산 / 버퍼링
  • △ 복잡한 디버깅
  • △ 최종 일관성
⚠️ 통신 방식 선택 기준

동기 통신(REST/gRPC)은 즉각적인 응답이 필요할 때, 비동기 통신(Message Queue)은 긴 처리 시간이나 이벤트 기반 처리에 적합합니다. 대부분의 MSA는 두 방식을 혼합하여 사용합니다.

통신 패턴 비교

특성 REST gRPC Message Queue
지연 시간 중간 낮음 높음 (비동기)
결합도 중간 높음 낮음
사용 사례 외부 API, CRUD 내부 서비스 통신 이벤트 처리, 알림
04

서비스 호출 흐름 시뮬레이션

주문 프로세스를 통해 MSA 이해하기

시나리오 선택

시나리오를 선택하여 서비스 호출 흐름을 확인하세요
05

장점과 단점

MSA 도입 시 고려사항

장점
  • 🚀
    독립적 배포

    각 서비스를 개별적으로 빌드하고 배포 가능

  • 📈
    확장성

    부하가 높은 서비스만 선택적으로 스케일 아웃

  • 🛡️
    장애 격리

    한 서비스의 장애가 전체 시스템에 전파되지 않음

  • 🔧
    기술 다양성

    서비스별로 최적의 기술 스택 선택 가능

단점
  • 🔄
    분산 시스템 복잡성

    네트워크 지연, 부분 장애, 데이터 일관성 문제

  • 🔍
    디버깅 어려움

    분산 트레이싱, 로그 수집 등 추가 인프라 필요

  • 💰
    운영 비용

    여러 서비스 모니터링, 배포 파이프라인 관리

  • 📊
    데이터 관리

    분산 트랜잭션, 데이터 동기화 복잡성

⚠️ MSA 도입 결정

MSA는 만병통치약이 아닙니다. 팀 규모가 작거나, 도메인이 단순하거나, 빠른 초기 개발이 중요한 경우 모놀리스로 시작하는 것이 더 나을 수 있습니다. "모놀리스 우선(Monolith First)" 접근법을 고려하세요.

06

MSA 베스트 프랙티스

성공적인 MSA 구현을 위한 핵심 원칙

🗄️
Database per Service

각 서비스는 자체 데이터베이스를 가지며, 다른 서비스의 DB에 직접 접근하지 않습니다.

🚪
API Gateway

단일 진입점을 통해 인증, 라우팅, 속도 제한, 로깅 등을 중앙에서 관리합니다.

🔌
Circuit Breaker

장애 전파 방지를 위해 실패하는 서비스 호출을 일시적으로 차단합니다.

📡
분산 트레이싱

요청 흐름을 추적하기 위해 Jaeger, Zipkin 등을 활용한 트레이싱을 구현합니다.

📋
서비스 레지스트리

서비스 위치를 동적으로 관리하기 위한 서비스 디스커버리를 구현합니다.

🔄
Saga 패턴

분산 트랜잭션 대신 보상 트랜잭션을 활용한 데이터 일관성을 유지합니다.

SUMMARY

핵심 요약

  • MSA는 독립적으로 배포 가능한 작은 서비스들의 집합으로 구성된 아키텍처
  • 서비스 분리는 비즈니스 도메인(Bounded Context) 기준으로 수행
  • 통신 방식은 요구사항에 따라 REST, gRPC, Message Queue를 혼합 사용
  • MSA는 확장성과 독립성을 제공하지만, 분산 시스템 복잡성을 수반
  • 모놀리스 우선 접근법을 고려하고, 필요할 때 점진적으로 분리