Tamaño Óptimo de Fragmentos: Equilibrando el Rendimiento y la Gestión del Clúster

El tamaño de los fragmentos es una de esas decisiones en Elasticsearch que parece simple hasta que el clúster ha estado funcionando durante unos meses. Un fragmento es solo un índice de Lucene internamente, pero cada fragmento tiene sobrecarga. Demasiados fragmentos pequeños hacen que el clúster esté ocupado gestionando metadatos y objetivos de búsqueda diminutos. Muy pocos fragmentos grandes hacen que la reubicación, la recuperación y algunas búsquedas sean dolorosamente lentas.

No existe un tamaño de fragmento universal que funcione para todos los clústeres. Un clúster de registro con rotación diaria, un índice de búsqueda de productos y un clúster de análisis de seguridad se comportan de manera diferente. El enfoque útil es elegir un tamaño de fragmento objetivo, diseñar la rotación o creación de índices en torno a él, y luego ajustar según el comportamiento real de indexación y consulta.

Fundamentos de los Fragmentos en Elasticsearch

Antes de profundizar en las estrategias de tamaño, es esencial comprender los conceptos básicos:

• Índice: Una colección de documentos. En Elasticsearch, un índice se divide en múltiples fragmentos.
• Fragmento: Una unidad de distribución. Cada fragmento es un índice de Lucene independiente. Un índice puede contener múltiples fragmentos, distribuidos en diferentes nodos del clúster.
• Fragmento Primario: Cuando se crea un índice, se le asigna un número de fragmentos primarios. Estos fragmentos son donde se indexan tus datos. No puedes simplemente editar number_of_shards en un índice existente, pero Elasticsearch proporciona operaciones de división y reducción en condiciones específicas. Muchos equipos aún consideran el número de fragmentos primarios como una decisión de diseño porque cambiarlo más tarde requiere planificación.
• Fragmento Réplica: Copias de tus fragmentos primarios. Proporcionan redundancia y aumentan el rendimiento de lectura. Si un fragmento primario falla, una réplica puede ser promovida para convertirse en el primario. El número de fragmentos réplica se puede cambiar en cualquier momento.

Cómo Afectan los Fragmentos al Rendimiento

• Rendimiento de Indexación: Cada fragmento requiere recursos para la indexación. Más fragmentos significan más sobrecarga para los nodos coordinadores que gestionan las solicitudes. Sin embargo, si los fragmentos se vuelven demasiado grandes, la indexación en un solo fragmento puede convertirse en un cuello de botella.
• Rendimiento de Consultas: Las solicitudes de búsqueda se distribuyen a todos los fragmentos primarios relevantes. Un mayor número de fragmentos puede aumentar la cantidad de solicitudes que deben procesarse, lo que potencialmente aumenta la latencia. Por el contrario, fragmentos muy grandes pueden llevar a tiempos de búsqueda más largos, ya que Lucene tiene que trabajar con más datos dentro de ese fragmento.
• Gestión del Clúster: Una gran cantidad de fragmentos aumenta la carga en el nodo maestro, que es responsable de la gestión del estado del clúster. También impacta la sobrecarga de operaciones como la reubicación de fragmentos, la creación de instantáneas y la recuperación.
• Utilización de Recursos: Cada fragmento consume memoria y E/S de disco. Demasiados fragmentos pueden agotar los recursos del nodo, lo que lleva a un rendimiento degradado o inestabilidad del nodo.

Consideraciones Clave para el Tamaño de los Fragmentos

El tamaño "ideal" del fragmento no es un número fijo; depende de tu carga de trabajo específica, las características de los datos y el hardware. Sin embargo, varios factores deben guiar tus decisiones:

1. Volumen de Datos y Tasa de Crecimiento

• Tamaño Actual de los Datos: ¿Cuántos datos tienes en tu índice en este momento?
• Tasa de Crecimiento: ¿Qué tan rápido están creciendo tus datos? Esto ayuda a predecir los tamaños futuros de los fragmentos.
• Política de Retención de Datos: ¿Eliminarás datos antiguos? Esto impacta el tamaño efectivo de los datos activos.

2. Carga de Indexación

