Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le migliori pratiche per Step Functions

I seguenti argomenti sono le best practice per aiutarti a gestire e ottimizzare i flussi di lavoro Step Functions.

Ottimizzazione dei costi con Express Workflows

Step Functions determina i prezzi per i flussi di lavoro Standard ed Express in base al tipo di flusso di lavoro utilizzato per creare le macchine a stati. Per ottimizzare il costo dei flussi di lavoro serverless, puoi seguire uno o entrambi i seguenti consigli:

Per informazioni su come la scelta di un tipo di flusso di lavoro Standard o Express influisce sulla fatturazione, consulta AWS Step Functions Prezzi.

Flussi di lavoro Nest Express all'interno dei flussi di lavoro Standard

Step Functions esegue flussi di lavoro con una durata e un numero di passaggi limitati. Alcuni flussi di lavoro possono completare l'esecuzione entro un breve periodo di tempo. Altri potrebbero richiedere una combinazione di flussi di lavoro e high-event-rate di lunga durata. Con Step Functions, puoi creare flussi di lavoro ampi e complessi partendo da più flussi di lavoro più piccoli e semplici.

Ad esempio, per creare un flusso di lavoro di elaborazione degli ordini, puoi includere tutte le azioni non idempotenti in un flusso di lavoro Standard. Ciò potrebbe includere azioni, come l'approvazione dell'ordine tramite l'interazione umana e l'elaborazione dei pagamenti. È quindi possibile combinare una serie di azioni idempotenti, come l'invio di notifiche di pagamento e l'aggiornamento dell'inventario dei prodotti, in un flusso di lavoro Express. È possibile inserire questo flusso di lavoro Express all'interno del flusso di lavoro Standard. In questo esempio, il flusso di lavoro Standard è noto come macchina a stati principale. Il flusso di lavoro Express annidato è noto come macchina a stati secondari.

Converti i flussi di lavoro standard in flussi di lavoro Express

È possibile convertire i flussi di lavoro Standard esistenti in flussi di lavoro Express se soddisfano i seguenti requisiti:

Per ulteriori informazioni sulle migliori pratiche e linee guida per la gestione dell'ottimizzazione dei costi per i flussi di lavoro, consulta Building cost-effective AWS Step Functions flussi di lavoro.

Etichettatura di macchine a stati e attività in Step Functions

AWS Step Functions supporta l'etichettatura delle macchine a stati (sia Standard che Express) e delle attività. I tag possono aiutarvi a tracciare e gestire le vostre risorse e a fornire una maggiore sicurezza nelle AWS Identity and Access Management (IAM) politiche. Dopo aver taggato le risorse di Step Functions, puoi gestirle con AWS Resource Groups. Per sapere come, consulta il AWS Resource Groups Guida per l'utente.

Per l'autorizzazione basata su tag, le risorse di esecuzione di una macchina a stati, come illustrato nell'esempio seguente, ereditano i tag associati a una macchina a stati.

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

Quando si chiama DescribeExecutiono si APIs specifica la risorsa di esecuzioneARN, Step Functions utilizza i tag associati alla macchina a stati per accettare o rifiutare la richiesta durante l'esecuzione dell'autorizzazione basata su tag. Ciò consente di consentire o negare l'accesso alle esecuzioni delle macchine a stati a livello di macchina a stati.

Per esaminare le limitazioni correlate la tagging delle risorse, consultare Restrizioni relative all'etichettatura.

Tagging per l'allocazione dei costi

È possibile utilizzare i tag di allocazione dei costi per identificare lo scopo di una macchina a stati e rispecchiare tale organizzazione nel AWS fattura. Iscriviti per ricevere il tuo AWS fattura del conto per includere le chiavi e i valori del tag. Vedi Impostazione di un rapporto mensile di allocazione dei costi nel AWS Billing Guida per l'utente per i dettagli sulla configurazione dei report.

Ad esempio, è possibile aggiungere tag che rappresentano il centro di costo e lo scopo delle risorse Step Functions, come segue.

