실무자를 위한 서비스 메시 - 이스티오가 해답인가

이스티오가 해답인가

이상에서 언급한 여러 제약 사항에도 불구하고, 서비스 메시의 기능이 다양한 측면에서 필요하다고 판단하는 경우, 서비스 메시를 도입할 수 있습니다. 그렇다면 다음 단계로, 서비스 메시 환경을 구축하기 위한 여러 가지 대안들 중에 어떤 도구를 사용할 것인지 면밀히 분석해 볼 필요가 있습니다. 먼저, 서비스 메시를 전파하는 데 일등 공신을 한 이스티오를 살펴보겠습니다.

이스티오 해부

이스티오는 사이드카 프록시로서 엔보이를 사용합니다. 엔보이는 유연하고 범용적인 프록시입니다. 이러한 범용성 때문에, 많은 서비스 메시 솔루션에서 사이트카 프록시로 채택하였습니다. 엔보이를 인그레스, 이그레스, 서비스 메시 사이드카 등 다양한 방법으로 사용할 수 있습니다. 그러나 이러한 유연성 이면에는, 복잡성이 따릅니다. 엔보이는 많은 기능을 수행하기 위해, 복잡한 코드들이 많습니다. 링커디(Linkerd) 프로젝트에서 사용하는 마이크로 프록시인 Linkerd2-proxy의 코드 길이는 엔보이보다 5배 작고 복잡도는 엔보이보다 10배 적습니다.

모든 사이드카 기반 서비스 메시에서 한 가지 분명한 사실은 서비스가 늘어날수록 많은 프록시를 갖게 된다는 것입니다. 데이터 플레인에서 사용하는 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

사용률에 있어서는 아시아를 제외한, 유럽과 북미 지역은 링커디가 이스티오보다 높습니다. 성장률에 있어서는 링커디가 모든 지역에서 우세합니다.

서비스 메시 프로젝트 사용률

• Linkerd - 73%
• Istio - 34%
• Traefik - 11%
• Consul(in service mesh mode) - 7%
• AWS App Mesh - 6%
• Open Service Mesh - 6%
• Other - 5%
• None of the above - 3%

이미지 출처 : https://www.cncf.io/blog/2022/05/17/service-meshes-are-on-the-rise-but-greater-understanding-and-experience-are-required

이러한 차이 때문인지, CNCF 조사 결과는 73%의 사용자가 링커디를 채택하였거나, 앞으로 채택할 예정이라고 말해주고 있습니다. 그렇다면 다음 질문으로, 이스티오에서 제공하는 많은 기능들을 링커디를 포함한 다른 서비스 메시 솔루션에서도 제공하는가를 확인해 볼 필요가 있습니다.

서비스 메시 솔루션 비교

CNCF 프로젝트 중 서비스 메시 솔루션은 링커디, 이스티오, 쿠마(Kuma)가 있습니다. 그 외, Public Cloud CSP에서는 AWS App Mesh가 있고, Google Cloud에서는 이스티오를 사용하고 있습니다. 또한, Samsung Cloud Platform에서도 Kubernetes Apps를 이용하여 이스티오 커뮤니터 버전을 제공하고 있습니다.
※ Azure Service Fabric Mesh는 사용 중단되었습니다.(Deprecated)

인프라 측면

  • 이스티오와 쿠마는 쿠버네티스 환경뿐만 아니라, VM 메시 환경도 제공합니다.
  • 링커디는 엔보이가 아닌 자체 경량 프록시를 사용하는 것이 특징입니다.
  • 노드 에이전트 방식은 최근에 이스티오가 ambient mesh라는 이름의 노드 에이전트를 추가하여 프리뷰(preview)로 제공합니다.
  • 링커디와 쿠마는 3rd party 인그레스 컨트롤러를 지원합니다. 반면에 이스티오는 외부 인그레스 컨트롤러를 지원하지 않습니다.

트래픽 관리 측면

링커디는 서킷 브레이커 기능을 지원하지 않습니다. 트래픽 관리 기능은 이스티오가 타 서비스 메시 솔루션과 비교하여 가장 많은 기능을 제공합니다.

동향: 사이드카 없는 서비스 메시 출시

이스티오는 최근 새로운 데이터 플레인 모드인 엠비언트 메시라는 기능을 출시했습니다. 기존에 엔보이를 사용하지 않고, ztunnel이라는 노드 에이전트를 구성하는 방식입니다.

사이트카 방식

• c1(sidecar proxy) -(mTLS upgrade) s1(sidecar proxy)
• c2(sidecar proxy) -(mTLS upgrade) s2(sidecar proxy)
• c3(sidecar proxy)

노드 에이전트 방식

• c1 / c2
• ztunnel -(http connect tunnel)

• s1 /s2 /c3
• - ztunnel

