No content

Franco Ariel Salonia Sobre nosotros CEO @ DinoCloud AWS Certified Solutions Architect - Professional [email protected] @Franksalo Franco Ariel Salonia Gonzalo Campos DevOps @ DinoCloud AWS Certified Solutions Architect - Associate (Coming Soon) [email protected] @GonzaaCampos Gonzalo Campos

Agenda ● Mensajería asíncrona en la vida real. ● Conceptos de asincronismo, colas y AMQP. ● Patrones de AMQP. ● Alternativas de soluciones en AWS ● El caso de uso y arquitectura elegida ● Momento de demo

La fábula de la cerveza

Conceptos y casos de uso de la mensajería ● Event: ○ Necesito saber cuándo hacer algo. ● Data Fragment: ○ Necesito darte una porción de datos sin la necesidad de conocer el esquema completo. ● Routing: ○ Controlar quién recibe qué mensaje, sin la necesidad de cambiar el emisor ni el receptor. ● Publish: ○ Avisar a todos los interesados que se publicó un mensaje. ● Batch: ○ Emisor y receptor pueden correr en momentos independientes. ● Telemetry: ○ Metadata de los servidores y dispositivos implicados. ● Load Share: ○ Agregar más consumidores para escalar.

Introducción a AMQP ● AMQP (Advanced Queuing Message Protocol) es un estándar abierto de protocolo de mensajería capa 7 para middlewares orientados a mensajes. Es un protocolo abierto (como TCP, HTTP, SMTP, etc.). ● Las features claves de AMQP son: ○ Orientación a mensajes ○ Colas ○ Routing ○ Confiabilidad ○ Seguridad

Escalas de deployment de AMQP Tipo de despliegue Posible escenario Uso casual / desarrollo 1 servidor, 1 usuario, 10 colas, 1 mensaje por segundo Aplicación en producción 2 servidores, 10-100 usuarios, 10-50 colas, 25 mensajes por segundo. Aplicación de misión crítica departamental 4 servidores, 100-500 usuarios, 50-100 colas, 250 mensajes por segundo. Aplicación de misión crítica regional 16 servidores, 500-2000 usuarios, 100-500 colas y tópicos, 2500 mensajes por segundo. Aplicación de misión crítica global 64 servidores, 2K-10K usuarios, 500-1000 colas y tópicos, 25000 mensajes por segundo. Market data (trading) 200 servidores, 5000 usuarios, 10K de tópicos y colas, 250K mensajes por segundo

AMQP Direct Exchanges ● Mensajería punto a punto. ● Un solo mensaje que debe ser enviado a un solo receptor. ● Puede tener múltiples consumidores (la carga puede ser balanceada).

AMQP Fan-Out Exchanges ● El fan-out exchange es un modelo “Publish and Suscribe”. ● Usado para enviar un mismo mensaje a múltiples receptores. ● Cualquier cola asociada a un fan-out exchange va a recibir cualquier mensaje recibido en el exchange. ● La consumición de los mensajes de la cola va a depender del número de consumidores y de la velocidad de procesamiento de los mensajes de los consumidores.

AMQP Topic Exchange ● Ruteo de mensajes basados en el contenido. ● Mensajes agregados a la cola basado en patrones de bindeo. ● Mecanismo muy poderoso.

Mensajería asíncrona en AWS

Mensajería asíncrona en AWS Fuente: https://medium.com/trainingcenter/sqs-ou-kinesis-comparando-laranjas-com-ma%C3%A7%C3%A3s-fe193b974a61

Data Streams - La aplicabilidad de Kinesis ➔ El principal caso de uso de Kinesis es: colectar, almacenar y procesar stream de datos (en tiempo real). ➔ Los streams de datos son datos generados continuamente por miles de fuentes de datos, que típicamente suelen enviarse simultáneamente y de poco tamaño. ➔ Casos de uso comunes: ◆ Colección de logs y datos de eventos. ◆ Análisis en real-time. ◆ Captura de datos de apps mobile. ◆ Data feed para IoT.

Ventajas y desventajas de Kinesis ● Ventajas: ○ Real time: throughput altísimo para ingesta y procesamiento de datos. ○ “Big Data” ● Desventajas: ○ Administración de los shards. ○ Throughput de lectura limitada: 5 readings per second per shard. 2MB / sec. ○ Librerías complejas para consumers y producers.

Queuing - La aplicabilidad de SQS / SNS ➔ Las colas de mensajes facilitan el desacople y scheduling de microservicios, sistemas distribuidos y aplicaciones serverless. ➔ Usando una cola, se pueden enviar, almacenar y recibir cualquier número de mensajes entre diferentes componentes de software. ➔ Casos de uso comunes: ◆ Integración entre aplicaciones. ◆ Desacople de microservicios. ◆ Desacople de navegación de usuarios en procesos pesados. ◆ Alocar tareas en diferentes workers. ◆ Mensajes batch para procesamiento futuro.

Ventajas y desventajas de SQS ● Ventajas: ○ Fácil de usar ○ Throughput de lectura. ● Desventajas: ○ Un consumidor por cola por mensaje: Esto puede ser solucionado integrando SNS. ○ Imposibilidad de reproducir mensajes ya procesados: En estos casos se suelen usar otros data sources, como por ejemplo DynamoDB.

El problema

Los requerimientos ● Migrar microservicios alocados en Bluemix (IBM Cloud). ● Permitir que estos servicios se comuniquen con el core de naranja de manera segura: un Oracle Enterprise Service Bus comunicándose con Cobol. ● Incorporar capa de mensajería asíncrona y desacople de mensajes en peticiones complejas que se comuniquen con el core y otros servicios.

La solución

DISCLAIMER

La arquitectura

La arquitectura

Migrando los servicios CustomerService Customer CRUD operations Customer CRUD operations CustomerProducer CustomerConsumer CustomerQueue (c/ su deadletter) Customer Topics (1 por operación)

La incorporación de DynamoDB ● Mantener el estado de los mensajes y el tracking de los eventos. ● De esta manera podemos: ○ Conocer el estado actual de cada mensaje. ○ Evitar mensajes duplicados en los consumidores. ○ Hacer un seguimiento de los eventos. ○ Conocer cuándo entró en la deadletter queue.

La incorporación de DynamoDB

Mucho bla bla, vamos a la Demo

¡GRACIAS! ¿PREGUNTAS?

No content