Best practice per l'utilizzo delle metriche Pub/Sub come indicatore di scalabilità

Se utilizzi le metriche Pub/Sub come indicatore per scalare automaticamente la pipeline, ecco alcuni suggerimenti.

Usa 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 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à del cliente stanno gestendo il lavoro e se lo scale up consente alle attività del cliente di gestire ulteriormente il 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 Monitoring. Compute Engine supporta anche più metriche e indicatori multipli per una maggiore affidabilità.

    Per ulteriori informazioni sulla scalabilità con le metriche di Monitoring, consulta Scalabilità basata sulle metriche di Monitoring. Per saperne di più 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 (GKE) supporta la scalabilità automatica basata sull'utilizzo di risorse come l'utilizzo di CPU e memoria, metriche Kubernetes personalizzate e metriche esterne come le metriche di Monitoring per Pub/Sub. Supporta inoltre più indicatori.

    Per saperne di più, consulta Scalabilità automatica orizzontale dei pod.

Come affrontare 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 a metriche mancanti, fai fare lo scale down delle attività di elaborazione a zero, i messaggi già presenti nel backlog o che vengono pubblicati durante questo periodo non verranno 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 che gli HPA GKE sono progettati per mantenere il numero di repliche attuale 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 che le attività vengano sovraccaricate se vengono involontariamente ridimensionate a causa di metriche mancanti.