★ MSA 총 정리 ★

MSA(Microservices Architecture) 총정리

1. MSA란?

MSA(Microservices Architecture)는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 분리하여 개발하는 아키텍처 방식이다.

각 서비스는 주문, 결제, 배송, 회원과 같이 특정 비즈니스 기능을 담당하며 독립적으로 개발, 배포, 확장할 수 있다.

예를 들어 쇼핑몰 서비스를 MSA로 구성한다면 다음과 같이 나눌 수 있다.

[회원 서비스]
[상품 서비스]
[주문 서비스]
[결제 서비스]
[배송 서비스]

각 서비스는 서로 독립적으로 동작하며 HTTP API, 메시지 브로커(Kafka, RabbitMQ) 등을 통해 통신한다.

MSA의 주요 특징

• 독립적인 배포: 특정 서비스만 수정하여 별도로 배포할 수 있다.
• 독립적인 확장: 트래픽이 많은 서비스만 서버를 추가하여 확장할 수 있다.
• 작은 단위의 서비스: 각 서비스가 하나의 비즈니스 기능을 중심으로 구성된다.
• 기술 스택의 다양성: 서비스 특성에 따라 서로 다른 기술이나 데이터베이스를 사용할 수 있다.
• 장애 격리: 하나의 서비스 장애가 전체 시스템 장애로 이어지지 않도록 설계할 수 있다.

반면 서비스가 많아지면서 서비스 간 통신, 장애 처리, 데이터 정합성, 모니터링, 배포 및 운영이 복잡해진다는 단점도 존재한다.

---

2. Spring Cloud

Spring Cloud는 Spring Boot 기반의 MSA를 구축할 때 필요한 여러 기능을 제공하는 프로젝트들의 집합이다.

MSA에서는 여러 서비스가 서로 통신하기 때문에 다음과 같은 문제를 해결해야 한다.

서비스의 위치는 어떻게 찾을까?
        ↓
Service Discovery

요청을 어떤 서버에 전달할까?
        ↓
Load Balancing

외부 요청을 어디로 받을까?
        ↓
API Gateway

다른 서비스에 장애가 발생하면?
        ↓
Circuit Breaker

여러 서비스의 설정은 어떻게 관리할까?
        ↓
Spring Cloud Config

요청이 여러 서비스를 거칠 때 어떻게 추적할까?
        ↓
Distributed Tracing

Spring Cloud는 이러한 분산 시스템의 문제를 해결하기 위한 다양한 기능을 제공한다.

---

3. Service Discovery - Eureka

MSA에서는 하나의 서비스가 여러 개의 인스턴스로 실행될 수 있다.

Product Service
 ├─ localhost:8081
 ├─ localhost:8082
 └─ localhost:8083

이때 다른 서비스가 모든 서버의 IP와 Port를 직접 알고 있는 것은 관리하기 어렵다.

Service Discovery는 서비스의 위치를 등록하고 필요한 서비스가 해당 위치를 동적으로 찾을 수 있도록 하는 방식이다.

Eureka

Eureka는 Netflix에서 개발한 Service Discovery 기술이다.

각 마이크로서비스는 Eureka Server에 자신의 위치를 등록한다.

Product Service ──┐
Order Service   ──┼──> Eureka Server
Payment Service ──┘

다른 서비스는 Eureka를 통해 필요한 서비스의 인스턴스 정보를 조회할 수 있다.

따라서 IP와 Port를 직접 관리하는 대신 PRODUCT-SERVICE와 같은 서비스 이름을 기반으로 통신할 수 있다.

---

4. Load Balancing

로드 밸런싱은 들어오는 요청을 여러 서버에 분산하여 특정 서버에 부하가 집중되지 않도록 하는 기술이다.

             ┌─> Product Server 1
Client ──────┼─> Product Server 2
             └─> Product Server 3

대표적인 로드 밸런싱 알고리즘에는 다음과 같은 방식이 있다.

• Round Robin: 서버에 순서대로 요청을 전달한다.
• Weighted: 서버 성능에 따라 가중치를 부여한다.
• Least Connections: 현재 연결 수가 가장 적은 서버에 전달한다.
• Response Time: 응답 시간이 빠른 서버를 선택한다.

