익스프레스 워크플로를 통한 최적화 리소스에 태그 지정 타임아웃을 사용하여 실행 중단 방지 Amazon S3를 사용하여 대용량 데이터 전달 실행 기록 할당량 피하기 Lambda 예외 처리 액티비티 태스크의 지연 방지 로그 리소스 정책 제한

Step Functions 모범 사례

다음 항목은 Step Functions 워크플로를 관리하고 최적화하는 데 도움이 되는 모범 사례입니다.

모범 사례 목록

익스프레스 워크플로를 사용한 비용 최적화
Step Functions에서 스테이트 머신 및 액티비티에 태그 지정하기
타임아웃을 사용하여 Step Functions 워크플로 실행 중단 방지
Step Functions에서 대용량 페이로드를 전달하는 ARNs 대신 Amazon S3 사용
Step Functions의 기록 할당량에 도달하지 않도록 새 실행 시작
일시적인 Lambda 서비스 예외 처리
액티비티 태스크를 위한 폴링 시 지연 방지
CloudWatch 리소스 정책 크기 제한을 기록합니다.

익스프레스 워크플로를 사용한 비용 최적화

Step Functions는 상태 시스템을 빌드하는 데 사용하는 워크플로 유형에 따라 표준 및 Express 워크플로의 요금을 결정합니다. 서버리스 워크플로 비용을 최적화하려면 다음 권장 사항 중 하나 또는 둘 다 따르면 됩니다.

Standard 또는 Express 워크플로우 유형 선택이 청구에 미치는 영향에 대한 자세한 내용은 을 참조하십시오. AWS Step Functions 요금.

표준 워크플로우 내 Nest Express 워크플로우

Step Functions는 기간과 단계 수가 한정적인 워크플로를 실행합니다. 일부 워크플로는 짧은 시간 내에 실행을 완료할 수 있습니다. 장기 실행 high-event-rate 워크플로와 워크플로를 함께 사용해야 하는 경우도 있습니다. Step Functions를 사용하면 여러 단순한 소규모 워크플로에서 복잡한 대규모 워크플로를 빌드할 수 있습니다.

예를 들어 주문 처리 워크플로를 빌드하려면 멱등성이 없는 모든 작업을 표준 워크플로에 포함하면 됩니다. 여기에는 인적 상호 작용을 통한 주문 승인 및 결제 처리와 같은 작업이 포함될 수 있습니다. 그런 다음 결제 알림 전송 및 제품 인벤토리 업데이트와 같은 일련의 멱등성이 있는 작업을 Express 워크플로에 결합할 수 있습니다. 표준 워크플로 내에서 이 Express 워크플로를 중첩할 수 있습니다. 이 예제에서는 표준 워크플로를 상위 상태 시스템이라고 합니다. 중첩된 Express 워크플로를 하위 상태 시스템이라고 합니다.

표준 워크플로를 Express 워크플로로 전환하십시오.

다음 요구 사항을 충족하는 경우 기존 표준 워크플로를 Express 워크플로로 변환할 수 있습니다.

워크플로는 실행을 5분 이내에 완료해야 합니다.
워크플로는 at-least-once실행 모델을 준수합니다. 즉, 워크플로의 각 단계가 정확히 2회 이상 실행될 수 있습니다.
워크플로는 .waitForTaskToken 또는 .sync 서비스 통합 패턴을 사용하지 않습니다.

중요

익스프레스 워크플로는 Amazon CloudWatch Logs를 사용하여 실행 기록을 기록합니다. 로그를 사용할 CloudWatch 경우 추가 비용이 발생합니다.

콘솔을 사용하여 표준 워크플로를 Express 워크플로로 전환하기

Step Functions 콘솔을 엽니다.
상태 시스템 페이지에서 표준 유형 상태 시스템을 선택하여 엽니다.

작은 정보
상태 시스템 목록을 필터링하고 표준 워크플로만 보려면 모든 유형 드롭다운 목록에서 표준을 선택하세요.
신규로 복사를 선택합니다.

