Práticas recomendadas do Step Functions

Gerenciando o estado e transformando dados

Recentemente, o Step Functions adicionou variáveis JSONata para gerenciar dados de estado e transformação.

Saiba mais sobre como transmitir dados com variáveis e transformar dados com JSONata.

Os tópicos a seguir são as práticas recomendadas para ajudar você a gerenciar e otimizar os fluxos de trabalho do Step Functions.

Otimizar os custos usando fluxos de trabalho expressos

O Step Functions determina os preços dos fluxos de trabalho Padrão e Expressos com base no tipo de fluxo de trabalho que você usa para criar máquinas de estado. Para otimizar o custo dos fluxos de trabalho de tecnologia sem servidor, você pode seguir uma ou ambas as seguintes recomendações:

Para obter informações sobre como a escolha de um tipo de fluxo de trabalho Padrão ou Expresso afeta o faturamento, consulte Preços do AWS Step Functions.

Fluxos de trabalho expressos aninhados em fluxos de trabalho padrão

O Step Functions executa fluxos de trabalho que têm uma duração e um número de etapas finitos. Alguns fluxos de trabalho podem concluir a execução em um curto período. Outros podem exigir uma combinação de fluxos de high-event-rate trabalho e de longa duração. Com o Step Functions, você pode criar fluxos de trabalho grandes e complexos a partir de vários fluxos de trabalho menores e mais simples.

Por exemplo, para criar um fluxo de trabalho de processamento de pedidos, você pode incluir todas as ações não idempotentes em um fluxo de trabalho Padrão. Isso pode incluir ações, como aprovação de pedidos por meio de interação humana e processamento de pagamentos. Em seguida, você pode combinar uma série de ações idempotentes, como enviar notificações de pagamento e atualizar o estoque de produtos, em um fluxo de trabalho expressoo. Você pode aninhar esse fluxo de trabalho expressoo no fluxo de trabalho Padrão. Neste exemplo, o fluxo de trabalho Padrão é conhecido como máquina de estado pai. O fluxo de trabalho expressoo aninhado é conhecido como máquina de estado filha.

Converter fluxos de trabalho padrão em fluxos de trabalho expressos

Você pode converter fluxos de trabalho Padrão existentes em fluxos de trabalho expressoos se eles atenderem aos seguintes requisitos:

• O fluxo de trabalho deve concluir a execução em cinco minutos.

• O fluxo de trabalho está em conformidade com um modelo at-least-oncede execução. Isso significa que cada etapa no fluxo de trabalho pode ser executada mais de uma vez.

• O fluxo de trabalho não usa os padrões de integração de serviços .waitForTaskToken ou .sync.

Importante

Os fluxos de trabalho expressos usam o Amazon CloudWatch Logs para registrar históricos de execução. Você incorrerá em custos adicionais ao usar o CloudWatch Logs.

Para converter um fluxo de trabalho Padrão em um fluxo de trabalho expressoo usando o console

1. Abra o console do Step Functions.

2. Na página Máquinas de estado, escolha uma máquina de estado do tipo Padrão para abri-la.

   dica

   Na lista suspensa Qualquer tipo, escolha Padrão para filtrar a lista de máquinas de estado e visualizar somente fluxos de trabalho Padrão.

3. Escolha Copiar para novo.

   O Workflow Studio é aberto no Modo de design que exibe o fluxo de trabalho da máquina de estado que você selecionou.

4. (Opcional) Atualize o design do fluxo de trabalho.

5. Especifique um nome para a máquina de estado. Para fazer isso, escolha o ícone de edição ao lado do nome padrão da máquina de estado de MyStateMachine. Em seguida, em Configuração da máquina de estado, insira um nome na caixa Nome da máquina de estado.

