Meilleures pratiques pour Step Functions - AWS Step Functions
Optimisation avec Express WorkflowsBalisage des ressourcesUtiliser les délais d'attente pour éviter les exécutions bloquéesUtilisation d'Amazon S3 pour transmettre des données volumineusesÉviter le quota d'historique d'exécutionGestion des exceptions LambdaÉviter le temps de latence pour les tâches liées aux activitésLimites de la politique des ressources du journal

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Meilleures pratiques pour Step Functions

Les rubriques suivantes présentent les meilleures pratiques destinées à vous aider à gérer et à optimiser vos flux de travail Step Functions.

Optimisation des coûts à l'aide d'Express Workflows

Step Functions détermine le prix des flux de travail Standard et Express en fonction du type de flux de travail que vous utilisez pour créer vos machines d'état. Pour optimiser le coût de vos flux de travail sans serveur, vous pouvez suivre l'une des recommandations suivantes ou les deux :

Pour plus d'informations sur l'impact du choix d'un type de flux de travail Standard ou Express sur la facturation, voir AWS Step Functions Tarification.

Flux de travail Nest Express intégrés aux flux de travail standard

Step Functions exécute des flux de travail dont la durée et le nombre d'étapes sont limités. Certains flux de travail peuvent être exécutés dans un court laps de temps. D'autres peuvent nécessiter une combinaison de longue durée et de high-event-rate flux de travail. Avec Step Functions, vous pouvez créer des flux de travail volumineux et complexes à partir de plusieurs flux de travail plus petits et plus simples.

Par exemple, pour créer un flux de travail de traitement des commandes, vous pouvez inclure toutes les actions non idempotentes dans un flux de travail standard. Cela pourrait inclure des actions telles que l'approbation de la commande par le biais d'une interaction humaine et le traitement des paiements. Vous pouvez ensuite combiner une série d'actions idempotentes, telles que l'envoi de notifications de paiement et la mise à jour de l'inventaire des produits, dans un flux de travail Express. Vous pouvez intégrer ce flux de travail Express au flux de travail standard. Dans cet exemple, le flux de travail standard est connu sous le nom de machine à états parent. Le flux de travail Express imbriqué est connu sous le nom de machine à états fils.

Convertissez les flux de travail standard en flux de travail Express

Vous pouvez convertir vos flux de travail standard existants en flux de travail Express s'ils répondent aux exigences suivantes :

  • Le flux de travail doit être terminé dans les cinq minutes.

  • Le flux de travail est conforme à un modèle at-least-onced'exécution. Cela signifie que chaque étape du flux de travail peut être exécutée plusieurs fois exactement.

  • Le flux de travail n'utilise pas les .waitForTaskToken modèles d'intégration des .sync services.

Important

Les flux de travail Express utilisent Amazon CloudWatch Logs pour enregistrer les historiques d'exécution. L'utilisation de CloudWatch Logs entraîne des coûts supplémentaires.

Pour convertir un flux de travail standard en flux de travail express à l'aide de la console

  1. Ouvrez la console Step Functions.

  2. Sur la page Machines d'état, choisissez une machine d'état de type standard pour l'ouvrir.

    Astuce

    Dans la liste déroulante Tous les types, choisissez Standard pour filtrer la liste des machines à états et afficher uniquement les flux de travail standard.

  3. Choisissez Copier vers un nouveau.

    Workflow Studio s'ouvre pour Mode de conception afficher le flux de travail de la machine à états que vous avez sélectionnée.

  4. (Facultatif) Mettez à jour la conception du flux de travail.

  5. Spécifiez un nom pour votre machine à états. Pour ce faire, cliquez sur l'icône d'édition à côté du nom de la machine à états par défaut de MyStateMachine. Ensuite, dans Configuration de la machine d'état, spécifiez un nom dans le champ Nom de la machine d'état.

  6. (Facultatif) Dans Configuration de la machine à états, spécifiez d'autres paramètres de flux de travail, tels que le type de machine à états et son rôle d'exécution.

    Assurez-vous que pour Type, vous choisissez Express. Conservez toutes les autres sélections par défaut dans les paramètres State Machine.

    Note

    Si vous convertissez un flux de travail standard défini précédemment dans AWS CDK ou AWS SAM, vous devez modifier la valeur Type et le Resource nom de.

  7. Dans la boîte de dialogue Confirmer la création du rôle, choisissez Confirmer pour continuer.

    Vous pouvez également choisir Afficher les paramètres des rôles pour revenir à la configuration de la machine State.

    Note

    Si vous supprimez le IAM rôle créé par Step Functions, Step Functions ne pourra pas le recréer ultérieurement. De même, si vous modifiez le rôle (par exemple, en supprimant Step Functions des principes de la IAM politique), Step Functions ne pourra pas restaurer ses paramètres d'origine ultérieurement.

