Guía de dimensionamiento de shards de Elasticsearch: Equilibrio entre rendimiento y escalabilidad

Elasticsearch es un potente motor distribuido de búsqueda y análisis que destaca por manejar volúmenes masivos de datos. Sin embargo, lograr un rendimiento y una estabilidad óptimos depende significativamente de cómo estructure la distribución de sus datos, específicamente, del dimensionamiento de los shards. Los shards son los bloques de construcción fundamentales de los índices de Elasticsearch; determinan cómo se particiona, replica y distribuye la data a través de los nodos del clúster. Un dimensionamiento incorrecto de los shards puede conducir a graves cuellos de botella en el rendimiento, un aumento de la sobrecarga operativa o, por el contrario, a recursos subutilizados.

Esta guía proporciona un marco práctico para determinar el tamaño óptimo de los shards en su clúster de Elasticsearch. Exploraremos las compensaciones críticas entre el rendimiento de las consultas, el rendimiento de la indexación, la resiliencia del clúster y el consumo de recursos para ayudarle a encontrar el equilibrio perfecto para su carga de trabajo específica.

Entendiendo los Shards de Elasticsearch

Antes de sumergirnos en el dimensionamiento, es esencial comprender qué es un shard y cómo funciona dentro de la arquitectura del clúster. Un índice en Elasticsearch se compone de uno o más shards primarios. Cada shard primario es un índice independiente basado en Lucene que puede alojar datos.

Shards Primarios vs. de Réplica

Shards Primarios: Estos contienen los datos reales. Son responsables de las operaciones de indexación y búsqueda. Cuando usted define el número de shards primarios para un índice, decide cómo se distribuirán los datos horizontalmente a través del clúster.
Shards de Réplica: Son copias de los shards primarios. Proporcionan redundancia (tolerancia a fallos) y aumentan el rendimiento de la búsqueda al permitir que las consultas sean atendidas tanto por las copias primarias como por las de réplica.

El Impacto del Conteo de Shards

El número total de shards (Primarios + Réplicas) afecta directamente la sobrecarga del clúster. Cada shard requiere memoria (espacio de heap) y recursos de CPU para rastrear su estado y metadatos. Demasiados shards pequeños abruman el nodo maestro y aumentan la sobrecarga de gestión del clúster, lo que lleva a la degradación del rendimiento, incluso si los shards individuales son pequeños.

Restricciones Clave y Recomendaciones de Dimensionamiento

No existe un "número mágico" único para el tamaño del shard. El tamaño óptimo depende en gran medida del volumen de sus datos, la tasa de indexación y los patrones de consulta. Sin embargo, la documentación de Elasticsearch y las mejores prácticas de la comunidad ofrecen varias pautas cruciales.

1. Umbral de Tamaño: El Tamaño Óptimo del Shard

El factor más crítico es el tamaño de los datos contenidos dentro de un solo shard.

Tamaño Máximo Recomendado: El consenso general y la mejor práctica sugieren mantener los shards primarios individuales entre 10 GB y 50 GB.
Máximo Absoluto: Si bien es técnicamente posible, se recomienda encarecidamente no exceder los 100 GB por shard, ya que dificulta las operaciones de recuperación, el rendimiento de la indexación y la estabilidad del clúster.

¿Por qué el límite? Si un nodo falla, Elasticsearch debe reasignar (reubicar o volver a replicar) los shards almacenados en ese nodo. Los shards grandes aumentan significativamente el tiempo requerido para la recuperación, incrementando la ventana de resiliencia reducida. Además, Lucene funciona mejor cuando gestiona segmentos de tamaño medio.

2. Umbral de Conteo de Documentos

Si bien el tamaño es primordial, el conteo de documentos también es relevante, especialmente para documentos muy pequeños.

Rango de Documentos Recomendado: Apunte a shards que contengan entre 100.000 y 5 millones de documentos.

Si sus documentos son extremadamente pequeños (p. ej., unos pocos cientos de bytes), podría alcanzar el límite de tamaño (50 GB) antes de alcanzar la recomendación de conteo de documentos. Por el contrario, si los documentos son muy grandes (p. ej., blobs JSON de varios megabytes), podría alcanzar rápidamente el límite de conteo de documentos mientras se mantiene por debajo del límite de tamaño.

3. Sobrecarga del Clúster y Conteo de Shards

Limite el número total de shards por nodo para gestionar eficazmente el consumo de recursos.

Shards por GB de Heap: Una pauta común sugiere mantener el número total de shards (primarios + réplicas) de modo que el clúster utilice aproximadamente 20 shards por cada 1 GB de espacio de heap asignado a los nodos de datos.

Ejemplo de Cálculo: Si sus nodos de datos tienen asignados 30 GB de heap:

$$30 \text{ GB} \times 20 \text{ shards/GB} = 600 \text{ shards totales}$$

Si necesita 100 shards primarios para un índice, debe asegurarse de que el clúster tenga suficientes nodos para mantener la sobrecarga total manejable de acuerdo con esta proporción.