6. (Opcional) Em Configuração da máquina de estado, especifique outras configurações do fluxo de trabalho, como o tipo de máquina de estado e a função de execução.

   Certifique-se de que, para Tipo, você escolha Expresso. Mantenha todas as outras seleções padrão nas Configurações da máquina de estado.

   nota

   Se você estiver convertendo um fluxo de trabalho padrão definido anteriormente em AWS CDKou AWS SAM, você deverá alterar o valor Type e o Resource nome.

7. Na caixa de diálogo Confirmar criação do perfil, selecione Confirmar para continuar.

   Você também pode escolher Exibir configurações do perfil para voltar às Configurações da máquina de estado.

   nota

   Se você excluir a IAM função criada pelo Step Functions, o Step Functions não poderá recriá-la posteriormente. Da mesma forma, se você modificar a função (por exemplo, removendo Step Functions dos principais na IAM política), o Step Functions não poderá restaurar suas configurações originais posteriormente.

Para obter mais informações sobre as melhores práticas e diretrizes ao gerenciar a otimização de custos para seus fluxos de trabalho, consulte Criação de fluxos de trabalho econômicos AWS Step Functions.

Marcar máquinas de estado e atividades no Step Functions

AWS Step Functions suporta a marcação de máquinas de estado (tanto Standard quanto Express) e atividades. As tags podem ajudá-lo a rastrear e gerenciar seus recursos e fornecer melhor segurança em suas AWS Identity and Access Management (IAM) políticas. Depois de marcar os recursos do Step Functions, você pode gerenciá-los com o. AWS Resource Groups Para saber mais, consulte o Guia do usuário do AWS Resource Groups.

Para autorização baseada em tags, os recursos de execução da máquina de estado, conforme mostrado no exemplo a seguir, herdam as tags associadas a uma máquina de estado.

arn:<partition>:states:<Region>:<account-id>:execution:<StateMachineName>:<ExecutionId>

Quando você chama DescribeExecutionou outra APIs na qual você especifica o recurso de execuçãoARN, o Step Functions usa tags associadas à máquina de estado para aceitar ou negar a solicitação enquanto executa a autorização baseada em tags. Isso ajuda você a permitir ou negar acesso às execuções no nível da máquina de estado.

Para revisar as restrições relacionadas à marcação de recursos, consulte Restrições relacionadas à marcação.

Marcação de alocação de custo

Você pode usar etiquetas de alocação de custos para identificar a finalidade de uma máquina estadual e refletir essa organização em sua AWS fatura. Inscreva-se para receber a fatura AWS da sua conta e incluir as chaves e valores da tag. Consulte Setting Up a Monthly Cost Allocation Repor no Guia do usuário do AWS Billing para saber detalhes sobre como configurar relatórios.

Por exemplo, é possível adicionar tags que representam o centro de custos e o objetivo dos recursos do Step Functions, conforme o seguinte:

Recurso	Chave	Valor
StateMachine1	Cost Center	34567
	Application	Image processing
StateMachine2	Cost Center	34567
	Application	Rekognition processing

Marcação para segurança

O IAM oferece suporte para controlar o acesso a recursos com base em tags. Para controlar o acesso com base em tags, forneça informações sobre as tags de recurso no elemento de condição de uma política do IAM.

Por exemplo, é possível restringir o acesso a todos os recursos do Step Functions que incluam uma tag com a chave environment e o valor production.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "states:TagResource",
                "states:DeleteActivity",
                "states:DeleteStateMachine",
                "states:StopExecution"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {"aws:ResourceTag/environment": "production"}
            }
        }
    ]
}

Para obter mais informações, consulte Controlando o acesso usando tags no Guia IAM do usuário.

Gerenciar tags no console do Step Functions

É possível visualizar e gerenciar tags para as máquinas de estado no console do Step Functions. Na página Details (Detalhes) de uma máquina de estado, selecione Tags.

Gerenciando tags com Step Functions API Actions

Para gerenciar tags usando o Step FunctionsAPI, use as seguintes API ações:

• ListTagsForResource

• TagResource

• UntagResource

Usar tempos limite para evitar o travamento de execuções do fluxo de trabalho do Step Functions

