agsandrew - Fotolia

Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

Ticketmaster unifica el monitoreo de DevOps con Confluent Kafka

Ticketmaster soluciona problemas y asegura aplicaciones distribuidas utilizando el procesamiento de flujo de Kafka como un hub central para la recopilación de datos.

El procesamiento de flujo de Confluent Kafka le da a Ticketmaster Entertainment Inc. un sistema cohesivo para la recolección de datos de aplicaciones distribuidas, y una integración simple con herramientas de análisis de seguridad y monitoreo de DevOps.

A medida que la compañía de venta y distribución de boletos comenzó a moverse hace cuatro años desde las aplicaciones monolíticas hacia una arquitectura de microservicios como parte de su transformación DevOps, descubrió que la gestión de datos se volvería más crítica y más difícil.

"Para saber con mucha precisión qué está sucediendo en la capa [de transacciones] individual se requiere la integración con cada uno de estos sistemas para todos y cada uno de los proyectos que se realicen", dijo Chris Smith, vicepresidente de ingeniería y ciencia de datos de Ticketmaster, con sede en Beverly Hills, California. Algunos sistemas de monitoreo de TI se configuraron para agregar datos de aplicaciones distribuidas en grupos de máquinas virtuales, pero el monitoreo de una infraestructura de microservicios más granular requería visibilidad en cada componente específico, lo cual no era posible mediante los métodos tradicionales, según Smith.

"Cuando tienes n tecnologías, y para nosotros n es bastante grande porque hemos existido durante 40 años, [el monitoreo] se convierte en un problema de n al cuadrado", dijo. "Los datos no eran una pieza central de la estrategia tecnológica hace 40 años".

El procesamiento de flujo de Kafka clasifica los datos mezclados

En lugar de intentar integrar todos los componentes de unas 300 aplicaciones alojadas en más de 4.500 máquinas virtuales entre los centros de datos locales de la compañía y la infraestructura de nube de AWS, Ticketmaster configuró un lago de datos centralizado para la telemetría de aplicaciones y lo alimentó utilizando un conjunto de tuberías de procesamiento de flujo Apache Kafka.

En el sistema Kafka, respaldado en el despliegue de Ticketmaster por el proveedor comercial Confluent, Inc., las aplicaciones envían flujos de datos a repositorios conocidos como temas a través de la API de Productor de Kafka, y los leen desde un clúster de servidores central de Kafka usando la API del consumidor. Es una versión distribuida de los sistemas de intermediación de mensajes de aplicaciones que utilizan una arquitectura de publicación/suscripción para compartir información de forma asíncrona. Sin embargo, en contraste, la arquitectura Kafka implica menos sobrecarga que los enfoques tradicionales porque delega tareas de seguimiento de lectura a los consumidores en lugar de utilizar los recursos del clúster central.

"Cada tecnología [solo] tiene que estar conectada a Kafka, y a través de eso, están efectivamente conectadas entre sí", dijo Smith. Cada registro de aplicación almacenado en el sistema Confluent Kafka incluye una marca de tiempo, que ayuda a correlacionar eventos y transacciones de manera consistente entre varios componentes de la aplicación.

El apoyo de Confluent Kafka alivia los dolores de crecimiento

Confluent, fundada por los desarrolladores que crearon Kafka en LinkedIn en 2014, admite Apache Kafka de código abierto de la misma forma que Red Hat admite Linux de código abierto. Ticketmaster se apoya en el soporte de Confluent para administrar su back-end de procesamiento de flujo Kafka, que puede ser una tarea compleja.

"Lo que la gente suele preguntar, y en lo que siempre insisto, es sobre el Registro de esquemas que Confluent proporciona", dijo Smith. Sin él, los cambios en los flujos de datos pueden perturbar potencialmente a los consumidores vinculados a ellos y, como resultado, la fragilidad dentro del sistema puede acumularse.

"Realmente uno puede llegar a un punto donde se adquiere deuda tecnológica, y eso podría matar [el negocio]", dijo. "Una vez que se llega a docenas [de sistemas], realmente se convierte en un gran dolor de cabeza que puede ponernos en un punto muerto operativo, donde literalmente no se puede hacer ningún cambio".

El apoyo de Confluent también fue clave para desenredar un clúster de Kafka mal provisto a medida que crecía el uso del procesamiento de flujo por parte de Ticketmaster.

"En un momento de la producción, teníamos más de 10,000 particiones en uno de nuestros cuatro grupos; no hay realmente una buena justificación para eso", dijo Smith. "Era solo una función de las personas que no entendían cómo dimensionar sus temas y administrar su software".

