Antipatroon Noisy Neighbor
Multitenant-systemen delen resources tussen tenants. Dit betekent dat de activiteit van de ene tenant een negatieve invloed kan hebben op het gebruik van het systeem van een andere tenant.
Beschrijving van het probleem
Wanneer u een service bouwt die moet worden gedeeld door meerdere klanten of tenants, kunt u deze zo bouwen dat deze multitenant is. Een voordeel van multitenant-systemen is dat resources kunnen worden gepoold en gedeeld tussen tenants. Dit leidt vaak tot lagere kosten en verbeterde efficiëntie. Als één tenant echter een onevenredige hoeveelheid beschikbare resources in het systeem gebruikt, kunnen de algehele prestaties van het systeem hier last van hebben. Het ruisprobleem treedt op wanneer de prestaties van de ene tenant verslechteren vanwege de activiteiten van een andere tenant.
Denk aan een voorbeeld van een multitenant-systeem met twee tenants. De gebruikspatronen van tenant A en de gebruikspatronen van tenant B vallen samen, wat betekent dat het totale resourcegebruik tijdens pieken hoger is dan de capaciteit van het systeem:
Het is waarschijnlijk dat elke tenantaanvraag die het eerst is binnengekomen, voorrang krijgt en dat de andere tenant een ruisprobleem krijgt. Beide tenants kunnen ook last hebben van prestatieverbeteringen.
Het ruisprobleem treedt ook op wanneer elke afzonderlijke tenant relatief kleine hoeveelheden van de capaciteit van het systeem verbruikt, maar het collectieve resourcegebruik van veel tenants resulteert in een piek in het totale gebruik:
Dit kan gebeuren wanneer u meerdere tenants hebt met vergelijkbare gebruikspatronen of wanneer u onvoldoende capaciteit hebt ingericht voor de collectieve belasting van het systeem.
Het probleem oplossen
Ruisproblemen vormen een inherent risico in multitenant-systemen en het is niet mogelijk om de kans dat ze worden beïnvloed door een ruisende buur volledig te elimineren. Er zijn echter enkele stappen die zowel clients als serviceproviders kunnen nemen om de kans op ruisproblemen te verminderen of om de effecten ervan te beperken wanneer ze worden waargenomen.
Acties die clients kunnen uitvoeren
- Koop gereserveerde capaciteit, indien beschikbaar. Als u bijvoorbeeld een Cosmos DB, koopt u gereserveerde doorvoer en bij het gebruik van ExpressRoute, moet u afzonderlijke circuits inrichten voor omgevingen die gevoelig zijn voor prestaties.
- Migreert naar een exemplaar met één tenant van de service of naar een servicelaag met sterkere isolatiegaranties. Als u bijvoorbeeld Service Bus gebruikt, migreert u naar de Premium-laagen bij het gebruik van Azure Cache voor Redis u een cache voor de Standard- of Premium-laag in.
- Zorg ervoor dat uw toepassing servicebeperking verwerktom onnodige aanvragen naar de service te verminderen.
Acties die serviceproviders kunnen uitvoeren
- Controleer het resourcegebruik voor uw systeem, zowel voor het algemeen als voor elke tenant. Configureer waarschuwingen om pieken in resourcegebruik te detecteren en configureer, indien mogelijk, automatisering om bekende problemen automatisch te verhelpen door omhoog of uit te schalen.
- Pas resourcebeheer toe om één tenant te voorkomen die het systeem overstelpen en de capaciteit voor anderen vermindert. Dit kan de vorm hebben van het afdwingen van quotums, via het patroon Beperking of het patroon Snelheidsbeperking.
- Overweeg om meer infrastructuur in terichten. Dit kan gepaard gaan met omhoog schalen door een upgrade uit te brengen van een aantal van uw oplossingsonderdelen, of om uit te schalen door extra shards in terichten, als u het Sharding-patroonof stempels volgt, als u het patroon Implementatiestempels volgt.
- Overweeg tenants toe te staan vooraf inrichtende of gereserveerde capaciteit aan te schaffen. Dit biedt tenants meer zekerheid dat uw oplossing de workload adequaat verwerkt.
- Overweeg methoden om het resourcegebruik te verminderen:
- Als u meerdere exemplaren van uw oplossing host, kunt u tenants opnieuw in balans brengen over de instanties of stempels. U kunt bijvoorbeeld tenants met voorspelbare en vergelijkbare gebruikspatronen op meerdere stempels plaatsen om de pieken in het gebruik af te vlakken.
- Overweeg of u achtergrondprocessen of resource-intensieve workloads hebt die niet tijdgevoelig zijn. Voer deze asynchroon uit tijdens daluren, om uw piekresourcecapaciteit voor tijdgevoelige workloads te behouden.
- Overweeg of uw services besturingselementen bieden om ruisproblemen te verhelpen. Als u bijvoorbeeld Kubernetes gebruikt,kunt u podlimieten gebruiken. Wanneer u Service Fabric gebruikt, kunt u overwegen om de ingebouwde governancemogelijkheden te gebruiken.
- Overweeg, indien van toepassing, de bewerkingen te beperken die tenants kunnen uitvoeren. U kunt bijvoorbeeld voorkomen dat tenants bewerkingen uitvoeren die zeer grote databasequery's uitvoeren. Dit vermindert het risico dat tenants acties uitvoeren die een negatieve invloed kunnen hebben op andere tenants.
- Indien van toepassing, kunt u overwegen om een Quality of Service (QoS)-systeem op te geven. Wanneer u QoS toe passen, geeft u prioriteit aan sommige processen of workloads vóór andere. Door QoS in uw ontwerp en architectuur te factoreren, kunt u ervoor zorgen dat bewerkingen met hoge prioriteit voorrang krijgen wanneer uw resources onder druk staan.
Overwegingen
- In de meeste gevallen veroorzaken afzonderlijke tenants geen ruisproblemen. Afzonderlijke tenants zijn er mogelijk niet eens van op de hoogte dat hun workloads ruisproblemen veroorzaken voor anderen.
- Het is echter ook mogelijk dat tenants beveiligingsproblemen in gedeelde onderdelen gebruiken om een service aan te vallen, afzonderlijk of door een DDoS-aanval (Distributed Denial of Service) uit te voeren.
- Ongeacht de oorzaak is het belangrijk om deze problemen te behandelen als problemen met resourcebeheer en om gebruiksquota, beperking en beheercontroles toe te passen om het probleem te verhelpen.
Notitie
Zorg ervoor dat u uw klanten vertelt over eventuele beperkingen die u wilt toepassen of over eventuele gebruiksquota voor uw service. Het is belangrijk dat ze op betrouwbare wijze mislukte aanvragen verwerken en dat ze niet worden vervangen door beperkingen of quota die u van toepassing bent.
Het probleem vaststellen
Vanuit het perspectief van een client manifesteert het probleem met ruis meestal als mislukte serveraanvragen of aanvragen die lang duren. Met name als dezelfde aanvraag op andere momenten slaagt en willekeurig lijkt te mislukken, is er mogelijk een probleem met ruis. Clienttoepassingen moeten telemetriegegevens registreren om het slagingspercentage en de prestaties van de aanvragen voor services bij te houden, en de toepassingen moeten ook metrische basislijnprestatiegegevens registreren voor vergelijkingsdoeleinden.
Vanuit het perspectief van een service kan het probleem met ruis op verschillende manieren worden weergegeven:
- Pieken in resourcegebruik. Het is belangrijk dat u een duidelijk inzicht hebt in uw normale basislijnresourcegebruik en dat u bewaking en waarschuwingen configureert om pieken in resourcegebruik te detecteren. Zorg ervoor dat u alle resources overweegt die van invloed kunnen zijn op de prestaties of beschikbaarheid van uw service. Deze omvatten metrische gegevens zoals server-CPU en geheugengebruik, schijf-IO, databasegebruik, netwerkverkeer en metrische gegevens die beschikbaar worden gemaakt door beheerde services, zoals het aantal aanvragen en de synthetische en abstracte prestatiemetrieken, zoals de Azure Cosmos DB-aanvraageenheden.
- Fouten bij het uitvoeren van een bewerking voor een tenant, zelfs wanneer die tenant geen groot deel van de resources van het systeem gebruikt. Een dergelijk patroon kan erop wijzen dat de tenant het slachtoffer is van het probleem met de ruis van de buren. Overweeg het resourceverbruik per tenant bij te houden. Wanneer u bijvoorbeeld Azure Cosmos DB gebruikt, kunt u overwegen om de aanvraageenheden die voor elke aanvraag worden gebruikt te registreren en de tenant-id als dimensie toe te voegen aan de telemetrie, zodat u het verbruik van de aanvraageenheid voor elke tenant kunt aggregeren.