Tagging per la sicurezza

IAMsupporta il controllo dell'accesso alle risorse in base ai tag. Per controllare l'accesso in base ai tag, fornisci informazioni sui tag delle risorse nell'elemento condition di una IAM policy.

Ad esempio, è possibile limitare l'accesso a tutte le risorse Step Functions che includono un tag con la chiave environment e il valoreproduction.

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

Per ulteriori informazioni, consulta Controllare l'accesso tramite tag nella Guida IAM per l'utente.

Gestione dei tag nella console Step Functions

Puoi visualizzare e gestire i tag per le tue macchine a stati nella console Step Functions. Dalla pagina Details (Dettagli) di una macchina a stati, seleziona Tags (Tag).

Gestione dei tag con Step Functions API Actions

Per gestire i tag utilizzando Step FunctionsAPI, utilizzate le seguenti API azioni:

Utilizzo dei timeout per evitare esecuzioni bloccate del flusso di lavoro Step Functions

Per impostazione predefinita, Amazon States Language non specifica i timeout per le definizioni delle macchine a stati. Senza un timeout esplicito, Step Functions spesso si affida esclusivamente alla risposta di un addetto all'attività per sapere che un'attività è completa. Se qualcosa va storto e il TimeoutSeconds campo non è specificato per uno Task stato Activity o, l'esecuzione rimane bloccata in attesa di una risposta che non arriverà mai.

Per evitare questa situazione, specifica un timeout ragionevole quando crei una macchina a stati Task nella tua macchina a stati. Per esempio:

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

Se si utilizza un callback con un token task (. waitForTaskToken), ti consigliamo di utilizzare heartbeats e di aggiungere il HeartbeatSeconds campo nella definizione dello stato. Task Puoi impostare un valore inferiore HeartbeatSeconds al timeout dell'attività, in modo che se il flusso di lavoro fallisce con un errore di battito cardiaco, saprai che è dovuto all'errore dell'attività e non al completamento dell'operazione che richiede molto tempo.

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

Per ulteriori informazioni, consulta la documentazione Stato del flusso di lavoro delle attività di Amazon States Language.

Utilizzo di Amazon S3 ARNs anziché trasferire payload di grandi dimensioni in Step Functions

Le esecuzioni che trasmettono payload di dati di grandi dimensioni da uno stato all'altro si possono terminare. Se i dati che trasmetti tra gli stati potrebbero superare i 256 KB, usa Amazon Simple Storage Service (Amazon S3) per archiviare i dati e analizza l'Amazon Resource Name ARN () del bucket nel parametro per ottenere il nome del bucket e Payload il valore della chiave. In alternativa modifica la tua applicazione in modo da trasferire nelle esecuzioni payload di dimensioni più contenute.

Nell'esempio seguente, una macchina a stati passa l'input a un AWS Lambda funzione, che elabora un JSON file in un bucket Amazon S3. Dopo aver eseguito questa macchina a stati, la funzione Lambda legge il contenuto del JSON file e lo restituisce come output.

Creazione della funzione Lambda

La seguente funzione Lambda denominata pass-large-payload legge il contenuto di un JSON file archiviato in uno specifico bucket Amazon S3.

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

Crea la macchina a stati

La seguente macchina a stati richiama la funzione Lambda creata in precedenza.

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

Invece di passare una grande quantità di dati in input, puoi salvarli in un bucket Amazon S3 e passare l'Amazon Resource Name (ARN) del bucket nel Payload parametro per ottenere il nome del bucket e il valore della chiave. La tua funzione Lambda può quindi utilizzarla ARN per accedere direttamente ai dati. Di seguito è riportato un esempio di input per l'esecuzione della macchina a stati, in cui i dati vengono archiviati data.json in un bucket Amazon S3 denominato. amzn-s3-demo-large-payload-json

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

Avvio di nuove esecuzioni per evitare di raggiungere la quota di cronologia in Step Functions

