MSA(Microservices Architecture) 총 정리

이번 파트에서는 그동안 배우고 정리했던 MSA의 개념, 종류와 중요한 코드를 한 페이지에 정리하는 시간을 가져보도록 하겠다.

1. MSA(Microservices Architecture)

하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일이다.

[Product] - 독립APP
[  User ] - 독립APP
[ Order ] - 독립APP

MSA의 장단점

장점	단점
확장성: 특정 서비스만 확장하여 성능 최적화 가능	복잡성 증가: 서비스 간 통신, 데이터 일관성 유지 등의 복잡성 증가
독립적 배포: 개별 서비스의 변경 사항을 독립적으로 배포 가능	운영 비용 증가: 각 서비스의 모니터링, 로깅 등을 개별적으로 관리해야 한다.
유연성: 서비스별로 적합한 기술 스택을 선택할 수 있다.	데이터 관리: 분산된 데이터베이스로 인해 데이터 일관성 유지가 어려울 수 있다.

 

2. Spring Cloud

Spring Cloud는 분산 시스템(주로 마이크로서비스 아키텍처)의 공통 패턴을 쉽고 신속하게 구축할 수 있는 도구를 개발자에게 제공하는 프레임워크 생태계이다.

• 기존의 거대한 모놀리식 구조는 서비스가 커지면서 부분 확장과 배포가 어렵고, 한 곳의 장애가 전체로 번지는 한계가 있어 이를 해결하고자 서버를 잘게 쪼갠 마이크로서비스 아키텍처(MSA)가 등장했다.
• 그러나 수많은 서버의 설정 관리와 위치 추적 같은 새로운 분산 인프라 지옥이 열렸고, 이때 대규모 클라우드를 먼저 운영해 본 넷플릭스(Netflix)가 이를 통제할 수 있는 실전 노하우가 담긴 도구들을 오픈소스로 공개했다.
• 스프링 진영이 이 기술들을 흡수하여 자바 개발자가 어노테이션 몇 줄로 분산 시스템을 뚝딱 구축할 수 있게 표준화하며 탄생하게 되었다.

Spring Cloud 주요 모듈의 상황 별 역할

문제 상황	해결 모듈	핵심 역할
공통 설정(yml, properties) 변경 시 모든 서버를 재배포해야 함	Spring Cloud Config	설정을 원격(Git)에서 중앙관리 및 실시간 반영
클라우드 환경이라 서버 IP/Port가 수시로 변경됨	Spring Cloud Eureka	서버들의 위치를 동적으로 관리하는 주소록
진입점 일원화, 인증 검사, 라우팅이 필요함	Spring Cloud Gateway	모든 외부 요청을 안전하게 안내하는 보안역할
서버 간 복잡한 HTTP 통신 및 트래픽 분산이 필요함	OpenFeign + LoadBalancer	인터페이스 선언만으로 동적 부하 분산 통신 구현(라운드 로빈)
한 서버의 장애가 다른 서버로 전파되어 같이 터짐	Spring Cloud Circuit Breaker (Resilience4j)	장애 구간을 즉시 차단하고 우회 응답 처리
동기식 요청으로 인해 서버 간 결합도가 높고 응답속도가 느림	Spring Cloud Stream (이벤트 드리븐)	Kafka 등을 연동하여 비동기 이벤트 기반 구조 구현
여러 서버를 거치는 요청의 병목/에러 구간을 모름	Micrometer / Zipkin (분산 추적)	고유 ID(Trace)로 전체 이동 경로를 추적/시각화

 

3. 서비스 디스커버리(Service Discovery)

마이크로서비스 아키텍처에서 수시로 변하는 각 서비스 인스턴스의 위치(IP, Port)를 동적으로 등록하고 찾아주는 '자동 업데이트 주소록' 기능.

핵심 메커니즘 - 동적 관리: 서버가 켜지면 자신의 주소를 Eureka에 스스로 등록하고, 다른 서버가 호출할 때 Eureka가 그 주소를 알려준다.

