Chapter 8,9 스프링 클라우드 소개, 넷플릭스 유레카

[minkukjo]

느낀점

• 스프링 클라우드 게이트웨이를 사용해본 적은 없는데, OAuth와 URL 기반 라우팅 등 일반적인 MSA에서의 게이트웨이 역할을 해주는 것 같아서 혹시나 이 책에서 등장한다면 예제로 한 번 만들어보고 싶다는 생각이 들었다.
• 최근에 든 생각은 MSA의 디자인 패턴을 직접 OSS를 사용해서 구현하는 것도 좋지만, Istio를 사용해서 서비스 메쉬를 구현하는 편이 더 낫지 않나? 라는 생각도 종종 든다.
• 물론 그럴러면 클라우드 엔지니어(라고 쓰고 잡부 백엔드 엔지니어라고 읽는다)가 있어야해서 힘든 일이지만... 결국 우리가 나아가야하는 방향은 인프라 레이어에서 이러한 MSA를 위한 기능들을 구현하는게 더 좋지않나 싶은 생각은 든다. (Istio에선 대부분 MSA 디자인 패턴을 제공한다.)
• Resilience4j, 스프링 클라우드 슬루스, 집킨 등과 같이 앞으로 사용할 기술 스택 전반에 대해서 공부하기 위한 소개 정도를 하고 있음.
• 9장의 서비스 검색에서 DNS에 대응되는 IP 주소가 여러 개인 경우 첫 번째 IP 주소를 계속 사용한다는 사실이 놀라웠다. (유레카!)
• 근데 막상 서비스 검색 기능은 k8s의 ingress + service 조합으로 해결할 수 있을 것 같은데, 굳이 이걸 쓰는 이유에 대해서 공감하기 어려웠다. ( 내가 너무 k8s 빠돌이 같다고 생각할 수도 있겠지만 사실이다. k8s 최고 )
• 특히나 유레카 서버가 장애가 생기는 것은 너무나 치명적이라 유지보수 비용이 추가로 드는 점도 별로인 것 같다.

의문점

• OSS가 뭐지 하고 찾아봤더니 오픈 소스 소프트웨어의 줄임말이라고 한다. 그냥 오픈소스라고 하면 안되냐...?
• 상관 ID가 뭐지..? 했더니 Relation ID 정도로 해석이 되는 것 같다. 아마 MSA 환경에서 유저 한명의 요청에 대한 Request ID를 의미하는 걸로 이해했음.

[MinJunKweon]

느낀점

• 스프링 클라우드 컨피그가 Git Repo도 저장소로 지원해주는 것이 놀랐음. Git을 사용하는 환경이라면 (요즘은 아닌 환경 찾는게 더 힘들정도) 관리하기 쉬워서 매력적으로 느껴짐
• 평소에 DNS를 사용하지 않고 서비스 검색 사용하는 이유에 의문이 좀 있었음. 단순하게 생각했을 때 가졌던 의문들.
  • 클라이언트의 DNS 캐시 : 서비스 검색을 쓰면 어짜피 클라이언트 캐시가 안되는 것은 동일한 문제 아닌가?
  • 동적으로 변하는 서비스 IP : IP가 초 단위로는 변경되지 않을꺼고, DNS 서버도 사설서버 쓸텐데 변경될때 DNS 서버만 업데이트 잘하면 되는것 아닌가?
• 하지만, 이번에 9장 읽으면서 알게됨
  • 로드밸런싱이 세밀하지 않음 : DNS LB는 정보가 한정적이라서 라운드로빈 같이 좀 단순한 LB만 가능한듯
  • DNS 서버가 헬스체크도 해야함 : 이것까지 하면 DNS 서버로서의 역할을 넘어서는듯.. 서비스 검색 서버 따로 두는게 옳게된 것 같음. (납득)
• 민국님 말씀대로 Kubernetes 환경이라면 Service와 Ingress 리소스를 활용하는 것이 더 좋아보임
  • 반대로 말하면, k8s 안쓰는 환경에서도 서비스 검색이 가능하다는 게 장점이 될 수 있는듯