Modifier

Partager via

Antimodèle : voisin bruyant

Azure

Les systèmes multi-locataires partagent des ressources entre deux ou plusieurs locataires. Du fait que les locataires utilisent les mêmes ressources partagées, l’activité d’un locataire peut avoir un impact négatif sur l’utilisation du système par un autre locataire.

Description du problème

Lorsque vous créez un service qui doit être partagé par plusieurs clients ou locataires, vous pouvez le créer pour qu’il soit multi-locataire. L’un des avantages des systèmes multilocataires est que les ressources peuvent être groupées et partagées entre locataires. Cela permet souvent de réduire les coûts et d’améliorer l’efficacité. Toutefois, si un même locataire utilise une quantité disproportionnée des ressources disponibles dans le système, les performances globales du système peuvent être affectées. Le problème de voisin bruyant se produit quand les performances d’un locataire sont dégradées en raison des activités d’un autre locataire.

Prenons l’exemple d’un système multilocataire avec deux locataires. Les modèles d’utilisation du locataire A et ceux du locataire B coïncident. Aux heures de pointe, le locataire A utilise toutes les ressources du système, ce qui signifie que toutes les requêtes faites par le locataire B échouent. En d’autres termes, l’utilisation totale des ressources est supérieure à la capacité du système :

Illustration montrant l’utilisation des ressources de deux locataires. Le locataire A consomme l’ensemble complet des ressources du système, ce qui signifie que le locataire B connaît des défaillances.

Il est probable que la requête du locataire qui arrive en premier aura la priorité. L’autre locataire aura alors un problème de voisin bruyant. Il est également possible que les performances des deux locataires soient affectées.

Le problème de voisin bruyant peut même se produire si chaque locataire individuel consomme des quantités relativement faibles de la capacité du système. En effet, l’utilisation collective des ressources par plusieurs locataires peut entraîner un pic de l’utilisation globale :

Figure avec trois locataires, chacun consommant moins que le débit maximal de la solution. Au total, les trois locataires consomment la totalité des ressources du système.

Cette situation peut se produire lorsque vous avez plusieurs locataires ayant tous des modèles d’utilisation similaires, ou lorsque vous n’avez pas approvisionné suffisamment de capacité pour la charge collective sur le système.

Comment corriger le problème

Les problèmes de voisin bruyant sont un risque inhérent lorsque vous partagez une seule ressource, et il n’est pas possible d’éliminer complètement la possibilité d’être affecté par un voisin bruyant. Cependant, les clients et les fournisseurs de services peuvent prendre des mesures pour réduire le risque lié à des problèmes de voisin bruyant ou atténuer leurs effets lorsqu’ils les constatent.

Actions que les clients peuvent effectuer

Actions que les fournisseurs de services peuvent effectuer

  • Surveillez l’utilisation des ressources pour votre système. Surveillez l’utilisation globale des ressources et les ressources utilisées par chaque locataire. Configurez des alertes pour détecter les pics d’utilisation des ressources et, si possible, configurez l’automatisation pour atténuer automatiquement les problèmes connus en effectuant un scale-up ou un scale-out.
  • Appliquez la gouvernance des ressources. Envisagez d’appliquer des stratégies qui empêchent un seul locataire de surcharger le système et de réduire la capacité disponible pour les autres. Cette étape peut prendre la forme d’une application de quotas par le biais du modèle de limitation ou du modèle de limitation de débit.
  • Approvisionnez plus d’infrastructures. Ce processus peut nécessiter un scale-up, pour mettre à niveau certains composants de votre solution, ou un scale-out, pour approvisionner d’autres partitions (si vous suivez le modèle de partitionnement) ou empreintes (si vous suivez le modèle d’empreintes de déploiement).
  • Envisagez d’autoriser les locataires à acheter une capacité de réserve ou pré-approvisionnée. Cette capacité permet aux locataires de savoir avec plus de certitude que votre solution gère correctement leur charge de travail.
  • Lissez l’utilisation des ressources des locataires. Par exemple, vous pouvez essayer l’une des approches suivantes :
    • Si vous hébergez plusieurs instances de votre solution, pensez à rééquilibrer les locataires entre les instances ou empreintes. Par exemple, envisagez de placer des locataires avec des modèles d’utilisation prévisibles et similaires sur plusieurs empreintes afin d’atténuer les pics d’utilisation.
    • Déterminez si vous avez des processus en arrière-plan ou des charges de travail gourmandes en ressources qui ne sont pas urgents. Exécutez ces charges de travail de façon asynchrone aux heures creuses afin de conserver la capacité maximale de vos ressources pour les charges de travail urgentes.
  • Vérifiez que vos services en aval fournissent des contrôles pour atténuer des problèmes de voisin bruyant. Par exemple, quand vous utilisez Kubernetes, envisagez d’utiliser des limites de pod et, quand vous utilisez Service Fabric, envisagez d’utiliser les fonctionnalités de gouvernance intégrées.
  • Limitez les opérations que les locataires peuvent effectuer. Par exemple, restreindre les locataires d’exécuter des opérations qui lanceront des requêtes de bases de données très volumineuses, comme en spécifiant un nombre maximal d’enregistrements retournables ou une limite de temps sur les requêtes. Cette action atténue le risque que les locataires effectuent des actions susceptibles d’impacter négativement les autres locataires.
  • Fournissez un système Qualité de service (QoS). Quand vous appliquez QoS, certains processus ou charges de travail ont priorité sur d’autres. En factorisant QoS dans votre conception et votre architecture, vous pouvez faire en sorte que les opérations cruciales sont traitées en priorité quand vos ressources sont sous pression.