• 헬스 체크(Health Check): 주기적으로 각 서비스의 생존 상태를 확인(Heartbeat)하여 가용성을 유지한다.
• 장애 격리: 서비스 장애 발생 시 해당 인스턴스를 레지스트리(주소록)에서 즉시 제거하여 다른 서비스의 접근을 차단한다.

Eureka Server 설정

spring.application.name=server
server.port = 19090

// 이 설정을 통해 Eureka 서버로만 작동할 거니까 클라이언트용 기능은 다 끈다는 의미
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false

eureka.instance.hostname=localhost
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

Client 설정

spring.application.name=first 
server.port = 19091 
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

 

4. 로드 밸런싱(Load Balancing) & FeignClient

MSA 환경에서 서비스 간 통신을 구현할 때, FeignClient와 LoadBalancer는 유기적으로 결합되어 분산 시스템의 가용성과 확장성을 보장하는 핵심 모듈이라고 할 수 있다.

4-1. 로드 밸런싱 (Load Balancing) // Ribbon을 대체하여 작동

• 정의: 트래픽을 여러 서버로 분산시켜 특정 서버의 부하를 방지하고, 시스템의 성능과 가용성을 높이는 기술
• 종류:
  • 서버 사이드: 외부 장비(Nginx, AWS ALB 등)가 중간에서 트래픽을 분산
  • 클라이언트 사이드: 요청을 보내는 클라이언트가 직접 서버 목록을 들고 분산 대상 선택 (Spring Cloud가 채택)

4-2. FeignClient

• 정의: Spring Cloud에서 제공하는 선언적 HTTP 클라이언트로, 인터페이스 기반으로 간결하게 REST API를 호출하는 도구
• 주요 특징:
  • 선언적 API 호출: 인터페이스와 어노테이션 정의만으로 복잡한 통신 코드 없이 호출 가능
  • Eureka 연동: 서비스 디스커버리와 통합되어 가용 서비스 인스턴스 목록을 동적으로 조회
  • 자동 로드 밸런싱: 내부에 로드 밸런서가 통합되어 있어 서비스 호출 시 자동으로 부하 분산 수행

@SpringBootApplication
@EnableFeignClients // 어노테이션을 통해 Eureka 서버와 연동
public class OrderApplication{

@FeignClient(name = "product-service") // Eureka 서버에 등록된 이름
public interface ProductClient{ // order 에서 product의 id를 가져오는 역할
    @GetMapping("/product/{id}")

    String getProduct(@PathVariable String id);
}

@Service
@RequiredArgsConstructor
public class OrderService {
    private final ProductClient productClient;

    public String getProductInfo(String productId){
        return productClient.getProduct(productId);
    }

    public String getOrder(String orderId){ // 조건 검사 및 비즈니스 로직 시작
        if(orderId.equals("1")){
            String productId = "2";
            String productInfo = getProductInfo(productId);
            return "Your order is " + orderId + " and " + productInfo;
        }
        return "Not exist order ...";
    }
}

2026.06.26 - [MSA 공부] - 로드 밸런싱 참고! 

5. 서킷 브레이커(Resilience4j)

특정 서비스에 문제가 발생했을 때, 장애가 다른 서비스로 연쇄 전파되는 것을 즉시 차단(Isolation)하고 우회 경로를 제공하는 안전장치 기술이다.

도입 배경 (연쇄 실패 방지): MSA 환경에서는 하나의 요청을 처리하기 위해 여러 서버가 사슬처럼 엮여 통신한다. 이때 만약 '결제 서비스'가 터져서 응답을 주지 못하면, 요청을 보낸 '주문 서비스'의 스레드(Thread)들이 응답을 기다리며 계속 대기(Blocking)하게 됩니다. 결국 주문 서비스의 자원까지 고갈되면서 시스템 전체가 도미노처럼 무너지는 연쇄 실패(Cascading Failure)가 발생한다.

서킷 브레이커 상태	설명
클로즈드(Closed)	- 기본 상태(Default)로 모든 요청을 통과시킨다. - 호출 실패 시, 실패 카운터가 증가하며, 실패율이 설정된 임계값을 초과하면 서킷 브레이커는 클로즈드(Closed) -> 오픈(Open) 상태로 전환한다.
오픈(Open)	- 오픈 상태로 전환 시, 모든 요청을 즉시 실패로 처리한다.(요청이 들어오면 에러로 응답) - 설정된 대기 시간(20초)가 지난 후, 서킷 브레이커는 하프-오픈 (Half-Open) 상태로 전환한다.
하프-오픈(Half-Open)	- 하프-오픈 상태에서는 제한된 수의 요청을 허용하여 시스템이 정상 상태로 복구되었는지 확인한다. - 요청이 모두 성공하면 서킷 브레이커는 다시 클로즈드(Closed) 상태로 전환한다. - 요청이 실패하면 다시 오픈(Open) 상태로 변환한다.

Fallback: 외부 서비스 호출 실패 시 대체 로직을 제공하여 시스템 안정성을 확보하는 방법

@CircuitBreaker(name = "myService", fallbackMethod = "fallbackMethod") 
    // 에러 발생 시, fallbackMethod로 이동
    public String myMethod() {
        // 외부 서비스 호출
        return externalService.call();
    }

