Prácticas recomendadas para configurar el dominio de su Amazon Elasticsearch Service

Por Jon Handler, Arquitecto principal de soluciones en Amazon Web Services

Amazon Elasticsearch Service (Amazon ES) es un servicio completamente administrado que facilita la implementación, la seguridad, la escala y el monitoreo de su clúster de Elasticsearch en la nube de AWS. Elasticsearch es una solución de base de datos distribuida, que puede ser difícil de planificar y ejecutar. Esta publicación discute algunas de las prácticas recomendadas para la implementación de los dominios de Amazon ES.

La práctica más importante es la iteración. Si sigue estas prácticas recomendadas, puede planear una implementación básica de Amazon ES. Elasticsearch se comporta de manera distinta para cada carga de trabajo: su latencia y rendimiento están determinados en gran medida por la combinación de solicitudes, las propias solicitudes y los datos o consultas que se ejecutan. No hay ninguna regla determinista que pueda predecir al 100% cómo se comportará su carga de trabajo. Planifique el tiempo para afinar y perfeccionar su implementación, monitorear el comportamiento de su dominio y ajustarlo en consecuencia.

Implementación de Amazon ES

Ya sea que se implemente en la consola de administración de AWS, en AWS CloudFormation, o a través de las API de Amazon ES, dispone de una gran cantidad de opciones para configurar el hardware, la alta disponibilidad y las funciones de seguridad de su dominio. Esta publicación incluye prácticas recomendadas para elegir sus nodos de datos y la configuración de sus nodos maestros dedicados.

Cuando configure su dominio de Amazon ES, elija el tipo de instancia y el conteo para los datos y los nodos maestros dedicados. Elasticsearch es una base de datos distribuida que se ejecuta en un clúster de instancias o nodos. Estos tipos de nodos tienen diferentes funciones y requieren un tamaño diferente. Los nodos de datos almacenan los datos en sus índices y procesan las solicitudes de indexación y consulta. Los nodos maestros dedicados no procesan estas solicitudes; mantienen el estado de clúster y lo coordinan. Esta publicación se centra en los tipos de instancia. Para obtener más información sobre el tamaño de las instancias de los nodos de datos, consulte Introducción a Amazon Elasticsearch Service: calcule el tamaño de su dominio. Para obtener más información sobre el tamaño de las instancias de los nodos maestros dedicados, consulte Introducción con Amazon Elasticsearch Service: usar instancias maestras dedicadas para mejorar la visibilidad de los clústeres.

Amazon ES soporta cinco clases de instancia: M, R, I, C y T. Como práctica recomendada, usa la última generación de tipo de instancia de cada clase de instancia. Al escribir esto, estos son el M5, R5, I3, C5 y T2.

Elegir el tipo de instancia para los nodos de datos

Al elegir un tipo de instancia para sus nodos de datos, tenga en cuenta que estos nodos llevan todos los datos en sus índices (almacenamiento) y hacen todo el procesamiento de sus solicitudes (CPU). Como práctica recomendada, para cargas de trabajo de producción pesadas, elija el tipo de instancia R5 o I3. Si su énfasis está principalmente en el rendimiento, el R5 normalmente ofrece el mejor rendimiento para cargas de trabajo de análisis logístico, y a menudo para cargas de trabajo de búsqueda. Las instancias I3 son fuertes contendientes y pueden adaptarse mejor a su carga de trabajo, así que debería probar ambas. Si su énfasis está en el costo, las instancias I3 tienen una mejor eficiencia de costo a escala, especialmente si elige comprar instancias reservadas.

Para una instancia de entrada o una carga de trabajo menor, elija los M5. Los C5 son una instancia especializada, relevante para los casos de uso de consultas pesadas, que requieren más trabajo de la CPU que el disco o la red. Use las instancias T2 para las cargas de trabajo de desarrollo o de control de calidad, pero no para la producción. Para obtener más información sobre el número de instancias a elegir, y un análisis más profundo del espacio de manejo de datos, consulte Introducción con Amazon Elasticsearch Service: calcule el tamaño de su dominio.

