Questa pagina fornisce le best practice per testare il carico del servizio Cloud Run al fine di determinare se scala correttamente durante l'uso in produzione e per individuare eventuali colli di bottiglia che ne impediscono la scalabilità.
Test da eseguire prima dei test di carico
Identifica e risolvi i problemi di contemporaneità in un ambiente di sviluppo o di test ridotto prima di procedere con il test di carico. Misura la contemporaneità dei container prima di eseguire un test di carico e assicurati che il servizio Cloud Run si avvii in modo affidabile.
Concentra i test dei container su piccoli conteggi incrementali nelle esecuzioni scalate manualmente. Puoi approssimare la scalabilità manuale in Cloud Run impostando il numero massimo di istanze sul valore su cui vuoi scalare.
Se hai creato l'immagine container o hai modificato di recente l'immagine container, esegui un test indipendente prima di eseguire un test di carico.
Prima di eseguire un test di carico su larga scala, dovresti anche verificare altri tipi di problemi di prestazioni, come latenza eccessiva e utilizzo della CPU.
Usa max instances in modo appropriato
Cloud Run applica il numero massimo di istanze per limitare la scalabilità di un servizio. Il numero massimo predefinito di istanze è 100. Se prevedi che il test di carico supererà questo valore predefinito, assicurati di collaborare con il team dedicato al tuo account presso Google e di impostare un nuovo valore massimo. Se non hai ancora rapporti con un team dedicato all'account, contatta il team di vendita di Google Cloud.
Il numero massimo di istanze che puoi selezionare dipende dai limiti della CPU e dai limiti di memoria, nonché dall'area geografica in cui stai eseguendo il deployment.
Questi limiti sono gestiti da un limite di quota e possono essere aumentati effettuando una richiesta di aumento del limite di quota.
Test di carico nella regione us-central1
La regione di Google Cloud us-central1 offre un limite di quota elevato, quindi Google
consiglia il test di carico in us-central1. Coordinati con il team dedicato al tuo account e invia una richiesta di assistenza con i dettagli delle tempistiche e della portata del test se prevedi di avvicinarti ai limiti di quota.
Testa un utilizzo della CPU e un profilo di inizializzazione del servizio appropriati
In uno scenario ideale, esegui il deployment di una versione di test del tuo servizio in Cloud Run e la testiamo direttamente. Tuttavia, in alcuni casi potrebbe non essere possibile eseguire il deployment di una versione di prova del servizio. Ad esempio, il tuo servizio Cloud Run potrebbe far parte di un ecosistema complesso difficile da replicare in un ambiente di test.
In questi casi, puoi approssimare le prestazioni del tuo servizio simulandole con un servizio più semplice con un utilizzo della CPU comparabile e tempi di inizializzazione comparabili.
Il tempo di inizializzazione è particolarmente importante per una scalabilità rapida. Tieni presente che anche eseguire test con qualcosa di troppo semplice è problematico. Ad esempio, evita di eseguire test con un
servizio hello world semplice che restituisce le richieste ricevute senza alcuna elaborazione.
Utilizzare un imbracatura di test per generare carichi
Puoi generare carichi di test che causano un picco controllato di traffico utilizzando un test Bard, come JMeter. Puoi utilizzare il numero di gruppi di thread JMeter e il ritardo tra le richieste nel test JMeter per aumentare il carico.
Puoi anche inviare richieste HTTP semplici o registrare una sessione del browser con JMeter. Cloud Run consente di testare il servizio senza accesso a Internet utilizzando l'autenticazione sviluppatore. Ciò consente l'accesso da un imbracatura di test come JMeter, in esecuzione su una macchina virtuale Compute Engine collegata a un Virtual Private Cloud associato al progetto.
Non generare carico da strumenti in cui non è possibile controllare frequenza e contemporaneità. Pub/Sub non è uno strumento che consente di generare il carico perché non puoi controllare la velocità del traffico e il numero di client. Se non conosci la frequenza e la contemporaneità, non saprai su cosa stai testando.
Usa l'analisi dettagliata dei log utilizzando i log esportati
Hai bisogno di un'analisi secondo per secondo degli eventi per comprendere la risposta del servizio Cloud Run ai rapidi picchi di traffico. A questo scopo, è necessaria l'analisi dei log perché la granularità dei dati di monitoraggio non è sufficientemente granulare. L'analisi dei log consente inoltre di esaminare i motivi delle richieste con latenza elevata.
Quando scrivi i log, puoi migliorare le prestazioni di logging scrivendo direttamente su stdout anziché utilizzare una libreria client di Cloud Logging.
Per configurare un'esportazione dei log prima di iniziare il test, crea un sink di log con la destinazione BigQuery e un filtro di inclusione, ad esempio:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evita avvii a freddo sbagliati
Per ridurre al minimo gli avvii a freddo riscontrati dagli utenti, imposta il numero minimo di istanze su almeno 1.
Assicurati che il servizio faccia lo scale out in modo lineare
Ripeti il test con carichi diversi per assicurarti che il tuo servizio Cloud Run faccia lo scale out in modo lineare in base al carico e non raggiunga un collo di bottiglia limitante con un carico inferiore a quello previsto in produzione.
Analizza e visualizza i risultati in Colab
Utilizza i grafici di monitoraggio di riepilogo per acquisire una comprensione ad alto livello dei risultati e integrare l'analisi dettagliata dei log utilizzando i log esportati.
I grafici di monitoraggio possono aiutarti a scoprire:
- Quanto velocemente vengono create e inizializzate nuove istanze, con il secondo più vicino?
- Quanto sono distribuite le richieste tra istanze diverse in modo uniforme?
- Quanto ci vuole prima che la latenza a percentili diversi venga determinata per scendere a un valore fisso?
Puoi utilizzare l'interfaccia utente della console Google Cloud per BigQuery per analizzare lo schema di log esportato e visualizzare l'anteprima dei risultati. Esegui le query e traccia i risultati utilizzando Colab, già integrato con BigQuery, Pandas e Matplotlab. Inoltre, Colab si integra facilmente con strumenti di visualizzazione di dati avanzati come Seaborn.
Individua i colli di bottiglia
I test di carico possono aiutarti a scoprire l'esistenza sia di codice inefficiente sia di colli di bottiglia di scalabilità. Un codice inefficiente comporta costi più elevati, in quanto deve gestire più traffico, ma non impedisce necessariamente la scalabilità. Ad esempio, una dipendenza su una traduzione del database con blocco a livello di tabella può essere un collo di bottiglia che impedisce al servizio Cloud Run di scalare perché può essere eseguita una sola transazione alla volta.
Controllare il rendimento in base all'esperienza del cliente
Puoi eseguire query sui log acquisiti da JMeter, dove i log includono le latenze misurate sul client. Tuttavia, poiché gli strumenti di test del server come JMeter non sono gli stessi di un browser o di un client mobile, ti consigliamo di eseguire un test con un framework basato su browser, come Selenium Webdriver o con un framework di test dei client mobile. Fai attenzione alle latenze massime eccessive dovute all'inizializzazione della connessione TLS che potrebbero alterare i risultati con valori anomali.
Riepilogo delle best practice
Esegui un test di carico per determinare se la migrazione a Cloud Run è la scelta giusta e che il tuo servizio possa scalare fino al traffico previsto massimo. Esegui il test con un'imbracatura come JMeter. Esportare i log in BigQuery per un'analisi dettagliata.