Monitoramento da execução de fluxos de trabalhos (workflows) em arquitetura de micro serviços

Por Daniel Abib, Sr. Customer Solutions Manager, DNB/ISV – LATAM e
Enrico Bergamo, Sr. Specialist Solutions Architect, Serverless – LATAM

A migração de arquiteturas de soluções monolíticas e de plataformas altas (mainframes) para Soluções Modernas que utilizam conceitos de micro serviços já está bastante difundida no mercado e sendo adotada por empresas de todos tamanhos. Os micro serviços proporcionam um desacoplamento de lógica de negócio em pequenas partes autocontidas, possibilitam maneiras de realizar escalonamento sob demanda de determinada parte da solução, maior resiliência da arquitetura e, por consequência, proporcionar um aumento de produtividade das equipes de desenvolvimento e alavancam modelos mais ágeis de entrega com esteiras de CI/CD, visando sempre uma entrega de valor mais rápida e constante para o negócio da empresa.

Com esse novo paradigma de como definir os serviços que atendem as demandas de negócio, verificou-se que a orquestração ou governança dos mesmos precisaria ser feito de uma forma estruturada e que permitisse que diversos micro serviços possam fazer parte de um processo de negócio. Essa gestão das chamadas dos micro serviços poderiam ser realizadas dentro de código fonte ou de forma mais estruturada através de fluxos de trabalhos.

Esta publicação é relacionada ao serviço AWS Step Functions no papel de orquestrador de funções sem servidor (Serverless) que facilita o sequenciamento de funções do AWS Lambda, serviços em execução em Containers (Amazon ECS, Amazon EKS ou Amazon Fargate) e vários outros serviços da AWS em aplicações de negócio. Por meio de uma interface visual, através de comandos em linha (CLI) ou ainda através de SDK, é possível criar, executar e acompanhar o status de uma série de fluxos de trabalho orientados a eventos que mantêm o estado da aplicação, ou seja, a execução de uma máquina de estados de uma forma parametrizada e controlada.

Como benefícios do AWS Step Functions, a sua empresa pode criar fluxos de trabalho visuais que possibilitam a tradução dos requerimentos de negócios para requisitos técnicos, contidos em cada um dos micros serviços existentes na corporação. Também proporcionam uma melhor gestão da resiliência de cada um dos estados através do controle de verificação de execução e reinício de tarefas que falharam para que tenhamos certeza que a lógica de negócio seja executada na ordem e da forma esperada. Como vantagem final, a utilização AWS Step Functions gerencia a lógica de negócio para você, e ainda possibilita que você reaproveite as funções já existentes nos micro serviços atuais da sua empresa.

Com isso, podemos definir e utilizar os fluxos de trabalhos de negócio como forma a estruturar e controlar a execução dos micro serviços que possuem uma divisão segmentada, clara, organizada em torno do negócio da sua empresa, e como comentado anteriormente, proporciona ao time um constante alinhamento no conhecimento de negócio e suas regras, oferendo um reduzido time-to-market e entregando valor de forma continua e mais rápida.

Neste blog post serão detalhados alguns pontos cruciais de como identificar as melhores alternativas de arquiteturas dos fluxos de trabalhos, entender as possiblidades de gerenciamento de erros visando monitorar as execuções destes fluxos de trabalhos e, consequentemente, a execução das chamadas dos serviços da sua empresa.

Portanto, apresentaremos em detalhes:

• Parte I: O que são fluxos de trabalhos utilizando o AWS Step Functions
• Parte II: Diferenças dos fluxos de trabalho padrão e o expresso
• Parte III: Criação de um fluxo de trabalho aninhado
  • Fluxos de trabalho aninhado síncrono
  • Fluxos de trabalho aninhado assíncrono
• Parte IV: Exemplo completo de um fluxo de trabalho aninhado
• Parte V: Mecanismos de monitoramento de fluxos de trabalho
• Parte VI: Custos
• Parte VII: Removendo os serviços criados
• Parte VII: Conclusão

Parte I: O que são fluxos de trabalhos utilizando o AWS Step Functions

O AWS Step Functions permite que você crie um fluxo de trabalho (workflow ou mecanismo de controle de fluxo) baseado em estados usando objetos em formato JSON fáceis de ler, bem como uma interface visual para detalhamento e acompanhamento da execução dos fluxos. Esses objetos, que são especificados usando Linguagem Amazon States, definem uma série de estados e transições de estado, vinculando as saídas de cada estado às entradas dos estados seguintes.

Esse recurso oferece maior flexibilidade e torna o estabelecimento de fluxos de controle em seu aplicativo mais simples para que você possa construir sistemas complexos de processamento em lote, sem ter que projetar a infraestrutura escalável necessária em uma abordagem mais tradicional, já que este é um serviço Serverless da AWS.

O AWS Step Functions também permite criar várias funções de suporte para quando algum passo do fluxo não tiver sua execução bem sucedida. Isso inclui tratamento e roteamento de erros dinâmicos, novas tentativas automáticas e roteamento personalizado com base nas saídas de função.

Como o AWS Step Functions funciona:

Figura 1 – Como funciona o AWS Step Funcions

