Información acerca del ajuste de escala automático de instancias en los servicios de Cloud Run

El ajuste de escala automático de Cloud Run ajusta la cantidad de instancias de contenedor para cada revisión del servicio para que coincida con las solicitudes, los eventos y el uso de CPU entrantes. El escalado de instancias según demanda ayuda a tu servicio a controlar los aumentos repentinos de tráfico y a reducir la escala a cero cuando está inactivo para disminuir los costos.

Puedes ajustar los umbrales de ajuste de escala automático configurando objetivos personalizados de CPU y simultaneidad, y estableciendo límites de instancias mínimos y máximos. Si tu servicio usa la CPU fuera del procesamiento de solicitudes, establece las instancias mínimas en 1 como mínimo. Para ejecutar un recuento de instancias fijo, consulta Escalado manual.

Comportamiento del ajuste de escala automático horizontal del servicio

Cloud Run tiene dos mecanismos de ajuste de escala automático: el escalado basado en métricas y el escalado a pedido para determinar la cantidad de instancias necesarias para entregar tráfico.

Escalamiento basado en métricas

El escalado basado en métricas ajusta automáticamente la cantidad de instancias según los factores de escalamiento del uso promedio de CPU y la simultaneidad promedio de solicitudes para proporcionar una capacidad de entrega estable para tu servicio de Cloud Run.

El escalador automático determina una cantidad recomendada de instancias en función de la cantidad máxima de instancias que calcula para cada uno de los siguientes controladores de escalado de forma independiente:

  • Uso de CPU: Calcula la cantidad de instancias promediando el uso de CPU por segundo durante un período de 1 minuto y lo divide por la cantidad de CPU por instancia. Este resultado se divide aún más por el objetivo de CPU. La siguiente ecuación define este cálculo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \right\rceil \]

  • Simultaneidad de solicitudes: Calcula la cantidad de instancias promediando la simultaneidad de solicitudes por segundo durante un período de 1 minuto y 10 minutos, y divide este valor por la simultaneidad máxima. Este resultado se divide aún más por el objetivo de simultaneidad de solicitudes. La siguiente ecuación define este cálculo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\max(\text{average concurrent requests over 1 minute, 10 minutes})}{\text{Maximum concurrency}} \right)}{\text{Concurrency target}} \right\rceil \]

  • Ajuste de simultaneidad adaptable (ACT): Calcula la cantidad recomendada de instancias para la simultaneidad de solicitudes promedio de 1 minuto. Este método usa el valor de ACT de cada instancia como la capacidad de simultaneidad de solicitudes de la instancia en lugar del máximo de solicitudes simultáneas configurado. ACT reduce de forma dinámica la simultaneidad en 1 en intervalos de 1 segundo cuando el uso de CPU supera el 90%. Para obtener más información, consulta Ajuste de simultaneidad adaptable (ACT).

Para cada revisión del servicio, puedes configurar la cantidad de CPU por instancia y la simultaneidad máxima.

Cloud Run no admite el escalamiento en función del uso de memoria.

De forma predeterminada, el escalamiento basado en métricas establece un umbral del 60% para el uso de CPU y los objetivos de simultaneidad de solicitudes. Puedes usar controles de escalamiento para especificar objetivos personalizados de CPU o simultaneidad.

Cuando Cloud Run escala según el uso de CPU, considera el uso promedio de CPU en todas las CPUs asignadas a una instancia. Si tu aplicación tiene un solo subproceso, pero se implementa en una instancia con varias CPU, esto puede generar una lectura de uso promedio baja, lo que podría afectar la forma en que se toman las decisiones de escalamiento basadas en la CPU. Para obtener más detalles sobre cómo optimizar la configuración de la CPU para la arquitectura de tu aplicación, consulta Configura límites de CPU y Establece solicitudes simultáneas máximas por instancia.

Escalamiento vertical

Cloud Run aumenta la cantidad de instancias según el controlador de escalamiento que requiera más instancias. Cuando hay pocos recuentos de instancias, el escalamiento basado en métricas responde de cerca a tus objetivos de uso.

El escalamiento basado en métricas mantiene el recuento de instancias actual mientras el uso se mantiene dentro de una tolerancia del 10% de tu objetivo, en relación con el objetivo. Por ejemplo, con el objetivo predeterminado del 60%, el recuento de instancias no cambia mientras el uso se mantiene entre el 54% y el 66%.

