Las IPUs mejoran la latencia de la red en aplicaciones basadas en microservicios

¿Qué son los microservicios?

Los microservicios se refieren a un enfoque moderno de desarrollo de software que implica dividir una aplicación grande en servicios más pequeños, independientes y poco acoplados. En lugar de implementar aplicaciones como sistemas de software monolíticos tradicionales, los proveedores de servicios en la nube, incluidas compañías conocidas como Amazon, eBay, Netflix y Twitter, están implementando cada vez más sus aplicaciones como microservicios en lugar de diseños monolíticos tradicionales.

Algunos beneficios de los microservicios incluyen:

• Escalabilidad: Los microservicios permiten una mejor escalabilidad, ya que los servicios individuales se pueden escalar independientemente unos de otros. Esto significa que los desarrolladores pueden escalar hacia arriba o hacia abajo solo los servicios que lo necesitan, sin afectar al resto de la aplicación.

• Flexibilidad: Los microservicios facilitan la realización de cambios en un sistema porque los servicios individuales se pueden actualizar sin afectar a toda la aplicación. Esto hace que sea más fácil adoptar nuevas tecnologías, experimentar con diferentes lenguajes de programación y probar nuevas características.

• Aislamiento de errores: dado que cada microservicio es un componente independiente, si se produce un error en un servicio, no afecta al resto de la aplicación. Esto significa que los desarrolladores pueden identificar y solucionar problemas rápidamente sin afectar a todo el sistema.

• Mayor velocidad de desarrollo: los microservicios permiten que equipos de desarrollo más pequeños y más centrados trabajen de forma independiente en servicios específicos. Esto acelera el proceso de desarrollo y facilita la administración de sistemas grandes y complejos.

• Mejor tolerancia a errores: con los microservicios, es más fácil crear sistemas tolerantes a fallas porque cada servicio se puede diseñar para controlar los errores de forma independiente. Esto significa que todo el sistema es más resistente y menos probable que falle.

• Pruebas mejoradas: dado que cada microservicio es independiente, es más fácil probar los servicios individuales. Esto significa que los desarrolladores pueden probar los servicios de forma aislada, lo que facilita la búsqueda y corrección de errores.

Si bien las arquitecturas de software basadas en microservicios ofrecen beneficios importantes, introducen importantes sobrecargas de red, de modo que parámetros como la latencia de la red tienen una gran influencia en el desempeño general de las aplicaciones y el costo del centro de datos. Al aprovechar las unidades de procesamiento de infraestructura (IPU) de Intel FPGA que ejecutan software de plano de datos virtualizado de Napatech, los proveedores de servicios pueden maximizar el desempeño de su infraestructura de red, lo que permite un nivel de desempeño que de otro modo sería imposible de alcanzar, al tiempo que minimiza el CAPEX y el OPEX general de su centro de datos.

Desafíos de redes para microservicios

En una arquitectura de microservicios, la latencia de la red presenta un desafío importante, ya que los servicios virtualizados implementados en contenedores o máquinas virtuales (VM) se comunican entre sí a través de una red virtualizada. Por ejemplo, los microservicios se comunican entre sí con frecuencia, lo que puede generar una gran cantidad de tráfico de red. Este aumento del tráfico de red puede provocar congestión y un aumento de la latencia, lo que puede afectar negativamente al rendimiento del sistema. Del mismo modo, en una arquitectura de microservicios, los servicios a menudo necesitan llamar a otros servicios para completar una tarea y cada llamada de red agrega latencia adicional al sistema. A medida que aumenta el número de servicios y la complejidad del sistema, también aumenta el número de llamadas de red, lo que puede generar importantes problemas de latencia. Finalmente, diferentes microservicios pueden usar diferentes protocolos de red para la comunicación. Por ejemplo, un servicio puede utilizar REST (transferencia de estado representación) mientras que otro servicio puede utilizar gRPC (llamada a procedimiento remoto de Google). La traducción entre protocolos de red diferentes puede agregar latencia adicional al sistema.

