Tarefas programadas automatizam tarefas rotineiras e repetitivas e reduzem o risco de erro humano. Elas garantem que tarefas essenciais ocorram no prazo, melhorando assim a produtividade e a eficiência.
No domínio Serverless, temos algumas maneiras de implementá-los.
Este post de blog vai lhe ensinar a aproveitar o Amazon EventBridge para criar tarefas agendadas usando o AWS CDK. Você aprenderá sobre a implementação de trabalhos cron (agendados) com regras do Amazon EventBridge e o mais novo agendador do EventBridge.
Analisaremos as diferenças entre as duas opções e implementaremos tarefas agendadas usando ambos os métodos com construções Python AWS CDK.
Um projeto de modelo totalmente implantável e exemplos de código podem ser encontrados aqui .
Índice
Amazon EventBridge
Todos nós tivemos que definir uma tarefa agendada em algum momento. Sou velho o suficiente para lembrar que costumávamos chamá-los de " cron jobs " nos dias felizes do Linux, quando eu costumava escrever um processo de cron job que garantiria que meu processo primário estivesse ativo e funcionando o tempo todo.
No entanto, tarefas agendadas ainda são bastante valiosas para o domínio sem servidor.
Você precisa de tarefas recorrentes ou únicas que sejam executadas em uma programação específica em muitos casos de uso. Aqui estão algumas que me vêm à mente:
Uma sugestão de treino matinal que o ChatGPT cria para você todos os dias.
Um trabalho em lote noturno que cria relatórios diários ou executa manutenção de banco de dados.
Um e-mail único lembrando os clientes de que a versão de avaliação termina em uma semana.
O Amazon EventBridge nos ajuda a implementar essas tarefas agendadas.
O Amazon EventBridge é um serviço sem servidor que usa eventos para conectar componentes de aplicativos, facilitando para os desenvolvedores a criação de eventos escaláveis
O Amazon EventBridge é um dos pilares das arquiteturas orientadas a eventos, semelhante ao Amazon SNS. O EventBridge é conhecido por criar regras que são acionadas quando uma condição predefinida ocorre e enviar um evento para muitos alvos, incluindo vários serviços da AWS.
O EventBridge tem dois mecanismos para criar tarefas agendadas:
Regras
Agendador
Vamos analisar esses mecanismos e entender suas capacidades e diferenças.
Regras do Amazon EventBridge
O EventBridge tem um barramento de eventos padrão e pode criar vários barramentos de eventos.
Um barramento de eventos é um pipeline que recebe eventos. As regras do EventBridge pertencem a um barramento de eventos. Há dois tipos de regras:
Padrão de evento baseado
Baseado em programação
Na regra de padrão de evento, você define eventos roteados para um ou mais alvos com base em critérios de correspondência de padrões. Ela tem mais de 20 tipos de alvos AWS integrados (SNS, SQS, StepFunction, etc.) e inclui parceiros externos da AWS, como DataDog, PagerDuty e outros.
É considerado um dos melhores mecanismos de coreografia de eventos sem servidor que a AWS fornece (SNS também vem à mente).
No entanto, vamos nos concentrar no segundo tipo de regra nesta postagem do blog, as regras baseadas em agendamento.
Existem dois tipos de tarefas agendadas:
Um cronograma detalhado definido com uma expressão cron.
Uma programação de taxas que executa uma tarefa em uma taxa específica (minutos, horas, dias).
No entanto, a AWS parece estar descontinuando o mecanismo de regras agendadas em favor do agendador mais recente: observe o botão amarelado no canto inferior direito que sugere que usemos o agendador em vez de uma regra agendada.
Agora, tudo o que resta é selecionar um alvo entre mais de 20 opções (até cinco alvos) para acionar.
Selecionei a integração da função Lambda.
Agendador Amazon EventBridge
O Amazon EventBridge Scheduler é um agendador sem servidor que permite que você crie, execute e gerencie tarefas a partir de um serviço central e gerenciado. Altamente escalável, o EventBridge Scheduler permite que você agende milhões de tarefas que podem invocar qualquer serviço da AWS como alvo.
O agendador do Amazon EventBridge é bem impressionante. Você pode definir eventos recorrentes ou únicos. Para eventos recorrentes, você pode defini-los com uma expressão cron, ou seja, executar em um horário específico para sempre, ou em um horário baseado em taxa, ou seja, a cada 10 minutos, para sempre. O Eventbrite promete que o evento agendado será acionado no intervalo de minutos, então não é exato ao segundo, mas na maioria dos casos, isso é bom o suficiente.
Quanto às integrações de destino, há suporte para 270 serviços e mais de 6.000 APIs.
Quanto às cotas , você tem cerca de 1 milhão de eventos agendados, o que parece mais que suficiente, e mesmo esse é um limite flexível que pode aumentar.
Agora, tudo o que resta é definir um alvo dentre a enorme lista de integrações possíveis.
Você pode definir apenas um alvo por programação, diferentemente das regras que suportam até 5 alvos por regra.
Agendador vs. Regras
Vamos analisar as diferenças entre o agendador e o mecanismo de regras de acordo com a documentação oficial da AWS e decidir qual é o melhor para tarefas agendadas sem servidor.
Do jeito que eu vejo, o planejador é melhor do que o mecanismo de regras em todos os sentidos possíveis: ele suporta um milhão de programações por conta vs. 300, o que é ridículo, tem maior rendimento e tem mais de 270 integrações de API. A integração de API significa que você não precisará criar uma função Lambda para chamar uma API; você pode ficar 100% Serverless sem escrever nenhum código de negócios e criar funções Lambda.
Além disso, o agendador não requer uma conexão com um barramento EventBridge; ele é algo próprio.
O agendador suporta fusos horários e horário de verão, simplificando o tempo. O agendamento único abre a porta para muitos casos de uso interessantes, como eventos personalizados por evento do cliente, como enviar um lembrete por e-mail cinco dias antes do término do teste de um cliente, e outro caso de uso, já que a cota é relativamente alta (1 milhão).
O agendador é uma versão refinada e melhorada do mecanismo de regras mais antigo. Então, por que você usaria o mecanismo de regras mais antigo para tarefas agendadas? Não vejo nenhuma razão além do melhor suporte a construções de CDK (que é apenas temporário, veja este PR ).
O limite de 300 regras pode ser um obstáculo para muitos.
No agendador, você obtém muito mais recursos e uma cota maior. O recurso de agendamento único é poderoso para criar um gatilho em uma data específica, adaptado para um evento de cliente/locatário. No entanto, essa cota de um milhão pode ser um problema para empresas com milhões de usuários.
A única desvantagem do agendador, na minha opinião, é que ele só pode ter um alvo.
As regras podem ter até cinco alvos por regra, mas, por outro lado, você pode criar cinco programações diferentes e obter a mesma experiência.
Dito isso, as regras como orquestrador de eventos são uma ferramenta fantástica que não vai a lugar nenhum. Elas nos permitem ouvir eventos por um padrão e disparar alvos, sejam serviços da AWS ou parceiros externos, sem nenhuma relação com um tempo específico; elas disparam quando o evento ocorre.
O caso de uso do cronograma único
A opção de agendador único é única e empolgante, não suportada no mecanismo de regras. Um caso de uso diário pode estar relacionado a notificações de clientes em datas específicas.
Talvez você queira enviar um SMS/e-mail informando a um cliente que sua versão de teste está prestes a expirar ou expirou. Você pode enviar a eles uma oferta especial no aniversário deles. Você pode fazer isso sem uma única função Lambda, conectar o planejador ao AWS SES e definir os parâmetros de e-mail a serem usados. Como você tem uma cota de 1 milhão de eventos, é uma opção viável.
Devido à natureza única, o uso prático não seria por meio do CDK, mas chamando a API da AWS em tempo de execução em uma função Lambda.
No entanto, esse recurso tem uma desvantagem significativa : agendamentos expirados não são excluídos automaticamente, mas ainda contam para sua cota geral.
Atualização 08/03/23 - a partir de agora, é possível definir uma exclusão automática na conclusão do agendamento, então isso não é mais uma desvantagem!
Amostras de código CDK
Vamos ver como podemos implementar os casos de uso de exemplo com o AWS CDK e o EventBridge.
Analisaremos vários casos de uso reais e os implementaremos com regras do EventBridge e o agendador.
Daily ChatGPT Sugestão com Função Lambda
Um dos casos de uso mais simples e comuns de tarefas agendadas é a regra para o padrão de função Lambda. Pode ser em uma taxa baseada ou em um caso de data específica.
Para uma sugestão diária do ChatGPT, você pode definir uma regra de tarefa cron que acione uma função Lambda em um horário definido pela manhã. A função Lambda chama a API ChatGPT e usa o Amazon SES para enviar um e-mail com os resultados.
Um herói do AWS Serverless, Allen Helton , fez exatamente isso e escreveu um post detalhado sobre isso.
Para casos de uso simples que não exigem muitas etapas e terminam em menos de 15 minutos (o período máximo de tempo limite de uma função Lambda), esta é uma ótima solução que é fácil de testar tanto localmente quanto em um fluxo E2E. Leia aqui sobre como testar aplicativos Serverless.
Nas linhas 13 a 25, definimos a regra com um tempo cron e um alvo de uma função Lambda.
As linhas 17 a 22 definem o horário - 18h UTC, de segunda a sexta.
A linha 23 define uma lista de alvos. Neste exemplo, temos uma única função Lambda.
Se você deseja usar uma tabela de taxas, use esta implementação que define uma função Lambda para ser invocada a cada 60 minutos:
Vamos definir o mesmo caso de uso, mas com o novo mecanismo de agendamento.
Gostaria de agradecer a Amanda Quint por sua postagem que me ajudou a definir este recurso do CFN.
Ainda não há uma construção de nível superior para o agendador, mas ela está em andamento (em 28 de abril de 2023).
Nas linhas 13 a 28, definimos uma função para o agendador do EventBridge usar, que tem permissões de invocação lambda da função Lambda de destino.
Nas linhas 30-47, definimos o objeto CFN de baixo nível do CloudFormation do planejador. É uma classe de baixo nível que representa uma definição direta do CloudFormation. Os parâmetros são essencialmente um dicionário de parâmetros.
Nas linhas 40-41, definimos a expressão de agendamento de 10h de domingo a quinta-feira com o fuso horário de Jerusalém (Israel). O agendador tem um suporte de fuso horário mais refinado em vez de apenas UTC. Ele também tem suporte para alterações automáticas de horário de verão (DST).
Nas linhas 42-44, definimos a função Lambda alvo a ser invocada. O ARN do Lambda é o mesmo Lambda que permitimos que a função do planejador invocasse.
Trabalho noturno em lote longo com função de etapa
Se você precisar executar um processo que leve mais do que o tempo máximo da função Lambda, que é 15 minutos, você pode criar uma função de etapa e orquestrar o trabalho em lote.
Aqui está um exemplo de construção que cria uma função Step com um estado e uma regra EventBridge que a aciona diariamente às 18h UTC.
Nas linhas 14-24, criamos uma Máquina de Estados com uma etapa que aguarda 10 segundos e é concluída com sucesso.
Na linha 39, definimos o alvo da regra para a máquina de estados que criamos na linha 14.