spring cloud config 개념 및 동작 원리

spring cloud config 개념 및 동작 원리

Spring Cloud Config 개념 및 동작원리와 구현 예제까지 한 번에 정리를 해보려고 했으나, 구현 예제에 대한 내용이 다양하여 한번에 정리하기가 어려울 것 같아서 일단 개념과 동작 원리에 대해서만 먼저 정리하는 포스팅입니다.

 

 

*.properties, *.yml 파일

spring cloud config에 대해서 살펴보기 전에 .properties 또는 .yml 파일의 역할에 대해서 먼저 살펴보겠습니다.

*.properties와 *.yml 파일은 어플리케이션의 환경 설정 값을 가지고 있는 파일로 '환경설정 파일', '외부 설정 파일'(=config file)이라고 불리는데요.

 

스프링 부트 어플리케이션에서 이러한 환경설정 파일이 필요한 이유는 로컬(local), 개발(dev), 운영(prod) 환경에 따라 설정 정보(DB 연결 주소 등)가 다르기 때문에, 운영 환경에 따라 설정 값을 다르게 처리하고 관리할 수 있도록 하기 위함입니다.

(외부 API를 사용하기 위한 API Key 등의 중요한 값을 소스코드에 그대로 노출되지 않기 위한 방법이기도 합니다.)

 

/*

.properties 파일은 key=value의 구조를 가지고 있으며, .yml(=yaml) 파일은 .properties 파일에서 반복되는 prefix를 줄여 계층적 구성으로 표현할 수 있으며, 가독성이 좋아진다는 장점이 있습니다.

*/

 

 

 

spring cloud config가 필요한 이유?

그렇다면 spring cloud config는 무엇이며, 필요한 이유는 무엇일까요?

사용하고자 하는 서비스의 환경설정 값의 수정이 필요한 경우, 해당 어플리케이션은 변경된 환경설정 값을 수정하여 다시 빌드하고 배포를 하는 과정을 거쳐야 하는데요. 만약 환경설정 값의 수정이 자주 일어나거나, 관리해야 할 서비스가 많은 경우 이것은 매우 번거로운 일이 될 수 있습니다.

 

Spring Cloud Config는 분산 시스템에서 외부화된 설정 정보를 서버 및 클라이언트에게 제공하는 시스템으로 모든 외부 환경설정에 대한 정보들을 관리해주는 '중앙 서버'의 역할을 하는데요. 주요 기능으로는 서비스의 환경설정 값이 변경되었을 때 다시 빌드하고 배포하는 과정 없이 변경된 설정 값을 반영할 수 있다는 장점이 있습니다.

 

 

***

단점으로는, spring cloud config에서 외부 설정 파일은 git repository에 저장하여 사용되는 경우가 많는데요.

git 서버 또는 설정 서버(Config Server)에 의한 장애가 전파될 수 있으며, 설정 파일이 여러 곳에 나눠져 있고, 제대로 관리가 되지 않는 경우 spring cloud config가 설정 파일을 읽어드리는 우선순위에 의해 잘못된 정보를 가져오게 될 수도 있습니다.

 

/*

1. 프로젝트의 application.yml

2. 설정 저장소의 application.yml

3. 프로젝트의 application-{profile}.yml

4. 설정 저장소의 {application name}/{application name}-{profile}

 

설정 파일은 다음 위치에 존재할 수 있으며, 위에서부터 순서대로 읽어지는데, 나중에 읽어지는 것이 우선순위가 높습니다.

/*

 

 

 

동작 원리

spring cloud config 동작 원리

Spring Cloud Config의 동작 원리는 크게 세 가지 부분으로 나눠서 살펴볼 수 있는데요.

먼저 핵심이 되는 'Spring Cloud Config Server'와 하나 이상의 'Spring Cloud Config Client' 그리고 설정 파일이 저장되는 'Git Repository'(또는 JDBC, REDIS, File System 등)로 나눠집니다.

 

동작 방식은 Config Client가 Config Server에게 설정값을 요청하면 Config Server는 설정값이 저장된 중앙 저장소(git repository 등)를 통해 해당 설정값을 찾아 Config Client에게 다시 전달하는 방식인데요.

만약 외부 설정 파일의 설정값이 바뀌었을 때는 Spring Cloud Config Client의 '/actuator/refresh API'를 요청함으로써 변경된 설정값을 반영할 수 있습니다.

(설정 값의 변경으로 인해 어플리케이션을 다시 빌드하고 배포하는 번거로운 과정을 거치지 않아도 됩니다.)

 

 

하지만 이러한 구조에서 Spring Cloud Config Server에 연결된 Client Application의 수가 많고, 해당 Client Application들에게 공통적으로 사용되는 설정값이 바뀌었다고 하면, 각각의 Client Application 모두에 /actuator/refresh API를 호출해야 하는데, 이는 비효율적일 뿐만 아니라 실수로 호출을 빼먹었을 경우 문제가 발생할 수도 있는데요.

 

이러한 문제점은 'Spring Cloud Bus'를 사용해서 해결할 수 있다고 하며, 해당 부분 역시 추후 포스팅을 통해 아래에 함께 링크해놓도록 하겠습니다.

 

 

 

< 참고 자료 >

https://mangkyu.tistory.com/253

https://ch4njun.tistory.com/268