Tradicionalmente, un plano de datos virtualizado se implementa completamente en el software y muchos de sus ciclos de cómputo se consumen al ejecutar un conmutador virtual (vSwitch) que enruta el tráfico de red entre las máquinas virtuales. Dado que cada operación de vSwitch requiere una cantidad significativa de ciclos de CPU, esta arquitectura puede introducir una latencia inaceptable en el sistema y también puede impedir que el sistema alcance el rendimiento general requerido. Al mismo tiempo, una CPU muy utilizada para ejecutar el plano de datos virtual tendrá menos núcleos disponibles para ejecutar aplicaciones y servicios, lo que aumentará el número de servidores necesarios para admitir la carga de trabajo del centro de datos y aumentará tanto los gastos de capital como los gastos operativos. Consulte la Figura 1.

Aprovechamiento de la arquitectura basada en Intel® FPGA IPU

Una arquitectura de nivel de sistema más eficiente y rentable aprovecha una Intel FPGA IPU para descargar el vSwitch de la CPU del servidor, liberando la CPU del servidor para ejecutar aplicaciones y servicios.

La IPU, que reemplaza la tarjeta de interfaz de red (NIC) estándar en el servidor del centro de datos, implementa el vSwitch en el hardware mediante una FPGA programable (Field Programmable Gate Array) para ejecutar el plano de datos junto con una CPU de propósito general que ejecuta el plano de control. El vSwitch presenta una API (interfaz de programación de aplicaciones) estándar de la industria para las máquinas virtuales, lo que garantiza que no sea necesario realizar cambios en las propias máquinas virtuales cuando se aprovecha esta arquitectura. Ver Figura 2.

La arquitectura basada en IPU ofrece tres beneficios clave para un centro de datos que ejecuta aplicaciones basadas en microservicios:

• Latencia ultrabaja , que minimiza el tráfico de demora entre los microservicios;

• Alto rendimiento, que maximiza el rendimiento general del sistema y la aplicación;

• Uso óptimo de la CPU del servidor sin núcleos de CPU del servidor consumidos por el plano de datos de vSwitch, lo que minimiza el número total de servidores necesarios para la carga de trabajo general, minimizando también los gastos de capital y los gastos operativos del centro de datos.

Análisis MIT

Para cuantificar los beneficios de la descarga de vSwitch en escenarios del mundo real, el Instituto Tecnológico de Massachusetts (MIT) analizó el desempeño de dos casos de uso basados en microservicios y comparó los resultados del uso de un vSwitch tradicional basado en software con los obtenidos utilizando una Intel IPU ejecutando software de plano de datos virtualizado de Napatech, un proveedor líder de soluciones SmartNIC e IPU. Estos dos casos de uso fueron una aplicación "pub-sub" de publicación-suscripción que utiliza el paso de mensajes para transferencias de datos a través de múltiples niveles y una aplicación TCP de tres niveles que comprende un servidor web, caché en memoria y una base de datos back-end. Los resultados de esta iniciativa de análisis de referencia se documentan en el documento "Microservice Benchmarking on Intel IPUs running Napatech Software" publicado por el MIT.

Análisis de desempeño de aplicaciones Pub-Sub

Una aplicación pub-sub, abreviatura de "aplicación de publicación-suscripción", es un patrón de mensajería comúnmente utilizado en sistemas distribuidos para facilitar la comunicación y coordinación entre diferentes componentes o servicios. El patrón pub-sub permite una comunicación asíncrona y desacoplada, donde los remitentes de mensajes, conocidos como editores, no necesitan conocer a los destinatarios específicos, conocidos como suscriptores. Las aplicaciones pub-sub son aplicables a casos de uso como:

• Sistemas de reserva de asientos que crean un plano de planta, le asignan asientos y luego administran los eventos de reserva de asientos en vivo. A medida que los clientes compran boletos, el sistema pub-sub actualiza el plano de planta en todas partes en tiempo real y mantiene sincronizado el sistema de caché distribuido. Los clientes nunca terminan solicitando un asiento solo para descubrir que alguien lo había comprado mientras aún estaban en la fase de navegación / compra.

