Estrategias de ahorro de costos para Elasticsearch Service: Eficiencia de almacenamiento de datos

Miles de clientes consideran Elasticsearch Service (ESS) en Elastic Cloud como su hogar donde pueden ejecutar no solo Elasticsearch, sino productos exclusivos como Elastic Logs, Elastic APM, Elastic SIEM y más. Con más de siete años de experiencia operativa, ESS es el único servicio administrado que proporciona la experiencia de Elasticsearch completa con todas las características y soluciones, y soporte de la fuente; así como varios beneficios operativos y de despliegue que complementan estos productos.

En un blog anterior, explicamos el costo oculto de red al usar una solución SaaS que no se encuentra en la misma región que tus servicios, infraestructura o dispositivos de logging, lo que puede resultar en tarifas importantes. En este blog, destacaremos cómo Elasticsearch Service en Elastic Cloud te brinda la flexibilidad de elegir varias estrategias para mantener los costos bajo control a medida que se expanden tus cargas de trabajo.

Con cualquier crecimiento, en especial en los espacios de observabilidad y seguridad, aumenta la infraestructura necesaria para almacenar y analizar logs, métricas, rastreos de APM y eventos de seguridad generados por tus aplicaciones, lo que conlleva costos adicionales. ESS ofrece varias formas para ayudarte a administrar los datos para controlar los costos y retener los datos significativos por períodos más prolongados; además de que proporciona las mismas capacidades útiles del Elastic Stack: consolidación de datos de varias fuentes, opciones de visualización, alertas, detección de anomalías y más.

Revisaremos las oportunidades de ahorro de costos disponibles para los datos temporales como los casos de uso de observabilidad y seguridad. A modo de ejemplo, veremos una de las aplicaciones más comunes para la cual se usa el Elastic Stack: monitoreo de infraestructuras. El Elastic Stack incluye Beats, una recopilación de agentes ligeros que reside en los clientes y envía datos al cluster. Los equipos usan mucho Metricbeat para enviar métricas del sistema como uso de CPU, IOPS de disco o telemetría de contenedores de las aplicaciones que se ejecutan en Kubernetes.

A medida que expandes tu huella de aplicaciones, las necesidades de monitoreo exigirán más almacenamiento para alojar las métricas que se generan. Definir un período de retención es una estrategia que los equipos usan actualmente para administrar datos temporales a escala. Exploraremos opciones adicionales de eficiencia de almacenamiento disponibles y listas para usar con ESS actualmente.

Situación

Por motivos de continuidad, sumerjámonos en estrategias de ahorro de costos para un cluster que monitorea 1000 hosts en donde cada agente recopila 100 bytes por métrica y 100 métricas cada 10 segundos, con un período de retención de datos de 30 días. También almacenaremos una réplica de los datos en el cluster para alta disponibilidad, lo que evita la pérdida de datos en caso de una falla del nodo. Hagamos las cuentas para calcular cuánto almacenamiento necesitaremos:

Eso resulta en un requisito de almacenamiento de 5.2 TB para esas métricas. Por una cuestión de simplicidad, ignoraremos las exigencias de almacenamiento para funcionar del cluster de Elasticsearch.

En resumen:

Almacenamiento más eficiente con despliegues calientes-tibios y gestión de ciclo de vida del índice

En los casos de uso de observabilidad como logging y métricas, la utilidad de los datos disminuye con el tiempo. Por lo general, los equipos aprovechan los datos recientes para investigar con rapidez incidentes en el sistema, aumentos repentinos en el tráfico de red o alertas de seguridad. A medida que aumenta la antigüedad de los datos, estos se buscan con menor frecuencia, pero aún residen en el cluster y utilizan los mismos recursos informáticos, de memoria y almacenamiento que el resto del cluster. Esto resulta en dos patrones de acceso a los datos muy distintos, pero el cluster solo está optimizado para la ingesta rápida y la búsqueda frecuente, no para el almacenamiento de datos a los que se accede con poca frecuencia.