O primeiro passo é configurar a máquina de estados, ou seja, os passos que serão executados dentro do fluxo do serviço de negócio. Ele possui um estado inicial, um estado ativo (quando em execução) e o próximo estado a ser executado. Um estado ativo recebe uma entrada (input), toma alguma ação, e gera uma saída (output). As transições entre os estados do fluxo de trabalho são baseadas nas saídas e nas regras definidas pelo estado.

Um exemplo simples de um fluxo de trabalho contendo apenas um único passo, utilizando a Linguagem Amazon States é:

Neste JSON de exemplo acima, existe apenas um único estado chamado “Ola Mundo” definido pelo parâmetro “States”, e o fluxos de trabalho se inicia neste único estado definido pelo parâmetro “StartAt”. Ao ser executado, ele chama uma função Lambda definido no parâmetro “Resource” do JSON e finaliza sua execução, indicado pelo parâmetro “End: true”.

O tipo do estado, definido pelo parâmetro “Type”, pode conter as seguintes opções:

Como mencionado anteriormente, o AWS Step Functions pode integrar com algumas das APIs em vários outros serviços da AWS. Acima foi apresentado como usar funções do AWS Lambda (através de sua ARN) em estados de tarefas, mas também podem ser realizados em outros serviços. Alguns serviços particularmente populares que vale a pena mencionar incluem o Amazon ECS, Amazon EKS ou Amazon Fargate, permitindo que você faça o desenvolvimento da lógica de negócio por meio de contêineres, a integração do Amazon SageMaker, que é excelente para gerenciar o estado de seu treinamento de aprendizado de máquina (Machine Learning), e também a capacidade de chamar outros fluxos de trabalhos de AWS Step Functions, o que permite a chamada aninhada de outros fluxos, visando reutilizar a lógica entre fluxos de trabalho chamando outras funções se necessário.

Esses são alguns dos possíveis serviços AWS que podem ser integrados facilmente com o AWS Step Functions:

Figura 2 – Parte dos possíveis serviços de integração do AWS Step Functions

Parte II: Diferenças dos fluxos de trabalho padrão e o expresso

No momento da criação do seu fluxo de trabalho dentro do AWS Step Functions, você precisa definir um tipo Padrão (standard) ou Expresso (express), utilizando a Amazon States Language para a definição dos estados. As execuções da sua máquina de estado têm comportamentos diferentes, dependendo do tipo que você selecionar.

AWS Step Functions padrão (standard)

Os fluxos de trabalhos padrão são ideais para processos de negócio de longa execução, pois são persistidos (duráveis) ​​e auditáveis. Eles podem ser executados por até um ano e você pode recuperar o histórico de execução completo usando as APIs do AWS Step Functions em até 90 dias após a conclusão da execução.

Os fluxos de trabalho padrão utilizam mecanismos que garantem no máximo uma única execução, ou seja, suas tarefas e estados nunca são executados mais de uma vez, a menos que você tenha especificado o comportamento de novas tentativa caso de falha.

As execuções de fluxos de trabalho padrão são cobradas de acordo com o número de transições de estado processadas.

AWS Step Functions expressos (express)

O Fluxos de trabalho expresso é um novo tipo de workflow da AWS Step Functions lançado no Re:Invent de 2019 que orquestra de forma mais econômica (menor custo) os serviços de computação em nuvem com taxas de eventos superiores a 100.000 eventos por segundo.

Os fluxos de trabalho expressos são ideais para cargas de trabalho de processamento de eventos de alto volume, como ingestão de dados IoT, processamento e transformação de dados de streaming e back-ends de aplicativos móveis. Eles podem ter uma duração máxima (tempo de execução) de até cinco minutos. No entanto, os fluxos de trabalho expressos empregam um modelo de execução chamado “pelo menos uma vez”, em que existe a possibilidade de uma execução ser efetuada mais de uma vez.

As execuções dos fluxos de trabalhos expressos são cobradas pelo número de execuções, a duração de cada execução e a memória consumida.

As diferenças básicas dos fluxos de trabalhos padrão e expresso são:

Parte III: Criação de um fluxo de trabalho aninhado

A partir de agosto de 2019 é possível orquestrar diversos fluxos de trabalho dentro do mesmo serviço do AWS Step Functions, conforme anunciado neste blog.

Baseado em regras de negócio complexas ou com diversas interações de micro serviços, fica cada dia mais difícil criar um fluxo de trabalho que atenda por completo a lógica de negócio. Visando evitar repetições, é possível criar pequenos fluxos e estes serem invocados a partir de fluxos de trabalho mais abrangentes, facilitando assim a criação de serviços intermediários, fáceis de criar, testar e alterar de uma forma centralizada. Em outras palavras, utilizando processo de aninhamento de fluxos de trabalho do AWS Step Functions, você pode criar fluxos de trabalho maiores e mais complexos com base em fluxos de trabalho menores e mais simples.