    public String fallbackMethod(Throwable t) {
        return "Fallback response"; // 대체 로직 제공
    }

 

 

application.yml 설정(서킷 브레이커 상태 설정)

resilience4j:
  circuitbreaker:
    configs:
      default: 
        registerHealthIndicator: true  # 애플리케이션의 헬스 체크에 서킷 브레이커 상태를 추가하여 모니터링 가능
        slidingWindowType: COUNT_BASED # 최근 N번의 호출을 저장
        slidingWindowSize: 5  # 최근 5번 호출
        minimumNumberOfCalls: 5  # 서킷 브레이커가 동작하기 위해 호출 수를 5로 설정
        slowCallRateThreshold: 100  # 느린 호출의 비율이 이 임계값(100%)을 초과하면 서킷 브레이커가 동작
        slowCallDurationThreshold: 60000  # 60초 이상 걸리면 느린 호출로 간주
        failureRateThreshold: 50  # 실패율이 이 임계값(50%)을 초과하면 서킷 브레이커가 동작
        permittedNumberOfCallsInHalfOpenState: 3  # Half-open 상태 최대 호출 수 3
        waitDurationInOpenState: 20s  # Open 상태 유지 시간

6. API Gateway(Spring Cloud Gateway)

클라이언트와 서비스 간의 단일 진입점 역할을 하며, Gateway를 통해 인증 & 권한 부여, 라우팅, 로드 밸런싱, 모니터링 등을 처리한다. 

 

사용자는 각각의 URL에 따라 데이터를 요청하지않고, 하나의 URL을 통해 API Gateway에 요청을 하면 API Gateway는 인증, 인가, 요청, 응답 등을 수행하여 사용자가 원하는 데이터를 제공해주는 역할을 한다. 

6-1. Spring Cloud Gateway 필터링

Global Filter: 모든 요청에 대해 작동하는 필터

Gateway Filter: 특정 라우터에만 적용되는 필터

필터 시점별 종류

• Pre 필터: 요청이 처리되기 전에 실행되는 필터로, 요청을 가로채고 필요한 작업을 수행한 뒤, 체인의 다음 필터로 요청을 전달한다.
• Post 필터: 요청이 처리된 후, 응답이 반환되기 전에 실행된다(데이터를 가져온 뒤 실행). Post 필터에서는 체인의 다음 필터가 완료된 후에 실행되어야 하는 추가적인 작업을 수행해야 하기 때문에, chain.filter(exchange)를 호출하여 다음 필터를 실행한 후, then 메서드를 사용하여 응답이 완료된 후 실행할 작업을 정의하는 방식으로 진행된다.

CustomPostFilter

@Component
public class CustomPostFilter implements GlobalFilter, Ordered {

    private static final Logger logger = Logger.getLogger(CustomPostFilter.class.getName());

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, org.springframework.cloud.gateway.filter.GatewayFilterChain chain) {
        
        return chain.filter(exchange).then(Mono.fromRunnable(() -> { // chain.filter().then() 내부에 비동기 로직 예약
            ServerHttpResponse response = exchange.getResponse();
            logger.info("Post Filter: Response status code is " + response.getStatusCode());
        })); 
    }

