Se utilizzi le metriche di Pub/Sub come indicatore per la scalabilità automatica della pipeline, ecco alcuni suggerimenti.
Utilizza più di un indicatore per la scalabilità automatica della pipeline
Non utilizzare solo le metriche di Pub/Sub per la scalabilità automatica della pipeline. Potrebbe portare a scenari in cui hai un singolo punto di errore per le decisioni di scalabilità automatica. Utilizza invece una combinazione di indicatori per attivare la scalabilità automatica. Un esempio di indicatore aggiuntivo è il livello di utilizzo della CPU del client. Questo indicatore può indicare se le attività client stanno gestendo il lavoro e se l'aumento di scalabilità 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 pipeline:
Compute Engine supporta la scalabilità automatica basata su 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 ulteriori informazioni sulla scalabilità con le metriche di Monitoring, consulta Scalabilità basata sulle metriche di Monitoring. Per ulteriori informazioni sulla scalabilità con l'utilizzo della CPU, consulta Scalabilità basata sull'utilizzo della CPU.
La scalabilità automatica orizzontale dei pod (HPA) di Google Kubernetes Engine supporta la scalabilità automatica basata sull'utilizzo delle risorse, come l'utilizzo di CPU e memoria utilizzata, le metriche Kubernetes personalizzate e le metriche esterne, come le metriche di Monitoring per Pub/Sub. Supporta anche più indicatori.
Per ulteriori informazioni, consulta Scalabilità automatica orizzontale dei pod.
Utilizza la versione regionale delle metriche anziché le versioni globali
Pub/Sub offre due versioni di ogni metrica in genere utilizzata 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 a livello di 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 segnalano il backlog per regione. Se non è possibile calcolare il backlog per una singola regione, la metrica segnala comunque i valori per le altre regioni.
Evita di utilizzare le metriche di throughput lato sottoscrittore per la scalabilità automatica dei sottoscrittori
Evita di utilizzare le metriche di throughput lato sottoscrittore come subscription/ack_message_count per la scalabilità automatica dei client sottoscrittori. Valuta invece l'utilizzo di metriche che riflettono direttamente il backlog di messaggi in attesa di essere elaborati, come subscription/num_unacked_messages o subscription/oldest_unacked_message_age menzionate in precedenza.
Problemi relativi all'utilizzo delle metriche di throughput lato sottoscrittore per la scalabilità automatica
L'utilizzo di queste metriche può causare problemi perché rappresentano la quantità di traffico tra Pub/Sub e i sottoscrittori. La scalabilità basata su questa metrica può creare un loop autoreferenziale in cui una diminuzione dei messaggi consegnati o confermati comporta la riduzione della scalabilità dei client. Ad esempio, questo potrebbe verificarsi se si verifica un calo temporaneo del traffico o se si verifica un problema con uno dei tuoi sottoscrittori.
Se i client fare lo scale down a zero o quasi, tutto il traffico di sottoscrizione in corso può interrompersi e i sottoscrittori potrebbero non essere in grado di elaborare i messaggi, anche se ne arrivano di nuovi. Questo può comportare un ritardo di inserimento significativo e portare a uno stato non recuperabile per i client sottoscrittori.
Gestisci 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 fai fare lo scale down delle attività di elaborazione a zero, i messaggi già presenti nel backlog o pubblicati durante questo periodo potrebbero non essere utilizzati. Questo aumenta la latenza end-to-end. Per ridurre al minimo la latenza, imposta un numero minimo di attività maggiore di zero in modo da essere sempre pronto a gestire i messaggi pubblicati, anche se le metriche di Pub/Sub recenti indicano una coda vuota.
Sia i gestori della scalabilità automatica di Compute Engine sia gli HPA di Google Kubernetes Engine sono progettati per mantenere il numero di repliche corrente quando le metriche non sono disponibili. Questo fornisce una rete di sicurezza se non sono disponibili metriche.
Puoi anche implementare meccanismi di controllo del flusso di Pub/Sub per evitare che le attività vengano sovraccaricate se vengono ridotte involontariamente a causa della mancanza di metriche.