Pour plus d'informations sur les meilleures pratiques et les directives relatives à la gestion de l'optimisation des coûts de vos flux de travail, consultez la section Création de flux de travail rentables AWS Step Functions flux de travail.

Marquage des machines d'état et des activités dans Step Functions

AWS Step Functions prend en charge le balisage des machines d'état (Standard et Express) et des activités. Les balises peuvent vous aider à suivre et à gérer vos ressources et à renforcer la sécurité de votre AWS Identity and Access Management (IAM) politiques. Après avoir balisé les ressources Step Functions, vous pouvez les gérer avec AWS Resource Groups. Pour savoir comment procéder, consultez le AWS Resource Groups Guide de l'utilisateur.

Pour l'autorisation basée sur des balises, les ressources d'exécution de la machine d'état, comme indiqué dans l'exemple suivant, héritent des balises associées à une machine d'état.

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

Lorsque vous appelez DescribeExecutionou que vous spécifiez la ressource d'APIsexécutionARN, Step Functions utilise les balises associées à la machine d'état pour accepter ou refuser la demande tout en effectuant une autorisation basée sur des balises. Cela vous permet d'autoriser ou de refuser l'accès aux exécutions par machine d'état au niveau de la machine d'état.

Pour passer en revue les restrictions liées au balisage de ressources, consultez Restrictions liées au balisage.

Balisage de répartition des coûts

Vous pouvez utiliser des balises de répartition des coûts pour identifier l'objectif d'une machine étatique et refléter cette organisation dans votre AWS facture. Inscrivez-vous pour obtenir votre AWS facture de compte pour inclure les clés et les valeurs du tag. Voir Configuration d'un rapport mensuel de répartition des coûts dans le AWS Billing Guide de l'utilisateur pour plus de détails sur la configuration des rapports.

Par exemple, vous pouvez ajouter des balises qui représentent votre centre de coûts et l'objectif de vos ressources Step Functions, comme suit.

Ressource Clé Valeur
StateMachine1 Cost Center 34567
Application Image processing
StateMachine2 Cost Center 34567
Application Rekognition processing

Balisage pour la sécurité

IAMprend en charge le contrôle de l'accès aux ressources en fonction des balises. Pour contrôler l'accès en fonction des balises, fournissez des informations sur vos balises de ressources dans l'élément condition d'une IAM politique.

Par exemple, vous pouvez restreindre l'accès à toutes les ressources Step Functions qui incluent une balise avec la clé environment et la valeurproduction.

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

Pour plus d'informations, consultez la section Contrôle de l'accès à l'aide de balises dans le guide de IAM l'utilisateur.

Gestion des tags dans la console Step Functions

Vous pouvez afficher et gérer les tags de vos machines d'état dans la console Step Functions. Sur la page Détails d'une machine à états, sélectionnez Tags.

Gérer les tags avec les API actions Step Functions

Pour gérer les balises à l'aide des Step FunctionsAPI, utilisez les API actions suivantes :

Utiliser les délais d'attente pour éviter le blocage des exécutions de flux de travail Step Functions

Par défaut, l'Amazon States Language ne spécifie pas de délais d'expiration pour les définitions des machines à états. En l'absence de délai d'attente explicite, Step Functions s'appuie souvent uniquement sur la réponse d'un intervenant chargé de l'activité pour savoir qu'une tâche est terminée. Si quelque chose ne va pas et que le TimeoutSeconds champ n'est pas spécifié pour un Task état Activity ou, une exécution est bloquée dans l'attente d'une réponse qui n'arrivera jamais.

Pour éviter cette situation, spécifiez un délai d'attente raisonnable lorsque vous créez une machine Task dans votre état. Par exemple : 

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

