Architectuurbenaderingen voor kostenbeheer en toewijzing in een multitenant-oplossing

Voor multitenant-oplossingen is vaak speciale overweging vereist wanneer u kosten meet en toewijst en wanneer u kosten optimaliseert. Op deze pagina beschrijven we enkele belangrijke richtlijnen voor oplossingsarchitecten die rekening houden met de meting, toewijzing en optimalisatie van kosten voor een multitenant-toepassing.

Belangrijke overwegingen en vereisten

Houd rekening met de vereisten voor het meten van het verbruik voor uw oplossing. Dit wordt in meer detail besproken over het meten van het verbruik van elke tenant.

Doel van meting

Het is belangrijk om te bepalen wat uw doel is. Hier volgen enkele voorbeelden van doelen:

• Bereken een geschatte kosten voor goederen die voor elke tenant worden verkocht. Als u bijvoorbeeld een aanzienlijk aantal gedeelde resources implementeert, bent u mogelijk alleen geïnteresseerd in een ruwe benadering van de kosten die voor elke tenant worden gemaakt.
• Bereken de exacte kosten die door elke tenant worden gemaakt. Als u bijvoorbeeld uw tenants in rekening brengt voor de exacte hoeveelheid verbruik die ze in rekening brengen, moet u nauwkeurige informatie hebben over de hoeveelheid resources van elke tenant.
• Identificeer uitbijtertenants die aanzienlijk meer kosten dan andere. Als u bijvoorbeeld een vast prijsmodel opgeeft, moet u mogelijk bepalen of tenants een onevenredige hoeveelheid van uw ingerichte capaciteit verbruiken, zodat u beleid voor evenredig gebruik kunt toepassen. In veel situaties is voor deze use-case geen nauwkeurige meting van de kosten vereist.
• Verlaag de totale Azure-kosten voor uw oplossing. U kunt bijvoorbeeld de kosten van elk onderdeel bekijken en vervolgens bepalen of u overbeschikt bent ingericht voor de workload.

Door inzicht te krijgen in het doel van het meten van het verbruik door een tenant, kunt u bepalen of de kostentoewijzingen bij benadering of zeer nauwkeurig moeten zijn, wat van invloed is op de specifieke hulpprogramma's die u kunt gebruiken en de procedures die u kunt volgen.

Gedeelde onderdelen

Mogelijk kunt u de kosten van een multitenant-oplossing verlagen door tenants naar een gedeelde infrastructuur te verplaatsen. U moet echter zorgvuldig rekening houden met de impact van het delen van resources, zoals of uw tenants het probleem met noisy Neighbor gaan ervaren.

U moet ook overwegen hoe u de kosten van gedeelde onderdelen meet en toewijst. U kunt bijvoorbeeld de kosten gelijkmatig verdelen tussen elk van de tenants die gebruikmaken van het gedeelde onderdeel. U kunt ook het gebruik van elke tenant meten om een nauwkeurigere meting te krijgen van het verbruik van gedeelde onderdelen.

Benaderingen en patronen om rekening mee te houden

Kosten toewijzen met behulp van resourcetags

Met Azure kunt u tags toepassen op uw resources. Een tag is een sleutel-waardepaar. U gebruikt tags om aangepaste metagegevens toe te voegen. Tags zijn nuttig voor veel beheerbewerkingen en zijn ook handig voor het analyseren van de kosten van uw Azure-verbruik. Nadat u tags hebt toegepast, kunt u de kosten bepalen die aan elke tag zijn gekoppeld.

De manier waarop u tags in een multitenant-oplossing gebruikt, is waarschijnlijk anders, afhankelijk van uw architectuur.

In sommige oplossingen kunt u toegewezen resources implementeren voor elke tenant, bijvoorbeeld als u toegewezen implementatiestempels voor elke tenant implementeert. In deze situaties is het duidelijk dat elk Azure-verbruik voor deze resources moet worden toegewezen aan die tenant, zodat u uw Azure-resources kunt taggen met de tenant-id.

