Questa pagina fornisce le best practice per i test di carico del servizio Cloud Run per determinare se esegue il ridimensionamento correttamente durante l'utilizzo in produzione e per trovare eventuali colli di bottiglia che ne impediscono il ridimensionamento.
Test da eseguire prima del test di carico
Identifica e risolvi i problemi di concorrenza in un ambiente di sviluppo o di test di piccole dimensioni prima di procedere con il test di carico. Misura la concorrenza dei contenitori prima di eseguire un test di carico e assicurati che il servizio Cloud Run si avvii in modo affidabile.
Concentra i test dei contenitori su piccoli conteggi incrementali in esecuzioni con scalabilità manuale. Puoi approssimare il ridimensionamento manuale in Cloud Run impostando instance_maximum sul valore a cui vuoi eseguire il ridimensionamento.
Se hai creato o modificato di recente l'immagine container, testala indipendentemente prima di eseguire un test di carico.
Prima di eseguire un test di carico su larga scala, dovresti anche controllare altri tipi di problemi di prestazioni, come latenza e utilizzo della CPU eccessivi.
Utilizza max instances in modo appropriato
Cloud Run applica un numero massimo di istanze per limitare il ridimensionamento di un servizio. Il numero massimo di istanze predefinito è 100. Se prevedi che il test di carico superi questo valore predefinito, assicurati di collaborare con il team dell'account di Google e di impostare un nuovo valore massimo. Se non hai ancora un rapporto 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 di CPU e dai limiti di memoria, nonché dalla regione in cui esegui il deployment.
Questi limiti sono gestiti da un limite di quota e possono essere aumentati inviando una richiesta di aumento del limite di quota.
Test di carico nella regione us-central1
La regione Google Cloud us-central1 offre un limite di quota elevato, pertanto Google consiglia di eseguire test di carico in us-central1. Se prevedi di avvicinarti ai limiti di quota, contatta il team dedicato al tuo account
e invia una richiesta di assistenza con i dettagli relativi al tempo e alle dimensioni del test.
Testa un profilo di utilizzo della CPU e di inizializzazione del servizio appropriato
In uno scenario ideale, esegui il deployment di una versione di test del servizio su Cloud Run e ne esegui direttamente il test di carico. Tuttavia, in alcuni casi potresti non essere in grado di eseguire il deployment di una versione di test 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 il rendimento del servizio simulandolo con un servizio più semplice che abbia un utilizzo della CPU e tempi di inizializzazione paragonabili.
Il tempo di inizializzazione è particolarmente importante per la scalabilità rapida. Tieni presente che anche eseguire test con qualcosa di troppo semplice è problematico. Ad esempio, evita di eseguire test con un semplice servizio hello world che restituisce le richieste ricevute senza alcuna elaborazione.
Utilizza un test harness per generare carichi
Puoi generare carichi di test che causano un picco controllato del traffico utilizzando un test harness, 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 semplici richieste HTTP o registrare una sessione del browser con JMeter. Cloud Run ti consente di testare il tuo servizio senza accesso a internet utilizzando l'autenticazione dello sviluppatore. In questo modo, è possibile accedere da un framework 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 la frequenza e la concorrenza. Pub/Sub non è una buona scelta di strumento per generare carico perché non puoi controllare la frequenza del traffico e il numero di client. Se non conosci la frequenza e la concorrenza, non saprai cosa stai testando.
Utilizzare l'analisi dettagliata dei log utilizzando i log esportati
Per comprendere la risposta del servizio Cloud Run ai picchi di traffico rapidi, è necessaria un'analisi degli eventi in tempo reale. Per farlo è necessaria l'analisi dei log perché la granularità dei dati di monitoraggio non è sufficientemente fine. L'analisi dei log ti consente anche di esaminare i motivi delle richieste con alta latenza.
Quando scrivi i log, puoi migliorare le prestazioni di logging scrivendo direttamente in stdout anziché utilizzare una libreria client di Cloud Logging.
Per configurare un'esportazione dei log prima di iniziare il test, crea un sink dei log con la destinazione BigQuery e un filtro di inclusione, ad esempio:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evitare gli avvii a freddo spuri
Per ridurre al minimo gli avvii a freddo che gli utenti riscontrano, imposta il numero minimo di istanze su almeno 1.
Assicurati che il servizio sia scalabile in modo lineare
Ripeti il test con carichi diversi per assicurarti che il servizio Cloud Run sia scalabile in modo lineare con il 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 ottenere una panoramica dei risultati e integrare l'analisi dettagliata dei log utilizzando i log esportati.
I grafici di monitoraggio possono aiutarti a scoprire:
- Con quale rapidità, arrotondato al secondo più vicino, vengono create e inizializzate le nuove istanze?
- Le richieste sono distribuite in modo uniforme tra le diverse istanze?
- Quanto velocemente la latenza in diversi percentile può essere ridotta a un valore di stato stazionario?
Puoi utilizzare l'interfaccia utente della console Google Cloud per BigQuery per eseguire l'introspezione dello schema dei log esportato e visualizzare l'anteprima dei risultati. Esegui le query e traccia i risultati utilizzando Colab, che è già integrato con BigQuery, Pandas e Matplotlab. Colab si integra anche facilemente con strumenti di visualizzazione dei dati avanzati come Seaborn.
Individuare i colli di bottiglia
I test di carico possono aiutarti a scoprire l'esistenza di codice inefficiente e di colli di bottiglia di scalabilità. Il codice inefficiente comporta costi più elevati perché deve gestire più traffico, ma non impedisce necessariamente il ridimensionamento. Ad esempio, una dipendenza da una traduzione del database con blocco a livello di tabella può rappresentare un collo di bottiglia che impedisce il ridimensionamento del servizio Cloud Run perché è possibile eseguire una sola transazione alla volta.
Controllare il rendimento percepito dal cliente
Puoi eseguire query sui log acquisiti da JMeter, che includono le latenze misurate sul client. Tuttavia, poiché gli strumenti di test del server come JMeter non sono uguali a un browser o a un client mobile, ti consigliamo di eseguire anche un test con un framework basato su browser, come Selenium Webdriver, o un framework di test del client mobile. Fai attenzione alle latenze massime eccessive dovute all'inizializzazione della connessione TLS, che potrebbero distorcere 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 se il tuo servizio può scalare in base al traffico massimo previsto. Esegui il test con un harness come JMeter. Esportare i log in BigQuery per un'analisi dettagliata.