Se utilizzi le metriche Pub/Sub come indicatore per eseguire il ridimensionamento automatico della pipeline, ecco alcuni suggerimenti.
Utilizza più di un indicatore per eseguire la scalabilità automatica della pipeline
Non utilizzare solo le metriche Pub/Sub per scalare automaticamente la pipeline. Potrebbe portare a scenari in cui hai un singolo punto di errore per le tue decisioni di scalabilità automatica. Utilizza invece una combinazione di indicatori per attivare il ridimensionamento automatico. Un esempio di un indicatore aggiuntivo è il livello di utilizzo della CPU del cliente. Questo indicatore può indicare se le attività client stanno gestendo il lavoro e se l'aumento delle dimensioni 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 (GCE) supporta la scalabilità automatica in base a indicatori come l'utilizzo della CPU e le metriche di monitoraggio. Compute Engine supporta anche più metriche e più indicatori per una maggiore affidabilità.
Per ulteriori informazioni sulla scalabilità con le metriche di monitoraggio, consulta Eseguire il ridimensionamento in base alle metriche di monitoraggio. Per ulteriori informazioni sulla scalabilità in base all'utilizzo della CPU, consulta Eseguire la scalabilità in base all'utilizzo della CPU.
La scalabilità automatica orizzontale dei pod (HPA) di Google Kubernetes Engine (GKE) supporta la scalabilità in base all'utilizzo delle risorse, ad esempio l'utilizzo di CPU e memoria, le metriche Kubernetes personalizzate e le metriche esterne come le metriche di monitoraggio per Pub/Sub. Supporta anche più indicatori.
Per ulteriori informazioni, consulta la sezione Scalabilità automatica pod orizzontale.
Come gestire 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 riduci le attività di elaborazione a zero, i messaggi già presenti nel backlog o pubblicati durante questo periodo potrebbero non essere utilizzati. Ciò aumenta la latenza end-to-end. Per ridurre al minimo la latenza, imposta un conteggio minimo delle 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.
Sia i gestori della scalabilità automatica GCE sia gli HPA GKE sono progettati per mantenere il conteggio corrente delle repliche 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 Pub/Sub per contribuire a evitare che le attività vengano sovraccaricate se vengono ridotte involontariamente a causa di metriche mancanti.