Les applications modernes doivent rester disponibles même en cas de pics soudains de trafic ou de consommation disproportionnée de ressources par les Requête. MongoDB Atlas est conçu pour offrir une haute disponibilité, mais dans la pratique, celle-ci ne se limite pas à la simple résistance aux pannes d’hôte ou à l’élection de replica set. Il s’agit également de la façon dont un cluster se comporte lorsque la demande dépasse ce qu’il peut traiter en toute sécurité.
La semaine dernière, nous avons annoncé Intelligent Workload Management (IWM) comme étant GA dans MongoDB 9.0. IWM est une fonctionnalité de disponibilité managed qui assure la réactivité et la prévisibilité des clusters Atlas même en cas de surcharge. IWM met en file d’attente les pics transitoires, assure la fluidité des opérations de courte durée et la stabilité des opérations de longue durée, et protège l’intégrité du cluster sans aucune modification de l’application.
Les événements de surcharge se produisent souvent plus rapidement que l’infrastructure ne peut se répartir. Même si la mise à l'échelle est activée, l’approvisionnement en capacité supplémentaire prend du temps. Dans The Gap entre une augmentation du trafic et la disponibilité d’une nouvelle capacité, un cluster peut devenir instable si chaque demande est traitée de la même manière et que les clients réessayent de manière agressive. IWM est conçu pour combler The Gap en préservant l’intégrité du cluster, en optimisant les performances et en transformant ce qui serait une panne imprévisible en un événement contrôlé et observable.
Chez Coinbase, le volume des transactions peut monter en flèche en quelques minutes, et nos systèmes doivent être en mesure de répartir les charges en temps réel sous peine d'en faire pâtir les clients. Intelligent Workload Management nous donne l'assurance que nos clusters resteront réactifs lors des fenêtres de trading de pointe.
”En cas de surcharge prolongée, les clients peuvent activer le « Load Shedding » pour rejeter le surplus d’opérations. IWM permet de gérer la pression pendant qu'un pic passe ou qu'une capacité est ajoutée ; il n'augmente pas la capacité et ne remplace pas la mise à l'échelle automatique ou la planification des capacités.
Figure 1. La gestion intelligente des charges de travail (Intelligent Workload Management) permet de garder les clusters réactifs et prévisibles.
Gérer la pression sur la charge de travail pendant que la capacité se rattrape
Les pics de trafic et les opérations intensives en ressources peuvent faire augmenter la demande plus rapidement que l’infrastructure ne peut se répartir. Même lorsque la mise à l’échelle automatique est activée, l’approvisionnement de capacités supplémentaires prend du temps. Les tentatives répétées des clients peuvent ajouter une pression alors qu’un cluster est déjà occupé.
IWM aide à managed la pression sur la charge de travail pendant cette période. Il fonctionne avec ou sans mise à l’échelle : lorsque la mise à l’échelle est activée, IWM aide à maintenir la stabilité du cluster à mesure que la capacité devient disponible ; sans lui, IWM managed le travail à la capacité provisionnée du cluster. Pour une demande soutenue ou croissante, l'ajout de capacité peut encore être nécessaire.
Comment l’IWM réagit à la pression de la charge de travail
Lorsqu’un cluster est sain, IWM est pratiquement invisible. Lorsque la demande dépasse ce que le cluster peut traiter en toute sécurité, IWM managed la pression par étapes :
- Il limite le travail entrant et met en file d’attente les demandes excédentaires : par défaut, IWM met en file d’attente les demandes excédentaires plutôt que de les rejeter de manière proactive. Cela peut aider à absorber les pics transitoires, bien que les demandes mises en file d’attente puissent mettre plus de temps à se terminer lorsque les ressources sont limitées. La mise en file d’attente modifie le moment où le travail est traité, et non la quantité de travail que l’application demande finalement au cluster d’effectuer.
- Elle permet de maintenir la fluidité des opérations de courte durée : une opération de courte durée, telle qu’une opération de lecture ou d’écriture classique, et une opération de longue durée, telle qu’une Requête de rapport volumineuse, ne sollicitent pas le cluster de la même manière. Lorsque les ressources sont limitées, l'IWM permet aux opérations à exécution rapide de continuer à progresser, tout en gérant les opérations à exécution longue de manière plus prudente.
- Elle permet de gérer la pression sur les ressources : La fragmentation de la mémoire, le déséquilibre du cache et l’épuisement du stockage peuvent tous déstabiliser un cluster sain. L’IWM ajuste la gestion de la mémoire et du cache des clusters lorsqu’il détecte des tendances malsaines et peut suspendre les nouvelles écritures tout en autorisant les lectures lorsque l’utilisation du stockage atteint des niveaux critiques.
Ces protections aident à préserver l’intégrité du cluster en cas de surcharge. Elles ne rendent pas la capacité illimitée et ne remplacent pas une bonne indexation, une planification de la capacité ou la mise à l’échelle automatique.
Protections par défaut et délestage en option
Les protections par défaut d’IWM sont activées sans coût supplémentaire sur les clusters Atlas dédiés éligibles exécutant MongoDB 9.0. Elles ne nécessitent aucune modification de l’application ou mise à niveau du pilote. Par défaut, IWM managed la surcharge sans rejeter activement les excès de travail.
Le délestage de charge (Load Shedding) est un contrôle facultatif distinct pour la surcharge durable. S’il est activé, il peut rejeter les opérations excédentaires, et ces rejets sont visibles par votre application comme des erreurs de surcharge. Le délestage de charge est disponible sans frais supplémentaires pour les clusters Atlas éligibles de type replica-set dédiés M30+ exécutant MongoDB 9.0.
Les protections IWM par défaut fonctionnent avec n’importe quel pilote MongoDB. Si vous activez le délestage de charge, utilisez un pilote compatible avec la contre-pression afin que votre application puisse interpréter les signaux de surcharge et appliquer des tentatives limitées avec backoff. Consultez la matrice des pilotes pris en charge avant d’activer le délestage de charge.
Figure 2. La différence entre le paramètre par défaut (mise en file d’attente) et le paramètre « Load Shedding ».
.png)
Comprendre les interventions IWM avec Observability
Dans Atlas, examinez les mesures de limitation du taux d’opération et de limitation du taux de connexion pour les opérations ou connexions mises en file d’attente ou rejetées. Lorsque le délestage est activé, les opérations rejetées apparaissent sous Limitation du taux d’opération. Configurez ou examinez la condition d’alerte IWM pour suivre l’activité IWM pertinente, et consultez le flux d’activité pour les événements liés à IWM. Ensemble, ces surfaces Atlas vous aident à évaluer si la pression persiste et si vous devez revoir les modèles de charge de travail ou augmenter la capacité. En savoir plus sur l’observabilité d’IWM dans Atlas.
Pour les équipes qui évaluent le « Load Shedding » en option, Atlas fournit également un test pour valider la compatibilité des pilotes, la gestion des erreurs de surcharge par l’application et la visibilité opérationnelle avant de se fier à cette commande en production. Lorsqu'ils sont testés sur des cluster de test ou de développement actifs, Atlas rejette aléatoirement un petit pourcentage d'opérations, quelle que soit la charge. Les équipes peuvent suivre les opérations rejetées dans le graphique des métriques et examiner les résultats une fois le test terminé. Étant donné que les applications peuvent rencontrer des erreurs de surcharge lors des tests, les équipes ne doivent utiliser ces tests que pour vérifier le comportement du client. Les équipes ne doivent pas effectuer de tests sur un cluster de production. Apprenez à tester le « Load Shedding ».
Pour plus de détails sur le comportement d’IWM et sur la façon de réagir à une surcharge, consultez la documentation d’IWM.
Prise en main
Vérifiez que votre cluster est un cluster Atlas dédié éligible exécutant MongoDB 9.0.
Décidez si la mise à l’échelle doit ajouter de la capacité lors d’une surcharge prolongée. IWM aide à managed la pression pendant que la capacité supplémentaire devient disponible ; il ne remplace pas la mise à l’échelle ni la planification de la capacité.
Si vous activez le délestage de charge, consultez la matrice des pilotes pris en charge et confirmez que votre application utilise des tentatives limitées avec backoff.
Consultez les tableaux de bord d’observabilité Atlas pour savoir quand l’IWM intervient et quelles charges de travail sont affectées.
Pour aller plus loin
Vous êtes prêt à rendre vos cluster plus prévisibles lors des pics de charge ? Lisez la documentation IWM, découvrez la mise à l’échelle automatique d’Atlas ou inscrivez-vous à MongoDB Atlas pour commencer à créer dès aujourd’hui.