1. Introduzione
Il passaggio da architetture monolitiche a microservizi debolmente accoppiati nelle applicazioni cloud introduce una complessità significativa nella gestione delle risorse. Gli sviluppatori devono decidere quante risorse computazionali (ad esempio, repliche di container, VM) allocare per ogni microservizio. Questa decisione influisce in modo critico sia sul costo operativo per lo sviluppatore che sulla latenza end-to-end percepita dall'utente dell'applicazione. I metodi tradizionali di autoscaling, come l'Horizontal Pod Autoscaling (HPA), scalano ogni microservizio in modo indipendente basandosi su metriche locali come l'utilizzo della CPU. Tuttavia, questo approccio non è ottimale perché ignora la natura interdipendente dei microservizi all'interno di un flusso di lavoro applicativo. COLA (Collective Autoscaler) viene proposto come soluzione che alloca collettivamente le risorse tra tutti i microservizi con un obiettivo globale: minimizzare il costo in dollari garantendo che la latenza end-to-end dell'applicazione rimanga al di sotto di un target specificato.
2. Il Problema dell'Autoscaling Indipendente
L'autoscaling standard del settore opera attualmente in modo distribuito, per singolo microservizio. Ogni servizio attiva azioni di scaling (aggiunta/rimozione di VM o pod) quando la propria utilizzazione delle risorse (CPU, memoria) supera una soglia. Il difetto fondamentale è che questa visione locale non tiene conto delle performance globali dell'applicazione. Migliorare la latenza di un microservizio può avere un impatto trascurabile sulla latenza complessiva percepita dall'utente se un altro servizio nella catena rimane un collo di bottiglia. Ciò porta a un'allocazione inefficiente delle risorse – sovra-provisioning di alcuni servizi e sotto-provisioning dei colli di bottiglia critici – risultando in costi più elevati senza raggiungere l'obiettivo di livello di servizio (SLO) di latenza desiderato.
3. COLA: Approccio di Autoscaling Collettivo
COLA riformula il problema dell'autoscaling come un problema di ottimizzazione vincolata. Sostituisce molteplici autoscaler indipendenti con un singolo controller centralizzato che ha visibilità globale sulla topologia e sulle performance dei microservizi dell'applicazione.
3.1. Framework di Ottimizzazione Principale
L'obiettivo è formalizzato come:
- Obiettivo: Minimizzare il costo computazionale totale.
- Vincolo: Latenza end-to-end media o di coda dell'applicazione ≤ Latenza Target.
- Variabili Decisionali: Numero di VM (o repliche) allocate a ciascun microservizio $i$, indicato come $n_i$.
Questo è un complesso problema di ottimizzazione non lineare perché la relazione tra $n_i$ e la latenza end-to-end non è diretta e dipende dai pattern di carico di lavoro e dalla comunicazione inter-servizio.
3.2. Processo di Ricerca Offline
Risolvere questa ottimizzazione online è impraticabile a causa del tempo richiesto per il provisioning e la stabilizzazione delle performance. Pertanto, COLA impiega un processo di ricerca offline:
- Applicazione del Carico di Lavoro: Applicare un carico di lavoro rappresentativo all'applicazione.
- Identificazione del Collo di Bottiglia: Identificare il microservizio più congestionato (maggiore aumento dell'utilizzo della CPU sotto carico).
- Allocazione delle Risorse tramite Problema del Bandit: Per il servizio collo di bottiglia, determinare il numero ottimale di VM utilizzando una formulazione multi-armed bandit. La funzione di "ricompensa" bilancia il miglioramento della latenza contro l'aumento del costo.
- Iterazione: Ripetere i passaggi 2-3 per il microservizio successivo più congestionato fino a quando non viene raggiunto l'obiettivo di latenza globale.
- Generazione della Politica: Il risultato è una politica di scaling (una mappatura dalle caratteristiche del carico di lavoro alle allocazioni di risorse) che può essere distribuita online.
COLA può interpolare tra carichi di lavoro noti e ricadere su autoscaler di default se si trova di fronte a un pattern di carico di lavoro non visto.
4. Dettagli Tecnici e Formulazione Matematica
Il problema di ottimizzazione principale può essere rappresentato astrattamente come:
$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{soggetto a: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ Dove:
- $M$: Numero di microservizi.
- $n_i$: Numero di unità di risorse (es. VM) per il microservizio $i$.
- $C_i(n_i)$: Funzione di costo per il microservizio $i$ con $n_i$ unità.
- $L_{e2e}$: Funzione di latenza end-to-end, dipendente da tutti gli $n_i$ e dall'intensità del carico di lavoro $\lambda$.
- $L_{target}$: L'SLO di latenza desiderato.
5. Risultati Sperimentali e Valutazione
COLA è stato rigorosamente valutato rispetto a diversi autoscaler di base (basati sull'utilizzo e basati su ML) su Google Kubernetes Engine (GKE).
5.1. Configurazione Sperimentale
- Applicazioni: 5 applicazioni a microservizi open-source (es. Simple WebServer, BookInfo, Online Boutique).
- Piattaforme: GKE Standard (nodi gestiti dall'utente) e GKE Autopilot (infrastruttura gestita dal provider).
- Baseline: HPA standard (basato su CPU), autoscaler avanzati basati su ML.
- Carichi di Lavoro: 63 pattern di carico di lavoro distinti.
- Target: Raggiungere un SLO di latenza mediana o di coda (es. p95) specificato.
5.2. Metriche di Performance Chiave
Raggiungimento SLO
53/63
Carichi di lavoro in cui COLA ha raggiunto il target di latenza.
Riduzione Media dei Costi
19.3%
Rispetto all'autoscaler successivo più economico.
Politica Più Conveniente
48/53
COLA è stato il più economico per 48 dei 53 carichi di lavoro di successo.
Ottimalità su App Piccole
~90%
Per applicazioni più piccole dove la ricerca esaustiva era possibile, COLA ha trovato la configurazione ottimale in ~90% dei casi.
5.3. Riepilogo dei Risultati
I risultati dimostrano il significativo vantaggio di COLA. Ha costantemente raggiunto l'SLO di latenza desiderato laddove altri hanno fallito, e lo ha fatto a un costo sostanzialmente inferiore. I risparmi sui costi sono stati così pronunciati che il "costo di addestramento" per eseguire la ricerca offline di COLA è stato recuperato entro pochi giorni di funzionamento. Su GKE Autopilot, i benefici di COLA sono stati ancora più evidenti, poiché ha navigato efficacemente l'astrazione gestita dal provider per minimizzare i costi.
Descrizione Grafico (Immaginato): Un grafico a barre mostrerebbe probabilmente "Costo per Richiesta Riuscita" o "Costo Totale del Cluster" sull'asse Y, con diversi autoscaler (COLA, HPA, ML-A) sull'asse X. La barra di COLA sarebbe significativamente più bassa. Un secondo grafico potrebbe mostrare "Tasso di Violazione SLO di Latenza", dove la barra di COLA si avvicina allo zero mentre altre mostrano tassi di violazione più alti.
6. Framework di Analisi e Caso Esempio
Prospettiva dell'Analista: Una Scomposizione in Quattro Passi
Intuizione Principale: La svolta fondamentale del paper non è un nuovo algoritmo sofisticato, ma un cambiamento critico di prospettiva: trattare l'intera applicazione a microservizi come un unico sistema da ottimizzare, non una collezione di parti indipendenti. Questo è analogo al cambiamento nella visione artificiale portato da modelli come CycleGAN (Zhu et al., 2017), che è andato oltre la traduzione di immagini accoppiate considerando la consistenza ciclica dell'intero dominio di trasformazione. COLA applica un principio simile di "consistenza globale" alla gestione delle risorse.
Flusso Logico: L'argomentazione è convincentemente semplice: 1) Gli ottimi locali (scaling per servizio) sommano a un'inefficienza globale. 2) Pertanto, utilizzare un obiettivo globale (costo) con un vincolo globale (latenza end-to-end). 3) Poiché risolvere questo online è troppo lento, risolverlo offline tramite ricerca e distribuire la politica. L'eleganza risiede nell'utilizzo del problema del bandit per rendere efficiente la ricerca dell'allocazione ottimale per il collo di bottiglia, una tecnica supportata da ampie ricerche nell'apprendimento per rinforzo per l'ottimizzazione dei sistemi (es. lavori del RISELab della UC Berkeley).
Punti di Forza e Debolezze: Punti di Forza: I risultati empirici sono stellari – una riduzione del costo del 19.3% è una cifra da consiglio di amministrazione. L'approccio offline è pragmatico, evitando instabilità a runtime. Il framework è agnostico rispetto alla piattaforma. Debolezze: Il tallone d'Achille è la dipendenza da carichi di lavoro offline rappresentativi. In applicazioni in rapida evoluzione o sotto eventi di traffico "cigno nero", la politica pre-calcolata potrebbe essere obsoleta o catastrofica. La ricaduta su autoscaler di default del paper è un cerotto, non una cura, per questo problema di robustezza. Inoltre, la complessità della ricerca probabilmente scala male con il numero di microservizi, potenzialmente limitandone l'uso in applicazioni estremamente grandi e complesse.
Approfondimenti Azionabili: Per gli architetti cloud, il messaggio è chiaro: smettete di impostare soglie della CPU in isolamento. Investite nella costruzione o nell'adozione di osservabilità delle performance globali e di un motore decisionale centralizzato. Iniziate con un approccio ibrido: utilizzate la filosofia di COLA per definire catene di servizi critici e applicate lo scaling collettivo lì, lasciando servizi meno critici e indipendenti sul tradizionale HPA. Il ROI, come mostrato, può essere rapido. I provider cloud dovrebbero prendere nota; strumenti come GKE Autopilot necessitano di tali livelli di orchestrazione intelligente per mantenere veramente la promessa di infrastruttura "gestita".
7. Prospettive Applicative e Direzioni Future
I principi alla base di COLA hanno un'ampia applicabilità oltre lo scaling base delle VM:
- Scaling Multi-Risorsa ed Eterogeneo: Versioni future potrebbero decidere collettivamente la dimensione delle VM (ottimizzate per memoria vs. calcolo), l'allocazione di GPU e persino il posizionamento tra zone di disponibilità o provider cloud per costo e resilienza.
- Integrazione con Service Mesh: Accoppiare COLA con un service mesh (come Istio) fornirebbe una telemetria più ricca (tracciamento a livello di richiesta, grafi di dipendenza) e abiliterebbe persino il controllo diretto sul routing del traffico e sul circuit breaking come parte dell'ottimizzazione.
- Adattamento Online e Meta-Learning: La principale frontiera di ricerca è superare la limitazione offline. Tecniche di meta-learning potrebbero permettere a COLA di adattare rapidamente la sua politica online basandosi su feedback in tempo reale, o di esplorare in sicurezza nuove configurazioni durante periodi di basso traffico.
- Obiettivi di Green Computing: L'obiettivo di ottimizzazione potrebbe essere esteso per minimizzare l'impronta di carbonio o il consumo energetico, allineandosi con le iniziative di computing sostenibile, incorporando dati da fonti come il progetto Cloud Carbon Footprint.
- Marketplace per Politiche: Per pattern applicativi comuni (es. e-commerce, streaming multimediale), politiche COLA pre-ottimizzate potrebbero essere condivise o vendute, riducendo la necessità di sessioni di addestramento individuali.
8. Riferimenti
- Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
- Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
- Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
- Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (Esempio di RL avanzato rilevante per l'adattamento online).
- Cloud Carbon Footprint. (n.d.). Uno strumento open source per misurare e visualizzare l'impronta di carbonio dell'uso del cloud. Recuperato da https://www.cloudcarbonfootprint.org/.
- Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).