Apresentando o AWS Step Functions Redrive para se recuperar de falhas com mais facilidade

Por Benjamin Smith – Principal Developer Advocate na AWS

Os desenvolvedores usam o AWS Step Functions, um serviço visual de workflow para criar aplicativos distribuídos, automatizar processos comerciais e de TI e orquestrar serviços da AWS com o mínimo de código.

O redrive do Step Functions para workflow standard (fluxos do tipo padrão) permite que você redirecione a execução de um workflow com falha a partir do ponto da falha, em vez de precisar reiniciar todo o workflow. Esta postagem explica como usar o novo recurso de redrive para pular etapas desnecessárias do workflow e reduzir o custo de redirecionar workflows com falha.

Tratamento de erros do workflow

Qualquer estado do workflow pode encontrar erros de runtime. Os erros ocorrem por vários motivos, incluindo problemas de definição da máquina de estado, falhas de tarefas, permissões incorretas e exceções de serviços posteriores. Por padrão, quando um estado relata um erro, o Step Functions faz com que a execução do workflow falhe. O Step Functions permite lidar com erros tentando novamente, capturando e voltando a um estado definido.

Agora, você também pode reconduzir (redrive) o workflow do estado de falha, ignorando as etapas anteriores bem-sucedidas do workflow. Isso resulta em uma conclusão mais rápida do workflow e custos mais baixos. Você só pode redirecionar uma execução de workflow com falha a partir da etapa em que ela falhou usando a mesma entrada do último estado sem sucesso. Você não pode reconduzir uma execução de workflow com falha usando uma definição de máquina de estado diferente da execução inicial do workflow.

Escolhendo entre tentar novamente (retry) e reconduzir (redrive)

Use o mecanismo de retry para problemas transitórios, como problemas de conectividade de rede ou indisponibilidade momentânea do serviço. Você pode configurar o número de novas tentativas, junto com intervalos e taxas back-off, fornecendo ao workflow várias tentativas para concluir uma tarefa com êxito.

Em cenários em que a causa subjacente de um erro exige maior tempo de investigação ou resolução, o redrive se torna uma ferramenta valiosa. Considere uma situação em que um serviço downstream tenha um tempo de inatividade prolongado ou seja necessária uma intervenção manual, como atualizar um banco de dados ou fazer alterações no código de uma função do Lambda. Nesses casos, ser capaz de reorientar (redrive) o workflow pode lhe dar tempo para resolver a causa raiz antes de retomar a execução do workflow.

Combinando retry e redrive

Adote uma estratégia híbrida que combine mecanismos de retry e redrive:

1. Mecanismo de retry: configure um conjunto inicial de novas tentativas para erros que podem ser resolvidos automaticamente. Isso garante que problemas transitórios sejam resolvidos imediatamente e que o workflow prossiga sem atrasos desnecessários.
2. Detecção e redrive de erros: se o mecanismo de retry se esgotar sem sucesso, permita que o estado falhe e use o recurso de redrive para reiniciar o workflow a partir do último estado sem sucesso. Essa abordagem permite a intervenção onde os erros persistem ou exigem ações externas.

Reduzindo custos

A AWS cobra pelos workflows Standard com base no número de transições de estado necessárias para executar uma carga de trabalho. O Step Functions conta uma transição de estado cada vez que uma etapa do seu workflow é executada. O Step Functions cobra pelo número total de transições de estado entre máquinas de estado, incluindo novas tentativas (retry). O custo é de 0,025 USD por 1.000 transições de estado. Isso significa que reduzir o número de transições de estado reduz o custo de execução de seus workflows standard.

Se um workflow tiver muitas etapas, incluir estados paralelos, em mapas ou estiver propenso a erros que exigem repetições frequentes, esse novo recurso reduz os custos incorridos. Você paga somente por cada transição de estado após o estado de falha e esses custos por cada serviço downstream invocado como parte da repetição.

O exemplo a seguir explica as implicações de custo de repetir um workflow que falhou, com e sem redrive. Neste exemplo, um workflow do Step Functions orquestra o Amazon Transcribe para gerar uma transcrição de texto a partir de um arquivo.mp4.

Como o estado de falha ocorre no final desse workflow, a execução do redrive não executa os estados bem-sucedidos, reduzindo o tempo geral de conclusão bem-sucedida. Se esse workflow falhar regularmente, a redução nas transições e na duração da execução se tornará cada vez mais valiosa.

Na primeira vez em que esse workflow é executado, o estado final, que usa uma função do AWS Lambda para fazer uma solicitação HTTP, falha com um erro do IAM. Isso ocorre porque o workflow não tem as permissões necessárias para invocar a função Lambda. Depois de conceder as permissões necessárias para a função de execução do workflow, redirecione (redrive) para continuar o workflow a partir do estado de falha.