Por padrão, a Amazon States Language não especifica tempos limite para definições de máquinas de estado. Sem um tempo limite explícito, o Step Functions frequentemente se baseia somente em uma resposta de um operador de atividade para saber que uma tarefa foi concluída. Se algo der errado e o campo TimeoutSeconds não estiver especificado para um estado Activity ou Task, uma execução ficará travada, aguardando uma resposta que nunca chegará.

Para evitar essa situação, ao criar uma Task em sua máquina de estado, especifique um tempo limite razoável. Por exemplo:

"ActivityState": {
  "Type": "Task",
  "Resource": "arn:aws:states:us-east-1:123456789012:activity:HelloWorld",
  "TimeoutSeconds": 300,
  "Next": "NextState"
}

Se você usar um retorno de chamada com um token de tarefa (. waitForTaskToken), recomendamos que você use heartbeats e adicione o HeartbeatSeconds campo na sua definição de Task estado. Você pode definir HeartbeatSeconds para ser menor que o tempo limite da tarefa, de modo que, se o seu fluxo de trabalho falhar com um erro de heartbeat, você saberá que isso se deve à falha da tarefa, e não ao fato de a tarefa demorar muito para ser concluída.

{
  "StartAt": "Push to SQS",
  "States": {
    "Push to SQS": {
      "Type": "Task",
      "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
      "HeartbeatSeconds": 600,
      "Parameters": {
        "MessageBody": { "myTaskToken.$": "$$.Task.Token" },
        "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/push-based-queue"
      },
      "ResultPath": "$.SQS",
      "End": true
    }
  }
}

Para ver mais informações, consulte Estado de tarefa do fluxo de trabalho na documentação da Amazon States Language.

nota

Você pode definir um tempo limite para sua máquina de estado usando o campo TimeoutSeconds na definição da Amazon States Language. Para obter mais informações, consulte Estrutura da máquina de estado na Amazon States Language para fluxos de trabalho do Step Functions.

Usando o Amazon S3 ARNs em vez de transmitir grandes cargas em Step Functions

As execuções que transmitem grandes cargas de dados entre os estados podem ser encerradas. Se os dados que você está passando entre estados puderem crescer para mais de 256 KiB, use o Amazon Simple Storage Service (Amazon S3) para armazenar os dados e analise o Amazon Resource Name ARN () do bucket no parâmetro para obter o nome do bucket e Payload o valor da chave. Como alternativa, ajuste a implementação para passar cargas menores em suas execuções.

No exemplo a seguir, uma máquina de estado passa a entrada para uma AWS Lambda função, que processa um JSON arquivo em um bucket do Amazon S3. Depois de executar essa máquina de estado, a função Lambda lê o conteúdo do JSON arquivo e retorna o conteúdo do arquivo como saída.

Criar a função do Lambda

A função Lambda a seguir chamada pass-large-payload lê o conteúdo de um JSON arquivo armazenado em um bucket específico do Amazon S3.

nota

Depois de criar essa função Lambda, certifique-se de fornecer à função a permissão apropriada para ler a partir de um bucket do Amazon S3. IAM Por exemplo, anexe a ReadOnlyAccess permissão do AmazonS3 à função do Lambda.

import json
import boto3
import io
import os

s3 = boto3.client('s3')

def lambda_handler(event, context):
    event = event['Input']
    final_json = str()
    
    s3 = boto3.resource('s3')
    bucket = event['bucket'].split(':')[-1]
    filename = event['key']
    directory = "/tmp/{}".format(filename)
    
    s3.Bucket(bucket).download_file(filename, directory)
    
    with open(directory, "r") as jsonfile:
    
        final_json = json.load(jsonfile)
    
    os.popen("rm -rf /tmp")
    
    return final_json

Criar a máquina de estado

A máquina de estado a seguir invoca a função do Lambda que você criou anteriormente.