Cuando el uso se sale de ese rango, el escalamiento basado en métricas vuelve a calcular el recuento de instancias a partir del uso medido y tu objetivo, no de la cantidad de instancias en ejecución, y redondea el resultado a la siguiente instancia completa. Debido a este redondeo, tu servicio puede escalar verticalmente mientras el uso aún está por debajo de tu objetivo. Por ejemplo, un servicio que necesita 4.1 instancias para cumplir con el objetivo ejecuta 5 instancias.

Reducción de escala

El ajuste de escala automático de Cloud Run reduce la cantidad de instancias en ejecución cuando ya no son necesarias para entregar el tráfico entrante. El escalamiento basado en métricas ajusta de forma continua la cantidad de instancias que recomienda según el uso. Cloud Run reduce la cantidad de instancias recomendada solo cuando el uso disminuye más del 10% por debajo del objetivo y, luego, usa el mismo cálculo redondeado para determinar la cantidad nueva.

Cuando el uso promedio de CPU o las solicitudes activas promedio disminuyen, el algoritmo de escalamiento reduce la cantidad recomendada de instancias. El balanceador de cargas de solicitudes de Cloud Run considera estas recomendaciones y enruta de forma preferencial las solicitudes entrantes a las instancias recomendadas primero. Esto mantiene más ocupadas las instancias recomendadas y permite que otras instancias queden inactivas. Cloud Run reduce el recuento de estas instancias no recomendadas, ya que les quita prioridad para que solo reciban tráfico si todas las instancias recomendadas están ocupadas. Para mantener la estabilidad, Cloud Run cierra las instancias con prioridad baja en el siguiente orden:

  1. Cloud Run cierra un grupo de instancias cuando su uso durante un período de 1 minuto es inferior al 10%.
  2. Un segundo grupo de instancias permanece en ejecución hasta que se produce un tiempo de espera de inactividad de 15 minutos, lo que garantiza que haya capacidad disponible en caso de un aumento repentino del tráfico.

Si tu servicio realiza otras tareas incluso cuando no procesa solicitudes, como ejecutar subprocesos en segundo plano o procesar tareas asíncronas, debes establecer las instancias mínimas en 1, como mínimo, para garantizar que la CPU permanezca asignada al procesamiento en segundo plano.

Escalamiento a pedido

Cloud Run usa el escalamiento on demand cuando no puede encontrar una instancia disponible para entregar la solicitud entrante. El ajuste de escala on demand responde en tiempo real a los cambios en el tráfico entrante en una revisión de Cloud Run o a los cambios en la latencia de la revisión. Este escalamiento intenta garantizar que cada solicitud entrante se enrute a una instancia en un período breve. El escalamiento on demand es el único factor que impulsa el escalamiento desde cero. Sin embargo, cuando se escala desde N instancias, el escalamiento basado en métricas o a pedido controla el tráfico, según cuál se active primero.

Dado que el escalamiento a pedido responde en tiempo real a los cambios repentinos en el tráfico, Cloud Run administra el equilibrio entre la latencia de inicio en frío (el tiempo para iniciar una instancia nueva) y la latencia de la cola pendiente (el tiempo que espera una solicitud para que se abra un espacio en una instancia existente). Para cada solicitud, el sistema determina si es más rápido poner en cola una instancia futura o una existente (en ese orden) antes de intentar iniciar una nueva instancia bajo demanda. Una solicitud permanece en la cola pendiente durante un máximo de 10 segundos o 3.5 veces el tiempo previsto de inicio en frío (lo que sea mayor) antes de que el sistema active una nueva instancia bajo demanda.

Ajuste de simultaneidad adaptable (ACT)

Cloud Run usa el ajuste de simultaneidad adaptable (ACT) para evitar que la limitación de CPU provoque una latencia de solicitud alta. Este enfoque mide el uso de CPU de cada instancia en una cantidad determinada de solicitudes y ajusta el valor máximo de solicitudes simultáneas de la instancia de forma dinámica para mantener el uso de CPU por debajo del 90%. ACT ajusta la simultaneidad según las siguientes situaciones:

  • Cada vez que el uso de CPU durante el último segundo supera el 90%, ACT reduce en 1 la cantidad máxima de solicitudes simultáneas de la instancia.

  • Si la instancia alcanza su límite máximo de solicitudes simultáneas y el uso de CPU se mantiene por debajo del 70% durante 1 segundo, ACT aumenta en 1 el máximo de solicitudes simultáneas para la instancia.

  • Si tus métricas de escalamiento muestran que la simultaneidad nunca alcanza el máximo configurado, es posible que se deba a que ACT redujo de forma dinámica el máximo real para proteger el rendimiento de la instancia.

