기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon EventBridge Scheduler 문제 해결 이 섹션의 주제를 통해 일반적인 Amazon EventBridge Scheduler 문제를 해결할 수 있습니다. **Topics** + [대상 오류로 인해 일정이 실패함](#troubleshooting-target-errors) + [일정 실행 역할 권한 문제](#troubleshooting-perms) + [서비스 할당량 이해 및 관리](#troubleshooting-quotas) + [일정 패턴 및 트리거 타이밍 문제](#troubleshooting-timing) + [일정 패턴 및 cron 표현식 생성](#troubleshooting-patterns) + [대상이 트리거되고 있는가?](#troubleshooting-trigger-target) + [템플릿 기반 대상과 범용 대상 비교](#troubleshooting-temp-universal-target) + [잘못된 범용 대상 입력 구성](#troubleshooting-usi-target-input) + [예기치 않은 간접 호출을 트리거하는 일정 업데이트](#troubleshooting-temp-universal-target-invoke) + [일회성 일정 비활성화 또는 활성화](#troubleshooting-temp-universal-target-enable) ## 대상 오류로 인해 일정이 실패함 대상 간접 호출 실패는 EventBridge Scheduler에서 가장 일반적인 문제 중 하나입니다. 이러한 실패는 다음과 같은 여러 가지 이유로 발생할 수 있습니다. ### 일반적인 원인: + 대상 파라미터가 누락되었거나 잘못됨. + 네트워크 연결 문제. + API 스로틀링. + 잘못된 대상 구성. ### 문제 해결 단계 1. **Dead Letter Queue(DLQ) 설정** + DLQ는 실패한 간접 호출을 캡처하고 분석하는 데 도움이 됩니다. + 실패한 간접 호출은 자세한 오류 메시지와 함께 DLQ로 전송됩니다. + [DLQ를 구성](configuring-schedule-dlq.md)하려면 일정 구성에 추가합니다. ``` { "DeadLetterConfig": { "Arn": "arn:aws:sqs:region:account-id:MyDLQ" } } ``` 참고: DLQ가 KMS 키로 암호화된 경우 키 정책에서 EventBridge Scheduler가 이를 사용하도록 허용하는지 확인합니다. ``` { "Sid": "Allow EventBridge Scheduler to use the key", "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "*" } ``` 1. **API 파라미터 확인** + 대상 API 직접 호출에 필요한 모든 파라미터가 존재하고 올바른 형식인지 확인합니다. + 파라미터 값이 허용된 범위 내에 있는지 확인합니다. + VPC 엔드포인트를 사용하는 경우 VPC에서 API 엔드포인트에 액세스할 수 있는지 확인합니다. 1. **네트워크 구성 검토** + 일시적인 네트워크 문제로 인해 직접 호출이 실패하는 경우 [재시도](https://docs.aws.amazon.com/scheduler/latest/APIReference/API_RetryPolicy.html) 로직을 구현합니다. + 재시도 정책 예: ``` { "RetryPolicy": { "MaximumRetryAttempts": 3, "MaximumEventAgeInSeconds": 3600 } } ``` 1. **대상별 구성 확인** + 템플릿 기반 대상(예: ECS 작업)의 경우 일정 생성 API의 `Target.Input` 파라미터를 통해 재정의를 제공해야 합니다. + 대상 서비스가 [지원](managing-targets-templated.md)되고 올바르게 구성되었는지 확인합니다. ## 일정 실행 역할 권한 문제 IAM 역할 권한 문제는 일정 실행 실패의 일반적인 원인입니다. 이러한 문제를 해결하는 방법은 다음과 같습니다. ### 일반적인 원인 + 대상 서비스에 필요한 권한이 없음 + 일정에 잘못된 역할 구성 + EventBridge Scheduler 서비스와의 신뢰 관계가 없음 + 암호화된 리소스에 액세스할 수 있는 권한이 충분하지 않음 ### 증상 + CloudWatch에서 `TargetErrorCount` 지표 증가 + 일정 구성에서 명백한 문제 없이 일정이 실행되지 않음 ### 문제 해결 단계 1. **CloudWatch 지표 모니터링** + CloudWatch에서 `TargetErrorCount` 지표를 확인합니다. 1. **Dead Letter Queue(DLQ)를 사용하여 권한 문제 확인** + 일정에 맞게 DLQ를 구성합니다. + 대상에 권한 문제가 있고 DLQ가 올바르게 구성된 경우 권한 관련 오류 메시지와 함께 DLQ에 실패한 간접 호출이 표시됩니다. + CloudWatch 지표에 실행 실패가 표시되더라도 DLQ가 비어 있는 경우 이는 EventBridge Scheduler가 DLQ 자체에 쓸 수 없는 권한 문제를 나타낼 수 있습니다. **참고** DLQ 자체에 올바른 권한이 있는지 확인합니다. 암호화된 경우 EventBridge Scheduler에 KMS 키를 사용할 수 있는 권한이 있는지 확인합니다. 1. **신뢰 관계 확인** + IAM 역할이 EventBridge Scheduler와 올바른 신뢰 관계를 갖고 있는지 확인합니다. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": "sts:AssumeRole" }] } ``` 1. **일정 실행 역할 권한 확인** + 일정의 실행 역할에는 다양한 대상 유형을 간접적으로 호출할 수 있는 특정 권한이 필요합니다. + 일정의 실행 역할 정책에 포함할 권한의 예: ``` // For Lambda function targets - add to schedule execution role { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:region:account-id:function:function-name" }] } // For SQS queue targets - add to schedule execution role { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "sqs:SendMessage" ], "Resource": "arn:aws:sqs:region:account-id:queue-name" }] } ``` 1. **암호화된 리소스 액세스 확인** + 대상이 암호화된 리소스(예: KMS 암호화 SQS 대기열)를 사용하는 경우 역할에 KMS 키를 사용할 권한이 있는지 확인합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:region:account-id:key/key-id" } ] } ``` 1. **역할 ARN 구성 확인** + 일정 구성의 역할 ARN이 올바른지 확인합니다. + 역할이 일정과 동일한 AWS 계정 및 리전에 있는지 확인합니다. ## 서비스 할당량 이해 및 관리 일정을 생성하거나 스로틀링된 간접 호출을 보는 데 문제가 있는 경우 서비스 할당량 한도에 도달했을 수 있습니다. EventBridge Scheduler에는 일정, 일정 그룹 및 간접 호출 비율 수에 대한 할당량이 있으며, 이는 리전에 따라 다를 수 있습니다. ### 할당량 문제 식별 할당량 한도에 도달하고 있는지 확인하려면: 1. **CloudWatch 지표 모니터링** + `InvocationThrottleCount` 지표를 확인합니다. 이 지표가 증가하면 간접 호출 속도 한도를 초과하고 있음을 나타냅니다. + `InvocationAttemptCount` 지표를 검토하여 현재 사용량을 파악합니다. 1. **특정 오류 메시지 확인** + 일정을 생성하거나 수정할 때 `LimitExceededException`은 최대 일정 또는 일정 그룹 수에 도달했음을 나타냅니다. + 스로틀링 오류를 반환하는 API 직접 호출은 API 요청 할당량을 초과하고 있음을 나타냅니다. ### 할당량 문제 해결 할당량 한도에 도달하고 있는지 확인하려면: 1. 현재 일정을 검토하고 최적화합니다. 유사한 일정을 통합하거나 사용하지 않는 일정을 제거하는 것이 좋습니다. 1. API 스로틀링의 경우 API 직접 호출에서 [백오프를 사용한 재시도](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)를 구현합니다. 1. 더 높은 할당량이 필요한 경우 Service Quotas 콘솔을 통해 증가를 요청할 수 있습니다. EventBridge Scheduler를 선택하고 늘려야 할 할당량을 선택한 다음 사업성 근거와 함께 요청을 제출합니다. ## 일정 패턴 및 트리거 타이밍 문제 때때로 사용자에게 일정이 예상 시간에 트리거되지 않는 문제가 발생합니다. 이는 대개 일정 패턴, 일광 절약 시간 변경 또는 유연한 기간에 대한 오해 때문일 수 있습니다. ### 일반적인 원인 + cron 표현식의 잘못된 해석. + 일광 절약 시간 변경 중 예기치 않은 동작. + 유연한 기간에 대한 혼동. + rate 표현식에 대한 오해. ### 문제 해결 단계 1. **cron 표현식 확인** + cron 표현식의 형식이 올바른지 확인합니다. + 한 cron 표현식에서 day-of-month와 day-of-week 필드를 동시에 지정할 수는 없습니다. 1. **시간대 고려 사항** + 일정을 생성할 때 원하는 시간대를 선택합니다. + 이 조정은 UTC를 기반으로 하므로 일광 절약 시간이 일정에 미치는 영향을 이해합니다. 일광 절약 영향의 예: GMT 기준 오전 7시에 실행되도록 일정을 구성하는 경우: + 겨울: 일정이 GMT 기준 오전 7시(GMT = UTC)에 실행됩니다. + 여름: 일정이 여전히 UTC 기준 오전 7시(GMT/BST 기준 오전 6시)에 실행됩니다. 일정이 연중 동일한 현지 시간에 실행되어야 하는 경우 일정을 생성할 때 적절한 시간대와 일광 절약이 해당 시간대에 미치는 영향을 선택해야 합니다. 1. **유연한 기간 이해** + [유연한 기간](managing-schedule-flexible-time-windows.md)을 통해 EventBridge Scheduler가 간접 호출을 최적화할 수 있습니다. + 일정이 기간 시작 시 정확히 트리거되지 않을 수 있습니다. + 실제 간접 호출 시간을 모니터링하여 동작을 이해합니다. 1. **rate 표현식 및 cron 표현식 검토** + rate 표현식이 올바른 형식(예: `rate(5 minutes)`, `rate(1 hour)`)인지 확인합니다. + rate 표현식과 cron 표현식 모두에서 일정 간접 호출이 1분의 0초로 고정되지 않는다는 점에 유의하세요. + 일정은 지정된 분 내에 트리거될 수 있지만 반드시 정확하게 시작되는 것은 아닙니다. 예제: + `rate(1 hour)`의 일정은 오후 2:00:45, 오후 3:00:32, 오후 4:00:18 등에 실행될 수 있습니다. + `0 * * * ? *`(매시간)으로 설정된 cron 일정은 오후 2:00:15, 오후 3:00:07, 오후 4:00:52 등에 실행될 수 있습니다. 1. **CloudWatch 지표 모니터링** + `InvocationAttemptCount` 지표를 사용하여 일정이 트리거되고 있는지 확인합니다. + 간접 호출이 실패하는 경우 `TargetErrorCount`를 확인합니다. + Dead Letter Queue(DLQ)를 구성한 경우 `InvocationsSentToDeadLetterCount`를 모니터링하여 실패한 간접 호출을 추적합니다. ## 일정 패턴 및 cron 표현식 생성 일정 패턴을 생성할 때 특히 cron 표현식에서 문제가 발생하는 경우가 많습니다. 다음은 몇 가지 일반적인 문제와 이를 해결하는 방법입니다. ### 일반적인 문제 + 잘못된 cron 구문 + 지원되지 않는 cron 기능 사용 시도 + 함께 사용할 수 있는 필드에 대한 혼동 ### 문제 해결 단계 1. **cron 표현식 구문 검토** + cron 표현식이 올바른 [형식](schedule-types.md#cron-based)(`Minutes Hours Day-of-month Month Day-of-week Year`)을 따르는지 확인합니다. + EventBridge Scheduler는 추가 연도 필드와 함께 cron 표준을 사용합니다. 1. **제한 사항 이해** + [여기](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html#eb-cron-expressions)에 설명된 대로 day-of-month와 day-of-week 필드를 동시에 지정할 수 없습니다. + 1분보다 빠른 속도로 이어지는 cron 표현식은 지원되지 않습니다. 1. **일정 미리 보기 기능 사용** + 일정을 생성하거나 편집할 때 EventBridge Scheduler는 다음 10회의 실행 시간에 대한 미리 보기를 제공합니다. + 이 미리 보기를 사용하여 일정이 의도한 시간에 실행되는지 확인합니다. + 미리 보기가 예상과 다를 경우 cron 표현식을 검토하고 조정합니다. ## 대상이 트리거되고 있는가? 대상이 트리거되고 있는지 확인하려면: 1. CloudWatch 지표 확인: + `InvocationAttemptCount`는 간접 호출 시도 횟수를 보여줍니다. + `TargetErrorCount`는 간접 호출이 실패했는지 여부를 나타냅니다. + `TargetErrorThrottledCount`는 대상이 스로틀링되고 있는지 여부를 보여줍니다. + `InvocationDroppedCount`는 간접 호출이 중단되었는지 여부를 나타냅니다. 1. 실패한 간접 호출을 캡처하고 분석하도록 [Dead Letter Queue(DLQ)를 구성](configuring-schedule-dlq.md)합니다. ## 템플릿 기반 대상과 범용 대상 비교 “Invalid request provided: [service] is not a supported service for a target”과 같은 오류가 발생하는 경우 지원되지 않는 서비스를 템플릿 지정 대상으로 사용하려고 시도했을 수 있습니다. 이 문제를 해결하려면: 1. 원하는 서비스가 [템플릿 기반 대상](managing-targets-templated.md)으로 지원되는지 확인합니다. 1. 지원되지 않는 경우 [범용 대상](managing-targets-universal.md)을 대신 사용하고 서비스에 대한 적절한 API 직접 호출을 수행하도록 구성합니다. ## 잘못된 범용 대상 입력 구성 [범용 대상으로](managing-targets-universal.md) 일정을 생성하면 EventBridge 스케줄러는 대상 ARN 형식을 검증하지만 다운스트림 서비스의 API에 대해 `Input` 필드의 내용을 검증하지 않습니다. 즉,에 호출 시 대상 서비스가 거부하는 값이 `Input` 포함되어 있더라도 일정을 성공적으로 생성할 수 있습니다. 잘못된 대상 입력 구성이 있는 일정은 구성된 표현식에서 트리거되지만 호출할 때마다 실패합니다. 일정이 호출될 때까지 잘못된 구성을 발견하지 못할 수 있으며, 생성 후 몇 시간 또는 며칠이 걸릴 수 있습니다. ### 증상 + 일정은 오류 없이 생성되었지만 `TargetErrorCount` CloudWatch 지표는 호출할 때마다 증가합니다. + DLQ 메시지에는가 아닌 대상 서비스(예: `InvalidParameterValueException` 또는 `ValidationException`)의 오류 코드가 포함됩니다`AWS.Scheduler.InternalServerError`. + DLQ 메시지`ERROR_MESSAGE`의는 특정 입력 파라미터 검증 실패를 참조합니다. ### 예제 다음 예제에서는 범용 대상()에 AWS Lambda 대한 일반적인 잘못된 입력 구성을 보여줍니다`arn:aws:scheduler:::aws-sdk:lambda:invoke`. **불일치 한정자** 다음 입력이 포함된 일정은 `2`의 버전`FunctionName`과 `1` `Qualifier` 필드의 버전을 지정합니다. ``` { "FunctionName": "MyFunction:2", "Qualifier": "1" } ``` 이 일정은 성공적으로 생성되지만 모든 호출은 실패합니다. DLQ 메시지에는 다음이 포함됩니다. + `ERROR_CODE`: `InvalidParameterValueException` + `ERROR_MESSAGE`: `The derived qualifier from the function name does not match the specified qualifier.` **잘못된 함수 이름** 다음 입력이 있는 일정은에 대한 공백 전용 값을 지정합니다`FunctionName`. ``` { "FunctionName": " " } ``` DLQ 메시지에는 다음이 포함됩니다. + `ERROR_CODE`: `ValidationException` + `ERROR_MESSAGE`: 함수 이름이 필수 패턴과 일치하지 않음을 나타내는 검증 오류입니다. ### 해결 방법 1. **DLQ를 구성합니다.** 범용 대상[을 사용하는 일정에 대해 항상 배달 못한 편지 대기열을 구성합니다](configuring-schedule-dlq.md). DLQ 메시지 속성(`ERROR_CODE` 및 `ERROR_MESSAGE`)에는 잘못된 입력 파라미터를 식별하는 대상 서비스에서 반환되는 특정 오류가 포함됩니다. 1. **대상 서비스 API에 대해 입력 파라미터를 검증합니다.** 일정을 생성하기 전에 대상 API를 직접 호출하여 `Input` 필드의 JSON에 유효한 값이 포함되어 있는지 확인합니다. 예를 들어 API를 사용하여 동일한 파라미터로 AWS Lambda 함수를 AWS Lambda `Invoke` 호출하여 요청이 성공했는지 확인합니다. 1. **일회성 일정으로 테스트합니다.** 반복 일정을 구성하기 전에 일회성 일정을 생성하여 대상 간접 호출이 성공하는지 확인합니다. 1. **대상 서비스 API 참조를 검토합니다.** 대상 서비스에 대한 API 참조를 확인하여 필수 파라미터, 유효한 값 범위 및 제약 조건을 확인합니다. 의 경우 *AWS Lambda 개발자 안내서*의 [호출](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)을 AWS Lambda `Invoke`참조하세요. ## 예기치 않은 간접 호출을 트리거하는 일정 업데이트 일정을 변경하는 경우 간접 호출에 업데이트된 일정이 즉시 반영되지 않을 수 있습니다. 변경 사항이 적용될 때까지 잠시 기다리세요. 예를 들어 원래 트리거 시간에 가깝게 일정을 업데이트하면 원래 일정 구성을 기반으로 간접 호출이 표시될 수 있습니다. ## 일회성 일정 비활성화 또는 활성화 원래 예약된 시간이 경과한 후 일회성 일정을 다시 활성화하면 일정이 대상을 즉시 간접적으로 호출할 수 있습니다. 이는 원래 실행 시간 이전에 일정이 비활성화된 경우에도 발생할 수 있습니다. 예제: + 현재 시간: 13:15 UTC + 13:30 UTC에 일회성 일정 생성 + 13:30 UTC 이전에 일정 비활성화 + 14:00 UTC에 일정 다시 활성화 + 결과: 다시 활성화하는 즉시 대상이 간접적으로 호출될 수 있습니다.