Amazon EventBridge スケジューラのトラブルシューティング - EventBridge スケジューラ
ターゲットエラーロールのアクセス許可サービスクォータパターンとトリガーのタイミングパターンの作成ターゲットがトリガーされているか。テンプレート化されたターゲットとユニバーサルターゲット予期しない呼び出しをトリガーする更新をスケジュールする1 回限りのスケジュールの無効化または有効化

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon EventBridge スケジューラのトラブルシューティング

このセクションのトピックを使用して、Amazon EventBridge スケジューラの一般的な問題のトラブルシューティングを行えます。

スケジュールがターゲットエラーで失敗する

ターゲット呼び出しの失敗は、EventBridge スケジューラの最も一般的な問題の 1 つです。これらの障害は、以下のいくつかの理由で発生する可能性があります。

一般的な原因:

  • ターゲットパラメータがないか、正しくない。

  • ネットワーク接続の問題。

  • API スロットリング。

  • ターゲット設定が正しくない。

トラブルシューティングのステップ

  1. デッドレターキュー (DLQ) を設定する

    • DLQ は、失敗した呼び出しをキャプチャして分析するのに役立ちます。

    • 失敗した呼び出しは、詳細なエラーメッセージとともに DLQ に送信されます。

    • DLQ を設定するには、スケジュール設定に追加します。

    
{
    "DeadLetterConfig": {
        "Arn": "arn:aws:sqs:region:account-id:MyDLQ"
    }
}

    注: DLQ が KMS キーで暗号化されている場合は、キーポリシーで EventBridge スケジューラによる使用が許可されていることを確認してください。

    
{
    "Sid": "Allow EventBridge Scheduler to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "scheduler.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*"
}

  2. API パラメータを確認する

    • ターゲット API コールに必要なすべてのパラメータが存在し、正しくフォーマットされていることを確認します。

    • パラメータ値が許容範囲内であることを確認します。

    • VPC エンドポイントを使用している場合は、VPC から API エンドポイントにアクセスできることを確認します。

  3. ネットワーク設定を確認する

    • 一時的なネットワークの問題が原因で呼び出しが失敗する場合は、再試行ロジックを実装します。

    • 再試行ポリシーの例:

    
{
    "RetryPolicy": {
        "MaximumRetryAttempts": 3,
        "MaximumEventAgeInSeconds": 3600
    }
}

  4. ターゲット固有の設定を確認する

    • テンプレート化されたターゲット (ECS タスクなど) の場合は、スケジュール作成 API の Target.Input パラメータを使用してオーバーライドを指定してください。

    • ターゲットサービスがサポートされており、正しく設定されていることを確認します。

スケジュール実行ロールのアクセス許可の問題

IAM ロールのアクセス許可の問題は、スケジュールの実行が失敗する一般的な理由です。これらの問題のトラブルシューティングと解決方法は次のとおりです。

一般的な原因

  • ターゲットサービスに必要なアクセス許可がない

  • スケジュールのロール設定が正しくない

  • EventBridge スケジューラサービスとの信頼関係がない

  • 暗号化されたリソースにアクセスするためのアクセス許可が不十分

症状

  • CloudWatch での TargetErrorCount メトリクスの増加

  • スケジュール設定で明らかな問題なくスケジュールを実行できない

トラブルシューティングのステップ

  1. CloudWatch メトリクスのモニタリング

    • CloudWatch で TargetErrorCount メトリクスをチェックします。

  2. デッドレターキュー (DLQ) を使用してアクセス許可の問題を確認する

    • スケジュールに合わせて DLQ を設定します。

    • ターゲットにアクセス許可の問題があり、DLQ が正しく設定されている場合、DLQ に失敗した呼び出しとアクセス許可関連のエラーメッセージが表示されます。

    • CloudWatch メトリクスに失敗した実行にもかかわらず DLQ が空のままである場合、EventBridge スケジューラが DLQ 自体に書き込むことを妨げるアクセス許可の問題を示している可能性があります。

    注記

    DLQ 自体に正しいアクセス許可があるかどうかを確認します。暗号化されている場合は、EventBridge スケジューラに KMS キーを使用するアクセス許可があることを確認してください。

  3. 信頼関係を検証する

    • IAM ロールに EventBridge スケジューラとの正しい信頼関係があることを確認します。

    
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "Service": "scheduler.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
    }]
}

  4. スケジュール実行ロールのアクセス許可を確認する

    • スケジュールの実行ロールには、さまざまなターゲットタイプを呼び出すための特定のアクセス許可が必要です。

    • スケジュールの実行ロールポリシーに含めるアクセス許可の例:

    
