작업 구성 작동 방식 - AWS IoT Core
작업 롤아웃, 예약 및 중단 구성작업 실행 제한 시간 및 재시도 구성

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

작업 구성 작동 방식

작업을 배포할 때 롤아웃 및 중단 구성을 사용하고 작업을 실행할 때 제한 시간 및 재시도 구성을 사용합니다. 다음 섹션은 이러한 구성의 작동 방식에 대한 자세한 정보를 보여줍니다.

작업 롤아웃, 예약 및 중단 구성

작업 롤아웃, 예약, 중단 구성을 사용하여 작업 문서를 수신하는 디바이스 수를 정의하고, 작업 롤아웃을 예약하고, 작업을 취소하는 기준을 결정할 수 있습니다.

대상에게 대기 중인 작업 실행을 얼마나 빨리 알릴지 지정할 수 있습니다. 또한 단계별 롤아웃을 생성하여 업데이트, 재부팅 및 기타 작업을 효과적으로 관리할 수 있습니다. 대상에게 알릴 방법을 지정하려면 작업 롤아웃 속도를 사용합니다.

작업 롤아웃 속도

상수 롤아웃 속도 또는 기하급수적인 롤아웃 속도를 사용하여 롤아웃 구성을 생성할 수 있습니다. 분당 알릴 최대 작업 대상 수를 지정하려면 상수 롤아웃 속도를 사용합니다.

AWS IoT 다양한 기준과 임계값이 충족되면 기하급수적인 롤아웃 비율을 사용하여 작업을 배포할 수 있습니다. 실패한 작업 수가 지정한 기준과 일치하면 작업 롤아웃을 취소할 수 있습니다. 작업을 생성할 때 JobExecutionsRolloutConfig 객체를 사용하여 작업 롤아웃 속도 기준을 설정합니다. 또한 작업 생성 시 AbortConfig 객체를 사용하여 작업 중단 기준을 설정합니다.

다음 예에서는 롤아웃 속도가 작동하는 방식을 보여줍니다. 분당 50개의 기본 속도, 증분 계수 2, 알림을 받고 성공한 분당 디바이스의 수 1,000을 사용하는 작업 롤아웃을 예로 들면, 작업은 분당 50개의 작업을 실행하는 속도로 시작되고 1000개의 사물이 작업 실행 알림을 수신하거나 1,000개의 성공적인 작업 실행이 발생할 때까지 해당 속도로 계속됩니다.

다음 표는 처음 4회의 증가에 걸쳐 롤아웃이 어떻게 진행되는지 보여줍니다.

분당 롤아웃 속도

50

100

200

400

속도 증가를 충족하기 위한 알림을 받는 디바이스 또는 성공한 작업 실행의 수

1,000

2,000

3,000

4,000
참고

최대 동시 작업 제한인 500개 작업(isConcurrent = True)에 도달하면 모든 활성 작업은 IN-PROGRESS 상태로 유지되며 동시 작업 수가 499개 이하(isConcurrent = False))가 될 때까지 새 작업 실행이 롤아웃되지 않습니다. 이는 스냅샷 작업과 연속 작업에 적용됩니다.

isConcurrent = True인 경우 현재 작업이 대상 그룹의 모든 디바이스에 작업 실행을 롤아웃하는 중입니다. isConcurrent = False인 경우 이 작업은 대상 그룹의 모든 디바이스에 대한 모든 작업 실행 롤아웃을 완료한 것입니다. 대상 그룹의 모든 디바이스가 최종 상태에 도달하거나 대상 그룹의 임계값 백분율에 도달할 때(작업 중단 구성을 선택한 경우) 상태가 업데이트됩니다. isConcurrent = True 및 isConcurrent = False인 경우 작업 수준 상태는 모두 IN_PROGRESS입니다.

활성 및 동시 작업 제한에 대한 자세한 내용은 활성 및 동시 작업 제한 섹션을 참조하세요.

동적 사물 그룹을 사용한 연속 작업의 작업 롤아웃 속도

연속 작업을 사용하여 플릿에 원격 작업을 롤아웃하면 AWS IoT 잡스는 대상 사물 그룹의 장치에 대한 작업 실행을 롤아웃합니다. 새 디바이스가 동적 사물 그룹에 추가되는 경우 이러한 작업 실행은 작업이 생성된 후에도 새로 추가된 디바이스로 계속 롤아웃됩니다.

