O blog da AWS

Implementação de padrões que precocemente saem de um estado paralelo no AWS Step Functions

Por Benjamin Smith

Este post foi escrito por Madhav Vishnubhatta, gerente técnico sênior de contas (TAM) e enterprise suporte, e adaptado para Português por Daniel ABIB, arquiteto de soluções sênior para Entreprise.

Este blog post explica como implementar padrões no AWS Step Functions, serviço que controla a saída de um estado paralelo assim que um requisito mínimo é atendido. O estado paralelo geralmente é concluído somente quando todos os fluxos paralelos dentro dele são concluídos. Entretanto, se você não quiser esperar que todos os fluxos paralelos sejam concluídos antes de passar para a próxima etapa, este post fornece padrões para ajudar a implementar esta funcionalidade.

Você pode usar o AWS Step Functions para configurar fluxos de trabalho (workflows) visuais Serverless que orquestram e coordenam vários serviços da AWS em um fluxo de trabalho Serverless. Isso permite que você crie aplicativos complexos, dinâmicos e escaláveis sem gerenciar a infraestrutura básica. No Step Functions, as etapas individuais são chamadas de estados.

O Step Functions oferece vários tipos de estados. Alguns estados ajudam a controlar a lógica do fluxo de trabalho. Por exemplo, o estado de escolha permite que a lógica condicional controle o fluxo para qualquer um dos vários próximos estados possíveis, dependendo das condições definidas no estado. O estado paralelo ajuda a controlar a lógica, mas em vez de escolher um dos vários próximos estados (como acontece com o estado de escolha), o estado paralelo permite que todas as ramificações funcionem como fluxos paralelos simultaneamente. Quando todos os fluxos paralelos estiverem concluídos, o controle passa para o próximo estado do estado paralelo.

Padrões que não precisam esperar que todos os fluxos paralelos terminem

Considere um cenário em que o fluxo de trabalho do Step Functions represente o processo de um funcionário solicitando um laptop em sua organização. O processo começa com uma solicitação do funcionário como primeira etapa, mas a aprovação dessa solicitação pode vir de qualquer um dos dois gerentes de TI.

Nesse caso, pode haver dois fluxos paralelos, cada um aguardando a aprovação de um gerente de TI. Mas, assim que uma pessoa der a aprovação, o fluxo de trabalho pode avançar para a próxima etapa, que é realmente entregar um laptop para o funcionário. Esse é um padrão “um ou outro”.

Considere um caso de uso semelhante, mas com um requisito um pouco diferente. Em vez de a aprovação de uma pessoa ser suficiente para emitir um laptop, seja necessária a aprovação de no mínimo dois em cada três gerentes de TI antes que o laptop seja liberado. Esse é o padrão do “quórum”.

O estado paralelo não suporta diretamente esses dois padrões porque espera que todos os fluxos sejam concluídos. Nesse caso, isso significa que todos os gerentes devem fornecer uma aprovação antes que um laptop possa ser emitido.

Visão geral da solução

O Step Functions fornece um mecanismo de tratamento de erros com o estado de falha, que pode ser usado para falhar no fluxo de trabalho com um erro. Esse erro pode ser detectado posteriormente no fluxo de trabalho e tratado conforme necessário. Tanto o padrão de “um ou outro” quanto o de “quórum” podem ser implementados com esse estado de falha junto com o recurso de tratamento de erros.

No caso de “um ou outro”, assim que o fluxo paralelo for concluído, o estado de falha pode gerar um erro, que é detectado fora do estado paralelo para processamento posterior. Mesmo sendo o estado de falha, ele pode não representar um cenário de erro em seu caso de uso.

O padrão de “quorum” precisa de um mecanismo adicional para armazenar o status de cada fluxo paralelo, usando uma tabela do Amazon DynamoDB. O padrão de “quorum” cria um item na tabela do DynamoDB no início do fluxo de trabalho que é atualizado por cada fluxo paralelo assim que ele é concluído. Cada fluxo paralelo verifica a tabela do DynamoDB para ver o número de processos concluídos e compará-la com o quórum. Se o quórum for atingido, esse fluxo gerará um erro com um estado de falha que pode ser detectado fora da etapa paralela.

Pré-requisitos

Ambos os padrões são publicados no Serverless Land:

  • https://serverlessland.com/workflows/either-or-parallel-pattern
  • https://serverlessland.com/workflows/quorum-with-parallel-pattern

Para implantar e usar esses padrões, você precisa:

  1. Uma conta da AWS
  2. Acesso para fazer login como usuário ou assumir uma função que possa:
    • Criar e executar um fluxo de trabalho do Step Functions.
    • Criar e atualizar uma tabela do DynamoDB.
    • Criar uma função do AWS Identity and Access Management (IAM) para as Step Functions assumirem ao executar o fluxo de trabalho.
  3. Familiaridade com o AWS Serverless Application Model (AWS SAM).
  4. Interface de linha de comando AWS SAM instalada.

Exemplo de explicação passo a passo

Padrão “Um ou outro”

