Approcci architetturali per la gestione e l'allocazione dei costi in una soluzione multi-tenant

Le soluzioni multi-tenant richiedono spesso valutazioni specifiche per la misurazione, l'allocazione e l'ottimizzazione dei costi. In questa pagina vengono presentate alcune linee guida chiave che gli architetti di soluzioni possono prendere in considerazione per la misurazione, l'allocazione e l'ottimizzazione dei costi per un'applicazione multi-tenant.

Considerazioni e requisiti principali

Considerare i requisiti relativi alla misurazione del consumo della soluzione. Questo argomento viene illustrato in modo più dettagliato in Misurare il consumo di ogni tenant.

Scopo della misurazione

Innanzitutto, è importante definire l'obiettivo della misurazione. Di seguito sono riportati alcuni esempi di obiettivi:

• Calcolare un costo del venduto approssimativo per ogni tenant. Ad esempio, se si distribuisce un numero significativo di risorse condivise, si potrebbe essere interessati solo a una stima approssimativa dei costi sostenuti per ogni tenant.
• Calcolare il costo esatto sostenuto per ogni tenant. Ad esempio, se si addebita ai tenant la quantità esatta di consumo effettivo, è necessario disporre di informazioni precise sul costo delle risorse di ogni tenant.
• Identificare i tenant outlier con costi significativamente superiori rispetto agli altri. Ad esempio, se si fornisce un modello di determinazione dei prezzi a tariffa fissa, potrebbe essere necessario determinare se alcuni tenant stanno consumando una quantità sproporzionata della capacità di cui è stato effettuato il provisioning, in modo da poter applicare i criteri di equo utilizzo. In molti scenari, questo caso d'uso non richiede una misurazione precisa dei costi.
• Ridurre il costo complessivo di Azure per la soluzione. Ad esempio, è possibile esaminare il costo di ogni componente e quindi determinare se è stato eseguito il provisioning in eccesso per il carico di lavoro.

Definendo l'obiettivo di misurazione del consumo da parte di un tenant, è possibile determinare se le allocazioni dei costi devono essere approssimative o estremamente precise, con effetto sugli strumenti specifici che è possibile usare e sulle procedure che si possono seguire.

COMPONENTI CONDIVISI

È possibile che si riesca a ridurre il costo di una soluzione multi-tenant spostando i tenant nell'infrastruttura condivisa. Tuttavia, è necessario valutare attentamente l'impatto della condivisione delle risorse, ad esempio nei tenant si potrebbero riscontrare problemi di rumore.

È anche necessario valutare il modo in cui misurare e allocare i costi dei componenti condivisi. Ad esempio, è possibile suddividere uniformemente il costo tra ogni tenant che utilizza il componente condiviso. In caso contrario, è possibile misurare l'utilizzo di ogni tenant per una misurazione più precisa dell'utilizzo dei componenti condivisi.

Approcci e modelli da prendere in considerazione

Allocare i costi usando i tag delle risorse

Con Azure è possibile applicare i tag alle risorse. Un tag è una coppia chiave-valore. I tag consentono di aggiungere metadati personalizzati. I tag sono utili per molte operazioni di gestione e per analizzare il costo del consumo di Azure. Dopo aver applicato i tag, è possibile determinare i costi associati a ognuno di essi.

È probabile che il modo in cui si usano i tag in una soluzione multi-tenant vari in base all'architettura.

In alcune soluzioni, è possibile distribuire risorse dedicate per ogni tenant, ad esempio stamp di distribuzione dedicati per ogni tenant. In queste situazioni, è chiaro che qualsiasi utilizzo di Azure per tali risorse deve essere allocato al tenant pertinente ed è quindi possibile contrassegnare le risorse di Azure con l'ID del tenant.

