클라우드명제상이스티오가 해답인가이상에서 언급한 여러 제약 사항에도 불구하고 , 서비스 메시의 기능이 다양한 측면에서 필요하다고 판단하는 경우, 서비스 메시를 도입할 수 있습니다. 그렇다면 다음 단계로, 서비스 메시 환경을 구축하기 위한 여러 가지 대안들 중에 어떤 도구를 사용할 것인지 면밀히 분석해 볼 필요가 있습니다. 먼저, 서비스 메시를 전파하는 데 일등 공신을 한 이스티오를 살펴보겠습니다.이스티오 해부이스티오는 사이드카 프록시로서 엔보이를 사용합니다. 엔보이는 유연하고 범용적인 프록시입니다. 이러한 범용성 때문에, 많은 서비스 메시 솔루션에서 사이트카 프록시로 채택하였습니다. 엔보이를 인그레스, 이그레스, 서비스 메시 사이드카 등 다양한 방법으로 사용할 수 있습니다. 그러나 이러한 유연성 이면에는, 복잡성이 따릅니다. 엔보이는 많은 기능을 수행하기 위해, 복잡한 코드들이 많습니다. 링커디(Linkerd) 프로젝트에서 사용하는 마이크로 프록시인 Linkerd2-proxy의 코드 길이는 엔보이보다 5배 작고 복잡도는 엔보이보다 10배 적습니다.사이드카 프록시 비교항목 엔보이 (Envoy) Linkerd2-proxy 구현 언어 C++ Rust 코드 길이 172 KLOC 30 KLOC 복잡성 점수(분기 및 루프 개수 측정) 19 k 1.5k cpu/mem 리소스 소비(4000RPS 기준) 156ms / 135mb 15ms / 14mb모든 사이드카 기반 서비스 메시에서 한 가지 분명한 사실은 서비스가 늘어날수록 많은 프록시를 갖게 된다는 것입니다. 데이터 플레인에서 사용하는 CPU 및 메모리는 특히 애플리케이션이 확장될 때 서비스 메시 실행 비용의 중요한 구성 요소입니다. 보안 측면에서 엔보이는 C++로 작성됐으며, 보안 취약점 개선을 위해 많은 비용을 들이고 있습니다. C++ 언어 자체가 버퍼 오버플로우에 취약한 언어이기 때문입니다. 반면에, Linkerd2-proxy의 구현을 위해 사용된 언어 Rust는 메모리 안전성이 특징입니다. Linkerd2-proxy가 보안 취약점은 더 적을 것으로 예상할 수 있습니다.리소스 사용률 비교실제 리소스 사용 면에서도, 링커디(Linkerd)가 이스티오보다 훨씬 자원 소모가 덜합니다.이미지 출처 : https://www.cncf.io/blog/2021/12/17/benchmarking-linkerd-and-istio-2021-redux위 이미지에서 알 수 있듯이, 이스티오의 CPU/Memory 사용률이 링커디보다 현저히 높고 편차도 큽니다. 네트워크 지연도 이스티오에서 더 많이 발생합니다.서비스 메시 사용률 및 성장률 비교이하는 운영 환경에서 채택 중 또는 채택을 예정으로 하는 서비스 메시의 사용률 및 성장률에 대한 차트입니다.이미지 출처 : https://www.cncf.io/blog/2022/03/04/linkerd-surpasses-istio-adoption-in-europe-and-north-america-with-118-growth-in-2021사용률에 있어서는 아시아를 제외한, 유럽과 북미