이미지 출처 : https://istio.io/latest/blog/2022/introducing-ambient-mesh

기존 사이드카 방식의 한계

기존 사이드카 방식은, 사이드카를 설치하거나 업그레이드하려면 애플리케이션 파드를 다시 시작해야 하며 이는 워크로드에 지장을 줄 수 있습니다. 또한, 사이드카 프록시는 각 워크로드 전용이므로 CPU 및 메모리 리소스는 각 개별 파드의 최악의 사용에 대비하여 프로비저닝되어야 합니다. 이로 인해 클러스터 전체에서 리소스 활용률이 저하될 수 있고, 워크로드의 고정비용이 항상 발생합니다.

노드 에이전트 방식

엠비언트 메시는 쿠버네티스 클러스터의 각 노드에서 실행되는 공유 에이전트를 사용합니다.

• client(sleep) -⁢
• ztunnel -(mTLS)

• ---(xDS config) Istio ---

• productpage -⁢
• ⁢- ztunnel

• -⁢(secure overlay layer) reviews

이미지 출처 : https://istio.io/latest/blog/2022/introducing-ambient-mesh

이 에이전트는 제로 트러스트 터널(ztunnel)이라고 불리며, 메시 내의 워크로드들을 인증 기반으로 연결해줄 수 있도록 제로 트러스트를 활성화합니다. 이때, 워크로드 트래픽에 대해 L7 처리를 수행하지 않으므로 사이드카보다 훨씬 간편하여, 복잡성 및 관련 리소스 비용이 크게 감소합니다. 이후, L7 기능을 활용하기 위해서는, 네임스페이스의 워크로드에 대한 L7 처리를 처리를 관장하는 엔보이 기반의 웨이포인트 프록시(waypoint proxy)를 배치할 수 있습니다.

마무리

최근, 이스티오 프로젝트는 CNCF에 가입하여 인큐베이팅 프로젝트가 되었습니다. 그 배경에는 이스티오에 많은 시간을 투자한 구글이 기존의 이스티오 상표권을 포기하고, Linux Foundation에 기증한 것이 있었습니다. 기존에도 OUC(Open Usage Commons)에 속한 오픈소스였으나, CNCF에 가입하게 되면서 장기적으로 개방형 오픈소스를 통해 발전해 나갈 것이라고 생각합니다. 저희는 대표적으로 쿠버네티스 프로젝트를 통해 프로젝트가 성숙해 나가는 과정을 목격했습니다.

많은 기업들이 서비스 메시를 엔터프라이즈 시장의 중요한 진입점으로 보고 있습니다. 컨테이너 기술의 발전으로 서비스의 크기는 작아지고, 개수는 점점 늘어나기에 서비스 메시가 필요한 상황이 다가오고 있습니다. 서비스 메시를 이미 운영을 하고 있다면, 다양한 채널(slack 포함)을 통해, 오픈소스 기술에 대한 이슈를 계속 체크하는 것이 중요합니다. 도입을 검토하고 있다면, 위 3번의 질문을 통해 내가 처한 애플리케이션 환경의 어떠한 문제를 해결하기 위한 도구로 활용할 것인지 먼저 파악하는 것이 중요합니다.

마지막으로 서비스 메시는 어렵습니다. 다양한 서비스 메시 도구 간 기능의 차이를 경험해보는 것을 추천합니다. Samsung Cloud Platform의 Kubernetes Apps에서 제공하는 이스티오 커뮤니티 버전을 활용하여, 연습해보시는 것을 추천합니다.



References
[1] https://www.cncf.io/blog/2020/10/26/service-mesh-is-still-hard/
[2] https://www.cncf.io/blog/2021/12/17/benchmarking-linkerd-and-istio-2021-redux/
[3] https://www.cncf.io/blog/2022/05/17/service-meshes-are-on-the-rise-but-greater-understanding-and-experience-are-required/
[4] https://linkerd.io/2021/04/01/introduction-to-the-service-mesh/
[5] https://istio.io/latest/blog/2022/get-started-ambient/
[6] https://istio.io/latest/blog/2022/introducing-ambient-mesh/
[7] https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/
[8] https://buoyant.io/service-mesh-manifesto
[9] https://medium.com/containers-101/fully-automated-canary-deployments-in-kubernetes-70a671105273
[10] https://blog.aquasec.com/istio-kubernetes-security-zero-trust-networking
[11] https://medium.com/jaegertracing/jaeger-tracing-a-friendly-guide-for-beginners-7b53a4a568ca
[12] https://www.waytoeasylearn.com/learn/istio-circuit-breaker/
[13] https://thenewstack.io/istio-applies-to-join-cncf-why-now/
[14] https://karlstoney.com/2019/05/31/istio-503s-ucs-and-tcp-fun-times



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.