Eficiencia en la ingesta masiva de MQSeries on premise a AWS S3 y EKS

Caso de éxito | AWS


Eficiencia en la ingesta masiva de MQSeries on premise a AWS S3 y EKS



Objetivos:

  • Contar con un artefacto que sea capaz de extraer los eventos de MQSeries a una velocidad cercana al tiempo real.
  • Depositar estos eventos en un pipeline de procesamiento de datos, para que comience con el ciclo de procesamiento pertinente al lago de datos de Paris.
  • Trasladar de manera rápida y eficaz los eventos de transacciones generadas en los PoS al lago de datos ubicado en AWS.

La Solución:

  • Paralelización del proceso de extracción de mensajes, logrando una solución escalable que permite soportar altas cargas de trabajo en periodos de alta demanda.
  • Según la cantidad de mensajes, se incrementan los hilos y los pods, permitiendo la cantidad de mensajes extraídos totalmente flexible según demanda.
  • Arquitectura de artefacto de software se basado en los principios de diseño de arquitecturas hexagonales.
  • Diseño de un pipeline de datos flexible.

Beneficios:

  • El gobierno recomendado permite a través de roles de acceso en base a las funciones de los responsables de leer y escribir datos en las diferentes etapas, dando mayor flexibilidad a la hora de generar zonas seguras o enmascaradas a datos esenciales.
  • Alcance de aproximadamente 3.7 mensajes extraídos por segundo, por una instancia y un hilo.
  • Escenario de ejemplo:
    • Mensajes: 587.122
    • Cantidad de hilos: 10
    • Duración de la extracción total: 32 minutos

Resumen

La empresa

París es una cadena de tiendas por departamento creada el año 1900 en Chile y que, con el tiempo, se ha posicionado como una de las mayores empresas del sector. Desde el 2005 pasó a ser parte del conglomerado Cencosud y desde el 2013 abrió tiendas en Perú, logrando así su internacionalización del negocio de Tiendas por Departamento.

El desafío

En la actualidad, los puntos de venta de Paris generan un alto volumen de transacciones de ventas en fechas como el día de la madre y navidad. Estas transacciones generan alrededor de 1.500.000 eventos en un periodo de 12 horas. Estos eventos son recolectados de forma distribuida. En cada tienda existe un concentrador que toma los mensajes y los comunica. Estos mensajes se encuentran descritos en TSL, un lenguaje de transacciones de cajas, que debe ser transformado a un lenguaje que los analistas de negocio puedan comprender.

El conjunto de estos eventos llega a un servidor de colas MQSeries de IBM que está en un datacenter privado de Cencosud en Chile. Luego de esto, es necesario tomar estos eventos y trasladarlos a la fase inicial del lago de datos donde deberán ser procesados en AWS. La latencia de la red es de 132 ms, siendo 264 ms la velocidad máxima con la que un mensaje puede ser extraído de la cola MQ on-premise a un bucket S3 en AWS. Dado el volumen de mensajes en momentos críticos, la extracción de estos en forma secuencial lleva a tiempos inaceptables para el negocio.

El requerimiento de París es extraer los eventos de MQSeries on-premise a una velocidad cercana al tiempo real, y depositarlos en un pipeline de procesamiento de datos, para que comience con el ciclo de procesamiento pertinente en el lago de datos de París en AWS.


Zenta construyó una solución de alto rendimiento que permitió mover grandes volúmenes de datos de la plataforma on-premise a AWS, tecnología en la que se basa nuestra estrategia de datos.

-- Pablo Durán,
Subgerente de Arquitectura Digital
Cencosud


La solución

Como Zenta, construimos una solución basada en auto-escalamiento para la recuperación en paralelo de mensajes de la cola MQ desde AWS. La solución consiste en una aplicación implementada en Java 8, utilizando una arquitectura hexagonal para independizar la lógica de extracción de mensajes de tecnologías particulares. El core de la aplicación está conformado por un gestor de extracción (Gestor Extracción) que es responsable de la extracción de mensajes de la cola de mensajes y su archivado en el repositorio. El gestor de extracción utiliza un monitor (instancia de Monitor que corre en su propio hilo) que, en forma periódica, obtiene el tamaño de la cola de mensajes y, en función de este y de la configuración de mapeo de tamaño de la cola de mensajes a la cantidad de extractores, solicita al gestor de la extracción que re-escale la cantidad de extractores (instancias de Extractor). Cada extractor corre en su propio hilo y tiene la responsabilidad de extraer un mensaje de la cola y de archivarlo en un bucket S3. Este es el primer nivel de escalamiento, utilizando hilos de ejecución dentro de la aplicación.

Para el segundo nivel de escalamiento, se utilizó la solución de EKS para administrar clústeres de kubernetes y usar las características de crecimiento horizontal. Dependiendo de la carga de trabajo de la aplicación, reflejado en su consumo de recursos, se inician o detienen pods corriendo la aplicación. De esta forma, en un escenario de alta carga, crecerá la cantidad de instancias de la aplicación corriendo en forma paralela, logrando así la extracción de todos los mensajes de la cola MQ a AWS en el menor tiempo posible.

La aplicación configurada con los dos niveles de escalamiento descritos, deja en un bucket S3 los mensajes en crudo (RAW), para luego ser procesados por una función ejecutada en AWS Lambda, la cual clasifica los mensajes según su tipo y los deposita en las carpetas correspondientes en un segundo bucket S3. Esto permite poder definir traductores específicos para cada tipo de mensaje y además da la libertad de escalar por tipo de mensaje. El escalamiento de AWS Lambda es capaz de generar la cantidad de funciones necesarias según la demanda o volumen de mensajes a traducir. Como atributo adicional, esta estructura de lago de datos inicial permite mantener una historia desde el dato crudo hasta el dato procesado sin perder detalles del mismo.

El gobierno de este tipo de estructuras de lago de datos es más flexible ya que permite gobernar a través de roles de acceso en base a las funciones de los responsables de leer y escribir datos en las diferentes etapas, dando mayor flexibilidad a la hora de generar zonas seguras o enmascaradas a datos esenciales.

En resumen, en el proceso se utilizaron los siguientes servicios de AWS:

  • Elastic Kubernetes Service (EKS)
  • Simple Storage Service (S3)
  • Lambda
  • Identity and Access Management

Resultados

Mediante el trabajo realizado, se logró una paralelización del proceso de extracción de mensajes, obteniendo una solución escalable que permite soportar altas cargas de trabajo en periodos de alta demanda. Esta paralelización se logró construyendo una aplicación de extracción que consume los mensajes de la cola de MQ on-premise. La aplicación utiliza una conexión no-bloqueante a la cola de mensajes, permitiendo así el trabajo en conjunto por múltiples hilos dentro de una aplicación, y múltiples instancias de ésta corriendo en múltiples pods de EKS. La solución construida, utilizando como máximo 10 pods y 10 hilos de extractores por pod, logró extraer y archivar 276 mensajes por segundo, número muy superior a la cota mínima de 120 mensajes por segundo necesaria para los escenarios de alta carga de París.

Si bien es cierto, esto se trabajó como una PoC, actualmente esto está operando en ambientes productivos