    @Override
    public int getOrder() {
        return Ordered.LOWEST_PRECEDENCE; // 응답 직전 가장 마지막에 처리
    }
}

CustomPreFilter

@Component
public class CustomPreFilter implements GlobalFilter, Ordered {

    private static final Logger logger = Logger.getLogger(CustomPreFilter.class.getName());

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest response = exchange.getRequest();
        logger.info("Pre Filter: Request URI is " + response.getURI());

        return chain.filter(exchange); // 로직 실행 후 바로 chain.filter 반환
    }

    @Override
    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE; // 가장 먼저 진입
    }
}

application.yml(서버 설정)

spring:
  main:
    web-application-type: reactive  # Spring 애플리케이션이 리액티브 웹 애플리케이션으로 설정됨
  application:
    name: gateway-service  # 애플리케이션 이름을 'gateway-service'로 설정
  cloud:
    gateway:
      routes:  # Spring Cloud Gateway의 라우팅 설정
        - id: order-service
          uri: lb://order-service  # 'order-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/order/**  # /order/** 경로로 들어오는 요청을 이 라우트로 처리
        - id: product-service  # 라우트 식별자
          uri: lb://product-service  # 'product-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/product/**  # /product/** 경로로 들어오는 요청을 이 라우트로 처리
      discovery:
        locator:
          enabled: true  # 서비스 디스커버리를 통해 동적으로 라우트를 생성하도록 설정

본 설정을 통해 클라이언트는 각 마이크로서비스(Order, Product)의 실제 IP나 포트 번호를 알 필요 없이, Gateway(Port: 19091)라는 하나의 단일 창구(Single Entry Point)를 통해 내부 애플리케이션에 안전하게 접근할 수 있게 되었다.

7. 보안 구성(API Gateway & JWT)

마이크로서비스 아키텍처(MSA)에서는 각 서버마다 개별적으로 로그인 상태를 확인하는 세션 방식을 쓰기 어렵습니다. 따라서 시스템의 단일 진입점인 API Gateway와 JWT 토큰, 그리고 인증 서버(Auth)를 연동하여 중앙 집중식 분산 보안 시스템을 구축합니다.

1) 핵심 개념

• OAuth2: 토큰 기반의 인증 및 권한 부여 표준 프로토콜입니다. 클라이언트가 자격 증명을 통해 보호된 리소스(Microservices)에 안전하게 접근할 수 있도록 권한 체계를 제공합니다.
• JWT (JSON Web Token): JSON 형식의 자가 포함된(Self-contained) 토큰으로, 회원 ID나 권한 등의 정보(Claim)를 내부에 직접 들고 다닙니다. 헤더(Header), 페이로드(Payload), 서명(Signature)의 3단 구조로 이루어져 있으며, 서명을 통해 데이터의 변조 여부(무결성)를 보장합니다.

  

 

• 클라이언트의 요청: 클라이언트가 HTTP 헤더에 JWT 토큰을 실어 API Gateway로 요청을 보낸다.
• Gateway의 1차 검증: API Gateway는 해당 JWT 토큰의 서명(Signature)을 확인하여 위변조 여부 및 만료 기간을 통과시킨다.
• 인증 서비스(Auth) 연동: 필요한 경우, Gateway는 인증 서비스(Auth APP)에 직접 컨택하거나 내부 필터를 통해 해당 사용자의 상세 권한(Role) 정보를 주입받아 요청을 최종 승인한다.
• 마이크로서비스 라우팅: 검증이 완료된 안전한 요청만 뒤에 있는 개별 서비스(Service, Product, User 등)로 안전하게 라우팅한다.

Auth 설정

Auth/ application.yml

service:
  jwt:
    access-expiration: 3600000 # 1시간
    secret-key: "key"
	// 구현하기 위한 키 이므로 미제공
server:

 

Auth/Config 설정