{  
   "StartAt":"Invoke Lambda function",
   "States":{  
      "Invoke Lambda function":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:us-east-2:123456789012:function:pass-large-payload",
            "Payload":{  
               "Input.$":"$"
            }
         },
         "OutputPath": "$.Payload",
         "End":true
      }
   }
}

Em vez de passar uma grande quantidade de dados na entrada, você pode salvar esses dados em um bucket do Amazon S3 e passar o Amazon Resource Name (ARN) do bucket no Payload parâmetro para obter o nome do bucket e o valor da chave. Sua função Lambda pode então usar isso ARN para acessar os dados diretamente. Veja a seguir um exemplo de entrada para uma execução de máquina de estado, onde os dados estão armazenados em data.json em um bucket do Amazon S3 denominado amzn-s3-demo-large-payload-json.

{
  "key": "data.json",
  "bucket": "arn:aws:s3:::amzn-s3-demo-large-payload-json"
}

Iniciar novas execuções para evitar atingir a cota de histórico no Step Functions

AWS Step Functions tem uma cota fixa de 25.000 entradas no histórico de eventos de execução. Quando uma execução atinge 24.999 eventos, ela aguarda a ocorrência do próximo evento.

• Se o número do evento 25 mil for ExecutionSucceeded, a execução será concluída com êxito.

• Se o número do evento 25 mil não for ExecutionSucceeded, o evento ExecutionFailed será registrado e a execução da máquina de estado falhará por ter atingido o limite do histórico

Para evitar atingir essa cota em execuções de longa duração, você pode tentar uma das seguintes soluções alternativas:

• Usar o estado Mapa no modo Distribuído. Nesse modo, o estado Map executa cada iteração como uma execução de fluxo de trabalho secundário, o que permite um processamento simultâneo de até 10 mil execuções paralelas de fluxo de trabalho secundário. Cada execução de fluxo de trabalho secundário tem seu próprio histórico de execução separado do fluxo de trabalho principal.

• Iniciar uma nova execução de máquina de estado diretamente do estado Task de uma execução em andamento. Para iniciar essas execuções de fluxo de trabalho aninhadas, use a StartExecution API ação do Step Functions na máquina de estado pai junto com os parâmetros necessários. Para obter mais informações sobre o uso de fluxos de trabalho aninhados, consulte Iniciar execuções de fluxo de trabalho usando um estado de tarefa no Step Functions ou Usando a API ação Step Functions para continuar um novo tutorial de execução.

  dica

  Para implantar um exemplo de fluxo de trabalho aninhado em seu Conta da AWS, consulte o Módulo 13 - Fluxos de trabalho expressos aninhados.

• Implemente um padrão que use uma AWS Lambda função que possa iniciar uma nova execução de sua máquina de estado para dividir o trabalho contínuo em várias execuções de fluxo de trabalho. Para mais informações, consulte o tutorial Usar uma função do Lambda para prosseguir com uma nova execução no Step Functions.

Processar exceções transitórias do serviço Lambda

AWS Lambda ocasionalmente, podem ocorrer erros transitórios de serviço. Nesse caso, a invocação do Lambda resulta em um erro 500, como ClientExecutionTimeoutException, ServiceException, AWSLambdaException ou SdkClientException. Como uma prática recomendada, lide com essas exceções de maneira proativa em sua máquina de estado para executar Retry da invocação da função do Lambda ou para executar Catch do erro.

Erros do Lambda são relatados como Lambda.ErrorName. Para repetir um erro de exceção do serviço Lambda;, você pode usar o código Retry a seguir.

"Retry": [ {
   "ErrorEquals": [ "Lambda.ClientExecutionTimeoutException", "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException"],
   "IntervalSeconds": 2,
   "MaxAttempts": 6,
   "BackoffRate": 2
} ]

nota

