Comment résoudre les rejets de recherche ou d'écriture dans Amazon Elasticsearch Service ?

Dernière mise à jour : 25/03/2021

Les requêtes de recherche ou d'écriture que je soumets à mon cluster Amazon Elasticsearch Service (Amazon ES) sont rejetées et j'obtiens une erreur. Pourquoi cela se produit-il ?

Brève description

Lorsque vous écrivez ou recherchez des données dans votre cluster Elasticsearch, vous pouvez recevoir l'erreur HTTP 429 ou 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]]"

Les variables suivantes peuvent contribuer à l'apparition d'une erreur HTTP 429 ou es_rejected_execution_exception :

  • Types d'instance de nœud de données et limites de recherche ou d'écriture
  • Valeurs élevées pour les métriques d'instance
  • Threads actifs et en file d'attente

Des erreursHTTP 429 peuvent survenir à la suite de requêtes de recherche et d'écriture passées à votre cluster Elasticsearch. Les rejets peuvent également provenir d'un seul nœud ou de plusieurs nœuds de votre cluster.

Remarque : différentes versions d'Amazon ES utilisent différents pools de threads pour traiter les appels à l'API _index. Les versions 1.5 et 2.3 d'Elasticsearch utilisent le pool de threads d'index. Les versions 5.x, 6.0 et 6.2 d'Elasticsearch utilisent le pool de threads en bloc. Elasticsearch version 6.3 et les versions ultérieures utilisent le pool de threads d'écriture. Pour plus d'informations, consultez la section Pool de threads sur le site Web Elasticsearch.

Solution

Types d'instance de nœud de données et limites de recherche ou d'écriture

Un type d'instance de nœud de données a des processeurs virtuels (vCPU) fixes. Ajoutez le nombre de vCPU à votre formule pour obtenir les opérations de recherche ou d'écriture simultanées que votre nœud peut effectuer avant d'entrer dans une file d'attente. Si un thread actif devient plein, celui-ci déborde sur une file d'attente et est finalement rejeté. Pour plus d'informations sur la relation entre les vCPU et les types de nœuds, consultez Tarification d'Amazon Elasticsearch Service.

En outre, il existe une limite au nombre de recherches par nœud ou d'écritures par nœud que vous pouvez effectuer. Cette limite est basée sur la définition du pool de threads et le numéro de version d'Elasticsearch. Pour plus d'informations, consultez la section Pool de threads sur le site Web Elasticsearch.

Par exemple, si vous avez choisi le type de nœud R5.2xlarge pour cinq nœuds dans votre cluster Elasticsearch (version 7.4), celui-ci aura 8 vCPU.

Utilisez cette formule pour calculer le nombre maximal de threads actifs pour les requêtes de recherche :

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

Utilisez cette formule pour calculer le nombre maximal de threads actifs pour les requêtes d'écriture :

