Se utilizzi le metriche Pub/Sub come indicatore per la scalabilità automatica della pipeline, ecco alcuni suggerimenti.
Utilizza più di un indicatore per scalare automaticamente la pipeline
Non utilizzare solo le metriche Pub/Sub per scalare automaticamente la pipeline. Potrebbe portare a scenari in cui hai un unico punto di errore per le tue decisioni di scalabilità automatica. Utilizza invece una combinazione di indicatori per attivare lo scaling automatico. Un esempio di indicatore aggiuntivo è il livello di utilizzo della CPU del client. Questo indicatore può indicare se le attività client gestiscono il lavoro e se lo scale up può consentire alle attività client di gestire più lavoro. Di seguito sono riportati alcuni esempi di indicatori di altri prodotti cloud che puoi utilizzare per la tua pipeline:
Compute Engine supporta la scalabilità automatica in base a indicatori come l'utilizzo della CPU e le metriche di Monitoring. Compute Engine supporta anche più metriche e più indicatori per una maggiore affidabilità.
Per saperne di più sulla scalabilità con le metriche di Monitoring, consulta Scalabilità in base alle metriche di Monitoring. Per ulteriori informazioni sulla scalabilità in base all'utilizzo della CPU, consulta Scala in base all'utilizzo della CPU.
La scalabilità automatica orizzontale dei pod (HPA) di Google Kubernetes Engine supporta la scalabilità automatica in base all'utilizzo delle risorse, come l'utilizzo di CPU e memoria, metriche Kubernetes personalizzate e metriche esterne come le metriche di Monitoring per Pub/Sub. Supporta anche più indicatori.
Per maggiori informazioni, consulta Scalabilità automatica orizzontale dei pod.
Utilizza la versione regionale delle metriche anziché quelle globali
Pub/Sub offre due versioni di ogni metrica utilizzata in genere con la
scalabilità automatica. Assicurati di utilizzare le versioni con il suffisso by_region:
Non utilizzare le versioni globali di queste metriche se vuoi che la scalabilità automatica
sia resiliente alle interruzioni di una singola regione. La versione globale di queste metriche
richiede il calcolo del backlog in tutte le regioni in cui sono presenti
messaggi, il che significa che l'indisponibilità in una singola regione comporta una lacuna
nei dati. Al contrario, le versioni by_region delle metriche calcolano e riportano
il backlog su base regionale. Se il backlog non può essere calcolato per una
singola regione, la metrica riporta comunque i valori per le altre regioni.
Evita di utilizzare le metriche di velocità effettiva lato abbonato per scalare automaticamente gli abbonati
Evita di utilizzare metriche di velocità effettiva lato abbonato come
subscription/ack_message_count per la scalabilità automatica dei client abbonati. In alternativa,
valuta la possibilità di utilizzare metriche che riflettano direttamente l'arretrato di messaggi in attesa
di essere elaborati, come subscription/num_unacked_messages o
subscription/oldest_unacked_message_age menzionati in precedenza.
Problemi relativi all'utilizzo delle metriche di velocità effettiva lato abbonato per la scalabilità automatica
L'utilizzo di queste metriche può causare problemi perché rappresentano la quantità di traffico tra Pub/Sub e gli abbonati. Il dimensionamento basato su questa metrica può creare un ciclo autoreferenziale in cui una diminuzione dei messaggi consegnati o confermati comporta la riduzione dei client. Ad esempio, questo potrebbe verificarsi in caso di calo temporaneo del traffico o di problemi con uno dei tuoi iscritti.
Se i tuoi client fare lo scale down a zero o quasi zero, tutto il traffico di iscrizione in corso può interrompersi e gli abbonati potrebbero non essere in grado di elaborare i messaggi, anche se ne arrivano di nuovi. Ciò può comportare un ritardo significativo nell'importazione e portare a uno stato irreversibile per i client abbonati.
Gestire le lacune nelle metriche quando si verificano
Non dare per scontato che l'assenza di metriche significhi che non ci sono messaggi da elaborare. Ad esempio, se in risposta alle metriche mancanti, riduci le attività di elaborazione a zero, i messaggi già presenti nel backlog o pubblicati durante questo periodo potrebbero non essere utilizzati. In questo modo, aumenta la latenza end-to-end. Per ridurre al minimo la latenza, imposta un conteggio minimo di attività maggiore di zero in modo da essere sempre pronto a gestire i messaggi pubblicati, anche se le metriche Pub/Sub recenti indicano una coda vuota.
Gli autoscaler di Compute Engine e gli HPA di Google Kubernetes Engine sono progettati per mantenere il conteggio attuale delle repliche quando le metriche non sono disponibili. In questo modo, viene fornita una rete di sicurezza se non sono disponibili metriche.
Puoi anche implementare meccanismi di controllo del flusso Pub/Sub per evitare che i task vengano sovraccaricati se vengono ridimensionati in modo involontario a causa della mancanza di metriche.