Misurare il consumo di ogni tenant

  • Articolo

In qualità di provider di soluzioni, è importante misurare il consumo di ogni tenant nella soluzione multi-tenant. Misurando il consumo di ogni tenant, è possibile garantire che il costo delle merci vendute (COGS), per fornire il servizio a ogni tenant, sia redditizio. In questa pagina vengono fornite indicazioni per i decision maker tecnici sull'importanza della misurazione del consumo e gli approcci che è possibile prendere in considerazione per misurare il consumo di un tenant, nonché i compromessi coinvolti.

Esistono due problemi principali che guidano la necessità di misurare il consumo di ogni tenant:

  • È necessario misurare il costo effettivo per gestire ogni tenant. Questo è importante per monitorare la redditività della soluzione per ogni tenant.
  • È necessario determinare l'importo da addebitare al tenant quando si usano i prezzi basati sul consumo.

Tuttavia, può essere difficile misurare le risorse effettive usate da un tenant in una soluzione multi-tenant. La maggior parte dei servizi che possono essere usati come parte di una soluzione multi-tenant non differenzia o suddivide automaticamente l'utilizzo, in base a qualsiasi elemento definito come tenant. Si consideri, ad esempio, un servizio che archivia i dati per tutti i tenant in un singolo database relazionale. È difficile determinare esattamente la quantità di spazio usata da ogni tenant del database relazionale, in termini di archiviazione o capacità di calcolo necessaria per gestire query e richieste.

Al contrario, per una soluzione a tenant singolo, è possibile usare Gestione costi Microsoft all'interno del portale di Azure per ottenere una suddivisione completa dei costi per tutte le risorse di Azure utilizzate da tale tenant.

Pertanto, quando si affrontano queste sfide, è importante considerare come misurare il consumo.

Nota

In alcuni casi, è commercialmente accettabile prendere una perdita per il recapito del servizio a un tenant, ad esempio quando si entra in un nuovo mercato o area geografica. Questa è una scelta commerciale. Anche in queste situazioni, è comunque consigliabile misurare il consumo di ogni tenant, in modo da poter pianificare il futuro.

Metriche di consumo indicative

Le applicazioni moderne (create per il cloud) sono in genere costituite da molti servizi diversi, ognuno con diverse misure di consumo. Ad esempio, un account di archiviazione misura il consumo in base alla quantità di dati archiviati, ai dati trasmessi e al numero di transazioni. Tuttavia, app Azure consumo del servizio viene misurato in base alla quantità di risorse di calcolo allocate nel tempo. Se si dispone di una soluzione che include un account di archiviazione e risorse servizio app, combinare tutte queste misurazioni per calcolare l'effettivo COGS (costo di beni venduti) può essere un'attività molto difficile. Spesso, è più facile usare una singola misura indicativa per rappresentare il consumo nella soluzione.

Ad esempio, se una soluzione multi-tenant condivide un singolo database relazionale, i dati archiviati da un tenant potrebbero essere una buona metrica di consumo indicativa.

Nota

Anche se si usa il volume di dati archiviati da un tenant come misura indicativa di consumo, potrebbe non essere una vera rappresentazione dell'utilizzo per ogni tenant. Ad esempio, se un tenant specifico esegue molte più letture o esegue più report dalla soluzione, ma non scrive molti dati, potrebbe usare molto più calcolo rispetto ai requisiti di archiviazione.

È importante misurare occasionalmente ed esaminare il consumo effettivo tra i tenant, per determinare se le ipotesi che si stanno facendo sulle metriche indicative sono corrette.

Metriche delle transazioni

Un modo alternativo per misurare il consumo consiste nell'identificare una transazione chiave rappresentativa del COGS per la soluzione. Ad esempio, in una soluzione di gestione dei documenti, potrebbe trattarsi del numero di documenti creati. Può essere utile, se è presente una funzione o una funzionalità di base all'interno di un sistema transazionale e se può essere misurata facilmente.

Questo metodo è in genere semplice ed economico da implementare, perché in genere è presente un solo punto nell'applicazione che deve registrare il numero di transazioni che si verificano.

Metriche per richiesta