Si vous utilisez un rappel avec un jeton de tâche (. waitForTaskToken), nous vous recommandons d'utiliser les pulsations cardiaques et d'ajouter le HeartbeatSeconds champ dans la définition de votre Task état. Vous pouvez le régler HeartbeatSeconds pour qu'il soit inférieur au délai d'expiration de la tâche. Ainsi, si votre flux de travail échoue en raison d'une erreur cardiaque, vous savez que c'est à cause de l'échec de la tâche et non du fait que l'exécution de la tâche prend du temps.

{
  "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
    }
  }
}

Pour plus d'informations, consultez État du flux de travail des tâches la documentation Amazon States Language.

Note

Vous pouvez définir un délai d'expiration pour votre machine à états en utilisant le TimeoutSeconds champ de votre définition du langage Amazon States. Pour de plus amples informations, veuillez consulter Structure des machines à états dans Amazon States Language pour les flux de travail Step Functions.

Utiliser Amazon S3 ARNs au lieu de transmettre des charges utiles importantes dans Step Functions

Les exécutions qui transmettent de grandes charges utiles de données entre états peuvent être résiliées. Si les données que vous transmettez d'un État à l'autre peuvent atteindre plus de 256 Ko, utilisez Amazon Simple Storage Service (Amazon S3) pour stocker les données, puis analysez le ARN nom de ressource Amazon () du compartiment Payload dans le paramètre pour obtenir le nom du compartiment et la valeur clé. Sinon, vous pouvez aussi ajuster votre implémentation de façon à transmettre des charges utiles plus petites dans vos exécutions.

Dans l'exemple suivant, une machine à états transmet une entrée à un AWS Lambda fonction, qui traite un JSON fichier dans un compartiment Amazon S3. Après avoir exécuté cette machine à états, la fonction Lambda lit le contenu du JSON fichier et renvoie le contenu du fichier en sortie.

Créer la fonction Lambda

La fonction Lambda nommée ci-dessous pass-large-payload lit le contenu d'un JSON fichier stocké dans un compartiment Amazon S3 spécifique.

Note

Après avoir créé cette fonction Lambda, assurez-vous de fournir à son IAM rôle l'autorisation appropriée pour lire depuis un compartiment Amazon S3. Par exemple, attachez l'ReadOnlyAccessautorisation AmazonS3 au rôle de la fonction 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
Création de la machine à états

La machine à états suivante appelle la fonction Lambda que vous avez créée précédemment.

{  
   "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
      }
   }
}

Plutôt que de transmettre une grande quantité de données en entrée, vous pouvez enregistrer ces données dans un compartiment Amazon S3 et transmettre le nom de ressource Amazon (ARN) du compartiment dans le Payload paramètre pour obtenir le nom du compartiment et la valeur clé. Votre fonction Lambda peut ensuite l'utiliser ARN pour accéder directement aux données. Voici un exemple d'entrée pour l'exécution de la machine à états, où les données sont stockées data.json dans un compartiment Amazon S3 nomméamzn-s3-demo-large-payload-json.

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

Lancer de nouvelles exécutions pour éviter d'atteindre le quota d'historique dans Step Functions

AWS Step Functions dispose d'un quota strict de 25 000 entrées dans l'historique des événements d'exécution. Lorsqu'une exécution atteint 24 999 événements, elle attend que le prochain événement se produise.

  • Si le numéro d'événement 25 000 est égal à 25 000ExecutionSucceeded, l'exécution se termine correctement.

  • Si le numéro d'événement 25 000 ne l'est pasExecutionSucceeded, l'ExecutionFailedévénement est enregistré et l'exécution de la machine à états échoue car la limite d'historique a été atteinte

Pour éviter d'atteindre ce quota pour les exécutions de longue durée, vous pouvez essayer l'une des solutions suivantes :

Gérer les exceptions transitoires du service Lambda

AWS Lambda peut parfois rencontrer des erreurs de service transitoires. Dans ce cas, l'invocation de Lambda entraîne une erreur 500, telle ClientExecutionTimeoutException que, ServiceExceptionAWSLambdaException, ou. SdkClientException Il est recommandé de gérer ces exceptions de manière proactive dans votre machine à états avant d'Retryappeler votre fonction Lambda ou de corriger l'erreur. Catch

Les erreurs Lambda sont signalées sous forme de. Lambda.ErrorName Pour réessayer une erreur d'exception du service Lambda, vous pouvez utiliser le Retry code suivant.

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

