Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SGNext Elasticsearch

911 views

Published on

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.

Published in: Technology

SGNext Elasticsearch

  1. 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. 2. Agenda • Storage • Alternativas • Caso de estudio • Lecciones aprendidas
  3. 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. 4. storage
  5. 5. https://www.domo.com/blog/2015/08/data-never-sleeps-3-0/
  6. 6. https://www.domo.com/blog/2016/06/data-never-sleeps-4-0/
  7. 7. 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
  8. 8. 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
  9. 9. Cloud Storage
  10. 10. REST API propietario
  11. 11. Storage REST APIs • Amazon S3 • OpenStack Swift • CDMI (Cloud Data Management Interface) • By Storage Network Industry Association (SNIA) • Propietarias como Azure <- NO recomendado
  12. 12. ¿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)
  13. 13. Opciones en Appliances
  14. 14. 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.
  15. 15. Cuando usar un appliance • Tienes presupuesto • Tienes un centro de datos dedicado • Usas Colocation • Administras información restringida por las leyes locales/federales
  16. 16. 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
  17. 17. 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)
  18. 18. 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.
  19. 19. 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
  20. 20. 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)
  21. 21. Solución
  22. 22. 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
  23. 23. 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
  24. 24. Búsqueda de metadata
  25. 25. You know, for search…
  26. 26. 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
  27. 27. Conceptos • Cluster • Node • Index • Shard & Replica • Type(s) • Mapping • Documents
  28. 28. Como se organiza la información en Elasticsearch
  29. 29. Nodes & shards
  30. 30. Indexing documents
  31. 31. 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!
  32. 32. Distributed indexing
  33. 33. 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
  34. 34. 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
  35. 35. Cluster de Elasticsearch
  36. 36. API REST
  37. 37. 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
  38. 38. 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.
  39. 39. ¡Es divertido trabajar desde un data center!
  40. 40. 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

×