Para implantar o padrão “um ou outro”, siga a seção Instruções de implantação no repositório do GitHub. Essa implantação cria os seguintes recursos:

  1. Um fluxo de trabalho (workflow) do Step Functions.
  2. Uma função (role) do IAM que é assumida pelo fluxo de trabalho do Step Functions durante a execução.

Navegue até a página do AWS CloudFormation no AWS Management Console e escolha a pilha com o nome fornecido durante a implantação. Escolha o recurso State Machine na seção Recursos da pilha do CloudFormation para acessar o console Step Functions. Escolha Editar e, em seguida, escolha WorkflowStudio para ver uma representação visual do fluxo de trabalho.

Você pode ver o fluxo de trabalho exportado no repositório do GitHub. Essa é a lógica do fluxo de trabalho:

Padrão “Um ou outro”. Fluxo conceitual.

  1. Há três fluxos paralelos (numerados) nesse fluxo de trabalho.
  2. Os fluxos #1 e #2 são os principais fluxos paralelos, um dos quais, sendo concluído, deve mover o controle para fora do estado paralelo.
  3. O fluxo #3 é o fluxo de tempo limite para que o fluxo de trabalho possa sair após um determinado período de tempo se nenhum dos outros dois fluxos paralelos for concluído até lá.
  4. Cada um dos dois principais fluxos paralelos segue a seguinte lógica:
    • Aguarde a conclusão do processo. Isso é um preenchimento e pode ser substituído pela sua lógica de negócios sobre como monitorar a conclusão do processo. Isso pode ser uma aprovação humana ou qualquer outro trabalho que precise ser concluído.
    • Quando o processo estiver concluído, emita um erro fictício, que move o controle para fora do estado paralelo.
  5. Os erros fictícios dos dois fluxos são detectados fora do estado paralelo com a condição de captura correspondente.
  6. Os erros dos dois fluxos não precisam ser detectados separadamente. Você pode simplesmente fazer a mesma ação, independentemente de qual dos fluxos paralelos tenha terminado, mas eu mostro etapas separadas caso você precise fazer algo diferente com base no fluxo paralelo concluído.

Para testar o fluxo de trabalho, siga as instruções fornecidas na seção Teste do arquivo README no repositório do GitHub.

Para limpar os recursos criados, execute:

sam delete

Padrão de “quórum”

Para implantar o padrão Quorum, siga a seção Instruções de implantação no repositório do GitHub. Esse deploy cria os seguintes recursos:

  1. Um fluxo de trabalho (workflow) do Step Functions.
  2. Uma função (role) do IAM que é assumida pelo fluxo de trabalho do Step Functions durante a execução.
  3. Uma tabela do DynamoDB chamada “QuorumWorkflowTable”.

Navegue até o CloudFormation no AWS Management Console e escolha a pilha com o nome fornecido durante o deployment. Escolha o recurso da máquina de estado na seção Recursos da pilha do CloudFormation para acessar o console Step Functions.

Escolha Editar e, em seguida, escolha WorkflowStudio para ver uma representação visual do fluxo de trabalho

Você pode ver o fluxo de trabalho exportado no repositório do GitHub. Essa é a lógica do fluxo de trabalho:

Padrão de quórum. Fluxo conceitual.

  1. A primeira etapa cria uma entrada na tabela do DynamoDB com o ID de execução da execução do fluxo de trabalho. Esse item na tabela acompanha a conclusão dos processos.
  2. O próximo estado é o estado paralelo, que tem três fluxos paralelos e um quarto fluxo de saída de tempo. Todos os quatro fluxos estão numerados.
  3. Os fluxos #1, #2 e #3 são os principais fluxos paralelos, dois dos quais, concluídos, devem mover o controle para fora do estado paralelo.
  4. O fluxo #4 é o fluxo de tempo limite para que o fluxo de trabalho possa sair após um determinado período de tempo, se nenhum dos outros dois fluxos paralelos for concluído até lá.
  5. Cada um dos três fluxos paralelos principais usa a seguinte lógica:
    • Aguarde a conclusão do processo.
    • Depois de concluído, atualize a entrada da tabela do DynamoDB para marcar a conclusão do processo.
    • Após a atualização, consulte o item do DynamoDB para obter a lista de processos que foram concluídos e verificar se o quórum foi atingido.
    • Se o quórum tiver sido atingido, gere um “Erro” (que na verdade é um critério de sucesso em termos de caso comercial) para mover o controle para fora do estado paralelo.

Para testar o fluxo de trabalho, siga as instruções fornecidas na seção Teste do arquivo README no repositório do GitHub.

Para limpar os recursos criados, execute:

sam delete

Conclusão

Esta blog post mostra como você pode implementar padrões que devem sair antecipadamente de um estado paralelo em um fluxo de trabalho do AWS Step Functions.

Os casos de uso dessa abordagem não se limitam a esses dois padrões. Casos de uso mais complicados, como ter diferentes combinações de condições para sair de um estado paralelo, podem ser implementados usando estados paralelos e de falha.

Visite Serverless Land para obter mais padrões de fluxo de trabalho do Step Functions.

 

Este artigo foi traduzido do Blog da AWS em Inglês.


Sobre o autor

Madhav Vishnubhatta

 

 

 

 

Tradutor

Daniel Abib é Enterprise Solution Architect 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/