Workflow Studio가 디자인 모드에서 열리고 선택한 상태 시스템의 워크플로가 표시됩니다.
(선택 사항) 워크플로 설계를 업데이트합니다.
상태 시스템 이름을 지정합니다. 이렇게 하려면 기본 상태 머신 이름 옆에 있는 편집 아이콘을 선택합니다. MyStateMachine 그런 다음 상태 머신 구성에서 상태 머신 이름 상자에 이름을 지정합니다.
(선택 사항) 상태 머신 구성에서 상태 시스템 유형 및 실행 역할과 같은 기타 워크플로 설정을 지정합니다.

유형에 Express를 선택했는지 확인합니다. 상태 머신 설정의 다른 모든 기본 선택을 그대로 둡니다.

참고
에서 이전에 정의한 표준 워크플로를 변환하는 경우 AWS CDK 또는 AWS SAMType및 Resource 이름의 값을 변경해야 합니다.
역할 생성 확인 대화 상자에서 확인을 선택하여 계속합니다.

역할 설정 보기를 선택하여 상태 머신 구성으로 돌아갈 수도 있습니다.

참고
Step IAM Functions가 생성하는 역할을 삭제하면 Step Functions에서 해당 역할을 나중에 다시 생성할 수 없습니다. 마찬가지로 역할을 수정하는 경우 (예: IAM 정책의 보안 주체에서 Step Functions를 제거하는 경우) Step Functions는 나중에 원래 설정을 복원할 수 없습니다.

워크플로의 비용 최적화 관리를 위한 모범 사례 및 지침에 대한 자세한 내용은 비용 효율적인 구축을 참조하십시오. AWS Step Functions 워크플로.

Step Functions에서 스테이트 머신 및 액티비티에 태그 지정하기

AWS Step Functions 상태 머신 (스탠다드 및 익스프레스 모두) 과 활동에 대한 태깅을 지원합니다. 태그를 사용하면 리소스를 추적 및 관리하고 보안을 강화할 수 있습니다. AWS Identity and Access Management (IAM) 정책. Step Functions 리소스에 태그를 지정한 후 다음과 같이 리소스를 관리할 수 있습니다. AWS Resource Groups. 방법을 알아보려면 다음을 참조하십시오. AWS Resource Groups 사용자 가이드.

태그 기반 권한 부여의 경우 다음 예제와 같은 상태 시스템 실행 리소스는 상태 시스템과 연결된 태그를 상속합니다.


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

실행 리소스를 DescribeExecutionARN지정하거나 호출하는 경우 Step Functions는 태그 기반 권한 부여를 수행하는 동안 상태 머신과 연결된 태그를 사용하여 요청을 수락하거나 거부합니다. APIs 이렇게 하면 상태 시스템 수준에서 상태 시스템 실행에 대한 액세스를 허용하거나 거부할 수 있습니다.

리소스 태그 지정에 관련된 제한을 검토하려면 태그 지정과 관련된 제한 단원을 참조하십시오.

비용 할당을 위한 태그 지정

비용 할당 태그를 사용하여 스테이트 머신의 용도를 식별하고 해당 조직을 사용자 환경에 반영할 수 있습니다. AWS 청구서. 가입하고 받아가세요 AWS 태그 키와 값이 포함된 계정 청구서 의 월별 비용 할당 보고서 설정을 참조하십시오. AWS Billing 보고서 설정에 대한 자세한 내용은 사용 설명서를 참조하십시오.

예를 들어 다음과 같이 Step Functions 리소스의 비용 센터 및 용도를 나타내는 태그를 추가할 수 있습니다.

Resource	키	값
`StateMachine1`	`Cost Center`	`34567`
`StateMachine1`	`Application`	`Image processing`
`StateMachine2`	`Cost Center`	`34567`
`StateMachine2`	`Application`	`Rekognition processing`

보안을 위한 태그 지정

IAM태그를 기반으로 리소스에 대한 액세스 제어를 지원합니다. 태그를 기반으로 액세스를 제어하려면 IAM 정책의 조건 요소에 리소스 태그에 대한 정보를 제공하십시오.

