Comment puis-je résoudre les refus de recherche ou d'écriture dans Amazon OpenSearch Service ?

Brève description

Lorsque vous écrivez ou recherchez des données dans votre cluster OpenSearch Service, vous pouvez recevoir l'erreur HTTP 429 suivante 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 à une exception es_rejected_execution_exception :

• Types d'instances de nœuds de données et limites de recherche ou d'écriture
• Valeurs élevées pour les métriques par exemple
• Fils actifs et file d'attente
• Utilisation élevée du processeur et pression de mémoire JVM

Des erreurs HTTP 429 peuvent se produire en raison de demandes de recherche et d'écriture adressées à votre cluster. Les rejets peuvent également provenir d'un seul nœud ou de plusieurs nœuds de votre cluster.

**Remarque :**Les différentes versions d'Elasticsearch 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 groupés. Les versions 6.3 et ultérieures d'Elasticsearch utilisent le pool de threads d'écriture. Pour plus d'informations, consultez la section Thread pool sur le site Web d'Elasticsearch.

Résolution

Types d'instances de nœuds de données et limites de recherche ou d'écriture

Un type d'instance de nœud de données possède des processeurs virtuels fixes (vCPU). Insérez le nombre de processeurs virtuels dans votre formule pour récupérer les opérations de recherche ou d'écriture simultanées que votre nœud peut effectuer avant qu'il n'entre dans une file d'attente. Si un fil actif est plein, il se retrouve dans une file d'attente et est finalement rejeté. Pour plus d'informations sur la relation entre les processeurs virtuels et les types de nœuds, consultez la tarification d'OpenSearch Service.

En outre, le nombre de recherches par nœud ou d'écritures par nœud que vous pouvez effectuer est limité. 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 Thread pool sur le site Web d'Elasticsearch.

Par exemple, si vous choisissez le type de nœud R5.2xlarge pour cinq nœuds de votre cluster Elasticsearch (version 7.4), le nœud sera doté de 8 processeurs virtuels.

Utilisez la formule suivante pour calculer le nombre maximum de threads actifs pour les demandes de recherche :

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

Utilisez la formule suivante pour calculer le nombre maximum de threads actifs pour les demandes d'écriture :

