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

Step Functions 모범 사례

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

Express 워크플로를 사용하여 비용 최적화

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

표준 또는 Express 워크플로 유형 선택이 결제에 미치는 영향은 AWS Step Functions 요금을 참조하세요.

표준 워크플로 내에서 Express 워크플로 중첩

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

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

표준 워크플로를 Express 워크플로로 전환

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

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

Step Functions에서 상태 시스템 및 활동에 태그 지정

AWS Step Functions 는 상태 시스템(표준 및 Express 모두) 및 활동에 태그 지정을 지원합니다. 태그는 리소스를 추적 및 관리하고 AWS Identity and Access Management (IAM) 정책에 더 나은 보안을 제공하는 데 도움이 될 수 있습니다. Step Functions 리소스에 태그를 지정한 후를 사용하여 리소스를 관리할 수 있습니다 AWS Resource Groups. 자세한 방법은 AWS Resource Groups 사용 설명서를 참조하세요.

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

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

DescribeExecution 또는 실행 리소스 ARN을 지정하는 다른 API를 직접적으로 호출하면 태그 기반 권한 부여를 수행하는 동안 Step Functions에서 상태 시스템과 연결된 태그를 사용하여 요청을 수락하거나 거부합니다. 이렇게 하면 상태 시스템 수준에서 상태 시스템 실행에 대한 액세스를 허용하거나 거부할 수 있습니다.

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

비용 할당을 위한 태그 지정

비용 할당 태그를 사용하여 상태 시스템의 목적을 식별하고 해당 조직을 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 Functions API 작업으로 태그 관리

Step Functions API를 사용하여 태그를 관리하려면 다음 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"
}

작업 토큰(.waitForTaskToken)과 함께 콜백을 사용하는 경우 하트비트를 사용하고 Task 상태 정의에 HeartbeatSeconds 필드를 추가하는 것이 좋습니다. 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 문서의 Task 워크플로 상태 섹션을 참조하세요.

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

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

다음 예제에서 상태 시스템은 Amazon S3 버킷의 JSON 파일을 처리하는 AWS Lambda 함수에 입력을 전달합니다. 이 상태 시스템을 실행하면 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 버킷에 저장하고 버킷의 Amazon 리소스 이름(ARN)을 Payload 파라미터에 전달하여 버킷 이름과 키 값을 가져올 수 있습니다. 그러면 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
} ]

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

활동 작업을 폴링할 때 지연 시간 방지

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

응답을 기다리는 폴링 수가 적은 경우에만 모든 요청을 차단된 요청 뒤쪽의 대기열에 넣고 정지합니다. 그러나 활동 Amazon 리소스 이름(ARN)마다 미해결 폴링이 상당수 있고 요청 일부가 대기 상태에 머물러 있으면 계속 taskToken을 가져와 작업을 처리할 수 있는 경우가 많습니다.

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

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

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

CloudWatch Logs 리소스 정책 크기 제한

로깅이 있는 상태 시스템을 만들거나 로깅을 활성화하도록 기존 상태 시스템을 업데이트하는 경우, Step Functions에서 지정된 로그 그룹으로 CloudWatch Logs 리소스 정책을 업데이트해야 합니다. CloudWatch Logs 리소스 정책은 5,120자로 제한됩니다.

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

CloudWatch Logs 리소스 정책 크기 한도에 도달하지 않도록 CloudWatch Logs 로그 그룹 이름에 접두사 /aws/vendedlogs/를 추가할 수 있습니다. Step Functions 콘솔에서 로그 그룹을 만들면 제안된 로그 그룹 이름에 접두사 /aws/vendedlogs/states가 이미 추가되어 있습니다.

또한 CloudWatch Logs는 계정당, 리전당 리소스 정책 10개의 할당량을 가집니다. 계정에 대한 리전에 이미 10개의 CloudWatch Logs 리소스 정책이 있는 상태 시스템에 로깅을 활성화하려고 하면 상태 시스템이 생성되지 않거나 업데이트되지 않습니다. 로깅 할당량에 대한 자세한 정보는 CloudWatch Logs 할당량을 참조하세요.

CloudWatch Logs로 로그를 전송하는 데 문제가 있는 경우 Troubleshooting state machine logging to CloudWatch Logs 섹션을 참조하세요. 일반적인 로깅에 대한 자세한 내용은 AWS 서비스에서 로깅 활성화를 참조하세요.