Spring Boot MSA 아키텍처 구축 : 기초 개념

2025. 3. 8. 22:01·Spring/MSA

이번 게시글에서는 MSA의 전반적인 개념과 구조에 대해서 살펴본다.

또한 각각의 컴포넌트가 Spring Boot에서 어떻게 사용될지를 살펴본다.


MSA 기초 개념

모놀리식 아키텍처

하나의 서비스에서 여러개의 프로세스가 동작하는 아키텍처이다.

scale up은 자유롭지만, scale out 시 데이터베이스 귀속 문제 등으로 인해 확장이 어렵다.

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

여러개의 기능을 각각의 독립적인 컴포넌트로 분리 및 배포하는 아키텍처이다.

여러 msa를 모으면 하나의 서비스가 되어야하기에 msa 간 통신이 가능해야 한다.

 

msa의 장점 중 하나는 확장과 업데이트가 쉽다는 것이다.

  • 확장 : 개별 컴포넌트를 scale out하기 쉽기에 확장이 쉬움
  • 업데이트 : 개별 독립적인 컴포넌트에 대한 테스트 시나리오만 고려하면 되기에 업데이트가 쉬움
    • 각각의 컴포넌트는 서로 독립적으로 작동한다는 가정이 있기 때문

MSA를 활용한 루즈 커플링

루즈 커플링 : 컴포넌트 간 의존성을 최소화 하는 것

 

아래와 같은 방식으로 MSA를 활용한 루즈 커플링이 가능하다.

  • 컴포넌트 업데이트시 인터페이스나 API 변경 최소화
    • 인터페이스나 API의 변경은 다른 컴포넌트의 수정으로 이어지기 때문
  • 외부에는 서비스의 기능인 API 혹은 추상화된 기능만을 노출
  • 특정 기술에 얽메여서 다른 서비스에 영향을 주면 안됨
  • 서비스를 stateless하게 디자인하여 확장이 쉽도록 해야함

 

전체적인 MSA 아키텍처 구조도

 

아래는 2018년에 가트너에서 제공한 MSA의 전반적인 구조이다. 

상당히 복잡한 내용이지만, 우선 아래와 같이 간단하게 흐름을 정리할 수 있다.

  1. 클라이언트가 External API Gateway로 요청 전달하고, 요청을 전달할 서비스를 결정함
  2. API Gateway는 Service discovery를 통해 요청을 보낼 서비스의 IP, port 정보를 받아옴
  3. Load Balancer로 트래픽을 적절한 서비스에 분배함
  4. 각 서비스들은 config store 혹은 config server에서 설정 정보를 받아와서 동작함 (설정정보 분리)
  5. 서비스 간 통신이 필요하면 Service Discovery를 통해 대상 서비스의 정보를 조회 및 사용
  6. 응답이 준비되면 API Gateway를 통해 응답을 클라이언트에 전달

위 설명은 MSA의 모든 흐름을 설명하지 않지만, 간단한 흐름을 이해하기에 충분하다.

 

Discovery Service

 

Discovery Service와 Spring Boot에서 사용할 수 있는 Discovery Service에 대해서 알아본다.

Discovery Service의 역할

Discovery Service는 서로 다른 IP와 포트를 갖고 있는 서비스들의 주소 정보를 저장 및 관리하는 서비스이다.

Discovery Service의 필요성

MSA 아키텍처에서는 각각의 기능들이 서로 독립적인 서비스로서 동작하고, 이러한 서비스들의 주소는 매번 동적으로 바뀔 수 있다.

이러한 상황에서 매번 변경 위험성이 있는 특정 서비스의 ip와 port를 특정짓는 것은 어렵기 때문에 서비스의 주소 정보를 관리하기 위한 Discovery Service가 필요하다.

Spring Boot에서의 Discovery Service : Netflix Eureka

이번에는 Netflix Eureka라는 라이브러리를 활용하여 서비스 디스커버리를 구축할 예정이다.

 

Netflix Eureka는 client와 server로 구성된다.

  • Eureka Client : Eureka Server에서 관리할 서비스 정보 주체
    • MSA의 각각의 서비스를 유레카 클라이언트로 등록할 수 있다. 
    • client는 자신의 정보를 유레카 서버에 등록 및 관리
    • client는 주기적으로 서비스별 정보(ip, port, service name)을 Fetch하여 보관
  • Eureka Server : Eureka Client의 정보를 관리하는 서버
    • 서버-클라이언트 구조로 구성되고, json와 Restful API를 지원
    • Eureka Server는 Eureka Client의 정보를 관리하고, 이를 다른 Eureka Client와 공유함

