기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Step Functions 모범 사례

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

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

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

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

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

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

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

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

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

워크플로의 비용 최적화 관리를 위한 모범 사례 및 지침에 대한 자세한 내용은 비용 효율적인 구축을 참조하십시오. 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 리소스의 비용 센터 및 용도를 나타내는 태그를 추가할 수 있습니다.

보안을 위한 태그 지정

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 문서의 작업 워크플로 상태 섹션을 참조하세요.

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 콘텐츠를 읽습니다.

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개에 도달하면 다음 이벤트가 발생할 때까지 대기합니다.

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

일시적인 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
} ]

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

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

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

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

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

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

활동 및 활동 작업자에 대한 자세한 내용은 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 서비스.