Progettare per l'ottimizzazione dell'utilizzo
 Ottimizzare l'uso di risorse e operazioni. Applicarli ai requisiti funzionali e non funzionali negoziati della soluzione. |
|---|
I servizi e le offerte offrono diverse funzionalità e piani tariffari. Dopo aver acquistato un set di funzionalità, evitare di sottoutilizzarle. Trovare modi per massimizzare l'investimento nel livello. Allo stesso modo, valutare continuamente i modelli di fatturazione per trovare quelli più allineati all'utilizzo, in base ai carichi di lavoro di produzione correnti.
Scenario di esempio
Contoso University ospita attualmente una soluzione commerciale off-the-shelf che consente alla facoltà universitaria di creare e aggiornare i corsi per l'anno scolastico ed è il portale di registrazione principale usato dagli studenti per tali corsi. La soluzione ha un'integrazione personalizzata con un sistema di gestione dell'istruzione SaaS (Software-as-a-Service), che spera di eseguire la migrazione di tutte le funzioni in pochi anni. Nel frattempo, vogliono ottimizzare i costi per i componenti di integrazione personalizzati.
La soluzione tecnologica dell'offerta HANDLE è generalmente trattata come una scatola nera, ad eccezione del suo database che è Database di Azure per MySQL. L'integrazione personalizzata è una funzione durevole di Azure, che viene eseguita in un piano di servizio Standard in app Azure Service. Questo servizio app ospitato in precedenza un sito Web universitario, ma questo non è più il caso. Questa funzione durevole è un'applicazione Python supportata da un account Archiviazione di Azure dedicato che esegue una sincronizzazione notturna dal database MySQL all'API SaaS.
Usare i prezzi basati sul consumo quando è pratico
Potrebbero esserci servizi che offrono prezzi basati sul consumo, il che significa che vengono fatturati solo per l'utilizzo del servizio ed è possibile arrestare il servizio quando non è necessario interrompere l'incorrere in costi. Se si dispone di componenti del carico di lavoro utilizzati solo sporadicamente, ciò può contribuire a ridurre al minimo i costi sprecate rispetto al pagamento per l'esecuzione del componente 24/7/365.
Usando i prezzi basati sul consumo, si paga solo per quello che si usa. Questa opzione è una scelta ottimale quando non è previsto che il calcolo del carico di lavoro venga usato a tempo pieno.
Sfida di Contoso
- Il processo di sincronizzazione viene in genere eseguito per circa un'ora ogni notte, in un momento specifico. Le prestazioni di esso sono state storicamente soddisfacenti. I malfunzionamenti sono rari e gli errori temporanei vengono gestiti correttamente nella configurazione corrente.
- Poiché il calcolo necessario per il processo di sincronizzazione viene usato solo circa un'ora al giorno e paga per 24 ore indipendentemente dall'utilizzo, il team del carico di lavoro è interessato a un'alternativa alla progettazione corrente.
- Il team ha considerato la scrittura di uno script per arrestare il servizio ogni notte dopo l'esecuzione della sincronizzazione e ridistribuirlo il giorno successivo, ma questa soluzione avrebbe un alto livello di rischio e complessità.
Applicazione dell'approccio e dei risultati
- Il team analizza la cronologia dei processi e rileva che la durata della funzione più lunga è stata appena di due ore. Confrontano il costo del piano dedicato con il costo di Funzioni di Azure piano di consumo per lo scenario peggiore e concludono che il piano a consumo sarà meno costoso.
- Il team esegue un test delle prestazioni per garantire che le prestazioni siano sufficienti e notano un lieve aumento del tempo di esecuzione, ma è ancora entro limiti accettabili.
- Il costo complessivo del carico di lavoro viene ridotto usando il piano a consumo perché comportano costi solo quando il processo è in esecuzione.
Ottimizzare la progettazione della disponibilità elevata
Classificare in ordine di priorità la distribuzione di modelli attivi-attivi o attivi solo su modelli attivi-passivi, come parte del piano di ripristino, se è già stato pagato per le risorse.
Se per impostazione predefinita la progettazione usa modelli attivi-passivi, potrebbero essere presenti risorse inattive che altrimenti potrebbero essere usate. La conversione in attivo-attivo potrebbe consentire di soddisfare i requisiti di livellamento del carico e ridimensionamento del bursting senza sovraccarico. Se è possibile soddisfare le destinazioni di ripristino con un modello solo attivo, i costi di tali risorse possono essere rimossi completamente.
Sfida di Contoso
- L'applicazione ENCLOSURE usa Database di Azure per MySQL server flessibile configurato per la disponibilità elevata della stessa zona, che fornisce un server standby nella stessa zona di disponibilità del server primario. Hanno anche abilitato i backup automatici.
- L'RPO del carico di lavoro è relativamente lungo a 12 ore e l'obiettivo RTO è di tre ore durante il giorno dell'istituto di istruzione.
- In base ai test di ripristino precedenti, il team sa che può soddisfare le destinazioni RPO e RTO tramite failover automatico nel server di standby. Hanno anche testato il ripristino del database da un backup e possono soddisfare le destinazioni in questo scenario.
Applicazione dell'approccio e dei risultati
- Il team del carico di lavoro valuta nuovamente il vantaggio della progettazione a disponibilità elevata rispetto al costo del servizio pari al doppio di una singola istanza.
- Il team verifica la creazione di una nuova istanza e il ripristino di un database dal backup e sono soddisfatti che saranno ancora conformi alle destinazioni di ripristino, in modo da decidere di eliminare l'istanza di standby.
- Il team aggiorna il piano di ripristino di emergenza per riflettere la nuova strategia di ripristino e realizzare i risparmi sui costi tramite la nuova configurazione.
Mantenere l'ambiente cloud pulito di risorse e dati inutilizzati
Esaminare regolarmente e rigorosamente le distribuzioni per le risorse e i dati inutilizzati e rimuoverli. Nel corso del tempo, le risorse e i dati necessari per qualche scopo in passato, ma non vengono più usati possono rimanere negli ambienti cloud e accumulare inutilmente i costi. Prestare attenzione a mantenere puliti gli ambienti per ottimizzare l'efficienza dei costi.
Arrestare le risorse inutilizzate ed eliminare i dati quando non sono più necessari riduce i rifiuti e libera fondi in modo da poterli investire altrove.
Sfida di Contoso
- L'università ha storicamente adottato un approccio conservativo per rimuovere le soluzioni, temendo che possano dover ripristinare una configurazione precedente. Questa cautela ha portato ad aver abbandonato i servizi in esecuzione in uno o più ambienti per mesi che sono stati dimenticati in alcuni casi.
- Quando vengono individuati servizi abbandonati, è in genere accidentale perché non esiste un processo formale per esaminare l'ambiente per tali servizi.
Applicazione dell'approccio e dei risultati
- Il team aggiunge la rimozione delle autorizzazioni del servizio app al backlog come parte della migrazione da servizio app all'hosting a consumo per durable function. Come parte dello sprint successivo, verranno arrestate le distribuzioni servizio app in tutti gli ambienti.
- Per facilitare il rilevamento proattivo delle risorse abbandonate, il team configura gli avvisi in Azure Advisor per notificare loro le risorse inutilizzate.
- Il team implementa un nuovo criterio che richiede al team di eseguire revisioni complete mensili degli ambienti di pre-produzione e revisioni complete trimestrali dell'ambiente di produzione per identificare le risorse abbandonate. Tutte le risorse abbandonate trovate verranno aggiunte al backlog per rimuovere le autorizzazioni.