Partager via

Antimodèle : voisin bruyant

Azure

Les systèmes multi-locataires partagent des ressources entre deux ou plusieurs locataires. Étant donné que les locataires utilisent les mêmes ressources partagées, l’activité d’un locataire peut affecter négativement l’utilisation d’un autre locataire du système.

Contexte et problème

When you build a service that multiple customers or tenants share, you can build it to be multitenanted. L’un des avantages des systèmes multilocataires est que les ressources peuvent être groupées et partagées entre locataires. Ce partage de ressources entraîne souvent des coûts inférieurs et une amélioration de 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. The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.

Prenons un exemple de système mutualisé qui a 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, la demande totale de ressources est supérieure à la capacité du système :

Diagramme montrant l’utilisation des ressources de deux locataires.

Il est probable que le locataire dont la demande arrive en premier est prioritaire. Ensuite, l’autre locataire peut rencontrer un problème de voisin bruyant. Les performances peuvent également se dégrader pour les deux locataires.

Le problème de voisin bruyant se produit également lorsque chaque locataire individuel consomme uniquement une petite partie de la capacité du système. Toutefois, l’utilisation combinée des ressources de nombreux locataires peut entraîner un pic d’utilisation globale :

Diagramme montrant trois locataires, chacun utilisant moins de débit maximal. Ensemble, ils consomment entièrement les ressources système totales.

Ce scénario peut se produire lorsque vous avez plusieurs locataires qui ont tous des modèles d’utilisation similaires ou lorsque vous n’avez pas provisionné une capacité suffisante pour la charge collective sur le système.

Solution

Le partage d’une seule ressource entraîne intrinsèquement le risque de problèmes de voisin bruyant que vous ne pouvez pas éviter complètement. Toutefois, il existe certaines étapes que les clients et les fournisseurs de services peuvent prendre pour réduire la probabilité de problèmes de voisins bruyants ou pour atténuer leurs effets.

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. 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 d’autres locataires. This step might take the form of quota enforcement through the Throttling pattern or the Rate Limiting pattern.

  • Approvisionnez plus d’infrastructures. Ce processus peut inclure un scale-up en mettant à niveau certains de vos composants de solution. Or it might include scaling out by provisioning extra shards if you follow the Sharding pattern, or stamps if you follow the Deployment Stamps pattern.

  • Envisagez d’autoriser les locataires à acheter une capacité de réserve ou pré-approvisionnée. Cette approche donne aux locataires une plus grande confiance que votre solution peut gérer de manière fiable leurs charges de travail.

  • Équilibrez l’utilisation des ressources du locataire. 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 complémentaires sur plusieurs tampons pour aplatir les pics de leur 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 manière asynchrone à des heures creuses pour préserver votre capacité de ressources pour les charges de travail sensibles au temps.

  • Vérifiez que vos services en aval fournissent des contrôles pour atténuer des problèmes de voisin bruyant. For example, when you use Kubernetes, consider using pod limits. Lorsque vous utilisez Azure Service Fabric, envisagez d’utiliser les fonctionnalités de gouvernance intégrées.

  • Limitez les opérations que les locataires peuvent effectuer. Par exemple, empêchez les locataires d’effectuer des opérations qui exécutent des requêtes de base de données très volumineuses, par exemple en spécifiant un nombre maximal d’enregistrements pouvant être retournés ou une limite de temps sur les requêtes. Ou modifiez ces opérations pour qu’elles soient asynchrones et planifiez-les pour qu’elles s’exécutent à des heures creuses. Cette action atténue le risque que les locataires prennent des actions susceptibles d’affecter négativement d’autres locataires.

  • Fournir un système de qualité de service (QoS). Lorsque vous appliquez qoS, vous hiérarchiser certains processus ou charges de travail avant d’autres processus ou charges de travail. 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.

Considerations

Dans la plupart des cas, les locataires individuels n’ont pas l’intention de provoquer des problèmes de voisins bruyants. Les locataires individuels peuvent ne pas savoir que leurs charges de travail provoquent des problèmes de voisins bruyants pour d’autres locataires. Toutefois, certains locataires peuvent exploiter des vulnérabilités dans des composants partagés pour attaquer un service, individuellement ou en effectuant une attaque par déni de service distribué.

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, une limitation et des contrôles de gouvernance pour atténuer le problème.

Note

Soyez transparent avec les clients concernant les mécanismes de limitation ou les quotas d’utilisation que vous appliquez. Il est important qu’ils gèrent correctement les demandes ayant échoué et qu’ils ne sont pas pris de garde par des limitations.

Comment détecter le problème

Du point de vue d’un client, le problème de voisin bruyant se manifeste généralement comme des demandes ayant échoué au service ou en tant que demandes qui prennent beaucoup de temps. Plus précisément, si la même requête réussit à d’autres moments et semble échouer de façon aléatoire, il peut y avoir un problème de voisin bruyant. Les applications clientes doivent enregistrer les données de télémétrie pour suivre le taux de réussite et les performances des demandes adressées aux services. Les applications doivent également enregistrer les métriques de performances de référence à des fins de comparaison.

Pour les services Basés sur Azure, passez en revue les limites, quotas et contraintes d’abonnement Azure pour comprendre les limites et les quotas qui s’appliquent à chaque composant Azure de votre solution.

Du point de vue d’un service, le problème de voisin bruyant peut apparaître de la manière suivante.

  • Pics d’utilisation des ressources : Il est important de comprendre clairement votre utilisation normale des ressources de référence et de configurer la surveillance et les alertes pour détecter les pics. Tenez compte de toutes les ressources susceptibles d’affecter les performances ou la disponibilité de votre service. Ces ressources incluent des métriques telles que l’utilisation du processeur du serveur et de la mémoire, l’entrée et la sortie du disque, l’utilisation de la base de données et le trafic réseau. Vous devez également surveiller les métriques exposées par les services managés, notamment les indicateurs de performances synthétiques ou abstraits tels que les unités de requête Azure Cosmos DB.

  • Échecs lors de l’exécution d’une opération pour un locataire : Recherchez les défaillances qui se produisent lorsqu’un locataire ne consomme pas une grande partie des ressources du système. Ce modèle peut indiquer que le locataire rencontre un problème de voisin bruyant. Suivez la consommation des ressources par locataire. Par exemple, lorsque vous utilisez Azure Cosmos DB, consignez les unités de requête pour chaque requête et incluez l’identificateur du locataire dans la télémétrie afin de pouvoir agréger l’utilisation de l’unité de requête pour chaque locataire.

Contributors

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Principal author:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

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