개발 블로그

스프링 클라우드 게이트웨이 글로벌 필터와 지역 필터

chanhee01 — Mon, 5 Aug 2024 16:40:26 +0900

사진 출처 : 스프링 클라우드 MSA 유튜브 강의 (강의자 : 개발자 유미)

MSA 환경에서 각각의 마이크로 서비스로 요청을 하기 전에 jwt 검증, IP에 대한 접근 권한 등을 해야 하기에 필터를 적용해야 한다.

order라고 필터의 숫자가 있는데, 숫자가 작을 수록 가장 먼저 필터가 수행된다.

글로벌 필터 - 모든 서비스를 거치기 전에 거치는 필터
지역 필터 - 특정 마이크로 서비스 라우팅에 대해서만 동작하는 필터

1. 글로벌 필터 - 모든 서비스를 거치기 전에 거치는 필터

@Component
public class G1Filter implements GlobalFilter, Ordered {


    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {

        System.out.println("pre global filter order -1");
        // 마이크로 서비스를 거치기 전의 pre filter

        return chain.filter(exchange)
                .then(Mono.fromRunnable(() -> {

                    System.out.println("post global filter order -1");
                    // 마이크로 서비스를 거치고 난 후의 post filter
                }));
    }

    @Override
    public int getOrder() {

        return -1;
    }
}

위와 같은 코드가 글로벌 필터이다. @Component 어노테이션으로 필터로 지정하고, 이미 구현된 GlobalFilter, Ordered를 상속받아서 구현한다.

그리고 filter와 getOrder를 오버라이딩 해준다.

filter 함수를 보면 return 이전의 코드들은 마이크로 서비스에 접근하기 전에 수행되는 pre filter이며, return 이후의 코드들은 마이크로 서비스를 거치고 난 후에 실행되는 post filter이다.

getOrder 함수는 필터의 순서 값을 return 해주는 함수이다.

맨 위의 사진에서 보면 pre filter는 숫자가 낮은 필터부터 실행되지만, post filter는 마이크로 서비스를 거치고 난 이후기에 숫자가 큰 것부터 실행된다.

-2의 pre filter -> -1의 pre filter -> -1의 post filter -> -2의 post filter 순으로 실행된다.

server.port=8080
spring.application.name=SCG-2