Aquí es donde entran las arquitecturas calientes-tibias en Elasticsearch Service. Esta opción de despliegue proporciona dos perfiles de hardware en el mismo cluster de Elasticsearch. Los nodos calientes se ocupan de todos los datos nuevos que ingresan y cuentan con un almacenamiento más rápido para asegurar que puedan ingestar y recuperar datos rápidamente. Los nodos tibios cuentan con una densidad de almacenamiento mayor y son más rentables para el almacenamiento de datos por períodos de retención mayores.

En Elasticsearch Service, generalmente provisionamos SSD NVMe con conexión local en una proporción RAM-disco de 1:30 para los nodos calientes y HDD de alta densidad en una proporción de 1:160 para los nodos tibios. Esta arquitectura poderosa viene acompañada de otra característica importante: gestión de ciclo de vida del índice (ILM). La característica ILM proporciona los medios para automatizar la gestión del índice en el tiempo, lo que simplifica el movimiento de los datos desde los nodos calientes hasta los tibios según ciertos criterios como tamaño del índice, cantidad de documentos o antigüedad del índice.

Con estas dos características juntas en funcionamiento, obtienes dos perfiles de hardware distintos en tu cluster, y las herramientas de automatización del índice para mover los datos entre los niveles.

Ahora pasemos a un despliegue caliente-tibio y configuremos las políticas de ILM. En ESS, puedes crear un despliegue caliente-tibio nuevo y restaurar opcionalmente un snapshot de otro cluster. Si ya tienes un despliegue de E/S alta, puedes simplemente migrar a un despliegue caliente-tibio agregando nodos tibios a tu cluster. Usaremos una política de ILM para mantener los datos en el nivel caliente durante siete días y después moverlos a los nodos tibios.

Internamente, cuando se mueven los datos a la fase tibia, ya no se puede escribir en los índices. Esto nos brinda otra oportunidad para ahorrar costos dado que podemos elegir no almacenar ningún dato de réplica en los nodos tibios. En caso de falla de un nodo tibio, restauraríamos desde el snapshot más reciente que se tomó y no desde las réplicas.

La desventaja de este enfoque es que la restauración desde un snapshot suele ser más lenta y puede aumentar el tiempo de resolución después de la falla. Sin embargo, puede ser aceptable en muchos casos debido a que los nodos tibios suelen contener menos datos de búsqueda frecuente, lo que disminuye el impacto en el mundo real.

Por último, eliminaremos los datos cuando cumplan 30 días de antigüedad para alinearnos con la política de retención original. Con un cálculo similar al anterior, aquí hay un resumen de este enfoque:

Con este enfoque se ahorra un notable 60 % en los costos mensuales mientras se mantienen datos resistentes que se pueden buscar. Puedes ajustar las políticas de ILM para encontrar períodos de desplazamiento ideales que ayuden a maximizar el uso del almacenamiento en nodos tibios.

Liberación de más espacio de almacenamiento con data rollups

Otra opción de ahorro de almacenamiento para tener en cuenta es data rollups. Al realizar un "rollup" de los datos en un solo documento de resumen en Elasticsearch, las API de rollup te permiten resumir los datos y almacenarlos de forma más compacta. Después puedes archivar o eliminar los datos originales para obtener espacio de almacenamiento.

Cuando creas un rollup, puedes elegir todos los campos que te interesan para análisis futuro y se crea un índice nuevo con solo esos datos en el rollup. Es particularmente útil para monitorear casos de uso que se ocupan principalmente de datos numéricos que se pueden resumir con facilidad a mayor granularidad (como a nivel de minuto, hora o incluso día) y seguir mostrando tendencias en el tiempo. Los índices resumidos están disponibles a través de Kibana y pueden agregarse fácilmente junto a los dashboards existentes para evitar interrupciones en cualquier esfuerzo de análisis. Todo esto se puede configurar directamente en Kibana.

