Comprender el escalado de la función de Lambda

La simultaneidad representa la cantidad de solicitudes que la función AWS Lambda‎ puede tolerar al mismo tiempo. Para cada solicitud simultánea, Lambda aprovisiona una instancia independiente del entorno de ejecución. A medida que las funciones reciben más solicitudes, Lambda se encarga automáticamente de escalar la cantidad de entornos de ejecución hasta que alcance el límite de simultaneidad de la cuenta. De forma predeterminada, Lambda proporciona a su cuenta un límite de simultaneidad total de 1000 ejecuciones simultáneas en todas las funciones de una Región de AWS. Para satisfacer las necesidades específicas de la cuenta, puede solicitar un aumento de la cuota y configurar los controles de simultaneidad en la función para que las funciones críticas no sufran limitaciones.

En este tema se explican los conceptos de simultaneidad y el escalado de funciones en Lambda. Al final de este tema, podrá entender cómo calcular la simultaneidad, visualizar las dos opciones principales de control de simultaneidad (reservadas y aprovisionadas), estimar la configuración de control de simultaneidad adecuada y ver las métricas para una mayor optimización.

Secciones

• Cómo comprender y visualizar la simultaneidad
• Calcular la simultaneidad de una función
• Comprender la simultaneidad reservada y simultaneidad aprovisionada
• Descripción de la simultaneidad y las solicitudes por segundo
• Cuotas de simultaneidad
• Configurar la simultaneidad reservada para una función
• Configuración de simultaneidad aprovisionada para una función
• Comportamiento de escalado de Lambda
• Monitoreo de la simultaneidad

Cómo comprender y visualizar la simultaneidad

Lambda invoca la función en un entorno de ejecución seguro y aislado. Para administrar una solicitud, Lambda debe inicializar primero un entorno de ejecución (la fase de inicio), antes de usarlo para invocar la función (la fase de invocación):

nota

Las duraciones reales de inicio e invocación pueden variar en función de muchos factores, como el tiempo de ejecución que elija y el código de la función de Lambda. El diagrama anterior no pretende representar las proporciones exactas de las duraciones de las fases de inicio e invocación.

El diagrama anterior utiliza un rectángulo para representar un único entorno de ejecución. Cuando la función recibe la primera solicitud (representada por un círculo amarillo con la etiqueta 1), Lambda crea un nuevo entorno de ejecución y ejecuta el código fuera del controlador principal durante la fase de inicio. A continuación, Lambda ejecuta el código del controlador principal de la función durante la fase de invocación. Durante todo este proceso, este entorno de ejecución está ocupado y no puede procesar otras solicitudes.

Cuando Lambda termina de procesar la primera solicitud, este entorno de ejecución puede procesar solicitudes adicionales para la misma función. Para las solicitudes posteriores, Lambda no necesita volver a inicializar el entorno.

En el diagrama anterior, Lambda reutiliza el entorno de ejecución para administrar la segunda solicitud (representada por el círculo amarillo con la etiqueta 2).

Hasta ahora, nos hemos centrado en una sola instancia del entorno de ejecución (es decir, una simultaneidad de 1). En la práctica, es posible que Lambda necesite aprovisionar varias instancias del entorno de ejecución en paralelo para administrar todas las solicitudes entrantes. Cuando la función recibe una nueva solicitud, puede ocurrir una de estas dos cosas:

• Si una instancia de entorno de ejecución preinicializada está disponible, Lambda la utiliza para procesar la solicitud.

• De lo contrario, Lambda crea una nueva instancia del entorno de ejecución para procesar la solicitud.

Por ejemplo, analicemos lo que ocurre cuando la función recibe 10 solicitudes:

En el diagrama anterior, cada plano horizontal representa una única instancia del entorno de ejecución (etiquetada de la A a F). Así es como Lambda administra cada solicitud:

Solicitud	Comportamiento de Lambda	Razonamiento
1	Aprovisiona el nuevo entorno A.	Esta es la primera solicitud; no hay instancias de entorno de ejecución disponibles.
2	Aprovisiona el nuevo entorno B.	La instancia A del entorno de ejecución existente está ocupada.
3	Aprovisiona el nuevo entorno C.	Las instancias A y B del entorno de ejecución existentes están ocupadas.
4	Aprovisiona el nuevo entorno D.	Las instancias A, B y C del entorno de ejecución existentes están todas ocupadas.
5	Aprovisiona el nuevo entorno E.	Las instancias A, B, C y D del entorno de ejecución existentes están todas ocupadas.
6	Reutiliza el entorno A.	La instancia A del entorno de ejecución terminó de procesar la solicitud 1 y ya está disponible.
7	Reutiliza el entorno B.	La instancia B del entorno de ejecución terminó de procesar la solicitud 2 y ya está disponible.
8	Reutiliza el entorno C.	La instancia C del entorno de ejecución terminó de procesar la solicitud 3 y ya está disponible.
9	Aprovisiona el nuevo entorno F.	Las instancias A, B, C, D y E del entorno de ejecución existentes están todas ocupadas.
10	Reutiliza el entorno D.	La instancia D del entorno de ejecución terminó de procesar la solicitud 4 y ya está disponible.

Como respuesta, a medida que la función recibe más solicitudes simultáneas, Lambda escala verticalmente la cantidad de instancias del entorno de ejecución. La siguiente animación registra la cantidad de solicitudes simultáneas a lo largo del tiempo:

Cuando se congela la animación anterior en seis puntos distintos en el tiempo, se obtiene el siguiente diagrama:

En el diagrama anterior, podemos dibujar una línea vertical en cualquier momento y contar la cantidad de entornos que se cruzan con esta línea. Esto nos da la cantidad de solicitudes simultáneas en ese momento. Por ejemplo, en el momento t1, existen tres entornos activos que atienden tres solicitudes simultáneas. La cantidad máxima de solicitudes simultáneas de esta simulación se produce en el momento t4, cuando hay seis entornos activos que atienden seis solicitudes simultáneas.

En resumen, la simultaneidad de la función es la cantidad de solicitudes simultáneas que se administran a la vez. En respuesta a un aumento en la simultaneidad de la función, Lambda aprovisiona más instancias del entorno de ejecución para satisfacer la demanda de solicitudes.

Calcular la simultaneidad de una función

En general, la simultaneidad de un sistema es la capacidad de procesar más de una tarea simultáneamente. En Lambda, la simultaneidad es la cantidad de solicitudes en vuelo que la función administra al mismo tiempo. Una forma rápida y práctica de medir la simultaneidad de una función de Lambda consiste en utilizar la siguiente fórmula:

Concurrency = (average requests per second) * (average request duration in seconds)

La simultaneidad se diferencia de las solicitudes por segundo. Por ejemplo, supongamos que la función recibe una media de 100 solicitudes por segundo. Si la duración media de las solicitudes es de un segundo, es cierto que la simultaneidad también es de 100:

Concurrency = (100 requests/second) * (1 second/request) = 100

Sin embargo, si la duración media de la solicitud es de 500 ms, entonces la simultaneidad es de 50:

Concurrency = (100 requests/second) * (0.5 second/request) = 50

¿Qué significa en la práctica una simultaneidad de 50? Si la duración media de las solicitudes es de 500 ms, entonces puede pensar que una instancia de la función puede administrar dos solicitudes por segundo. Luego, se necesitan 50 instancias de la función para administrar una carga de 100 solicitudes por segundo. Una simultaneidad de 50 significa que Lambda debe aprovisionar 50 instancias del entorno de ejecución para administrar esta carga de trabajo de manera eficiente sin ningún tipo de limitación. A continuación, se explica cómo expresar esto en forma de ecuación:

Concurrency = (100 requests/second) / (2 requests/second) = 50

