#SGNext Massive storage in the Mexican banking industry

En esta sesión analizaremos el caso de un proyecto que se realizó para una institución financiera para manejar el almacenamiento y búsqueda de grandes cantidades de datos. La implementación utiliza un cluster de 24 nodos distribuidos para manejar y buscar miles de millones de documentos que representan cientos de terabytes. Entre las tecnologías que se utilizaron están #StorageGrid y #Elasticsearch.

En esta plática compartiremos algunos de los principales retos técnicos del proyecto, y cómo se resolvieron

Transcript

1. Ya eres parte de la evolución Liquid Day Almacenamiento masivo en el sector bancario con StorageGRID Webscale & Elasticsearch Domingo Suarez Torres @domix
2. Agenda • Storage • Alternativas • Caso de estudio • Lecciones aprendidas
3. Sobre Domingo • @domix (twitter, github) • CTO @ HolaGus • CoFounder @ TheDataPub • YouTube Channel http://bit.ly/coderdog • Previamente • Solution Architect @ SyC • Chief Architect @ Grupo Expansión • CTO @ clickOnero
4. storage
5. https://www.domo.com/blog/2015/08/data-never-sleeps-3-0/
7. https://www.domo.com/blog/2016/06/data-never-sleeps-4-0/
9. Almacenamiento masivo • No solo para compañías de social media • Tendencia a la alta en compañías de bienes y servicios • Requerimientos legales • Archivo muerto • Data Analytics • Medios de información cada vez más ricos
10. Tipos de almacenamiento • Archivos • File systems • Estructura jerárquica (Carpetas/Directorios) • Objeto (Blob storage/Object storage) • Contenedores (Buckets/Containers) • No estructurado, para acceder se requiere un conjunto de llaves • Identificador del contenedor + identificador del objeto
11. Cloud Storage
13. REST API propietario
17. Storage REST APIs • Amazon S3 • OpenStack Swift • CDMI (Cloud Data Management Interface) • By Storage Network Industry Association (SNIA) • Propietarias como Azure <- NO recomendado
18. ¿Cuando usar cloud storage? • Pay as you go (presupuesto limitado) • Capacidad interna en la compañía para integrar el servicio con sistemas existentes • Información no restringida por las leyes locales/ federales (recuerden terrible caso del INE)
19. Opciones en Appliances
21. Interface de appliances • Muchos están basados en estándares abiertos • OpenStack Swift • CDMI • Amazon S3 • Se ha convertido en un estándar de industria.
22. Cuando usar un appliance • Tienes presupuesto • Tienes un centro de datos dedicado • Usas Colocation • Administras información restringida por las leyes locales/federales
23. Alternativa OpenSource • LinkedIn recientemente anuncio Ambry • http://bit.ly/linkedin-ambry • Distributed Object Storage • https://github.com/ linkedin/ambry • API REST propietaria • Pensado para cloud • Escalamiento horizontal • Baja latencia • Optimizado para archivos pequeños y grandes
25. A considerar • Object storage es el camino para alto escalamiento y gran capacidad de almacenamiento • Las soluciones de Object storage en general no ofrecen un mecanismo de búsqueda por metadata • Si se desea poder hacer búsquedas no hay soporte nativo, solo paginaciones de los contenedores y filtros sencillos (fecha, patrones de nombre)
26. Caso de estudio • El Banco más grande de México • Solución para almacenamiento y recuperación de al menos 7 sistemas fuentes • Estados de cuenta (XMLs pequeños y algunos enormes) • Archivo digital (imágenes) • Bitácora de transacciones • Mi rol en el proyecto fue de Arquitecto de Solución.
27. Requerimientos • Alta capacidad de almacenamiento (Petas) • Replicación en 2 centros de datos nacionales, ademas del banco (activo-activo) • Búsqueda de documentos basada en metadata • Alta disponibilidad • API RESTful para integrar en los sistemas internos • Seguridad • Cifrado, Confidencialidad, Integridad, No repudio
28. Búsqueda por metadata • Metadata por tipo de documento • Atributos de metadata deben ser dinámicos • N documentos por N atributos de metadata • Millardos de documentos (do the math!) • Velocidad de consulta (2 segundos máximo)
29. Solución
30. Almacenamiento • NetApp StorageGRID Webscale • Appliance de “fácil” configuración • Soporta Amazon S3, Swift y CDMI • Se usó Amazon S3. • Políticas de replicación
31. Retos de almacenamiento • Millardos de documentos pequeños (~4K) • Capacidad de ingestar 5 millones de documentos por hora • Latencia de red • Procesos, Verificación de integridad, cifrado, etc. • Velocidad de recuperación
32. Búsqueda de metadata
34. You know, for search…
35. Features • Real-Time Data. Yo (Domingo) digo que es cercano a Real-Time Data. • Massivamente Distribuido • Alta Disponibilidad • Full-Text Search • Document-Oriented • Schema-Free • Developer-Friendly, RESTful API • Extensible via plugins
36. Conceptos • Cluster • Node • Index • Shard & Replica • Type(s) • Mapping • Documents
37. Como se organiza la información en Elasticsearch
38. Nodes & shards
39. Indexing documents
40. Sharding es crucial • Un Shard es un indice fisico de Lucene • Limite de # documentos en un indice de Lucene es de 2 millardos. • Cuando un indice es creado se debe especificar el # de shards, no se puede cambiar después. ¡Cuidado! • ¡No hagan over-sharding del indice! ¡Cuidado!
41. Distributed indexing
42. Shard allocation awareness • Los shards pueden ubicarse en nodos diferentes • Con metadata a nivel nodo podemos indicar a Elasticsearch que el nodo vive en cierto “rack” del data center • Con mas metadata podemos indicarle que el nodo vive en cierto data center • Con la combinación correcta, la replicación no compromete la integridad de los datos
43. Elasticsearch setup • 2 Centros de datos. Geográficamente separados por 700 KM • 24 Nodos • 12 Nodos en cada Centro de datos • 10 Nodos de datos • 2 Nodos cliente • Cada VM • 16 CPUs • 32 GB RAM. 16 GB para Elasticsearch • 700 GB de Storage, para nodos de datos. • Centos 6
44. Cluster de Elasticsearch
45. API REST
46. Microservices • Desarrollados con SpringBoot y Java 8 • Ingesta de documentos • blob del documento y metadata (JSON) • Recuperación directa • Búsqueda basada en criterios (atributos de metadata). ES ~40 milisegundos de respuesta • Spring Cloud. Hystrix, Eureka, RxJava de Netflix • Escalar horizontal bajo demanda
47. Lecciones aprendidas • Monitoreo de la infraestructura es elemental • VMs, Microservicios, Salud cluster de ES • Análisis muy detallado de los requerimientos de atributos metadata • Hizo falta involucrar un experto en gestión de documentos y archivos. • Falta de recursos con conocimientos de Elasticsearch. Evangelización dentro del banco. • Los bancos pueden adoptar nuevas tecnologías si se comunican eficientemente los beneficios.
48. ¡Es divertido trabajar desde un data center!
49. Ya eres parte de la evolución Liquid Day ¿Preguntas? @domix domingo.suarez@gmail.com http://domingosuarez.com http://www.slideshare.net/domingo.suarez http://bit.ly/coderdog