Ribbon

Ribbon은 Netflix에서 개발한 클라이언트 사이드 로드 밸런서이다.

Eureka에서 서비스 인스턴스 목록을 가져온 후 요청을 전달할 서버를 선택하는 역할을 수행했다.

다만 Ribbon은 현재 유지보수가 중단된 레거시 기술이며, 최근 Spring Cloud에서는 Spring Cloud LoadBalancer를 사용한다.

---

5. FeignClient

FeignClient는 다른 마이크로서비스의 REST API를 선언적인 방식으로 호출할 수 있도록 도와주는 HTTP Client이다.

일반적인 HTTP 요청 코드를 직접 작성하는 대신 인터페이스와 어노테이션을 이용하여 다른 서비스를 호출할 수 있다.

Order Service
      │
      │ FeignClient
      ▼
Product Service

Eureka 및 Spring Cloud LoadBalancer와 함께 사용하면 서비스 이름을 기반으로 인스턴스를 찾고 요청을 분산할 수도 있다.

즉,

FeignClient
    ↓
Eureka에서 서비스 검색
    ↓
LoadBalancer가 인스턴스 선택
    ↓
해당 서비스 호출

과 같은 구조로 이해할 수 있다.

---

6. Circuit Breaker

MSA에서는 하나의 요청이 여러 서비스를 거칠 수 있다.

Order → Payment → Delivery → Notification

만약 Payment Service에 장애가 발생했는데 계속 요청을 보내면 요청이 쌓이면서 다른 서비스까지 영향을 받을 수 있다.

Circuit Breaker는 문제가 발생한 서비스에 대한 요청을 일정 시간 차단하여 장애가 다른 서비스로 전파되는 것을 방지하는 패턴이다.

Circuit Breaker의 상태

Closed → Open → Half-Open
   ↑                 │
   └─────────────────┘

Closed 상태에서는 정상적으로 요청을 전달한다. 일정 수준 이상의 실패가 발생하면 Open 상태가 되어 요청을 즉시 차단한다.

일정 시간이 지나면 Half-Open 상태가 되어 일부 요청을 보내 서비스가 복구되었는지 확인한다.

요청이 정상적으로 처리되면 다시 Closed 상태로 돌아가며, 계속 실패하면 다시 Open 상태가 된다.

Resilience4j

Resilience4j는 Java 기반의 경량 장애 대응 라이브러리로 Circuit Breaker를 비롯해 Retry, Rate Limiter, Time Limiter 등의 기능을 제공한다.

과거에는 Netflix의 Hystrix가 많이 사용되었지만 현재는 유지보수 모드에 들어갔으며, Spring 환경에서는 Resilience4j가 대표적으로 사용된다.

Fallback

Fallback은 다른 서비스 호출에 실패했을 때 실행하는 대체 로직이다.

Payment Service 호출
        ↓
       실패
        ↓
Fallback 실행
        ↓
대체 응답 반환

이를 통해 장애 상황에서도 사용자에게 일정한 응답을 제공할 수 있다.

---

7. API Gateway

MSA에서는 서비스마다 각각 다른 주소를 가지고 있을 수 있다.

회원 → /users
상품 → /products
주문 → /orders
결제 → /payments

클라이언트가 각각의 서비스 주소를 직접 알고 요청하면 서비스가 많아질수록 관리가 어려워진다.

API Gateway는 외부 요청을 받는 하나의 진입점 역할을 한다.

             Client
                │
                ▼
        [ API Gateway ]
          /     |     \
         ▼      ▼      ▼
      User   Order   Product

API Gateway는 요청 경로를 확인하여 적절한 마이크로서비스로 요청을 전달한다.

대표적으로 다음과 같은 기능을 수행할 수 있다.

• Routing
• 인증 및 인가
• 요청/응답 필터링
• 로깅
• 모니터링
• Rate Limiting

Spring 환경에서는 Spring Cloud Gateway를 사용할 수 있다.

과거에는 Netflix의 Zuul도 사용되었지만 현재 Spring Cloud 환경에서는 Spring Cloud Gateway를 사용하는 것이 일반적이다.

Gateway Filter

Spring Cloud Gateway에서는 요청과 응답을 가공하기 위해 Filter를 사용할 수 있다.

