Las tareas programadas automatizan las tareas rutinarias y repetitivas y reducen el riesgo de error humano. Garantizan que las tareas esenciales se realicen a tiempo, mejorando así la productividad y la eficiencia.
En el dominio sin servidor, tenemos un par de formas de implementarlos.
En esta publicación del blog, aprenderá a aprovechar Amazon EventBridge para crear tareas programadas con AWS CDK. Aprenderá a implementar trabajos cron (programados) con reglas de Amazon EventBridge y el programador más nuevo de EventBridge.
Revisaremos las diferencias entre las dos opciones e implementaremos tareas programadas utilizando ambos métodos con construcciones Python AWS CDK.
Aquí encontrará un proyecto de plantilla totalmente implementable y ejemplos de código .
Tabla de contenido
Puente de eventos de Amazon
Todos tuvimos que definir una tarea programada en algún momento. Soy lo suficientemente mayor como para recordar que solíamos llamarlas " tareas programadas " en los felices días de Linux, cuando escribía un proceso de tarea programada que se aseguraba de que mi proceso principal estuviera activo y en ejecución en todo momento.
Sin embargo, las tareas programadas siguen siendo bastante valiosas para el dominio sin servidor.
Necesita tareas recurrentes o únicas que se ejecuten según un cronograma específico en muchos casos de uso. A continuación, se muestran algunos que me vienen a la mente:
Una sugerencia de entrenamiento matutino que ChatGPT elabora para ti todos los días.
Un trabajo por lotes de larga duración que se realiza cada noche y que genera informes diarios o ejecuta el mantenimiento de la base de datos.
Un correo electrónico único para recordar a los clientes que su versión de prueba finaliza en una semana.
Amazon EventBridge nos ayuda a implementar estas tareas programadas.
Amazon EventBridge es un servicio sin servidor que utiliza eventos para conectar componentes de aplicaciones, lo que facilita a los desarrolladores la creación de aplicaciones escalables basadas en eventos.
Amazon EventBridge es uno de los pilares de las arquitecturas basadas en eventos, similar a Amazon SNS. EventBridge es conocido por crear reglas que se activan cuando se produce una condición predefinida y enviar un evento a muchos destinos, incluidos numerosos servicios de AWS.
EventBridge tiene dos mecanismos para crear tareas programadas:
Normas
Programador
Repasemos estos mecanismos y entendamos sus capacidades y sus diferencias.
Reglas de Amazon EventBridge
EventBridge tiene un bus de eventos predeterminado y puede crear múltiples buses de eventos.
Un bus de eventos es una canalización que recibe eventos. Las reglas de EventBridge pertenecen a un bus de eventos. Existen dos tipos de reglas:
Basado en patrones de eventos
Basado en programación
En la regla de patrón de eventos, se definen los eventos enrutados a uno o más destinos según los criterios de coincidencia de patrones. Tiene más de 20 tipos de destinos de AWS integrados (SNS, SQS, StepFunction, etc.) e incluye socios externos de AWS como DataDog, PagerDuty y otros.
Se considera uno de los mejores mecanismos de coreografía de eventos sin servidor que ofrece AWS (SNS también me viene a la mente).
Sin embargo, en esta entrada del blog nos centraremos en el segundo tipo de regla: las reglas programadas.
Hay dos tipos de tareas programadas:
Una programación detallada definida con una expresión cron.
Un programa de tarifas que ejecuta una tarea a una velocidad específica (minutos, horas, días).
Sin embargo, AWS parece estar desactualizando el mecanismo de reglas programadas en favor del programador más nuevo: observe el botón amarillento en la parte inferior derecha que sugiere que usemos el programador en lugar de una regla programada.
Ahora, todo lo que queda es seleccionar un objetivo entre las más de 20 opciones (hasta cinco objetivos) para activarlo.
He seleccionado la integración de la función Lambda.
Programador de Amazon EventBridge
Amazon EventBridge Scheduler es un programador sin servidor que le permite crear, ejecutar y administrar tareas desde un servicio central y administrado. EventBridge Scheduler es altamente escalable y le permite programar millones de tareas que pueden invocar cualquier servicio de AWS como destino.
El programador de Amazon EventBridge es bastante impresionante. Puedes definir eventos recurrentes o únicos. En el caso de los eventos recurrentes, puedes definirlos con una expresión cron, es decir, que se ejecuten a una hora específica para siempre, o con una frecuencia determinada, es decir, cada 10 minutos, para siempre. Eventbrite promete que el evento programado se activará en el rango de minutos, por lo que no es exacto al segundo, pero en la mayoría de los casos, eso es suficiente.
En cuanto a las integraciones de objetivos, hay soporte para 270 servicios y más de 6000 API.
En cuanto a los cupos , tienes alrededor de 1 millón de eventos programados, lo que parece más que suficiente, e incluso ese es un límite suave que puede aumentar.
Ahora, todo lo que queda es definir un objetivo de la abrumadora lista de posibles integraciones.
Puede definir solo un objetivo por programación, a diferencia de las reglas que admiten hasta 5 objetivos por regla.
Programador vs. Reglas
Repasemos las diferencias entre el programador y el mecanismo de reglas según la documentación oficial de AWS y decidamos cuál es mejor para las tareas programadas sin servidor.
En mi opinión, el programador es mejor que el mecanismo de reglas en todos los sentidos posibles: admite un millón de programaciones por cuenta en lugar de 300, lo cual es ridículo, tiene un mayor rendimiento y tiene más de 270 integraciones de API. La integración de API significa que no necesitarás activar una función Lambda para llamar a una API; puedes trabajar sin servidor al 100 % sin escribir ningún código comercial ni activar funciones Lambda.
Además, el programador no requiere una conexión a un bus EventBridge; es algo propio.
El programador admite zonas horarias y horario de verano, lo que simplifica la programación. La programación única abre la puerta a muchos casos de uso interesantes, como eventos personalizados para cada evento del cliente, como enviar un recordatorio por correo electrónico cinco días antes de que finalice la prueba de un cliente, y otro caso de uso dado que la cuota es relativamente alta (1 millón).
El programador es una versión refinada y mejorada del mecanismo de reglas anterior. Entonces, ¿por qué usarías el mecanismo de reglas anterior para tareas programadas? No veo ninguna razón aparte de la mejor compatibilidad con las construcciones de CDK (que es solo temporal, consulta esta PR ).
El límite de 300 reglas podría ser un factor decisivo para muchos.
En el programador, obtienes muchas más funciones y una mayor cuota. La capacidad de programar una sola vez es poderosa para crear un disparador en una fecha específica adaptada a un evento de cliente/inquilino. Sin embargo, esa cuota de un millón puede ser un problema para empresas con millones de usuarios.
La única desventaja del programador, tal como lo veo, es que solo puede tener un objetivo.
Las reglas pueden tener hasta cinco objetivos por regla, pero por otro lado, podrías crear cinco programas diferentes y obtener la misma experiencia.
Dicho esto, las reglas como orquestador de eventos son una herramienta fantástica que no desaparecerá. Nos permiten escuchar eventos según un patrón y activar objetivos, ya sean servicios de AWS o socios externos, sin ninguna relación con un momento específico; se activan cuando ocurre el evento.
El caso de uso de programación única
La opción de programador de una sola vez es única y emocionante, no está respaldada por el mecanismo de reglas. Un caso de uso cotidiano podría estar relacionado con las notificaciones a clientes en fechas específicas.
Es posible que desee enviar un SMS o correo electrónico para informar a un cliente que su versión de prueba está a punto de vencer o ha vencido. Puede enviarles una oferta especial en su cumpleaños. Puede hacerlo sin una sola función Lambda, conectar el programador a AWS SES y definir los parámetros de correo electrónico que se utilizarán. Dado que tiene una cuota de 1 millón de eventos, es una opción viable.
Debido a su naturaleza de un solo uso, el uso práctico no sería a través de CDK sino llamando a la API de AWS en tiempo de ejecución en una función Lambda.
Sin embargo, esta función tiene una desventaja importante : los horarios vencidos no se eliminan automáticamente, pero siguen contando para la cuota general.
Actualización 8/3/23: a partir de ahora, es posible definir una eliminación automática al finalizar el cronograma, por lo que esto ya no es un inconveniente.
Ejemplos de código CDK
Veamos cómo podemos implementar los casos de uso de muestra con AWS CDK y EventBridge.
Analizaremos varios casos de uso reales y los implementaremos con las reglas de EventBridge y el programador.
Sugerencia de Daily ChatGPT con función Lambda
Uno de los casos de uso más simples y comunes de las tareas programadas es el patrón de función Lambda de reglas. Puede basarse en una tasa o en un caso de fecha específica.
Para una sugerencia diaria de ChatGPT, puedes definir una regla de trabajo cron que active una función Lambda a una hora determinada de la mañana. La función Lambda llama a la API de ChatGPT y utiliza Amazon SES para enviar un correo electrónico con los resultados.
Un héroe de AWS Serverless, Allen Helton , hizo exactamente eso y escribió una publicación detallada al respecto.
Para casos de uso simples que no requieren muchos pasos y finalizan en menos de 15 minutos (el período de espera máximo de una función Lambda), esta es una excelente solución que es fácil de probar tanto de manera local como en un flujo E2E. Lea aquí sobre cómo probar aplicaciones sin servidor.
En las líneas 13-25, definimos la regla con un tiempo cron y un objetivo de una función Lambda.
Las líneas 17 a 22 definen la hora (6:00 p. m. UTC) de lunes a viernes.
La línea 23 define una lista de objetivos. En este ejemplo, tenemos una única función Lambda.
Si desea utilizar un programa de tarifas, utilice esta implementación que define una función Lambda que se invocará cada 60 minutos:
Definamos el mismo caso de uso pero con el nuevo mecanismo de programación.
Quiero agradecer a Amanda Quint por su publicación que me ayudó a definir este recurso de CFN.
Todavía no existe una construcción de nivel superior para el programador, pero se está trabajando en ello (a partir del 28 de abril de 2023).
En las líneas 13 a 28, definimos un rol que el programador EventBridge debe usar y que tiene permisos de invocación de lambda de la función Lambda de destino.
En las líneas 30 a 47, definimos el objeto CFN de bajo nivel del planificador CloudFormation. Es una clase de bajo nivel que representa una definición directa de CloudFormation. Los parámetros son, esencialmente, un diccionario de parámetros.
En las líneas 40 y 41, definimos la expresión de programación de las 10 a. m. de domingo a jueves con la zona horaria de Jerusalén (Israel). El programador tiene una compatibilidad con zonas horarias más refinada en lugar de solo UTC. También admite cambios automáticos de horario de verano (DST).
En las líneas 42 a 44, definimos la función Lambda de destino que se invocará. El ARN Lambda es el mismo Lambda que permitimos que invoque la función del programador.
Trabajo por lotes largo nocturno con función de pasos
Si debe ejecutar un proceso que toma más que el tiempo máximo de la función Lambda, que es de 15 minutos, puede crear una función de paso y orquestar el trabajo por lotes.
A continuación se muestra un ejemplo de construcción que crea una función Step con un estado y una regla EventBridge que la activa diariamente a las 6:00 p. m. UTC.
En las líneas 14 a 24 creamos una máquina de estados con un paso que espera 10 segundos y se completa exitosamente.
En la línea 39 establecemos el objetivo de la regla en la máquina de estados que creamos en la línea 14.
Comentarios