# 마이크로서비스 아키텍처 (Microservices Architecture, MSA)

## 1. 개요
본 문서는 소프트웨어 아키텍트 및 백엔드 개발자를 대상으로 하며, 기초적인 네트워크 및 HTTP 통신에 대한 이해가 있다는 전제하에 작성되었습니다.

마이크로서비스 아키텍처(Microservices Architecture, 이하 MSA)는 하나의 거대한 애플리케이션을 독립적으로 배포 가능한 여러 개의 작은 서비스 단위로 분할하여 구축하는 소프트웨어 개발 방법론이다. 

전통적인 **모놀리식 아키텍처(Monolithic Architecture)**가 모든 비즈니스 로직을 하나의 코드 베이스와 하나의 데이터베이스에 통합하여 관리하는 방식이라면, MSA는 각 서비스가 고유의 비즈니스 기능을 수행하며 API(Application Programming Interface)를 통해 서로 통신하는 분산 시스템 구조를 가진다.

## 2. 주요 특징 및 설계 원칙
MSA의 핵심은 서비스 간의 **느슨한 결합(Loose Coupling)**과 **높은 응집도(High Cohesion)**를 유지하는 것이다.

*   **서비스 독립성:** 각 서비스는 독립적으로 개발, 배포, 확장될 수 있으며, 특정 서비스의 장애가 전체 시스템의 붕괴로 이어지지 않도록 격리된다.
*   **단일 목적 서비스:** 단일 책임 원칙(SRP)의 개념을 서비스 단위로 확장하여, 하나의 서비스는 하나의 비즈니스 목적(Bounded Context)만을 수행해야 한다.
*   **분산 데이터 관리:** 각 서비스는 자신만의 데이터 저장소를 가지며, 타 서비스의 데이터에 직접 접근하지 않고 API를 통해서만 데이터를 교환한다.

### [표] 모놀리식 vs 마이크로서비스 비교

| 구분 | 모놀리식 아키텍처 (Monolithic) | 마이크로서비스 아키텍처 (MSA) |
| :--- | :--- | :--- |
| **구조** | 단일 코드 베이스, 단일 실행 파일 | 다수의 독립적인 서비스 집합 |
| **배포** | 전체 애플리케이션을 한 번에 배포 | 서비스별 개별 배포 가능 |
| **확장성** | 서버 전체를 복제하는 수평 확장만 가능 | 부하가 많은 특정 서비스만 선택적 확장 가능 |
| **데이터베이스** | 통합 데이터베이스 (Shared DB) | 서비스별 전용 데이터베이스 (DB per Service) |
| **기술 스택** | 단일 언어 및 프레임워크 강제 | 서비스별 최적의 언어/DB 선택 가능 (Polyglot) |
| **복잡도** | 초기 개발 및 배포가 단순함 | 인프라 구성 및 서비스 간 통신 관리가 복잡함 |

## 3. 서비스 분할 전략 (DDD)
MSA에서 가장 어려운 과제는 "서비스를 어떻게 나눌 것인가"이다. 이를 위해 **도메인 주도 설계(Domain-Driven Design, DDD)** 방법론이 주로 사용된다.

*   **전략적 설계 (Strategic Design):** 비즈니스 도메인을 분석하여 유사한 기능을 가진 영역을 그룹화한다.
*   **바운디드 컨텍스트 (Bounded Context):** 특정 모델이 적용되는 논리적 경계를 설정한다. 예를 들어, '상품'이라는 개념이 '주문 서비스'에서는 주문 대상으로서의 상품이지만, '재고 서비스'에서는 수량 관리 대상으로서의 상품으로 다르게 정의될 수 있다. 이 경계가 곧 마이크로서비스의 분할 기준이 된다.
*   **컨텍스트 맵 (Context Map):** 분리된 바운디드 컨텍스트 간의 관계와 데이터 흐름을 정의하여 서비스 간의 의존성을 시각화한다.

## 4. 핵심 구성 요소 및 기술 스택
분산된 서비스들이 유기적으로 작동하기 위해서는 다음과 같은 인프라 요소가 필수적이다.