예를 들어 environment 키 및 production 값과 함께 태그가 포함된 모든 Step Functions 리소스에 대한 액세스를 제한할 수 있습니다.


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

자세한 내용은 사용 IAM 설명서의 태그를 사용한 액세스 제어를 참조하십시오.

Step Functions 콘솔에서 태그 관리하기

Step Functions 콘솔에서 상태 머신의 태그를 보고 관리할 수 있습니다. 상태 머신의 세부 정보 페이지에서 태그를 선택합니다.

Step API Functions 액션을 사용한 태그 관리

Step API Functions를 사용하여 태그를 관리하려면 다음 API 작업을 사용하십시오.

타임아웃을 사용하여 Step Functions 워크플로 실행 중단 방지

기본적으로 Amazon States Language는 상태 시스템 정의 제한 시간을 지정하지 않습니다. 명시적 제한 시간 없이 Step Functions는 활동 작업자의 응답만 사용하여 작업이 완료되었는지를 확인합니다. 문제가 발생하고 Activity 및 Task 상태에 TimeoutSeconds 필드가 지정되지 않으면 돌아오지 않는 응답을 기다리기 위해 실행이 멈춥니다.

이를 방지하려면 상태 시스템에 Task를 만들 때 적절한 제한 시간을 지정합니다. 예:


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

태스크 토큰이 포함된 콜백을 사용하는 경우 (. waitForTask토큰) 에서는 하트비트를 사용하고 상태 정의에 HeartbeatSeconds 필드를 추가하는 것이 좋습니다. Task HeartbeatSeconds를 작업 제한 시간보다 작게 설정할 수 있으므로 하트비트 오류로 인해 워크플로가 실패하는 경우 작업이 완료되는 데 오랜 시간이 걸리는 것이 아니라 작업 실패가 원인이라는 것을 알 수 있습니다.


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

자세한 내용은 Amazon States Language 문서의 작업 워크플로 상태 섹션을 참조하세요.

참고

Amazon States Language 정의의 TimeoutSeconds 필드를 사용하여 상태 시스템 제한 시간을 설정할 수 있습니다. 자세한 내용은 Step Functions용 Amazon States 언어 워크플로의 상태 시스템 구조 단원을 참조하십시오.

Step Functions에서 대용량 페이로드를 전달하는 ARNs 대신 Amazon S3 사용

상태 사이에 대용량 데이터 페이로드를 전달하는 실행은 종료될 수 있습니다. 상태 간에 전달하는 데이터가 256KB를 초과할 수 있는 경우 Amazon Simple Storage Service (Amazon S3) 를 사용하여 데이터를 저장하고 파라미터에 있는 버킷의 Amazon 리소스 이름 ARN () 을 파싱하여 버킷 이름과 키 값을 가져옵니다. Payload 또는 실행에서 더 작은 용량의 페이로드를 전달하도록 구현을 조정합니다.

다음 예제에서는 상태 머신이 입력을 다음 주소로 전달합니다. AWS Lambda 함수는 Amazon S3 버킷의 JSON 파일을 처리합니다. 이 상태 머신을 실행한 후 Lambda 함수는 파일의 JSON 콘텐츠를 읽고 파일 콘텐츠를 출력으로 반환합니다.

Lambda 함수 생성

pass-large-payload라는 이름의 다음 Lambda 함수는 특정 Amazon S3 버킷에 저장된 파일의 JSON 콘텐츠를 읽습니다.

참고

이 Lambda 함수를 생성한 후에는 IAM 해당 역할에 Amazon S3 버킷에서 읽을 수 있는 적절한 권한을 제공해야 합니다. 예를 들어, AmazonS3 ReadOnlyAccess 권한을 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

상태 시스템 만들기

다음 상태 시스템은 이전에 만든 Lambda 함수를 간접적으로 호출합니다.


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

