Kubernetes까지 도입하고나서, 도입을 고려해야 했던 것은 Istio이었다. 현재 Kubernetes 시스템에서 Service Mesh을 도입해야 했던 가장 큰 이유는 GRPC 로드 밸런싱을 Kubernetes만 가지고는 잘 안되기 때문. [1] [2]
그리고, 두번째 이유는 각 서비스의 연결이 각 서비스의 네트웍 프록시로 이루어지기 하게 때문에, 프록시 설정을 통해, 네트웍에 대한 공통적인 문제 해결 접근을 애플리케이션이 아닌, 인프라에서 일괄적으로 적용/관리해볼수가 있다. [3] [4]
가장 단순하게는, (나에게는) 이 두가지 이유가 도입할때 매력중 하나가 아닐까 생각된다.
나머지는 다 어렵다..
[1]: https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/
[2]: Kubernetes만 가지고는 Connection 기반 load balancing(L4)이 가능한데, GRPC는 Request based load balancing (L7)이 필요하다.
[3]: Retry and Timeout, Load Balancing, Circuit Breaking, ...
[4]: 특히, 서비스간의 커뮤니케이션에 프록시가 개입하므로, 네트웍 이슈에 대한 프록시가 리포팅인하여, 모니터링이 한결 쉬워진다. (단, istio경우, istio때문에 생성되는 엄청난 매트릭을 보게 됩..;ㅁ;)
댓글
의견을 남겨주세요