¿Cómo puedo resolver los rechazos de búsqueda o escritura en Amazon OpenSearch Service?

Descripción corta

Cuando escriba o busque datos en el clúster de OpenSearch Service, es posible que reciba el siguiente error HTTP 429 o la excepción es_rejected_execution_exception:

error":"elastic: Error 429 (Too Many Requests): rejected execution of org.elasticsearch.transport.TransportService$7@b25fff4 on 
EsThreadPoolExecutor[bulk, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@768d4a66[Running, 
pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 820898]] [type=es_rejected_execution_exception]"

Reason={"type":"es_rejected_execution_exception","reason":"rejected execution of org.elasticsearch.transport.TcpTransport$RequestHandler@3ad6b683 on EsThreadPoolExecutor[search, queue capacity = 1000, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@bef81a5[Running, pool size = 25, active threads = 23, queued tasks = 1000, completed tasks = 440066695]]"

Las siguientes variables pueden contribuir a que se produzca un errorHTTP 429 o una excepción es_rejected_execution_exception:

• tipos de instancias de nodos de datos y límites de búsqueda o escritura
• valores altos para las métricas de las instancias
• subprocesos activos y en cola

Los errores HTTP 429 pueden producirse debido a las solicitudes de búsqueda y escritura al clúster. Los rechazos también pueden provenir de un solo nodo o de varios nodos del clúster.

Nota: Las diferentes versiones de Elasticsearch utilizan grupos de subprocesos diferentes para procesar las llamadas a la API _index. Las versiones 1.5 y 2.3 de Elasticsearch utilizan el grupo de subprocesos de índice. Las versiones 5.x, 6.0 y 6.2 de Elasticsearch utilizan el grupo de subprocesos masivos. Las versiones 6.3 y posteriores de Elasticsearch utilizan el grupo de subprocesos de escritura. Para obtener más información, consulte Grupos de subprocesos en el sitio web de Elasticsearch.

Resolución

Tipos de instancias de nodos de datos y límites de búsqueda o escritura

Un tipo de instancias de nodos de datos tiene CPU virtuales (vCPU) fijas. Incluya el recuento de vCPU en su fórmula para recuperar las operaciones simultáneas de búsqueda o escritura que su nodo puede realizar antes de entrar en una cola. Si un subproceso activo se llena, el subproceso se desborda y se transforma en una cola, lo que al final produce el rechazo. Para obtener más información acerca de la relación entre las vCPU y los tipos de nodos, consulte Precios de OpenSearch Service.

Además, hay un límite referido la cantidad de búsquedas o escrituras que se pueden realizar por nodo. Este límite se basa en la definición de grupo de subprocesos y en el número de la versión de Elasticsearch. Para obtener más información, consulte Grupos de subprocesos en el sitio web de Elasticsearch.

Por ejemplo, si ha elegido el tipo de nodo R5.2xlarge para cinco nodos de su clúster de Elasticsearch (versión 7.4), el nodo tendrá 8 vCPU.

Utilice la siguiente fórmula para calcular la cantidad máxima de subprocesos activos para las peticiones de búsqueda:

int ((# of available_processors * 3) / 2) + 1

Utilice la siguiente fórmula para calcular la cantidad máxima de subprocesos activos para las solicitudes de escritura:

int (# of available_processors)

Por lo tanto, para un nodo R5.2xlarge, puede realizar un máximo de 13 operaciones de búsqueda:

(8 VCPUs * 3) / 2 + 1 = 13 operations

Para un nodo R5.2xlarge, puede realizar un máximo de 8 operaciones de escritura:

8 VCPUs = 8 operations

Para un clúster de OpenSearch Service con cinco nodos, puede realizar un máximo de 65 operaciones de búsqueda:

5 nodes * 13 = 65 operations

Para un clúster de OpenSearch Service con cinco nodos, puede realizar un máximo de 40 operaciones de escritura:

5 nodes * 8 = 40 operations

Valores altos para las métricas de las instancias

Para solucionar la excepción 429, verifique las siguientes métricas de Amazon CloudWatch para su clúster:

• IndexingRate: cantidad de operaciones de indexación por minuto. Una sola llamada a la API _bulk que agrega dos documentos y actualiza dos recuentos como cuatro operaciones que pueden estar distribuidas en uno o más nodos. Si ese índice tiene una o más réplicas, los demás nodos del clúster también registrarán un total de cuatro operaciones de indexación. Las eliminaciones de documentos no cuentan para la métrica IndexingRate.
• SearchRate: cantidad total de peticiones de búsqueda por minuto para todas las particiones de un nodo de datos. Una única llamada a la API _search puede devolver resultados de muchas particiones diferentes. Si hay cinco particiones diferentes en un nodo, el nodo informará “5” para esta métrica, aunque el cliente solo haya realizado una solicitud.
• CoordinatingWriteRejected: el número total de rechazos que se produjeron en el nodo de coordinación. Estos rechazos se deben a la presión de indexación que se acumuló desde el inicio del servicio OpenSearch.
• PrimaryWriteRejected: el número total de rechazos que se produjeron en las particiones principales. Estos rechazos se deben a la presión de indexación acumulada desde el último inicio del servicio OpenSearch.
• ReplicaWriteRejected: el número total de rechazos que se produjeron en las particiones de réplica debido a la presión de indexación. Estos rechazos se deben a la presión de indexación acumulada desde el último inicio del servicio OpenSearch.
• ThreadpoolWriteQueue: cantidad de tareas en cola en el grupo de subprocesos de escritura. Esta métrica le informa si se rechaza una solicitud debido a un uso elevado de la CPU o a una elevada simultaneidad de indexación.
• ThreadpoolWriteRejected: cantidad de tareas rechazadas en el grupo de subprocesos de escritura.
  Nota: El tamaño de la cola de escritura predeterminado se incrementó de 200 a 10 000 en la versión 7.9 de OpenSearch Service. Como resultado, esta métrica ya no es el único indicador de rechazos de OpenSearch Service. Utilice las métricas CoordinatingWriteRecjected, PrimaryWriteRejected y ReplicaWriteRejected para monitorear los rechazos en las versiones 7.9 y posteriores. Para obtener más información, consulte Métricas de UltraWarm.
• ThreadpoolSearchQueue: cantidad de tareas en cola en el grupo de subprocesos de búsqueda. Si el tamaño de la cola es siempre alto, considere escalar el clúster. El tamaño máximo de la cola de búsqueda es de 1000.
• ThreadpoolSearchRejected: cantidad de tareas rechazadas en el grupo de subprocesos de búsqueda. Si este número aumenta continuamente, considere escalar el clúster.

Nota: Las métricas de grupo de subprocesos que se enumeran ayudan a informar sobre las métricas IndexingRate y SearchRate.

Para obtener más información acerca de cómo monitorear su clúster de OpenSearch Service con Amazon CloudWatch, consulte Métricas de instancias.

Subprocesos activos y en cola

Si faltan CPU o hay una alta concurrencia de solicitudes, la cola se puede llenar rápidamente, lo que dará como resultado un error HTTP 429. Para monitorear los subprocesos en cola, consulte las métricas ThreadpoolSearchQueue y ThreadpoolWriteQueue de Amazon CloudWatch.

Para verificar si hay rechazos de búsqueda en los subprocesos activos y en cola, utilice el siguiente comando:

GET /_cat/thread_pool/search?v&h=id,name,active,queue,rejected,completed

Para verificar si hay rechazos de escritura en los subprocesos activos y en cola, sustituya “search” (búsqueda) por “write” (escritura). Los valores rejected (rechazados) y completed (completados) del resultado son recuentos acumulativos de nodos, que se restablecen cuando se lanzan nuevos nodos. Para obtener más información, consulte la sección Example with explicit columns de la cat thread pool API en el sitio web de Elasticsearch.

Nota: La cola masiva de cada nodo puede contener entre 50 y 200 solicitudes, según la versión de Elasticsearch que utilice. Cuando la cola está llena, se rechazan las nuevas solicitudes. Para obtener más información, consulte Grupos de subprocesos en el sitio web de Elasticsearch.

Errores de ejemplo para rechazos de búsqueda y escritura

Rechazos de búsqueda

Un error de rechazo de búsqueda indica que los subprocesos activos están ocupados y que las colas están llenas hasta el número máximo de tareas. Como resultado, su petición de búsqueda puede ser rechazada. Puede configurar los registros de OpenSearch Service para que estos mensajes de error aparezcan en los registros lentos de búsqueda.

Nota: Para evitar sobrecargas adicionales, establezca el límite de registros lentos en un número alto. Por ejemplo, si la mayoría de las consultas tardan 11 segundos y el límite es “10”, OpenSearch Service tardará más tiempo en escribir un registro. Puede evitar esta sobrecarga estableciendo el límite de registros lentos en 20 segundos. Entonces, solo se registrará un pequeño porcentaje de las consultas más lentas (que tarden más de 11 segundos).

Una vez configurado el clúster para enviar los registros lentos de búsqueda a Amazon CloudWatch, establezca un límite específico para la generación de registros lentos. Puede establecer un límite específico para la generación de registros lentos con la siguiente llamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.search.slowlog.threshold.query.<level>":"10s"}'

Rechazos de escritura

El mensaje de error 429 como rechazo de escritura indica un error de cola masiva. La excepción es_rejected_execution_exception[bulk] indica que la cola está llena y que se rechazarán las nuevas solicitudes. Este error de cola masiva se produce cuando la cantidad de peticiones al clúster supera el tamaño de la cola masiva (threadpool.bulk.queue_size). Una cola masiva en cada nodo puede contener entre 50 y 200 solicitudes, según la versión de Elasticsearch que utilice.

Puede configurar los registros de OpenSearch Service para que estos mensajes de error aparezcan en los registros lentos de índice.

Nota: Para evitar sobrecargas adicionales, establezca el límite de registros lentos en un número alto. Por ejemplo, si la mayoría de las consultas tardan 11 segundos y el límite es “10”, OpenSearch Service tardará más tiempo en escribir un registro. Puede evitar esta sobrecarga estableciendo el límite de registros lentos en 20 segundos. Entonces, solo se registrará un pequeño porcentaje de las consultas más lentas (que tarden más de 11 segundos).

Una vez configurado el clúster para enviar los registros lentos de búsqueda a Amazon CloudWatch, establezca un límite específico para la generación de registros lentos. Para establecer un límite específico para la generación de registros lentos, utilice la siguiente llamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.indexing.slowlog.threshold.query.<level>":"10s"}'

Prácticas recomendadas para los rechazos de escritura

A continuación, se presentan algunas prácticas recomendadas para mitigar los rechazos de escritura:

• Considere que cuando los documentos se indexan más rápido, es menos probable que la cola de escritura alcance su capacidad máxima.
• Ajuste el tamaño masivo según su carga de trabajo y el rendimiento deseado. Para obtener más información, consulte Tune for indexing speed en el sitio web de Elasticsearch.
• Agregue lógica de reintento exponencial a la lógica de su aplicación. La lógica de reintento exponencial garantiza que las solicitudes fallidas se vuelvan a intentar automáticamente.
  Nota: Si su clúster experimenta una gran cantidad de solicitudes simultáneas de forma continua, la lógica de reintento exponencial no ayudará a resolver el error 429. Incorpore esta práctica recomendada cuando haya un pico repentino u ocasional de tráfico.
• Si piensa incorporar datos de Logstash, ajuste el recuento de trabajadores y el tamaño masivo. La práctica recomendada es establecer el tamaño masivo entre 3 y 5 MB.

Para obtener más información acerca del ajuste del rendimiento de indexación, consulte ¿Cómo puedo mejorar el rendimiento de indexación de mi clúster de OpenSearch Service?

Prácticas recomendadas para los rechazos de búsqueda

A continuación, se presentan algunas prácticas recomendadas para mitigar los rechazos de búsqueda:

• Cambie a un tipo de instancias más grande. OpenSearch Service depende en gran medida de la memoria caché del sistema de archivos para obtener resultados de búsqueda más rápidos. La cantidad de subprocesos en el grupo de subprocesos de cada nodo para las solicitudes de búsqueda es igual a lo siguiente: int((cantidad de procesadores disponibles * 3) / 2) + 1. Cambie a una instancia con más vCPU para obtener más subprocesos y poder procesar las solicitudes de búsqueda.
• Active los registros lentos de búsqueda para un índice determinado o para todos los índices con un valor límite razonable. Verifique qué consultas tardan más en ejecutarse e implemente estrategias de rendimiento de búsqueda para sus consultas. Para obtener más información, consulte Solución de problemas de búsquedas de Elasticsearch o Ajustes avanzados: encontrar y resolver búsquedas lentas en Elasticsearch en el sitio web de Elasticsearch.

---