또한 Eureka는 아래와 같은 방식으로 동작한다.

  1. 클라이언트 서비스 시작시 유레카 서버에 서비스 정보를 등록
  2. 클라이언트는 일정 간격으로 핑을 전송하여 가용상태임을 알리고, 서버는 핑을 통해 클라이언트의 상태를 체크함
  3. 레지스트리(클라이언트 정보 목록) 정보를 모든 클라이언트들과 공유

서비스들의 가용 여부와 정보는 일정 간격으로 갱신되고, 서비스 이름을 기반으로 API 호출을 가능하도록 해준다.

 

API Gateway

API Gateway의 역할과 Spring Boot에서의 API Gateway에 대해서 알아본다

API Gateway의 역할

API Gateway는 서비스와 클라이언트의 요청 간 중계 역할을 하는 장치이다.

Netflix Eureka와 함께 사용한다면 서비스가 재시작되어도 최신 서비스 정보를 사용 가능하다.

API Gateway는 서비스로의 단일 진입점을 제공한다. 따라서 클라이언트는 API Gateway의 주소만 알고 있으면 된다.

API Gateway의 특징과 필요성

  • 인증 및 보안 : 리소스에 대한 인증 요구 사항을 기반으로 요청 분류 가능
    • 따라서 사용자 요청에 대한 인증 및 보안을 한 곳에서 관리 가능
  • 모니터링 : 모니터링 및 통계 제공
  • 동적 라우팅 : 요청을 다른 클러스터(특정 기능에 대한 서비스 집합)로 동적으로 라우팅
  • 부하 테스트 : 성능 측정을 위한 부하 테스트 가능
  • 부하 차단 : 각 서비스별 요청에 대한 용량 할당 및 제한 가능
  • 정적 응답 처리 : 클러스터의 응답을 대신 처리

API Gateway : Zuul VS Spring Cloud Gateway

우리는 Spring Cloud Netflux Zuul와 Spring Cloud Gateway를 Gateway로서 사용 가능하다.

  Zuul Spring Cloud Gateway
기본 개념 JVM 기반의 라우터 겸 로드밸런서 서비스 간 요청을 처리하는 API Gateway
Spring 지원 Spring Boot 2.4부터 지원 종료 Spring Cloud와 긴밀하게 연결
비동기 처리 차단 API를 사용하기에 성능 저하 우려 비차단 API를 사용 (Netty, WebFlux 기반)
장기 연결 웹소켓와 같은 장기 연결은 지원하지 않음 장기 연결 지원
라우팅 방식 필터 기반의 전통적인 프록시 API 기반의 동적 라우팅
필터링 방식 서블릿 기반의 pre, post 필터 Webflux 기반의 비동기 필터링

 

따라서 Spring 생태계와 긴밀히 연결되어 있고 웹소켓을 지원하는 Spring Cloud Gateway를 사용하는 것이 좋을 것이라 판단했다.

 

Config Sever

Config Server 역할

Config Server는 분산 환경에서 환경변수를 관리하기 위해 사용하는 서버이다.

Config Server의 필요성

기존에는 서비스 내부 설정 파일에서 환경변수를 관리했기에 변경 사항 적용을 위해서는 서버 재시작이 필요했다.

Config Server는 외부에서 환경변수를 가져오기에 서비스 실행 중에 환경변수 갱신이 가능하다.

이러한 설정 파일은 git와 같은 외부 저장소로부터 암호화/복호화를 통해 Json API 형태로 제공할 수 있다.

Config Server : Spring Cloud Config

Spring 생태계에서는 설정 파일 관리를 위해 Spring Cloud Config에 대한 의존성을 제공한다.

Eureka와 마찬가지로 Server와 Client로 구분된다.

  • Spring Cloud Config Server
    • 외부에 저장된 설정 정보를 Spring Cloud Client에게 제공해주는 역할을 한다.
    • MSA 환경에서 설정 정보의 중앙 집중화를 가능하도록 한다.
    • Actuator와 연동하여 동적으로 설정 정보를 갱신할 수 있다.
    • 기본적을 Spring Cloud Server는 외부 저장소로 git을 선택한다.
  • Spring Cloud Config Client
    • Spring Cloud Config Server에서 설정 정보를 받아오는 주체
    • @RefreshScope 어노테이션으로 설정 정보 변경시 자동 갱신이 가능하다
    • client는 application 이름과 profile을 기반으로 설정 정보를 받아올 수 있다.

 

설정 정보는 git에 yml 혹은 properties 형식으로 저장 가능하고, 로딩 순서는 아래와 같다.

  1. config client의 application.yml
  2. 외부 저장소의 application.yml
  3. config client의 application-{profile}.yml
  4. 외부 저장소의 application-{profile}.yml
  5. 외부 저장소의 {application_name}.yml
  6. 외부 저장소의 {application_name}-{profile}.yml