• Tasa de Indexación: ¿Cuántos documentos por segundo estás indexando?
• Tamaño del Documento: ¿Qué tan grandes son los documentos individuales en promedio?
• Rendimiento de Indexación: ¿Pueden tus nodos manejar la carga de indexación con la configuración actual de fragmentos?

3. Patrones de Consulta

• Complejidad de la Consulta: ¿Son tus consultas simples búsquedas de palabras clave o agregaciones complejas?
• Frecuencia de Consulta: ¿Con qué frecuencia se ejecutan consultas contra tus datos?
• Requisitos de Latencia de Consulta: ¿Cuáles son tus tiempos de respuesta aceptables?

4. Topología del Clúster y Recursos

• Número de Nodos: ¿Cuántos nodos hay en tu clúster?
• Hardware del Nodo: CPU, RAM y disco (se recomienda encarecidamente SSD para Elasticsearch).
• Límites de Fragmentos: Elasticsearch incluye límites de seguridad que evitan que un nodo tenga un número excesivo de fragmentos abiertos. Las versiones recientes comúnmente usan cluster.max_shards_per_node como la barrera de seguridad a nivel de clúster para índices abiertos normales. cluster.routing.allocation.total_shards_per_node es diferente: limita cuántos fragmentos de un solo índice, o ámbito de asignación coincidente, pueden asignarse a un nodo. Verifica tu versión de Elasticsearch antes de cambiar cualquiera de estas configuraciones.

Mejores Prácticas para la Asignación de Fragmentos

1. Apunta a un Tamaño de Fragmento Objetivo

Aunque no hay un número mágico, muchos clústeres de producción apuntan a fragmentos de alrededor de 10GB a 50GB para cargas de trabajo comunes de registro y búsqueda. Ese rango es un punto de partida, no una regla. Los sistemas de muy alto rendimiento o retención prolongada pueden elegir fragmentos más grandes después de las pruebas; los índices de búsqueda de pequeñas empresas pueden funcionar mejor con un solo fragmento pequeño.

• Demasiado pequeño (< 10GB): Puede llevar a una sobrecarga excesiva. Cada fragmento tiene una huella de memoria y contribuye a la carga del nodo maestro. Gestionar miles de fragmentos diminutos se convierte en una carga operativa significativa.
• Demasiado grande (> 50GB): Puede causar problemas de rendimiento. La fusión de segmentos, la recuperación y las operaciones de reequilibrio toman más tiempo. Si un fragmento grande falla, puede llevar una cantidad considerable de tiempo recuperarlo.

2. Considera Índices Basados en el Tiempo

Para datos de series temporales (registros, métricas, eventos), usar índices basados en el tiempo es una práctica estándar y altamente efectiva. Esto implica crear nuevos índices para períodos de tiempo específicos (por ejemplo, diario, semanal, mensual).

• Ejemplo: En lugar de un índice masivo, podrías tener logs-2023.10.26, logs-2023.10.27, etc.
• Beneficios: Gestión de datos más fácil (eliminación de índices antiguos mediante la Gestión del Ciclo de Vida de Índices - ILM), mejor rendimiento ya que las consultas a menudo se dirigen a datos recientes y tamaños de fragmentos controlados.

3. Implementa la Gestión del Ciclo de Vida de Índices (ILM)

Las políticas de ILM te permiten automatizar la gestión de índices según la edad, el tamaño o el recuento de documentos. Puedes definir fases para un índice (caliente, cálido, frío, eliminar) y especificar acciones para cada fase, incluido cambiar el número de réplicas, reducir índices o eliminarlos.

• Fase Caliente: El índice se está escribiendo y consultando activamente. Maximiza el rendimiento.
• Fase Cálida: El índice ya no se escribe pero aún se consulta. Se puede mover a hardware menos potente, potencialmente con menos réplicas o reducido.
• Fase Fría: Consultas poco frecuentes. Los datos se pueden mover a almacenamiento más barato o nodos de menor rendimiento, dependiendo de tu licencia, versión y arquitectura de Elasticsearch.
• Fase de Eliminación: Los datos ya no son necesarios y se eliminan.

4. Evita la Sobre-Fragmentación

La sobre-fragmentación ocurre cuando tienes demasiados fragmentos para el tamaño de tu clúster y volumen de datos. Este es un error común que conduce a un rendimiento deficiente y problemas de gestión.