입력에서 대량의 데이터를 전달하는 대신 Amazon S3 버킷에 데이터를 저장하고 Payload 파라미터에 버킷의 Amazon Resource Name (ARN) 을 전달하여 버킷 이름과 키 값을 가져올 수 있습니다. 그러면 Lambda 함수가 이를 사용하여 ARN 데이터에 직접 액세스할 수 있습니다. 다음은 상태 시스템 실행을 위한 입력의 예제입니다. 여기서 데이터는 data.json이라는 Amazon S3 버킷의 amzn-s3-demo-large-payload-json에 저장됩니다.


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

Step Functions의 기록 할당량에 도달하지 않도록 새 실행 시작

AWS Step Functions 실행 이벤트 기록에는 25,000개 항목의 엄격한 할당량이 있습니다. 실행이 이벤트 24,999개에 도달하면 다음 이벤트가 발생할 때까지 대기합니다.

이벤트 번호 25,000이 ExecutionSucceeded이면 실행이 성공적으로 완료됩니다.
이벤트 번호 25,000이 ExecutionSucceeded가 아니면 ExecutionFailed 이벤트가 로깅되고 내역 한도에 도달하여 상태 시스템 실행이 실패합니다.

이 장기 실행 할당량에 도달하지 않게 하려면 다음 해결 방법 중 하나를 시도하면 됩니다.

분산 모드에서 Map 상태를 사용합니다. 이 모드에서 Map 상태는 각 반복을 하위 워크플로 실행으로 실행하므로 병렬 하위 워크플로를 동시에 최대 10,000개까지 실행할 수 있습니다. 각 하위 워크플로 실행에는 상위 워크플로와 별개인 자체 실행 내역이 있습니다.
실행 중인 Task 상태에서 직접 새 상태 시스템 실행을 시작합니다. 이러한 중첩된 워크플로 실행을 시작하려면 필요한 매개 변수와 함께 상위 상태 시스템에서 Step StartExecution API Functions의 작업을 사용하십시오. 중첩된 워크플로 사용에 대한 자세한 내용은 Step Functions의 작업 상태에서 워크플로우 실행 시작 또는 Step Functions API 작업을 사용하여 새 실행 계속하기 자습서를 참조하십시오.

작은 정보
중첩된 워크플로의 예를 사용자 환경에 배포하려면 AWS 계정모듈 13 - 중첩된 익스프레스 워크플로를 참조하십시오.
a를 사용하는 패턴을 구현하십시오. AWS Lambda 상태 머신의 새 실행을 시작하여 진행 중인 작업을 여러 워크플로 실행으로 분할할 수 있는 함수입니다. 자세한 내용은 Lambda 함수를 사용하여 Step Functions에서 새 실행 계속 자습서를 참조하세요.

일시적인 Lambda 서비스 예외 처리

AWS Lambda 때때로 일시적인 서비스 오류가 발생할 수 있습니다. 이 경우 Lambda를 간접적으로 호출하면 ClientExecutionTimeoutException, ServiceException, AWSLambdaException 또는 SdkClientException과 같은 500 오류가 발생합니다. 모범 사례로서, 상태 시스템에서 이러한 예외를 사전에 처리하여 Lambda 함수 간접 호출을 Retry하거나 오류를 Catch하는 것이 좋습니다.

Lambda 오류가 Lambda.ErrorName으로 보고됩니다. Lambda 서비스 예외 오류를 다시 시도하려면 다음 Retry 코드를 사용하면 됩니다.


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

참고

Lambda에서 처리되지 않은 오류는 오류 출력에서 Lambda.Unknown으로 보고됩니다. 여기에는 out-of-memory 오류와 함수 타임아웃이 포함됩니다. Lambda.Unknown, States.ALL 또는 States.TaskFailed를 일치시켜 이러한 오류를 처리할 수 있습니다. Lambda에서 최대 간접 호출 수에 도달하면 오류는 Lambda.TooManyRequestsException입니다. HandledLambda Unhandled 및 오류에 대한 자세한 내용은 을 참조하십시오. FunctionError AWS Lambda 개발자 안내서.

자세한 내용은 다음 자료를 참조하세요.

액티비티 태스크를 위한 폴링 시 지연 방지