Global Filter는 모든 요청에 적용되고, Gateway Filter는 특정 Route에 적용된다.

또한 실행 시점에 따라 다음과 같이 생각할 수 있다.

Client
  ↓
Pre Filter
  ↓
Service
  ↓
Post Filter
  ↓
Client

Pre Filter에서는 인증, 요청 로그 등의 작업을 수행할 수 있고, Post Filter에서는 응답 처리 및 응답 로그 등의 작업을 수행할 수 있다.

---

8. OAuth2와 JWT

MSA 환경에서는 여러 서비스에 대한 인증과 인가를 효율적으로 처리하는 것도 중요하다.

OAuth2

OAuth 2.0은 애플리케이션이 사용자의 자격 증명 자체를 직접 공유하지 않고도 보호된 리소스에 접근할 수 있도록 권한을 위임하는 프레임워크이다.

대표적인 구성 요소는 다음과 같다.

• Resource Owner
• Client
• Authorization Server
• Resource Server

현재 일반적인 사용자 로그인 환경에서는 Authorization Code 방식이 주로 사용되며, 서버 간 통신에서는 Client Credentials 방식 등을 사용할 수 있다.

JWT

JWT(JSON Web Token)는 Claim 정보를 JSON 형태로 표현하는 토큰 형식이다.

JWT는 다음 세 부분으로 구성된다.

Header.Payload.Signature

• Header: 토큰 타입과 서명 알고리즘
• Payload: 사용자 정보 및 Claim
• Signature: 토큰이 변조되지 않았는지 검증

주의할 점은 일반적인 JWT의 Payload가 암호화되는 것은 아니라는 것이다. JWT 서명은 주로 데이터의 무결성과 발급자 검증에 사용된다.

---

9. Spring Cloud Config

마이크로서비스가 많아지면 각각의 application.yml 설정을 관리하기 어려워진다.

User Service    → application.yml
Order Service   → application.yml
Payment Service → application.yml
Product Service → application.yml

Spring Cloud Config는 여러 마이크로서비스의 설정을 중앙에서 관리할 수 있도록 해준다.

              Config Server
             /      |       \
            ▼       ▼        ▼
         User     Order    Product

Git 저장소 등을 이용하여 환경별 설정을 중앙에서 관리할 수도 있다.

application-dev.yml
application-test.yml
application-prod.yml

Spring Cloud Bus와 메시지 브로커를 함께 사용하면 설정 변경 사항을 여러 서비스에 전파하는 구조도 구성할 수 있다.

---

10. 분산 추적 - Zipkin

MSA에서는 하나의 요청이 여러 서비스를 거치기 때문에 장애가 발생했을 때 어느 서비스에서 문제가 발생했는지 찾기 어려울 수 있다.

Client
  ↓
Gateway
  ↓
Order
  ↓
Payment
  ↓
Delivery

분산 추적(Distributed Tracing)은 하나의 요청이 여러 서비스를 이동하는 전체 과정을 추적하는 방식이다.

Zipkin은 이러한 Trace 정보를 수집하고 시각화하는 분산 추적 시스템이다.

Trace와 Span

Trace는 하나의 요청에 대한 전체 흐름이다.

Trace
 ├─ Span : Gateway
 ├─ Span : Order
 ├─ Span : Payment
 └─ Span : Delivery

Span은 Trace 내부에서 수행된 하나의 작업 단위를 의미한다.

이를 이용하면 각 서비스의 처리 시간과 호출 관계를 확인하여 어느 서비스에서 지연이나 오류가 발생했는지 파악할 수 있다.

---

11. Event-Driven Architecture

MSA에서는 서비스 간에 HTTP를 이용한 동기 통신뿐만 아니라 이벤트를 이용한 비동기 통신 방식도 사용할 수 있다.

동기 방식에서는 다른 서비스의 처리가 끝날 때까지 응답을 기다려야 하며, 특정 서비스에 장애가 발생하면 이를 호출하는 서비스에도 영향을 줄 수 있다.

주문 서비스
    ↓
결제 서비스
    ↓
배송 서비스
    ↓
알림 서비스