Elegir el tipo de instancia para nodos maestros dedicados

Cuando elija un tipo de instancia para sus nodos maestros dedicados, tenga en cuenta que estos nodos están principalmente ligados a la CPU, con algo de demanda de RAM y de red también. Las instancias de C5 funcionan mejor como maestros dedicados hasta unos 75 clústeres de nodos de datos. Por encima de ese conteo de nodos, debería elegir R5.

Elegir zonas de disponibilidad

Amazon ES facilita el aumento de la disponibilidad de su clúster mediante el uso de la función de Conciencia de la zona. Puede elegir implementar los datos y nodos maestros en una, dos o tres zonas de disponibilidad. Como práctica recomendada, elija tres Zonas de disponibilidad para las implementaciones de producción.

Cuando se elige más de una Zona de disponibilidad, Amazon ES implementa los nodos de datos por igual a través de las zonas y se asegura de que las réplicas vayan a diferentes zonas. Además, cuando se elige más de una Zona de disponibilidad, Amazon ES siempre implementa nodos maestros dedicados en tres zonas (si la Región soporta tres zonas). La implementación en más de una Zona de disponibilidad le da a su dominio más estabilidad y aumenta su disponibilidad.

Índice de Elasticsearch y diseño de partición

Cuando usa Amazon ES, envía los datos a los índices de su clúster. Un índice es como una tabla en una base de datos relacional. Cada documento de búsqueda es como una fila, y cada campo JSON es como una columna.

Amazon ES divide sus datos en particiones, con un hash aleatorio de forma predeterminada. Debe configurar el conteo de particiones, y usar prácticas recomendadas en esta sección.

Patrones de índice

Para los casos de uso de análisis logístico, usted quiere controlar el ciclo de vida de los datos en su clúster. Puede hacer esto con un patrón de índice rodante. Cada día se crea un nuevo índice, luego se archiva y se elimina el índice más antiguo del clúster. Usted define un periodo de retención que controla cuántos días (índices) de datos mantiene en el dominio en función de sus necesidades de análisis. Para obtener más información, consulte Administración del estado de índice.

Establecer el conteo de particiones

Hay dos tipos de particiones: primarias y de réplica. El conteo de particiones primarias define cuántas particiones de datos crea Elasticsearch. El conteo de réplicas especifica cuántas copias adicionales de las particiones primarias crea. Se establece el conteo de particiones primarias en la creación del índice y no se puede cambiar (hay formas, pero no se recomienda usar la API de _shrink o _split para los clústeres bajo carga a escala). También se establece el conteo de la réplica en la creación del índice, pero se puede cambiar la cuenta de la réplica sobre la marcha y Elasticsearch se ajusta en consecuencia creando o eliminando réplicas.

Puede establecer el conteo de particiones primarias y de réplica si crea el índice manualmente, con un comando de POST. Una mejor forma de análisis logístico es establecer una plantilla de índice. Ver el siguiente código:

PUT _template/<template_name>
{
    "index_patterns": ["logs-*"],
    "settings": {
        "number_of_shards": 10,
        "number_of_replicas": 1
    },
    "mappings": {
        …
    }
}

Cuando se establece una plantilla como esta, cada índice que coincide con el index_pattern tiene la configuración y el mapeo (si se especifica uno) aplicado a ese índice. Esto le proporciona una forma conveniente de manejar su estrategia de partición para los índices de rodadura. Si cambia la plantilla, obtendrá un nuevo conteo de particiones en el siguiente ciclo de indexación.

Debe establecer el number_of_shards en función del tamaño de los datos de la fuente, utilizando la siguiente directriz: conteo de particiones primarias = (datos de la fuente diaria en bytes * 1,25) / 50 GB.