Quando os fluxos de trabalho têm processos recorrentes, como revisão e aprovação humana ou provisionamento de recursos em contas, você pode criar uma biblioteca de componentes básicos modulares e reutilizáveis para acelerar o desenvolvimento. O AWS Step Functions permite alternar e reorganizar módulos de fluxo de trabalho sem personalizar o código. Isso permite montar novos fluxos de trabalho baseados em fluxos de trabalho atuais em alguns minutos.

Você pode separar etapas de fluxos de trabalho de alto nível das etapas de fluxos de trabalho de baixo nível para facilitar o monitoramento e a detecção das origens dos erros em alguns segundos.

O exemplo abaixo mostra uma chamada do fluxo de serviço de trabalho principal (à esquerda). O primeiro passo deste processo é a execução do micro serviço de negócio 1 (utilizado apenas como exemplo). Após esta etapa, é feita uma chamada síncrona do fluxo de trabalho secundário (à direita).

Figura 3 – Chamada síncrona entre dois fluxos de trabalho no AWS Step Functions

Esta execução é considerada síncrona pois o fluxo principal aguarda a execução do fluxo secundário para dar continuidade na sua lógica de negócio. Com isso, o micro serviço 2 só será executado quando a execução dos micros serviços 4 e 5 forem finalizadas. Desta forma é possível mapear qualquer processo de negócio que dependa da execução de um sub-processo para ser considerado finalizado, com sucesso ou falha.

Para execução de fluxos assíncronos, é necessário a utilização de tokens de controle de execução bem como mecanismos de validação de estados (choice) para garantir que o fluxo principal só seja finalizado quando todos os fluxos secundários também estejam completos.

O exemplo a seguir apresenta um fluxo principal que, após a execução do primeiro micro serviço, cria três ramificações de execução. A ramificação à direita realiza a chamada de um novo fluxo de trabalho que, no seu final, atualiza através de um token ou de alguma outra forma de notificação (como SNS, SQS, etc.) que seu trabalho foi finalizado.

Figura 4 – Chamada assíncrona e com execuções em paralelo entre dois fluxos de trabalho no AWS Step Functions

Neste modelo, um processo de validação acontece no fluxo de trabalho principal para verificar se a execução do fluxo secundário se encerrou, e caso ainda não tenha sido finalizada, ele aguarda um intervalo de tempo e novamente volta a fazer a validação. Caso o fluxo de trabalho secundário tenha sido finalizado, o fluxo principal segue sua execução ou é finalizado.

Parte IV: Exemplo completo de um fluxo de trabalho aninhado

O exemplo a seguir mostra uma solicitação de uma compra de um pacote de viagem que contempla a validação dos dados do solicitante (através de um micro serviço em AWS Lambda), realiza execução de um fluxo de trabalho para reservar e efetivar o pagamento do hotel, um segundo fluxo de trabalho para emissão e pagamento de passagem aérea e um último fluxo de trabalho criado para gerenciar a reserva de carro.

Figura 5 – Diagrama de alto nível da solução de reserva de viagem

É possível notar neste exemplo a utilização de um fluxo de trabalho (fluxo de negócio) principal marcado com o número 1, que durante sua execução possui a chamada de um micro serviço de validação dos dados da viagem. Logo após esse passo, o fluxo principal realiza as chamadas de outros fluxos para cada uma das etapas requeridas (2, 3 e 4).

Para cada um dos fluxos de trabalhos aninhados (2, 3 e 4), existe uma lógica particular para atender o serviço de negócio. Para os fluxos 3 e 4, ainda existe a necessidade de ser chamado novamente um fluxo de negócio de pagamento (5), já que esses serviços exigem pagamento no ato da sua contratação, mas o fluxo 4, a lógica de negócio apenas realiza a reserva sem a necessidade de pagamento imediato.

O último fluxo desse exemplo define a lógica (micro serviço) de realizar o pagamento de uma forma genérica (fluxo 5), para que ele possa ser reaproveitado por vários processos de negócio. Para sua lógica estar completa é necessário realizar a invocação de outros micro serviços como validação de dados cadastrais para que o pagamento não seja rejeitado.

Você pode criar e executar o AWS Step Funcions usando o AWS Management Console, AWS CLI, AWS ou AWS CloudFormation. As etapas abaixo explicam como construir um fluxo de trabalho expresso a partir AWS CLI e também será utilizado o AWS Management Console para visualização dos passos realizados via CLI.

1. Setup Básico de Acesso

Passo 1.1: Criando uma conta gratuita AWS ou utilizando sua própria conta

Se você ainda não tem uma conta da AWS com acesso de administrador, acesse o link a seguir e veja como criar a sua conta gratuita: https://aws.amazon.com/pt/getting-started/

Passo 1.2: Criando usuário para acesso via AWS CLI

Depois de ter uma conta AWS, crie um usuário “sfdemo” (nome sugerido – não utilize as aspas) utilizando serviço IAM com acesso de administrador à conta AWS e defina o tipo de acesso programático (primeiro check box)

https://console.aws.amazon.com/iam/home?#/users$new?step=details

Após a criação do usuário, atribua a policy de administrador (AdministratorAccess) para este usuário.

INFORMAÇÃO IMPORTANTE: O acesso de administrador não é recomendado para ambientes de desenvolvimento, testes ou produção, pois permite que este usuário realize todo tipo de serviços dentro da AWS. A criação deste usuário com esta permissão é apenas para demonstração e deve ser evitada sempre que possível.