In altre situazioni, potrebbero essere presenti set di risorse condivise. Ad esempio, quando si applica il modello di partizionamento orizzontale è possibile distribuire più database e distribuire i tenant tra di essi. Valutare la possibilità di contrassegnare le risorse con un identificatore per il gruppo di tenant. Quando si usa questo approccio, è possibile che non si riesca ad allocare facilmente i costi a un singolo tenant, ma si potrebbe comunque limitare almeno il costo a un set di tenant. È anche possibile usare le informazioni sul consumo per ribilanciare i tenant tra le partizioni, nel caso in cui una partizione specifica accumuli costi più elevati rispetto alle altre.

Si consideri una soluzione multi-tenant di esempio compilata usando il modello Deployment Stamps e un modello tenancy partizionato verticalmente. Ogni indicatore di distribuzione include un server Web condiviso e database partizionati. È possibile applicare i tag a ogni componente di Azure, come illustrato nel diagramma di seguito.

La strategia di assegnazione di tag in questo caso utilizzata è la seguente:

• Ogni risorsa ha un tag stamp-id.
• Ogni database partizionato ha un tag shard-id.
• Ogni risorsa dedicata a un tenant specifico ha un tagtenant-id.

Usando questa strategia di assegnazione dei tag, è facile filtrare le informazioni sui costi per un singolo stamp. È anche facile trovare il costo delle risorse specifiche del tenant, ad esempio il costo totale del database per il tenant C. I componenti condivisi non hanno un tag tenant-id, ma il costo dei componenti condivisi per uno stamp può essere suddiviso tra i tenant assegnati per l'uso di tale stamp o partizione.

Instrumentare l'applicazione

Nelle situazioni in cui non c'è una relazione diretta tra una risorsa di Azure e un tenant, valutare la possibilità di instrumentare l'applicazione per raccogliere i dati di telemetria.

Il livello applicazione potrebbe già raccogliere log e metriche utili per rispondere a domande sulla misurazione, ad esempio:

• Approssimativamente, quante richieste API vengono effettuate per ogni tenant?
• In quali ore del giorno il traffico è più intenso per determinati tenant?
• Qual è il confronto tra i modelli di utilizzo del tenant A rispetto ai modelli di utilizzo del tenant B?

In Azure queste metriche vengono spesso acquisite tramite Application Insights. Usando gli inizializzatori di telemetria, è possibile arricchire i dati di telemetria acquisiti da Application Insights includendo un identificatore del tenant o altri dati personalizzati.

Tuttavia, Application Insights e altre soluzioni di registrazione e monitoraggio non sono appropriate per una misurazione precisa dei costi o per scopi di misurazione. Application Insights è progettato per il campionamento dei dati, soprattutto nei i casi in cui l'applicazione gestisca un volume elevato di richieste. Il campionamento è progettato per ridurre il costo del monitoraggio della soluzione poiché, spesso, l'acquisizione di ogni dato di telemetria può diventare costosa.

Se è necessario tenere traccia di dettagli precisi sul consumo o sull'utilizzo a scopo di fatturazione, è opportuno creare una pipeline personalizzata per registrare i dati necessari. È necessario quindi aggregare i dati in base alle esigenze. I servizi di Azure utili a questo scopo sono Hub eventi per l'acquisizione di grandi volumi di dati di telemetria e Analisi di flusso per l'elaborazione di tali dati in tempo reale.

Usare prenotazioni di Azure e piano di risparmio di Azure per ridurre i costi

Prenotazioni di Azure: le prenotazioni di Azure consentono di ridurre i costi di Azure eseguendo il pre-commit a un determinato livello di spesa. È possibile applicare le prenotazioni a diversi tipi di risorse di Azure.

In una soluzione multi-tenant, le prenotazioni possono essere molto efficaci. Tenere presenti le considerazioni seguenti:

• Quando si distribuisce una soluzione multi-tenant che include risorse condivise, considerare il livello di utilizzo di base necessario per il carico di lavoro. È possibile prendere in considerazione una prenotazione per il consumo di base e quindi pagare tariffe standard per un consumo maggiore durante i picchi imprevedibili.
• Quando si distribuiscono risorse per ogni tenant, valutare se è possibile prenotare l'utilizzo delle risorse per un tenant specifico o per il portfolio di tenant.

Le prenotazioni di Azure consentono di impostare l'ambito delle prenotazioni da applicare a un gruppo di risorse, a una sottoscrizione o a un set di sottoscrizioni. Ciò consente di sfruttare le prenotazioni, anche se si partiziona il carico di lavoro tra più sottoscrizioni.

Gli ambiti di prenotazione possono essere utili anche nel caso di tenant con carichi di lavoro imprevedibili. Si consideri, ad esempio, una soluzione in cui il tenant A richiede solo un'istanza di una risorsa specifica, mentre i tenant B e C ne richiedono due. Successivamente, l'utilizzo del tenant B si riduce e quindi si riduce anche il numero di istanze, mentre il tenant A viene utilizzato di più e di conseguenza aumenta anche il numero di istanze. Le prenotazioni vengono applicate ai tenant che lo richiedono.

Piano di risparmio di Azure per il calcolo: il piano di risparmio di Azure per il calcolo è un piano flessibile di risparmio sui costi che genera risparmi significativi rispetto ai prezzi con pagamento in base al consumo. Si accetta un contratto di un anno o tre anni e si ricevono sconti per i servizi di calcolo idonei. Questi servizi includono macchine virtuali, host dedicati, istanze di contenitore, funzioni Premium di Azure e servizi app di Azure. I risparmi si applicano a questi servizi di calcolo indipendentemente dall'area, dalle dimensioni dell'istanza o dal sistema operativo. Per altre informazioni, vedere Panoramica del piano di risparmio di Azure e documentazione del piano di risparmio di Azure.

Combinare prenotazioni e piano di risparmio: per ottimizzare ulteriormente i costi e la flessibilità, è possibile combinare un piano di risparmio di Azure con prenotazioni di Azure.

Antipattern da evitare

• Non tenere traccia dei costi. È importante avere almeno un'idea approssimativa dei costi sostenuti e dell'impatto di ogni tenant sul costo di distribuzione della soluzione. In caso contrario, se i costi cambiano nel tempo, non sarà disponibile alcun dato di riferimento per un confronto. Potrebbe anche non essere possibile prevedere in che modo una crescita nei tenant influirà sui costi e sulla redditività.
• Procedere per ipotesi o tentativi. Assicurarsi che la misurazione dei costi si basi su informazioni reali. Potrebbe non essere necessario un livello elevato di precisione, ma anche le stime devono essere basate su misurazioni reali.
• Precisione eccessiva. Potrebbe non essere necessario avere una contabilità dettagliata di ogni costo addebitato per ogni tenant. La creazione di processi di misurazione e ottimizzazione dei costi inutilmente precisi può essere controproducente, perché aggiunge complessità di progettazione e crea processi fragili.
• Misurazione in tempo reale. La maggior parte delle soluzioni non necessitano di misurazioni dei costi in tempo reale. I dati di misurazione e consumo possono essere complessi da elaborare, pertanto, è consigliabile registrare i dati necessari e quindi aggregare ed elaborare i dati in modo asincrono in un secondo momento.
• Uso degli strumenti di monitoraggio per la fatturazione. Come descritto nella sezione Instrumentare l'applicazione, assicurarsi di usare strumenti progettati per il monitoraggio e la misurazione dei costi. Le soluzioni di monitoraggio delle applicazioni non sono in genere efficaci per la gestione di questo tipo di dati, soprattutto quando è richiesta molta precisione.

Collaboratori

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

Autore principale:

• John Downs | Principal Customer Engineer, FastTrack per Azure

Altri contributori:

• Babilonia Sherri | Senior Customer Engineer, FastTrack per Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

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

Passaggi successivi

• Misurare il consumo di ogni tenant