Metodología Práctica de Dimensionamiento de Shards

Utilice los siguientes pasos para calcular el número apropiado de shards primarios para un nuevo índice basándose en el tamaño total de datos esperado.

Paso 1: Estime el Tamaño Total del Índice

Determine la cantidad total de datos que espera que este índice almacene durante su vida útil operativa (p. ej., 6 meses o 1 año).

Ejemplo: Anticipamos almacenar 2 TB de datos para nuestro índice logs-2024.

Paso 2: Defina el Tamaño Objetivo del Shard

Seleccione un tamaño objetivo seguro basado en las pautas (p. ej., 40 GB).

Ejemplo: Tamaño objetivo del shard = 40 GB.

Paso 3: Calcule los Shards Primarios Requeridos

Divida el tamaño total estimado por el tamaño objetivo del shard. Siempre redondee al número entero más cercano.

$$\text{Shards Primarios} = \text{Techo} \left( \frac{\text{Tamaño Total del Índice}}{\text{Tamaño Objetivo del Shard}} \right)$$

Ejemplo de Cálculo (2 TB = 2048 GB):
$$\text{Shards Primarios} = \text{Techo} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{Techo}(51.2) = 52$$

En este escenario, debe crear el índice con 52 shards primarios.

Paso 4: Determine el Conteo de Réplicas

Decida el conteo de réplicas en función de sus necesidades de resiliencia y volumen de búsqueda.

Resiliencia: Establezca number_of_replicas en al menos 1 (para alta disponibilidad).
Rendimiento de Búsqueda: Si el tráfico de búsqueda es intenso, use 2 o más réplicas.
Ejemplo: Elegimos 1 réplica para la tolerancia a fallos estándar.

Configuración Final del Índice: 52 shards primarios y 1 réplica (un total de 104 shards).

Paso 5: Distribución a Través de los Nodos

Asegúrese de que su clúster tenga suficientes nodos (y suficiente espacio de heap) para alojar estos shards de manera efectiva, manteniendo la regla de 20 shards/GB de heap.

Gestión del Ciclo de Vida del Índice y Redimensionamiento

Elasticsearch no admite cambiar el tamaño del número de shards primarios en un índice existente y no vacío. Esta es una limitación crítica para recordar durante el diseño inicial.

El Papel de la Gestión del Ciclo de Vida del Índice (ILM)

Para los datos de series de tiempo (logs, métricas), la mejor práctica es aprovechar la Gestión del Ciclo de Vida del Índice (ILM) y la función Rollover (rotación).

En lugar de crear un único índice masivo y difícil de gestionar, cree un alias de rotación (rollover alias) que apunte a una plantilla.

Fase Caliente (Hot Phase): Los datos se escriben en el índice activo actual. ILM monitorea este índice basándose en el tamaño o la antigüedad (p. ej., rotar cuando alcanza los 40 GB).
Rotación (Rollover): Cuando se alcanza el umbral, Elasticsearch crea automáticamente un nuevo índice basado en la plantilla (con el número calculado de shards primarios) y cambia el alias para que apunte al nuevo índice. El índice antiguo pasa a una fase diferente (Cálida/Fría - Warm/Cold).

Este enfoque le permite mantener shards de tamaño constante y rendimiento óptimo a lo largo del ciclo de vida de sus datos.

Cuando es Necesario Re-sharding (Avanzado)

Si un índice existente crece mucho más allá de la recomendación de 50 GB debido a patrones de datos imprevistos, debe emplear la API Reindex para solucionar la distribución de shards:

Cree un nuevo índice con la configuración de shards corregida (óptima).
Utilice la API Reindex para copiar todos los datos del índice antiguo y mal dimensionado en el nuevo.
Actualice los alias para que apunten al nuevo índice.
Elimine el índice antiguo.

Advertencia sobre la Reindexación: La reindexación es una operación que consume muchos recursos. Debe programarse durante períodos de bajo tráfico y requiere suficientes recursos del clúster para manejar la carga simultánea de indexación y copia.

Resumen de Mejores Prácticas

Área	Mejor Práctica / Pauta
Tamaño de Shard Individual	Mantenga los shards primarios entre 10 GB y 50 GB (máx. 100 GB).
Conteo de Documentos	Apunte a 100k a 5M de documentos por shard (secundario al tamaño).
Sobrecarga del Clúster	Limite el total de shards (primario + réplica) a aproximadamente 20 shards por cada 1 GB de heap en los nodos de datos.
Gestión de Índices	Utilice la Gestión del Ciclo de Vida del Índice (ILM) y la Rotación (Rollover) para datos de series de tiempo para garantizar un dimensionamiento óptimo continuo.
Redimensionamiento	No intente cambiar el conteo de shards primarios en índices en vivo; use la API Reindex para migrar datos a un nuevo índice dimensionado correctamente.

Al adherirse a estas pautas de tamaño y utilizar ILM para la gestión continua, puede asegurarse de que su clúster de Elasticsearch se mantenga eficiente, escalable y resiliente contra fallos operativos.