롤아웃 구성은 작업을 만들 때까지 그룹에 추가된 디바이스에 대해서만 롤아웃 속도를 제어할 수 있습니다. 작업이 생성된 후 새 디바이스에 대해 디바이스가 대상 그룹에 조인하자마자 거의 실시간으로 작업 실행이 만들어집니다.

미리 결정된 시작 시간, 종료 시간 및 종료 동작(종료 시간에 도달할 때 각 작업 실행에 발생하는 일)을 사용하여 최대 1년 전에 연속 또는 스냅샷 작업을 예약할 수 있습니다. 또한 연속 작업의 빈도, 시작 시간 및 기간을 유연하게 조정할 수 있는 선택적 반복 유지 관리 기간을 만들어 대상 그룹 내의 모든 디바이스에 작업 문서를 롤아웃할 수 있습니다.

작업 예약 구성

시작 시간

예약된 작업의 시작 시간은 작업이 대상 그룹의 모든 디바이스에 대한 작업 문서 롤아웃을 시작할 미래 날짜 및 시간입니다. 예약된 작업의 시작 시간은 연속 작업과 스냅샷 작업에 적용됩니다. 예약된 작업이 처음 생성되면 SCHEDULED 상태를 유지합니다. 선택한 startTime에 도달하면 IN_PROGRESS로 업데이트되고 작업 문서 롤아웃이 시작됩니다. startTime은 예약된 작업을 처음 생성한 날짜 및 시간으로부터 1년 이내여야 합니다.

API 명령 또는 를 사용할 startTime 때의 구문에 대한 자세한 내용은 타임스탬프를 참조하십시오. AWS CLI

일광 절약 시간(DST)을 준수하는 위치에서 반복되는 유지 관리 기간 중에 수행되는 선택적 예약 구성을 사용하는 작업의 경우 DST에서 표준 시간으로, 표준 시간에서 DST로 전환하면 시간이 1시간 변경됩니다.

참고

에 표시된 시간대는 현재 시스템 AWS Management Console 시간대입니다. 그러나 이러한 시간대는 시스템에서 UTC로 변환됩니다.

종료 시간

예약된 작업의 종료 시간은 작업이 대상 그룹의 나머지 디바이스에 대한 작업 문서 롤아웃을 중지할 미래 날짜 및 시간입니다. 예약된 작업의 종료 시간은 연속 작업과 스냅샷 작업에 적용됩니다. 예약된 작업이 선택한 endTime에 도달하고 모든 작업 실행이 최종 상태에 도달하면 상태 상태가 IN_PROGRESS에서 COMPLETED로 업데이트됩니다. endTime은 예약된 작업을 처음 생성한 날짜 및 시간으로부터 2년 이내여야 합니다. startTime과 endTime 사이의 최소 기간은 30분입니다. 작업이 endTime에 도달할 때까지 작업 실행 재시도가 수행되며 endBehavior에 따라 이후 진행 방법이 결정됩니다.

API 명령 또는 를 사용할 endTime 때의 구문에 대한 자세한 내용은 타임스탬프를 참조하십시오. AWS CLI

일광 절약 시간(DST)을 준수하는 위치에서 반복되는 유지 관리 기간 중에 수행되는 선택적 예약 구성을 사용하는 작업의 경우 DST에서 표준 시간으로, 표준 시간에서 DST로 전환하면 시간이 1시간 변경됩니다.

참고

에 표시된 시간대는 현재 시스템 AWS Management Console 시간대입니다. 그러나 이러한 시간대는 시스템에서 UTC로 변환됩니다.

종료 동작

예약된 작업의 종료 동작은 작업이 선택한 endTime에 도달할 때 해당 작업 및 완료되지 않은 모든 작업 실행에 발생하는 일을 결정합니다.