### 4.1 서비스 간 통신
*   **동기 통신 (Synchronous):** 요청 후 응답이 올 때까지 대기하는 방식. 주로 **REST API** (HTTP/JSON)나 고성능 통신을 위한 **gRPC** (Google Remote Procedure Call)가 사용된다.
*   **비동기 통신 (Asynchronous):** 메시지를 발행하고 응답을 기다리지 않는 방식. **Message Queue**(RabbitMQ, Apache Kafka)를 활용하여 서비스 간 결합도를 낮춘다.

### [표] 서비스 간 통신 방식 비교

| 구분 | 동기 통신 (Synchronous) | 비동기 통신 (Asynchronous) |
| :--- | :--- | :--- |
| **특징** | 요청-응답(Request-Response) 구조 | 발행-구독(Pub-Sub) 또는 메시지 큐 구조 |
| **장점** | 구현이 직관적이며 즉각적인 결과 확인 가능 | 서비스 간 결합도 낮음, 시스템 가용성 향상 |
| **단점** | 응답 대기 시간 발생, 연쇄 장애 위험 | 구현 복잡도 증가, 최종 일관성 모델 필요 |
| **주요 기술** | REST, gRPC | Kafka, RabbitMQ, AWS SQS/SNS |

### 4.2 서비스 관리 및 라우팅
*   **API 게이트웨이 (API Gateway):** 클라이언트의 모든 요청을 단일 진입점으로 받아 적절한 서비스로 라우팅하며, 인증/인가, 부하 분산(Load Balancing), 로깅 등의 공통 기능을 처리한다.
*   **서비스 발견 (Service Discovery):** 동적으로 변하는 서비스의 네트워크 위치(IP, Port)를 자동으로 등록하고 찾아주는 메커니즘이다. (예: Netflix Eureka, Consul)

### 4.3 서비스 안정성 및 제어
*   **서킷 브레이커 (Circuit Breaker):** MSA의 최대 약점인 '연쇄 장애(Cascading Failure)'를 방지하기 위한 패턴이다. 특정 서비스에 장애가 발생하여 응답이 지연되거나 에러가 반복될 경우, 호출을 즉시 차단(Open)하여 시스템 전체의 붕괴를 막고 대체 응답(Fallback)을 제공한다. (예: Resilience4j, Netflix Hystrix)
*   **서비스 메시 (Service Mesh):** Kubernetes 환경에서 API Gateway만으로는 부족한 서비스 간 통신 제어(Traffic Management), 보안(mTLS), 관찰 가능성을 위해 사용되는 인프라 계층이다. 사이드카(Sidecar) 프록시를 통해 통신을 관리한다. (예: Istio, Linkerd)

## 5. 데이터 관리 전략
MSA에서는 데이터 무결성을 유지하는 것이 가장 큰 도전 과제이다.

### 5.1 Database per Service
각 서비스는 전용 DB를 가지며, 이는 서비스 간의 강한 결합을 방지하고 기술적 자율성을 부여한다. 하지만 이로 인해 분산 트랜잭션 문제가 발생한다.

### 5.2 분산 트랜잭션 해결 사례 및 패턴
전통적인 2PC(Two-Phase Commit)는 성능 저하와 가용성 문제로 MSA에서 지양되며, 대신 **최종 일관성(Eventual Consistency)** 모델을 채택한다.

*   **Saga 패턴:** 여러 서비스에 걸친 트랜잭션을 로컬 트랜잭션의 연속으로 처리하는 방식이다.
    *   **Choreography-based:** 중앙 제어자 없이 각 서비스가 이벤트를 발행/구독하며 다음 단계를 수행한다.
    *   **Orchestration-based:** 중앙 오케스트레이터가 전체 흐름을 제어하며, 실패 시 **보상 트랜잭션(Compensating Transaction)**을 호출하여 이전 상태로 롤백한다.