Les erreurs non gérées dans Lambda sont signalées Lambda.Unknown comme dans le résultat d'erreur. Il s'agit notamment out-of-memory des erreurs et des délais d'expiration des fonctions. Vous pouvez faire correspondre ou States.TaskFailed gérer ces erreurs. Lambda.Unknown States.ALL Lorsque Lambda atteint le nombre maximum d'appels, l'erreur est. Lambda.TooManyRequestsException Pour plus d'informations sur Lambda Handled et les Unhandled erreurs, consultez le FunctionError AWS Lambda Guide du développeur.

Pour plus d’informations, consultez les ressources suivantes :

Éviter la latence lors de l'interrogation pour des tâches d'activité

GetActivityTaskAPIIl est conçu pour fournir une taskTokenseule fois. Si un taskToken est supprimé lors de la communication avec un travail d'activité, un certain nombre de demandes GetActivityTask peuvent être bloquées pendant 60 secondes dans l'attente d'une réponse avant expiration de GetActivityTask.

Si vous avez seulement un petit nombre d'interrogations en attente de réponse, il est possible que toutes les demandes soient placées en file d'attente derrière la demande bloquée et s'arrêtent. Toutefois, si vous avez un grand nombre de sondages en suspens pour chaque activité Amazon Resource Name (ARN) et qu'un certain pourcentage de vos demandes sont en attente, il y en aura encore beaucoup d'autres qui pourront encore obtenir un résultat taskToken et commencer à traiter.

Pour les systèmes de production, nous recommandons au moins 100 sondages ouverts par activité ARN à chaque moment. Si une interrogation est bloquée et qu'une partie de ces interrogations sont placées en file d'attente derrière celle-ci, un grand nombre de demandes recevra encore un taskToken pour poursuivre le travail tandis que la demande GetActivityTask est bloquée.

Pour éviter ces problèmes de latence lors de la recherche de tâches :

  • Implémentez les observateurs sous forme de threads distincts du travail dans l'implémentation de votre travail d'activité.

  • Ayez au moins 100 sondages ouverts par activité ARN à chaque moment.

    Note

    Il ARN peut être coûteux de passer à 100 bureaux de vote ouverts par bureau de vote. Par exemple, 100 fonctions Lambda interrogeant chacune ARN sont 100 fois plus coûteuses qu'une seule fonction Lambda avec 100 threads d'interrogation. Pour réduire la latence et minimiser les coûts, utilisez un langage qui comporte des E/S asynchrones et implémentez plusieurs threads d'interrogation par unité de travail. Pour obtenir un exemple de travail d'activité où les threads de l'outil d'interrogation sont distincts des threads de travail, consultez Exemple : Activity Worker dans Ruby.

Pour plus d'informations sur les activités et les travaux d'activité, consultez En savoir plus sur les activités dans Step Functions.

CloudWatch Limites de taille des règles relatives aux ressources des journaux

Lorsque vous créez une machine d'état avec journalisation, ou que vous mettez à jour une machine d'état existante pour activer la journalisation, Step Functions doit mettre à jour votre politique de ressources de CloudWatch journaux avec le groupe de journaux que vous spécifiez. CloudWatch Les politiques relatives aux ressources des journaux sont limitées à 5 120 caractères.

Lorsque CloudWatch Logs détecte qu'une politique approche la limite de taille, CloudWatch Logs active automatiquement la journalisation pour les groupes de journaux commençant par/aws/vendedlogs/.

Vous pouvez préfixer les noms de vos groupes de CloudWatch journaux de journaux /aws/vendedlogs/ pour éviter la limite de taille de la politique de gestion des CloudWatch journaux. Si vous créez un groupe de journaux dans la console Step Functions, le nom de groupe de journaux suggéré sera déjà préfixé par/aws/vendedlogs/states.

CloudWatch Logs dispose également d'un quota de 10 politiques de ressources par région et par compte. Si vous essayez d'activer la journalisation sur une machine d'état qui dispose déjà de 10 politiques de ressources de CloudWatch journaux dans une région pour un compte, la machine d'état ne sera ni créée ni mise à jour. Pour plus d'informations sur les devis de journalisation, consultez la section Quotas de CloudWatch journalisation.

Si vous ne parvenez pas à envoyer des CloudWatch journaux à Logs, consultezTroubleshooting state machine logging to CloudWatch Logs. Pour en savoir plus sur la journalisation en général, voir Activer la journalisation depuis AWS services.