Sin embargo, corregir este problema requería grandes cantidades de eliminación de datos. Mientras Kafka federa el consumo de datos por defecto, las escrituras permanecen centralizadas en un almacén de datos de Apache ZooKeeper, que se vio abrumado por los intentos de eliminar la mayoría de esas 10,000 particiones.

"Los ingenieros de Confluent nos explicaron cómo detener todas esas eliminaciones, para que podamos rehacerlas de una manera más acelerada y asegurarnos de que no se pierda nada y que no se cree ningún riesgo operativo", dijo Smith.

LightStep y Vowpal Wabbit disciernen patrones en las corrientes de Kafka

Con los datos centralizados a través del clúster Confluent Kafka, el siguiente paso de Ticketmaster fue aplicar herramientas de análisis de datos para solucionar incidentes de TI y proteger sus aplicaciones contra amenazas que evolucionan rápidamente.

Inicialmente, Ticketmaster utilizó el proyecto de código abierto Jaeger para el rastreo distribuido de transacciones de clientes a través de sus aplicaciones. Los datos en tiempo real recopilados a través de Kafka significaron que podría usar el sistema de rastreo distribuido para priorizar a los consumidores comunes sobre aquellos que abusarían del sistema.

"Básicamente, los malos actores abusan de nuestro sistema para asegurarse de tener acceso prioritario a los boletos", dijo Smith. Estos malos actores luego revenden boletos a un precio marcado para su propio beneficio. "Tener una visión holística de toda la actividad en el sistema nos permite construir modelos de aprendizaje automático que pueden combatir ese abuso y, lo que es más importante, priorizar la capacidad de los fanáticos para obtener acceso antes que esos malos actores".

Eventualmente, las interfaces personalizadas creadas internamente para Jaeger resultaron demasiado engorrosas para administrar, y Ticketmaster enlistó al proveedor de rastreo distribuido LightStep para analizar y visualizar datos.

"Jaeger fue difícil y lento, no en términos de recuperar los resultados de la consulta, sino en términos de que los humanos descubrieran cómo hacer la pregunta correcta y obtener la respuesta correcta", dijo Smith. "LightStep no solo visualizaba los datos, sino que los navegaba más allá de esa visualización inicial".

Para el análisis de seguridad, Ticketmaster utiliza un motor de aprendizaje automático de código abierto escrito en Microsoft llamado Vowpal Wabbit para adelantarse a los ataques en sus sistemas. Aquí, la naturaleza centralizada y en tiempo real de los flujos de datos de Kafka es crucial, dijo Smith.

"Los atacantes aprenden de nuestro comportamiento y ajustan su comportamiento en consecuencia", dijo. "Cualquiera que sea el modelo [de amenaza] que tenga su organización ... 15 minutos después, ellos han cambiado su comportamiento. Por lo tanto, realmente necesitamos un mecanismo de aprendizaje en línea para reaccionar lo suficientemente rápido ante el entorno cambiante".

Monitoreo de DevOps, abundan las opciones de análisis de datos

Otras empresas han suministrado transmisiones de Kafka al software AIOps de compañías como Moogsoft, Inc. para aplicar el aprendizaje automático para la reparación de incidentes de TI, pero Ticketmaster tiene científicos de datos internos que pueden diseñar sus propios algoritmos de análisis de seguridad utilizando el motor de aprendizaje automático de código abierto, explicó Smith.

Mientras tanto, hay muchas herramientas de análisis de datos disponibles para empresas que desean centralizar los datos de monitoreo de DevOps, desde almacenes de datos tradicionales de IBM, Teradata y SAS Institute, hasta proveedores de distribución de Hadoop como Cloudera, Hortonworks y MapR y especialistas como MemSQL, SQLstream y Striim. Confluent Kafka compite directamente con los servicios de procesamiento de flujo de datos de proveedores en la nube como Amazon Kinesis y Google Cloud Dataproc. Los usuarios de microservicios también pueden aplicar una malla de servicios para administrar centralmente la seguridad de TI y la telemetría junto con herramientas como Kafka, aunque Smith dijo que la malla de servicios sigue siendo demasiado compleja para su gusto.

"Estoy tratando de evitar que Envoy abarque todas las comunicaciones con Kafka, lo cual creo que solo complicará todo, y [por lo tanto] creará nuevos riesgos para la operación de Kafka", dijo. "Prefiero tener una exposición directa a los corredores [de Kafka] y aprovechar su contenido".

Investigue más sobre Análisis de negocios e inteligencia de negocios

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close