Prepararsi per la crescita
- 8 minuti
Probabilmente hai sentito dire che la preparazione è la chiave per il successo. Questo detto è particolarmente vero in relazione a una crescita uniforme, riuscita, affidabile.
Uno dei principali vantaggi del cloud computing è la possibilità di ridimensionare. Questa capacità ha portato a un presupposto errato che non c'è bisogno di preparare o pianificare la crescita nel cloud perché ha una scalabilità infinita.
È vero che è probabile che nel cloud siano presenti più risorse che sufficienti per soddisfare le esigenze dell'applicazione. Esistono tuttavia alcuni motivi per cui è ancora importante comprendere le esigenze di capacità:
Anche se nel cloud sono probabilmente presenti molte risorse per soddisfare le tue esigenze, non tutti i servizi che utilizzi scalano automaticamente o sono intrinsecamente scalabili. È quindi necessario conoscere i limiti del servizio e sapere quando è necessario aumentare le prestazioni dei servizi e delle risorse.
Le risorse cloud potrebbero essere illimitate, ma il budget probabilmente non è. È necessario prendere in considerazione i costi e gli amici del reparto Finanziario vogliono conoscere la spesa prevista per il cloud.
Pianificare la crescita organica
La crescita organica nel mondo aziendale si riferisce al processo con cui le organizzazioni espandono la propria capacità, affidandosi a risorse intrinseche e competenze per alimentare una crescita più lenta e più naturale.
La prima cosa da fare quando si cerca di pianificare la capacità nel cloud man mano che l'azienda cresce in modo organico consiste nel mappare i requisiti correnti delle risorse per i componenti più grandi nell'applicazione.
Scenario: Crescita organica
Torniamo all'architettura esaminata all'inizio di questo modulo. Tailwind Traders sta per lanciare un nuovo prodotto innovativo e prevede una crescita drammatica di conseguenza. Giusto per ricordarti, ecco come appare il diagramma della loro architettura.
Per iniziare la pianificazione della capacità, è necessario identificare i componenti più grandi. In questo esempio che include:
- Cluster del servizio Azure Kubernetes
- Applicazione Rewards in esecuzione nell'App Service di Azure
- Diversi database, ad esempio Cosmos DB, Azure SQL e simili.
Per ognuno di questi componenti di grandi dimensioni, è necessario comprendere qual è l'utilizzo corrente delle risorse, per pianificare l'utilizzo futuro. Verrà ora illustrato l'utilizzo delle risorse per uno di questi componenti di grandi dimensioni.
Misurare la capacità in Cosmos DB
In Cosmos DB, l'archiviazione viene misurata in gigabyte e ridimensiona automaticamente, anche se è comunque necessario essere consapevoli delle misurazioni per motivi di costo.
La velocità effettiva è soggetta a provisioning preliminare e per misurarla si usa una metrica denominata Unità richiesta. Le unità richiesta (UR) sono una combinazione di memoria, CPU e operazioni di I/O al secondo, offrendo una singola metrica in base alla quale è possibile pianificare la capacità. Il provisioning delle UR avviene a incrementi di 100 UR al secondo.
Ogni operazione di database viene misurata in UR/sec. Le letture sono semplici: una lettura da 1 KB è una singola Unità di Richiesta. Altre operazioni vengono calcolate in base a diversi fattori, ad esempio dimensioni degli elementi, coerenza dei dati, modelli di query e così via.
Quando si crea il profilo dell'applicazione, ogni risposta restituita da Cosmos DB contiene l'intestazione dell'addebito della richiesta, che indica esattamente il numero di UR usate dalla richiesta. È possibile confrontare il numero di RU utilizzate con quello allocato per verificare che la capacità corrente sia più che sufficiente.
È consigliabile correlare l'utilizzo delle risorse a una metrica aziendale, ad esempio utenti attivi mensili o ricavi. Questa correlazione consente di pianificare la capacità in base alla modalità di crescita dell'azienda. È possibile recuperare queste metriche di capacità in Monitoraggio di Azure. Comprendere l'utilizzo delle risorse del sistema consente di sapere quando è necessario aumentare le prestazioni e quali saranno i costi nel tempo.
Esaminiamo in modo concreto i dati dell'utilizzo di Cosmos DB da parte di Tailwind Traders. Ecco un grafico dell'utilizzo.
In questo esempio Tailwind traders cresce in media di 2.500 utenti attivi mensili (MAU) con una base di utenti corrente di 10.000.
Se si esamina l'archiviazione, è possibile vedere che il database usa 300 GB di 5 TB disponibili (6%). Cresce quindi dell'1% o di 50 GB al mese.
In termini di velocità effettiva, questa si attesta su 300/1000 e cresce a una percentuale del 10% al mese:
Ora che è possibile comprendere le metriche delle risorse dei sistemi, è possibile sapere quando è probabile che sia necessario ridimensionare la velocità effettiva e quali saranno i costi nel tempo.
È ora possibile produrre un grafico che ci aiuta a pianificare la capacità.
Ora sappiamo che a maggio raggiungeremo la capacità delle RUs nel nostro database, quindi dobbiamo scalare prima di allora. Un'altra interessante osservazione è che potrebbero anche ridimensionare il loro database Cosmos DB in questo momento, perché non stanno usando neanche lontanamente la capacità pre-provisionata.
Pianificare la crescita inorganica
Nell'esempio precedente si stava pianificando la crescita organica. Crescita inorganica deriva da fattori esterni piuttosto che da un aumento delle attività interne dell'azienda. Invece di essere una progressione naturale, tende a comportare un aumento più improvviso e più grande dell'utilizzo.
In alcuni casi, in realtà non si conosce in anticipo un aumento del traffico, degli utenti e così via. In previsione di questi casi, è necessario creare il tuo sistema in modo che sia il più scalabile possibile automaticamente, e fallire in modo elegante quando non è possibile. Questo argomento verrà affrontato più avanti in questo modulo.
In altre occasioni, come nel caso di un prossimo lancio di un prodotto, puoi sperimentare una crescita inorganica per cui puoi pianificare e prepararti. Se i team interagiscono tra progettazione, prodotto, marketing e finanza e si sa come ottenere i modelli di utilizzo e crescita delle risorse. È possibile eseguire un'operazione ragionevole per stimare l'impatto di questi eventi sui requisiti delle risorse e implementare le modifiche di conseguenza.
Fare bene questa cosa è specifico della vostra organizzazione e dell'evento particolare. Non sempre si riesce a farcela, ma essere il più preparati possibile dà un vantaggio iniziale.
Scenario: Crescita inorganica
Esaminiamo un'altra situazione ipotetica come esempio di pianificazione della crescita inorganica. C'è un prossimo evento di marketing per il lancio di un nuovo prodotto innovativo di alto profilo presso Tailwind Traders. Si prevede che ciò attirerà 5000 utenti in più sul loro sito di vendita.
Usando i dati dell'esempio precedente di crescita organica e correlandola, speriamo con la causazione, a una metrica aziendale ottenuta dai team di prodotto/marketing (ad esempio, numero di utenti). È possibile iniziare a pianificare la crescita non organica.
Si sa dallo scenario precedente che per 2500 utenti sono necessari circa 50 GB di spazio di archiviazione e 100 UR. È ora possibile usare tali dati e determinare se si è pronti per questo evento. Se si prevede che 5000 utenti richiedano 100 GB di spazio di archiviazione e 200 UR/sec.
È possibile notare che le capacità di archiviazione sono più che sufficienti per la crescita prevista dall'evento. Queste capacità vengono ridimensionate automaticamente per l'utente, quindi non c'è da preoccuparsi, tranne che per comprendere i nuovi costi, che vengono risolti in un secondo momento.
È anche possibile prevedere che le UR raggiungeranno solo il 50% di capacità dopo l'evento. Quindi, non hanno preoccupazioni in termini di capacità di Cosmos DB per questo evento.
Tuttavia, ci sarà un impatto sui costi.
Si noterà che i 100 GB di spazio di archiviazione aggiuntivo costeranno un costo aggiuntivo di $ 25 al mese. Il costo del throughput rimane invariato poiché i clienti pagano per le RU provisionate, e ne hanno già in quantità più che sufficiente. In sintesi, questo evento di marketing probabilmente aumenterà di 25 dollari USA la loro fattura di CosmosDB.