작업 또는 작업 템플릿을 생성할 때 선택할 수 있는 종료 동작은 다음과 같습니다.

  • STOP_ROLLOUT

    • STOP_ROLLOUT은 작업 대상 그룹의 나머지 모든 디바이스에 대한 작업 문서 롤아웃을 중지합니다. 또한 모든 QUEUED 및 IN_PROGRESS 작업 실행은 최종 상태에 도달할 때까지 계속됩니다. CANCEL 또는 FORCE_CANCEL을 선택하지 않는 한, 이것이 기본 종료 동작입니다.

  • CANCEL

    • CANCEL은 작업 대상 그룹의 나머지 모든 디바이스에 대한 작업 문서 롤아웃을 중지합니다. 또한 모든 QUEUED 작업 실행은 취소되지만 모든 IN_PROGRESS 작업 실행은 최종 상태에 도달할 때까지 계속됩니다.

  • FORCE_CANCEL

    • FORCE_CANCEL은 작업 대상 그룹의 나머지 모든 디바이스에 대한 작업 문서 롤아웃을 중지합니다. 또한 모든 QUEUED 및 IN_PROGRESS 작업 실행이 취소됩니다.

참고

선택하려면 하나를 선택해야 합니다. endbehavior endtime

최대 기간

예약된 작업의 최대 기간은 startTime 및 endTime에 관계없이 2년 이하여야 합니다.

다음 테이블은 예약된 작업의 일반적인 기간 시나리오입니다.

예약된 작업 예시 번호 startTime endTime 최대 기간

1

최초 작업 생성 직후

최초 작업 생성 1년 후

1년

2

최초 작업 생성 1개월 후

최초 작업 생성 13개월 후

1년

3

최초 작업 생성 1년 후

최초 작업 생성 2년 후

1년

4

최초 작업 생성 직후

최초 작업 생성 2년 후

2년

반복 유지 관리 기간

유지 관리 기간은 AWS Management Console CreateJob 및 CreateJobTemplate API의 스케줄링 구성 SchedulingConfig 내에 있는 선택적 구성입니다. 미리 정해진 시작 시간, 기간 및 유지 관리 기간이 발생하는 빈도(매일, 매주 또는 매월)로 반복 유지 관리 기간을 설정할 수 있습니다. 유지 관리 기간은 연속 작업에만 적용됩니다. 반복 유지 관리 기간의 최대 기간은 23시간 50분입니다.

다음 다이어그램은 선택적으로 유지 관리 기간이 적용된 다양한 예약된 작업 시나리오의 작업 상태를 보여줍니다.

특정 이벤트가 발생했을 때 스케줄링됨, IN_PROGRESS, 취소됨, DELETION_IN_PROGRESS 등의 상태가 진행되는 연속 작업의 수명 주기를 보여주는 다이어그램입니다.

작업 상태에 대한 자세한 내용은 작업 및 작업 실행 상태 섹션을 참조하세요.

참고

유지 관리 기간 중에 작업이 endTime에 도달하면 IN_PROGRESS에서 COMPLETED로 업데이트됩니다. 또한 나머지 모든 작업 실행은 작업의 endBehavior에 따라 실행됩니다.

Cron 표현식

사용자 지정 빈도를 사용하여 유지 관리 기간 중에 작업 문서를 롤아웃하는 예약된 작업의 경우 사용자 지정 빈도는 cron 표현식을 사용하여 입력됩니다. Cron 표현식에는 각각 공백으로 구분되는 필수 필드 6개가 있습니다.

구문

cron(fields)
필드 값 와일드카드

Minutes

0~59

, - * /

시간

0~23

, - * /

D. ay-of-month

1~31

, - * ? / L W

월

1-12 또는 JAN-DEC

, - * /

D ay-of-week

1-7 또는 SUN-SAT

, - * ? L #

연도

1970~2199

