Esta es una publicación coescrita con Rivlin Pereira y Vaibhav Pandey de Tanzu CloudHealth (VMware by Broadcom).

VMware Tanzu CloudHealth es la plataforma de gestión de costos en la nube elegida por más de 20,000 organizaciones en todo el mundo, que confían en ella para optimizar y gobernar sus entornos multinube más grandes y complejos. En esta publicación, analizamos cómo el equipo de DevOps de VMware Tanzu CloudHealth migró sus cargas de trabajo autoadministradas de Apache Kafka (que ejecutan la versión 2.0) a Streaming administrado por Amazon para Apache Kafka (Amazon MSK) ejecutando la versión 2.6.2. Discutimos las arquitecturas del sistema, los procesos de implementación, la creación de temas, la observabilidad, el control de acceso, la migración de temas y todos los problemas que enfrentamos con la infraestructura existente, además de cómo y por qué migramos a la nueva configuración de Kafka y algunas lecciones aprendidas.

Descripción general del clúster Kafka

En el panorama de rápida evolución de los sistemas distribuidos, la plataforma de microservicios de próxima generación de VMware Tanzu CloudHealth se basa en Kafka como columna vertebral de mensajería. Para nosotros, el sistema de registro distribuido de alto rendimiento de Kafka destaca en el manejo de flujos de datos masivos, lo que lo hace indispensable para una comunicación fluida. Al actuar como un sistema de registro distribuido, Kafka captura y almacena de manera eficiente diversos registros, desde registros de acceso al servidor HTTP hasta registros de auditoría de eventos de seguridad.

La versatilidad de Kafka brilla al admitir patrones de mensajería clave, tratando los mensajes como registros básicos o almacenes estructurados de valores clave. La partición dinámica y el orden consistente garantizan una organización eficiente de los mensajes. La confiabilidad inquebrantable de Kafka se alinea con nuestro compromiso con la integridad de los datos.

La integración de los servicios Ruby con Kafka se optimiza a través de la biblioteca Karafka, que actúa como un contenedor de nivel superior. Nuestros otros servicios de pila de idiomas utilizan envoltorios similares. Las sólidas funciones de depuración y los comandos administrativos de Kafka desempeñan un papel fundamental para garantizar operaciones fluidas y el estado de la infraestructura.

Kafka como pilar arquitectónico

En la plataforma de microservicios de próxima generación de VMware Tanzu CloudHealth, Kafka emerge como un pilar arquitectónico crítico. Su capacidad para manejar altas velocidades de datos, admitir diversos patrones de mensajería y garantizar la entrega de mensajes se alinea perfectamente con nuestras necesidades operativas. A medida que continuamos innovando y escalando, Kafka sigue siendo un compañero firme que nos permite construir una infraestructura resiliente y eficiente.

Por qué migramos a Amazon MSK

Para nosotros, la migración a Amazon MSK se redujo a tres puntos de decisión clave:

• Operaciones técnicas simplificadas – Ejecutar Kafka en una infraestructura autogestionada fue una sobrecarga operativa para nosotros. No habíamos actualizado la versión 2.0.0 de Kafka por un tiempo y los brokers de Kafka estaban dejando de funcionar, lo que causaba problemas con los temas que se desconectaban. También tuvimos que ejecutar scripts manualmente para aumentar los factores de replicación y reequilibrar a los líderes, lo que supuso un esfuerzo manual adicional.
• Canalizaciones heredadas obsoletas y permisos simplificados – Estábamos buscando alejarnos de nuestras tuberías existentes escritas en Ansible para crear temas de Kafka en el clúster. También teníamos un proceso engorroso para dar a los miembros del equipo acceso a las máquinas Kafka en fase de preparación y producción, y queríamos simplificarlo.
• Costo, parches y soporte - Porque Apache Zookeeper está completamente administrado y parcheado por AWS, pasar a Amazon MSK nos iba a ahorrar tiempo y dinero. Además, descubrimos que ejecutar Amazon MSK con el mismo tipo de agentes en Nube informática elástica de Amazon (Amazon EC2) era más barato de ejecutar en Amazon MSK. Combinado con el hecho de que AWS aplica parches de seguridad a los corredores, migrar a Amazon MSK fue una decisión fácil. Esto también significó que el equipo quedó libre para trabajar en otras cosas importantes. Finalmente, obtener soporte empresarial de AWS también fue fundamental en nuestra decisión final de pasar a una solución administrada.