Si la función recibe el doble de solicitudes (200 solicitudes por segundo), pero solo necesita la mitad del tiempo para procesar cada solicitud (250 ms), entonces la simultaneidad sigue siendo de 50:

Concurrency = (200 requests/second) * (0.25 second/request) = 50

Evaluemos su comprensión de la simultaneidad

Supongamos que tiene una función que tarda, en promedio, 200 ms en ejecutarse. Durante la carga máxima, nota que hay 5000 solicitudes por segundo. ¿Cuál es la simultaneidad de la función durante la carga máxima?

Respuesta

La duración promedio de la función es de 200 ms o 0,2 segundos. Con la fórmula de simultaneidad, puede introducir los números para obtener una simultaneidad de 1000:

Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000

Como alternativa, una duración promedio de una función de 200 ms significa que la función puede procesar 5 solicitudes por segundo. Para administrar la carga de trabajo de 5000 solicitudes por segundo, necesita 1000 instancias de entorno de ejecución. Por lo tanto, la simultaneidad es de 1000:

Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000

Comprender la simultaneidad reservada y simultaneidad aprovisionada

De forma predeterminada, la cuenta tiene un límite de simultaneidad de 1000 ejecuciones simultáneas en todas las funciones de una región. Las funciones comparten este conjunto de 1000 simultaneidades bajo demanda. Si se agota la simultaneidad disponible, la función experimenta limitaciones (es decir, empieza a eliminar solicitudes).

Es posible que algunas de las funciones sean más importantes que otras. Como resultado, es posible que desee configurar los ajustes de simultaneidad para garantizar que las funciones críticas obtengan la simultaneidad que necesitan. Existen dos tipos de controles de simultaneidad disponibles: simultaneidad reservada y simultaneidad aprovisionada.

• Utilice la simultaneidad reservada para reservar una parte de la simultaneidad de la cuenta para una función. Esto resulta útil si no desea que otras funciones ocupen toda la simultaneidad no reservada disponible.

• Utilice la simultaneidad aprovisionada para preinicializar varias instancias de entorno para una función. Esto es útil para reducir las latencias de arranque en frío.

Simultaneidad reservada

Si desea garantizar que haya una cierta cantidad de simultaneidad disponible para la función en cualquier momento, utilice la simultaneidad reservada.

La simultaneidad reservada es la cantidad máxima de instancias simultáneas que desea asignar a la función. Cuando dedica la simultaneidad reservada a una función, ninguna otra función puede usarla. En otras palabras, la configuración de la simultaneidad reservada puede afectar al grupo de simultaneidad que está disponible para otras funciones. Las funciones que no tienen simultaneidad reservada comparten el conjunto restante de simultaneidad no reservada.

La configuración de la simultaneidad reservada cuenta para el límite general de simultaneidad de la cuenta. No hay ningún cargo por configurar la concurrencia reservada para una función.

Para entender mejor la simultaneidad reservada, tenga en cuenta el siguiente diagrama:

En este diagrama, el límite de simultaneidad de la cuenta para todas las funciones de esta región está en el límite predeterminado de 1000. Supongamos que tiene dos funciones críticas, la function-blue y la function-orange, que de forma rutinaria se espera que obtengan altos volúmenes de invocación. Decide asignar 400 unidades de simultaneidad reservada a la function-blue y 400 unidades de simultaneidad reservada a la function-orange. En este ejemplo, todas las demás funciones de la cuenta deben compartir las 200 unidades restantes de simultaneidad no reservada.

El diagrama tiene cinco puntos de interés:

• En el momento t1, tanto la function-orange como la function-blue comienzan a recibir solicitudes. Cada función comienza a utilizar su parte asignada de las unidades de simultaneidad reservadas.

• En el momento t2, la function-orange y la function-blue reciben cada vez más solicitudes. Al mismo tiempo, implementa otras funciones de Lambda, que comienzan a recibir solicitudes. No asigna la simultaneidad reservada a estas otras funciones. Estas empiezan a utilizar las 200 unidades restantes de simultaneidad no reservada.