int (# of available_processors) + 1

Par conséquent, pour un nœud R5.2xlarge, vous pouvez effectuer un maximum de 13 opérations de recherche :

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

Pour un nœud R5.2xlarge, vous pouvez effectuer un maximum de 9 opérations d'écriture :

8 VCPUs + 1 = 9 operations

Pour un cluster Elasticsearch avec cinq nœuds, vous pouvez effectuer un maximum de 65 opérations de recherche :

5 nodes * 13 = 65 operations

Pour un cluster Elasticsearch avec cinq nœuds, vous pouvez ensuite effectuer un maximum de 45 opérations d'écriture :

5 nodes * 9 = 45 operations

Valeurs élevées pour les métriques d'instance

Pour résoudre les problèmes liés à votre exception 429, vérifiez les métriques Amazon CloudWatch suivantes pour votre cluster Elasticsearch :

  • IndexingRate : nombre d'opérations d'indexation par minute. Un appel unique à l'API _bulk qui ajoute deux documents et en met à jour deux compte comme quatre opérations, qui peuvent être réparties sur un ou plusieurs nœuds. Si cet index comporte un ou plusieurs réplicas, les autres nœuds du cluster enregistrent également un total de quatre opérations d'indexation. Les suppressions de documents ne sont pas prises en compte dans la métrique IndexingRate.
  • SearchRate : nombre total de requêtes de recherche par minute pour tous les fragments d'un nœud de données. Un appel unique à l'API _search peut renvoyer les résultats de nombreux fragments différents. Si cinq fragments différents sont sur un nœud, le nœud indique « 5 » pour cette métrique, même si le client n'a fait qu'une seule requête.
  • ThreadpoolWriteQueue : nombre de tâches en file d'attente dans le pool de threads d'écriture. Cette métrique vous indique si une requête est rejetée en raison d'une utilisation du processeur ou d'une concurrence d'indexation élevée.
  • ThreadpoolWriteRejected : nombre de tâches rejetées dans le pool de threads d'écriture.
  • ThreadpoolSearchQueue : nombre de tâches en file d'attente dans le pool de threads de recherche. Si la taille de la file d'attente est constamment élevée, envisagez de mettre à l'échelle votre cluster. La taille maximale de la file d'attente de recherche est 1000.
  • ThreadpoolSearchRejected : nombre de tâches rejetées dans le pool de threads de recherche. Si ce nombre augmente continuellement, envisagez de mettre à l'échelle votre cluster.

Remarque : Les métriques de pool de threads répertoriées vous aident à vous informer sur IndexingRate et SearchRate.

Pour plus d'informations sur la surveillance de votre cluster Elasticsearch avec Amazon CloudWatch, consultez Métriques d'instance.

Threads actifs et en file d'attente

En cas de manque de processeurs ou de concurrence élevée, une file d'attente peut se remplir rapidement, ce qui entraîne une erreur HTTP 429. Pour surveiller vos threads de file d'attente, vérifiez les métriques ThreadpoolSearchQueue et ThreadpoolWriteQueue dans Amazon CloudWatch.

Pour vérifier les threads actifs et en file d'attente pour des rejets de recherche, utilisez la commande suivante :

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

Pour vérifier les rejets d'écriture dans les threads actifs et en file d'attente, remplacez « search » par « write ». Les valeurs rejected et completed dans la sortie sont des compteurs de nœuds cumulatifs, qui sont réinitialisés lorsque de nouveaux nœuds sont lancés. Pour plus d'informations, consultez le paragraphe Example with explicit columns de la section cat thread pool API sur le site Web Elasticsearch.

Remarque : la file d'attente en bloc sur chaque nœud peut contenir entre 50 et 200 demandes, selon la version d'Elasticsearch que vous utilisez. Lorsque la file d'attente est pleine, les nouvelles demandes sont rejetées. Pour plus d'informations, consultez la section Pool de threads sur le site Web Elasticsearch.

Exemples d'erreurs pour les rejets de recherche et d'écriture

Rejets de recherche

Une erreur de rejet de recherche indique que les threads actifs sont occupés et que les files d'attente ont été remplies jusqu'à la quantité maximale de tâches. Par conséquent, votre requête de recherche peut être rejetée. Vous pouvez configurer les journaux Elasticsearch de sorte que ces messages d'erreur apparaissent dans vos journaux lents de recherche.

Remarque : pour éviter des frais supplémentaires, définissez votre seuil de journaux lents sur une valeur généreuse. Par exemple, si la plupart de vos requêtes prennent 11 secondes et que votre seuil est « 10 », Amazon ES prendra plus de temps pour écrire un journal. Vous pouvez éviter cette surcharge en définissant votre seuil de journal lent sur 20 secondes. Seul un petit pourcentage des requêtes plus lentes (qui prennent plus de 11 secondes) seront enregistrées.

Une fois que votre cluster Elasticsearch a été configuré pour envoyer les journaux lents de recherche vers Amazon CloudWatch, définissez un seuil spécifique pour la génération des journaux lents. Vous pouvez définir un seuil spécifique pour la génération des journaux lents avec l'appel HTTP POST suivant :

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

Rejets d'écriture

Un message d'erreur 429 en tant que rejet d'écriture indique une erreur de file d'attente en bloc. es_rejected_execution_exception[bulk] indique que votre file d'attente est pleine et que toute nouvelle requête est rejetée. Lorsque le nombre de requêtes vers le cluster Elasticsearch dépasse la taille de la file d'attente en bloc (threadpool.bulk.queue_size), cette erreur se produit. La file d'attente en bloc sur chaque nœud peut contenir entre 50 et 200 demandes, selon la version d'Elasticsearch que vous utilisez.

Vous pouvez configurer les journaux Elasticsearch de sorte que ces messages d'erreur apparaissent dans vos journaux lents d'index.

Remarque : pour éviter des frais supplémentaires, définissez votre seuil de journaux lents sur une valeur généreuse. Par exemple, si la plupart de vos requêtes prennent 11 secondes et que votre seuil est « 10 », Amazon ES prendra plus de temps pour écrire un journal. Vous pouvez éviter cette surcharge en définissant votre seuil de journal lent sur 20 secondes. Seul un petit pourcentage des requêtes plus lentes (qui prennent plus de 11 secondes) seront enregistrées.

Une fois que votre cluster Elasticsearch a été configuré pour envoyer les journaux lents de recherche vers Amazon CloudWatch, définissez un seuil spécifique pour la génération des journaux lents. Pour définir un seuil spécifique pour la génération du journal lent, utilisez l'appel HTTP POST suivant :

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

Les bonnes pratiques en matière de rejets d'écriture

Voici quelques bonnes pratiques qui atténuent les rejets d'écriture :

  • Lorsque les documents sont indexés plus rapidement, la file d'attente d'écriture est moins susceptible d'atteindre sa capacité.
  • Réglez la taille en bloc selon votre charge de travail et les performances souhaitées. Pour plus d'informations, consultez la section Tune for indexing speed sur le site Web Elasticsearch.
  • Ajoutez une logique de nouvelle tentative exponentielle dans votre logique d'application. Celle-ci garantit que les requêtes ayant échoué sont automatiquement réessayées.
    Remarque : si votre cluster Elasticsearch subit continuellement des requêtes simultanées élevées, la logique de nouvelle tentative exponentielle ne vous aidera pas à résoudre l'erreur 429. Intégrer cette bonne pratique lorsqu'il y a un pic soudain ou occasionnel du trafic.
  • Si vous ingérez des données à partir de Logstash, ajustez le nombre de nœuds de travail et la taille en bloc. Il est recommandé de définir votre taille en bloc entre 3 et 5 Mo.

Pour plus d'informations sur le réglage des performances d'indexation, consultez Comment améliorer les performances d'indexation sur mon cluster Amazon Elasticsearch Service ?

Les bonnes pratiques en matière de rejets de recherche

Voici quelques bonnes pratiques qui atténuent les rejets de recherche :

  • Basculez vers un type d'instance plus important. Elasticsearch s'appuie fortement sur le cache du système de fichiers pour obtenir des résultats de recherche plus rapides. Le nombre de threads dans le pool de threads sur chaque nœud pour les requêtes de recherche est égal à : int((# de processeurs_disponibles * 3) / 2) + 1. Passez à une instance avec plus de vCPU pour obtenir plus de threads afin de traiter les requêtes de recherche.
  • Activez les journaux lents de recherche pour un index donné ou pour tous les indexes avec une valeur de seuil raisonnable. Vérifiez quelles requêtes prennent plus de temps à s'exécuter et mettez en œuvre des stratégies de performance de recherche pour vos requêtes. Pour plus d'informations, consultez Dépannage des recherches Elasticsearch, pour les débutants ou Réglage avancé : Recherche et correction des requêtes Elasticsearch lentes sur le site Web Elasticsearch.

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?