더 늦게 로딩되는 설정 정보가 더 우선순위가 높다.

따라서 1과 6에 동일한 설정 정보가 있다면, 최종적으로 6이 적용된다.

 

서비스 간 통신 

서비스 간 통신의 필요성

MSA에서는 각 기능들이 독립적인 서비스로 동작한다.

따라서 두 서비스 간 의존성이 있다면 이를 서비스 간 통신으로 해결할 수 있다.

서비스 간 통신 방법

서비스 간 통신은 크게 두 가지로 나뉜다.

  1. API Gateway를 통한 통신
    • API Gateway라는 단일 진입점을 사용한 통신 방법
    • API Gateway에서 서비스 주소를 관리하기에 서비스 주소 관리 불필요
    • API Gateway에서 인증 및 인가를 관리하기에 인증 인가 책임 전가 가능
    • 문제점 : 네트워크 부하 증가, Gateway의 SPOF 문제
  2. p2p 통신
    • MSA 간 직접 통신 방식
    • HOP (API Gateway와의 불필요한 통신)이 없음
    • 서버 간 호출이 많다면 1번 방법에 비해 유리함
    • 서비스 주소 관리가 필요하지만, Eureka를 사용하면 해결 가능
    • 문제점 : 중앙에서 API 호출 통제가 어려움

RestTemplate VS WebCLient VS OpenFeign

Spring Boot에서 선택할 수 있는 통신 방법은 크게 세 가지가 있다.

이번에는 각각을 비교해볼 예정이다.

  RestTemplate WebClient OpenFeign
패러다임 동기0 비동기 선언적
Spring 지원 maintenance mode 공식 지원 공식 지원
비동기 처리 지원 안함 지원 선택적 지원
성능 낮음 ( Tread Blocking ) 높음 ( Non-Blocking ) 중간 (Http Client 기반)
기반 라이브러리 + 웹서버 Spring MVC  ( tomcat ) Spring Webflux ( netty ) Spring MVC ( tomcat )
편의성 낮음 유연한 설정 가능 인터페이스를 통한 자동 구현
주요 사용처 간단한 API 호출 대규모 특래픽 비동기 처리 MSA 간 통신

 

따라서 필요에 따라서 적절한 라이브러리를 선택하면 된다.

 

필자의 경우, 외부 요청과 MSA 간 통신이 모두 필요하기에 WebClient 기반의 MSA 통신 방법을 선택했다.

또한, 추후 웹소켓 기반 통신 시스템 구축이 필요하기에 WebClient가 더 유리하다는 판단을 내렸다.

 

마무리

 

이번 게시글에서는 성공적으로 Spring Boot에서의 MSA 아키텍처에 대해서 알아볼 수 있었다.

 

각각의 개념과 기술스택을 마지막으로 정리한다.

  역할 기술스택
Service Discovery MSA 환경에서 서비스 주소 관리 Netflix Eureka
API Gateway MSA 환경에서 단일 진입점 제공 Zuul, Spring Cloud Gateway
Config Server 분산 환경에서 동적으로 설정 정보 관리 Spring Cloud Config
MSA 간 통신 분산 환경에서 서비스 간 통신 RestTemplate, WebClient, OpenFeign

 

여러 기술이 있는만큼, 현재 진행하는 서비스의 특성에 맞게 적절한 서비스를 선택하는 것이 중요할 것이다.

'Spring > MSA' 카테고리의 다른 글

[Spring Boot] MSA 아키텍처 구축 : API Gateway와 Service Discovery  (0) 2025.03.16
'Spring/MSA' 카테고리의 다른 글
  • [Spring Boot] MSA 아키텍처 구축 : API Gateway와 Service Discovery
코드래곤
코드래곤
코드래곤 님의 블로그 입니다.
  • 코드래곤
    코드래곤 님의 블로그
    코드래곤
  • 전체
    오늘
    어제
    • 분류 전체보기 (61)
      • 알고리즘 (3)
        • 그리디 (1)
        • 그래프 (2)
      • 시스템 설계 (6)
      • CS 및 기본 개념 (17)
      • Docker (5)
      • Spring (23)
        • 백준 서비스 구현하기 (1)
        • 기초 개념 (14)
        • MSA (2)
        • JPA (1)
      • Dart (3)
      • Flutter (1)
      • Kubernetes (3)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.4
코드래곤
Spring Boot MSA 아키텍처 구축 : 기초 개념
상단으로

티스토리툴바