Valide as informações e confirme as informações do usuário.

O usuário foi criado com sucesso.

Realize o download do arquivo .csv ou anote o Access Key ID e o Secret Access Key

Passo 1.3: Instalando o AWS CLI

A instalação do AWS CLI é dependente de qual sistema operacional (Windows, Linux, macOS, etc.) você está usando na sua máquina. Os links para a instalação do CLI estão disponíveis no seguinte endereço:

https://docs.aws.amazon.com/pt_br/cli/latest/userguide/install-cliv2.html

Passo 1.4: Configurando as credenciais do usuário criado

Depois que os passos de criação de usuário, download (ou nota) das credenciais e instalação do AWS CLI for realizada, é necessário configurar as credenciais. Para isso, basta executar o comando “aws configure” e passar as informações de credencial do seu usuário criado.

O AWS Step está disponível na maioria das Regiões da AWS, e para padronização deste blog, é recomendado utilizar us-east-1 no campo “Default Region”. O campo “Default Format” pode ser deixado em branco ou com o formato json.

2. Iniciando a criação do processo de negócio de Reservar Viagem

Agora que o usuário já está criado e o acesso ao AWS CLI foi configurado, vamos iniciar a criação dos micros serviços e fluxos de negócio que correspondem ao diagrama anteriormente apresentado.

Figura 5 – Diagrama de alto nível da solução de reserva de viagem

Passo 2.1: Criação Roles de execução dos Micro Serviços em AWS Lambda

Para este cenário, utilizaremos 7 micros serviços que já podem estar disponíveis para sua empresa para outros processos de negócio ou podem ser criados a qualquer momento utilizando AWS Lambda ou alguma solução de Containers AWS. São eles:

• Obter Dados da Viagem
• Validar Disponibilidade de Quarto (de hotel)
• Reservar Hotel
• Comprar Passagem aérea
• Reservar Carro
• Validar CPF / CNPJ
• Executar Pagamento

Para que estes micros serviços possam ser executados, não é mandatório mas recomendado criar uma Role (Função) que permita o AWS AWS Lambda a gravar logs no AWS CloudWatch e possamos fazer investigação e análise de logs da solução.

Iremos criar então a Role chamada SFDemoLambdaExecutionRole relacionado ao serviço Principal Lambda. Principal é a entidade (Trust relationship ou serviço) que tem permissão para executar a ação AssumeRole com a seguinte policy:

Para a geração de um arquivo chamado lambdaTrust.json que contenha esta policy (que será utilizada em breve no AWS Cli), digite na linha de comando:

O comando do AWS CLI que realiza a criação desta Role é o seguinte:

aws iam create-role --role-name SFDemoLambdaExecutionRole --assume-role-policy-document "$(cat /tmp/lambdaTrust.json)" --output text --query "Role.Arn" > /tmp/lambdaExecutionRoleArn

Notem que a saída do comando está no formato “text” (utilizando o parâmetro –output) e do resultado do comando precisamos apenas do ARN (filtramos pelo parâmetro –query). Este valor será armazenado no arquivo lambdaExecutionRoleArn.

Como resultado final, a Role que será criada irá ter a seguinte relação de confiança:

Ainda não há nenhuma permissão anexada a esta Role.

Após este passo, será criado uma policy de acesso ao CloudWatch com o seguinte conteúdo:

A geração do arquivo lambdaExecutionRole.json que contem este json é realizada com a execução do seguinte comando:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [\"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\", \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\" ], \"Resource\": \"*\" } ] }" > /tmp/lambdaExecutionRole.json

Para validação deste passo, é possível ver a Role SFDemoLambdaExecutionRole no AWS Management Console, no serviço IAM:

A partir de agora, os micro serviços Lambda que serão criados para este blog poderão ser executados e irão gerar o log no CloudWatch.

Passo 2.2: Criação dos micro serviços

Para a criação dos 7 micros serviços, podemos utilizar o AWS Management Console, criar 7 funções Lambda, copiar e colar todos os códigos em NodeJS. Para facilitar o trabalho e evitar problemas de copiar e colar, o arquivo a seguir contem a definição de todos os micros serviços e seu publicação (deploy) utilizando o AWS CLI.  Faça o download do arquivo, realize a mudança de permissão (chmod) consentindo o script ser executado e posteriormente realizar a chamada do script:

Download do Script de Criação de Fluxos de Serviço

chmod ugo+x ./CriarMicroServicos.sh
./CriarMicroServicos.sh

No AWS Management Console, no serviço de Lambda, será possível ver a existência dos 7 micros serviços criados, conforme a imagem a seguir.

Para verificar o código Lambda que algum dos micro serviços criados, basta clicar no nome e aparecerá a tela de edição das funções Lambda. Por exemplo, o micro serviço de Comprar Passagem Aérea terá a seguinte tela:

Passo 2.4: Criação da Role e inclusão de policies para execução dos fluxos de trabalho

Para que seja possível a criação e execução dos fluxos de trabalho, é necessário criar uma Role associado ao serviço AWS Step Functions e incluir as policies de permissão a escrita no CloudWatch, semelhante aos passos que foram feitos para os micro serviços. Também é necessário a política de execução das funções Lambda que compõem o processo de negócio, ou seja, o AWS Step Functions precisa de uma policy que autoriza a execução de Lambda.

Passo 2.4.1: Criação da Role para execução dos fluxos de trabalho

O comando para gerar um arquivo stateTrust.json contendo esta policy é:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": { \"Service\": \"states.amazonaws.com\"}, \"Action\": \"sts:AssumeRole\"} ] }" > /tmp/statesTrust.json

Para a criação da Role chamada SFDemoStatesExecutionRole utilizando este documento .json gerado anteriormente, o comando AWS CLI é:

aws iam create-role --role-name SFDemoStatesExecutionRole --assume-role-policy-document "$(cat /tmp/statesTrust.json)" --output text --query "Role.Arn" > /tmp/statesExecutionoRoleArn

Notem que a saída do comando está no formato “text” (utilizando o parâmetro –output) e do resultado do comando precisamos apenas do ARN (filtramos pelo parâmetro –query). Este valor será armazenado no arquivo statesExecutionoRoleArn.

Passo 2.4.2: Criação das permissões necessárias para a execução do fluxo de negócio

O AWS Step Functions, em nosso caso, precisa de 2 permissões em outros serviços da AWS. O primeiro é acesso ao CloudWatch para a criação de logs. Para isso, a seguinte policy será gerada:

O comando necessário para criar um arquivo no formato .json contendo esta policy é o seguinte:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"logs:CreateLogGroup\", \"logs:CreateLogStream\", \"logs:PutLogEvents\", \"logs:GetLogDelivery\", \"logs:ListLogDeliveries\", \"logs:UpdateLogDelivery\" ], \"Resource\": [ \"*\"]}]}" > /tmp/statesCloudWhatchLogs.json

Para incluir esta policy na Role SFDemoStatesExecutionRole, precisamos executar o seguinte comando AWS CLI:

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoCloudWatchLogsPolicy --policy-document file:///tmp/statesCloudWhatchLogs.json

O AWS Step Functions irá também realizar chamadas de serviços Lambda, que em nosso cenário simulam os micro serviços da empresa. Para isso, é necessário permitir a chamada de Lambdas com a seguinte policy:

O comando necessário para criar um arquivo no formato .json contendo esta policy é o seguinte:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"lambda:InvokeAsync\", \"lambda:InvokeFunction\"  ], \"Resource\": [\"*\"]}]}" > /tmp/statesRunLambdaBasicPolicy.json

Para também incluir esta policy na Role SFDemoStatesExecutionRole (assim como fizemos para a policy de CloudWatch), precisamos executar o seguinte comando AWS CLI:

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoLambdaBasicExecutionPolicy --policy-document file:///tmp/statesRunLambdaBasicPolicy.json

A última policy que é necessária é a permissão de executar, descrever e parar as execuções de máquina de estados do AWS Step Functions e também incluir eventos no EventBridge. Para isso, a seguinte policy precisa estar presente nesta Role:

O comando necessário para criar um arquivo no formato .json contendo esta policy é o seguinte:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"states:StartExecution\", \"states:DescribeExecution\", \"states:StopExecution\" ], \"Resource\": [\"*\"]}, { \"Effect\": \"Allow\", \"Action\": [ \"events:PutTargets\", \"events:PutRule\", \"events:DescribeRule\" ], \"Resource\": [\"*\"]}]}" > /tmp/statesExecutionPolicy.json

Para incluir esta ultima policy necessária para este blog na Role SFDemoStatesExecutionRole, precisamos executar o seguinte comando AWS CLI:

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesExecutionPolicy --policy-document file:///tmp/statesExecutionPolicy.json

Neste momento, a Role SFDemoStatesExecutionRole terá três policies:

Conforme o diagrama proposto do processo de negócio, agora é necessário criar os 4 AWS Step Functions contendo os fluxos secundários (Fazer Pagamento, Reservar Hotel, Reservar Passagem e Reservar Carro) e também o fluxo de trabalho principal (Reservar Viagem) que irá chamar estes fluxos de trabalho aninhados.

A criação de um fluxo de trabalho pode ser feito via AWS Management console, utilizando a linguagem ASL (Amazon States Language) através de AWS CLI, AWS CloudFormation ou de SDK.

Esta é a visão de criação de um novo fluxo de trabalho utilizando a console. Note que à medida que os estados estão sendo criados dentro do quadro Definitions (à esquerda), é possível ter uma apresentação gráfica do fluxo no diagrama ao lado (à direita).

Para facilitar o trabalho e evitar problemas de copiar e colar, o arquivo a seguir contem a definição de todos fluxos de trabalho (AWS Step Functions) e seu publicação (deploy) utilizando o AWS CLI.  Faça o download do arquivo, realize a mudança de permissão (chmod) consentindo o script ser executado e posteriormente realizar a chamada do script:

O script de criação dos fluxos está disponível neste arquivo, e os passos para sua execução são apresentados abaixo.

Download do Script de Criação de Fluxos de Trabalho

chmod ugo+x ./CriarFluxoTrabalho.sh
./CriarFluxoTrabalho.sh

Para visualizar cada um dos fluxos de trabalho, basta clicar no nome do fluxo e depois em edit e ver o json que define os estados do fluxo e a representação gráfica deste processo.

O fluxo de trabalho principal (Reservar Viagem) terá os estados listados a seguir. Nota-se que o fluxo é composto por 4 etapas (estados) chamados de “Validar Dados da Viagem”, “Reservar Hotel”, “Reservar passagem” e “Reservar Carro”.

Destes 4 passos, o primeiro é a chamada simples de um micro serviço Lambda e os outros 3 estados são chamadas de outros fluxos de trabalho em AWS Step Funcions.

Com estes passos já temos todo o fluxo de trabalho (principal e secundário), micro serviços e permissões para realizar o processo de negócio.

Parte VI: Mecanismos de monitoramento de fluxos de trabalhos

Com a AWS, você pode melhorar a agilidade dos negócios enquanto mantém o controle de governança. A AWS fornece soluções de monitoramento e observabilidade para que você possa entender e melhorar a integridade, o desempenho e a disponibilidade de seus recursos na AWS e no local.

Alternativa 1 – Utilizando o AWS Management Console do Step Functions

Se existe a necessidade de utilizar fluxos de trabalho aninhados em seu processo de negócio, é necessário planejar mecanismos de controle de execução e investigações de incidentes que esses diversos fluxos podem gerar. Como não já um ponto único de logs para todos os micro serviços ou fluxos de trabalho, tento em vista que cada micro serviço tem seu própria LogGroup e também são executados por diversos serviços de negócio, precisamos ter alternativas para facilitar a análise de execução e correções quando necessário.

A maneira mais simples de acompanhar a execução de um fluxo de trabalho é através da console do AWS Step Funcions. Nesta console é possível ver todas as execuções em andamento ou já finalizadas, e se a execução foi correta ou com erro.

É possível iniciar uma nova execução através do botão “Start Execution” no AWS Management Console ou através do CLI com o seguinte comando:

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

Ao clicar em alguma das execuções do serviço, é possível validar quais processos / passos foram executados, os parâmetros de entrada e saída de cada estado e o resultado final do processo de negócio. Por exemplo, selecionando uma das execuções de nosso processo de negócio principal, é possível ver os 4 passos executados (um micro serviço e 3 processos secundários) na cor verde, mostrando que para esta execução todo o processo aconteceu sem falhas.

Mas, caso seja necessário investigar os fluxos de trabalho secundários ou ter uma visão mais completa da execução, o console do AWS Step Functions pode não proporcionar esta visão detalhada.

Alternativa 2 – Utilizar o AWS X-Ray

Para ter uma visibilidade de todos os passos executados por um fluxo de trabalho, é possível habilitar o rastro (trace) utilizando o AWS X-Ray. O AWS X-Ray ajuda desenvolvedores a analisar e depurar aplicações distribuídas de produção, como as criadas usando uma arquitetura de micro serviços. Com ele é possível entender também a performance de aplicações e de seus serviços subjacentes para identificar e solucionar problemas e erros ou ainda impactos em execuções demoradas. O AWS X-Ray disponibiliza uma visualização completa sobre as solicitações, conforme elas percorrem o processo de negócio, além de mostrar um mapa dos componentes aninhados, foco deste blog.

Para habilitar o X-Ray em nosso exemplo, precisamos dar permissões de chamadas do serviço X-Ray às funções em Lambda através de uma policy e também adicionar mais uma policy similar na Role que está associada aos nossos fluxos de trabalho.

Esta policy para as funções Lambda terá a seguinte estrutura:

A criação deste arquivo no formato json pode ser realizada executando o seguinte comando:

echo "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [\"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\" ], \"Resource\": \"*\" } ] }" > /tmp/lambdaExecutionRoleXRay.json

Para incluir esta policy de permissão ao serviço X-Ray na Role SFDemoLambdaExecutionRole, precisamos executar o seguinte comando AWS CLI:

aws iam put-role-policy --role-name SFDemoLambdaExecutionRole --policy-name SFDemoLambdaBasicExecution --policy-document file:///tmp/lambdaExecutionRoleXray.json

De forma similar, os fluxos de negócios que foram construídos utilizando o AWS Step Functions precisam ter acesso ao serviço X-Ray. A policy para esta permissão é:

A criação deste arquivo no formato json pode ser realizada executando o seguinte comando:

echo "{\"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": [ \"xray:PutTraceSegments\", \"xray:PutTelemetryRecords\", \"xray:GetSamplingRules\", \"xray:GetSamplingTargets\" ], \"Resource\": [\"*\"]}]}" > /tmp/statesXrayPolicy.json

Para incluir esta policy de permissão ao serviço X-Ray na Role SFDemoStatesExecutionRole, precisamos executar o seguinte comando AWS CLI:

aws iam put-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesXrayPolicy --policy-document file:///tmp/statesXrayPolicy.json

Para ativar o X-Ray nas funções Lambda que já existem, é possível fazer via AWS Management Console ou através do AWS CLI. O comando de AWS CLI para atualizar todos os micros serviços deste blog é:

aws lambda update-function-configuration --function-name SFDemoValidaCPF                            --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoExecutarPagamento            --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoValidarDisponibilidadeQuarto --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoReservarHotel                --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoComprarPassagemAerea         --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoReservarCarro                --tracing-config Mode=Active --output text --query "LastUpdateStatus"
aws lambda update-function-configuration --function-name SFDemoValidarDadosDaViagem         --tracing-config Mode=Active --output text --query "LastUpdateStatus"

De forma similar, para atualizar os fluxos de negócio para gerar informações para o serviço X-Ray, podemos utilizar o AWS Management Console ou via AWS CLI. Os comandos para atualizar os 5 fluxos de negócios do escopo deste nosso blog é:

aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarPassagemArn)" --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarHotelArn)"    --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarCarroArn)"    --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineFazerPagamentoArn)"   --tracing-configuration enabled=true --output text --query "updateDate"
aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)"   --tracing-configuration enabled=true --output text --query "updateDate"