Após o redrive, o workflow do Step Functions relata uma falha diferente. Desta vez, está relacionado à configuração da função Lambda. Este é um exemplo de uma falha posterior que não exige uma atualização na definição do meu workflow.

Depois de resolver o problema de configuração do Lambda e redirecionar o workflow, a execução é concluída com êxito. A imagem a seguir mostra os detalhes da execução, incluindo o número de redrives, o total de transições de estado e o horário do último redrive:

Começando com o redrive

O Redrive funciona somente para workflows standard. Você pode redirecionar programaticamente um fluxo de trabalho da etapa que falhou, por meio da AWS CLI ou do SDK da AWS, ou usando o console Step Functions, que fornece uma experiência visual ao operador:

1. No console do Step Functions, selecione o workflow com falha que você deseja reconduzir e escolha Redrive.
   
2. Um modal aparece com os detalhes da execução. Escolha Redrive execution.
   

O estado a partir do qual é possível redirecionar, bem como a definição do workflow e a entrada anterior são imutáveis.

Para redirecionar a execução de um workflow programaticamente a partir do ponto de falha, chame a nova ação da API Redrive Execution. A mesma execução do workflow começa no último estado sem êxito e usa a mesma entrada que o último estado sem êxito da execução inicial do workflow com falha.

Detectando programaticamente execuções de workflow com falha para redrive

O Step Functions pode processar cargas de trabalho de forma autônoma, sem a necessidade de interação humana, ou pode incluir a intervenção de um usuário implementando o padrão .waitForTaskToken.

O Redrive é apenas para erros não tratados e inesperados. O tratamento de erros em um workflow usando os mecanismos integrados para captura, repetição e roteamento para um estado de falha não permite que o workflow seja reconduzido. No entanto, é possível detectar quase em tempo real quando um workflow falhou e reorientá-lo programaticamente. Quando um workflow falha, ele emite um evento no barramento de eventos padrão do Amazon EventBridge. O evento se parece com o seguinte objeto JSON:

Há quatro novos pares de chave/valores neste evento:

"redriveCount": 0, 
"redriveDate": null, 
"redriveStatus": "REDRIVABLE", 
"redriveStatusReason": null,

A contagem de redirecionamentos mostra quantas vezes o workflow foi redirecionado anteriormente. O status do redrive mostra se o workflow com falha está qualificado para execução do redrive.

É possível reorientar (redrive) programaticamente o workflow do estado de falha. Crie uma regra cujo padrão corresponda a esse evento e encaminhe o evento para um serviço de destino para lidar com o erro. O serviço de destino usa a nova API States.redriveExecution para reorientar (redrive) o fluxo de trabalho.

Baixe e implante o padrão anterior deste exemplo em serverlessland.com.

No exemplo a seguir, o primeiro estado envia uma solicitação post para um endpoint da API. Se a solicitação falhar devido a problemas de conectividade de rede ou latência, o estado tentará novamente. Se a nova tentativa falhar, o Step Functions emitirá um evento ‘Step Functions Execution Status Change’ no barramento de eventos padrão do EventBridge. Uma regra do EventBridge direciona esse evento para um serviço em que você pode corrigir esse erro e, em seguida, reconduzir a tarefa usando a API Step Functions.

O novo recurso de redrive também suporta o estado do Distributed Map.

Redrive para execuções express em workflows secundários

Para execuções malsucedidas de workflows secundários que são workflow expressos em um Distributed Map, o recurso de redrive garante uma reinicialização perfeita desde o início do workflow secundário. Isso permite que você resolva problemas específicos de iterações individuais sem reiniciar o mapa inteiro.

Redrive para execuções standard em workflows secundários

Para execuções malsucedidas de workflow secundário em um Distributed Map que são workflows Standard, o recurso de redrive funciona da mesma forma em workflow Standard autônomos. Você pode reiniciar a iteração com falha a partir do ponto de falha, ignorando etapas desnecessárias que já foram executadas com êxito.

Conclusão

O redrive do Step Functions para workflows Standard permite que você redirecione a execução de um workflow com falha a partir do ponto da falha, em vez de precisar reiniciar todo o workflow. Isso resulta em uma conclusão mais rápida do workflow e menores custos de processamento de execuções malsucedidas. Isso ocorre porque ele minimiza o número de transições de estado e invocações de serviços posteriores.

Visite a Coleção de workflows serverless para ver os diversos workflows implantáveis para ajudar a criar seus aplicativos serverless.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Biografia do Autor

Ben Smith, Principal Developer Advocate

Biografia do tradutor

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Biografia do revisor

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/