Docs Architecture

마이크로서비스(Microservice)아키텍처

정의

마이크로서비스 아키텍처는 비즈니스 도메인별로 독립적으로 개발, 배포, 확장이 가능한 소프트웨어 개발 접근 방식입니다. 각 서비스는 특정 비즈니스 기능을 담당하며, 다양한 통신 방식을 조합하여 서로 통신하는 분산 시스템을 구성합니다.

특징

1. 독립적인 배포와 확장성

  • 자율적 배포: 각 서비스는 독립적으로 빌드, 테스트, 배포가 가능하여 빠른 기능 릴리즈와 지속적인 배포(Continuous Deployment)에 유리합니다.
  • 독립 확장: 트래픽 증가나 처리량 변화에 따라 개별 서비스 단위로 확장(Scale-out)이 가능해 자원 효율성과 성능 최적화에 강점을 가집니다.
  • 느슨한 결합 (Loosely Coupled): 서비스 간 의존성을 최소화하여 하나의 변경이 전체 시스템에 영향을 주지 않도록 설계됩니다.

2. 경량화된 통신 방식

  • HTTP, REST, JSON 기반의 통신: 서비스 간 데이터 교환은 경량 프로토콜을 사용하여 플랫폼과 언어에 독립적인 통신이 가능하도록 합니다.
  • 기술 스택 독립성: JSON과 같은 기술 중립 포맷 사용으로 각 서비스는 서로 다른 언어나 프레임워크로 개발될 수 있습니다.

3. 데이터 독립성

  • 각 서비스는 자체 데이터베이스를 소유하며, 데이터 접근은 반드시 해당 서비스를 통해서만 이루어집니다.
  • 이는 데이터 일관성 보장과 서비스 간 경계를 명확히 하는 데 도움이 됩니다.

4. 작은 팀 단위의 운영

  • 각 서비스는 독립적인 소규모 팀에서 관리되며,
  • 팀은 해당 서비스의 전체 라이프사이클(개발, 테스트, 배포, 운영)에 대한 책임을 집니다.

5. 비즈니스 도메인 중심 설계

  • 도메인 주도 설계(DDD): 서비스는 명확한 비즈니스 도메인을 기준으로 분리되며, 도메인 모델의 일관성과 유지를 위한 전략적 경계를 설정합니다.
  • 엔드투엔드 캡슐화: 사용자 인터페이스, 비즈니스 로직, 데이터 접근까지 하나의 서비스 내부에 통합되어 높은 응집도를 유지합니다.

DDD(Domain-Driven Design) 핵심 개념

1. 도메인 (Domain)

  • 정의: 소프트웨어가 해결하고자 하는 비즈니스 문제 영역
  • 특징:
    • 비즈니스 전문성과 프로세스를 포함
    • 조직의 가치 창출 영역
    • 도메인 전문가의 지식 체계화

도메인 모델 (Domain Model)

  • 정의: 도메인을 개념적으로 표현한 추상화된 모델
  • 연계 개념:
    • 도메인의 구체적인 구현체
    • 유비쿼터스 언어를 코드로 표현한 클래스
    • 하위 도메인별로 독립적인 모델 보유
  • 중요성:
    • 비즈니스 로직의 명확한 표현
    • 개발자와 도메인 전문가 간의 소통 도구
    • 유지보수성 향상

2. 하위 도메인 (Subdomain)

기본 개념

  • 정의: 도메인을 비즈니스 능력에 따라 분할한 논리적 단위
  • 유형:
    • 핵심(Core): 비즈니스 경쟁력의 핵심이 되는 부분
    • 지원(Supporting): 핵심을 지원하는 부가 기능
    • 일반(Generic): 표준화된 솔루션으로 해결 가능한 부분

바운디드 컨텍스트 (Bounded Context)

  • 정의: 특정 도메인 모델이 적용되는 명시적인 경계
  • 연계 개념:
    • 하위 도메인을 구현하는 물리적/논리적 단위
    • 각 컨텍스트는 자체 유비쿼터스 언어 보유
    • 도메인 모델의 적용 범위 정의
  • 특징:
    • 독립적인 개발/배포 단위
    • 마이크로서비스 아키텍처의 서비스 경계
    • 모델의 명확한 경계 설정

