기존의 단일 프로젝트 멀티모듈 아키텍처에서는 GitHub Submodule을 사용하여 민감한 정보를 관리하고, 설정 파일이나 시크릿을 별도의 Private Repository로 분리하여 관리했다. 그러나 현재 마이크로서비스 아키텍처로의 이전 과정에서는 각 서비스마다 GitHub Submodule을 별도로 관리해야 하는 상황이 발생했다. 이로 인해 각 서버마다 서브모듈을 갱신하고 설정을 수정한 후 다시 빌드 및 배포하는 과정이 필요해져, 관리 오버헤드가 크게 커졌다.
그래서 위의 문제를 해결하기위해 중앙 집중식으로 처리해줄 수 있는 Spring Cloud Config Server에 대해 정리해보게 됐다.
Spring Cloud Config란?
Spring Cloud Config는 분산 시스템에서 외부화된 설정 정보를 서버 및 클라이언트에게 제공하는 시스템이다.
MSA(Microservices Architecture)에서는 수십, 수백 개의 서비스가 독립적으로 배포되는데 각 서비스의 구성 정보(DB 연결, API 키, 환경 변수)를 개별적으로 관리하면 복잡성, 보안 등에서 문제가 될 수 있다.
그래서, Spring Cloud Config Server는 이러한 문제를 해결하기 위해 "중앙 집중식 Config 정보 저장소를 제공"해준다.
Git, SVN, 파일 시스템 등 다양한 소스에서 설정 파일을 가져올 수 있으며, 설정의 관리와 배포를 중앙에서 통합하여 처리해준다.
Spring Cloud Config Server 구성 요소
Config Server: 모든 마이크로서비스들이 가져올 설정을 제공하는 서버
Config Client: 각 마이크로서비스가 Config Server에서 설정을 가져오는 클라이언트
Git Repository(Private): Config Server가 설정 파일을 들고오는 곳. (구성 파일 관리되는 저장소)
Spring Cloud Bus: 구성 변경 사항을 실시간으로 전파하기 위한 메시지 브로커 통합
Spring Cloud Config Server의 동작 원리
마이크로서비스가 Config Server에 설정 요청
마이크로서비스는 애플리케이션 시작 시 bootstrap.yml 또는 application.yml에서 설정 서버의 위치를 지정한다.
설정 서버는 클라이언트로부터 요청을 받으면 Git, SVN 또는 파일 시스템에서 설정 파일을 찾아 반환한다.
Git Repository에서 설정 파일 가져오기
Config Server는 Git Repository에서 설정 파일을 가져온다.
각 서비스는 자신의 애플리케이션 이름에 해당하는 설정 파일을 요청한다. ex) {서비스 명}-service-local.yml, {서비스 명}-service-prod.yml과 같은 형식
설정 정보 클라이언트로 전달
Config Server는 가져온 설정 파일을 해당 마이크로서비스 클라이언트에 전달한다.
클라이언트는 이 설정을 @Value나 @ConfigurationProperties 등을 통해 사용하게 된다.
⁉️ bootstrap.yml에서 application.yml로의 전환 bootstrap.yml
Spring Boot에서bootstrap.yml은 주로 Spring Cloud Config를 사용할 때 외부 설정을 로드하기 위해 사용되었음. 이 파일은 application.yml보다 먼저 로드되며, Config Server에 대한 정보를 포함하고 있어 해당 Config Server에서 설정 정보를 조회한다.
하지만 Spring Boot 2.4.X 버전부터는bootstrap.yml의 사용이 점차 줄어드는 것 같다. 이는 Spring Cloud 자체의 Config 로드 방식이 변경되었기 때문인데, 이제는application.yml하나로 대부분의 설정을 관리할 수 있게 되었다.
따라서, 최신 Spring Boot 프로젝트에서는bootstrap.yml대신application.yml을 사용하는 것이 권장한다.
과거에는 spring-cloud-starter-bootstrap 스타터 의존성을 명시적으로 추가하지 않아도, Spring Cloud가 자동으로 bootstrap.yml을 인식하고 사용. 하지만 Spring Boot 2.4 이후부터는 bootstrap.yml을 사용하려면 spring-cloud-starter-bootstrap 의존성을 명시적으로 추가해야 하며, bootstrap.yml 파일이 기본적으로 자동으로 로드되지 않게 됐다.
우선순위
프로젝트의 application.yaml
설정 저장소의 application.yaml
프로젝트의 application-{profile}.yaml
설정 저장소의 {application name}/{application name}-{profile}
설정 파일은 덮어쓰는 방식으로 작동하기 때문에 우선순위가 밀려있는 설정 파일이 적용되게 된다.
이에 따라 Spring Cloud Config Server를 도입하면, 중앙에서 모든 설정을 관리할 수 있게 되어 각 서비스에 설정을 자동으로 전달할 수 있습니다. Config Server만 관리하면 설정 파일 변경 시 자동으로 각 서버에 반영되며, 서브모듈 방식이라면 각 서버의 서브모듈을 수정하고 재배포하는 번거로운 작업이 필요합니다. 따라서 Spring Cloud Config Server는 설정 관리의 효율성을 크게 향상시키고, MSA 환경에서의 관리 오버헤드를 줄이는 데 유리합니다.
이와 같은 이유로 Spring Cloud Config Server는 MSA 아키텍처에서 설정 관리의 복잡함을 해결하고, 유지보수성을 향상시키는 중요한 도구가 됩니다.
