[Spring boot] MSA 환경 구성

 

서비스 레지스트리 / 서비스 디스커버리

MSA에서 마이크로서비스 관리와 운영을 위한 패턴 중 서비스 레지스트리와 서비스 디스커버리가 있다.
서비스 간 통신 시 서비스 위치 (포트, 호스트) 가 정적이던 전통적인 애플리케이션 / 아키텍처와는 달리

주소가 동적으로 변화하고 (클라우드 환경, 오토 스케일링, 컨테이너 기반의 배포 등) 서비스 역시

무수히 많은 마이크로서비스에서는 서비스 위치에 대한 관리가 많이 복잡해지게 되는데,

이를 해결하기 위해 서비스 레지스트리 패턴과 서비스 디스커버리 패턴이 등장하게 된다.

서비스 레지스트리와 서비스 디스커버리 패턴은 다음과 같다.

서비스 레지스트리

마이크로서비스 / 관리, 운영을 위한 기반 서비스의 주소와 유동적인 IP를 매핑하여 저장하는 패턴

서비스 디스커버리

클라이언트가 여러 개의 마이크로서비스를 호출하기 위해 최적 경로를 찾아주는 라우팅 기능,

적절한 부하 분산을 위한 로드 밸런싱 기능을 제공해야 하는데 이와 관련된 패턴

Example MSA Architecture

 

Spring Cloud Eureka

Spring Cloud Eureka는 Netflix OSS에서 제공하는 서비스 디스커버리 및 서비스 등록 서버이다.

MSA에서는 여러 개의 마이크로서비스가 개별적으로 배포되며, 각 서비스는 동적으로

실행되기 때문에 고정된 IP를 가지지 않는다. 이러한 문제를 해결하기 위해 Eureka 서버가

각 서비스의 위치를 관리하고, 클라이언트가 동적으로 서비스의 주소를 찾을 수 있도록 도와준다.

Eureka는 기본적으로 클라이언트-서버 구조로 동작한다.

Eureka Server는 서비스의 레지스트리 역할을 하며, 모든 서비스 인스턴스는

서버에 자신의 정보를 등록하며, 서버는 이를 유지 관리하게 된다.

 

Eureka Client는 Eureka Server에 등록되며, 다른 서비스의 정보를 가져와 동적으로 호출할 수 있다.

또한 Heartbeat로 Eureka Client는 정기적으로 자신의 상태를 Eureka Server에 전달하게 된다.

만약 일정 시간 동안 Heartbeat가 전달되지 않으면, Eureka Server는 해당 서비스를 제거한다.

레지스트리의 모든 정보는 모든 Eureka Client에서 복제되어 있으며 가용 중인 모든 서비스들의 목록을

확인할 수 있고 30초마다 목록이 갱신된다. Eureka Client 들에게 자신이 가지고 있는

Eureka Client 들의 정보를 공유하며, 일정 간격으로 Client로부터 핑을 전달받아 

가용 상태임을 확인하며 일정 횟수 이상 핑이 안 된다면 Eureka Client를 레지스트리에서 제외시킨다.

이것이 HeartBeat에 의해 이루어지는 것이다.

 

Eureka Server 설정

아래는 Eureka Server의 application.yml 설정 파일과 main 메서드이다.

@EnableEurekaServer
@SpringBootApplication
public class ModuleEurekaApplication {

	public static void main(String[] args) {
		SpringApplication.run(ModuleEurekaApplication.class, args);
	}

}

spring:
  application:
    name: ModuleEurekaServer

server:
  port: 8761

eureka:
  client:
    register-with-eureka: false  # Eureka 서버 자체는 다른 서버에 등록하지 않음
    fetch-registry: false         # Eureka 서버는 레지스트리를 가져오지 않음

 

Eureka Server가 자신을 다른 Eureka Server에 등록하지 않도록 설정하며,

fetch-registry 옵션을 false로 설정하여 Eureka Server가 다른 서비스의 레지스트리를 가져오지 않도록

설정해야 한다.

 

Eureka Client 설정

각 마이크로서비스는 Eureka Client로 동작하며, Eureka Server에 자신을 등록해야 한다.

server:
  port: 9000

eureka:
  client:
    register-with-eureka: true   # 해당 서비스를 Eureka Server에 등록
    fetch-registry: true         # Eureka Server에서 다른 서비스 목록을 가져옴
    service-url:
      defaultZone: http://localhost:8761/eureka  # Eureka Server 주소
  instance:
    hostname: localhost

@EnableDiscoveryClient
@SpringBootApplication
public class SampleApplication {

    public static void main(String[] args) {
        SpringApplication.run(SampleApplication.class, args);
    }

}

 

각 옵션에 대해 설명하면 다음과 같다.

• register-with-eureka: true: 해당 서비스가 Eureka Server에 등록
• fetch-registry: true: Eureka Server에 등록된 다른 서비스 정보를 가져온다.
• service-url.defaultZone: Eureka Server의 주소를 설정
  (여러 개의 Eureka Server를 설정할 수도 있음)

 

Spring Cloud Gateway

Spring Cloud Gateway는 API Gateway 역할을 수행하며,

클라이언트의 요청을 내부 마이크로서비스로 라우팅 하는 역할을 한다.