@Configuration
@EnableWebSecurity
public class AuthConfig {

    // SecurityFilterChain 빈을 정의합니다. 이 메서드는 Spring Security의 보안 필터 체인을 구성합니다.
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                // CSRF 보호를 비활성화. CSRF 보호는 주로 브라우저 클라이언트를 대상으로 하는 공격을 방지하기 위해 사용.
                .csrf(csrf -> csrf.disable())
                // 요청에 대한 접근 권한을 설정
                .authorizeRequests(authorize -> authorize
                        // /auth/signIn 경로에 대한 접근을 허용(인증x).
                        .requestMatchers("/auth/signIn").permitAll()
                        // 그 외의 모든 요청은 인증이 필요
                        .anyRequest().authenticated()
                )
                // 세션 관리 정책을 정의. 여기서는 세션을 사용하지 않도록 STATELESS로 설정
                .sessionManagement(session -> session
                        .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                );

        // 설정된 보안 필터 체인을 반환
        return http.build();
    }
}

 

gateway/ LocalJwtAuthenticationFilter

public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String path = exchange.getRequest().getURI().getPath();
        if (path.equals("/auth/signIn")) {
            return chain.filter(exchange);  // /signIn 경로는 필터를 적용하지 않음
        }
		
        // //HTTP 요청 헤더에서 JWT 토큰을 추출하고, 비밀키를 통해 위변조 여부를 검증
        String token = extractToken(exchange); 
        
        // 검증 결과 토큰이 없거나, 만료되었거나, 위변조되었다면 뒤에 있는 서비스(Product, Order 등)로 
        // 요청이 전달되지 못하도록 401 Unauthorized 에러와 즉시 요청을 종료
        if (token == null || !validateToken(token)) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();

        }
        return chain.filter(exchange);
    }

8. Config(Spring Cloud Config)

분산 시스템 환경에서 각 마이크로서비스의 환경 설정(yml)을 한 곳에서 중앙 집중식으로 관리하는 프레임워크 (Git, 파일 시스템 등 지원)

주요 기능:

• 중앙 관리: 모든 서비스의 설정을 단일 원격 저장소에서 통제
• 환경별 분리: 개발(local/dev), 운영(prod) 등 환경에 따른 설정 격리
• 실시간 변경: 서버 재시작 없이 변경된 설정을 애플리케이션에 동적 반영 가능

Spring Cloud Bus

• 정의: 분산 시스템의 모듈들을 경량 메시지 브로커(Kafka, RabbitMQ 등)로 연결하는 상태 버스
• 핵심 역할: 특정 설정이 변경되었을 때, 단 한 번의 이벤트 발행으로 연결된 모든 마이크로서비스에 변경 사항을 실시간으로 동시 전파하여 반영함

수동 구성 갱신 (Bus 미사용 시)

• 정의: Spring Cloud Bus와 같은 메시지 브로커가 없을 때, 개발자가 직접 설정을 새로고침하는 방식
• 동작 방식: Config 서버의 설정 파일을 변경한 후, 각 마이크로서비스의 /actuator/refresh 엔드포인트로 각각 POST 요청을 직접 호출하여 변경된 설정을 수동으로 반영함

Config/application.yml

spring:
  profiles:
    active: native
  application:
    name: config-server
  cloud:
    config:
      server:
        native:
          search-locations: classpath:/config-repo

Product/application.yml

spring:
  application:
    name : product-service
  profiles:
    active: local
  config:
    import: "configserver:"
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server

9. 분산 추적(Zipkin)

도입 배경: MSA 환경에서는 하나의 요청이 여러 서비스를 거쳐 가기 때문에, 에러나 성능 저하가 발생했을 때 정확한 원인 지점을 찾아내기 어렵다.

분산 추적은 시스템 전체의 요청 흐름을 추적·모니터링하는 기법이다. 요청이 시작되어 끝날 때까지의 전체 이동 경로인 트레이스(Trace)와 그 과정에서 일어나는 개별 작업 단위인 스팬(Span)을 생성하여 서비스 간의 호출 관계와 성능을 시각화한다.