• Herramientas educativas que permiten a los estudiantes participar en un aula a través de una aplicación basada en la web, donde los clientes a menudo encuentran problemas como WiFi poco confiable o redes celulares impredecibles. El sistema pub-sub recupera su conexión cuando se reincorporan a la red y es capaz de manejar cambios rápidos en el número de participantes en línea.

• Aplicaciones financieras , como la distribución de datos de mercado, incluidos los precios de las acciones, los índices de mercado, los datos comerciales y las actualizaciones de la cartera de pedidos, a los suscriptores dentro de una organización.

• Sistemas de Internet de las cosas (IoT),donde pub-sub facilita la comunicación entre numerosos dispositivos IoT y permite la difusión eficiente de datos. Los sensores publican datos, luego los suscriptores pueden recibir y procesar esos datos en tiempo real.

Para este análisis, el MIT evaluó una topología de cadena de cinco niveles desarrollada con un modelo de comunicación pub-sub de Dapr, que es un tiempo de ejecución portátil y basado en eventos que permite a los desarrolladores crear aplicaciones resistentes, sin estado y con estado que se ejecutan tanto en la nube como en el perímetro, al tiempo que admiten una diversidad de lenguajes y marcos de desarrolladores. Cada nivel realiza un cómputo intensivo de CPU durante un período de tiempo especificado por el usuario, antes de transmitir su salida al nivel descendente. Ver Figura 3.

Dentro de la aplicación pub-sub de cinco niveles, la ubicación de servicios en los dos servidores habilitados para OVS garantiza que los servicios dependientes se ejecuten en máquinas físicas diferentes, de modo que todo el tráfico entre niveles pase a través de las IPU, cuando esté habilitado.

El MIT analizó el rendimiento del subsistema pub-sub con y sin la descarga basada en IPU, midiendo la latencia de la mensajería a través de cargas variables que se expresan como miles de consultas por segundo (kQPS). Consulte la Figura 4.

Cuando la descarga está deshabilitada y considerando la latencia de cola (es decir, en el peor de los casos), la aplicación comienza a saturarse a 90 kQPS, como lo indica el punto de inflexión en el gráfico. Más allá de ese nivel de carga, el sistema ya no puede mantenerse al día con las solicitudes de manera eficiente, probablemente debido a las caídas de paquetes que resultan en retransmisiones TCP. Sin embargo, cuando se habilita la descarga, el sistema sigue cumpliendo con las solicitudes a una carga de 140 kQPS, la velocidad máxima utilizada en esta prueba, lo que indica que la IPU permite un aumento del 50 % en el rendimiento mientras mantiene una latencia de cola aceptable. Esto representa una mejora significativa en la capacidad del sistema, lo que resulta en ahorros del 30-40% tanto en el costo total del servidor como en el consumo de energía.

Análisis de desempeño de aplicaciones TCP de tres niveles

Una aplicación TCP (Protocolo de control de transmisión) de tres niveles se refiere a un diseño de arquitectura de software que divide una aplicación en tres capas o niveles lógicos, cada uno responsable de funciones específicas. Estos niveles suelen denominarse nivel de presentación, nivel de aplicación y nivel de datos. El protocolo TCP se utiliza en la comunicación entre estos niveles:

• Nivel de presentación: también conocido como nivel de interfaz de usuario (UI), esta capa es responsable de presentar la información de la aplicación a los usuarios y recibir sus entradas. Se ocupa de componentes de interfaz gráfica de usuario (GUI), como páginas web, formularios o interfaces de escritorio. El nivel de presentación se comunica con el nivel de aplicación para recuperar o actualizar datos según sea necesario.

• Nivel de aplicación: el nivel de aplicación contiene la lógica empresarial y la lógica de procesamiento de la aplicación. Maneja la funcionalidad principal y realiza tareas como la validación de datos, la aplicación de reglas de negocio y las operaciones específicas de la aplicación. Este nivel procesa las solicitudes del nivel de presentación y se comunica con el nivel de datos para recuperar o almacenar datos.

