스프링 설정이 바뀌었을 때 빌드, 배포없이 갱신
스프링의 설정 파일들을 어떻게 외부로 분리?
특정 확률에 따라 광고를 내보내는 기능을 개발한다고 하자, 그리고 확률 값이 변경될 때마다 수익이 어떻게 변하는지 확인해보는 A/B 테스트를 진행할 것이다. 확률 값을 프로젝트 설정 파일에서 읽어오거나 특정 변수에 대입하여 사용할 텐데 이러한 경우 값을 변경할 때마다 다시 빌드 후에 배포하는 과정이 필요하다. 즉, 테스트마다 확률 값 설정한 후 다시 빌드하고 배포해야 한다.
이럴 때 Spring Cloud Config가 도움을 줄 수 있다.분산된 환경에서 설정 파일을 외부로 분리할 수 있도록 해준다. 개발/테스트 환경 그리고 운영 환경에서까지 모든 환경 구성을 간편하게 관리할 수 있다. 설정을 위한 별도의 서버를 구성하기 때문에 실행 중인 애플리케이션이 서버에서 설정 정보를 받아와 갱신하는 방식이다. 즉 실행 중에 설정값 변경이 필요해지면, 설정 서버만 변경하고 애플리케이션은 갱신하도록 해주기만 하면 된다. 따라서 설정이 바뀔 때마다 빌드와 배포가 필요 없는 구조이다.
Spring Cloud Config 는 분산 시스템에서 외부화된 설정 정보를 서버 및 클라이언트에게 제공하는 시스템이다. 설정 서버(Config Server)는 외부에서 모든 환경에 대한 정보들을 관리해주는 중앙 서버이다. 기본적으로 설정 정보 저장을 위해 git을 사용하도록 되어있어서 손쉽게 외부 도구들로 접근 가능하고, 버전 관리도 가능하다.
먼저 클라이언트는 서버로 설정값을 요청하면 서버는 설정 파일이 위치한 Git 저장소에 접근한다. 서버는 Git 저장소로부터 최신 설정값을 받고 클라이언트는 다시 서버를 통해 최신 설정값을 받는다. 만일, 사용자가 설정 파일을 변경하고 Git 저장소를 업데이트했다면 애플리케이션(클라이언트)의 actuator/refresh
엔드 포인트를 호출하여 설정값을 변경하도록 한다. 여기서의 설정값 갱신을 위한 엔드 포인트 호출은 각각의 클라이언트를 호출해야 하며 호출된 클라이언트만 반영된다.
Amazon EKS 관리형 서비스는 컨트롤 플레인을 직접 구성하지 않고서 쿠버네티스를 손쉽게 사용할 수 있도록 편리함을 제공한다. AWS에서 제공하는 VPC, ELB, IAM 등 특정 기능들을 같이 활용하고자 할 때 유용하다.