3. 애그리게이트 (Aggregate)

기본 개념

  • 정의: 일관성 경계를 정의하는 도메인 객체의 집합
  • 연계 개념:
    • 바운디드 컨텍스트 내에서 트랜잭션 경계 정의
    • 도메인 모델의 일관성 유지 단위
    • 도메인 이벤트를 발생시켜 다른 애그리게이트와 통신
  • 설계 원칙:

    1. 일관성 경계

      • 한 애그리게이트는 하나의 트랜잭션으로 처리
      • 예: 주문과 주문 항목은 함께 저장/수정

    2. 참조 제한

      • 다른 애그리게이트는 ID로만 참조
      • 예: Order는 Customer를 직접 참조하지 않고 customerId만 가짐

    3. 작은 크기 유지

      • 성능과 확장성을 고려해 작게 유지
      • 예: 주문과 결제는 별도 애그리게이트로 분리

4. 개념 간의 관계

  1. 계층적 구조
도메인
└── 하위 도메인(핵심/지원/일반) (Subdomain) 
    │
    └── 바운디드 컨텍스트 (Bounded Context)
        │
        └── 도메인 모델 (Domain Model)
            │
            └── 애그리게이트 (Aggregate)
                │
                ├── 엔티티 (Entities)
                │   ├── [주요 엔티티]
                │   └── [보조 엔티티]
                │
                └── 값 객체 (Value Objects)
                    ├── [단순 값 객체]
                    └── [복합 값 객체]
  1. 상호작용 흐름 클라이언트 요청 → 애플리케이션 서비스 → 리포지토리 → 애그리게이트 → 도메인 서비스/도메인 이벤트
  2. 일관성 유지
    • 애그리게이트: 트랜잭션 일관성
    • 도메인 이벤트: 분산 일관성
    • 바운디드 컨텍스트: 모델 일관성

모니터링

MSA 분산 추적: 상관관계 ID를 활용한 모니터링

MSA(Microservice Architecture) 환경에서는 단일 요청이 여러 서비스를 거치면서 처리되기 때문에, 전통적인 모니터링 방식으로는 전체적인 흐름을 파악하기 어렵습니다. 이를 해결하기 위해 상관관계 ID(Correlation ID) 기반의 분산 추적 기법이 널리 사용되고 있습니다. image

🔍 핵심 개념

상관관계 ID(Correlation ID)란?

  • 정의: 분산 시스템에서 요청을 추적하기 위한 고유 식별자
  • 표준: W3C Trace Context 표준 준수
  • 특징:
    • 모든 마이크로서비스 호출에 걸쳐 전파되는 트랜잭션 ID
    • 요청의 시작부터 종료까지의 전체 경로 추적 가능

주요 이점

  • 엔드투엔드 가시성: 사용자 요청이 거치는 모든 서비스 경로 추적
  • 장애 진단 용이성: 문제 발생 시 특정 요청의 전체 호출 체인 분석
  • 성능 모니터링: 서비스별 처리 시간 측정 및 병목 지점 식별

🛠️ 구현 방법

  1. 시스템 진입점(API Gateway 등)에서 전역 호출 식별자 globally unique identifier(GUID)를 생성하고 후속 호출에 전달
  2. 컨텍스트 전파
  • HTTP 요청: 헤더에 ID 포함
# 요청 헤더 예시
X-Request-ID: 123e4567-e89b-12d3-a456-426614174000
X-Correlation-ID: abcdef12-34ab-56cd-ef12-34567890abcd
Traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
  • 메시지 큐: 메시지 속성에 ID 추가

Reference

  • 마이크로 서비스 아키텍처 구축 - 대용량 시스템의 효율적인 분산 설계 기법
  • Spring Microservices in Action, Second Edition
Previous
Kafka 분산 시스템 설계: 파티셔닝, 데이터 정합성
Next
마이크로서비스 아키텍처를 정의하는 3단계 핵심 프로세스