• En el momento t3, la function-orange alcanza la simultaneidad máxima de 400. Aunque hay simultaneidad no utilizada en otras partes de la cuenta, la function-orange no puede acceder a esta. La línea roja indica que la function-orange se está sufriendo limitaciones y Lambda podría anular las solicitudes.

• En el momento t4, la function-orange comienza a recibir menos solicitudes y ya no tiene limitaciones. Sin embargo, las otras funciones experimentan un aumento en el tráfico y comienzan a sufrir limitaciones. Si bien hay simultaneidad no utilizada en otras partes de la cuenta, estas otras funciones no pueden acceder a esta. La línea roja indica que las demás funciones están sufriendo limitaciones.

• En el momento t5, otras funciones comienzan a recibir menos solicitudes y ya no experimentan limitaciones.

En este ejemplo, observe que reservar la simultaneidad tiene los siguientes efectos:

• La función se puede escalar independientemente de otras funciones de la cuenta. Todas las funciones de la cuenta en la misma región que no tienen simultaneidad reservada comparten el grupo de simultaneidad no reservada. Sin simultaneidad reservada, otras funciones pueden llegar a utilizar toda la simultaneidad disponible. Esto impide que las funciones críticas se escalen verticalmente cuando sea necesario.

• La función no se puede escalar horizontalmente de forma descontrolada. La simultaneidad reservada limita a la simultaneidad máxima de la función. Esto significa que la función no puede usar la simultaneidad reservada para otras funciones ni la simultaneidad del grupo no reservado. Puede reservar simultaneidad para evitar que la función utilice toda la simultaneidad disponible en la cuenta o que sobrecargue los recursos empleados posteriormente.

• Es posible que no pueda utilizar toda la simultaneidad disponible en la cuenta. Reservar la simultaneidad cuenta para el límite de simultaneidad de la cuenta, pero esto también significa que otras funciones no pueden usar esa parte de la simultaneidad reservada. Si la función no consume toda la simultaneidad que reserva para esta, efectivamente está desperdiciando esa simultaneidad. Esto no es un problema, a menos que otras funciones de la cuenta puedan aprovechar la simultaneidad desperdiciada.

Para saber cómo administrar la configuración de la simultaneidad reservada para las funciones, consulte Configurar la simultaneidad reservada para una función.

Simultaneidad aprovisionada

La simultaneidad reservada se utiliza para definir la cantidad máxima de entornos de ejecución reservados para una función de Lambda. Sin embargo, ninguno de estos entornos viene preinicializado. Como resultado, las invocaciones de la función pueden tardar más porque Lambda primero debe inicializar el nuevo entorno antes de poder usarlo para invocar la función. Cuando Lambda tiene que inicializar un nuevo entorno para llevar a cabo una invocación, esto se denomina arranque en frío. Para mitigar los arranques en frío, puede utilizar la simultaneidad aprovisionada.

La simultaneidad aprovisionada es la cantidad de entornos de ejecución preinicializados que desea asignar a la función. Si se establece la simultaneidad aprovisionada en una función, Lambda inicializa esa cantidad de entornos de ejecución para que estén preparados para responder a las solicitudes de la función.

nota

Utilizar la simultaneidad aprovisionada genera cargos en su cuenta. Si trabaja con los entornos de ejecución de Java 11 o Java 17, también puede utilizar Lambda SnapStart para mitigar los problemas de arranque en frío sin costo adicional. SnapStart utiliza instantáneas almacenadas en caché de su entorno de ejecución para mejorar de forma significativa el rendimiento de inicio. No puede utilizar SnapStart y la simultaneidad aprovisionada en la misma versión de la función. Para obtener más información sobre las características, las limitaciones y las regiones admitidas de SnapStart, consulte Mejora del rendimiento de inicio con Lambda SnapStart.

