Chpater12. 구성 중앙화

[minkukjo]

느낀 점

• Spring Cloud Configuration Server의 존재로 인해 구성파일들을 각각의 서비스가 관리하지 않아도 된다는 장점은 분명 좋아보였다.
• 그러나 결과적으로 구성 서버라는 서버를 별도로 개발/유지보수 해야하는데 이게 과연 좋을까? 라는 생각이 들었음.
• 물론 반드시 운영중에 설정값이 바뀌어야하고 그것이 즉각적으로 반영되어야하는 서비스라고 한다면 의미가 있을 것 같음.
• 결국 설정서버 유지보수 비용 VS 운영 중 재배포 없이 설정 변경 가능의 가치 중 어느것에 더 무게를 둘지에 따라 다를 것 같음.
• 그리고 공부하면서 Spring Cloud Vault라는 것도 발견했는데, 회사에 동기가 이걸로 볼트 설정값을 가져오는 것을 본 적 있음. 이걸 쓰면 확실히 더 편리할 것 같아보이긴 함. (물론 런타임 설정 변경은 안됨)
• 토이프로젝트에서 요거는 한 번 적용해봐도 괜찮겠다? 싶은 기능이긴 했음.

[LOG-INFO]

느낀점

• 아.. 역시나 Kubernetes의 ConfigMap, Secret 쓰면 되지 않나라는 생각이 읽는 내내 강하게 들었다.
  • 그리고 뒤쪽 챕터들에서.. 스포를 봐버렸다....
  • 근데 민국님 말씀대로 진짜 꼭 런타임상황에서 설정값이 바뀌어야한다면 Configmap/Secret보다는 나을 듯
  • 근데 그래야하는 경우가 있나....?
• 근데 /encrypt, /decrypt까지 지원해주는거 보면 꽤나 신경써서 만든 것 같다. (당연한건가?)
• 구성서버가 정상적이지 않으면 다른 마이크로 서비스들은 최대 20회까지 재시도를 하느라 시작을 못하게 된다는 단점이 있는 것 같다
• 암호화 하려면 직접 암호화 요청 보내서 알아낸 다음 다시 구성파일에 써줘야하는 것 같음

[MinJunKweon]

느낀점

• 구성정보를 한군데에 몰아넣고 관리하는 방식은 매우 합리적인듯
• 그 중에서 런타임에 설정을 바꿀 수 있다는 점이 가장 큰 장점인 것 같은데, 아직까진 필요한 상황을 못본거같고 그런 상황이 상상이 잘 안됨
• 그리고 구성서버 API로 암/복호화를 지원하는 게 좋은 것인가 의문
  • 어짜피 구성서버에서 내려주는 데이터를 복호화할거면 처음부터 복호화해서 주면 안되나?
  • 마찬가지로 암호화 해야하는 정보가 있으면 구성서버 API에 쏠 때 암호화할 정보라는 것만 표기하는 방식으로 쓰면 훨씬 좋지 않았을까 싶음..