Algunas cosas que debe saber antes de usar el servicio Elasticsearch de Amazon en AWS

Elasticsearch es una infraestructura poderosa pero frágil con un montón de cosas que pueden hacer que el servicio AWS se vuelva inestable

Escribo esto después de un día de trabajo particularmente frustrante y esperando mensajes flojos del equipo de soporte de AWS. Nuestro clúster de Elasticsearch estuvo inactivo durante la mayor parte del día, y estuvimos comprometidos con el soporte de AWS todo el tiempo.

En mi trabajo anterior trabajando para Loggly, mi equipo y yo mantuvimos una implementación masiva de Multi-cluster Elasticsearch. Aprendí muchas lecciones y tengo muchos trucos bajo la manga para lidiar con los temperamentos de Elasticsearch. Me siento capacitado para enfrentar la mayoría de los problemas de Elasticsearch, dado el acceso a las API administrativas de Elasticsearch, las métricas y el registro.

Elasticsearch de AWS ofrece acceso a nada de eso . Ni siquiera las API que son de solo lectura, como la API / _cluster / pending_tasks , que habrían sido realmente útiles, dado que el número de tareas en nuestra cola de tareas pendientes había ido ascendiendo constantemente en la región de 60K +.

Este maldito mensaje me ha atormentado desde que hace unos meses se me impuso Elasticsearch alojado de AWS:

 { 
"Mensaje": "Su solicitud: '/ _cluster / pending_tasks' no está permitida."
}

Gracias, AWS. Gracias….

Sin acceso a los registros, sin acceso a las API administrativas, sin métricas a nivel de nodo (todo lo que obtienes son métricas agregadas de nivel de clúster) o incluso los malditos registros de consulta, es básicamente imposible solucionar tu propio clúster de Elasticsearch. Esto te deja con una opción cada vez que algo salga mal: ponte en contacto con el equipo de soporte de AWS.

9 de cada 10 veces, AWS simplemente se quejará de que tiene demasiados fragmentos.

Es amargamente divertido que te critiquen por esto porque, de forma predeterminada, cualquier índice que crees contendrá 5 fragmentos y 1 réplica. Cualquier veterano de ES se dirá a sí mismo: diablos, ¡simplemente actualizaré la configuración del clúster y reduciré el valor predeterminado a 1 fragmento! Nop.

 { 
"Mensaje": "Su solicitud: '/ _cluster / settings' no está permitida para el verbo: GET"
}

Bueno, joder (aunque puedes evitar esto usando plantillas de índice ).

Eventualmente, el soporte de AWS sugirió que actualicemos el tamaño de la instancia de nuestros nodos maestros, ya que no podían mantenerse al día con la creciente cola de tareas pendientes. Sin embargo, nos aconseja ser prudentes porque hacer ningún cambio en absoluto se duplicará el tamaño de la agrupación y copiar cada fragmento.

Está bien. Al aumentar el tamaño de la instancia de solo los nodos maestros, el middleware de AWS duplicará el tamaño de todo el clúster y reubicará todos los fragmentos del clúster en nuevos nodos. Después de lo cual, los nodos antiguos se eliminan del clúster. Por qué es necesario esto está completamente más allá de mí.

Agregar una entrada a la lista de direcciones IP que tienen acceso al clúster causará que el clúster duplique su tamaño y migre cada fragmento apestoso.

De hecho, incluso al agregar un solo nodo de datos al clúster, se duplicará su tamaño y se moverán todos los datos.

No me creas? Aquí está el gráfico real de nuestro conteo de nodos ya que estábamos lidiando con el problema de ayer:

El recuento de nodos aumentó en 10x durante un período de tiempo

De vuelta en Loggly, nunca hubiéramos considerado hacer esto. La reubicación de todos los fragmentos en cualquier clúster de tamaño respetable de forma individual borra los nodos maestros y haría que tanto la indexación como la búsqueda se detengan bruscamente. Que es precisamente lo que sucede cada vez que hacemos algún cambio en nuestro clúster Elasticsearch en AWS.

Esta es probablemente la razón por la cual AWS siempre se queja sobre la cantidad de fragmentos que tenemos … Como, sé que Elasticsearch tiene una manera fácil y sencilla de agregar un nodo a un clúster. No hay razón para esta locura dada la forma en que Elasticsearch funciona.

A menudo me pregunto cuánta complejidad gratuita acecha en el middleware Elasticsearch de AWS. Mi teoría es que sus clústeres de ES son multi-tenant. ¿Por qué otra cosa se bloquearía el punto final de las tareas pendientes? ¿Por qué si no le darían acceso a los registros de ES? ¿Por qué si no abrirían tantas API administrativas útiles detrás del Cerberus "no permitido"?

Debo admitir, sin embargo, que es tremendamente agradable poder agregar y eliminar nodos de un clúster con solo hacer clic en un botón. Puede cambiar los tamaños de instancia de sus nodos desde un menú desplegable; obtienes un panel de métricas semi-útil; cuando los nodos bajan, se vuelven a subir automáticamente; obtienes instantáneas automáticas; la autenticación funciona a la perfección dentro del ecosistema de AWS (pero hace que su clúster de ES sea tremendamente difícil de integrar con bibliotecas y herramientas que no son AWS, y podría gastar toda una nueva publicación de blog despotricando) y cuando las cosas van mal, todo lo que tiene que hacer es mueva los pulgares y espere porque no tiene el poder de hacer nada más.

Elasticsearch es una pieza de infraestructura poderosa pero frágil. Sus problemas son matizados. Hay un montón de cosas que pueden hacer que se vuelva inestable, la mayoría de las cuales están relacionadas con patrones de consulta, los documentos que se indexan, la cantidad de campos dinámicos que se crean, los desequilibrios en los tamaños de los fragmentos, la proporción de documentos y el espacio del montón. El diagnóstico de estos problemas es un poco artístico, y se necesita una gran cantidad de métricas, archivos de registro y API administrativas para profundizar y encontrar la causa raíz de un problema.

Elasticsearch de AWS no brinda acceso a ninguna de estas cosas, por lo que no le queda otra opción que ponerse en contacto con el equipo de asistencia técnica de AWS. Pero el equipo de soporte de AWS no tiene el tiempo, las habilidades o el contexto para diagnosticar problemas no triviales, por lo que solo lo regañarán por la cantidad de fragmentos que tenga y le dirán que agregue más hardware al problema. Aunque alojar Elasticsearch en AWS le ahorra la molestia de necesitar un ingeniero devops competente en su equipo, eso no significa que su clúster sea más estable.

Entonces, si su conjunto de datos es pequeño, si puede tolerar interminables horas de inactividad, si su presupuesto es demasiado ajustado, si su infraestructura está demasiado encerrada en el ecosistema de AWS para comprar algo mejor que Elasticsearch hospedado de AWS: AWS Elasticsearch es para usted. Pero considérate advertido …

Actualización: 19/06/2017 : desde que se publicó esto, los ingenieros del equipo AWS Elasticsearch se han comunicado personalmente con nosotros para comprender mejor nuestros casos de uso. Están planeando mejorar la experiencia de los "usuarios avanzados" y obtuvieron muchos comentarios nuestros. Agradezco sinceramente la disposición de AWS para enfrentar estos problemas de frente y estoy impresionado de lo rápido que abordaron esto. Entonces, ¡felicitaciones a ellos!

¡Gracias por leer! Si te gusta lo que lees, mantén presionado el botón de aplaudir para que otros puedan encontrarlo. Puedes seguirme en Twitter .