Delen via

Het verbruik van elke tenant meten

  • Artikel

Als oplossingsprovider is het belangrijk om het verbruik van elke tenant in uw multitenant-oplossing te meten. Door het verbruik van elke tenant te meten, kunt u ervoor zorgen dat de kosten van verkochte goederen (COGS) voor het leveren van de service aan elke tenant winstgevend zijn. Op deze pagina bieden we richtlijnen voor technische besluitvormers over het belang van het meten van verbruik en de benaderingen die u kunt overwegen om het verbruik van een tenant te meten, evenals de betrokken compromissen.

Er zijn twee belangrijke aandachtspunten die de noodzaak van het meten van het verbruik van elke tenant stimuleren:

  • U moet de werkelijke kosten meten voor elke tenant. Dit is belangrijk om de winstgevendheid van de oplossing voor elke tenant te bewaken.
  • U moet het bedrag bepalen om de tenant in rekening te brengen wanneer u op verbruik gebaseerde prijzen gebruikt.

Het kan echter lastig zijn om de werkelijke resources te meten die door een tenant in een multitenant-oplossing worden gebruikt. De meeste services die kunnen worden gebruikt als onderdeel van een multitenant-oplossing, onderscheiden of splitsen het gebruik niet automatisch op, op basis van wat u een tenant definieert. Denk bijvoorbeeld aan een service waarin gegevens voor al uw tenants in één relationele database worden opgeslagen. Het is moeilijk om precies te bepalen hoeveel ruimte elke tenant gebruikt voor die relationele database, in termen van opslag of van de rekencapaciteit die nodig is om query's en aanvragen te verwerken.

Voor een oplossing met één tenant kunt u daarentegen Microsoft Cost Management in Azure Portal gebruiken om een volledige kostenanalyse te krijgen voor alle Azure-resources die door die tenant worden gebruikt.

Daarom is het belangrijk om bij deze uitdagingen na te denken over het meten van verbruik.

Notitie

In sommige gevallen is het commercieel acceptabel om een verlies te nemen bij het leveren van service aan een tenant, bijvoorbeeld wanneer u een nieuwe markt of regio invoert. Dit is een commerciële keuze. Zelfs in deze situaties is het nog steeds een goed idee om het verbruik van elke tenant te meten, zodat u de toekomst kunt plannen.

Metrische gegevens over indicatief verbruik

Moderne toepassingen (gebouwd voor de cloud) bestaan meestal uit veel verschillende services, elk met verschillende verbruiksmetingen. Een opslagaccount meet bijvoorbeeld het verbruik op basis van de hoeveelheid gegevens die is opgeslagen, de verzonden gegevens en het aantal transacties. Azure-app Serviceverbruik wordt echter gemeten door de hoeveelheid rekenresources die in de loop van de tijd zijn toegewezen. Als u een oplossing hebt die een opslagaccount en App Service-resources bevat, kan het combineren van al deze metingen samen om de werkelijke COGS (kosten van verkochte goederen) te berekenen een zeer moeilijke taak zijn. Vaak is het eenvoudiger om één indicatieve meting te gebruiken om het verbruik in de oplossing aan te geven.

Als een multitenant-oplossing bijvoorbeeld één relationele database deelt, zijn de gegevens die door een tenant zijn opgeslagen mogelijk een goede metrische gegevens over indicatief verbruik.

Notitie

Zelfs als u het volume van gegevens gebruikt dat door een tenant is opgeslagen als indicatief verbruik, is dit mogelijk geen echte weergave van verbruik voor elke tenant. Als een bepaalde tenant bijvoorbeeld veel meer leesbewerkingen uitvoert of meer rapportage uitvoert vanuit de oplossing, maar er niet veel gegevens worden geschreven, kan er veel meer rekenkracht worden gebruikt dan de opslagvereisten aangeven.

Het is belangrijk om af en toe het werkelijke verbruik in uw tenants te meten en te controleren om te bepalen of de veronderstellingen die u maakt over uw indicatieve metrische gegevens juist zijn.

Metrische gegevens voor transacties

Een alternatieve manier om het verbruik te meten is het identificeren van een belangrijke transactie die representatief is voor de COGS voor de oplossing. In een oplossing voor documentbeheer kan dit bijvoorbeeld het aantal documenten zijn dat is gemaakt. Dit kan handig zijn, als er een kernfunctie of functie in een systeem is dat transactioneel is en als het eenvoudig kan worden gemeten.

Deze methode is meestal eenvoudig en rendabel om te implementeren, omdat er meestal slechts één punt in uw toepassing is dat het aantal transacties moet registreren dat plaatsvindt.

Metrische gegevens per aanvraag