// 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"
    }]
}

  5. 暗号化されたリソースアクセスを確認する

    • ターゲットが暗号化されたリソース (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"
        }
    ]
}

  6. ロール ARN 設定を確認する

    • スケジュール設定のロール ARN が正しいことを確認します。

    • スケジュールと同じ AWS アカウント およびリージョンにロールが存在することを確認します。

Service Quotas の理解と管理

スケジュールの作成や呼び出しのスロットリングに問題がある場合は、Service Quotas の制限に達している可能性があります。EventBridge スケジューラには、スケジュール数、スケジュールグループ、呼び出しレートのクォータがあり、リージョンによって異なる場合があります。

クォータの問題の特定

クォータ制限に達しているかどうかを判断するには:

  1. CloudWatch メトリクスのモニタリング

    • InvocationThrottleCount メトリクスを確認します。このメトリクスの増加は、呼び出しレートの制限を超えていることを示します。

    • InvocationAttemptCount メトリクスを確認して、現在の使用状況を把握します。

  2. 特定のエラーメッセージを監視する

    • スケジュールを作成または変更する場合、LimitExceededException はスケジュールまたはスケジュールグループの最大数に達したことを示します。

    • スロットリングエラーを返す API コールは、API リクエストのクォータを超えていることを示します。

クォータの問題の解決

クォータ制限に達していると判断した場合:

  1. 現在のスケジュールを確認して最適化します。同様のスケジュールを統合するか、未使用のスケジュールを削除することを検討してください。

  2. API スロットリングの場合は、API コールにバックオフによる再試行を実装します。

  3. より高いクォータが必要な場合は、Service Quotas コンソールから引き上げをリクエストしてください。EventBridge スケジューラを選択し、引き上げるクォータを選択し、ビジネス上の理由とともにリクエストを送信します。

スケジュールパターンとトリガータイミングの問題

ユーザーは、予定された時間にスケジュールがトリガーされない問題に遭遇することがあります。これは最も一般的に、スケジュールパターン、夏時間の変更、または柔軟な時間枠に関する誤解が原因である可能性があります。

一般的な原因

  • cron 式の誤解。

  • 夏時間の変更中の予期しない動作。

  • 柔軟な時間枠に関する混乱。

  • rate 式の誤解。

トラブルシューティングのステップ

  1. cron 式を検証する

    • cron 式の形式が正しいことを確認します。

    • cron 式では日フィールドと曜日フィールドの両方を同時に指定することはできないことに注意してください。

  2. タイムゾーンに関する考慮事項

    • スケジュールの作成時に希望するタイムゾーンを選択します。

    • この調整は UTC に基づいているため、夏時間がスケジュールにどのように影響するかを理解します。

    夏時間への影響の例: GMT 午前 7 時に実行するようにスケジュールを設定した場合:

    • 冬季: スケジュールは GMT 午前 7 時に実行されます (GMT = UTC)

    • 夏季: スケジュールは引き続き UTC 午前 7:00 に実行されます。現在は GMT/BST 午前 6:00 です。

    スケジュールを一年中同じ現地時間で実行する必要がある場合は、スケジュールの作成時に適切なタイムゾーンを選択し、夏時間がどのようにそのタイムゾーンに影響するかを確認してください。

  3. 柔軟な時間枠を理解する

    • 柔軟な時間枠により、EventBridge スケジューラは呼び出しを最適化できます。

    • スケジュールは、時間枠の開始時に正確にトリガーされない場合があります。

    • 実際の呼び出し時間をモニタリングして、動作を理解します。

  4. rate 式と cron 式を確認する

    • rate 式の形式が正しいことを確認します (例: rate(5 minutes)、rate(1 hour))。

    • rate 式と cron 式の両方でスケジュール呼び出しは 1 分間の 0 秒にクランプされないことに注意してください。

    • スケジュールは、指定された 1 分以内にトリガーされる場合がありますが、必ずしも 1 分の正確な開始時にトリガーされるとは限りません。

    例えば、次のようになります。

    • rate(1 hour) を使用するスケジュールは、午後 2:00:45、午後 3:00:32、午後 4:00:18 などに実行される場合があります。

    • 0 * * * ? * (1 時間ごと) に設定された cron スケジュールは、午後 2 時 00 分 15 秒、午後 3 時 00 分 7 秒、午後 4 時 00 分 52 秒などに実行される場合があります。

  5. CloudWatch メトリクスのモニタリング

    • InvocationAttemptCount メトリクスを使用して、スケジュールがトリガーされているかどうかを確認します。

    • 呼び出しが失敗しているかどうか、TargetErrorCount を確認します。

    • デッドレターキューを設定している場合は、InvocationsSentToDeadLetterCount をモニタリングして、失敗した呼び出しを追跡します。

