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.
# Bonnes pratiques pour Step Functions
**Gestion de l'état et transformation des données**
Découvrez comment [transmettre des données entre états à l'aide de variables](workflow-variables.md) et [transformer des données avec JSONata](transforming-data.md).
Les rubriques suivantes présentent les meilleures pratiques destinées à vous aider à gérer et à optimiser vos flux de travail Step Functions.
**Topics**
+ [Optimisation des coûts à l'aide d'Express Workflows](#cost-opt-exp-workflows)
+ [Marquage des machines d'état et des activités dans Step Functions](#concepts-tagging)
+ [Utiliser les délais d'attente pour éviter le blocage des exécutions de flux de travail Step Functions](#sfn-stuck-execution)
+ [Utiliser Amazon S3 ARNs au lieu de transmettre des charges utiles importantes dans Step Functions](#avoid-exec-failures)
+ [Lancer de nouvelles exécutions pour éviter d'atteindre le quota d'historique dans Step Functions](#bp-history-limit)
+ [Gérer les exceptions transitoires du service Lambda](#bp-lambda-serviceexception)
+ [Éviter la latence lors de l'interrogation pour des tâches d'activité](#bp-activity-pollers)
+ [Éviter les CloudWatch limites de taille fixées par les politiques de](#bp-cwl)
## 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, consultez la section [AWS Step FunctionsTarification](https://aws.amazon.com/step-functions/pricing/).
### 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 flux de travail à long terme 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*.
### Migrer les flux de travail standard vers les flux de travail Express
Vous devriez envisager de migrer vos flux de travail standard vers des flux de travail Express s'ils répondent aux exigences suivantes :
+ L'exécution de votre flux de travail doit être terminée dans les cinq minutes.
+ Votre flux de travail est conforme à un modèle *at-least-once*d'exécution, ce qui signifie que chaque étape du flux de travail peut être exécutée plusieurs fois exactement.
+ Votre 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. Vous devrez payer des frais supplémentaires lors de l'utilisation de CloudWatch Logs.
**Pour migrer un flux de travail standard vers un flux de travail Express à l'aide de la console**
1. Ouvrez la [console Step Functions](https://console.aws.amazon.com/states/home?region=us-east-1#/).
1. 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.
1. Choisissez **Copier vers un nouvel élément**.
Workflow Studio s'ouvre pour [Mode de conception](workflow-studio.md#wfs-interface-design-mode) afficher le flux de travail de la machine à états que vous avez sélectionnée.
1. (Facultatif) Mettez à jour la conception du flux de travail.
1. 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**.
1. (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 migrez un flux de travail standard défini précédemment dans [AWS CDK](https://docs.aws.amazon.com/cdk/api/latest/docs/aws-stepfunctions-readme.html)ouAWS SAM, vous devez modifier la valeur `Type` et le `Resource` nom de.
1. 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 rôle IAM 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 politique IAM), 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, voir [Création de AWS Step Functions flux de travail rentables](https://aws.amazon.com/blogs/compute/building-cost-effective-aws-step-functions-workflows/).
## Marquage des machines d'état et des activités dans Step Functions
AWS Step Functionsprend 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 vos politiques Gestion des identités et des accès AWS (IAM). Après avoir balisé les ressources Step Functions, vous pouvez les gérer avecGroupes de ressources AWS. Pour savoir comment procéder, consultez le [guide de Groupes de ressources AWS l'utilisateur](https://docs.aws.amazon.com/ARG/latest/userguide/).
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::
```
Lorsque vous appelez [DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)ou que vous spécifiez l'ARN de la ressource d'exécution, Step Functions utilise des balises associées à la machine d'état pour accepter ou refuser la demande tout en effectuant une autorisation basée sur des balises. APIs 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](service-quotas.md#sfn-limits-tagging).
### 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 la facture de votre AWS compte qui inclura les clés et les valeurs des tags. Voir [Configuration d'un rapport mensuel de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html#allocation-report) dans le *guide de AWS Billing l'utilisateur* pour plus de détails sur la configuration des rapports.
Par exemple, vous pouvez ajouter des balises représentant votre centre de coûts et l'objectif de vos ressources Step Functions, comme suit.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/step-functions/latest/dg/sfn-best-practices.html)
### Balisage pour la sécurité
IAM prend 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 politique IAM.
Par exemple, vous pouvez restreindre l'accès à toutes les ressources Step Functions qui incluent une balise avec la clé `environment` et la valeur`production`.
****
```
{
"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 [Contrôle de l'accès à l'aide d'identifications](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) dans le Guide de l'utilisateur IAM.
### 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**.
### Gestion des balises avec les actions de l'API Step Functions
Pour gérer les balises à l'aide de l'API Step Functions, utilisez les actions d'API suivantes :
+ [https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListTagsForResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListTagsForResource.html)
+ [https://docs.aws.amazon.com/step-functions/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TagResource.html)
+ [https://docs.aws.amazon.com/step-functions/latest/apireference/API_UntagResource.html](https://docs.aws.amazon.com/step-functions/latest/apireference/API_UntagResource.html)
## 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 d'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:region:account-id:activity:HelloWorld",
"TimeoutSeconds": 300,
"Next": "NextState"
}
```
Si vous utilisez un [rappel avec un jeton de tâche (. waitForTaskToken)](connect-to-resource.md#connect-wait-token), 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/account-id/push-based-queue"
},
"ResultPath": "$.SQS",
"End": true
}
}
}
```
Pour plus d'informations, consultez [État du flux de travail des tâches](state-task.md) 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](statemachine-structure.md).
## 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 KiB, utilisez Amazon Simple Storage Service (Amazon S3) pour stocker les données, puis analysez l'Amazon Resource Name (ARN) du bucket `Payload` dans le paramètre pour obtenir le nom du bucket 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 à une AWS Lambda fonction qui traite un fichier JSON dans un compartiment Amazon S3. Après avoir exécuté cette machine à états, la fonction Lambda lit le contenu du fichier JSON 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 fichier JSON stocké dans un compartiment Amazon S3 spécifique.
**Note**
Après avoir créé cette fonction Lambda, assurez-vous de fournir à son rôle IAM 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 invoque 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 utiliser cet 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 Functionsdispose 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 000`ExecutionSucceeded`, l'exécution se termine correctement.
+ Si le numéro d'événement 25 000 ne l'est pas`ExecutionSucceeded`, 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 :
+ [Utilisez l'état de la carte en mode distribué](state-map-distributed.md). Dans ce mode, l'`Map`état exécute chaque itération en tant qu'exécution d'un flux de travail enfant, ce qui permet une simultanéité élevée de jusqu'à 10 000 exécutions parallèles de flux de travail enfant. Chaque exécution de flux de travail enfant possède son propre historique d'exécution distinct de celui du flux de travail parent.
+ Démarrez une nouvelle exécution par machine à états directement à partir de l'`Task`état d'une exécution en cours. Pour démarrer de telles exécutions de flux de travail imbriqués, utilisez l'action `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API de Step Functions dans la machine d'état parent avec les paramètres nécessaires. Pour plus d'informations sur l'utilisation de flux de travail imbriqués, voir [Lancer des exécutions de flux de travail à partir d'un état de tâche dans Step Functions](concepts-nested-workflows.md) ou [Utiliser une action d'API Step Functions pour poursuivre un nouveau didacticiel d'exécution](tutorial-continue-new.md).
**Astuce**
Pour déployer un exemple de flux de travail imbriqué, consultez la section [Optimisation des coûts](https://catalog.workshops.aws/stepfunctions/nested-workflow) dans *The AWS Step Functions Workshop*.
+ Implémentez un modèle qui utilise une AWS Lambda fonction capable de démarrer une nouvelle exécution de votre machine à états afin de répartir le travail en cours entre plusieurs exécutions de flux de travail. Pour plus d'informations, consultez le didacticiel [Utiliser une fonction Lambda pour poursuivre une nouvelle exécution dans Step Functions](tutorial-use-lambda-cont-exec.md).
## Gérer les exceptions transitoires du service Lambda
AWS Lambdapeut parfois rencontrer des erreurs de service transitoires. Dans ce cas, l'invocation de Lambda entraîne une erreur 500, telle `ClientExecutionTimeoutException` que, `ServiceException``AWSLambdaException`, ou. `SdkClientException` Il est recommandé de gérer ces exceptions de manière proactive dans votre machine à états avant d'`Retry`appeler 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 les environnements d'exécution Lambda étaient historiquement signalées uniquement sous la forme. `Lambda.Unknown` Dans les nouveaux environnements d'exécution, les délais d'expiration sont signalés comme `Sandbox.Timedout` dans le résultat d'erreur.
Lorsque Lambda dépasse le nombre maximum d'appels, l'erreur signalée sera. `Lambda.TooManyRequestsException`
Faites correspondre `Lambda.Unknown``Sandbox.Timedout`, et `States.TaskFailed` pour gérer les erreurs éventuelles. Vous pouvez également l'utiliser`States.ALL`, mais il doit être seul et en fin de liste.
Pour plus d'informations sur Lambda `Handled` et `Unhandled` les erreurs, consultez le `FunctionError` manuel du [AWS Lambdadéveloppeur](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax).
Pour plus d’informations, consultez les ressources suivantes :
+ [Nouvelle tentative après une erreur](concepts-error-handling.md#error-handling-retrying-after-an-error)
+ [Gestion des conditions d'erreur dans une machine à états Step Functions](tutorial-handling-error-conditions.md)
+ [Erreurs d'appel Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors)
## Éviter la latence lors de l'interrogation pour des tâches d'activité
L'API `[GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)` est conçue pour fournir un [https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html#StepFunctions-GetActivityTask-response-taskToken](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html#StepFunctions-GetActivityTask-response-taskToken) *exactement une 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 interrogations ouvertes par ARN d'activité à un moment donné. 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 interrogations ouvertes par ARN d'activité à un moment donné.
**Note**
Le passage à 100 interrogations ouvertes par ARN peut être coûteux. Par exemple, l'interrogation de 100 fonctions Lambda par ARN coûte 100 fois plus cher que d'avoir 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](concepts-activities.md#example-ruby-activity-worker).
Pour plus d'informations sur les activités et les travaux d'activité, consultez [En savoir plus sur les activités dans Step Functions](concepts-activities.md).
## Éviter les CloudWatch limites de taille fixées par les politiques de
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 dix 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 dix 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 quotas de journalisation, consultez la section [Quotas de CloudWatch journalisation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html).
Si vous ne parvenez pas à envoyer des CloudWatch journaux à Logs, consultez[Troubleshooting state machine logging to CloudWatch Logs](cw-logs.md#troubleshooting-logging-to-cloudwatch).