Cómo migramos a Amazon MSK

Una vez identificados los impulsores clave, avanzamos con una propuesta de diseño para migrar Kafka autoadministrado existente a Amazon MSK. Realizamos los siguientes pasos previos a la migración antes de la implementación real:

• Evaluación:
  • Realicé una evaluación meticulosa del clúster EC2 Kafka existente, entendiendo sus configuraciones y dependencias.
  • Compatibilidad verificada de la versión Kafka con Amazon MSK
• Configuración de Amazon MSK con Terraform
• Configuración de la red:
  • Se garantizó una conectividad de red perfecta entre los clústeres EC2 Kafka y MSK, se ajustaron los grupos de seguridad y la configuración del firewall.

Después de los pasos previos a la migración, implementamos lo siguiente para el nuevo diseño:

• Canalizaciones automatizadas de implementación, actualización y creación de temas para clústeres de MSK:
  • En la nueva configuración, queríamos tener implementaciones y actualizaciones automatizadas de los clústeres MSK de forma repetible mediante una herramienta IaC. Por lo tanto, creamos módulos Terraform personalizados para implementaciones y actualizaciones de clústeres MSK. Estos módulos fueron llamados desde un Jenkins canalización para implementaciones automatizadas y actualizaciones de los clústeres de MSK. Para la creación de temas de Kafka, utilizamos una canalización propia basada en Ansible, que no era estable y generó muchas quejas por parte de los equipos de desarrollo. Como resultado, evaluamos opciones para implementaciones en Kubernetes grupos y utilizó el Operador de tema Strimzi para crear temas en clústeres de MSK. La creación de temas se automatizó mediante canalizaciones de Jenkins, que los equipos de desarrollo podían autoservicio.
• Mejor observabilidad de los clusters:
  • Los antiguos cúmulos de Kafka no tenían buena observabilidad. Solo teníamos alertas sobre el tamaño del disco del broker Kafka. Con Amazon MSK, aprovechamos monitoreo abierto usando Prometeo. Creamos un servidor Prometheus independiente que extraía métricas de los clústeres de MSK y las enviaba a nuestra herramienta de observabilidad interna. Como resultado de la observabilidad mejorada, pudimos configurar alertas sólidas para Amazon MSK, lo que no era posible con nuestra configuración anterior.
• COGS mejorados y mejor infraestructura informática:
  • Para nuestra antigua infraestructura de Kafka, teníamos que pagar por la administración de instancias de Kafka y Zookeeper, más los costos adicionales de almacenamiento del corredor y los costos de transferencia de datos. Con el cambio a Amazon MSK, debido a que Zookeeper está completamente administrado por AWS, solo tenemos que pagar por los nodos Kafka, el almacenamiento del agente y los costos de transferencia de datos. Como resultado, en la configuración final de Amazon MSK para producción, ahorramos no solo en costos de infraestructura sino también en costos operativos.
• Operaciones simplificadas y seguridad mejorada:
  • Con el cambio a Amazon MSK, no tuvimos que administrar ninguna instancia de Zookeeper. AWS también se encargó de los parches de seguridad del corredor por nosotros.
  • Las actualizaciones del clúster se volvieron más sencillas con el cambio a Amazon MSK; es un proceso sencillo de iniciar desde la consola de Amazon MSK.
  • Con Amazon MSK, tenemos intermediario escalado automático fuera de la caja. Como resultado, no tuvimos que preocuparnos de que los brokers se quedaran sin espacio en disco, lo que generó una estabilidad adicional del clúster MSK.
  • También obtuvimos seguridad adicional para el clúster porque Amazon MSK admite el cifrado en reposo de forma predeterminada y también están disponibles varias opciones para el cifrado en tránsito. Para obtener más información, consulte Protección de datos en Amazon Managed Streaming para Apache Kafka.