Para los casos de uso de búsqueda, en los que no se utilizan índices de rodadura, utilice 30 GB como divisor, apuntando a particiones de 30 GB. Sin embargo, estas son las directrices. Siempre pruebe con sus propios datos, indexación y consultas para encontrar el tamaño óptimo de su partición.

Debería tratar de alinear su partición y los conteos de instancias para que sus particiones se distribuyan equitativamente a través de sus nodos. Lo haces ajustando los conteos de particiones o los conteos de nodos de datos para que sean divisibles por igual. Por ejemplo, la configuración predeterminada de las versiones 6 y posteriores de Elasticsearch son 5 particiones primarias y 1 de réplica (un total de 10 particiones). Puede obtener una distribución uniforme al elegir 2, 5 o 10 nodos de datos. Aunque es importante distribuir la carga de trabajo de manera uniforme en los nodos de datos, no siempre es posible implementar todos los índices por igual. Usar el tamaño de la partición como guía primaria para el conteo de particiones y hacer pequeños ajustes (< 20%), generalmente para favorecer a más instancias o particiones más pequeñas, basados en una distribución uniforme.

Determinar el tamaño del almacenamiento

Hasta ahora, se ha hecho un mapeo de particiones, basado en el almacenamiento necesario. Ahora debe asegurarse de que tiene suficiente almacenamiento y recursos de CPU para procesar sus solicitudes. Primero, encuentre su necesidad general de almacenamiento: almacenamiento necesario = (datos de fuente diaria en bytes * 1,25) * (number_of_replicas + 1) * número de días de retención.

Se multiplica el tamaño del índice no replicado por el número de réplicas y días de retención para determinar el almacenamiento total necesario. Cada réplica agrega una necesidad de almacenamiento adicional igual al tamaño del almacenamiento primario. Agregue esto de nuevo por cada día que quiera retener datos en el clúster. Para los casos de uso de búsqueda, establezca el número de días de retención en 1.

La necesidad de almacenamiento total impulsa un mínimo en el tipo de instancia y la instancia se basa en el máximo de almacenamiento que proporciona esa instancia. Si utiliza instancias respaldadas por EBS como la M5 o la R5, puede implementar volúmenes de EBS hasta el límite admitido. Para obtener más información, consulte Amazon Elasticsearch Service Limits.

En los casos de almacenamiento efímero, el almacenamiento está limitado por el tipo de instancia (por ejemplo, I3.8xlarge.elasticsearch tiene 7,8 TB de almacenamiento adjunto). Si elige EBS, debería usar el tipo de volumen de propósito general, GP2. Aunque el servicio es compatible con el tipo de volumen io1 y las IOPS provisionadas, generalmente no los necesita. Utilice las IOPS provisionadas solo en circunstancias especiales, cuando las métricas lo soporten.

Tome el total de almacenamiento necesario y divídalo por el almacenamiento máximo por instancia de su tipo de instancia elegido para obtener el conteo mínimo de instancias.

Una vez que tenga un tipo de instancia y un conteo, asegúrese de que tiene suficientes vCPU para procesar sus solicitudes. Multiplique el conteo de instancias por los vCPU que esa instancia proporciona. Esto le da un conteo total de vCPU en el clúster. Como punto inicial de la escala, asegúrese de que su recuento de vCPU es 1,5 veces el conteo de particiones activas. Una partición activa es cualquier partición para un índice que recibe escritos sustanciales. Utilice el conteo de particiones primarias para determinar las particiones activas de los índices que reciben escritos sustanciales. Para el análisis logístico, solo el índice actual está activo. Para los casos de uso de búsqueda, que se leen mucho, utilice el conteo de particiones primarias.

Aunque se recomienda 1,5, esto depende en gran medida de la carga de trabajo. Asegúrese de probar y monitorear la utilización de la CPU y escalar en consecuencia.