AWS Step Functions ha una quota fissa di 25.000 voci nella cronologia degli eventi di esecuzione. Quando un'esecuzione raggiunge 24.999 eventi, attende che si verifichi l'evento successivo.

Per evitare di raggiungere questa quota per le esecuzioni di lunga durata, puoi provare una delle seguenti soluzioni alternative:

Gestire le eccezioni transitorie del servizio Lambda

AWS Lambda possono occasionalmente verificarsi errori temporanei del servizio. In questo caso, l'invocazione di Lambda genera un errore 500, ad ClientExecutionTimeoutException esempioServiceException,AWSLambdaException, o. SdkClientException Come best practice, gestisci in modo proattivo queste eccezioni nella tua macchina a stati per Retry richiamare la funzione Lambda o l'errore. Catch

Gli errori Lambda vengono segnalati come. Lambda.ErrorName Per riprovare un errore di eccezione del servizio Lambda, puoi utilizzare il Retry codice seguente.

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

Per ulteriori informazioni, consulta gli argomenti seguenti:

Evitare la latenza durante il polling delle attività

GetActivityTaskAPIÈ progettato per fornire esattamente una volta. taskToken Se un taskToken viene rimosso durante la comunicazione con un lavoratore di attività, un numero di richieste di GetActivityTask può rimanere bloccato per 60 secondi in attesa di risposta finché non si verifica un timeout del GetActivityTask.

Se hai solo un numero ridotto di poll in attesa di risposta, è possibile che tutte le richieste si accodino alla richiesta bloccata e si arrestino. Tuttavia, se hai un gran numero di sondaggi in sospeso per ogni attività Amazon Resource Name (ARN) e una certa percentuale delle tue richieste è bloccata in attesa, ce ne saranno molte altre che possono ancora ottenere un risultato taskToken e iniziare a funzionare.

Per i sistemi di produzione, consigliamo almeno 100 sondaggi aperti per attività ARN in ogni momento. Se un poll si blocca e una parte di quei poll vi si accoda, rimangono ancora molte altre richieste che otterranno un taskToken per elaborare il lavoro mentre la richiesta di GetActivityTask è bloccata.

Per evitare questo tipo di problemi di latenza durante il polling dei task:

Per ulteriori informazioni sulle attività e sui lavoratori di attività, consultare Scopri di più su Activities in Step Functions.

CloudWatch Registra i limiti di dimensione delle politiche relative alle risorse

Quando si crea una macchina a stati con registrazione o si aggiorna una macchina a stati esistente per abilitare la registrazione, Step Functions deve aggiornare la politica delle risorse CloudWatch Logs con il gruppo di log specificato. CloudWatch Le politiche relative alle risorse dei log sono limitate a 5.120 caratteri.

Quando CloudWatch Logs rileva che una policy si avvicina al limite di dimensione, CloudWatch Logs abilita automaticamente la registrazione per i gruppi di log che iniziano con. /aws/vendedlogs/

È possibile aggiungere come prefisso i nomi dei gruppi di log CloudWatch Logs /aws/vendedlogs/ per evitare il limite di dimensione della politica delle CloudWatch risorse Logs. Se crei un gruppo di log nella console Step Functions, il nome del gruppo di log suggerito avrà già il prefisso. /aws/vendedlogs/states

CloudWatch Logs ha anche una quota di 10 politiche relative alle risorse per regione e per account. Se si tenta di abilitare la registrazione su una macchina a stati che dispone già di 10 politiche relative alle risorse di CloudWatch Logs in una regione per un account, la macchina a stati non verrà creata o aggiornata. Per ulteriori informazioni sulla registrazione delle quotazioni, consulta CloudWatch Registra le quote.

Se riscontri problemi nell'invio dei log a Logs, consulta. CloudWatch Troubleshooting state machine logging to CloudWatch Logs Per ulteriori informazioni sulla registrazione in generale, consulta Abilitare la registrazione da AWS servizi.