, - * /
와일드카드

  • ,(쉼표) 와일드카드는 추가 값을 포함합니다. 예컨대, Month 필드에서 JAN, FEB, MAR은 1월, 2월, 3월을 포함한다는 의미입니다.

  • -(대시) 와일드카드는 범위를 지정합니다. 예컨대, Day 필드에서 1-15는 지정된 달의 1일에서 15일까지 포함한다는 의미입니다.

  • *(별표) 와일드카드는 필드의 모든 값을 포함합니다. '시간' 필드에서 *는 모든 시간을 포함한다는 의미입니다. ay-of-month D와 D ay-of-week 필드 모두에 *를 사용할 수 없습니다. 필드 중 하나에 사용할 경우 다른 하나에는 반드시 ?를 사용해야 합니다.

  • /(슬래시) 와일드카드로 증분을 지정합니다. 예를 들어, '분' 필드에 1/10을 입력하면 지정한 시간의 1분부터 시작해서 매 10분 간격을 지정할 수 있습니다(즉, 11분, 21분, 31분 등).

  • ?(물음표) 와일드카드는 어떤 한 가지나 다른 것을 지정합니다. D ay-of-month 필드에 7을 입력할 수 있고, 7일이 무슨 요일인지 신경 쓰지 않는다면? D ay-of-week 필드에.

  • D ay-of-month 또는 D ay-of-week 필드의 L 와일드카드는 해당 월 또는 주의 마지막 날을 지정합니다.

  • D ay-of-month 필드의 W 와일드카드는 요일을 지정합니다. D ay-of-month 필드에서 해당 월의 3일에 가장 가까운 요일을 3W 지정합니다.

  • D ay-of-week 필드의 # 와일드카드는 한 달 내 특정 요일의 특정 인스턴스를 지정합니다. 예를 들어, 3#2는 그 달의 두 번째 화요일입니다. 3은 각 주의 셋째 날이므로 화요일을 나타내고 2는 그 달의 두 번째 해당 요일입니다.

    참고

    '#' 문자를 사용하는 경우 day-of-week 필드에 표현식을 하나만 정의할 수 있습니다. 예를 들어 "3#1,6#3"은 두 개의 표현식으로 해석되기 때문에 유효하지 않습니다.

제한 사항

  • 동일한 cron 표현식에 D ay-of-month ay-of-week 필드와 D 필드를 지정할 수 없습니다. 이들 필드 중 하나에 값(또는 *)을 지정하는 경우에는 다른 필드에서 반드시 ?를 사용해야 합니다.

예제

반복 유지 관리 기간의 startTime에 cron 표현식을 사용할 때는 다음 샘플 cron 문자열을 참조하세요.

분 시간 일 월 요일 연도 의미
0 10 * * ? *

매일 오전 10시(UTC)에 실행
15 12 * * ? *

매일 오후 12시 15분(UTC)에 실행
0 18 ? * 월-금 *

매주 월요일부터 금요일까지 오후 6시(UTC)에 실행
0 8 1 * ? *

매월 1일 오전 8시(UTC)에 실행

반복 유지 관리 기간 종료 로직

유지 관리 기간 중 작업 롤아웃이 현재 유지 관리 기간 종료 시점에 도달하면 다음과 같은 작업이 수행됩니다.

  • 작업은 대상 그룹의 나머지 모든 디바이스에 대한 작업 문서 롤아웃을 중지합니다. 다음 유지 관리 기간의 startTime에 재개됩니다.

  • 상태가 QUEUED인 모든 작업 실행은 다음 유지 관리 기간의 startTime까지 QUEUED 상태로 유지됩니다. 다음 기간에는 디바이스가 작업 문서에 지정된 작업을 수행할 준비가 되었을 때 IN_PROGRESS로 전환할 수 있습니다.

  • 상태가 IN_PROGRESS인 모든 작업 실행은 최종 상태에 도달할 때까지 작업 문서에 지정된 작업을 계속 수행합니다. JobExecutionsRetryConfig에 지정된 대로 모든 재시도는 다음 유지 관리 기간의 startTime에 이루어집니다.

이 구성을 사용하여 디바이스의 임계값 비율이 해당 기준을 충족할 때 작업을 취소하는 기준을 생성할 수 있습니다. 예를 들어, 이 구성을 사용하여 다음과 같은 경우 작업을 취소할 수 있습니다.

  • 임계값 비율의 디바이스가 작업 실행 알림을 받지 못하는 경우(예: 디바이스가 무선 업데이트(OTA)와 호환되지 않는 경우). 이 경우 디바이스가 REJECTED 상태를 보고할 수 있습니다.

  • 임계값 비율의 디바이스가 작업 실행에 대해 실패를 보고하는 경우(예: Amazon S3 URL에서 작업 문서를 다운로드하려고 할 때 디바이스 연결이 끊어지는 경우). 이와 같은 경우 디바이스는 FAILURE 상태를 AWS IoT에 보고하도록 프로그래밍되어야 합니다.

  • 작업 실행이 시작된 후 임계값 비율의 디바이스에 대해 작업 실행이 시간 초과되어 TIMED_OUT 상태가 보고되는 경우.

  • 재시도 실패가 여러 번 있는 경우. 재시도 구성을 추가하는 경우 각 재시도가 AWS 계정에 추가 요금을 발생시킬 수 있습니다. 이와 같은 경우 작업을 취소하면 대기열에 있는 작업 실행을 취소하고 이러한 실행에 대한 재시도를 방지할 수 있습니다. 재시도 구성 및 이 구성을 중단 구성과 함께 사용하는 것에 대한 자세한 내용은 작업 실행 제한 시간 및 재시도 구성 섹션을 참조하세요.