Al trabajar con conteos de particiones e instancias, tenga en cuenta que Amazon ES funciona mejor cuando el recuento total de particiones es lo más pequeño posible, menos de 10.000 es un buen límite flexible. Cada instancia no debe tener más de 25 particiones en total por cada GB de masa de JVM en esa instancia. Por ejemplo, el R5.xlarge tiene 32 GB de RAM en total. El servicio asigna la mitad de la RAM (16 GB) para el montón (el tamaño máximo del montón en cualquier caso es de 31,5 GB). Nunca debe tener más de 400 = 16 * 25 particiones en cualquier nodo de ese clúster.

Caso de uso

Suponga que tiene una carga de trabajo de análisis de registros que soporta los registros web de Apache (500 GB/día) y los registros de sistema (500 GB/día), retenidos durante 7 días. Esta publicación se centra en el tipo de instancia R5 como la mejor opción para el análisis logístico. Se utiliza una implementación de tres zonas de disponibilidad, una primaria y dos réplicas por índice. Con una implementación de tres zonas, tiene que implementar los nodos en múltiplos de tres, lo que impulsa el conteo de instancias y, hasta cierto punto, el conteo de particiones.

El conteo de particiones primarias para cada índice es de (500 * 1,25) / 50 GB = 12,5 particiones, que redondeo es igual a 15. El uso de 15 primarias permite que crezca un espacio adicional en cada partición y que sea divisible por tres (el número de Zonas de disponibilidad, y por lo tanto el número de instancias es un múltiplo de 3). El total de almacenamiento necesario es de 1.000 * 1,25 * 3 * 7 = 26,25 TB. Puede proporcionar ese almacenamiento con 18 instancias de R5.xlarge.elasticsearch, 9 instancias de R5.2xlarge.elasticsearch, o 6 instancias de R5.4xlarge.elasticsearch (basado en los límites de EBS de 1.5 TB, 3 TB, y 6 TB, respectivamente). Debe elegir las instancias 4xlarge, siguiendo la directriz general de que la escalada vertical suele ser más eficaz que la horizontal (hay muchas excepciones a esta regla general, así que asegúrese de iterar adecuadamente).

Una vez que haya encontrado una implementación mínima, necesitará validar el conteo de CPU. Cada índice tiene 15 particiones primarias y 2 de réplica, para un total de 45 particiones. Los índices más recientes reciben una escritura sustancial, por lo que cada uno tiene 45 particiones activas, lo que da un total de 90 particiones activas. Ignora los otros 6 días de índices porque se accede a ellos con poca frecuencia. Para el análisis logístico, puede asumir que el volumen de lectura es siempre bajo y disminuye con el paso de los años de los datos. Cada R5.4xlarge.elasticsearch tiene 16 vCPU, para un total de 96 en su clúster. La directriz de prácticas recomendadas es 135 = 90 * 1,5 vCPU necesarios. Como punto de partida de la escala, hay que aumentar a 9x R5.4xlarge.elasticsearch, con 144 vCPU. Una vez más, las pruebas pueden revelar que está sobreaprovisionado (lo cual es probable), y es posible que pueda reducirse a seis. Finalmente, dado el conteo de nodos de datos y particiones, aprovisiona 3 nodos maestros dedicados a la búsqueda elástica C5.large.elasticsearch.

Conclusión

Esta publicación incluyó algunas prácticas recomendadas para implementar su dominio de Amazon ES. Estas directrices le dan una estimación razonable del número y tipo de nodos de datos. Manténgase en sintonía para las siguientes publicaciones que incluyen prácticas recomendadas para la implementación de dominios seguros, el monitoreo del rendimiento de su dominio y la ingesta de datos en su dominio.

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre el autor

Jon Handler es un Arquitecto principal de soluciones en Amazon Web Services con sede en Palo Alto, CA. Jon trabaja en estrecha colaboración con los equipos de CloudSearch y Elasticsearch, proporcionando ayuda y orientación a una amplia gama de clientes que tienen cargas de trabajo de búsqueda que quieren trasladar a la nube de AWS. Antes de unirse a AWS, la carrera de Jon como desarrollador de software abarcó cuatro años de codificación de un motor de búsqueda de comercio electrónico a gran escala.