Considérations

Dans la plupart des cas, les locataires individuels n’ont pas l’intention de causer des problèmes de voisin bruyant. Il est même possible qu’ils ne soient pas conscients que leurs charges de travail entraînent des problèmes de voisin bruyant pour d’autres. Cependant, il est également possible que certains locataires exploitent les vulnérabilités des composants partagés pour attaquer un service, soit individuellement, soit en exécutant une attaque par déni de service distribué (DDoS).

Quelle que soit la cause, il est important de traiter ces problèmes comme des problèmes de gouvernance des ressources, et d’appliquer des quotas d’utilisation, des limitations et des contrôles de gouvernance pour atténuer le problème.

Notes

Veillez à informer vos clients des limitations que vous appliquez ou des quotas d’utilisation sur votre service. Il est important qu’ils puissent traiter de manière fiable les demandes ayant échoué et qu’ils ne soient pas surpris par les limitations ou les quotas que vous appliquez.

Comment détecter le problème

Du point de vue du client, le problème de voisin bruyant se manifeste généralement par des requêtes échouées au service, ou par des requêtes prenant beaucoup de temps à s’exécuter. En particulier, si une même requête réussit à certains moments et semble échouer à d’autres de manière aléatoire, il est possible que vous ayez affaire à un problème de voisin bruyant. Les applications clientes doivent enregistrer la télémétrie pour suivre le taux de réussite et les performances des demandes adressées aux services, et les applications doivent également enregistrer les métriques des performances de base à des fins de comparaison.

Du point de vue d’un service, le problème de voisin bruyant peut se manifester de plusieurs façons :

  • Pics d’utilisation des ressources. Il est important de bien comprendre l’utilisation normale de vos ressources de base et de configurer la supervision et les alertes pour détecter les pics d’utilisation des ressources. Veillez à prendre en compte toutes les ressources susceptibles d’affecter les performances ou la disponibilité de votre service. Ces ressources comprennent des métriques telles que l’utilisation de l’UC et de la mémoire du serveur, les E/S de disque, l’utilisation de la base de données et le trafic, ainsi que les métriques exposées par les services gérés (comme le nombre de demandes) et les métriques de performances synthétiques et abstraites (comme les unités de demande Azure Cosmos DB).
  • Défaillances lors de l’exécution d’une opération pour un locataire. En particulier, recherchez des défaillances qui se produisent lorsqu’un locataire n’utilise pas une grande partie des ressources du système. Un tel modèle peut indiquer que le locataire est victime du problème de voisin bruyant. Songez à faire le suivi de la consommation des ressources par locataire. Par exemple, quand vous utilisez Azure Cosmos DB, envisagez de consigner les unités de demande utilisées pour chaque demande et ajoutez l’identificateur du locataire en tant que dimension à la télémétrie afin de pouvoir agréger la consommation d’unités de demande pour chaque locataire.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.