issues
search
DevSprout
/
Hands-On-Microservices-with-Spring-Boot-and-Spring-Cloud
:rocket: 스프링으로 하는 마이크로서비스 구축 스터디
6
stars
2
forks
source link
Chpater12. 구성 중앙화
#9
Open
minkukjo
opened
2 years ago
minkukjo
commented
2 years ago
느낀 점
Spring Cloud Configuration Server의 존재로 인해 구성파일들을 각각의 서비스가 관리하지 않아도 된다는 장점은 분명 좋아보였다.
그러나 결과적으로 구성 서버라는 서버를 별도로 개발/유지보수 해야하는데 이게 과연 좋을까? 라는 생각이 들었음.
물론
반드시
운영중에 설정값이 바뀌어야하고 그것이 즉각적으로 반영되어야하는 서비스라고 한다면 의미가 있을 것 같음.
결국 설정서버 유지보수 비용 VS 운영 중 재배포 없이 설정 변경 가능의 가치 중 어느것에 더 무게를 둘지에 따라 다를 것 같음.
그리고 공부하면서
Spring Cloud Vault
라는 것도 발견했는데, 회사에 동기가 이걸로 볼트 설정값을 가져오는 것을 본 적 있음. 이걸 쓰면 확실히 더 편리할 것 같아보이긴 함. (물론 런타임 설정 변경은 안됨)
토이프로젝트에서 요거는 한 번 적용해봐도 괜찮겠다? 싶은 기능이긴 했음.
LOG-INFO
commented
2 years ago
느낀점
아.. 역시나 Kubernetes의 ConfigMap, Secret 쓰면 되지 않나라는 생각이 읽는 내내 강하게 들었다.
그리고 뒤쪽 챕터들에서.. 스포를 봐버렸다....
근데 민국님 말씀대로 진짜 꼭 런타임상황에서 설정값이 바뀌어야한다면 Configmap/Secret보다는 나을 듯
근데 그래야하는 경우가 있나....?
근데
/encrypt
,
/decrypt
까지 지원해주는거 보면 꽤나 신경써서 만든 것 같다. (당연한건가?)
구성서버가 정상적이지 않으면 다른 마이크로 서비스들은 최대 20회까지 재시도를 하느라 시작을 못하게 된다는 단점이 있는 것 같다
암호화 하려면 직접 암호화 요청 보내서 알아낸 다음 다시 구성파일에 써줘야하는 것 같음
MinJunKweon
commented
2 years ago
느낀점
구성정보를 한군데에 몰아넣고 관리하는 방식은 매우 합리적인듯
그 중에서 런타임에 설정을 바꿀 수 있다는 점이 가장 큰 장점인 것 같은데, 아직까진 필요한 상황을 못본거같고 그런 상황이 상상이 잘 안됨
그리고 구성서버 API로 암/복호화를 지원하는 게 좋은 것인가 의문
어짜피 구성서버에서 내려주는 데이터를 복호화할거면 처음부터 복호화해서 주면 안되나?
마찬가지로 암호화 해야하는 정보가 있으면 구성서버 API에 쏠 때 암호화할 정보라는 것만 표기하는 방식으로 쓰면 훨씬 좋지 않았을까 싶음..
느낀 점