Siguiendo con la situación anterior, recuerda que necesitábamos 5.2 TB de espacio de almacenamiento para los datos de métricas de 30 días de 1000 hosts, incluido un conjunto de réplica para asegurar la disponibilidad. Luego describimos una situación con una plantilla de despliegue caliente-tibia. Ahora usaremos la API de data rollup para configurar un trabajo de rollup para ejecutar cuando los datos tengan siete días de antigüedad, sacrificar un poco menos de granularidad y obtener mucho más almacenamiento gratuito.

Configuremos el trabajo de data rollup para realizar el rollup de los datos de métricas de 10 segundos en documentos resumidos por hora. Esto nos seguirá permitiendo buscar y visualizar métricas antiguas en intervalos de una hora, lo que se puede usar en visualizaciones de Kibana y Lens para revelar tendencias y otros momentos clave de los datos. A continuación, eliminaremos los documentos originales a los que acabamos de realizar el rollup y liberaremos una gran cantidad de almacenamiento en el cluster. Si hacemos el cálculo, podemos ver cuánto almacenamiento se necesita para los datos a los que acabamos de realizar el rollup.

Los datos originales de estos documentos de rollup tenían más de siete días, por lo que estaban almacenados en nodos tibios en nuestro cluster caliente-tibio. La totalidad de esos 1.99 TB de datos puede simplemente eliminarse. La columna de la derecha muestra nuestra situación actual:

La diferencia de ahorro de costos es drástica. Cuando agregamos data rollups a nuestro cluster caliente-tibio existente, podemos lograr una reducción del 31 % en los costos. Los resultados se amplifican incluso más cuando comparamos nuestra situación final con un cluster tradicional de un solo nivel de hardware y ahorramos el 73 %.

Despliega a tu manera

Cada método tiene sus beneficios y compensaciones. Tienes la flexibilidad de ajustar cada estrategia para que se adapte lo mejor posible a tus necesidades.

Las políticas de ILM te permiten definir los períodos de desplazamiento según el tamaño del índice, la cantidad de documentos o la antigüedad de los documentos, lo que mueve los datos a nodos tibios en tu cluster caliente-tibio. Los nodos tibios pueden compactar mucho almacenamiento de forma eficiente, lo cual te ayuda a gastar menos en costos informáticos. Es posible que el tiempo de búsqueda no sea tan eficiente como en los nodos calientes, por lo que se prefiere este enfoque para datos que no son de búsqueda frecuente.

Los data rollups resumen los datos en documentos menos granulares que resultan útiles si los datos tienen una antigüedad en la cual no se requiere la granularidad de bajo nivel original. Después se pueden eliminar los documentos fuente para ayudarte a ahorrar en costos de almacenamiento. Puedes definir qué tanto deseas resumir los documentos y cuándo hacerlo. Encuentra el equilibrio adecuado para que los datos en el rollup sigan proporcionándote información clave como las tendencias en el tiempo o el comportamiento del sistema en un aumento de tráfico.

Ahora que estás familiarizado con nuestras estrategias listas para usar de optimización de cargas de trabajo de métricas en tu cluster de Elasticsearch, ¿qué deberías hacer con todo ese espacio de almacenamiento adicional? El Elastic Stack se usa en todo el mundo para múltiples casos de uso: logs, rastreos de APM, eventos de auditoría, datos de endpoint y más.

Elasticsearch Service en Elastic Cloud proporciona todo lo que el Elastic Stack tiene para ofrecer junto con la experiencia operativa de los creadores. Si no estás listo para expandirte a casos de uso nuevos, puedes continuar poniendo tu cluster a trabajar aprovechando la optimización de almacenamiento. Expande el tiempo de retención de datos y almacena incluso más a un punto de precio similar o reduce el tamaño del cluster con solo unos clics sin tener que comprometer la visibilidad y ahorra.

¿Buscas dar los primeros pasos con Elasticsearch Service en Elastic Cloud? Activa una prueba gratuita de 14 días.