Calcolo per carichi di lavoro SaaS in Azure
L'applicazione SaaS (Software as a Service) deve essere eseguita in una piattaforma di calcolo. Analogamente ad altri componenti dell'architettura, deve soddisfare i requisiti aziendali e essere progettati in base al modello aziendale. La scelta della piattaforma di calcolo è una decisione di progettazione significativa. La decisione influisce sull'isolamento dei clienti, sulle prestazioni e sulla resilienza e sulla piattaforma di calcolo influisce sul modo in cui l'intera soluzione SaaS può essere ridimensionata e cresciuta.
Questo articolo descrive le considerazioni per la scelta del modello di hosting, gli aspetti operativi del modello e come ottimizzare le opzioni tecnologiche per soddisfare i contratti di servizio e gli obiettivi del livello di servizio.
Selezionare una piattaforma di calcolo
La scelta della piattaforma di calcolo appropriata per il carico di lavoro SaaS è importante, ma l'abbondanza di opzioni disponibili può rendere la scelta travolgente. La piattaforma migliore dipende da fattori come l'architettura dell'applicazione, la scalabilità, le esigenze di prestazioni e il modello di isolamento del tenant. Ciò che è ottimale per un'applicazione potrebbe non essere per un'altra.
Considerazioni relative alla progettazione
Modello di hosting. Azure offre diversi modelli di hosting, principalmente infrastruttura distribuita come servizio (IaaS) e piattaforma distribuita come servizio (PaaS), ognuno con i propri vantaggi e compromessi. Valutare i requisiti dell'applicazione e scegliere il modello più adatto.
IaaS fornisce macchine virtuali (VM) e il controllo completo su di essi, tra cui rete e archiviazione. Tuttavia, richiede la gestione e l'applicazione di patch, che può essere a elevato utilizzo operativo. Ad esempio, i set di scalabilità di macchine virtuali e i cluster servizio Azure Kubernetes del servizio Azure Kubernetes (AKS).
PaaS consente di distribuire applicazioni senza gestire l'infrastruttura sottostante. Include funzionalità predefinite per la scalabilità automatica e il bilanciamento del carico. Gli esempi sono app Azure Servizio e App Azure Container.
I servizi PaaS offrono un minor controllo rispetto a IaaS, che può essere problematico se l'applicazione necessita di una configurazione specifica. Ad esempio, l'applicazione potrebbe essere eseguita in un sistema operativo che il servizio PaaS non supporta.
Tipo di carico di lavoro. Alcune piattaforme sono specializzate per carichi di lavoro specifici, mentre altri sono versatili. Ad esempio, servizio app è progettato per le applicazioni Web, mentre il servizio Azure Kubernetes è più generico. Può ospitare app Web, carichi di lavoro di intelligenza artificiale e attività di calcolo batch.
Sviluppare competenze del team. Le modifiche di grandi dimensioni possono risultare complesse se il team non ha esperienza con la nuova piattaforma. Valutare le competenze del team e soddisfare i requisiti della piattaforma. Iniziare con una semplice piattaforma e evolvere gradualmente l'architettura invece di passare direttamente a un'opzione più avanzata.
Ad esempio, se si sta creando un'applicazione in contenitori, iniziare con App contenitore per semplificare la gestione. Man mano che le esigenze aumentano di più, è possibile passare al servizio Azure Kubernetes quando si acquisisce una migliore comprensione della piattaforma nel tempo.
Sovraccarico di gestione. Le piattaforme di calcolo bilanciano il sovraccarico e il controllo. Maggiore responsabilità di gestione spostata dal team significa meno controllo sulla piattaforma.
Ad esempio, IaaS offre un controllo elevato sulle macchine virtuali, ma comporta un sovraccarico significativo. Se l'applicazione viene distribuita nell'ambiente di un cliente, potrebbe essere disponibile un accesso limitato per le operazioni di gestione. Valutare se questi compromessi sono accettabili e fattibili.
Requisiti di prestazioni. Comprendere i requisiti di prestazioni dell'applicazione modellando CPU, memoria, rete, tra cui larghezza di banda e latenza, GPU e esigenze di disponibilità. Dovresti anche considerare la crescita futura. Usare queste informazioni per scegliere le risorse di calcolo appropriate, ad esempio la serie e le dimensioni delle macchine virtuali. Potrebbe anche essere necessario selezionare aree specifiche che supportano una serie di macchine virtuali specifica per soddisfare requisiti specializzati.
Requisiti di affidabilità. Prendere in considerazione le funzionalità di affidabilità della piattaforma di calcolo e assicurarsi che soddisfino gli obiettivi di affidabilità. Potrebbe essere necessario usare livelli di servizio specifici per avere più istanze della soluzione o distribuirla tra zone di disponibilità per migliorare l'affidabilità.
Per definire le destinazioni di affidabilità, vedere RE:04 Recommendations (Raccomandazioni RE:04).
Sicurezza e conformità delle applicazioni. Valutare le funzionalità di sicurezza e le certificazioni di conformità di ogni piattaforma di calcolo per assicurarsi che soddisfino le proprie esigenze. Ad esempio, se è necessario monitorare e filtrare il traffico in uscita, potrebbe essere necessario scegliere servizi di calcolo o livelli specifici.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Valutare i requisiti di prestazioni di calcolo stimando le dimensioni cpu, memoria, rete e scala GPU. Eseguire test di carico per raccogliere dati più accurati per informare l'esercizio di modellazione. |
Queste attività consentono di selezionare il dimensionamento appropriato per la piattaforma di calcolo e di ridimensionare in modo appropriato quando il carico nel sistema aumenta. |
| Valutare la competenza del team e iniziare con la piattaforma meno complessa che soddisfa le proprie esigenze o con una con cui il team ha già familiarità. | È possibile garantire operazioni più fluide ed evitare di sovraccaricare il team scegliendo una piattaforma di calcolo con cui hanno familiarità. |
| Siate flessibili nel vostro design. Mirare a una soluzione che è possibile scorrere nel tempo per adattarsi ai requisiti aziendali e tecnici in continua evoluzione. | La flessibilità consente di adattarsi più facilmente alle modifiche e ai miglioramenti nel tempo. È possibile rispondere in modo efficace alle esigenze aziendali e tecniche in continua evoluzione. |
| Valutare il costo totale di proprietà (TCO), inclusi i costi di gestione della soluzione. | Si ha una chiara comprensione dei costi, che è fondamentale per pianificare il modello di determinazione dei prezzi e garantire operazioni convenienti. |
| Valutare se è necessario usare piattaforme di calcolo specifiche a causa dello stack di tecnologie. Alcune piattaforme di calcolo sono più adatte per determinati linguaggi di programmazione, strumenti e sistemi operativi. Cercare di usare piattaforme che supportano in modo nativo le scelte tecnologiche. | È possibile evitare il costo della riprogettazione dell'architettura, che potrebbe includere la migrazione a una nuova piattaforma. |
| Valutare le funzionalità di affidabilità della piattaforma e considerare le garanzie del provider di servizi cloud nei contratti di servizio. | È possibile ridurre il rischio di interruzioni localizzate dei data center pianificando le funzionalità di affidabilità e usando le zone di disponibilità, se disponibili. |
Modello di tenancy e isolamento
Il modello aziendale SaaS determina se si ospitano le risorse per i clienti o le si gestiscono nell'ambiente del cliente. La maggior parte dei provider SaaS ospita risorse per conto dei clienti, che consente la flessibilità nella progettazione della piattaforma di calcolo. Isolare i carichi di lavoro dei clienti in modo efficace per ottimizzare l'efficienza dei costi senza compromettere l'esperienza o le prestazioni dei clienti.
Considerazioni relative alla progettazione
Pianificare il modello di tenancy. Il modello di tenancy determina la condivisione delle risorse tra i clienti ed è influenzato dai modelli aziendali e tariffari. I modelli a tenant singolo hanno costi più elevati per cliente rispetto ai modelli completamente multi-tenant. I prezzi devono riflettere queste differenze.
Requisiti dei clienti. Alcuni clienti potrebbero avere esigenze specifiche per la residenza dei dati, le garanzie di prestazioni o la conformità alla sicurezza. Se questi requisiti richiedono livelli di isolamento più elevati del solito, considerare come riflettere i costi maggiori nel modello aziendale.
Problema del vicino rumoroso. Tenere presente il problema del vicino rumoroso durante la condivisione delle risorse tra i tenant. Le risorse di calcolo sono interessate maggiormente. Per altre informazioni, vedere Antipattern del vicino rumoroso.
Quando si sceglie un modello di tenancy, bilanciare il risparmio sui costi della condivisione delle risorse con la necessità di garantire le prestazioni dei clienti. La sovra-condivisione delle risorse o la possibilità di un consumo eccessivo può compromettere l'esperienza del cliente.
Compromesso: prestazioni e costi. La condivisione delle risorse tra i clienti può essere conveniente, ma se alcuni clienti usano più risorse del previsto, questo approccio può ridurre le prestazioni per altri utenti. Per evitare questo problema, implementare una governance delle risorse appropriata per garantire che l'utilizzo del tenant rimanga entro i limiti previsti.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Valutare le funzionalità di isolamento della piattaforma di calcolo per assicurarsi che soddisfi i requisiti del modello di tenancy. | Per evitare di rielaborare la piattaforma, verificare prima di tutto la configurazione critica. |
| Applicare il modello di isolamento. Prestare attenzione alle risorse condivise, ad esempio cache dei dischi locali, memoria di sistema e cache esterne, perché possono involontariamente perdere dati tra i tenant se non sono gestiti correttamente. Per i requisiti di isolamento elevato, applicare l'isolamento all'interno della piattaforma di calcolo e nell'applicazione. |
L'isolamento sicuro riduce il rischio di perdita di dati tra tenant, un grave incidente di sicurezza. |
| Implementare la governance e il monitoraggio delle risorse, con visibilità delle metriche a livello di cliente. Monitorare in modo proattivo l'utilizzo delle risorse di ogni cliente per rilevare e mitigare i problemi dei vicini rumorosi. |
Si evitano problemi che interessano altri clienti monitorando il consumo delle risorse e attenuando i problemi in anticipo. |
Configurare per la scalabilità e l'efficienza dei costi
I clienti possono usare l'applicazione con profili di prestazioni diversi. Si prevede che l'applicazione gestisca le crescenti richieste degli utenti, i dati su larga scala e carichi di lavoro complessi senza compromettere velocità e prestazioni. L'architettura di sistema deve garantire scalabilità e prestazioni ottimali, sia che gestisca centinaia o milioni di utenti, bilanciando al contempo le esigenze e i costi delle prestazioni.
Per altre informazioni sulla gestione dei costi, vedere Fatturazione e gestione dei costi per i carichi di lavoro SaaS in Azure.
Considerazioni relative alla progettazione
Strategie di ridimensionamento orizzontale e verticale. Gli approcci di scalabilità orizzontale e verticale sono validi per la gestione di un carico maggiore. L'approccio usato dipende dalla capacità dell'applicazione di ridimensionarsi tra più istanze.
- La scalabilità orizzontale comporta l'aggiunta di più istanze di nodi di calcolo. L'architettura richiede un servizio di bilanciamento del carico per distribuire il traffico in ingresso tra più server o istanze.
- La scalabilità verticale comporta l'aumento delle risorse, ad esempio CPU e memoria, in un singolo server. Usare questo approccio per le applicazioni con stato che non necessitano di archivi di stato esterni come le cache. Il ridimensionamento verticale può causare brevi interruzioni del servizio e un limite di risorse in un singolo server.
Per il ridimensionamento e il partizionamento, vedere PE:05 Recommendations (Consigli su PE:05).
Scalabilità automatica. I sistemi devono gestire in modo efficiente vari livelli di domanda. Con l'aumentare del traffico degli utenti, le risorse dell'applicazione devono aumentare le prestazioni per mantenere le prestazioni. Quando la domanda diminuisce, le risorse si riducono per controllare i costi senza influire sull'esperienza utente. Fattori come l'utilizzo della CPU, l'ora del giorno o le richieste in ingresso guidano queste modifiche. La scalabilità automatica consente di bilanciare le prestazioni e i costi e di ridurre l'impatto della domanda elevata su altri tenant.
Per una scalabilità affidabile, vedere RE:06 Recommendations (Raccomandazioni su RE:06).
Pianificazione della capacità e allocazione di calcolo. L'onboarding di nuovi clienti nel carico di lavoro SaaS usa la capacità delle risorse. Anche se si ridimensiona verticalmente o orizzontalmente, si raggiungono i limiti, ad esempio vincoli di rete o archiviazione, nella scalabilità della soluzione.
Nota
Il modello Deployment Stamps consente di distribuire più istanze indipendenti della soluzione. Fornisce un'altra dimensione di ridimensionamento. È fondamentale comprendere la capacità di ogni stamp per determinare quando distribuire di più. Questo concetto è noto anche come imballaggio bin.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Scegliere scalabilità orizzontale rispetto alla scalabilità verticale. La scalabilità orizzontale è spesso meno complessa, più affidabile e più conveniente rispetto alla scalabilità verticale. | La scalabilità orizzontale è spesso più semplice, più affidabile e conveniente, che consente di ridimensionare fino a un livello superiore rispetto al ridimensionamento verticale. |
| Eseguire test di carico. | La simulazione dell'utilizzo consente di identificare i colli di bottiglia e le soglie di ridimensionamento prima di eseguire la distribuzione nell'ambiente di produzione. |
| Definire la soglia di ridimensionamento per la distribuzione di un nuovo timbro invece di ridimensionare orizzontalmente o verticalmente. Per una scalabilità conveniente senza perdita di prestazioni, condensare i tenant nel minor numero possibile di risorse. |
È meglio prepararsi a gestire la crescita oltre l'infrastruttura corrente. |
| Implementare la scalabilità automatica, laddove possibile. Impostare le regole di scalabilità automatica per riflettere il carico dell'applicazione in modo accurato. | È possibile ottimizzare le prestazioni e i costi aumentando e riducendo le risorse in base alle esigenze. |
| Monitorare e valutare i modelli di utilizzo dei clienti. | Quando modificare l'infrastruttura per migliorare le prestazioni o ottimizzare i costi. |
| Implementare meccanismi di memorizzazione nella cache, laddove possibile. | Si riduce il carico di elaborazione potenziale nel livello di calcolo. |
| Usare gli avvisi relativi ai costi. | Gli avvisi consentono di rilevare in anticipo i problemi di utilizzo elevato e controllo dei costi. |
| Usare le prenotazioni di Azure per i clienti che hanno impegni a lungo termine e un utilizzo di calcolo garantito per l'intero periodo. | È possibile ottimizzare l'efficienza dei costi per la capacità riservata. |
Progettare per la resilienza
La resilienza del livello di calcolo svolge un ruolo importante nella strategia di resilienza complessiva. L'applicazione deve tollerare e ripristinare gli errori comuni in modo automatico e senza alcun impatto sull'utente.
Considerazioni relative alla progettazione
Requisiti di affidabilità. Impostare requisiti di affidabilità chiari. Questi requisiti includono obiettivi interni, contratti di servizio e impegni dei clienti o contratti di servizio, che spesso specificano obiettivi di tempo di attività come il 99,9% al mese.
Per definire le destinazioni di affidabilità, vedere RE:04 Recommendations (Raccomandazioni RE:04).
Strategia di distribuzione. Le risorse cloud vengono distribuite in aree geografiche specifiche. In Azure le zone di disponibilità sono set di data center isolati all'interno di un'area. Per la resilienza, distribuire le applicazioni in più zone di disponibilità. La distribuzione tra aree o provider di servizi cloud migliora la resilienza, ma aggiunge complessità operativa e costi.
Fare riferimento a RE:05 Recommendations for using availability zones and regions (Consigli su RE:05 per l'uso di zone e aree di disponibilità).
Carichi di lavoro senza stato. Per distribuire applicazioni resilienti, in genere è necessario eseguire copie ridondanti in posizioni diverse. Questa attività può risultare complessa per i carichi di lavoro con stato, che devono mantenere lo stato della sessione. Mirare a creare carichi di lavoro senza stato, quando possibile.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Gestire gli errori temporanei nell'applicazione. | È possibile aumentare la disponibilità ripristinando rapidamente i problemi secondari. |
| Scegliere applicazioni senza stato. Se l'applicazione deve essere con stato, usare un meccanismo di archiviazione dello stato esterno come una cache per archiviare lo stato. | Si evita la perdita di stato causata da un'istanza non disponibile, ad esempio durante il bilanciamento del carico errato o durante un'interruzione. |
| Usare le zone di disponibilità. | È possibile aumentare la resilienza riducendo le interruzioni localizzate del data center. |
| Progettare un'architettura multimultidimensionale in caso di giustificazione aziendale. | Si soddisfano requisiti di tempo di attività elevati e si supportano gli utenti in aree diverse. |
| Eseguire l'ingegneria del caos. | È meglio comprendere dove si trovano i punti di errore e correggerli prima che si verifichi un'interruzione. |
| Limitare l'uso di componenti condivisi da più stamp. | Si eliminano singoli punti di guasto e si riduce l'area potenziale di impatto per un'interruzione. |
Risorse aggiuntive
La multi-tenancy è una metodologia aziendale di base per la progettazione di carichi di lavoro SaaS. Questi articoli forniscono altre informazioni sulle considerazioni sulla piattaforma di calcolo:
Passaggio successivo
Informazioni sulle considerazioni sulla rete per i carichi di lavoro SaaS.