*   **CQRS 패턴 (Command Query Responsibility Segregation):** 명령(CUD)과 조회(R)의 책임을 분리하는 패턴이다. 복잡한 조회가 필요한 경우, 여러 서비스의 데이터를 읽기 전용 DB에 통합하여 조회 성능을 최적화한다.

## 6. 배포 및 운영 환경
MSA는 관리해야 할 서비스 수가 많으므로 자동화된 인프라가 필수적이다.

### 6.1 컨테이너화 및 오케스트레이션
*   **Docker:** 애플리케이션과 실행 환경을 하나로 묶어 어디서나 동일하게 실행되도록 하는 컨테이너 기술이다.
*   **Kubernetes (K8s):** 수많은 컨테이너의 배포, 확장, 관리를 자동화하는 오케스트레이션 툴이다.

```yaml
# Kubernetes Deployment 예시 (간략화)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3 # 고가용성 및 부하 분산을 위해 3개의 포드(Pod) 유지
  selector:
    matchLabels:
      app: order
  template:
    metadata:
      labels:
        app: order
    spec:
      containers:
      - name: order-service
        image: my-registry/order-service:v1.0
        ports:
        - containerPort: 8080
```

### 6.2 CI/CD 파이프라인
지속적 통합(CI)과 지속적 배포(CD)를 통해 코드 변경 사항을 자동으로 테스트하고 운영 환경에 반영하여 배포 주기를 단축한다. (예: Jenkins, GitHub Actions, GitLab CI)

## 7. 모니터링 및 로깅 전략
분산 환경에서는 장애 발생 시 원인을 찾는 것이 매우 어렵기 때문에 통합 관제 체계가 필요하다.

*   **분산 추적 (Distributed Tracing):** 요청 하나가 여러 서비스를 거칠 때, 고유한 **Trace ID**를 부여하여 전체 경로를 추적한다. (예: Zipkin, Jaeger)
*   **중앙 집중형 로깅 (Centralized Logging):** 각 서비스의 로그를 한곳으로 모아 검색하고 분석한다. 주로 **ELK 스택**(Elasticsearch, Logstash, Kibana)이 사용된다.
*   **메트릭 모니터링:** CPU, 메모리, 응답 시간 등 시스템 지표를 실시간으로 시각화한다. (예: Prometheus, Grafana)

## 8. 장단점 및 해결 방안

### 장점
1.  **독립적 확장성:** 트래픽이 몰리는 특정 서비스만 개별적으로 확장하여 자원 효율성을 높일 수 있다.
2.  **기술 유연성:** 서비스 특성에 맞는 최적의 언어와 DB를 선택할 수 있다.
3.  **빠른 배포 주기:** 전체 시스템을 재빌드할 필요 없이 변경된 서비스만 배포하여 릴리스 속도를 높인다.

### 단점 및 해결 방안 (Trade-off)

| 단점 | 해결 방안 |
| :--- | :--- |
| **운영 복잡도 증가** | 컨테이너 오케스트레이션(Kubernetes), CI/CD 자동화, 서비스 메시(Istio) 도입 |
| **네트워크 지연 및 오버헤드** | gRPC 등 고성능 통신 프로토콜 사용, 서비스 간 통신 최소화 설계 |
| **데이터 일관성 유지 어려움** | Saga 패턴을 통한 보상 트랜잭션 구현, CQRS 패턴을 통한 조회 최적화 |
| **연쇄 장애 위험** | 서킷 브레이커(Circuit Breaker) 패턴 적용, 타임아웃 설정 및 Fallback 전략 수립 |
| **분산 환경의 디버깅 난해함** | 분산 추적(Distributed Tracing) 및 중앙 집중형 로깅(ELK) 시스템 구축 |

**결론적으로,** MSA는 모든 프로젝트의 정답이 아니며, 시스템의 규모가 매우 크고 팀 단위의 독립적인 개발/배포가 절실한 경우에 도입하는 것이 권장된다. 소규모 프로젝트에서는 오히려 모놀리식 아키텍처가 생산성 면에서 유리할 수 있다.