Nelle soluzioni basate principalmente sulle API può essere utile usare una metrica di consumo basata sul numero di richieste API inviate alla soluzione. Questo può spesso essere piuttosto semplice da implementare, ma richiede l'uso delle API come interfaccia primaria per il sistema. L'implementazione di una metrica per richiesta comporta un aumento del costo operativo, soprattutto per i servizi con volumi elevati, a causa della necessità di registrare l'utilizzo della richiesta (per scopi di controllo e fatturazione).

Nota

Le soluzioni rivolte agli utenti costituite da un'applicazione a pagina singola o da un'applicazione per dispositivi mobili che usa le API potrebbero non essere adatte alla metrica per richiesta. Ciò è dovuto al fatto che l'utente finale non è a conoscenza della relazione tra l'uso dell'applicazione e l'utilizzo delle API. L'applicazione potrebbe essere chatty (effettua molte richieste API) o chunky (effettua troppe richieste API) e l'utente non noterà una differenza.

Avviso

Assicurarsi di archiviare le metriche delle richieste in un archivio dati affidabile progettato per questo scopo. Ad esempio, anche se app Azure lication Insights può tenere traccia delle richieste e può anche tenere traccia degli ID tenant (usando le proprietà), Application Insights non è progettato per archiviare tutti i dati di telemetria. Rimuove i dati, come parte del comportamento di campionamento. Per scopi di fatturazione e misurazione, scegliere un archivio dati che offrirà un livello elevato di accuratezza.

Stimare il consumo

Quando si misura il consumo per un tenant, può essere più semplice fornire una stima del consumo per il tenant, anziché provare a calcolare la quantità esatta di consumo. Ad esempio, per una soluzione multi-tenant che gestisce molte migliaia di tenant in una singola distribuzione, è ragionevole approssimare che il costo della gestione del tenant sia solo una percentuale del costo delle risorse di Azure.

È possibile valutare la stima di COGS per un tenant, nei casi seguenti:

  • Non si usano prezzi basati sul consumo.
  • I modelli di utilizzo e i costi per ogni tenant sono simili, indipendentemente dalle dimensioni.
  • Ogni tenant usa una percentuale bassa (ad esempio, <2%), delle risorse complessive nella distribuzione.
  • Il costo per tenant è basso.

È anche possibile scegliere di stimare il consumo in combinazione con metriche di consumo indicative, metriche delle transazioni o metriche per richiesta. Ad esempio, per un'applicazione che gestisce principalmente i documenti, la percentuale di archiviazione complessiva usata da un tenant, per archiviare i documenti, fornisce una rappresentazione abbastanza vicina dell'effettivo COGS. Questo può essere un approccio utile, quando si misura COGS è difficile o quando si aggiunge una complessità eccessiva all'applicazione.

Addebito dei costi

In alcune soluzioni è possibile addebitare ai clienti il cogs per le risorse del tenant. Ad esempio, è possibile usare i tag delle risorse di Azure per allocare risorse di Azure fatturabili ai tenant. È quindi possibile determinare il costo per ogni tenant per il set di risorse dedicate, oltre a un margine per profitto e funzionamento.

Nota

Alcuni servizi di Azure non supportano i tag. Per questi servizi, è necessario attribuire i costi a un tenant, in base al nome della risorsa, al gruppo di risorse o alla sottoscrizione.

Analisi dei costi di Azure può essere usato per analizzare i costi delle risorse di Azure per soluzioni a tenant singolo che usano tag, gruppi di risorse o sottoscrizioni ai costi degli attributi.

Tuttavia, questo diventa proibitivo nelle soluzioni multi-tenant più moderne, a causa della sfida di determinare accuratamente l'esatto COGS per gestire un singolo tenant. Questo metodo deve essere considerato solo per soluzioni molto semplici, soluzioni con distribuzioni di risorse a tenant singolo o funzionalità aggiuntive personalizzate specifiche del tenant all'interno di una soluzione più grande.

Alcuni servizi di Azure forniscono funzionalità che consentono altri metodi di attribuzione dei costi in un ambiente multi-tenant. Ad esempio, servizio Azure Kubernetes supporta più pool di nodi, in cui ogni tenant viene allocato a un pool di nodi con tag del pool di nodi, che vengono usati per attribuire i costi.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Prendere in considerazione il modello di distribuzione degli aggiornamenti che verrà usato.