Het verbruik van elke tenant meten

  • Artikel
  • 6 minuten om te lezen

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, laag zijn.

Er zijn twee belangrijke zaken die de noodzaak stimuleren om het verbruik van elke tenant te meten:

  • 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 gebruik maakt van prijzen op basis van verbruik.

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 maken niet automatisch onderscheid tussen het gebruik of definieert het gebruik op basis van wat u definieert als een tenant. Denk bijvoorbeeld aan een service die gegevens voor al uw tenants opgeslagen in één relationele database. Het is moeilijk om precies te bepalen hoeveel ruimte elke tenant van die relationele database gebruikt, ofwel wat betreft opslag of van de rekencapaciteit die nodig is voor het verwerken van query's en aanvragen.

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

Daarom is het bij deze uitdagingen belangrijk om te overwegen hoe u het verbruik meet.

Notitie

In sommige gevallen is het commercieel acceptabel om verlies te nemen bij het leveren van een service aan een tenant, bijvoorbeeld wanneer u een nieuwe markt of regio binnenkomt. 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 voor de toekomst kunt plannen.

Metrische indicatieve verbruiksgegevens

Moderne toepassingen (gebouwd voor de cloud) zijn meestal opgebouwd uit veel verschillende services, elk met verschillende verbruiksmogelijkheden. Een opslagaccount meet bijvoorbeeld het verbruik op basis van de hoeveelheid opgeslagen gegevens, de verzonden gegevens en het aantal transacties. Het verbruik Azure App Service wordt echter gemeten aan de hoeveelheid rekenbronnen die gedurende een bepaalde periode zijn toegewezen. Als u een oplossing hebt die een opslagaccount en App Service-resources bevat, kan het combineren van al deze metingen om de werkelijke KOSTEN van verkochte goederen te berekenen, erg lastig zijn. Vaak is het gemakkelijker om één indicatieve meting te gebruiken om het verbruik in de oplossing weer te geven.

In het geval van een multitenant-oplossing die één relationele database deelt, kunt u bijvoorbeeld bepalen dat de opgeslagen gegevens een goede indicatieve verbruiksgegevens zijn.

Notitie

Zelfs als u het volume van gegevens dat door een tenant is opgeslagen als indicatieve verbruiksmeting gebruikt, is het mogelijk geen echte weergave van het verbruik voor elke tenant. Als een bepaalde tenant bijvoorbeeld veel meer lees- of rapporteringen van de oplossing heeft, maar er niet veel gegevens worden geschreven, kan deze veel meer rekenkracht gebruiken dan de opslagvereisten zouden aangeven.

Het is van tijd tot tijd belangrijk om 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 door een sleuteltransactie te identificeren die representatief is voor de COGS voor de oplossing. In een oplossing voor documentbeheer kan dit bijvoorbeeld het aantal gemaakte documenten zijn. Dit kan handig zijn als er een kernfunctie of -functie in een systeem is die transactioneel is en als deze eenvoudig kan worden gemeten.

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

Metrische gegevens per aanvraag

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

Notitie

Gebruikers gerichte 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 gebruik van API's. Uw toepassing kan chatty zijn (er worden veel API-aanvragen gemaakt) of chunky (er worden te weinig API-aanvragen gemaakt) en de gebruiker merkt geen verschil.

Waarschuwing

Zorg ervoor dat u metrische aanvraaggegevens opgeslagen in een betrouwbare gegevensopslag die is ontworpen voor dit doel. Hoewel gebruikers bijvoorbeeld Azure-toepassing Insights aanvragen kunnen bijhouden en zelfs tenant-ID's kunnen bijhouden (door eigenschappen te gebruiken),is Application Insights niet ontworpen om alle telemetrie op te slaan. Hiermee verwijdert u gegevens als onderdeel van het steekproefgedrag. Kies voor facturerings- en meetdoeleinden een gegevensopslag die u een hoog nauwkeurigheidsniveau geeft.

Verbruik schatten

Bij het meten van het verbruik voor een tenant is het wellicht eenvoudiger om een schatting te maken van het verbruik voor de tenant, in plaats van te proberen de exacte hoeveelheid verbruik te berekenen. Voor een multitenant-oplossing die bijvoorbeeld vele duizenden tenants in één implementatie bedient, is het redelijk om te schatten 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 indicatieve metrische verbruiksgegevens, metrischegegevens voor transacties of metrische gegevens per aanvraag. Voor een toepassing die voornamelijk documenten beheert, geeft het percentage van de totale opslag dat door een tenant wordt gebruikt om de documenten op te slaan, bijvoorbeeld een dicht genoeg representatie van de werkelijke kosten van kosten en kosten(en) . Dit kan een nuttige benadering zijn, wanneer het meten van de COGS moeilijk is of wanneer het te complex zou zijn voor de toepassing.

Kosten in rekening brengen

In sommige oplossingen kunt u gewoon de KOSTEN voor de resources van hun tenant in rekening brengen voor uw klanten. 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 aan deze tenants is toegewezen, plus een marge voor winst en bewerking.

Notitie

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

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

Dit wordt echter in de meeste moderne oplossingen met meerdere tenants te complex, vanwege de uitdaging om nauwkeurig de exacte COGS 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 invoegfuncties binnen een grotere oplossing.

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

Volgende stappen

Overweeg het update-implementatiemodel dat u gaat gebruiken.