Big Data de verdad, en 4K y en tiempo real; Arquitectura Logtrust
Juan Vicente Herrera @jvicenteherrera Joaquin Díez Gómez @joaquindiez
All data that is not a fit for a traditional RDBMS, whether used for OLTP or Analytics purposes
@eddie_satterly - Splunk
• 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.
¿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
- 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
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
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
Top Related