AWS IoT 콘솔 또는 AWS IoT Jobs API를 사용하여 작업 중단 조건을 설정할 수 있습니다.

작업 실행 제한 시간 및 재시도 구성

작업 실행 제한 시간 구성을 사용하면 작업 실행이 설정된 기간보다 오래 진행되는 경우 작업 알림을 전송할 수 있습니다. 작업 실행 재시도 구성을 사용하면 작업이 실패하거나 시간 초과되는 경우 실행을 재시도할 수 있습니다.

작업 실행 시간 제한 구성을 사용하면 작업 실행이 예상치 않게 장시간 동안 IN_PROGRESS 상태에 멈출 때마다 알림을 받을 수 있습니다. 작업이 IN_PROGRESS 상태이면 작업 실행의 진행 상황을 모니터링할 수 있습니다.

작업 시간 제한 타이머

타이머에는 진행 중 타이머와 단계 타이머 두 가지 유형이 있습니다.

진행 중 타이머

작업 또는 작업 템플릿을 생성할 때 진행 중 타이머에 1분에서 7일 사이의 값을 지정할 수 있습니다. 작업 실행 전에는 이 타이머의 값을 업데이트할 수 있습니다. 타이머가 시작된 후에는 업데이트할 수 없으며 타이머 값은 해당 작업의 모든 작업 실행에 적용됩니다. 작업 실행이 이 간격보다 오랫동안 IN_PROGRESS 상태를 유지할 때마다 작업 실행이 실패하고 터미널 TIMED_OUT 상태로 전환됩니다. AWS IoT 또한 MQTT 알림을 게시합니다.

단계 타이머

업데이트하려는 작업 실행에만 적용되는 단계 타이머를 설정할 수도 있습니다. 이 타이머는 진행 중 타이머에는 영향을 주지 않습니다. 작업 실행을 업데이트할 때마다 이 타이머에 대해 새 값을 설정할 수 있습니다. 사물에 대해 대기 중인 다음 작업 실행을 시작할 때 새 단계 타이머를 생성할 수도 있습니다. 작업 실행이 단계 타이머 간격보다 오랫동안 IN_PROGRESS 상태를 유지하는 경우, 해당 작업 실행은 실패하며 터미널 상태인 TIMED_OUT으로 전환됩니다.

참고

AWS IoT 콘솔 또는 Jobs API를 사용하여 진행 중인 타이머를 설정할 수 있습니다. AWS IoT 단계 타이머를 지정하려면 API를 사용합니다.

작업 시간 제한에 대해 타이머가 작동하는 방식

다음은 20분 시간 제한 기간 동안 진행 중 시간 제한과 단계 시간 제한이 서로 상호 작용하는 방식을 설명합니다.

진행 중인 타이머가 20분이고 중첩된 단계 타이머는 7, 5, 8분으로 표시된 타임라인입니다.

다음은 여러 단계를 보여줍니다.

  1. 12:00

    새 작업이 생성되고 작업을 생성할 때 20분 동안 진행 중 타이머가 시작됩니다. 진행 중 타이머가 실행되기 시작하고 작업 실행은 IN_PROGRESS 상태로 전환됩니다.

  2. 12:05 PM

    7분 값으로 새 단계 타이머가 생성됩니다. 이제 작업 실행이 오후 12시 12분에 시간 초과됩니다.

  3. 12:10 PM

    5분 값으로 새 단계 타이머가 생성됩니다. 새 단계 타이머가 생성되면 이전 단계 타이머가 삭제되고 이제 작업 실행은 오후 12시 15분에 시간 초과됩니다.

  4. 12:13 PM

    9분 값으로 새 단계 타이머가 생성됩니다. 이전 단계 타이머가 삭제되고 이제 작업 실행은 진행 중 타이머가 오후 12시 20분에 시간 초과되므로 오후 12시 20분에 시간 초과됩니다. 단계 타이머는 진행 중 타이머의 절대 한계를 초과할 수 없습니다.