int (# of available_processors)

Pour un nœud R5.2xlarge, vous pouvez effectuer au maximum 13 opérations de recherche :

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

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

8 VCPUs = 8 operations

Pour un cluster OpenSearch Service à cinq nœuds, vous pouvez effectuer un maximum de 65 opérations de recherche :

5 nodes * 13 = 65 operations

Pour un cluster OpenSearch Service à cinq nœuds, vous pouvez effectuer un maximum de 40 opérations d'écriture :

5 nodes * 8 = 40 operations

Valeurs élevées pour les métriques par exemple

Pour résoudre votre exception 429, vérifiez les métriques Amazon CloudWatch suivantes pour votre cluster :

• Taux d'indexation : Nombre d'opérations d'indexation par minute. Un seul appel à l'API _bulk qui ajoute deux documents et en met à jour deux compte pour quatre opérations susceptibles de se répartir entre les nœuds. Si cet index comporte une ou plusieurs répliques, 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.
• Taux de recherche : Nombre total de demandes de recherche par minute pour toutes les partitions d'un nœud de données. Un seul appel à l'API _search peut renvoyer des résultats provenant de nombreuses partitions différentes. Si cinq partitions différentes se trouvent sur un nœud, le nœud indique « 5 » pour cette métrique, même si le client n'a fait qu'une seule demande.
• **Rédaction de coordination rejetée :**Le nombre total de rejets survenus sur le nœud de coordination. Ces rejets sont dus à la pression d'indexation qui s'est accumulée depuis le démarrage d'OpenSearch Service.
• **Écriture principale rejetée :**Le nombre total de rejets survenus sur les partitions principales. Ces rejets sont dus à la pression d'indexation qui s'est accumulée depuis le dernier démarrage d'OpenSearch Service.
• Réplique d'écriture refusée : Nombre total de rejets survenus sur les fragments de réplique en raison de la pression d'indexation. Ces rejets sont dus à la pression d'indexation qui s'est accumulée depuis le dernier démarrage d'OpenSearch Service.
• **File d’'écriture de Threadpool :**Le nombre de tâches en file d'attente dans le pool de threads d'écriture. Cette métrique vous indique si une demande est rejetée en raison d'une utilisation élevée du processeur ou d'une forte concurrence d'indexation.
• **ThreadPoolWrite a été rejeté :**Nombre de tâches rejetées dans le pool de fils d'écriture.
  Remarque : La taille de la file d’attente d'écriture par défaut a été augmentée de 200 à 10 000 dans la version 7.9 d'OpenSearch Service. Par conséquent, cette métrique n'est plus le seul indicateur des rejets de la part d'OpenSearch Service. Utilisez les métriques CoordinatingWriteRejected, PrimaryWriteRejected et ReplicaWriteRejected pour surveiller les rejets dans les versions 7.9 et ultérieures.
• File de recherche ThreadPool : Le nombre de tâches en file d'attente dans le pool de fils de recherche. Si la taille de la file d'attente est constamment élevée, envisagez de dimensionner votre cluster. La taille maximale de la file de recherche est de 1 000.
• Recherche dans le pool de threads rejetée : Le nombre de tâches rejetées dans le pool de fils de recherche. Si ce nombre augmente continuellement, envisagez de faire évoluer votre cluster.
• Pression de la mémoire JVM : La pression de mémoire de la JVM indique le pourcentage du tas Java dans un nœud de cluster. Si la pression de mémoire de la JVM atteint 75 %, OpenSearch Service lance le ramasse-miettes CMS (Concurrent Mark Sweep). La collecte des déchets est un processus gourmand en ressources CPU. Si la pression sur la mémoire de la JVM reste à ce pourcentage pendant quelques minutes, vous risquez de rencontrer des problèmes de performances du cluster. Pour plus d'informations, consultez la section Comment résoudre les problèmes de pression de mémoire élevée sur la machine virtuelle Java sur mon cluster Amazon OpenSearch Service ?

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

Pour plus d'informations sur la surveillance de votre cluster OpenSearch Service avec CloudWatch, consultez Métriques de l’instance.

Fils actifs et file d'attente

En cas de manque de processeurs ou de forte simultanéité des demandes, une file d'attente peut se remplir rapidement, ce qui entraîne une erreur HTTP 429. Pour surveiller les threads de votre file d'attente, consultez les métriques ThreadPoolSearchQueue et ThreadPoolWriteQueue dans CloudWatch.

Pour vérifier que vos threads actifs et de file d'attente pour tout rejet 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 rejetées et complété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 colonnes explicites de l'API Cat Thread Pool sur le site Web d'Elasticsearch.

Remarque : La file d'attente groupée 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.

Erreurs liées aux refus 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 sont remplies au maximum de tâches. Par conséquent, votre demande de recherche peut être rejetée. Vous pouvez configurer les journaux d'OpenSearch Service de manière à ce que ces messages d'erreur apparaissent dans vos journaux de lenteur de recherche.

Remarque : Pour éviter des frais supplémentaires, fixez votre seuil de lenteur de journalisation à un montant généreux. Par exemple, si la plupart de vos requêtes prennent 11 secondes et que votre seuil est de « 10 », OpenSearch Service met plus de temps à écrire un journal. Vous pouvez éviter cette surcharge en réglant votre seuil de lenteur de journalisation à 20 secondes. Ensuite, seul un faible pourcentage des requêtes les plus lentes (qui prennent plus de 11 secondes) est enregistré.

Une fois que votre cluster est configuré pour transmettre les journaux de recherche lents à CloudWatch, définissez un seuil spécifique pour la génération de journaux lents. Vous pouvez définir un seuil spécifique pour la lenteur de la génération de journaux à l'aide de l'appel HTTP POST suivant :

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

Rédiger des refus

Un message d'erreur 429 correspondant à un rejet d'écriture indique une erreur de file d'attente groupée. Le paramètre es_rejected_execution_exception[bulk] indique que votre file d'attente est pleine et que toute nouvelle demande est rejetée. Cette erreur de file d'attente groupée se produit lorsque le nombre de demandes adressées au cluster dépasse la taille de la file d'attente groupée (threadpool.bulk.queue_size). Une file d'attente groupée sur chaque nœud peut contenir entre 50 et 200 demandes, selon la version d'Elasticsearch que vous utilisez.

Vous pouvez configurer les journaux d'OpenSearch Service de manière à ce que ces messages d'erreur apparaissent dans les journaux de lenteur de votre index.

Remarque : Pour éviter des frais supplémentaires, fixez votre seuil de lenteur de journalisation à un montant généreux. Par exemple, si la plupart de vos requêtes prennent 11 secondes et que votre seuil est de « 10 », OpenSearch Service mettra plus de temps à écrire un journal. Vous pouvez éviter cette surcharge en réglant votre seuil de lenteur de journalisation à 20 secondes. Ensuite, seul un faible pourcentage des requêtes les plus lentes (qui prennent plus de 11 secondes) est enregistré.

Une fois que votre cluster est configuré pour transmettre les journaux de recherche lents à CloudWatch, définissez un seuil spécifique pour la génération de journaux lents. Pour définir un seuil spécifique pour la lenteur de la génération de journaux, utilisez l'appel HTTP POST suivant :

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

Rédiger les meilleures pratiques de rejet

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

• Lorsque les documents sont indexés plus rapidement, la file d'écriture a moins de chances d'atteindre sa capacité maximale.
• Réglez la taille de la masse en fonction de votre charge de travail et des performances souhaitées. Pour plus d'informations, voir Optimiser la vitesse d'indexation sur le site Web d'Elasticsearch.
• Ajoutez une logique de nouvelle tentative exponentielle à la logique de votre application. La logique de nouvelle tentative exponentielle garantit que les demandes ayant échoué sont automatiquement réessayées.
  Remarque : Si votre cluster est continuellement confronté à un nombre élevé de demandes simultanées, la logique de nouvelles tentatives exponentielle ne vous aidera pas à résoudre l'erreur 429. Utilisez cette bonne pratique en cas de pic de trafic soudain ou occasionnel.
• Si vous ingérez des données depuis Logstash, ajustez le nombre de travailleurs et la taille en bloc. Il est recommandé de définir votre taille globale entre 3 et 5 Mo.

Pour plus d'informations sur le réglage des performances d'indexation, consultez la section Comment puis-je améliorer les performances d'indexation sur mon cluster OpenSearch Service ?

Bonnes pratiques en matière de rejet des recherches

Voici quelques bonnes pratiques qui permettent d'atténuer les rejets de recherche :

• Passez à un type d'instance plus important. Le service OpenSearch s'appuie fortement sur le cache du système de fichiers pour obtenir des résultats de recherche plus rapides. Le nombre de threads du pool de threads sur chaque nœud pour les demandes de recherche est égal au suivant : int((nombre de processeurs_processeurs disponibles * 3) / 2) + 1. Passez à une instance dotée d'un plus grand nombre de processeurs virtuels pour obtenir davantage de threads afin de traiter les demandes de recherche.
• Activez les journaux de lenteur de recherche pour un index donné ou pour tous les indices dont la valeur de seuil est raisonnable. Vérifiez quelles requêtes prennent le 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 la section Résolution des problèmes liés aux recherches dans Elasticsearch, pour les débutants ou pour les réglages avancés : Recherche et correction de requêtes Elasticsearch lentes sur le site Web d'Elasticsearch.