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

Dernière mise à jour : 13/01/2021

Lorsque je soumets une requête de recherche ou d'écriture à mon cluster Amazon Elasticsearch Service (Amazon ES), les requêtes 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 à 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 vers 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 Pool de threads sur le site Web Elasticsearch.

Ré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, le thread 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 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 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), il aura 8 vCPU.

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

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

Utilisez la formule suivante 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.x2xLarge, vous pouvez effectuer un maximum de 13 opérations de recherche :

(8 VCPU's * 3) / 2 + 1 = 13 operations

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

8 VCPU's + 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 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étriques 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 élevée 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 être remplie 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 rejetés d'écriture dans les threads actifs et en file d'attente, remplacez « search » par « write ». Les valeurs rejetées et terminées 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 la section Exemple avec des colonnes explicites de l'API de pool de threads cat 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 Pool de threads sur le site Web Elasticsearch.

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

Rejets de recherche

Si vous recevez une erreur de rejet de recherche, elle 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 journal lent sur un montant généreux. 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. Ensuite, seul un petit pourcentage des requêtes plus lentes (qui prennent plus de 11 secondes) sont 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

Si vous recevez un message d'erreur 429 pour un rejet d'écriture, il 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 de file d'attente en bloc 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 journal lent sur un montant généreux. 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. Ensuite, seul un petit pourcentage des requêtes plus lentes (qui prennent plus de 11 secondes) sont 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 en fonction de votre charge de travail et des performances souhaitées. Pour plus d'informations, consultez Réglage de la vitesse d'indexation sur le site Web Elasticsearch.
  • Ajoutez une logique de nouvelle tentative exponentielle dans votre logique d'application. La logique de nouvelle tentative exponentielle 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 travailleurs 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 au suivant : int((# de processeurs_disponibles * 3) / 2) + 1. Passez à une instance avec plus de vCPU pour obtenir plus de threads pour 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 que les requêtes prennent plus de temps à exécuter et à mettre 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 ?