어느 요청이 여러 서비스를 거치면 어디서 문제가 생기는지 원인을 찾아내기 어렵다. 이를 해결하기 위해 분산 추적의 Zipkin을 통해 트레이스 데이터를 수집하고 시각화해주어 어디서 문제가 발생했는지 파악할 수 있도록 도와준다. 

 

핵심 용어

• 스팬(Span): 단일 서비스의 작업 단위 (작업명, 시작/종료 시간, 스팬 ID, 부모 스팬 ID 등을 포함)
• 트레이스(Trace): 사용자 요청 하나가 완료될 때까지 생성된 스팬(Span)들의 집합이며, 각 스팬 간의 인과관계(부모-자식)를 보여주는 전체 실행 흐름

management:
  zipkin:
    tracing:
      endpoint: "http://localhost:9411/api/v2/spans"
  tracing:
    sampling:
      probability: 1.0

 

10. 이벤트 드리븐

기존 동기식(Request-Response)방식의 한계

[기존 방식: 동기식 체인 구조]

고객 ──> [주문 서비스] 
               │
               ├── (1) 결제 요청 ──> [결제 서비스] (대기...) ──> 완료 응답
               │
               ├── (2) 배송 요청 ──> [배송 서비스] (대기...) ──> 완료 응답
               │
               └── (3) 알림 요청 ──> [알림 서비스] (대기...) ──> 완료 응답

발생하는 문제점

• 강한 결합도(Strong Coupling): 주문 서비스는 결제, 배송, 알림 서비스의 주소와 상태를 모두 알고 있어야 한다.
• 연쇄 장애(Cascading Failure): 만약 알림 서비스의 서버에 장애가 발생하여 응답을 주지 못하면, 주문 서비스까지 멈추거나 사용자에게 주문 실패 에러를 반환하게 된다.(하나의 장애가 다른 서비스에 영향을 준다)
• 응답 속도 저하(Latency): 각 서비스가 작업을 끝내고 응답을 줄 때까지 주문 서비스가 계속 기다려야하므로, 사용자가 겪는 최종 대기시간이 모든 서비스의 처리 시간을 더한 만큼 매우 길어질 수 있다.

 

이벤트 드리븐(Event-Driven) 방식으로 전환

이벤트 드리븐 방식은 서비스 간에 직접 요청을 주고받지 않는다. 대신 시스템 내에 중요한 상태변화(주문 완료)가 발생하면, 이벤트를 메시지 브로커에게 전달한다.

[개선된 방식: 이벤트 기반 구조]

고객 ──> [주문 서비스] ── (이벤트 발행: "주문 완료!") ──> ┌──────────────────┐
                                                           │  메시지 브로커  │
                                                           │ (Kafka/RabbitMQ) │
                                                           └──────────────────┘
                                                             │      │      │
                                      ┌──────────────────────┘      │      └──────────────────────┐
                                      ▼                             ▼                             ▼
                              [결제 서비스]                 [배송 서비스]                 [알림 서비스]
                        ("주문 완료" 이벤트 수신 후   ("주문 완료" 이벤트 수신 후   ("주문 완료" 이벤트 수신 후
                           자신의 결제 로직 처리)        자신의 배송 로직 처리)        자신의 알림 로직 처리)

이벤트 드리븐을 통해 개선되는 점

• 느슨한 결합(Loose Coupling): 주문 서비스는 이제 결제, 배송, 알림 서비스의 정보들을 각각 알필요가 없다. 단지 메시지 브로커에 이벤트만 전달만 하면된다.
• 장애 고립 및 탈력성(Fault Tolerance): 만약 하나의 서비스에 장애가 발생하여 중단되더라도, 메시지 브로커에 전달한 이벤트는 안전하게 남아있다. 따라서 시스템 전체가 마비되는 일이 사라진다.
• 압도적인 응답 속도(Asynchronous & High Performance): 주문 서비스는 메시지 브로커에 이벤트를 전달하자마자 응답을 받을 수 있다. 이들은 비동기방식으로 각자 알아서 처리하기 때문에 체감하는 서비스 속도가 매우 개선된다.