Cloud Run calcula los valores de ACT para cada implementación. Estas métricas no persisten en las implementaciones. Si ACT reduce la simultaneidad por debajo del nivel preferido, aumenta la CPU asignada por solicitud simultánea máxima. Las tareas en segundo plano que causan aumentos repentinos periódicos de la CPU también pueden interferir en este enfoque de escalamiento.

Puedes supervisar cuándo ACT controla activamente el ajuste de escala automático consultando el campo scaling_driver en la consola de Google Cloud . Para obtener detalles sobre cómo ver esta métrica, consulta Configura controles de escalamiento personalizados para los servicios.

Facturación y ajuste de escala automático basados en instancias

Si configuras la facturación basada en instancias para tu servicio de Cloud Run, debes tener en cuenta el comportamiento del escalamiento a cero y desde cero.

Escalamiento desde cero. Solo una solicitud puede activar el escalamiento desde cero, por lo que un servicio que no procesa solicitudes no puede escalar desde cero. Para estas cargas de trabajo, puedes establecer instancias mínimas > 0 o incluir una “solicitud de activación” en el diseño a fin de reiniciar el procesamiento después de reducir la escala a cero.

Reducción de escala a cero Dado que ninguna instancia tiene un 0% de CPU, si se observa todo el uso de CPU, nunca se escalaría a cero. Esto significa que la decisión de escalar de uno a cero solo se puede tomar si se verifica que la instancia está procesando una solicitud.

Acerca de la cantidad máxima de instancias para los servicios

En algunos casos, se recomienda limitar la cantidad total de instancias que se pueden iniciar, por motivos de control de costos o para obtener una mejor compatibilidad con otros recursos que usa el servicio. Por ejemplo, el servicio de Cloud Run puede interactuar con una base de datos que solo puede manejar una cantidad determinada de conexiones abiertas simultáneas.

A todos los servicios se les asigna un límite máximo de instancias de forma predeterminada, incluso si no especificas tu propio límite. Establece y supervisa este límite para determinar el comportamiento de escalamiento y los costos asociados con tu servicio. Para obtener más información, consulta Límites de instancias máximas.

Puedes usar la configuración de un máximo de instancias para limitar la cantidad total de instancias que se pueden iniciar en paralelo, como se indica en Configura una cantidad máxima de instancias.

Consumo superior a la cantidad máxima de instancias

En circunstancias normales, la revisión se escala horizontalmente mediante la creación de instancias nuevas para controlar la carga de tráfico entrante. Sin embargo, cuando estableces un límite máximo de instancias, en algunas situaciones, no habrá suficientes instancias para poder manejar esa carga de tráfico. En ese caso, las solicitudes entrantes se ponen en cola (pendientes) de la siguiente manera:

Las solicitudes permanecerán pendientes hasta 3.5 veces el tiempo de inicio promedio de las instancias de contenedor de este servicio o 10 segundos, lo que sea mayor.

Durante este período, si una instancia termina de procesar solicitudes, estará disponible para procesar las solicitudes pendientes en cola. Si no hay instancias disponibles durante el período, la solicitud falla con un código de error 429.

Garantías de escalamiento

El límite máximo de instancias es un límite superior por revisión y significa que la cantidad de instancias para esta revisión no debe exceder el máximo.

En circunstancias normales, Cloud Run puede escalar horizontalmente hasta el límite máximo de instancias muy rápido para controlar todas las solicitudes o los eventos entrantes. Sin embargo, establecer un límite alto no significa que la revisión podrá escalar horizontalmente hasta la cantidad especificada de instancias en un momento determinado. En circunstancias excepcionales, Cloud Run puede limitar el escalamiento para garantizar un buen servicio para todos los clientes.

Se excedió la cantidad máxima de instancias debido a los aumentos repentinos de tráfico

En algunos casos, como picos de tráfico rápidos o mantenimiento del sistema, Cloud Run podría crear, durante un período breve, más instancias de las que se especifican en la configuración de instancias máximas. Las instancias nuevas se pueden iniciar en exceso de la configuración de instancias máximas para reemplazar las instancias existentes y proporcionar un período de gracia para que las solicitudes en tránsito terminen de procesarse.