In oplossingen die voornamelijk op API's zijn gebaseerd, kan het zinvol zijn om een metrische verbruiksgegevens te gebruiken die is gebaseerd op het aantal API-aanvragen dat wordt gedaan voor de oplossing. Dit kan vaak heel eenvoudig zijn om te implementeren, maar hiervoor moet u API's gebruiken als de primaire interface voor het systeem. Er zijn hogere operationele kosten voor het implementeren van een metrische gegevens per aanvraag, met name voor services met grote volumes, vanwege de noodzaak om het aanvraaggebruik vast te leggen (voor controle- en factureringsdoeleinden).

Notitie

Gebruikersgerichte oplossingen die bestaan uit een toepassing met één pagina (SPA) of een mobiele toepassing die gebruikmaakt van de API's, zijn mogelijk niet geschikt voor de metrische gegevens per aanvraag. Dit komt doordat de eindgebruiker weinig inzicht heeft in de relatie tussen het gebruik van de toepassing en het verbruik van API's. Uw toepassing is mogelijk chatty (het maakt veel API-aanvragen) of chunky (het maakt te weinig API-aanvragen) en de gebruiker merkt geen verschil.

Waarschuwing

Zorg ervoor dat u metrische aanvraaggegevens opslaat in een betrouwbaar gegevensarchief dat voor dit doel is ontworpen. Hoewel Azure-toepassing Insights bijvoorbeeld aanvragen kan bijhouden en zelfs tenant-id's (met behulp van eigenschappen) kan bijhouden, is Application Insights niet ontworpen om elk stukje telemetrie op te slaan. Gegevens worden verwijderd als onderdeel van het steekproefgedrag. Voor facturerings- en meterdoeleinden kiest u een gegevensarchief waarmee u een hoge mate van nauwkeurigheid krijgt.

Verbruik schatten

Bij het meten van het verbruik voor een tenant is het misschien gemakkelijker om een schatting te maken van het verbruik voor de tenant, in plaats van de exacte hoeveelheid verbruik te berekenen. Voor een multitenant-oplossing die veel duizenden tenants in één implementatie bedient, is het bijvoorbeeld redelijk om bij benadering te bepalen dat de kosten voor het bedienen van de tenant slechts een percentage van de kosten van de Azure-resources zijn.

In de volgende gevallen kunt u overwegen om de COGS voor een tenant te schatten:

  • U gebruikt geen prijzen op basis van verbruik.
  • De gebruikspatronen en -kosten voor elke tenant zijn vergelijkbaar, ongeacht de grootte.
  • Elke tenant verbruikt een laag percentage (bijvoorbeeld <2%), van de totale resources in de implementatie.
  • De kosten per tenant zijn laag.

U kunt er ook voor kiezen om het verbruik te schatten in combinatie met metrische gegevens over indicatief verbruik, metrische gegevens over transacties of metrische gegevens per aanvraag. Voor een toepassing die voornamelijk documenten beheert, het percentage van de totale opslag dat door een tenant wordt gebruikt om de documenten op te slaan, geeft dit bijvoorbeeld een dichte weergave van de werkelijke COGS. Dit kan een nuttige benadering zijn wanneer het meten van de COGS moeilijk is of wanneer het te veel complexiteit aan de toepassing zou toevoegen.

Uw kosten opladen

In sommige oplossingen kunt u de COGS van uw klanten in rekening brengen voor de resources van hun tenant. U kunt bijvoorbeeld Azure-resourcetags gebruiken om factureerbare Azure-resources toe te wijzen aan tenants. Vervolgens kunt u de kosten voor elke tenant bepalen voor de set resources die eraan zijn toegewezen, plus een marge voor winst en bewerking.

Notitie

Sommige Azure-services bieden geen ondersteuning voor tags. Voor deze services moet u de kosten toewijzen aan een tenant, op basis van de resourcenaam, resourcegroep of abonnement.

Azure Cost Analysis kan worden gebruikt voor het analyseren van Azure-resourcekosten voor oplossingen met één tenant die tags, resourcegroepen of abonnementen gebruiken om kosten toe te passen.

Dit wordt echter verboden complex in de meeste moderne multitenant oplossingen, vanwege de uitdaging om de exacte COGS nauwkeurig te bepalen voor één tenant. Deze methode moet alleen worden overwogen voor zeer eenvoudige oplossingen, oplossingen met resource-implementaties met één tenant of aangepaste tenantspecifieke invoegtoepassingsfuncties binnen een grotere oplossing.

Sommige Azure-services bieden functies waarmee andere methoden voor het toewijzen van kosten in een omgeving met meerdere tenants mogelijk zijn. Azure Kubernetes Service ondersteunt bijvoorbeeld meerdere knooppuntgroepen, waarbij aan elke tenant een knooppuntgroep wordt toegewezen met knooppuntgroeptags, die worden gebruikt om kosten toe te wijzen.

Medewerkers

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

Hoofdauteur:

Andere Inzenders:

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

Volgende stappen

Houd rekening met het update-implementatiemodel dat u gaat gebruiken.