API 게이트웨이는 마이크로서비스 관리 / 운영을 위한 플랫폼 패턴이며 

해당 패턴에 필요한 기능들을 제공하는 서버를 일컫는다.
API 게이트웨이는 개별 서비스의 앞 단에서 모든 서비스들의 엔드포인트를 단일화한다.

이를 통해 클라이언트는 특정 서비스를 호출하지 않고 단순히 게이트웨이와 통신하며,
API 게이트웨이는 각 종류의 클라이언트에 특정 API를 제공할 수 있게 된다.

Spring Cloud Gateway는 비동기 방식을 통해 수많은 요청을 빠르게 처리할 수 있으며,

다른 Spring Cloud 기반 기술들과 통합이 잘 되어 있어 다양한 기술적 연계가 가능하다.

Spring Cloud Gateway의 기능을 살펴보면 다음과 같다.

 

인증과 인가
모든 서비스들에 대한 접근에 있어서 단일 진입점에서 인증과 인가 처리를 진행하며,

JWT 토큰 검증, 인증 및 권한 관리를 단일 진입점을 통해 쉽게 처리가능하다.

추가적으로 전역 필터 및 라우트 필터를 제공한다.

 

API 요청 로드밸런싱 및 라우팅

클라이언트의 요청을 식별하여 적절한 마이크로서비스로 전달한다.

 

QoS(Quality of Service)

안정적인 서비스 제공 및 네트워크 품질을 관리하며,

사용자 / 클라이언트 / API 단위로 접속을 제어한다.

 

로깅 및 모니터링

API 요청에 대한 로깅 / 모니터링 기능 지원한다.

 

입력 유효성 검사

API 요청의 적절한 형식과 필수 데이터 포함 여부를 식별 및 관리한다.

 

 

Spring Cloud Gateway 작동 원리 및 구성 요소

1. 클라이언트가 API Gateway에 요청을 보낸다.
2. Gateway는 라우팅 규칙을 확인하고 적절한 서비스로 요청을 전달한다.
3. 요청을 받은 마이크로서비스는 응답을 생성한다.
4. Gateway는 응답을 받아 클라이언트에게 반환한다.

구성하는 주요 3요소로는 Route, Predicate, Filters가 있으며,

사용자의 요청이 각 컴포넌트를 거쳐 라우팅 된다.

Route
Route는 고유 ID + 목적지 URI + Predicate + Filter로 구성되며, 

아래에서 소개할 Predicate + Filter의 묶음이자 라우팅이 될 규칙이라고 할 수 있다.
Route를 통해 SCG로 요청된 URI의 조건이 Predicate를 통과하여

참인 경우 매핑된 해당 경로로 매칭된다.

Predicate
Predicate는 주어진 요청이 주어진 조건을 충족하는지 테스트하는 구성 요소이며, 

하나 이상의 조건자를 정할 수 있다.
만약 Predicate에 매칭되지 않을 경우 SCG 자체적으로 HTTP 404 Not Found로 응답한다.

Filter & Filter Chain
Filter & Filter Chain은 SCG를 통해 들어오는 요청이나 반환되는 응답에 대해

전처리 / 후처리를 담당한다. 이 중에서 Proxy Filter는 프록시 요청이 처리될 때 수행되는 필터이다.

특정 Route에 적용할 수 있는 Gateway Filter와 전역적으로 적용되는 Global Filter로

추가 분류가 가능하다. 

 

Spring Cloud Gateway를 통해 다음과 같은 장점을 얻을 수 있다.

• 유연한 서비스 확장
  새로운 서비스가 추가되면 Gateway 설정을 수정하지 않고 Eureka에만 등록하면 된다.
• 자동 로드 밸런싱
  여러 개의 서비스 인스턴스가 등록된 경우 자동으로 부하 분산된다.
• 단일 진입점 제공
  클라이언트는 하나의 엔드포인트(Gateway)만 호출하면 된다.

 

여기서 라우팅 되는 하위 마이크로서비스 측에서 주소나 포트를 변경한 후 다시 실행하더라도 

일정 시간 단위로 Eureka Server에서 핑을 보내 마이크로서비스의 정상 작동 여부를 확인하고 

이용할 수 없는 서비스 정보는 삭제, 다시 실행된 마이크로서비스의 정보가 레지스트리에 등록되어 

갱신되기 때문에 Gateway에서 정보를 바꾸지 않더라도 서비스 연결이 가능해진다.

Spring Cloud Eureka와 Spring Cloud Gateway를 사용하면

서비스 등록 및 검색을 효율적으로 관리할 수 있고, API Gateway를 통해

라우팅 및 보안을 강화할 수 있다. 마이크로서비스 아키텍처에서 유연성과 확장성을 확보하기 위해

Eureka와 Gateway는 필수적인 요소이다. 다음 포스팅에서는 Spring Cloud Gateway

설정 및 필터를 통한 인증 프로세스에 대해서 알아볼 것이다.

 

참고자료

https://velog.io/@mrcocoball2/Spring-Cloud-Spring-Cloud-Eureka-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%EB%B0%8F-%ED%99%9C%EC%9A%A9-74mogeh0

https://velog.io/@mrcocoball2/Spring-Cloud-Spring-Cloud-Gateway-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90