El límite máximo de instancias se puede superar en las operaciones normales algunas veces a la semana. Por lo general, el período de gracia dura hasta 15 minutos o hasta el valor especificado en la configuración de tiempo de espera de la solicitud. Estas instancias adicionales se destruyen en un plazo de 15 minutos después de que quedan inactivas.

Si se necesitan muchos reemplazos, las actualizaciones suelen distribuirse durante muchos minutos o incluso horas, pero cada reemplazo tiene un exceso de instancia solo durante el período de gracia. Las instancias que excedan el valor máximo de instancia suelen ser menos del doble del límite máximo de instancias configuradas, pero pueden ser mucho más grandes para los aumentos de tráfico repentinos.

Las pruebas de carga experimentan más instancias que exceden la configuración máxima porque el sistema puede cambiar dónde se entregan los picos de tráfico para conservar la capacidad de las cargas de trabajo existentes que tienen patrones de carga sostenidos.

Si tu servicio no puede tolerar este comportamiento temporal, se recomienda incluir un margen de seguridad y reducir la cantidad de instancias máximas permitidas.

Divisiones de tráfico

Debido a que el límite máximo de instancias es un límite para cada revisión, si el servicio divide el tráfico entre varias revisiones, la cantidad total de instancias del servicio puede exceder la cantidad máxima de instancias. por revisión. Esto se puede observar en las métricas de recuento de instancias.

Implementaciones

Cuando implementas una revisión nueva para entregar el 100% del tráfico, Cloud Run inicia suficientes instancias de la revisión nueva antes de dirigir el tráfico a ella. Esto reduce el impacto de las implementaciones de revisión nuevas en las latencias de solicitud, en especial cuando se entregan niveles altos de tráfico. Debido a que el límite máximo de instancias es un límite para cada revisión, durante una implementación, la cantidad total de instancias del servicio puede exceder el máximo de instancias por revisión. Esto se puede observar en las métricas de recuento de instancias.

Instancias inactivas y minimización de inicios en frío

Para minimizar los inicios en frío, Cloud Run podría mantener las instancias inactivas durante un período después de que terminen de controlar las solicitudes (hasta 15 minutos o 10 minutos para las GPUs).

Una instancia inactiva puede conservar recursos, como conexiones de bases de datos abiertas. Ten en cuenta que el parámetro de configuración de facturación predeterminado es la facturación basada en solicitudes, a menos que configures de forma explícita tu servicio para que tenga facturación basada en instancias.

Para mantener las instancias inactivas de forma permanente, usa la configuración min-instance. Ten en cuenta que usar esta función generará costos incluso cuando el servicio no entregue solicitudes de forma activa.

Ajuste de escala automático y solicitudes pendientes

Las solicitudes permanecerán pendientes hasta 3.5 veces el tiempo de inicio promedio de las instancias de contenedor de este servicio o 10 segundos, lo que sea mayor.

Impacto del ajuste de escala automático en los servicios de respaldo

A medida que la cantidad de instancias aumenta de automáticamente, tu servicio de Cloud Run puede encontrar límites con sus servicios de respaldo. Por ejemplo, Cloud SQL tiene un límite de cuota de la API. Asegúrate de que estos servicios de respaldo tengan suficiente cuota y puedan manejar conexiones desde todas las instancias de tu servicio de Cloud Run. Considera configurar una cantidad máxima de instancias para evitar sobrecargar los servicios de respaldo.

Ajuste de escala automático y Pub/Sub

Google recomienda usar suscripciones de envío para consumir mensajes de un tema de Pub/Sub en Cloud Run. El contenedor recibe mensajes enviados, como solicitudes HTTP, lo que activa el mismo comportamiento de ajuste de escala automático.

Ajuste de escala automático y varios contenedores (sidecars)

Cloud Run considera el uso de CPU de las instancias para el ajuste de escala automático, en el que el uso de CPU de una instancia es el porcentaje de CPU asignada en uso.

Ten en cuenta que asignas CPU cuando estableces límites de CPU a nivel del contenedor. Si usas varios contenedores por instancia, la asignación de CPU real para esa instancia es la suma de los límites de CPU que estableciste en cada contenedor.

¿Qué sigue?