재시도 구성을 사용하여 특정 조건 집합이 충족될 때 작업 실행을 재시도할 수 있습니다. 작업이 시간 초과되거나 디바이스가 실패할 때 재시도를 시도할 수 있습니다. 시간 제한 실패로 인해 실행을 재시도하려면 시간 제한 구성을 사용하도록 설정해야 합니다.

재시도 구성 사용 방법

다음 단계에 따라 구성을 재시도합니다.

  1. FAILED, TIMED_OUT 또는 두 실패 기준 모두에 대해 재시도 구성을 사용할지 여부를 결정합니다. 상태에 대해 TIMED_OUT 상태가 보고된 후 AWS IoT Jobs는 디바이스에 대한 작업 실행을 자동으로 재시도합니다.

  2. FAILED 상태의 경우 작업 실행 실패를 재시도할 수 있는지 확인합니다. 재시도 가능한 경우 디바이스를 FAILURE 상태를 AWS IoT에 보고하도록 프로그래밍합니다. 다음 섹션에서는 재시도 가능한 실패와 재시도 불가능한 실패에 대해 자세히 설명합니다.

  3. 앞의 정보를 사용하여 각 실패 유형에 사용할 재시도 횟수를 지정합니다. 단일 디바이스의 경우 두 실패 유형을 모두 합하여 최대 10회의 재시도를 지정할 수 있습니다. 재시도는 실행이 성공하거나 지정된 시도 횟수에 도달하면 자동으로 중지됩니다.

  4. 반복적으로 재시도가 실패하는 경우 많은 재시도 횟수로 인해 추가 요금이 발생하지 않도록 작업을 취소하려면 중단 구성을 추가합니다.

참고

작업이 반복 유지 관리 기간 종료에 도달하면 모든 IN_PROGRESS 작업 실행은 최종 상태에 도달할 때까지 작업 문서에 명시된 작업을 계속 수행합니다. 작업 실행이 최종 상태인 FAILED 또는 유지 관리 기간을 벗어난 TIMED_OUT 상태에 도달하면 시도 횟수가 모두 소진되지 않았으면 다음 기간에 재시도가 이루어집니다. 다음 유지 관리 기간의 startTime에 새 작업 실행이 생성되고 디바이스를 시작할 준비가 될 때까지 QUEUED의 상태가 됩니다.

재시도 및 중단 구성

다시 시도할 때마다 추가 요금이 부과됩니다. AWS 계정반복적인 재시도 실패로 인한 추가 요금이 발생하지 않도록 하려면 중단 구성을 추가하는 것이 좋습니다. 요금에 대한 자세한 내용은 AWS IoT Device Management 요금을 참조하세요.

높은 임계값 비율의 디바이스가 시간 초과되거나 실패를 보고하는 경우 재시도 실패 여러 번 발생할 수 있습니다. 이 경우 중단 구성을 사용하여 작업을 취소하고 대기열에 있는 모든 작업 실행이나 추가적인 재시도를 방지할 수 있습니다.

참고

작업 실행을 취소하기 위한 중단 기준이 충족되는 경우 QUEUED 작업 실행만 취소됩니다. 대기열에 있는 디바이스에 대한 재시도는 시도되지 않습니다. 그러나 IN_PROGRESS 상태인 현재 작업 실행은 취소되지 않습니다.

또한 실패한 작업 실행을 재시도하기 전에 다음 섹션에 설명된 대로 작업 실행 실패가 재시도 가능한지 여부를 확인하는 것이 좋습니다.

FAILED 실패 유형에 대한 재시도

