Service Mesh인 Istio에서 작년에 공개한 ambient service mesh의 변경사항을 업데이트한 글입니다. 이전에는 Service Mesh가 굳이 필요한가라고 생각했는데 현재 회사에서 Istio를 쓰면서 Service Mesh를 지지하는 쪽으로 바뀌었습니다. 기술 도입은 당연히 서비스 규모와 성격에 따라 다르겠지만 마이크로 서비스의 규모가 어느정도 커진다면 Service Mesh가 있다면 트래픽 관리는 개별 애플리케이션이 아니라 인프라 수준에서 관리하고 개선할 수 있다는 점에서 상당한 장점이 있다고 생각합니다. 다만 Istio는 Istio 프록시를 사이드카로 띄우기 때문에 모든 팟에 Istio 프록시가 있어야 하므로 필요한 자원도 꽤 커지는 문제가 있습니다. 이게 규모가 커지면서 더욱 프록시에 필요한 자원도 커지게 마련인데 eBPF도 등장하고 cillium 등이 나오면서 사이드카 없이 Service Mesh를 하는 기술들도 등장하기 시작했고 Istio도 이에 맞추어서 작년 Ambient Service Mesh 기능을 도입했습니다. 이는 설명한대로 각 팟에 사이트카가 있는게 아니라 노드에 ztunnel을 설치하고 이를 통해서 Service Mesh를 지원합니다. 팟마다 사이드카가 있는게 아니라 노드마다 있으므로 자원 면에서 더 효율적이라고 할 수 있고 ztunnel은 HTTP 트래픽 종료나 헤더 파싱은 하지 않고 mTLS, 인증, L4 인가, 텔레메트리 등의 기능을 담당하고 있습니다. Istio가 Envoy를 쓰기 때문에 처음엔 Envoy로 구현했지만 ztunnel에 필요한 요구사항에 Envoy는 적합하지 않다고 판단해서 Istiod와 통신할 수 있는 구성 프로토콜을 Rust 구현해서 해결했다고 합니다. Istio가 Go를 쓰고 있어서 Go로 하려고 Go로 하려고 했으나 둘을 비교해 본 결과 Rust가 더 적합하다고 판단했다고 합니다.