Cuando se utiliza la simultaneidad aprovisionada, Lambda sigue reciclando los entornos de ejecución en segundo plano. Sin embargo, Lambda se asegura, en todos los casos y en cualquier momento, de que la cantidad de entornos preinicializados sea igual al valor de la configuración de simultaneidad aprovisionada por la función. Este comportamiento difiere de la simultaneidad reservada, en la que Lambda puede terminar por completo un entorno tras un periodo de inactividad. En el siguiente diagrama se demuestra esto, comparando el ciclo de vida de un único entorno de ejecución cuando se configura la función mediante la simultaneidad reservada, en contraposición a la simultaneidad aprovisionada.

El diagrama tiene cuatro puntos de interés:

Tiempo	Simultaneidad reservada	Simultaneidad aprovisionada
t1	No ocurre nada.	Lambda preinicializa una instancia del entorno de ejecución.
t2	Se presenta la solicitud 1. Lambda debe inicializar una nueva instancia del entorno de ejecución.	Se presenta la solicitud 1. Lambda utiliza la instancia de entorno preinicializada.
t3	Tras un tiempo de inactividad, Lambda termina la instancia del entorno activo.	No ocurre nada.
t4	Se presenta la solicitud 2. Lambda debe inicializar una nueva instancia del entorno de ejecución.	Se presenta la solicitud 2. Lambda utiliza la instancia de entorno preinicializada.

Para comprender mejor la simultaneidad aprovisionada, tenga en cuenta el siguiente diagrama:

En este diagrama, tiene un límite de simultaneidad de cuentas de 1000. Decide otorgar 400 unidades de simultaneidad aprovisionadas a la function-orange. Todas las funciones de la cuenta, incluida la function-orange, pueden usar las 600 unidades restantes de simultaneidad no reservadas.

El diagrama tiene cinco puntos de interés:

• En el momento t1, la function-orange comienza a recibir solicitudes. Dado que Lambda ha preinicializado 400 instancias del entorno de ejecución, la function-orange está lista para la invocación inmediata.

• En el momento t2, la function-orange alcanza las 400 solicitudes simultáneas. Como resultado, la function-orange agota la simultaneidad aprovisionada. Sin embargo, dado que todavía hay simultaneidad no reservada disponible, Lambda puede usarla para administrar solicitudes adicionales a la function-orange (sin limitaciones). Lambda debe crear nuevas instancias para atender estas solicitudes, y es posible que la función experimente latencias de arranque en frío.

• En el momento t3, la function-orange vuelve a las 400 solicitudes simultáneas tras un breve aumento en el tráfico. Nuevamente, Lambda puede administrar todas las solicitudes sin latencias de arranque en frío.

• En el momento t4, las funciones de la cuenta experimentan una ráfaga de tráfico. Esta ráfaga puede provenir de la function-orange o de cualquier otra función de la cuenta. Lambda utiliza la simultaneidad no reservada para administrar estas solicitudes.

• En el momento t5, las funciones de la cuenta alcanzan el límite máximo de simultaneidad de 1000 y experimentan limitaciones.

En el ejemplo anterior se consideró solo la simultaneidad aprovisionada. En la práctica, puede configurar tanto la simultaneidad aprovisionada como la reservada en una función. Podría hacerlo si tuviera una función que gestione una carga constante de invocaciones durante los días de la semana, pero que detecte picos de tráfico de forma rutinaria durante los fines de semana. En este caso, puede utilizar la simultaneidad aprovisionada para establecer una cantidad básica de entornos para administrar las solicitudes durante los días de semana y utilizar la simultaneidad reservada para administrar los picos de los fines de semana. Tenga en cuenta el siguiente diagrama:

En este diagrama, imagine que configura 200 unidades de simultaneidad aprovisionadas y 400 unidades de simultaneidad reservadas para la function-orange. Como configuró la simultaneidad reservada, la function-orange no puede usar ninguna de las 600 unidades de simultaneidad no reservadas.

Este diagrama tiene cinco puntos de interés:

• En el momento t1, la function-orange comienza a recibir solicitudes. Dado que Lambda ha preinicializado 200 instancias del entorno de ejecución, la function-orange está lista para la invocación inmediata.

• En el momento t2, la function-orange utiliza toda su simultaneidad aprovisionada. La function-orange puede seguir atendiendo solicitudes mediante la simultaneidad reservada, pero estas solicitudes pueden experimentar latencias de arranque en frío.

• En el momento t3, la function-orange alcanza las 400 solicitudes simultáneas. Como resultado, la function-orange agota toda su simultaneidad reservada. Como la function-orange no puede utilizar la simultaneidad no reservada, las solicitudes comienzan a sufrir limitaciones.

• En el momento t4, la function-orange comienza a recibir menos solicitudes y ya no experimenta limitaciones.

• En el momento t5, la function-orange se reduce a 200 solicitudes simultáneas, por lo que todas las solicitudes pueden volver a utilizar la simultaneidad aprovisionada (es decir, sin latencias de arranque en frío).

Tanto la simultaneidad reservada como la aprovisionada se tienen en cuenta para el límite de simultaneidad de la cuenta y las cuotas regionales. En otras palabras, la simultaneidad reservada y aprovisionada puede afectar al grupo de simultaneidad que está disponible para otras funciones. La configuración de la simultaneidad aprovisionada genera cargos para su Cuenta de AWS.

nota

Si el volumen de simultaneidad aprovisionada en las versiones y alias de una función se suma a la simultaneidad reservada de la función, entonces todas las invocaciones se ejecutan en la simultaneidad aprovisionada. Esta configuración también tiene el efecto de aplicar una limitación controlada a la versión sin publicar de la función ($LATEST), lo que impide que se ejecute. No puede asignar más concurrencia aprovisionada que la concurrencia reservada para una función.

Para administrar la configuración de la simultaneidad aprovisionada para las funciones, consulte Configuración de simultaneidad aprovisionada para una función. Para automatizar el escalado de simultaneidad aprovisionada en función de un cronograma o la utilización de la aplicación, consulte Uso de Application Auto Scaling para automatizar la administración de simultaneidad aprovisionada.

Cómo asigna Lambda la simultaneidad aprovisionada

La simultaneidad aprovisionada no se pone en línea inmediatamente después de configurarla. Lambda comienza a asignar simultaneidad aprovisionada después de uno o dos minutos de preparación. Para cada función, Lambda puede aprovisionar hasta 6000 entornos de ejecución por minuto, independientemente de su Región de AWS. Es exactamente igual a la tasa de escalado de simultaneidad de las funciones.

Cuando envíe una solicitud para asignar la simultaneidad aprovisionada, no podrá acceder a ninguno de esos entornos hasta que Lambda termine de asignarlos por completo. Por ejemplo, si solicita 5000 entornos de simultaneidad aprovisionada, ninguna de sus solicitudes puede utilizar la simultaneidad aprovisionada hasta que Lambda termine de asignar por completo los 5000 entornos de ejecución.

Comparación de la simultaneidad reservada con la aprovisionada

En la siguiente tabla se resumen y se comparan la simultaneidad reservada y la aprovisionada.