Durante nuestros pasos previos a la migración, validamos la configuración en el entorno de prueba antes de continuar con la producción.

Estrategia de migración de temas de Kafka

Una vez completada la configuración del clúster MSK, realizamos una migración de datos de temas de Kafka desde el clúster antiguo que se ejecuta en Amazon EC2 al nuevo clúster MSK. Para lograr esto, realizamos los siguientes pasos:

• Configurar MirrorMaker con Terraform – Usamos Terraform para orquestar el despliegue de un fabricante de espejos Clúster que consta de 15 nodos. Esto demostró la escalabilidad y flexibilidad al ajustar la cantidad de nodos en función de las necesidades de replicación simultáneas de la migración.
• Implementar una estrategia de replicación simultánea: implementamos una estrategia de replicación simultánea con 15 nodos MirrorMaker para acelerar el proceso de migración. Nuestro enfoque impulsado por Terraform contribuyó a la optimización de costos mediante la gestión eficiente de los recursos durante la migración y garantizó la confiabilidad y coherencia de los clústeres de MSK y MirrorMaker. También mostró cómo la configuración elegida acelera la transferencia de datos, optimizando tiempo y recursos.
• Migrar datos – Migramos con éxito 2 TB de datos en un período de tiempo notablemente corto, minimizando el tiempo de inactividad y mostrando la eficiencia de la estrategia de replicación simultánea.
• Configurar el seguimiento posterior a la migración – Implementamos un monitoreo y alertas sólidos durante la migración, lo que contribuyó a un proceso fluido al identificar y abordar los problemas con prontitud.

El siguiente diagrama ilustra la arquitectura una vez completada la migración del tema.

Desafíos y lecciones aprendidas

Emprender un viaje migratorio, especialmente con grandes conjuntos de datos, suele ir acompañado de desafíos imprevistos. En esta sección, profundizamos en los desafíos encontrados durante la migración de temas de EC2 Kafka a Amazon MSK utilizando MirrorMaker y compartimos ideas y soluciones valiosas que dieron forma al éxito de nuestra migración.

Desafío 1: Compensar discrepancias

Uno de los desafíos que encontramos fue la falta de coincidencia en las compensaciones de temas entre los clústeres de origen y de destino, incluso con la sincronización de compensaciones habilitada en MirrorMaker. La lección aprendida aquí fue que los valores de compensación no necesariamente tienen que ser idénticos, siempre que la sincronización de compensación esté habilitada, lo que garantiza que los temas tengan la posición correcta para leer los datos.

Abordamos este problema utilizando una herramienta personalizada para ejecutar pruebas en grupos de consumidores, confirmando que las compensaciones traducidas eran más pequeñas o estaban al día, lo que indica sincronización según MirrorMaker.

Desafío 2: Migración de datos lenta

El proceso de migración enfrentó un cuello de botella: la transferencia de datos fue más lenta de lo previsto, especialmente con un conjunto de datos sustancial de 2 TB. A pesar de contar con un clúster MirrorMaker de 20 nodos, la velocidad era insuficiente.

Para superar esto, el equipo agrupó estratégicamente los nodos de MirrorMaker en función de números de puerto únicos. Los grupos de cinco nodos MirrorMaker, cada uno con un puerto distinto, aumentaron significativamente el rendimiento, lo que nos permitió migrar datos en horas en lugar de días.

Desafío 3: Falta de documentación detallada del proceso

