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.
Liste des meilleures pratiques
- Optimisation des coûts à l'aide d'Express Workflows
- Marquage des machines d'état et des activités dans Step Functions
- Utiliser les délais d'attente pour éviter le blocage des exécutions de flux de travail Step Functions
- Utiliser Amazon S3 ARNs au lieu de transmettre des charges utiles importantes dans Step Functions
- Lancer de nouvelles exécutions pour éviter d'atteindre le quota d'historique dans Step Functions
- Gérer les exceptions transitoires du service Lambda
- Éviter la latence lors de l'interrogation pour des tâches d'activité
- CloudWatch Limites de taille des règles relatives aux ressources des journaux
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
-
Ouvrez la console Step Functions
. -
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.
-
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.
-
(Facultatif) Mettez à jour la conception du flux de travail.
-
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.
-
(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 leResource
nom de. -
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
lit le contenu d'un JSON fichier stocké dans un compartiment Amazon S3 spécifique.pass-large-payload
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 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é. 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'StartExecution
APIaction 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 ou Utiliser une API action Step Functions pour poursuivre un nouveau didacticiel d'exécution.Astuce
Pour déployer un exemple de flux de travail imbriqué sur votre Compte AWS, voir Module 13 - Flux de travail express imbriqués
. -
Implémentez un modèle qui utilise un AWS Lambda fonction qui peut 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.
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, 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.
Pour réessayer une erreur d'exception du service Lambda, vous pouvez utiliser le ErrorName
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é
GetActivityTask
APIIl est conçu pour fournir une taskToken
seule 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.