Spring Cloud Config Server 구축

배경

애플리케이션에서 설정정보라하면 배포 환경마다 달라질 수 있는 모든 값이다. 12factor에 따르면 이러한 설정정보는 코드에서 분리하여 따로 관리하길 권장하고 있다. 코드에 종속된 설정정보라면 설정정보 변경 시 전체코드 재빌드가 필요하니 유지보수성이 떨어진다. 이를 극복하기 위해 각 프로젝트마다 application.yml을 따로 두어 설정 정보를 관리하면 하드코딩으로 설정정보를 입력하는 것보다 훨씬 유지보수성이 좋아질 것이다. 다만, 이러한 방식은 한 애플리케이션에서 관리해야할 프로젝트가 여럿인 경우에 유지보수성이 떨어지게 된다.

 

spring cloud config를 이용하면 config자체도 하나의 서버로써 설정정보를 동적으로 바꾸고 관리할 수 있다. 또한 각 프로젝트 내에서 설정 정보를 관리하는 게 아닌 한 서버에서 모든 설정정보를 관리하니 유지보수성도 높일 수 있다.

 

 

Spring Cloud Config Server

설정정보를 작성하기 전에 의존성 추가화 @EnableConfigServer 애노테이션을 추가해주자. 아마도 더이상 java코드를 작성할 일은 없을 것이다.

 

이제 설정파일을 읽어들일 저장소를 선정하고 설정정보를 작성하자. 이 예제에선 github의 private 레파지토리를 저장소로 사용하겠다. (개인 private github 저장소를 만드는 과정은 생략)

이제 설정파일을 읽어들일 저장소를 선정하고 설정정보를 작성하자. 이 예제에선 github의 private 레파지토리를 저장소로 사용하겠다. (개인 private github 저장소를 만드는 과정은 생략) 위와 같이 적은 뒤 url에 본인의 레포지토리 url을 적고 레포지토리가 private이기 때문에 username과 password도 적어주도록 하자. 여기서 default-label을 본인의 master branch이름으로 적어주자. spring cloud의 기본값은 master인데 git의 기본값은 main이어서 맞추지 않으면 오류가 난다.

 

이제 config server에서 설정정보를 가져올 클라이언트 서버를 생성하고 위와 같은 내용을 application.yml에 추가하자.

 

간단한 테스트를 통해 config-server에서 제대로 설정정보를 가져왔는지 체크해보자

클라이언트 서버의 설정파일에는 message라는 값이 없고 설정정보서버의 파일에만 message를 넣었다. 클라이언트가서버가 config서버에서 설정정보를 가져왔다면 get요청에 대해 입력한 값을 리턴할 것이다.

 

 

성공적으로 외부에서 설정정보를 가져온 걸 확인할 수 있다!

 

 

 

동적으로 설정정보 변경하기

이제 외부에서 설정파일을 관리할 수 있게 되었다. 다만, 설정정보가 실시간으로 변경되면 어떡할까? 첫번째 방법은 클라이언트 서버를 다시 띄우는 것이다. 재빌드를 할 필요는 없지만 비효율적이다. 두번째 방법으로 actuator를 이용해 refresh를 이용하는 방법이다. 이 방법은 서버를 다시 다시 띄울 필요가 없고 클라이언트서버에서 설정서버로 post요청 한번이면 설정정보가 업데이트 되어 첫번째 방법보다 나은 방법이다. 진행해보자.

config server에 의존하는 클라이언트 서버에 위와 같이 actuator의존성 및 설정정보를 추가한다. 이로써 actuator의 refresh를 사용할 수 있게 되었다. 이후 두 서버를 띄운 뒤 config서버의 설정정보를 변경하고 client-server/actuator/refresh를 호출해보자

 

서버를 띄운 상태에서 재부팅을 하지 않더라도 잘 변경된 걸 확인할 수 있다! 자세한 동작 프로세스는 추후 업로드하도록 한다.

 

 

이제 모든 걸 만족하는 동적 설정정보 서버를 만든 듯하지만 아직은 불편하다. 변경은 config server에서 일어났는데 갱신은 client server에서 직접 해줘야한다. config server에 의존한 client server가 많아질수록 이러한 수동작업은 번거롭다. message queue를 이용해 config서버를 구독해 변경된 내용을 자동으로 갱신하도록 만들어보자.

 

message queue 미들웨어로 rabbitMQ를 사용한다. 다만, 설치에 관해서는 생략하고 바로 사용하는 단계로 넘어간다.

브라우저에 localhost:15672를 요청했을 때 올바르게 rabbitMQ GUI가 나온 상태부터 시작한다.

이번엔 클라이언트 서버와 config서버 모두에 의존성 추가 및 설정정보를 추가해준다. 그리고 actuator의 busrefresh를 활성화 시킨 뒤 아까와 똑같은 작업을 한다면 rabbitMQ에 구독한 서버 모두에 설정정보 변경이 반영된 모습을 확인할 수 있다. post localhost:8888/actuator/busrefresh

 

 

마치며

자세한 동작과정을 공부한 게 아닌 hello, world 수준으로 사용해본 거라 설명이 매우 빈약하다. 우선 카프카까지 학습하고 카프카와 rabbitMQ의 차이점 위주로 깊게 공부해야겠다. actuator는 아직 잘 모르겠다. 나중에 공부해야겠다라는 생각이 들면 하도록하자. 갈길이 멀다.

 

아 그리고 진짜 월클 서버는 설정서버마저도 레플리카가 있다고 한다. 사실 생각지도 못했다. 어쨌든 월클을 다루기 위해 월클의 사고방식을 이해하도록 노력하자^^