spring.cloud.gateway.routes[0].id=ms1
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args.pattern=/ms1/**
spring.cloud.gateway.routes[0].uri=http://localhost:8081

application.properties에 위와 같이 8081 포트에 라우팅 해주고 8081/ms1/fisrt로 요청을 보내면 아래와 같이 나온다.

예상했던 것과 정확히 같은 순서로 동작한다.

2. 지역 필터 - 특정 마이크로 서비스 라우팅에 대해서만 동작하는 필터

@Component
public class L1Filter extends AbstractGatewayFilterFactory<L1Filter.Config> {

    public L1Filter() {

        super(Config.class);
    }


    @Override
    public GatewayFilter apply(Config config) {

        return (exchange, chain) -> {

            if (config.isPre()) {
                System.out.println("pre local filter 1");
            }

            return chain.filter(exchange)
                    .then(Mono.fromRunnable(() -> {

                        if (config.isPost()) {

                            System.out.println("post local filter 1");
                        }
                    }));
        };
    }

    @NoArgsConstructor
    @AllArgsConstructor
    @Data
    public static class Config {
        private boolean pre;
        private boolean post;
    }
}

위의 코드가 지역 필터의 코드이다.

생성자를 super 클래스로 만들어주고, apply 메서들을 오버라이딩 시켜준다.

이 때, return이 2번 등장하는데, 첫 번째 return은 pre filter의 부분이고, 두 번째 return은 post filter의 부분이다.

Config 클래스를 통해 변수 값 또한 받을 수 있다. 이 때는 lombok을 사용해서 받아줬다.

application.properties

server.port=8080
spring.application.name=SCG-2

spring.cloud.gateway.routes[0].id=ms1
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args.pattern=/ms1/**
spring.cloud.gateway.routes[0].uri=http://localhost:8081

# 지역 필터 관련 설정
spring.cloud.gateway.routes[0].filters[0].name=L1Filter
spring.cloud.gateway.routes[0].filters[0].args.pre=true
spring.cloud.gateway.routes[0].filters[0].args.post=true

지역 필터는 라우터에 대해 여러개의 필터를 등록할 수 있기에 index를 붙여주고, 위와 같이 설정을 추가해준다.

그리고 args를 통해 pre와 post를 true로 넣어줬다.

각 로직에서 true일 때만 로그를 찍기 때문에 이러한 변수를 설정해준 것이다.

위에서 작성한 글로벌 필터를 포함해서 로그가 총 6개가 찍힌 것을 확인할 수 있다.

application.properties의 변수를 false로 설정하면, 해당하는 필터는 로그를 찍지 않는다.

지금까지 스프링 클라우드 MSA를 공부해봤는데, 어려우면서도 재밌는 개념이라 공부를 하는데 즐겁게 할 수 있었다.

스프링 클라우드와 MSA의 개념은 매우 중요하고 많이 쓰이는 개념이기 때문에 앞으로도 잘 공부해야겠다는 생각이 들었다.

SCG 라우팅 추가와 삭제

chanhee01 — Mon, 5 Aug 2024 16:20:44 +0900

Gateway에서 여러 서비스들을 라우팅하는데, /user, /order 기능 외에 다른 마이크로 서비스 기능이 생겼다고 가정할 때, 추가 시 동작을 멈추고 재시작이 아니라 동작하는 상태에서 라우팅을 추가하는 방식이 존재한다.

필수 의존성 - Spring Boot Actuator

Actuator는 스프링 어플리케이션의 기능을 엔드 포인트로 제공하는 의존성으로, 가동중인 스프링 클라우드 게이트웨이에 새로운 라우팅을 추가 및 삭제할 수 있다.

server.port=8080
spring.application.name=SCG

management.endpoint.gateway.enabled=true # 특정 엔드포인트를 사용할 것이지
management.endpoints.web.exposure.include=gateway # 어떤 항목을 사용할 것인지 - gateway

의존성 주입 후 위와 같이 application.properties를 설정한다.

이 프로젝트는 Eureka Server 등 아무런 설정을 하지 않았기 때문에 localhost:8080/actuator/gateway/routes로 접근할 때아무것도 뜨지 않는다.

출처 : https://www.devyummi.com/page?id=668bb96a06cc3ded3bced8a8

라우팅을 추가 및 삭제하는 명령어에 대해 정리해둔 블로그가 있어서 첨부했다.

postman에 위와 같이 url과 JSON의 body를 넣고, 요청을 보낸다.

201 응답이 오면 성공이다.

추가한 뒤에 꼭 refresh를 POST 요청으로 보내고, 200 응답이 오면

방금 추가한 인스턴스가 라우팅에 추가된다.

삭제할 때에는 DELETE 요청을 보내면 되고, 이 때에도 refresh는 꼭 해줘야 한다.

이를 통해 서버를 무중지 상태로 라우팅을 추가할 수 있으며, 액츄에이터는 다른 사람이 외부에서 간단하게 조작할 수 있으므로 실 서비스 시에는 security 설정을 무조건 잘 해줘야 한다.

SCG - Eureka 연동 및 로드밸런싱

chanhee01 — Mon, 5 Aug 2024 15:55:50 +0900

MSA는 부하가 걸리면 자동으로 sclae out을 하는 기능을 내부적으로 가진다. 그렇기 때문에 라우팅 테이블에서 auto sclaing 된 후의 ip 주소를 알아야 한다.

SCG와 연동된 Eureka Server가 SCG에 리스트를 보내줘서 작동을 돕는다.

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' // 추가
	implementation 'org.springframework.boot:spring-boot-starter-webflux'
	implementation 'org.springframework.cloud:spring-cloud-starter-gateway'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'io.projectreactor:reactor-test' // WebFlux 테스트에 필요
}

SCG 프로젝트의 gradle에 eureka client로 동작할 수 있는 의존성을 추가한다.

server.port=8080

eureka.client.register-with-eureka=true
# eureka server에 나를 등록할 것인가
eureka.client.fetch-registry=true
# eureka에 등록된 클라이언트들의 정보를 등록할 것인가
eureka.client.service-url.defaultZone=http://admin:password@localhost:8761/eureka

이후에 application.properties에 다음과 같은 설정을 추가해준다. 이전 포스팅에서 eureka client 설정으로 했던 것과 동일한 설정이다.

Eureka Server 대시보드에 들어가보면 8081 포트와 8082 포트는 같은 비즈니스 로직을 수행하므로 이름을 ms1으로 동일하게 설정해서, 2개가 띄워졌다.

그 아래 SCG도 client로 포함되었다.

server.port=8080
spring.application.name=SCG

spring.cloud.gateway.routes[0].id=ms1
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args.pattern=/ms1/**
spring.cloud.gateway.routes[0].uri=lb://MS1

eureka.client.register-with-eureka=true
# eureka server에 나를 등록할 것인가
eureka.client.fetch-registry=true
# eureka에 등록된 클라이언트들의 정보를 등록할 것인가
eureka.client.service-url.defaultZone=http://admin:password@localhost:8761/eureka

로드밸런싱을 위해 추가 설정을 진행했다. 이전에 진행한 라우팅 설정에서 uri를 살짝 변경해줬는데, 이전에는 http://localhost:8081 같은 경로였는데, 이번에는 Eureka 대시보드에 이름으로 지정된 MS1 이라는 어플리케이션으로 라우팅한다는 의미로 lb://MS1으로 설정했다.

ms1의 마이크로 서비스

@RestController
public class HomeController {

    @GetMapping("/ms1/first")
    public String home() {
        return "ms1";
    }
}

ms2의 마이크로 서비스

@RestController
public class HomeController {

    @GetMapping("/ms1/first")
    public String home() {
        return "ms2";
    }
}

이렇게 2개의 마이크로 서비스를 같은 경로로 해둔 다음에 응답을 다르게 해두었다.

localhost:8080/ms1/first로 접근하면, ms1, ms2가 번갈아가며 나온다. 이를 통해 다른 경로의 라우팅 뿐만 아니라 sclae out에 따른 로드밸런싱까지 구현을 완료했다.

실제로 MSA 환경을 구성하면 AWS의 auto scaling 및 로드 밸런싱을 진행하게 될건데, 비용 등의 이유로 실제로 해보지는 않겠지만 spring cloud의 동작 원리를 로컬에서라도 작동시켜봤다.

스프링 클라우드 게이트웨이(SCG)

chanhee01 — Mon, 5 Aug 2024 15:38:56 +0900

Spring Cloud Gateway

스프링 클라우드 MSA 환경에서 가장 앞단에 존재하며 클라이언트로부터 요청을 받고 적절하게 서버에 보내준다.

가장 앞단에서 항상 무중지 상태로 모든 요청을 받기에 잘 신경써야 한다.

스프링 부트 어플리케이션, Eureka Server, Config와 같은 서비스는 블로킹 기반으로 톰캣 엔진을 통한 로직을 수행했지만, Gateway는 비즈니스 로직을 처리하기 보다는 단순하게 거쳐가는 라우팅 역할을 하기 때문에 논 블로킹 방식으로 구성되며 WebFlux와 Netty를 사용한다.

WebFlux는 기존 스프링 부트에서 사용하는 JPA와 같은 블로킹 방식의 의존성을 모두 사용하지 못한다.

필수 의존성 - Spring Cloud Routing의 Gateway

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-webflux'
	implementation 'org.springframework.cloud:spring-cloud-starter-gateway'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'io.projectreactor:reactor-test' // WebFlux 테스트에 필요
}

gradle의 의존성은 다음과 같다.

SCG의 라우팅 방법

application.properties 설정
application.yml 설정
Config 클래스 설정

client를 MS1, MS2로 각각 8081 포트, 8082 포트로 설정한 다음에 8081/ms1/first, 8082/ms2/second 경로를 설정해두었다. 이제 8081, 8082 포트가 아니라 8080 포트로 접근해도 알아서 라우팅해주는 gateway를 만들 것이다.

1. SCG - application.properties

server.port=8080

# 라우팅은 index로 0번부터 지정
spring.cloud.gateway.routes[0].id=ms1 # 이름
spring.cloud.gateway.routes[0].predicates[0].name=Path # Path 방식
spring.cloud.gateway.routes[0].predicates[0].args.pattern=/ms1/** # 경로
spring.cloud.gateway.routes[0].uri=http://localhost:8081 # 해당하는 포트

spring.cloud.gateway.routes[1].id=ms2
spring.cloud.gateway.routes[1].predicates[0].name=Path
spring.cloud.gateway.routes[1].predicates[0].args.pattern=/ms2/**
spring.cloud.gateway.routes[1].uri=http://localhost:8082

SCG의 application.properties의 port를 8080으로 지정하고, 아래에 spring.cloud.gateway.routes를 이용해서 하나는 8081 포트로, 하나는 8082 포트로 PATH를 진행한다.

8080 포트는 gateway로서의 설정만 했음에도, 8080/ms1/first, 8080/ms2/second로 요청을 보내면 404 Not Found가 아니라 응답을 한다. 이로 인해 8081 포트와 8082 포트로 라우팅을 한다는 것을 확인할 수 있다.

2. SCG - application.yml

server:
  port: 8080

spring:
  cloud:
    gateway:
      routes:
        - id: ms1
          uri: http://localhost:8081
          predicates:
            - Path=/ms1/**
        - id: ms2
          uri: http://localhost:8082
          predicates:
            - Path=/ms2/**

application.yml은 다음과 같이 설정하면 된다.

3. Config 클래스 설정

우선 application.properties나 application.yml 파일에서 포트 번호를 제외하고 나머지는 삭제한다.

@Configuration
public class CustomRoute {

    @Bean
    public RouteLocator ms1Route(RouteLocatorBuilder builder) {

        return builder.routes()
                .route("ms1", r -> r.path("/ms1/**")
                        .uri("http://localhost:8081"))
                .route("ms2", r -> r.path("/ms2/**")
                        .uri("http://localhost:8082"))
                .build();
    }
}

그리고 @Configuration 어노테이션을 통해서 라우팅을 빈으로 등록해주면 위와 같이 라우팅이 동작한다.

Eureka Client 등록 설정

chanhee01 — Mon, 5 Aug 2024 14:39:49 +0900

Eureka Client는 마이크로 서비스로 실행되는 각각의 스프링 서버가 Eureka Server로 관리되기 위해 설정을 통해 client로 작동하는 것이다.

일반적으로 MSA를 생각하면 떠오르는 각각의 기능을 수행하는 서버로 생각하면 된다.

build.gradle

ext {
	set('springCloudVersion', "2022.0.4")
}


dependencies {
	implementation 'org.springframework.boot:spring-boot-starter'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client' // eureka client
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

Eureka client 의존성을 추가해주고, Eureka client는 스프링 클라우드에서 동작하기 때문에 ext와 dependencyManagement까지 추가해줘야 한다.

Main class

@SpringBootApplication
@EnableDiscoveryClient // Eureka client 어노테이션
public class Ms1Application {

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

메인 클래스에 @EnableDiscoveryClient 어노테이션을 붙여서 Eureka client로 동작할 수 있게 해준다.

application.properties

eureka.client.register-with-eureka=true
#유레카 서버에 등록할지 여부
eureka.client.fetch-registry=true
#유레카 서버의 정보를 가져올지 여부
eureka.client.service-url.defaultZone=http://admin:password@localhost:8761/eureka
#유레카 서버 주소 (eureka.client.service-url.defaultZone=http://아이디:비밀번호@아이피:8761/eureka

application.properties에 다음과 같은 설정을 추가해줬는데, 차례대로 유레카 서버에 등록할지 여부, 유레카 서버의 정보를 가져올지 여부, 유레카 서버에 접근하기 위한 연결 주소이다.

이렇게 설정을 마치고 프로그램을 실행시켜주면, ms1이라는 이름으로 유레카 서버에 뜨게 된다.

Eureka 서버 구축

chanhee01 — Mon, 5 Aug 2024 13:57:27 +0900

이전 포스팅들에서는 스프링 서버에서 공통으로 사용하는 Config Repository와 Config Server에 대해 설명했다.

이번 포스팅에는 각각의 서버가 얼마나 켜져있는지, 어떤 상황인지를 모니터링할 수 있는 Eureka 서버에 대해서 알아볼 예정이다.

Eureka 서버의 역할

MSA를 구성하는 마이크로 서비스들을 모니터링하는 역할
스프링 클라우드 Gateway에게 마이크로 서비스들을 알려주는 역할
부하에 따라 자동으로 sclae out 되어도 Gateway에게 그 목록을 알려주는 역할

프로젝트 생성시 필수 의존성 - Eureka Server, Spring Security

Main Class

@SpringBootApplication
@EnableEurekaServer // Eureka Server를 위한 어노테이션
public class EurekaServerApplication {

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

프로젝트 의존성이 전부 주입되었으면, 메인 클래스에 @EnableEurekaServer 어노테이션을 붙여서 Eureka Server로 동작할 수 있도록 한다.

application.properties

server.port=8761

eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false

application.properties에도 위와 같이 설정을 해준다.

보통 port 번호는 8761번 port를 사용한다. 아래의 설정은 Eureka Server가 자기 자신을 등록하는 것을 방지해주는 설정과 client에 대한 fetch registry의 false에 대한 설정이다.

SecurityConfig

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean // 비밀번호 암호화
    public BCryptPasswordEncoder bCryptPasswordEncoder() {

        return new BCryptPasswordEncoder();
    }

    @Bean // http - security 관련 설정들
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http
                .csrf((auth) -> auth.disable());

        http
                .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated());

        http
                .httpBasic(Customizer.withDefaults());


        return http.build();
    }

    @Bean // 서버 접속은 간단하게 하기 위해 인메모리로 저장
    public UserDetailsService userDetailsService() {

        UserDetails user1 = User.builder()
                .username("admin")
                .password(bCryptPasswordEncoder().encode("password"))
                .roles("ADMIN")
                .build();

        return new InMemoryUserDetailsManager(user1);
    }
}

위의 코드는 Eureka Server의 보안을 위한 SecurityConfig 코드이다.

스프링을 실행하고 8761에 접속해서 admin, password를 입력하면 위와 같이 Eureka Server가 뜬다. 아직 스프링 어플리케이션이 없지만, Eureka Server의 대시보드를 띄웠고, 다음 포스팅에서 Eureka Server에 등록할 클라이언트를 공부하도록 하겠다.

Config 클라이언트 구축

chanhee01 — Sun, 4 Aug 2024 17:58:25 +0900

이전 포스팅에 Config 리포지토리와 서버를 구성했다. Config 서버에서 Config 리포지토리의 데이터를 받아오는 것까지 완료했으니, Config 서버에 접속해서 가져올 수 있도록 스프링 어플리케이션에 Config 클라이언트를 구성해야할 차례이다.

Config Client도 관련 의존성을 주입 받아야 한다.

application.properties에 Config 깃허브 Repository의 이름, 환경을 넣어주고 spring.config.import에 configServer에 대한 정보를 넣어주면 된다.

8080 포트에 접근하면 test라고 설정해둔 메시지가 나온다.

Config Repository와 Config Server에 접근해서 8080 포트로 연결한 것이다.

어플리케이션 설정파일이 아니라 Config Repository에서 포트를 8081로 변경하면 아래처럼 8081에 서버가 띄워진다.

클라우드 환경에서 여러 서버들을 파일 하나로 통제할 수 있다는 장점이 있다.

Config Server 설정

chanhee01 — Sun, 4 Aug 2024 17:20:47 +0900

지난 포스팅에서 Config Repository를 구축했는데, 여기서 데이터를 받아서 각각의 스프링 서버로 보낼 수 있도록 도와주는 Spring Config Server를 설정해볼 것이다.

spring 초기 세팅을 할 때 Spring Cloud Config의 Config Server와 Spring Security에 대한 의존성은 필수로 추가해야 한다. 이후의 의존성에 대한 세팅은 자유이다.

필수 의존성 - Config Server, Spring Security

프로젝트 설정 완료 시 가장 먼저 main 클래스에 @EnableConfigServer 어노테이션을 붙여준다. 이 어노테이션을 통해서 ConfigServer로 동작이 가능해진다.

application.properties에서 config server 관련 설정을 해주는데, 보통 config 서버는 9000으로 동작하기에 server.port는 9000으로 지정해줬다. 아래에는 깃허브의 주소, 설정, 접근을 위한 private key를 지정해주었다.

(properties 파일은 줄바꿈을 인식 못하기에 \n\으로 줄바꿈을 해준다.)

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http
                .csrf((auth) -> auth.disable());

        http
                .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated());

        http
                .httpBasic(Customizer.withDefaults());

        return http.build();
    }

    @Bean
    public UserDetailsService userDetailsService() {

        UserDetails user1 = User.builder()
                .username("admin")
                .password(bCryptPasswordEncoder().encode("password"))
                .roles("ADMIN")
                .build();

        return new InMemoryUserDetailsManager(user1);
        // 간단하게 하기 위해서 DB에 연결하지 않고 인메모리에 저장
    }

}

스프링 클라우드는 보안이 중요하기 때문에 security를 무조건 설정해줘야 한다. 위에 처럼 Security Config를 만들어서 스프링 빈으로 등록해준다.

이전에 Config 깃허브 Repository에 ms1-dev.properties라는 파일을 만들었는데, 이름을 그냥 지정한 것이 아니라 정해진 규칙에 따라 지정한 것이었다.

이름-환경.properties와 이름-환경.yml 파일에 있는 정보에 접근하기 위해 /이름/환경이라는 엔드포인트로 요청을 보내면 데이터를 받아올 수 있다.

localhost:9000/ms1/dev에 접근했더니, 관련 정보가 나오는 것을 확인할 수 있다.

지금은 source에 server.port밖에 없지만, Config Repository 파일에 더 많이 추가하면 source에 다른 요소들이 추가된다.

Config 깃허브 Repository 구축

chanhee01 — Sun, 4 Aug 2024 15:33:59 +0900

이전 포스팅에서 MSA 환경에서 공통으로 사용할 환경변수들이 지정된 Config Repository가 필요하다고 했었는데, 깃허브 리포지토리로 Config Repository를 구축할 수 있다.

리포지토리를 만들고 properties 파일을 하나 만들어준다. 이제 서버들에서 리포지토리를 사용할 수 있도록 키를 만들어줘야 한다.

접속하는 방법은 비대칭 키를 생성해서 public 키는 깃허브 리포지토리에 등록하고, Spring Config Server에서 private 키를 통해 접근한다.

터미널에 위와 같은 명령어를 입력해서 키를 생성했다.

해당 경로에 키가 생성되었다. 여기서 pulbic 키의 내용을 복사해서 깃허브 리포지토리에 넣어주면 된다.

Settings > Deploy keys > Add deploy key로 키를 등록해주면 된다.

public key의 내용을 입력했다.

이후에 Spring Config Server에서 private key를 가지고 여기에 접근하면 되고, 이에 대한 내용은 다음 포스팅에서 이어질 것이다.

스프링 클라우드 MSA

chanhee01 — Sun, 4 Aug 2024 15:03:23 +0900

모놀로식 개발 vs MSA 개발

모놀로식 개발은 프로젝트에서 흔히 사용하는 모든 기능들이 하나의 서버로 동작하는 방식이다. 이 방식은 간편하지만, 오류 발생 시 모든 기능이 사용 불가능하다는 단점과 하나의 프레임워크로만 개발되어야 한다는 단점이 존재한다. 때문에, MSA 구조의 개발에 대한 관심이 생겼다.

MSA의 장점

하나의 기능에서 오류가 발생해도 나머지 기능 사용 가능
언어, 프레임워크를 기능별로 다르게 사용 가능(스프링과 express 등)
서비스별 스케일링 가능

물론 장점만 존재하지는 않고, 초기에 구축하기 어려우며 분산 관리가 힘들다는 단점도 존재하긴 하지만, 그럼에도 불구하고 장점이 명확하기에 MSA를 공부하게 되었다.

사진 출처 : 스프링 클라우드 MSA 유튜브 강의 (강의자 : 개발자 유미)

스프링 클라우드 MSA의 구성 환경에 대한 그림이다.

각각의 스프링 부트 서버는 해당하는 요청을 받아서 로직을 수행한다.

Spring Cloud Gateway(SCG)는 요청에 해당하는 서버로 요청을 보내게 된다. 예를 들어서 /user로 요청이 왔다면, 해당하는 컨트롤러의 서버에 요청을 보내주는 역할을 한다.

Eureka Server는 각각의 스프링부트 서버와 Gateway의 상태를 모니터링할 수 있는 서버이다. 여기에는 등록되어 있는 모든 서버의 정보가 뜨며, 각각의 서버에서 등록을 시켜주면 Eureka Client가 생긴다. 추가적으로 Spring Cloud Gateway에 요청을 분배하는 로드밸런싱 역할도 한다. 스프링 MSA는 scale out이 자동으로 이루어지는데, 부하가 커졌을 때 새로운 ip 주소를 SCG에 알려주는 역할을 Eureka Server가 수행한다.

application.yml나 공통으로 사용되는 것들을 제공해주는 Spring Config Server가 뒷단에 존재해, 특정 서버의 Config Client에 데이터를 전달한다.

변수들은 Spring Config Server에 들어있지 않고 여기는 서빙만 해주는데, 뒤에 있는 Config Repository라는 곳에 데이터가 있다. 보통 깃허브 리포지토리, redis와 같은 저장소를 사용한다. 여기서 특정 변수값을 수정하면 모든 서버에서 수정된 변수를 사용할 수 있다.