In andere situaties hebt u mogelijk sets met gedeelde resources. Wanneer u bijvoorbeeld het Sharding-patroon toepast, kunt u meerdere databases implementeren en uw tenants over deze databases verdelen. Overweeg om de resources te taggen met een id voor de groep tenants. U kunt mogelijk niet eenvoudig kosten toewijzen aan één tenant, maar u kunt de kosten ten minste beperken tot een set tenants wanneer u deze benadering gebruikt. U kunt ook de verbruiksgegevens gebruiken om tenants opnieuw te verdelen over de shards, als u merkt dat een specifieke shard hogere kosten met zich brengt dan de andere.

Bekijk een voorbeeld van een multitenant-oplossing die is gebouwd met behulp van het patroon Implementatiestempels en een verticaal gepartitioneerd tenancymodel. Elke implementatiestempel bevat een gedeelde webserver en shard-databases. Tags kunnen worden toegepast op elk van de Azure-onderdelen, zoals wordt weergegeven in het volgende diagram.

De strategie voor taggen die hier wordt gebruikt, is als volgt:

• Elke resource heeft een stamp-id tag.
• Elke shard-database heeft een shard-id tag.
• Elke resource die is toegewezen aan een specifieke tenant heeft een tenant-id tag.

Met deze tagstrategie kunt u de kosteninformatie eenvoudig filteren op één stempel. Het is ook eenvoudig om de kosten van de tenantspecifieke resources te vinden, zoals de totale kosten van de database voor tenant C. Gedeelde onderdelen hebben tenant-id geen tag, maar de kosten van de gedeelde onderdelen voor een stempel kunnen worden verdeeld tussen de tenants die zijn toegewezen om die stempel of shard te gebruiken.

Uw toepassing instrumenteer

In situaties waarin u geen directe relatie hebt tussen een Azure-resource en een tenant, kunt u overwegen uw toepassing te instrumenteren om telemetrie te verzamelen.

Uw toepassingslaag verzamelt mogelijk al logboeken en metrische gegevens die handig zijn om vragen over meten te beantwoorden, bijvoorbeeld:

• Hoeveel API-aanvragen worden er ongeveer per tenant gedaan?
• Welke tijden van de dag zijn specifieke tenants drukst?
• Hoe verhouden de gebruikspatronen van tenant A zich tot de gebruikspatronen van tenant B?

In Azure worden deze metrische gegevens vaak vastgelegd door Application Insights. Met behulp van telemetrie-initialisatiefuncties kunt u de telemetrie verrijken die is vastgelegd door Application Insights, om een tenant-id of andere aangepaste gegevens op te nemen.

Application Insights en andere oplossingen voor logboekregistratie en bewaking zijn echter niet geschikt voor nauwkeurige kostenmeting of voor meetdoeleinden. Application Insights is ontworpen voor voorbeeldgegevens, met name wanneer uw toepassing een groot aantal aanvragen heeft. Steekproeven zijn ontworpen om de kosten voor het bewaken van uw oplossing te verlagen, omdat het vastleggen van elk stukje telemetrie vaak duur kan worden.

Als u nauwkeurige details over verbruik of gebruik wilt bijhouden voor factureringsdoeleinden, moet u in plaats daarvan een aangepaste pijplijn bouwen om de benodigde gegevens te registreren. Vervolgens moet u de gegevens aggregeren op basis van uw vereisten. Azure-services die nuttig kunnen zijn voor dit doel zijn Event Hubs, voor het vastleggen van grote hoeveelheden telemetrie en Stream Analytics, om deze in realtime te verwerken.

Azure-reserveringen en Azure-besparingsplan gebruiken om de kosten te verlagen

Azure-reserveringen: Met Azure-reserveringen kunt u uw Azure-kosten verlagen door vooraf vast te leggen aan een bepaald uitgavenniveau. Reserveringen zijn van toepassing op een aantal Azure-resourcetypen.

Reserveringen kunnen effectief worden gebruikt in een multitenant-oplossing. Let op de volgende overwegingen:

• Wanneer u een multitenant-oplossing met gedeelde resources implementeert, moet u rekening houden met het basisniveau van het verbruik dat u nodig hebt voor de workload. U kunt een reservering voor dat basislijnverbruik overwegen en vervolgens zou u standaardtarieven betalen voor een hoger verbruik tijdens onvoorspelbare pieken.
• Wanneer u resources voor elke tenant implementeert, moet u overwegen of u vooraf het resourceverbruik voor een specifieke tenant of in uw portfolio met tenants kunt doorvoeren.

Met Azure-reserveringen kunt u het bereik van uw reserveringen bepalen om van toepassing te zijn op een resourcegroep, een abonnement of een set abonnementen. Dit betekent dat u kunt profiteren van reserveringen, zelfs als u uw workload in meerdere abonnementen shardt.

Reserveringsbereiken kunnen ook handig zijn wanneer u tenants met onvoorspelbare workloads hebt. Denk bijvoorbeeld aan een oplossing waarin tenant A slechts één exemplaar van een specifieke resource nodig heeft, maar tenants B en C elk twee nodig hebben. Vervolgens wordt tenant B minder druk, dus vermindert u het aantal instanties en tenant A wordt drukker, zodat u het aantal exemplaren verhoogt. Uw reserveringen worden toegepast op de tenants die ze nodig hebben.

Azure-besparingsplan voor rekenkracht: Een Azure-besparingsplan voor rekenkracht is een flexibel kostenbesparende plan dat aanzienlijke besparingen genereert ten opzichte van prijzen voor betalen per gebruik. U gaat akkoord met een contract van één of drie jaar en ontvangt kortingen op in aanmerking komende rekenservices. Deze services omvatten virtuele machines, toegewezen hosts, containerinstanties, Azure Premium-functies en Azure-app-services. Besparingen zijn van toepassing op deze rekenservices, ongeacht de regio, de instantiegrootte of het besturingssysteem. Zie het overzicht van het Azure-spaarplan en de documentatie van het Azure-spaarplan voor meer informatie.

Reserveringen en besparingen combineren: Als u de kosten en flexibiliteit verder wilt optimaliseren, kunt u een Azure-besparingsplan combineren met Azure Reservations.

Antipatroon om te voorkomen

• Kosten worden helemaal niet bijgehouden. Het is belangrijk dat u ten minste een idee hebt van de kosten die u maakt en hoe elke tenant van invloed is op de kosten van het leveren van uw oplossing. Als uw kosten na verloop van tijd veranderen, hebt u geen basislijn om mee te vergelijken. U kunt mogelijk ook niet voorspellen hoe een groei in tenants van invloed is op uw kosten en winstgevendheid.
• Veronderstellingen maken of raden. Zorg ervoor dat uw kostenmeting is gebaseerd op echte informatie. Mogelijk hebt u geen hoge mate van precisie nodig, maar zelfs uw schattingen moeten worden geïnformeerd door echte metingen.
• Onnodige precisie. Mogelijk hoeft u geen gedetailleerde boekhouding te hebben van alle kosten die voor elke tenant worden gemaakt. Het bouwen van onnodig nauwkeurige kostenmetings- en optimalisatieprocessen kan contraproductief zijn, omdat het technische complexiteit toevoegt en broos processen creëert.
• Realtime meting. De meeste oplossingen hebben geen up-to-the-minute kostenmetingen nodig. Omdat meting- en verbruiksgegevens complex kunnen zijn om te verwerken, moet u de benodigde gegevens registreren en vervolgens asynchroon aggregeren en de gegevens later verwerken.
• Bewakingshulpprogramma's gebruiken voor facturering. Zoals beschreven in Instrument your application, moet u ervoor zorgen dat u hulpprogramma's gebruikt die zijn ontworpen voor kostenbewaking en meting. Oplossingen voor toepassingsbewaking zijn doorgaans geen goede kandidaten voor dit type gegevens, met name wanneer u hoge precisie nodig hebt.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

• Sherri Babylon | Senior klanttechnicus, FastTrack voor Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Het verbruik van elke tenant meten