Traducción de
Nick PriceActualmente estoy trabajando en un gran proyecto de registro que se implementó originalmente con AWS Elasticsearch. Después de haber trabajado con los clústeres de red troncal a gran escala de Elasticsearch durante varios años, estoy completamente abrumado por la calidad de la implementación de AWS y no puedo entender por qué no lo arreglaron o al menos lo mejoraron.
Resumen
Elasticsearch almacena datos en varios índices que crea explícitamente o que pueden crearse automáticamente después de enviar los datos. Las entradas en cada índice se dividen en un cierto número de fragmentos, que luego se equilibran entre los nodos en su grupo (lo más uniformemente posible si el número de sus fragmentos no se divide de manera uniforme por el número de nodos). Hay dos tipos principales de fragmentos en ElasticSearch: fragmentos básicos y fragmentos de réplica. Los fragmentos de réplica proporcionan tolerancia a fallas en caso de falla de un nodo, y los usuarios pueden establecer el número de fragmentos de réplica por separado para cada índice.
El trabajo de Elasticsearch estándar
Elasticsearch: es elástico. A veces puede ser bastante complicado, pero, en general, puede agregar nodos al clúster o eliminarlos. Y si en el caso de la eliminación de un nodo hay un número adecuado de réplicas, Elasticsearch distribuirá fragmentos e incluso equilibrará la carga en los nodos del clúster. Esto generalmente funciona.
El cumplimiento de consultas costosas a veces puede conducir a la caída de nodos y similares, pero una gran cantidad de configuraciones ayuda a mantener el trabajo. Con un número suficiente de fragmentos de réplica, si el nodo cae, esto no afecta el trabajo en su conjunto.
Standard Elasticsearch también tiene una serie de complementos disponibles, que incluyen X-Pack, funciones de auditoría, ACL granulares, monitoreo y alertas. La mayor parte del X-Pack recientemente se convirtió en gratuito, probablemente en respuesta a la nueva política de licencia de Splunk.
Amazon Elasticsearch Work
Como de costumbre, Amazon tomó el código fuente abierto de parte de Elasticsearch, hizo un hard fork y comenzó a venderlo como su propio servicio, introduciendo gradualmente sus propias versiones de funciones que durante muchos años han estado disponibles de una forma u otra en la versión principal de Elasticsearch.
El producto de Amazon carece de muchas cosas, como: RBAC y auditoría, lo cual es especialmente problemático para nosotros, ya que aceptamos registros de diferentes equipos y nos gustaría separarlos unos de otros. En este momento, cualquier usuario que tenga acceso a Elasticsearch tiene todos los derechos de acceso y puede eliminar accidentalmente los datos de otra persona, cambiar la forma en que se replican en los nodos y dejar de recibir datos al agregar la plantilla de indexación incorrecta.
Esto es frustrante, pero este no es el mayor problema con el servicio. El reequilibrio de fragmentos, el concepto central de Elasticsearch, no funciona en la implementación de AWS, lo que niega casi todo lo bueno en Elasticsearch.
Por lo general, cuando se agregan datos a los nodos, uno puede llenar más que los demás. Esto se espera ya que no hay garantías de que los registros cargados tengan el mismo tamaño o que el número de fragmentos siempre se distribuya de manera uniforme en todos los nodos del clúster. Esto no es crítico, porque Elasticsearch puede reequilibrar fragmentos entre nodos, y si un nodo está realmente lleno, entonces otros nodos comenzarán a recibir datos con gusto en lugar de rellenarse.
Esto no es compatible con Amazon. Algunos nodos pueden llenarse (mucho) más rápido que otros.
Además,
en Amazon, si un nodo en su clúster Elasticsearch no tiene suficiente espacio libre, todo el clúster deja de recibir datos , se detiene por completo. La solución de Amazon es permitir a los usuarios pasar por la pesadilla de cambiar periódicamente el número de fragmentos en sus plantillas de indexación, y luego reindexar los datos creados previamente en nuevos índices, eliminar los índices anteriores y, si es necesario, revertir la indexación de los datos en la estructura anterior. Esto es completamente redundante y requiere, además de los grandes costos computacionales, que se guarde una copia no procesada de los datos descargados junto con el registro analizado, ya que se requerirá una copia no procesada para volver a indexar. Y, por supuesto, esto duplica la cantidad de memoria necesaria para el trabajo "normal" en AWS.
"¡Uy! ¡No reindexé todo el clúster con suficiente frecuencia, y el nodo estaba lleno! ¿Qué hacer?
Tienes dos opciones. Primero, elimine tantos datos como sea necesario para revivir el clúster, y luego comience a reindexar con la esperanza de que nada se desmorone. ¿Tiene una copia de seguridad de lo que desea eliminar?
La segunda opción es agregar más nodos al clúster o cambiar el tamaño de los existentes a un tamaño de instancia más grande.
Pero espere, ¿cómo agrego nodos o hago cambios si los fragmentos no se pueden reequilibrar?
La solución de Amazon es un despliegue azul-verde. Giran un grupo completamente nuevo, copian todo el contenido del grupo anterior en uno nuevo y luego cambian y destruyen el grupo anterior.
Tales tareas de cambio de tamaño pueden llevar días, para grandes grupos, como puede imaginar, duplicar varios billones de registros puede llevar algo de tiempo. Esto también crea una carga loca en el clúster existente (probablemente ya excedió la capacidad) y en realidad puede hacer que el clúster falle. Realicé varias operaciones similares en más de 30 clústeres en AWS y solo una vez observé una finalización exitosa en modo automático.
Entonces, intentó cambiar el tamaño de su clúster y la tarea no se completó. Que ahora
Interacciones amazónicas
Su tarea de cambiar el tamaño del clúster se interrumpió (por el servicio que probablemente eligió no tratar con dicho artículo), por lo que abre el ticket para el soporte técnico de AWS con la máxima prioridad. Por supuesto, se quejarán de la cantidad o el tamaño de su fragmento y agregarán amablemente un enlace a las "mejores prácticas" que ya ha leído 500 veces. Y luego esperas a que se arregle. Y espera Y espera La última vez que intenté cambiar el tamaño del clúster, y estaba bloqueado, lo que provocó un mal funcionamiento grave, tardó SIETE DÍAS para volver a poner todo en línea. Restauraron el clúster en un par de días, pero cuando todo se detuvo, es obvio que los nodos en los que se ejecuta Kibana han perdido contacto con el clúster principal. AWS Support pasó otros cuatro días tratando de arreglar algo mientras se preguntaba si Kibana estaba trabajando. Ni siquiera sabían si habían solucionado el problema, y tuve que comprobar si habían restablecido la comunicación entre sus propios sistemas. Desde entonces, he dejado de hacer otra cosa que no sea eliminar datos si el nodo está lleno.
Los costos de nuestra organización en AWS son enormes. Esto nos brinda la oportunidad de reunirnos periódicamente con sus expertos en diversos campos, discutir estrategias de implementación y abordar una variedad de problemas técnicos. Hicimos una cita con un representante de Elasticsearch, durante el cual pasé la mayor parte de la reunión explicando los conceptos básicos de Elasticsearch y describiendo ... las peculiaridades ... de su producto. El experto estaba en completo shock porque todo se derrumba cuando el nodo está lleno. Si el experto enviado no conoce los conceptos básicos de su producto, no es sorprendente que el equipo de soporte necesite siete días para reanudar el clúster de producción.
Pensamientos al final
En el proyecto de registro, en el que me sumergí, hay una parte de errores arquitectónicos y decisiones de diseño débiles en las que estamos trabajando actualmente. Y, por supuesto, esperaba que AWS Elasticsearch fuera diferente del producto original. Sin embargo, en AWS Elasticsearch, hay tantas funciones fundamentales deshabilitadas o faltantes que esto exacerba casi todos los problemas que encontramos.
Para un uso fácil y grupos pequeños, AWS Elasticsearch funciona bastante bien, pero para grupos de tamaño petabyte, fue una pesadilla interminable.
Tengo mucha curiosidad por qué la implementación Elasticsearch de Amazon no puede equilibrar fragmentos; Esta es una funcionalidad fundamental de Elasticsearch. Incluso con limitaciones en comparación con el Elasticsearch principal, sin duda sería un producto aceptable para grandes grupos si funcionara correctamente. No puedo entender por qué Amazon ofrece algo tan roto y por qué no han remediado la situación en más de dos años.
Como otros han sugerido, y parece razonable, este comportamiento es un signo de la implementación de AWS, diseñada como un clúster gigante multiusuario, que intenta proporcionar aislamiento para que parezca un clúster independiente para los usuarios finales. Incluso con opciones como datos cifrados en reposo y transferencia de datos cifrados, esto parece plausible. O quizás sus herramientas y configuraciones son simplemente un legado de una arquitectura mucho anterior.
Y, como comentó mi amigo, es bastante divertido que todavía lo llamen "Flexible" cuando no puede agregar o eliminar nodos de sus clústeres sin activar uno nuevo y transferir todos sus datos.
Nota al pie: cuando escribí este texto, encontré una publicación hace dos años con muchas afirmaciones similares:
read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f