Rendimiento de Service Mesh: Un Análisis Profundo
Analizamos el impacto de mTLS en el rendimiento de la malla de servicios.
― 6 minilectura
Tabla de contenidos
En el mundo actual que ama la nube, muchas aplicaciones se construyen usando microservicios. Imagina un gran festival donde cada carpa tiene su propio tema. Para que todo funcione sin problemas, necesitamos un guardia de seguridad amigable pero firme entre estas carpas. ¡Eso es lo que hace una malla de servicios! Ayuda a los microservicios a hablar entre ellos, mantiene todo seguro y maneja tareas de red complejas, mientras deja a los desarrolladores concentrarse en sus proyectos divertidos.
Pero, así como agregar una capa extra de glaseado a un pastel puede hacerlo lucir bonito pero también un poco pesado, usar una malla de servicios puede ralentizar las cosas. Así que decidimos echar un buen vistazo a cómo el protocolo MTLS-nuestro guardia de seguridad-afecta el rendimiento al usar diferentes mallas de servicios como Istio, Linkerd y Cilium.
¿Qué es mTLS?
Antes de meternos en los detalles, primero entendamos qué es mTLS. Piensa en ello como un apretón de manos elegante. En un apretón de manos TLS normal, solo el servidor muestra su ID-como un portero revisando identificaciones en la puerta. En mTLS, tanto el cliente como el servidor muestran sus IDs. De esta manera, todos saben quién es quién, y pueden intercambiar información sin preocuparse por invitados no deseados.
¿Por qué usar una malla de servicios?
A medida que más empresas se suben al carro de los microservicios, las mallas de servicios se han vuelto más populares. Ayudan a gestionar el tráfico entre servicios, mejoran la seguridad y facilitan mantener todo funcionando. Una encuesta de algunos técnicos reveló que alrededor del 70% de las organizaciones están usando mallas de servicios ya sea en producción o en pruebas.
Diferentes mallas de servicios pueden ofrecer diferentes ventajas, y es importante sopesar eso contra posibles lentitudes. Entonces, ¿cómo encontramos cuál malla de servicios es la mejor para nuestras necesidades? ¡Necesitamos hacer unas pruebas al viejo estilo!
Configurando las Pruebas
Para llevar a cabo nuestra investigación, creamos un entorno de prueba similar a una configuración nublada ocupada. Piensa en ello como un parque de diversiones simulado lleno de atracciones (microservicios) que necesitan trabajar juntos en armonía.
Usamos una herramienta llamada Fortio para simular el tráfico de la red, como una prueba de presión, para ver qué tan bien maneja cada malla de servicios las solicitudes. Monitoreamos todo de cerca, buscando signos de estrés como latencia (cuánto tardan las cosas) y uso de recursos (cuánto CPU y memoria se están usando).
Durante la prueba, comparamos cada malla de servicios contra una línea base-eso es solo un término elegante para ejecutar todo sin ninguna malla de servicios. Queríamos ver cómo se desempeñaban con mTLS habilitado y sin él.
¿Qué encontramos?
Sobrecarga de Rendimiento
Así como los ingredientes adicionales en una pizza pueden hacerla más pesada, agregar una malla de servicios puede introducir una sobrecarga de rendimiento. Nuestras pruebas mostraron que hacer cumplir mTLS con mallas de servicios llevó a un aumento de latencia en todos los casos.
Así es como se clasificaron en términos de aumento de latencia:
- Istio: Un impresionante 166% de aumento
- Istio Ambient: Solo un 8%
- Linkerd: Alrededor del 33%
- Cilium: Un aumento del 99%
¡Esos son números locos! ¡Parece que Istio tiene que dar algunas explicaciones!
Consumo de Recursos
Eso no es todo. También encontramos que el consumo de recursos se disparó en todos los casos. Con mTLS habilitado, el uso de CPU y memoria se disparó, pero no todas las mallas de servicios fueron creadas iguales. Istio parecía llevarse la parte del león (o la pizza) en el uso de recursos más alto, mientras que Istio Ambient fue el más eficiente.
Sidecar vs. Sin Sidecar
Para entender mejor las cosas, aquí hay un repaso rápido de dos tipos de arquitectura de malla de servicios que probamos: con sidecar y sin sidecar.
Patrón Sidecar: Imagínalo como agregar un camarero separado (el sidecar) para cada mesa (servicio). Este camarero se encarga de toda la comida (datos) que entra y sale. ¡Mientras funciona, puede ponerse bastante ocupado!
Modelo Sin Sidecar: Imagina si los camareros estuvieran todos reunidos en la cocina (el nodo), reduciendo el número de personas corriendo por ahí. ¡Eso es lo que hace el modelo sin sidecar! Al gestionar todo con un agente central, evita los saltos de red adicionales del enfoque con sidecar.
Hallazgos Clave
Istio: Alta latencia y sobrecarga de recursos. ¡Es como tener un mini ejército de camareros, pero se están tomando su tiempo!
Istio Ambient: ¡Mejor rendimiento! Es como una cocina bien organizada con camareros eficientes que no se pierden.
Linkerd: Un poco detrás de Istio Ambient, pero todavía haciéndolo bastante bien. Un sólido rendimiento, como un amigo confiable.
Cilium: Es como esa persona en tu grupo de amigos que es súper eficiente y nunca parece ralentizarse, pero un poco peculiar. Cilium no cifra el tráfico intra-nodo, lo que aceleró las cosas, pero puede levantar cejas.
Conclusión
Nuestras pruebas revelaron que, aunque las mallas de servicios ofrecen beneficios importantes, también traen compromisos de rendimiento, especialmente al usar mTLS. Entonces, ¿qué malla de servicios deberías elegir?
- Si quieres muchas funciones y estás bien con algo de lentitud, Istio podría ser tu elección.
- Si quieres eficiencia sin sacrificar demasiado, dale una oportunidad a Istio Ambient.
- Si necesitas algo confiable pero no demasiado llamativo, Linkerd te cubre.
- Y si buscas a un velocista, Cilium es tu mejor opción, solo ten en cuenta sus peculiaridades.
Al final del día, se trata de descubrir qué es lo que buscas. Elegir una malla de servicios es un poco como elegir una comida: debe satisfacer tu apetito mientras se ajusta a tu presupuesto y objetivos de salud. ¡Así que reúne a tu equipo, evalúa tus necesidades y selecciona la malla de servicios que sea perfecta para ti! ¡Feliz networking!
Título: Technical Report: Performance Comparison of Service Mesh Frameworks: the MTLS Test Case
Resumen: Service Mesh has become essential for modern cloud-native applications by abstracting communication between microservices and providing zero-trust security, observability, and advanced traffic control without requiring code changes. This allows developers to leverage new network capabilities and focus on application logic without managing network complexities. However, the additional layer can significantly impact system performance, latency, and resource consumption, posing challenges for cloud managers and operators. In this work, we investigate the impact of the mTLS protocol - a common security and authentication mechanism - on application performance within service meshes. Recognizing that security is a primary motivation for deploying a service mesh, we evaluated the performance overhead introduced by leading service meshes: Istio, Istio Ambient, Linkerd, and Cilium. Our experiments were conducted by testing their performance in service-to-service communications within a Kubernetes cluster. Our experiments reveal significant performance differences (in terms of latency and memory consumption) among the service meshes, rooting from the different architecture of the service mesh, sidecar versus sidecareless, and default extra features hidden in the mTLS implementation. Our results highlight the understanding of the service mesh architecture and its impact on performance.
Autores: Anat Bremler Barr, Ofek Lavi, Yaniv Naor, Sanjeev Rampal, Jhonatan Tavori
Última actualización: Nov 4, 2024
Idioma: English
Fuente URL: https://arxiv.org/abs/2411.02267
Fuente PDF: https://arxiv.org/pdf/2411.02267
Licencia: https://creativecommons.org/licenses/by/4.0/
Cambios: Este resumen se ha elaborado con la ayuda de AI y puede contener imprecisiones. Para obtener información precisa, consulte los documentos originales enlazados aquí.
Gracias a arxiv por el uso de su interoperabilidad de acceso abierto.