Blog de Amazon Web Services (AWS)
Uso de las nuevas funciones Serverless: API HTTP de API Gateway, simultaneidad aprovisionada de Lambda, proxy de Amazon RDS, flujos de trabajo de Step Functions Express y Amazon EventBridge
Por Luiz Yanai, Arquitecto de Soluciones y Especialista sin Servidor, AWS Brasil
Recientemente, se han lanzado diferentes características dentro del espectro de los servicios sin servidor ( Serverless, en inles) para hacer que las soluciones basadas en dicha tecnología sean aún más escalables.
Esta entrada de blog presenta un escenario de ejemplo que demuestra el uso de cada una de las nuevas características para solucionar problemas de escalabilidad, por ejemplo, en una aplicación web o móvil.
Imaginando un escenario donde tenemos una aplicación disponible tanto a través de web como móvil y que tenga un gran volumen de usuarios, que dependiendo de la escala de accesos podemos caer en alguna limitación de recursos o también en aumento del costo de la solución. Específicamente sobre el problema del gasto inesperado en soluciones sin servidor, se recomienda leer esta publicación.
Nuevas características sin servidor
A continuación se muestra una lista de las nuevas características publicadas en los últimos meses:
- API HTTP de Amazon API Gateway: Para crear API RESTful, puede utilizar API HTTP o API REST de Amazon API Gateway. Las API HTTP son hasta un 71% más rentables que las API REST, pero solo ofrecen funcionalidad de proxy API. Las API HTTP están optimizadas para el rendimiento. Ofrecen la funcionalidad principal de API Gateway a un precio más bajo;
- Flujos de trabajo rápidos de Step Functions: Los flujos de trabajo Express utilizan el mismo modelo de especificación declarativa que Step Functions Standard, pero está diseñado para casos de uso con gran volumen y corta duración de transacción (hasta 5 minutos). Los flujos de trabajo Express están diseñados para admitir una tasa de invocación por cuenta de AWS superior a 100.000 eventos por segundo;
- Proxy de Amazon RDS: Amazon RDS Proxy actúa como intermediario entre su aplicación y una base de datos RDS. El proxy RDS establece y administra los conjuntos de conexiones necesarios para la base de datos para que la aplicación cree menos conexiones a la base de datos.
- Simultaneidad aprovisionada de Lambda: capacidad de calentar entornos de ejecución de Lambda para soportar una carga de solicitudes concurrentes predefinidas mediante la entrega de respuestas con menor latencia al usuario final;
- Amazon EventBridge: Muchos servicios de la nube de AWS producen eventos, incluidas aplicaciones integradas de software como servicio (SaaS). Sus aplicaciones personalizadas también pueden producir y consumir eventos. Con tantos eventos de diferentes fuentes, se necesita una forma de coordinar todo el tráfico. Amazon EventBridge, es un bus de eventos sin servidor que le ayuda a crear una arquitectura basada en eventos, que permite una mayor escalabilidad y flexibilidad de sus aplicaciones con menos mantenimiento.
Caso de uso: Aplicación móvil con transacciones de compra en varios pasos
La arquitectura de ejemplo a continuación hace uso de las características anteriores para cumplir los siguientes requerimientos:
- Recibir un alto número de solicitudes API para transacciones de compra;
- Minimizar el mantenimiento de la infraestructura para resistir los picos de uso;
- Controlar múltiples operaciones durante la conversión del carrito de la compra, incluida la gestión de excepciones;
- Posibilidad de integración futura de la solución utilizando eventos para el procesamiento asíncrono;
Desglose de la solución
Para soportar un gran número de solicitudes con baja latencia (recomendado para soportar aplicaciones móviles) y con un coste controlado podemos combinar el uso de API HTTP de API Gateway y Simultaneidad Aprovisada de funciones Lambda. Las API HTTP tienen un mejor costo y rendimiento que las API REST tradicionales y se pueden integrar directamente con las funciones de Lambda.
La interfaz de creación de API en API Gateway se ha vuelto mucho más intuitiva y ya trae la opción de crear una API HTTP.
Al seleccionar la opción para construir una nueva API (Build), podemos comenzar a incluir integraciones con recursos existentes (funciones Lambda o endpoints HTTP).
Las integraciones se pueden asociar a reglas de enrutamiento para cada método PATH + HTTP. Finalizando las asignaciones, simplemente defina el entorno de ejecución y termine la creación. Al habilitar la opción Implementación automática, la API estará disponible para la invocación.
Para no tener el problema del arranque en frío cuando se ejecutan funciones Lambda, podemos aprovisionar los entornos de ejecución de acuerdo con la concurrencia de acceso esperada. Para cada rol que desee realizar el aprovisionamiento, debe crear una configuración de aprovisionamiento en la sección específica de la consola.
En la configuración de aprovisionamiento debe asignar a qué Alias o Versión específica de la función Lambda se estará invocando en los entornos de ejecución, y también deberá también fijar la cantidad de concurrencia.
El aprovisionamiento de los entornos tarda unos minutos y su estado puede visualizarse consola.
Es muy común que las transacciones en una aplicación (por ejemplo, transacción de compra) impliquen varios pasos: validación, comprobación y persistencia de la información. En una implementación basada en funciones de Lambda, la recomendación es evitar que las diferentes funciones específicas de cada paso sean orquestadas por otra función de Lambda, lo que dificulta la visibilidad del proceso como un todo y consume más recursos del tiempo de ejecución de Lambda. Una buena alternativa es utilizar las funciones de pasos de AWS que le permiten coordinar varias llamadas a servicios (incluidos los servicios de AWS) en flujos de trabajo sin servidor. En aplicaciones con un volumen de alta demanda y en las que se desea una latencia baja, la función Express Workflows ayuda a ofrecer rendimiento y menores costos de infraestructura.
Al crear un flujo de trabajo Step Functions, la nueva función se puede seleccionar en el primer paso de creación.
El resto de los pasos de configuración son muy similares al flujo de trabajo estándar. La máquina de estado que se va a definir en el flujo de trabajo, puede incluir todos los pasos involucrados en una operación compleja, también podrá incluir el manejo de errores y la compensación. Este flujo se define visualmente y es fácil de realizar el mantenimiento posterior.
Para ofrecer los beneficios citados, existe una restricción para ejecutar el flujo de trabajo en un máximo de 5 minutos. Este tiempo es más que suficiente para llevar a cabo los pasos de una transacción de compra.
Con un gran número de solicitudes, el punto que más puede afectar al performance es donde existe una limitación de escalabilidad. En el caso de nuestra aplicación de ejemplo, la limitación está en la base de datos relacional utilizada para la persistencia de compras donde hay un límite máximo en el número de conexiones disponibles. Una forma de extraer el máximo rendimiento de estas conexiones es reutilizándolas. Un componente que le ayuda a realizar este control de las conexiones es Amazon RDS Proxy. El proxy RDS actúa como intermediario entre la aplicación y una base de datos RDS. El proxy RDS establece y administra los conjuntos de conexiones necesarios para la base de datos para que la aplicación cree menos conexiones a la base de datos.
Del mismo modo que para la simultaneidad aprovisionada de Lambda, en la configuración de la función que accederá a la base de datos hay una sección para configurar el proxy de la base de datos.
La configuración del proxy define a qué instancia de RDS desea acceder, el secreto que almacena las credenciales de acceso a la base de datos registradas con AWS Secrets Manager y el rol que da acceso a esta última.
Después de crear el proxy, se proporcionará un punto final que debe usarse en su código en lugar de la url de acceso a la base de datos directamente.
Para que esta arquitectura sea fácilmente integrable con otros componentes y aplicaciones, se puede trabajar en una arquitectura orientada a eventos. Por ejemplo, podríamos generar un evento después de la ejecución de una compra para indicar el éxito/fracaso de la operación. Este evento podría ser consumido por una o más aplicaciones que necesitan dicha información, para funcionar de forma independiente y escalable sin afectar a la solución de origen de eventos.
Una de las soluciones que habilitan este modelo es el uso de Amazon EventBridge. Puede crear un bus de eventos en EventBridge para recibir una serie de eventos diferentes que ocurren en su entorno y crear reglas de enrutamiento y manejo para cada uno de ellos. Una característica muy útil presente en EventBridge es la posibilidad de crear un registro de esquemas de eventos enviados al bus dinámicamente e integrarlo con herramientas de desarrollo, para crear aplicaciones que consumen los datos en el cuerpo del evento.
Para crear un bus de eventos para su aplicación, simplemente asígnele un nombre y defina quién puede tener acceso a su bus.
A continuación, simplemente cree reglas de enrutamiento de eventos con la siguiente información:
- nombre y descripción de la regla;
- Patrón de eventos que se consumirá o programa de ejecución de reglas;
- ¿Qué autobús aplica la regla?
- Destinos (servicios de AWS) para eventos recibidos en el bus que cumplan el estándar establecido anteriormente;
- Etiquetas asociadas al recurso que se va a crear.
Esta fue una visión general de las nuevas características aplicadas en un escenario simple para una mejor comprensión. Antes de empezar a aplicar estas nuevas funciones, recomiendo comprobar su disponibilidad en la región deseada y también comprobar el método de precios. A continuación se muestra el precio general de cada uno.
Precios
Simultaneidad aprovisionada: Usted paga sólo por la cantidad de concurrencia que configuró y por el período en el que la configuró. El precio en EE.UU. Este (Virginia del Norte) es de 0,015 USD por GB-hora para la simultaneidad aprovisionada y de 0,035 USD por GB-hora para la duración. El número de solicitudes se cobra al mismo ritmo que las funciones normales. Puede encontrar más información en la página de precios de Lambda (https://thinkwithwp.com/lambda/pricing/).
API HTTP de API Gateway: 1,00 USD por millón de solicitudes, para los primeros 300 millones de solicitudes y 0,90 USD por millon de solicitudes, para todas las solicitudes posteriores. La mayoría de los clientes verán un ahorro de costes medio de hasta un 70% en comparación con API REST de API Gateway.
Flujos de trabajo Express de Step Functions: El precio de los flujos de trabajo estándar se basa en el número de transiciones de estado. El precio de los flujos de trabajo Express se basa en el número de llamadas y una carga GB-segundo en función de la cantidad de memoria utilizada para realizar un seguimiento del estado del flujo de trabajo durante la ejecución. Aunque los modelos de precios no son directamente comparables, Express Workflows será mucho más rentable a escala. Para obtener más información, consulte los precios de las AWS Step Functions.
Proxy RDS: Amazon RDS Proxy tiene un precio por vCPU por hora para cada instancia de base de datos para la que esté habilitada. El precio depende del tipo de instancia RDS utilizada por la base de datos y puede variar según la región.
EventBridge: Con Amazon EventBridge, paga los eventos publicados en el bus de eventos y los eventos ingeridos para la detección de esquemas. No hay cargos adicionales por reglas o entrega de eventos. Todos los eventos de cambio de estado publicados por los servicios de AWS son gratuitos. En general, usted paga 1.00 USD por millón de eventos publicados.
Operaciones de desarrollo
Otra cuestión muy importante para permitir el uso de estas tecnologías de una manera empresarial y ágil es el soporte para la Integración Continua y la Implementación/Entrega Continua. Sobre este tema específico centrado en las tecnologías sin servidor, está disponible un taller que presenta una solución de CI/CD basada en SAM en forma de producto utilizando el catálogo de servicios.
https://application-catalog.serverlessworkshops.io/
Finalización y próximos pasos
En esta entrada de blog, describimos nuevas características que le permiten admitir transacciones a gran escala en sus cargas de trabajo de AWS.
Para obtener más información sobre las características y características utilizadas, visite los siguientes vínculos:
https://thinkwithwp.com/blogs/compute/icymi-serverless-reinvent-recap-2019/
https://thinkwithwp.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/
https://thinkwithwp.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/
https://thinkwithwp.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/
Sobre el autor
Luiz Yanai es arquitecto de soluciones en AWS y experto en tecnologías sin servidor, asiste a clientes de varios segmentos en sus viajes a la nube. Con más de 15 años de experiencia en arquitectura y desarrollo de soluciones que involucran negocios y sistemas de misión crítica.
Revisor
Gustavo Fandiño, es un Arquitecto de Soluciones, para América Latina. Ha realizado proyectos de modernización, migración y microservicios. Dentro de sus objetivos está el expandir el uso de AWS en el territorio y colaborar muy de cerca con los partners y clientes, para facilitar el uso y adopción de soluciones costos eficientes en AWS.