Os erros não tratados no Lambda são relatados como Lambda.Unknown na saída do erro. Isso inclui out-of-memory erros e tempos limite de função. Você pode combinar com Lambda.Unknown, States.ALL ou States.TaskFailed para lidar com esses erros. Quando o Lambda atinge o número máximo de invocações, o erro é Lambda.TooManyRequestsException. Para ter mais informações sobre os erros Handled e Unhandled do Lambda, consulte FunctionError no Guia do desenvolvedor do AWS Lambda.

Para obter mais informações, consulte:

• Repetir após um erro

• Tratar condições de erro usando uma máquina de estado Step Functions

• Erros de invocação do Lambda

Evitar latência ao fazer uma sondagem de tarefas de atividade

Foi GetActivityTask API projetado para fornecer taskTokenexatamente uma vez. Se um taskToken é descartado ao se comunicar com um operador de atividade, várias solicitações GetActivityTask podem ser bloqueadas por 60 segundos de espera por uma resposta até que GetActivityTask expire.

Se você tem apenas um pequeno número de sondagens aguardando uma resposta, é possível que todas as solicitações sejam colocadas em fila depois da solicitação bloqueada e interrompidas. No entanto, se você tiver um grande número de enquetes pendentes para cada atividade Amazon Resource Name (ARN) e alguma porcentagem de suas solicitações estiver esperando, muitas outras ainda poderão receber uma taskToken e começar a processar o trabalho.

Para sistemas de produção, recomendamos pelo menos 100 enquetes abertas por atividade ARN em cada momento. Se uma sondagem é bloqueada, e uma parte dessas sondagens é colocada em fila depois dela, há várias outras solicitações que receberão um taskToken para processar trabalhos enquanto a solicitação GetActivityTask está bloqueada.

Para evitar esses tipos de problemas de latência ao fazer uma sondagem de tarefas:

• Implemente seus agentes de sondagem como threads separados do trabalho na sua implementação do operador de atividade.

• Tenha pelo menos 100 enquetes abertas por atividade em cada ARN momento.

  nota

  Escalar para 100 enquetes abertas por pessoa ARN pode ser caro. Por exemplo, a pesquisa de 100 funções Lambda por sondagem ARN é 100 vezes mais cara do que ter uma única função Lambda com 100 segmentos de pesquisa. Para reduzir a latência e minimizar os custos, use uma linguagem de E/S assíncrona e implemente vários threads de sondagem por operador. Para obter um operador de atividade de exemplo em que os threads do agente de sondagem são separados de threads do trabalho, consulte Exemplo: operador de atividade em Ruby.

Para obter mais informações sobre atividades e operadores de atividade, consulte Saiba mais sobre atividades no Step Functions..

CloudWatch Registra os limites de tamanho da política de recursos

Quando você cria uma máquina de estado com registro ou atualiza uma máquina de estado existente para habilitar o registro, o Step Functions deve atualizar sua política de recursos de CloudWatch registros com o grupo de registros que você especificar. CloudWatch As políticas de recursos de registros estão limitadas a 5.120 caracteres.

Quando o CloudWatch Logs detecta que uma política se aproxima do limite de tamanho, o CloudWatch Logs ativa automaticamente o registro para grupos de registros que começam com/aws/vendedlogs/.

Você pode prefixar os nomes dos seus grupos de CloudWatch registros de registros /aws/vendedlogs/ para evitar o limite de tamanho da política de recursos de CloudWatch registros. Se você criar um grupo de logs no console do Step Functions, o nome do grupo de logs sugerido já terá o prefixo /aws/vendedlogs/states.

CloudWatch O Logs também tem uma cota de 10 políticas de recursos por região e por conta. Se você tentar ativar o registro em uma máquina de estado que já tem 10 políticas de recursos de CloudWatch registros em uma região para uma conta, a máquina de estado não será criada nem atualizada. Para obter mais informações sobre cotas de registro, consulte Cotas de CloudWatch registros.

Se você está tendo problemas para enviar registros para o CloudWatch Logs, consulteTroubleshooting state machine logging to CloudWatch Logs. Para saber mais sobre o registro em geral, consulte Habilitar o registro a partir de AWS serviços.