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.

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