[LG CNS AM Inspire Camp] 21. Spring Cloud Config로 MSA 에서도 깔끔하게 설정해버리기

1. 들어가며

마이크로서비스 환경에서는 각 서비스가 독립적으로 운영되기 때문에, 서비스별로 관리해야 할 설정 파일도 많아지고 복잡해진다. application.yml이나 application.properties에 설정을 넣어 관리하는 전통적인 방식은 규모가 작을 때는 괜찮지만, 서비스가 많아질수록 유지보수가 어려워지게 된다.

그래서 등장한 것이 Spring Cloud Config. 이 구성 요소는 분산 환경에서 애플리케이션 설정을 중앙 집중식으로 관리하고, 깃(Git) 기반으로 버전까지 추적할 수 있게 해준다.

 

2. Spring Cloud Config란?

2.1 환경 설정을 중앙에서 관리하는 이유

단일 서비스에서는 보통 application.yml만 잘 관리하면 충분하지만, 마이크로서비스에서는 문제가 달라진다. 설정이 중복되기 쉽고, 환경별로 일일이 수작업으로 관리하게 되면 실수가 생길 확률도 커지게 된다.

이때 하나의 중앙 서버에서 모든 설정을 Git이나 Vault 같은 외부 저장소로부터 불러오고, 각 애플리케이션은 이 서버에서 설정을 가져와 사용하는 구조를 사용하면, 이를 통해 설정 일관성, 가시성, 재사용성을 높일 수 있다.

 

2.2 구조 간단 정리 : Config Server와 Config Client

• Config Server는 설정 파일을 Git 저장소에서 읽어와 REST API로 제공하는 서버 역할.
• Config Client는 이 서버에 요청을 보내서 필요한 설정을 받아오는 클라이언트 역할.

이미지 출처 : https://velog.io/@18k7102dy/Spring-Cloud-cloud-config%EC%97%90-%EB%8C%80%ED%95%9C-%EC%84%A4%EB%AA%85-%EB%B0%8F-%EA%B5%AC%ED%98%84

Git이 기본 저장소로 사용되기 때문에 설정의 변경 내역을 모두 추적할 수 있고, 브랜치를 이용해 환경별로 분리도 가능하다. 예를 들어 develop, main 브랜치를 각각 dev, prod 환경으로 쓰는 것도 가능하다.

 

3. Spring Cloud Config Server 실습 예제

 

Config Server 를 만든다고 할때, Spring Boot 프로젝트를 생성한 후에 아래와 같이 의존성을 추가해준다.

dependencies {
  implementation 'org.springframework.cloud:spring-cloud-config-server'
}

 

application.yml 에는 다음과 같이 Git Repository 경로를 설정해준다.

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-org/config-repo

 

그리고 @SpringBootApplication 클래스에 @EnableConfigServer 애노테이션을 추가하면 끝이다.

@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

 

 

config server가 있으면 config 설정들을 뿌려줄 client도 있어야한다.

 

4. Config Client 애플리케이션 실습 예제

이제 실제 서비스(Spring Boot 앱)가 Config Server에서 설정을 불러오게 만들어보자.

Client 쪽에서는 bootstrap.yml 또는 application.yml에서 아래와 같이 설정해주면 된다.

spring:
  application:
    name: my-service
  cloud:
    config:
      uri: http://localhost:8888

 

여기서 중요한 포인트는 application.name이 설정 파일의 이름과 매칭된다는 점이다.

예를 들어 my-service-dev.yml 파일이 Config Server의 Git 저장소에 있다면, my-service라는 이름을 가진 애플리케이션이 dev 프로파일을 활성화하면 그 파일을 가져오게 되는 식이다.

 

설정이 잘 반영되었는지는 @Value나 @ConfigurationProperties를 사용해서 확인할 수 있다.

@Value("${greeting.message}")
private String message;

 

5. 그런데 설정 파일은 어떻게 관리하면 될까?

5.1 Git Repository 구성

설정 파일을 Git Repository에 두는 구조는 생각보다 단순하다. 기본적으로 아래와 같이 구성한다.

config-repo/
  ├── my-service-dev.yml
  ├── my-service-prod.yml
  ├── gateway-dev.yml

 

이러한 구조를 통해 서비스와 환경을 분리할 수 있고, PR을 통해 설정 변경을 승인하고 리뷰하는 GitOps 방식도 적용 가능하다.

 

5.2 Profile과 Label의 역할

Config SErver에서는 다음과 같은 REST URL 구조로 설정을 불러온다.

/{application}/{profile}/{label}

 

예를들어

/my-service/dev/main

 

이렇게 요청하면 config-repo의 my-service-dev.yml을 main 브랜치에서 읽어오는 방식이다.

label은 보통 Git 브랜치 이름과 연결되어있다. 이를 통해 환경별로 설정을 완전히 분리할 수 있는 장점이 있다.

 

6. 설정 변경을 실시간으로 반영하려면?

이대로 Config Server를 사용하게 되면 문제가 발생한다. Config 가 변경되게 되면 결국 서비스를 재배포해서 설정을 반영시켜줘야한다는 번거로움이 남아있다.

Config Server는 설정을 중앙에서 불러오는 역할까지만 담당한다. 만약 설정을 Git에 커밋했을 때, 모든 서비스가 자동으로 최신 설정을 반영하게 만들고 싶다면, Spring Cloud Bus를 함께 사용해야 한다.

Spring Cloud Bus는 RabbitMQ, Kafka 같은 메시지 브로커를 사용해서 설정 변경 이벤트를 전체 애플리케이션에 브로드캐스트하는 방식인데, 이 내용은 다음 글에서 나눠서 다뤄보겠다.

 

7. 마무리

Spring Cloud Config는 마이크로서비스 환경에서 설정을 깔끔하게 중앙에서 관리하고, Git으로 버전 추적까지 가능하게 해주는 매우 강력한 구성 요소다. 단순한 설정 외부화를 넘어서, GitOps 방식의 설정 관리, 환경 간 설정 분리, 일관성 있는 관리 전략 수립까지 도와주는 도구라고 볼 수 있다.

다만 설정 변경을 반영하는 실시간 트리거는 Spring Cloud Config만으로는 어렵고, Spring Cloud Bus를 통해 메시지 기반으로 이벤트를 전파해야 가능한 구조다. 이 부분은 앞서 말했 듯, 다음 글에서 RabbitMQ와 함께 자세히 다룰 예정이다.