Event-Driven Architecture는 서비스가 다른 서비스를 직접 호출하는 대신 특정 상황이 발생했음을 나타내는 이벤트(Event)를 전달하는 방식이다.

예를 들어 주문이 완료되면 주문 서비스에서 주문 완료 이벤트를 발행하고, 해당 이벤트가 필요한 서비스들이 이를 전달받아 각자의 작업을 처리할 수 있다.

             "주문 완료" 이벤트
Order Service ────────────────> Message Broker
                                    │
                          ┌─────────┼─────────┐
                          ▼         ▼         ▼
                       Payment   Delivery   Notification

서비스 사이에서 이벤트를 전달하는 역할을 하는 것이 Message Broker이며, 대표적인 기술로 Kafka, RabbitMQ 등이 있다.

Event-Driven의 장점

• 느슨한 결합(Loose Coupling): 서비스가 서로를 직접 호출하는 구조를 줄일 수 있다.
• 비동기 처리: 다른 서비스의 작업이 끝날 때까지 기다리지 않고 각 서비스가 독립적으로 작업을 처리할 수 있다.
• 장애 격리: 하나의 서비스에 장애가 발생했을 때 다른 서비스까지 직접적인 영향을 받는 것을 줄일 수 있다.

Event-Driven Architecture에서는 메시지 처리 및 데이터 정합성 등 추가적으로 고려해야 할 부분도 존재한다.

Kafka와 같은 메시지 브로커에 대한 자세한 내용은 추후 학습하면서 정리해보려고 한다.

---

12. 전체 구조 정리

지금까지 학습한 내용을 간단한 MSA 구조로 나타내면 다음과 같다.

                         Client
                            │
                            ▼
                  ┌─────────────────┐
                  │   API Gateway   │
                  └─────────────────┘
                            │
               ┌────────────┼────────────┐
               ▼            ▼            ▼
          User Service  Order Service  Product Service
                            │
                      Feign Client
                            │
                    Service Discovery
                        (Eureka)
                            │
                     Load Balancer
                            │
                            ▼
                     Payment Service

각 구성 요소의 역할을 간단하게 정리하면 다음과 같다.

Eureka
→ 서비스의 위치를 등록하고 필요한 서비스를 찾을 수 있도록 한다.

Spring Cloud LoadBalancer
→ 여러 서비스 인스턴스에 요청을 분산한다.

FeignClient
→ 서비스 간 HTTP 통신을 간편하게 구현할 수 있도록 한다.

Spring Cloud Gateway
→ 외부 요청의 단일 진입점 역할을 하며 요청을 적절한 서비스로 전달한다.

Resilience4j
→ 특정 서비스의 장애가 다른 서비스로 전파되는 것을 방지한다.

Spring Cloud Config
→ 여러 마이크로서비스의 설정을 중앙에서 관리한다.

Zipkin
→ 하나의 요청이 여러 서비스를 거치는 과정을 추적한다.

추가적으로 서비스 간 결합도를 낮추거나 비동기 처리가 필요한 경우에는 다음과 같이 이벤트 기반 통신을 사용할 수도 있다.

Order Service
     │
   Event
     ▼
Message Broker
     │
     ▼
다른 마이크로서비스

Message Broker에는 Kafka, RabbitMQ 등의 기술이 있으며 자세한 내용은 추후 학습하면서 다룬다.

핵심 요약

MSA의 핵심은 단순히 하나의 애플리케이션을 여러 서버로 나누는 것이 아니다.

각각의 비즈니스 기능을 독립적인 서비스로 분리하고, 각 서비스가 독립적으로 개발·배포·확장될 수 있도록 만드는 것이 핵심이다.

하지만 서비스가 분리되면서 서비스 탐색, 서비스 간 통신, 로드 밸런싱, 장애 처리, 인증, 설정 관리, 모니터링과 같은 새로운 문제들이 발생한다.

Spring Cloud와 Eureka, Gateway, LoadBalancer, FeignClient, Resilience4j, Config 등의 기술은 이러한 MSA 환경의 문제를 해결하는 데 도움을 준다.

또한 필요에 따라 메시지 브로커를 활용한 Event-Driven Architecture를 적용하여 서비스 간의 결합도를 낮추고 비동기 통신을 구현할 수도 있다.