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 è presente un single point of failure 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 gestiscono il lavoro e se lo scale up può consentire alle attività client di gestire più lavoro. Ecco alcuni esempi di indicatori di altri prodotti Cloud che puoi utilizzare per la tua 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 migliore affidabilità.
Per ulteriori informazioni sulla scalabilità con le metriche di Monitoring, consulta Scalabilità in base alle metriche di Monitoring. Per saperne di più sulla scalabilità con l'utilizzo della CPU, consulta Scalabilità 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 di risorse come 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.
Come colmare le lacune nelle metriche quando si verificano.
Non dare per scontato che l'assenza di metriche indichi che non ci sono messaggi da elaborare. Ad esempio, se in risposta a metriche mancanti scale down le attività di elaborazione a zero, i messaggi già nel backlog o che vengono pubblicati in questo periodo potrebbero non essere consumati. Ciò 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 pronti a gestire i messaggi pubblicati, anche se le metriche 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 attuale di repliche quando le metriche non sono disponibili. Ciò fornisce una rete di sicurezza se non sono disponibili metriche.
Puoi anche implementare meccanismi di controllo del flusso Pub/Sub per evitare il sovraccarico delle attività se vengono ridotte involontariamente a causa di metriche mancanti.
Utilizza la versione regionale delle metriche
Pub/Sub offre due versioni di ogni metrica, generalmente 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 di una singola regione. La versione globale di queste metriche
richiede il calcolo del backlog in tutte le regioni note per la presenza
di messaggi, il che significa che l'indisponibilità in una singola regione comporta una
gap di dati. Al contrario, le versioni by_region delle metriche calcolano e registrano il backlog in base alla regione. Se non è possibile calcolare il backlog per una singola regione, la metrica riporta comunque i valori per le altre regioni.