Com as permissões definidas (policies anexadas as Roles) e funções Lambda / fluxos de negócio no AWS Step Functions atualizados, precisamos executar um novo fluxo de trabalho principal mais uma vez para poder visualizar as informações no X-Ray.

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

A partir deste momento, os dados da última execução do fluxo de negócio já estão carregados na AWS. Usando o AWS Management Console, no serviço AWS X-Ray, no menu a esquerda aonde está o item “Service Map” é possível analisar toda a execução da reserva de viagem

Na console do AWS X-Ray é possível ver todos os serviços chamados, o tempo de execução de cada um deles e os problemas caso ocorram. O AWS X-Ray rastreia as solicitações do usuário enquanto percorrem todo o fluxo de negócio, independente se exista apenas um único fluxo ou fluxos aninhados como em nosso exemplo deste blog. Ele agrega os dados gerados por serviços e recursos individuais que compõem o fluxo de negócio, oferecendo uma visão completa do seu desempenho.

Para deixar mais claro como são percorridos o fluxo principal e os fluxos aninhados, na imagem a seguir foi destacado em roxo o fluxo de trabalho principal, em vermelho os fluxos secundários e também o fluxo terciário de execução de pagamento em azul.

Além desta visualização de encadeamento de serviços, é possível ter uma análise de tempo de execução de cada parte da solução utilizando a função “Traces” do menu a esquerda, logo abaixo do menu “Service Map”.