Navegar por el territorio inexplorado de la migración de grandes conjuntos de datos utilizando MirrorMaker destacó la ausencia de documentación detallada para tales escenarios.

Mediante prueba y error, el equipo creó un módulo IaC utilizando Terraform. Este módulo simplificó todo el proceso de creación del clúster con configuraciones optimizadas, lo que permitió un inicio perfecto de la migración en cuestión de minutos.

Configuración final y próximos pasos

Como resultado del cambio a Amazon MSK, nuestra configuración final después de la migración del tema se parecía al siguiente diagrama.

Estamos considerando las siguientes mejoras futuras:

Conclusión.

En esta publicación, analizamos cómo VMware Tanzu CloudHealth migró su infraestructura Kafka existente basada en Amazon EC2 a Amazon MSK. Lo guiamos a través de la nueva arquitectura, implementación y canales de creación de temas, mejoras en la observabilidad y el control de acceso, los desafíos de la migración de temas y los problemas que enfrentamos con la infraestructura existente, además de cómo y por qué migramos a la nueva configuración de Amazon MSK. También hablamos de todas las ventajas que nos brindó Amazon MSK, la arquitectura final que logramos con esta migración y los lecciones aprendidas.

Para nosotros, la interacción de la sincronización de compensación, la agrupación estratégica de nodos y la IaC resultó fundamental para superar los obstáculos y garantizar una migración exitosa de Amazon EC2 Kafka a Amazon MSK. Esta publicación sirve como testimonio del poder de la adaptabilidad y la innovación en los desafíos migratorios, ofreciendo ideas para otras personas que recorren un camino similar.

Si ejecuta Kafka autoadministrado en AWS, le recomendamos que pruebe la oferta de Kafka administrado. Amazon MSK.

Acerca de los autores

Rivlin Pereira es ingeniero de DevOps en la división VMware Tanzu. Le apasiona Kubernetes y trabaja en CloudHealth Platform creando y operando soluciones en la nube que son escalables, confiables y rentables.

Vaibhav Pandey, ingeniero de software de plantilla en Broadcom, es un colaborador clave en el desarrollo de soluciones de computación en la nube. Especializado en arquitectura e ingeniería de capas de almacenamiento de datos, le apasiona crear y escalar aplicaciones SaaS para un rendimiento óptimo.

Raj Ramasubbu es un Arquitecto de Soluciones Especialista en Análisis Sénior centrado en big data y análisis y AI/ML con Amazon Web Services. Ayuda a los clientes a diseñar y crear soluciones basadas en la nube altamente escalables, seguras y de alto rendimiento en AWS. Raj proporcionó experiencia técnica y liderazgo en la creación de soluciones de ingeniería de datos, análisis de big data, inteligencia empresarial y ciencia de datos durante más de 18 años antes de unirse a AWS. Ayudó a clientes en varios sectores verticales de la industria, como atención médica, dispositivos médicos, ciencias de la vida, comercio minorista, administración de activos, seguros de automóviles, REIT residencial, agricultura, seguros de títulos, cadena de suministro, administración de documentos y bienes raíces.

Todd McGrath es especialista en transmisión de datos en Amazon Web Services, donde asesora a los clientes sobre sus estrategias, integración, arquitectura y soluciones de transmisión. En el aspecto personal, le gusta observar y apoyar a sus tres hijos adolescentes en sus actividades preferidas, así como seguir sus propias actividades como pesca, pickleball, hockey sobre hielo y happy hour con amigos y familiares en pontones. Conéctese con él en LinkedIn.

Satya Pattanaik es arquitecto sénior de soluciones en AWS. Ha estado ayudando a los ISV a crear aplicaciones escalables y resistentes en la nube de AWS. Antes de unirse a AWS, desempeñó un papel importante en los segmentos empresariales con su crecimiento y éxito. Fuera del trabajo, dedica tiempo a aprender “cómo cocinar una sabrosa barbacoa” y a probar nuevas recetas.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/