Résilience améliorée avec contre-pression et contrôle d'admission pour Amazon OpenSearch Service | Services Web Amazon

Résilience améliorée avec contre-pression et contrôle d'admission pour Amazon OpenSearch Service | Services Web Amazon

Nœud source: 2723961

Service Amazon OpenSearch est un service géré qui simplifie la sécurisation, le déploiement et l'exploitation des clusters OpenSearch à grande échelle dans le cloud AWS. L'année dernière, nous avons présenté Contre-pression d'indexation des fragments et les controle d'admission, qui surveille les ressources du cluster et le trafic entrant pour rejeter de manière sélective les requêtes qui poseraient autrement des risques de stabilité, comme un manque de mémoire et affecteraient les performances du cluster en raison des conflits de mémoire, de la saturation du processeur et de la surcharge du GC, etc.

Nous sommes maintenant ravis de présenter Search Backpressure et le contrôle d'admission basé sur le processeur pour OpenSearch Service, ce qui améliore encore la résilience des clusters. Ces améliorations sont disponibles pour toutes les versions OpenSearch 1.3 ou supérieures.

Recherche contre-pression

La contre-pression empêche un système d'être submergé par le travail. Pour ce faire, il contrôle le taux de trafic ou en supprimant une charge excessive afin d'éviter les pannes et la perte de données, d'améliorer les performances et d'éviter une panne totale du système.

La contre-pression de recherche est un mécanisme permettant d'identifier et d'annuler les demandes de recherche gourmandes en ressources en cours lorsqu'un nœud est sous la contrainte. Il est efficace contre les charges de travail de recherche avec une utilisation anormalement élevée des ressources (telles que des requêtes complexes, des requêtes lentes, de nombreux accès ou des agrégations lourdes), qui pourraient autrement provoquer des pannes de nœud et affecter la santé du cluster.

Search Backpressure est construit au-dessus du cadre de suivi des ressources de tâche, qui fournit une API facile à utiliser pour surveiller l'utilisation des ressources de chaque tâche. Search Backpressure utilise un thread d'arrière-plan qui mesure périodiquement l'utilisation des ressources du nœud et attribue un score d'annulation à chaque tâche de recherche en cours en fonction de facteurs tels que le temps CPU, les allocations de tas et le temps écoulé. Un score d'annulation plus élevé correspond à une demande de recherche plus gourmande en ressources. Les demandes de recherche sont annulées dans l'ordre décroissant de leur score d'annulation pour récupérer rapidement les nœuds, mais le nombre d'annulations est limité pour éviter un travail inutile.

Le diagramme suivant illustre le workflow de recherche de contre-pression.

Les requêtes de recherche renvoient un code d'état HTTP 429 "Too Many Requests" lors de l'annulation. OpenSearch renvoie des résultats partiels si seules certaines partitions échouent et que des résultats partiels sont autorisés. Voir le code suivant :

{ "error": { "root_cause": [ { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } ], "type": "search_phase_execution_exception", "reason": "SearchTask was cancelled", "phase": "fetch", "grouped": true, "failed_shards": [ { "shard": 0, "index": "nyc_taxis", "node": "9gB3PDp6Speu61KvOheDXA", "reason": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } } ], "caused_by": { "type": "task_cancelled_exception", "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]" } }, "status": 429
}

Surveillance de la contre-pression de recherche

Vous pouvez surveiller l'état détaillé de Search Backpressure à l'aide de l'API node stats :

curl -X GET "https://{endpoint}/_nodes/stats/search_backpressure"

Vous pouvez également afficher le récapitulatif des annulations à l'échelle du cluster à l'aide de Amazon Cloud Watch. Les métriques suivantes sont désormais disponibles dans ES/OpenSearchService espace de noms :

  • RechercherTâcheAnnulé – Le nombre d'annulations de nœud coordinateur
  • RechercheShardTaskAnnulée – Le nombre d'annulations de nœuds de données

La capture d'écran suivante montre un exemple de suivi de ces métriques sur la console CloudWatch.

Contrôle d'admission basé sur le processeur

Le contrôle d'admission est un mécanisme de contrôle d'accès qui limite de manière proactive le nombre de demandes à un nœud en fonction de sa capacité actuelle, à la fois pour les augmentations organiques et les pics de trafic.

En plus de la pression de la mémoire JVM et des seuils de taille des requêtes, il surveille désormais également l'utilisation moyenne mobile du processeur de chaque nœud pour rejeter les appels entrants. _search et les _bulk demandes. Il empêche les nœuds d'être submergés par un trop grand nombre de requêtes entraînant des points chauds, des problèmes de performances, des délais d'expiration des requêtes et d'autres échecs en cascade. Les requêtes excessives renvoient un code d'état HTTP 429 "Too Many Requests" lors du rejet.

Gestion des erreurs HTTP 429

Vous recevrez des erreurs HTTP 429 si vous envoyez un trafic excessif à un nœud. Cela indique soit des ressources de cluster insuffisantes, soit des demandes de recherche gourmandes en ressources, soit un pic involontaire de la charge de travail.

La contre-pression de recherche fournit la raison du rejet, ce qui peut aider à affiner les demandes de recherche gourmandes en ressources. Pour les pics de trafic, nous recommandons de nouvelles tentatives côté client avec une temporisation et une gigue exponentielle.

Vous pouvez également suivre ces guides de dépannage pour déboguer les rejets excessifs :

Conclusion

La contre-pression de recherche est un mécanisme réactif pour éliminer une charge excessive, tandis que le contrôle d'admission est un mécanisme proactif pour limiter le nombre de requêtes à un nœud au-delà de sa capacité. Les deux fonctionnent en tandem pour améliorer la résilience globale d'un cluster OpenSearch.

La contre-pression est disponible dans Opensearch, et nous recherchons toujours apports extérieurs. Vous pouvez vous référer au RFC pour commencer.


À propos des auteurs

Ketan Verma est un SDE senior travaillant sur Amazon OpenSearch Service. Il est passionné par la construction de systèmes distribués à grande échelle, l'amélioration des performances et la simplification d'idées complexes avec des abstractions simples. En dehors du travail, il aime lire et améliorer ses compétences de barista à domicile.

Suresh NS est un SDE senior travaillant sur Amazon OpenSearch Service. Il est passionné par la résolution de problèmes dans les systèmes distribués à grande échelle.

Pritkumar Ladani est un SDE-2 fonctionnant sur Amazon OpenSearch Service. Il aime contribuer au développement de logiciels open source et est passionné par les systèmes distribués. Il est joueur de badminton amateur et aime faire de la randonnée.

Boukhtawar Khan est un ingénieur principal travaillant sur Amazon OpenSearch Service. Il s'intéresse à la construction de systèmes distribués et autonomes. Il est mainteneur et contributeur actif à OpenSearch.

Horodatage:

Plus de Big Data AWS