スケジュールパターンと cron 式の作成

ユーザーが、特に cron 式でスケジュールパターンを作成するときに、問題が発生することがよくあります。一般的な問題とその対処方法は次のとおりです。

一般的な問題

  • cron 構文が正しくない

  • サポートされていない cron 機能の使用を試みる

  • 一緒に使用できるフィールドに関する混乱

トラブルシューティングのステップ

  1. cron 式の構文を確認する

    • cron 式が次のような正しい形式であることを確認してください。Minutes Hours Day-of-month Month Day-of-week Year

    • EventBridge スケジューラは、追加の Year フィールドで cron 標準を使用することに注意してください。

  2. 制限を理解する

    • ここで説明するように、日フィールドと曜日フィールドの両方を同時に指定することはできません。

    • 1 分より短い間隔を導き出す cron 式はサポートされていません。

  3. スケジュールプレビュー機能を使用する

    • スケジュールを作成または編集すると、EventBridge スケジューラは次の 10 の実行時間のプレビューを提供します。

    • このプレビューを使用して、スケジュールが意図した時間に実行されることを確認します。

    • プレビューが期待と一致しない場合は、cron 式を確認して調整します。

ターゲットがトリガーされているか。

ターゲットがトリガーされているかどうかを確認するには:

  1. CloudWatch メトリクスを確認します。

    • InvocationAttemptCount は、試行された呼び出しの数を示します

    • TargetErrorCount は、呼び出しが失敗したかどうかを示します

    • TargetErrorThrottledCount は、ターゲットがスロットリングされているかどうかを示します

    • InvocationDroppedCount は、呼び出しが削除されたかどうかを示します

  2. 失敗した呼び出しをキャプチャして分析するようデッドレターキュー (DLQ) を設定します。

テンプレート化されたターゲットとユニバーサルターゲット

「提供されたリクエストが無効: [サービス] がターゲットでサポートされていないサービス」などのエラーが表示された場合は、サポートされていないサービスをテンプレート化されたターゲットとして使用しようとしている可能性があります。

これを解決するには:

  1. 目的のサービスがテンプレート化されたターゲットとしてサポートされているかどうかを確認します。

  2. サポートされていない場合は、代わりにユニバーサルターゲットを使用し、サービスに対して適切な API コールを行うように設定します。

予期しない呼び出しをトリガーする更新をスケジュールする

スケジュールを変更すると、呼び出しに更新されたスケジュールがすぐには反映されない場合があります。変更が有効になるまで、しばらくお待ちください。例えば、元のトリガー時間に近いスケジュールを更新すると、元のスケジュール設定に基づいて呼び出しが表示されることがあります。

1 回限りのスケジュールの無効化または有効化

元のスケジュールされた時刻が経過した後に 1 回限りのスケジュールを再度有効にすると、スケジュールはすぐにターゲットを呼び出すことがあります。これは、スケジュールが元の実行時間より前に無効になっていても発生する可能性があります。

例えば、次のようになります。

  • 現在の時刻: 13:15 UTC

  • 1 回限りのスケジュールの作成: 13:30 UTC

  • スケジュールは 13:30 UTC より前に無効になりました

  • スケジュールが 14:00 UTC に再度有効になりました

  • 結果: ターゲットは、再度有効にするとすぐに呼び出される可能性があります