• Síntomas: Alto uso de CPU en los nodos maestros, actualizaciones lentas del estado del clúster, tiempos de recuperación largos y lentitud general.
• Mitigación: Planifica el número de fragmentos primarios desde el principio. Para índices basados en el tiempo, comienza con un número razonable de fragmentos primarios por índice (por ejemplo, 1 o 3). Siempre puedes agregar réplicas más tarde.

5. No Sobrecargues de Índices

De manera similar, evita crear un número excesivo de índices cuando no sea necesario. Cada índice agrega sobrecarga. Para datos que no son de series temporales y donde no tienes un mecanismo de partición natural, considera si un solo índice con un número adecuado de fragmentos es suficiente.

6. Considera la Configuración number_of_shards

Al crear un índice, el parámetro number_of_shards define el número de fragmentos primarios. Esta configuración es inmutable después de la creación del índice.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // Ejemplo: 3 fragmentos primarios
      "number_of_replicas": 1   // Ejemplo: 1 fragmento réplica
    }
  }
}

• Consejo: Para índices más pequeños o aquellos con carga de indexación/consulta muy baja, un solo fragmento primario podría ser suficiente. Para índices más grandes y activos, 3 o 5 fragmentos primarios pueden ofrecer mejor distribución y resiliencia, especialmente si planeas dividir el índice más tarde (aunque la división es compleja).

7. Reequilibrio y Reubicación

Elasticsearch reequilibra automáticamente los fragmentos para garantizar una distribución uniforme entre los nodos. Sin embargo, si los fragmentos son demasiado grandes, estas operaciones pueden consumir muchos recursos y ser lentas. Fragmentos más pequeños y numerosos a veces pueden reequilibrarse más rápido, pero esto se contrarresta con la sobrecarga de gestionar más fragmentos.

8. Ajuste del Rendimiento de Consultas

Si el rendimiento de tus consultas se resiente, evalúa tu estrategia de fragmentos. Considera:

• Número de Fragmentos: Demasiados fragmentos pueden aumentar la sobrecarga de coordinación.
• Tamaño del Fragmento: Fragmentos muy grandes pueden ralentizar la fusión de segmentos y la búsqueda dentro del fragmento.
• Diseño del Índice: ¿Estás utilizando mapeos y analizadores apropiados?

Calculando tu Número Óptimo de Fragmentos

No hay una fórmula única, pero aquí hay un enfoque común:

1. Estima tu volumen total de datos por índice durante su ciclo de vida.
2. Determina tu tamaño de fragmento objetivo (por ejemplo, 30GB).
3. Calcula el número de fragmentos primarios necesarios: Volumen Total de Datos / Tamaño del Fragmento Objetivo.
4. Redondea hacia arriba al número entero más cercano. Esto te da tu number_of_shards para el índice.
   • Ejemplo: Si esperas 90GB de datos y apuntas a fragmentos de 30GB, necesitarías 90GB / 30GB = 3 fragmentos primarios.
5. Considera la resiliencia y la distribución: Para índices críticos, considera usar 3 o 5 fragmentos primarios para permitir una mejor distribución y opciones de recuperación, incluso si tu volumen de datos inicial no lo requiere estrictamente. La compensación es una mayor sobrecarga.
6. Comienza de manera conservadora: Generalmente es más fácil agregar réplicas que cambiar el número de fragmentos primarios (lo que generalmente requiere reindexación o soluciones complejas). Si no estás seguro, comienza con menos fragmentos primarios y monitorea el rendimiento.

Escenario de Ejemplo: Análisis de Registros

Supongamos que estás indexando registros de aplicación:

• Volumen de Datos: Esperas 1TB de registros por mes.

• Retención de Datos: Mantienes los registros durante 30 días.

• Tamaño de Fragmento Objetivo: Apuntas a 20GB.

• Índices Diarios: Creas índices diarios (logstash-YYYY.MM.DD). Cada índice diario contendrá aproximadamente 1TB / 30 días ≈ 33GB de datos.