• Nivel de datos: el nivel de datos, también conocido como capa de acceso a datos o nivel de base de datos, es responsable de administrar el almacenamiento y la recuperación de datos. Maneja las interacciones con los sistemas de bases de datos, como la consulta y actualización de datos. El nivel de datos recibe solicitudes del nivel de aplicación y devuelve los datos solicitados o realiza las modificaciones de datos necesarias.

En una aplicación TCP de tres niveles, la comunicación entre estos niveles se facilita mediante el protocolo TCP. TCP garantiza la entrega confiable y ordenada de datos entre los niveles, proporcionando un mecanismo de comunicación orientado a la conexión y basado en flujo. Al separar la aplicación en estos tres niveles, la arquitectura TCP de tres niveles permite modularidad, escalabilidad y un mantenimiento más sencillo de la aplicación. Cada nivel se puede desarrollar y escalar de forma independiente, lo que facilita la flexibilidad y la reutilización de los componentes.

Para este análisis, el MIT evaluó una aplicación de tres niveles con NGINX como servidor web front-end, Memcached como nivel de caché en memoria y MongoDB como base de datos back-end con almacenamiento persistente. Los clientes interactúan con NGINX, que comprueba si un par clave-valor está almacenado en caché en Memcached y, de ser así, devuelve el valor al cliente. De lo contrario, NGINX interactúa con MongoDB para obtener la salida y, además, almacenarla en caché en Memcached. Ver Figura 5.

El MIT analizó el rendimiento de la aplicación TCP de tres niveles con y sin la descarga basada en IPU, midiendo la latencia de la mensajería en cargas variables que, como en el ejemplo anterior, se expresan como miles de consultas por segundo (kQPS). Ver Figura 6.

Cuando la descarga está deshabilitada y considerando la latencia de cola (es decir, en el peor de los casos), la aplicación comienza a saturarse a aproximadamente 17 kQPS, como lo indica el punto de inflexión en el gráfico. Más allá de ese nivel de carga, el sistema ya no puede mantenerse al día con las solicitudes de manera eficiente, probablemente debido a las caídas de paquetes que resultan en retransmisiones TCP. Sin embargo, cuando la descarga está habilitada, la saturación no comienza hasta una carga de 26 kQPS, lo que indica que la IPU permite un aumento del 53 % en el rendimiento mientras mantiene una latencia de cola aceptable. Al igual que en el ejemplo anterior, esto representa una mejora significativa en la capacidad del sistema, lo que resulta en ahorros del 30-40% tanto en el costo total del servidor como en el consumo de energía.

Configuración del sistema

La configuración del sistema utilizada por el MIT para la evaluación comparativa de microservicios fue la siguiente:

• Dos servidores Inspur de doble zócalo, cada uno con un procesador Intel® Xeon® Gold 6338 con caché de 48 MB, funcionando a 2,0 GHz con velocidad turbo de 3,2 GHz. Cada servidor se configuró con una memoria de 512 GB, una unidad de arranque de 480 GB, módulos de almacenamiento NVMe P6410 duales de 1,6 TB y una NIC XL710 de controladora de Ethernet Intel® de 10 G.

• Además de la NIC estándar, cada servidor se configuró con un adaptador Intel IPU C5000X con puertos dobles SFP28 10/25G y una interfaz de host PCIe 3.0, basada en un FPGA Intel® Stratix® y Intel® Xeon® sistema en chip (SoC) D. Ver Figura 7.

• Cada IPU ejecutaba el software Link-Virtualization 4.3.3 de Napatech, que proporcionaba un plano de datos virtualizado descargado y acelerado que incluía funciones como Open vSwitch (OVS), compatibilidad con VirtIO, migración en vivo, duplicación de VM a VM, encapsulación/desencapsulación VLAN/VxLAN, Q-in-Q, equilibrio de carga RSS, agregación de enlaces y calidad de servicio (QoS).