En esta página se describen las prácticas recomendadas para realizar pruebas de carga en tu servicio de Cloud Run y determinar si se escala correctamente durante el uso en producción, así como para identificar los cuellos de botella que impiden que se escale.
Pruebas que se deben ejecutar antes de las pruebas de carga
Identifica y resuelve los problemas de simultaneidad en un entorno de desarrollo o de prueba pequeño antes de proceder a las pruebas de carga. Mide la simultaneidad de los contenedores antes de realizar una prueba de carga y asegúrate de que tu servicio de Cloud Run se inicia de forma fiable.
Centra las pruebas de contenedores en recuentos incrementales pequeños en ejecuciones escaladas manualmente. Puedes aproximar el escalado manual en Cloud Run configurando el valor de instancias máximas al valor al que quieras escalar.
Si has creado o cambiado recientemente la imagen de contenedor, pruébala de forma independiente antes de realizar una prueba de carga.
También debes comprobar otros tipos de problemas de rendimiento, como la latencia excesiva y la utilización de la CPU, antes de ejecutar una prueba de carga a gran escala.
Usar max instances de forma adecuada
Cloud Run aplica un número máximo de instancias para limitar el escalado de un servicio. El número máximo de instancias predeterminado es 100. Si crees que tu prueba de carga superará este valor predeterminado, ponte en contacto con tu equipo de cuenta de Google y define un nuevo máximo. Si aún no tienes una relación con un equipo de cuentas, ponte en contacto con el equipo de Ventas de Google Cloud.
El número máximo de instancias que puedes seleccionar depende de los límites de CPU y de memoria, así como de la región en la que vayas a implementar las instancias.
Estos límites se gestionan mediante un límite de cuota y se pueden aumentar enviando una solicitud de aumento del límite de cuota.
Prueba de carga en la región europe-west1
La Google Cloud región europe-west1 ofrece un límite de cuota alto, por lo que Google recomienda realizar pruebas de carga en europe-west1.
Coordínate con el equipo de tu cuenta y envía un caso de asistencia con los detalles de la hora y la escala de la prueba si prevés que te acercarás a los límites de cuota.
Probar un perfil de uso de CPU e inicialización de servicios adecuado
En un caso ideal, desplegarías una versión de prueba de tu servicio en Cloud Run y la probarías directamente. Sin embargo, en algunos casos, es posible que no puedas implementar una versión de prueba de tu servicio. Por ejemplo, tu servicio de Cloud Run puede formar parte de un ecosistema complejo que sea difícil de replicar en un entorno de pruebas.
En estos casos, puedes aproximar el rendimiento de tu servicio simulándolo con un servicio más sencillo que tenga un uso de CPU y unos tiempos de inicialización comparables.
El tiempo de inicialización es especialmente importante para el escalado rápido. Ten en cuenta que
probar con algo demasiado sencillo también es problemático. Por ejemplo, no hagas pruebas con un servicio hello world sencillo que devuelva las solicitudes recibidas sin procesarlas.
Usar un arnés de prueba para generar cargas
Puedes generar cargas de prueba que provoquen un aumento controlado del tráfico mediante un arnés de prueba, como JMeter. Puedes usar el número de grupos de hilos de JMeter y el tiempo de espera entre solicitudes en la prueba de JMeter para aumentar la carga.
También puedes enviar solicitudes HTTP sencillas o grabar una sesión de navegador con JMeter. Cloud Run te permite probar tu servicio sin acceso a Internet mediante la autenticación de desarrollador. Esto permite el acceso desde un arnés de pruebas como JMeter, que se ejecuta en una máquina virtual de Compute Engine conectada a una nube privada virtual asociada al proyecto.
No genere carga a partir de herramientas en las que no se puedan controlar la tasa y la simultaneidad. Pub/Sub no es una buena opción para generar carga porque no puedes controlar la tasa de tráfico ni el número de clientes. Si no conoces la tasa y la simultaneidad, no sabrás qué estás probando.
Usar análisis de registros detallados con registros exportados
Necesitas un análisis de los eventos segundo a segundo para entender la respuesta de tu servicio de Cloud Run a los picos de tráfico rápidos. Para ello, es necesario analizar los registros, ya que la granularidad de los datos de monitorización no es lo suficientemente precisa. El análisis de registros también te permite investigar los motivos de las solicitudes con una latencia alta.
Cuando escribes registros, puedes obtener un mejor rendimiento si lo haces directamente en stdout en lugar de usar una biblioteca de cliente de Cloud Logging.
Para configurar una exportación de registros antes de empezar la prueba, crea un sumidero de registros con el destino BigQuery y un filtro de inclusión, como el siguiente:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evitar arranques en frío falsos
Para minimizar los arranque en frío que experimentan los usuarios, define el número mínimo de instancias en 1 como mínimo.
Asegúrate de que tu servicio se escale de forma lineal
Repite la prueba con diferentes cargas para asegurarte de que tu servicio de Cloud Run se escale de forma lineal con la carga y no alcance un cuello de botella limitante con una carga inferior a la que esperas en producción.
Analizar y visualizar los resultados en Colab
Usa los gráficos de monitorización de resumen para obtener una visión general de los resultados y complementar el análisis de registros detallado con los registros exportados.
Los gráficos de monitorización pueden ayudarte a descubrir lo siguiente:
- ¿Con qué rapidez, hasta el segundo más cercano, se crean e inicializan las nuevas instancias?
- ¿Cómo se distribuyen las solicitudes de forma uniforme entre las diferentes instancias?
- ¿Con qué rapidez se puede reducir la latencia en diferentes percentiles hasta alcanzar un valor estable?
Puedes usar la interfaz de usuario de la consola de Google Cloud BigQuery para inspeccionar el esquema de registro exportado y obtener una vista previa de los resultados. Ejecuta las consultas y representa los resultados con Colab, que se integra fácilmente con BigQuery, Pandas y Matplotlib. Colab también se integra fácilmente con herramientas de visualización de datos enriquecidos, como Seaborn.
Detectar cuellos de botella
Las pruebas de carga pueden ayudarte a descubrir la existencia de código ineficiente y cuellos de botella de escalado. El código ineficiente conlleva costes más elevados, ya que necesita gestionar más tráfico, pero no impide necesariamente el escalado. Por ejemplo, una dependencia de una traducción de base de datos con bloqueo a nivel de tabla puede ser un cuello de botella que impida que el servicio de Cloud Run se escale, ya que solo se puede ejecutar una transacción a la vez.
Comprobar el rendimiento tal como lo experimenta el cliente
Puedes consultar los registros capturados por JMeter, donde los registros incluyen latencias medidas en el cliente. Sin embargo, como las herramientas de pruebas de servidores, como JMeter, no son lo mismo que un navegador o un cliente móvil, también puedes hacer una prueba con un framework basado en navegador, como Selenium Webdriver, o con un framework de pruebas de clientes móviles. Ten cuidado con las latencias máximas excesivas debido a la inicialización de la conexión TLS, ya que pueden sesgar los resultados con valores atípicos.
Resumen de las prácticas recomendadas
Realiza una prueba de carga para determinar si migrar a Cloud Run es la opción adecuada y si tu servicio puede escalarse hasta el tráfico máximo esperado. Ejecuta la prueba con un arnés como JMeter. Exporta los registros a BigQuery para analizarlos en detalle.