Big Data de verdad, en 4K y en tiempo real; Arquitectura Logtrust

Juan Vicente Herrera @jvicenteherrera Joaquin Díez Gómez @joaquindiez

BIG DATA en Tiempo Real

¿Por qué BIG DATA?

All data that is not a fit for a traditional RDBMS, whether used for OLTP or Analytics purposes

@eddie_satterly - Splunk

Eventos

BIG DATA en Tiempo Real

Casos de Uso

• Devops

• Desarrolladores: detección de errores, análisis de uso de sus aplicaciones (Web, Apps)

• Analíticas en Tiempo Real (User & Business)

• Detección de anomalías, análisis de tendencias.

• CAPTURAMOS DATOS (Eventos)

• ALMACENAMOS

• EXTRAER SU VALOR POTENCIAL

SIMPLIFICANDO

¿por que no usar una Base de datos normal?

• cuando se tiene un martillo todos los problemas son clavos.

• ACID compromete los limites escalabilidad y rendimiento de los sistemas

• No todos los datos necesitan almacenamientos ACID

• NO ESCALAN

EL PROBLEMA

RDBMS

• 10 servidores

• 8640 eventos por dia ( 1 cada 10 segundos)

• 365 dias

• = 31.536.000 eventos en 1 año

Big Data Technologies (2011-)

Bases de Datos Relacionales (muy estructurados)

Sistemas de Archivos Distribuidos (semi-estructurados)

Clave/Valor, Columnares y otros (semi-estructurados)

MongoDB

NOSQL

Cassandra

CouchDB

RDBMS Sharing

HDFS Storage

Map / Reduce

Vamos a desarrollar nuestra propia tecnología !!!!!!

- Almacenar Datos con y sin estructura - Almacenarlos en su formato Original - Escalable - Tolerante a Fallos - Muy eficiente en escritura y en lectura - Escalabilidad lineal en el rendimiento - Sin degradación del rendimiento según se incrementa el volumen de datos. - Procesar información en Tiempo Real - Un Lenguaje común: SQL

OBJETIVO

19

100.000 EPS Escritura por core (1 hebra)1.000.000 EPS Lectura por core = 1 Query 2M EPS

Ubuntu Linux 8 cores

30GB Memoria 2TB disco

EL DATANODO

Alcohol

Malote Malote

51.000 Millones de Eventos (512 bytes)

¿Como se consigue esa velocidad?

• Eliminando TODO lo que no necesitamos

• No Es ACID

• Solo se implementa Escritura y Lectura de Datos

• Compresión de los datos en crudo. Ratio 12:1

20

21

Escritura 100.000 *8 = 800.000 EPS

Batrasio

MetaMalote

22

Escritura 100.000 *30 = 3.000.000 EPS

60TB = 1.5 Billones de Eventos

30 datanodos

Consulta 1M *60 = 60.000.000 EPS

SQL

23

Cluster de Almacenamiento

Motor de Correlación

Motor de Alertas

SQL

Motor de Agregación

SQL

Web App, Busqueda Dashboards, Reporting, Aplicaciones

VerticalesSQ

LAPI

RESTEmail

JIRA

PushOver

PagerDuty

HTTP/JSON

MySql

Integración contínua• Hace no mucho…

• Integración contínua a medias. Test pero no automatizados ni despliegues automáticos

• Despliegues manuales mediante scripts que no cubrían todo el despliegue

• Sin gestión de configuración (manual)

• Control de versiones mediante git

24

Ansible al rescate• Despliegues mediante Ansible

• Gestión de la configuración mediante Ansible

• Cifrado mediante Ansible-vault

• Despliegues contínuos (Gitlab + Jenkins + Ansible)

• Notificaciones de jobs Jenkins mediante Slack (Mucho por mejorar aún)

• Migración a GitLab (Mejor gestión de permisos)

• Test seguimos mejorándolos: Hemos fichado al primer QA!

25

Infraestructura/Stack• Agnósticos al proveedor gracias a:

• Ansible (SSH)

• Stack opensource (Ubuntu, Java,NodeJs,Tomcat, Nginx, HAproxy, MongoDB, MySQL, RabbitMQ…)

26

Proveedores actuales• AWS

• Azure

• VDC (Teléfonica)

• VmWare

• Bare metal

27

Tipo de instalaciones

• OnPremise (Cloud y bare metal). Grandes clientes solo.

• Híbridos (Cloud y bare metal): Datos en servidor cliente.

• SAS: Solo agente y datos a nuestra nube.

28

Demo Time

29

30

https://www.logtrust.com/en/category/jobs/