GetActivityTaskAPItaskToken정확히 한 번만 제공하도록 설계되었습니다. 활동 작업자와 의사 소통 중 taskToken이 삭제되면GetActivityTask 시간이 초과될 때까지 응답을 기다리는 60초 동안 많은 GetActivityTask 요청이 차단될 수 있습니다.

응답을 기다리는 폴링 수가 적은 경우에만 모든 요청을 차단된 요청 뒤쪽의 대기열에 넣고 정지합니다. 그러나 Amazon Resource Name (ARN) 각 활동에 대한 미해결 설문 조사 수가 많고 요청 중 일정 비율이 대기 중인 경우 아직 작업을 taskToken 시작하고 시작할 수 있는 요청이 더 많을 수 있습니다.

프로덕션 시스템의 경우 각 시점에서 활동당 최소 100개의 공개 설문조사를 ARN 실시하는 것이 좋습니다. 하나의 폴링이 차단되고 이 폴링의 일부를 뒤쪽의 대기열에 넣으면 taskToken를 받아 작업을 처리할 수 있는 요청이 여전히 많은 반면 GetActivityTask 요청은 차단됩니다.

작업에 대한 폴링 시 이러한 종류의 지연 시간 문제를 피하려면:

활동 작업자 구현 시 작업에서 별도의 스레드로 poller를 구현하십시오.
각 ARN 시점에서 활동당 최소 100개의 공개 투표를 진행하세요.

참고
공개 투표를 1개당 100개로 확대하는 것은 비용이 많이 들 ARN 수 있습니다. 예를 들어, 100개의 Lambda 함수를 폴링하면 ARN 100개의 폴링 스레드가 있는 단일 Lambda 함수를 사용하는 것보다 100배 더 비쌉니다. 지연 시간 단축 및 비용 최적화를 모두 달성하려면 비동기 I/O가 있는 언어를 사용하고 작업자마다 여러 개의 폴링 스레드를 구현합니다. Poller 스레드가 작업 스레드와 분리되어 있는 경우 활동 작업자의 예제는 예: Ruby의 액티비티 워커를 참조하십시오.

활동 및 활동 작업자에 대한 자세한 내용은 Step Functions의 활동에 대해 알아보기을 참조하십시오.

CloudWatch 리소스 정책 크기 제한을 기록합니다.

로깅이 포함된 상태 머신을 생성하거나 기존 상태 머신을 업데이트하여 로깅을 활성화하는 경우 Step Functions는 지정된 로그 그룹으로 CloudWatch Logs 리소스 정책을 업데이트해야 합니다. CloudWatch 로그 리소스 정책은 5,120자로 제한됩니다.

CloudWatch Logs에서 정책이 크기 제한에 근접하는 것을 감지하면 Logs는 로 CloudWatch 시작하는 로그 그룹에 대한 로깅을 자동으로 활성화합니다. /aws/vendedlogs/

로그 리소스 정책 크기 제한을 피하기 /aws/vendedlogs/ 위해 CloudWatch 로그 로그 그룹 이름에 접두사를 붙일 CloudWatch 수 있습니다. Step Functions 콘솔에서 로그 그룹을 생성하는 경우 제안된 로그 그룹 이름에는 이미 접두사가 붙습니다/aws/vendedlogs/states.

CloudWatch 또한 로그에는 지역별, 계정당 10개의 리소스 정책 할당량이 있습니다. 한 리전에 이미 계정에 대해 10개의 CloudWatch 로그 리소스 정책이 있는 상태 시스템에서 로깅을 활성화하려고 하면 상태 머신이 생성되거나 업데이트되지 않습니다. 견적 기록에 대한 자세한 내용은 CloudWatch 로그 할당량을 참조하십시오.

로그를 Logs로 CloudWatch 보내는 데 문제가 있는 경우 을 참조하십시오. Troubleshooting state machine logging to CloudWatch Logs 일반적인 로깅에 대해 자세히 알아보려면 다음에서 로깅 활성화를 참조하십시오. AWS 서비스.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

문제 해결

Service quotas