• Fragmentos Primarios por Índice: Dado el objetivo de 20GB y el volumen diario de 33GB, podrías elegir 2 fragmentos primarios por índice (33GB / 20GB ≈ 1.65, redondeado a 2). Esto asegura que los fragmentos individuales se mantengan dentro de tu tamaño objetivo.

• Réplicas: Decides 1 réplica para alta disponibilidad.

• Fragmentos Totales: Durante el período de retención de 30 días, tendrás 30 índices, cada uno con 2 fragmentos primarios y 2 réplicas, totalizando 60 fragmentos primarios y 60 réplicas activos en cualquier momento.

Este enfoque mantiene los fragmentos individuales manejables y permite una eliminación eficiente de datos simplemente eliminando índices antiguos.

Lo que Suele Salir Mal

El problema más común es la sobre-fragmentación por costumbre. Alguien crea índices diarios con cinco primarios y una réplica porque un tutorial antiguo usaba esa configuración. Parece inofensivo al principio. Luego el clúster tiene cientos de índices pequeños, miles de fragmentos diminutos y los nodos maestros pasan demasiado tiempo en actualizaciones del estado del clúster. Las búsquedas también se distribuyen entre muchos fragmentos, lo que agrega sobrecarga de coordinación antes de que comience el trabajo de consulta real.

El problema opuesto se manifiesta durante la recuperación. Unos pocos fragmentos enormes pueden consultar aceptablemente en un día normal, pero cuando un nodo falla o comienza un reinicio gradual, la reubicación lleva mucho tiempo. Las instantáneas y restauraciones también pueden volverse más lentas porque cada fragmento es una unidad de trabajo grande. Si tu objetivo de recuperación es ajustado, el tamaño del fragmento importa incluso cuando la latencia de consulta parece buena.

Los fragmentos calientes son otro problema práctico. Si todas las nuevas escrituras van a un fragmento primario, agregar más nodos no distribuirá automáticamente esa carga de escritura. La rotación basada en el tiempo ayuda porque los nuevos índices pueden dimensionarse para el patrón de tráfico actual. Las elecciones de enrutamiento también importan. El enrutamiento personalizado puede ser poderoso, pero una clave de enrutamiento incorrecta puede enviar demasiados datos a un solo fragmento.

Un Mejor Patrón de Rotación

Para datos de series temporales, la rotación basada en el tamaño suele ser más fácil de gestionar que los índices diarios fijos. En lugar de crear un índice por día sin importar qué, creas un alias de escritura y dejas que ILM realice la rotación cuando el índice alcance un tamaño, edad o recuento de documentos objetivo.

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "30gb",
            "max_age": "1d"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Con este patrón, un fin de semana tranquilo podría producir menos índices, mientras que un día de incidente ocupado puede rotar antes. Aún necesitas elegir el número inicial de primarios, pero la rotación evita que el crecimiento de los fragmentos se desvíe demasiado del objetivo.

Cómo Inspeccionar tus Fragmentos Actuales

Antes de cambiar algo, observa el clúster que tienes:

GET _cat/shards?v&h=index,shard,prirep,state,docs,store,node&s=store:desc
GET _cat/indices?v&h=index,pri,rep,docs.count,store.size,pri.store.size&s=pri.store.size:desc
GET _cluster/health

Buscas patrones: muchos fragmentos pequeños, unos pocos fragmentos enormes, fragmentos no asignados, colocación desigual de nodos o índices cuyo tamaño de almacenamiento primario está muy lejos de tu objetivo previsto. Si un índice tiene 100GB de datos primarios y cinco fragmentos primarios, cada primario tiene aproximadamente 20GB antes de las réplicas. Si el mismo índice tiene 100GB y 50 primarios, probablemente creaste una sobrecarga innecesaria.

Notas Finales

Un buen tamaño de fragmento se trata menos de perseguir un número perfecto y más de mantener el clúster fácil de operar. Comienza con un objetivo razonable, usa ILM o rotación donde el patrón de datos se ajuste, y observa lo que realmente sucede con el tamaño del fragmento, la distribución de consultas, el tiempo de recuperación y la presión del nodo. Si tu clúster ya está sobre-fragmentado, arréglalo gradualmente con nuevas plantillas de índice, rotación, reducción o reindexación, en lugar de intentar forzar cada índice antiguo a una nueva forma de una vez.