FAILED 실패 유형에 대한 재시도를 시도하려면 디바이스를 실패한 작업 실행에 대한 FAILURE 상태를 AWS IoT에 보고하도록 프로그래밍해야 합니다. FAILED 작업 실행을 재시도하는 기준으로 재시도 구성을 설정하고 수행할 재시도 횟수를 지정해야 합니다. AWS IoT 작업이 FAILURE 상태를 감지하면 자동으로 디바이스에 대한 작업 실행을 재시도합니다. 재시도는 작업 실행이 성공하거나 최대 재시도 횟수에 도달할 때까지 계속됩니다.

각 재시도 및 이러한 디바이스에서 실행 중인 작업을 추적할 수 있습니다. 실행 상태를 추적하여 지정된 횟수의 재시도가 시도된 후 디바이스를 사용하여 실패를 보고하고 다른 재시도를 초기화할 수 있습니다.

재시도 가능한 실패와 재시도 불가능한 실패

작업 실행 실패는 재시도 가능하거나 재시도 불가능할 수 있습니다. 각 재시도 시 AWS 계정에 요금이 부과될 수 있습니다. 여러 번의 재시도로 인해 추가 요금이 발생하지 않도록 하려면 먼저 작업 실행 실패가 재시도 가능한지 여부를 확인하는 것이 좋습니다. 재시도 가능한 실패의 예로는 Amazon S3 URL에서 작업 문서를 다운로드하려고 시도하는 동안 디바이스에서 발생하는 연결 오류가 있습니다. 작업 실행 실패가 재시도 가능하면 작업 실행이 실패한 경우 FAILURE 상태를 보고하도록 디바이스를 프로그래밍합니다. 그런 다음 FAILED 실행을 재시도하도록 재시도 구성을 설정합니다.

실행을 재시도할 수 없는 경우 재시도하거나 계정에 추가 요금이 부과될 가능성이 없도록 REJECTED 상태를 AWS IoT에 보고하도록 디바이스를 프로그래밍하는 것이 좋습니다. 재시도 불가능한 실패의 예로는 디바이스가 작업 업데이트 수신과 호환되지 않는 경우 또는 작업을 실행하는 동안 메모리 오류가 발생하는 경우를 들 수 있습니다. 이러한 경우 AWS IoT 작업은 OR 상태가 감지될 때만 작업 실행을 재시도하므로 작업 실행을 재시도하지 않습니다. FAILED TIMED_OUT

작업 실행 실패가 재시도 가능하다고 확인된 후에도 재시도가 여전히 실패할 경우 디바이스 로그를 확인하는 것이 좋습니다.

참고

선택적 예약 구성이 있는 작업이 해당 endTime에 도달하면, endBehavior가 대상 그룹의 나머지 모든 디바이스에 대한 작업 문서 롤아웃을 중지하고 나머지 작업 실행을 진행하는 방법을 결정합니다. 재시도 구성을 통해 선택한 경우 재시도됩니다.

TIMEOUT 실패 유형에 대한 재시도

작업을 생성할 때 타임아웃을 활성화하면 상태가 에서 로 변경될 때 AWS IoT 잡스는 디바이스에 대한 작업 실행을 재시도합니다. IN_PROGRESS TIMED_OUT 이 상태 변경은 진행 중 타이머가 시간 초과되거나 지정한 단계 타이머가 IN_PROGRESS 상태이다가 시간 초과될 경우 발생할 수 있습니다. 재시도는 작업 실행이 성공하거나 이 실패 유형에 대한 최대 재시도 횟수에 도달할 때까지 계속됩니다.

연속 작업 및 사물 그룹 멤버십 업데이트

작업 상태가 IN_PROGRESS인 연속 작업의 경우 사물의 그룹 멤버십이 업데이트되면 재시도 횟수가 0으로 재설정됩니다. 예를 들어, 다섯 번의 재시도 횟수를 지정했고 세 번의 재시도가 이미 수행되었다고 가정해 보겠습니다. 이제 동적 사물 그룹의 경우와 같이 사물이 사물 그룹에서 제거되었다가 그룹에 다시 가입하면 재시도 횟수가 0으로 재설정됩니다. 이제 사물 그룹에 대해 남은 두 번의 시도 대신 다섯 번의 재시도를 수행할 수 있습니다. 또한 사물 그룹에서 사물이 제거되면 추가 재시도 시도가 취소됩니다.