Nesta execução, o fluxo principal teve a duração de 846 ms, que é a agregação do tempo de sua execução e também dos outros fluxos de negócio. A execução da função Lambda de validação dos dados de viagem durou 380 ms, a execução do fluxo de negócio reservar hotel durou 136 ms e assim por diante.

Com essa análise é possível identificar pontos de gargalo (queda de performance de execução) e atuar de forma a resolver o problema para que não afete a experiência final do usuário ou atrase os processos de negócio.

Alternativa 3 – Utilizar o CloudWatch Logs para visão completa da execução dos fluxos de negócio

Visando complementar as soluções de monitoramento e observabilidade da solução, é possível incluir logs do fluxo de processo principal e todos os seus passos. O CloudWatch Logs permite centralizar os logs de todos os sistemas, aplicativos e serviços da AWS que você usa em um único serviço altamente escalável. Em seguida, você pode facilmente visualizá-los, pesquisá-los por padrões ou códigos de erro específicos, filtrá-los com base em campos específicos ou arquivá-los de forma segura para análise futura. O CloudWatch Logs permite que você veja todos os seus logs, independentemente da origem, como um fluxo único e consistente de eventos ordenados por tempo, e você pode consultá-los e classificá-los com base em outras dimensões, agrupá-los por campos específicos, criar computações personalizadas com uma linguagem de consulta eficiente e visualizar dados de log em painéis.

O primeiro passo que vamos fazer é criar um novo LogGroup para o fluxo de trabalho principal. A criação deste LogStream é através do seguinte comando AWS CLI:

aws logs create-log-group --log-group-name SFDemoReservarViagemPRINCIPAL

Para poder ter acesso a ARN do LogGroup criado, é necessário executar o seguinte comando no AWS CLI:

aws logs describe-log-groups --log-group-name-prefix SFDemoReservarViagemPRINCIPAL --output text --query 'logGroups[*].arn' > /tmp/SFDemoReservarViagemPRINCIPALLogGroup

O último passo necessário e atualizar o fluxo de trabalho principal definindo o nível de log e qual LogGroup deve ser utilizado. Para este blog, utilizaremos o nível ALL (todos os dados de log). O comando AWS CLI para fazer esta atualização é:

aws stepfunctions update-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --logging-configuration "{\"level\": \"ALL\", \"includeExecutionData\": true, \"destinations\": [ { \"cloudWatchLogsLogGroup\": { \"logGroupArn\": \"$(cat /tmp/SFDemoReservarViagemPRINCIPALLogGroup)\" } } ] } " --output text --query "updateDate"

