Spring Config 서버는 필요할까?
해당 질문에 대해서는 서비스가 어떻게 구축되었는가에 따라 정답이 다르겠지만
적어도 yml에서 관리되고 있는 property 가 동일한 값을 여러 프로젝트에서 사용하고 있다면 매우 필요하다고 느끼고 있다.
왜 필요한가?
예를 들어 여러 프로젝트에서 Slack 알림을 발송하고 있다고 가정해보자.
Slack 알람을 발송하기 위해선 webHook 이 필요할 것이다. 또한 채널명도 알고 있어야 된다.
간단하게 아래와 같은 그림이 될 것 같다.
만약 현재 상태에서 슬랙 채널의 이름이 변경된다고 가정해보자.
그러면 모든 프로젝트의 yml 파일에 가서 정보를 변경해야 한다 여기까지는 충분히 할 수 있다.
(만약 프로젝트가 많다면 해당 슬랙 채널로 발송하고 있는 프로젝트를 다 찾아야 한다.)
하지만 코드를 변경했지만 Slack 채널명은 변경하지 못한다.
왜냐하면 배포를 하지 않았기 때문에 슬랙 채널명은 배포 시점에 같이 변경해야 한다.
여기까지도 충분히 할 수 있다.
하지만 프로젝트, 프로젝트 2, 프로젝트 3 이 모두 배포되고 나서야 Slack 채널명을 변경할 수 있다.
단 하나라도 먼저 배포하거나 하나라도 빠진다면 이슈 알람은 받지 못할 것이다.
슬랙 채널명을 변경하기 위해 알람을 발송하고 있는 서비스를 재배포하는 것도 뭔가.. 아쉽다. 😭
만약 Config Server 가 있다면 편해질까?
그림과 같이 나는 yml 이 저장소에 저장되어있는 파일만 수정하여 해당 파일이 변경되었다는
이벤트만 config server로 발행하고 config server는 해당 서버를 구독하고 있는
프로젝트들에게 알림을 발송하여 새로운 yml 파일로 변경하라는 메시지만 발행해준다면
앞선 문제점인
- yml 파일을 3번 수정하거나
- 누락되어 수정되지 않은 프로젝트가 있거나
- 마지막으로 제일 행복한 재배포 과정을 3번이나 가지지 않아도 된다.
하지만 정말로 이대로 행복한 걸까?
아직 깊게 공부하지는 않았지만 Config Server 가 단일 장애점이 될 수도 있지 않을까?🙀 에 대한 생각은 아직도 남아있다.
결론
해당 본문은 Spring Cloud Config Server 만들어보기 전에 왜 구축해보고 싶었는지 도입 글?이라고 해야 할까요..
아직까지는 단점보다는 장점이 많아 보이긴 하지만 또 하다 보면 단점이 더 많을 수도 있겠죠!?
따라서 다음 글은 구축 과정과 Spring Cloud Config과 관련된 글을 작성하고자 합니다.
부족한 글 읽어주셔서
감사합니다!