Tema	Simultaneidad reservada	Simultaneidad aprovisionada
Definición	Cantidad máxima de instancias del entorno de ejecución para la función.	Cantidad fija de instancias del entorno de ejecución preaprovisionadas para la función.
Comportamiento de aprovisionamiento	Lambda aprovisiona nuevas instancias bajo demanda.	Lambda aprovisiona previamente las instancias (es decir, antes de que la función comience a recibir solicitudes).
Comportamiento de arranque en frío	Es posible la latencia de arranque en frío, ya que Lambda debe crear nuevas instancias bajo demanda.	La latencia de arranque en frío no es posible, ya que Lambda no necesita crear instancias bajo demanda.
Comportamiento de las limitaciones	La función experimenta limitaciones cuando se alcanza el límite de simultaneidad reservado.	Si la simultaneidad reservada no está configurada, la función utiliza la simultaneidad no reservada cuando se alcanza el límite de simultaneidad aprovisionado. Si se establece la simultaneidad reservada, la función experimenta limitaciones cuando se alcanza el límite de simultaneidad reservado.
El comportamiento predeterminado no está configurado	La función utiliza la simultaneidad no reservada disponible en la cuenta.	Lambda no preaprovisiona ninguna instancia. En su lugar, si la simultaneidad reservada no está configurada, la función utiliza la simultaneidad no reservada disponible en la cuenta. Si se configura la simultaneidad reservada, la función usa la simultaneidad reservada.
Precios	Sin cargo adicional.	Conlleva cargos adicionales.

Descripción de la simultaneidad y las solicitudes por segundo

Como se mencionó en la sección anterior, la simultaneidad se diferencia de las solicitudes por segundo. Esta es una distinción importante cuando se trabaja con funciones que tienen una duración promedio de solicitud inferior a 100 ms.

En todas las funciones de su cuenta, Lambda aplica un límite de solicitudes por segundo igual a 10 veces la simultaneidad de la cuenta. Por ejemplo, dado que el límite predeterminado de simultaneidad de la cuenta es de 1000, las funciones de su cuenta pueden gestionar un máximo de 10 000 solicitudes por segundo.

Por ejemplo, considere una función con una duración promedio de solicitud de 50 ms. Con 20 000 solicitudes por segundo, la simultaneidad de esta función es la siguiente:

Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000

Según este resultado, se podría esperar que el límite de simultaneidad de la cuenta de 1000 sea suficiente para gestionar esta carga. Sin embargo, debido al límite de 10 000 solicitudes por segundo, la función solo puede gestionar 10 000 solicitudes por segundo del total de 20 000. Esta función experimenta una limitación.

La lección es que debe tener en cuenta tanto la simultaneidad como las solicitudes por segundo al configurar los ajustes de simultaneidad de las funciones. En este caso, debe solicitar un aumento del límite de simultaneidad de la cuenta a 2000, ya que esto aumentaría el límite total de solicitudes por segundo a 20 000.

nota

En función de este límite de solicitudes por segundo, es incorrecto decir que cada entorno de ejecución de Lambda solo puede gestionar un máximo de 10 solicitudes por segundo. En lugar de observar la carga en cualquier entorno de ejecución individual, Lambda solo tiene en cuenta la simultaneidad general y las solicitudes totales por segundo al momento de calcular las cuotas.

Ponga a prueba su comprensión de la simultaneidad (funciones de menos de 100 ms)

Supongamos que tiene una función que tarda, en promedio, 20 ms en ejecutarse. Durante la carga máxima, nota que hay 30 000 solicitudes por segundo. ¿Cuál es la simultaneidad de la función durante la carga máxima?

Respuesta

La duración promedio de la función es de 20 ms o 0,02 segundos. Con la fórmula de simultaneidad, puede introducir los números para obtener una simultaneidad de 600:

Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600

De forma predeterminada, el límite de simultaneidad de la cuenta de 1000 parece ser suficiente para gestionar esta carga. Sin embargo, el límite de 10 000 solicitudes por segundo no es suficiente para gestionar las 30 000 solicitudes entrantes por segundo. Para admitir por completo las 30 000 solicitudes, debe solicitar un aumento del límite de simultaneidad de la cuenta a 3000 o más.

El límite de solicitudes por segundo se aplica a todas las cuotas en Lambda que implican simultaneidad. En otras palabras, se aplica a las funciones sincrónicas bajo demanda, las funciones que utilizan la simultaneidad aprovisionada y al comportamiento de escalado de la simultaneidad. Por ejemplo, a continuación, se muestran algunos escenarios en los que debe considerar con detenimiento sus límites de simultaneidad y de solicitudes por segundo:

• Una función que utilice la simultaneidad bajo demanda puede experimentar un aumento de ráfaga de simultaneidad de 500 cada 10 segundos o de 5000 solicitudes por segundo cada 10 segundos, lo que ocurra primero.

• Supongamos que tiene una función que tiene una asignación de simultaneidad aprovisionada de 10. Esta función se extiende a la simultaneidad bajo demanda después de una simultaneidad de 10 o de 100 solicitudes por segundo, lo que ocurra primero.

Cuotas de simultaneidad

Lambda establece cuotas para la cantidad total de simultaneidad que puede utilizar en todas las funciones de una región. Estas cuotas existen en dos niveles:

• A nivel de cuenta, de forma predeterminada, las funciones pueden tener hasta 1000 unidades de simultaneidad. Para solicitar un aumento de cuota, consulte Solicitud de aumento de cuota en la Guía del usuario de Service Quotas.

• A nivel de función, de forma predeterminada, puede reservar hasta 900 unidades de simultaneidad en todas las funciones de forma predeterminada. Independientemente del límite total de simultaneidad de la cuenta, Lambda siempre reserva 100 unidades de simultaneidad para las funciones que no reserven explícitamente la simultaneidad. Por ejemplo, si aumentó el límite de simultaneidad de la cuenta a 2000, entonces puede reservar hasta 1900 unidades de simultaneidad a nivel de función.

• Tanto a nivel de la cuenta como de la función, Lambda también impone un límite de solicitudes por segundo igual a 10 veces la cuota de simultaneidad correspondiente. Por ejemplo, esto se aplica a la simultaneidad a nivel de la cuenta, a las funciones que utilizan la simultaneidad bajo demanda, a las funciones que utilizan la simultaneidad aprovisionada y al comportamiento de escalado de la simultaneidad. Para obtener más información, consulte Descripción de la simultaneidad y las solicitudes por segundo.

Para comprobar la cuota de simultaneidad actual a nivel de cuenta, utilice la AWS Command Line Interface (AWS CLI) para ejecutar el siguiente comando:

aws lambda get-account-settings

Debería ver una salida con un aspecto similar al siguiente:

{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 410759889,
        "FunctionCount": 8
    }
}

ConcurrentExecutions es la cuota total de simultaneidad a nivel de cuenta. UnreservedConcurrentExecutions es la cantidad de simultaneidad reservada que aún puede asignar a sus funciones.

A medida que una función recibe más solicitudes, Lambda escala de forma automática la cantidad de entornos de ejecución para gestionar estas solicitudes hasta que su cuenta alcance la cuota de simultaneidad. Sin embargo, para protegerse contra el exceso de escalado en respuesta a ráfagas repentinas de tráfico, Lambda limita la rapidez con la que sus funciones pueden escalar. Esta tasa de escalado de simultaneidad es la tasa máxima a la que las funciones de su cuenta pueden escalar en respuesta a un aumento de las solicitudes. (Es decir, la rapidez con la que Lambda puede crear nuevos entornos de ejecución). La tasa de escalado de simultaneidad difiere del límite de simultaneidad de la cuenta, que es la cantidad total de simultaneidad disponible para sus funciones.

En cada Región de AWS y para cada función, su tasa de escalado de simultaneidad es de 1000 instancias del entorno de ejecución cada 10 segundos (o 10 000 solicitudes por segundo cada 10 segundos). En otras palabras, cada 10 segundos, Lambda puede asignar como máximo 1000 instancias de entorno de ejecución adicionales o admitir 10 000 solicitudes por segundo adicionales a cada una de sus funciones.

Por lo general, no debe preocuparse por esta limitación. La tasa de escalado de Lambda es suficiente para la mayoría de los casos de uso.

Es importante destacar que la tasa de escalado de simultaneidad es un límite de función. Esto significa que cada función de su cuenta puede escalar independientemente de otras funciones.

Para obtener más información acerca de comportamientos de escalado, consulte Comportamiento de escalado de Lambda.