Para que seja gerado alguma informação no CloudWatch Logs, vamos fazer uma nova execução do fluxo de trabalho principal.

aws stepfunctions start-execution --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)" --input "{ \"Origem\": \"Sao Paulo\", \"Destino\": \"Nova Iorque\", \"Data\": \"15/04/2022\", \"NumeroPessoas\": 2, \"ReservarCarro\": true }"

No AWS Management Console, no serviço CloudWatch, no menu a esquerda dentro da opção de Logs e Log Groups, poderemos ver todos os LogGroup criados.

Selecionando o LogGroup SFDemoReservarViagemPRINCIPAL, podemos ver todas as execuções do fluxo principal. Neste momento, deve haver apenas 1 log de execução, mas caso o fluxo de trabalho tenha sido executado outras vezes, novas entradas estarão presentes.

O Log irá conter as chamadas de todos os estados, as execuções de todas as tarefas (tasks) e as chamadas de todos os outros fluxos de trabalhos da solução, dando uma visibilidade dos parâmetros de entrada e saída de cada uma das etapas.

Parte VI: Custos

Neste blog utilizamos IAM para definições de Roles e Policies, AWS Lambda para execução de micro serviços, AWS Step Functions para definição de fluxos de trabalho (principal e aninhados), AWS X-Ray para e CloudWatch observabilidade e logs. Existe um nível gratuito para cada um deles, mas de forma genérica é interessante consultar a página da AWS para consultar os custos de cada serviços, pois dependendo da utilização pode haver variações.

Segue uma tabela com o link para o modelo de precificação e também a descrição resumida do nível gratuito de cada serviço.

Parte VII: Removendo os serviços criados

Neste blog desenvolvemos micro serviços em AWS Lambda e fluxos de trabalho utilizando o AWS Step Functions. Para proporcionar acesso, foram criadas 2 Roles e algumas policies. Também foi criado automaticamente alguns LogGroups para os 7 micros serviços em Lambda e criamos de uma forma explicita um LogGroup para o fluxo de trabalho principal de reservar viagem. Para remover estes serviços, seguem os comandos em AWS CLI.

Policy e Role para o AWS Lambda:

aws iam delete-role-policy --role-name SFDemoLambdaExecutionRole --policy-name SFDemoLambdaBasicExecution

aws iam delete-role --role-name SFDemoLambdaExecutionRole

Serviços AWS Lambda:

aws lambda delete-function --function-name SFDemoValidaCPF

aws lambda delete-function --function-name SFDemoExecutarPagamento

aws lambda delete-function --function-name SFDemoValidarDisponibilidadeQuarto

aws lambda delete-function --function-name SFDemoReservarHotel

aws lambda delete-function --function-name SFDemoComprarPassagemAerea

aws lambda delete-function --function-name SFDemoReservarCarro

aws lambda delete-function --function-name SFDemoValidarDadosDaViagem

Policy e Role para o AWS Step Functions:

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesXrayPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoLambdaBasicExecutionPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoStatesExecutionPolicy

aws iam delete-role-policy --role-name SFDemoStatesExecutionRole --policy-name SFDemoCloudWatchLogsPolicy


aws iam delete-role --role-name SFDemoStatesExecutionRole

Fluxo de trabalho no AWS Step Functions:

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineFazerPagamentoArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarHotelArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarPassagemArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarCarroArn)"

aws stepfunctions delete-state-machine --state-machine-arn "$(cat /tmp/stateMachineReservarViagemArn)"

Logs no CloudWatch:

aws logs delete-log-group --log-group-name SFDemoReservarViagemPRINCIPAL

for lg in $(aws logs describe-log-groups --query "logGroups[?logGroupName | contains(@, 'aws/lambda/sumologic')].logGroupName" --output text); do

aws logs delete-log-group --log-group-name "$lg";

done;

Parte VIII: Conclusão

Muitos clientes já estão usando os fluxos de trabalho (AWS Step Functions) da AWS para orquestrar cargas de trabalho auditáveis de longa ou curta duração (padrão ou expresso). A adição de fluxos de trabalho aninhados implica em uma necessidade maior de controle de processos e execuções, mas com a utilização do AWS Management Console dentro do AWS Step Functions, do X-Ray e do CloudWatch é possível ter um acompanhamento fim a fim do processo de negócio e também dar ferramentas para os desenvolvedores analisar a performance e corrigir problemas que podem aparecer durante a construção da solução.

Sobre os autores

Daniel Abib é Gerente de Soluções para Clientes na AWS, com mais de 20 anos trabalhando gestão de projetos, arquiteturas de aplicaçõeds, desenvolvimento de sistemas, micro serviços, serverless e segurança. Atua apoiando clientes Enterprise, ajudando em sua jornada para a nuvem.

Enrico é Arquiteto de Soluções especialista em Serverless na AWS para a América Latina, e atua auxiliando clientes de diversos segmentos em suas jornadas de modernização de aplicações na nuvem. Com mais de 10 anos de experiência em Arquitetura e Desenvolvimento de Sistemas, e DevOps, Enrico atuou diretamente com diversas empresas na definição, implementação, e implantação de diversas soluções corporativas.