ジョブ設定の仕組み - AWS IoT Core
ジョブのロールアウト、スケジュール、中止の設定ジョブ実行タイムアウト設定と再試行の設定

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

ジョブ設定の仕組み

ジョブのデプロイ時にロールアウト設定と中止設定を使用し、タイムアウトと再試行設定をジョブの実行に使用します。以下のセクションに、これらの設定の仕組みの詳細を示します。

ジョブのロールアウト、スケジュール、中止の設定

ジョブのロールアウト、スケジューリング、中止の設定を使用して、ジョブドキュメントを受信するデバイスの数を定義し、ジョブのロールアウトをスケジューリングして、ジョブをキャンセルする基準を決定できます。

保留中のジョブの実行がターゲットに通知される速度を指定できます。また、ステージングされたロールアウトを作成し、更新、再起動、その他のオペレーションを管理できます。ターゲットの通知方法を指定するには、ジョブのロールアウトレートを使用します。

ジョブロールアウトレート

一定のロールアウトレートまたは指数関数的ロールアウトレートを使用して、ロールアウト設定を作成できます。1 分あたりに通知するジョブターゲットの最大数を指定するには、一定のロールアウトレートを使用します。

AWS IoT さまざまな基準やしきい値が満たされると、指数関数的なロールアウト率でジョブを展開できます。失敗したジョブの数が、指定した基準のセットと一致する場合、ジョブのロールアウトをキャンセルできます。ジョブのロールアウトレート基準は、ジョブを作成時に、JobExecutionsRolloutConfig オブジェクトを使用して設定します。ジョブの中止基準も、ジョブの作成時に、AbortConfig オブジェクトを使用して設定します。

次の例は、ロールアウトレートの仕組みを示しています。例えば、基本レートが 50 分あたり、増分係数 2、通知および成功したデバイスの数がそれぞれ 1,000 のジョブロールアウトは、次のように機能します。ジョブは、1 分あたり 50 のジョブ実行の割合で開始され、1,000 個のモノがジョブの実行通知を受信するか、1,000 のジョブ実行が成功するまでその割合で継続されます。

次の表で、最初の 4 つのインクリメントでロールアウトを進める方法を示します。

分あたりのロールアウトレート

50

100

200

400

レートの増加を満たすための通知されたデバイス数または成功したジョブ実行数

1,000

2,000

3,000

4,000
注記

同時に実行できるジョブの最大数が 500 (isConcurrent = True) の場合、同時実行ジョブの数が 499 以下 (isConcurrent = False) になるまで、すべてのアクティブなジョブのステータスは IN-PROGRESS のままで、新しいジョブは実行されません。これは、スナップショットジョブと連続ジョブに適用されます。

isConcurrent = True の場合、このジョブによってターゲットグループ内のすべてのデバイスへのジョブ実行をロールアウトしています。isConcurrent = False の場合、ジョブがターゲットグループ内のすべてのデバイスへのジョブ実行のロールアウトを完了しました。ターゲットグループのすべてのデバイスが終了状態になるか、ジョブ停止設定を選択した場合は、ターゲットグループのしきい値 (パーセント) に達すると、ステータスが更新されます。isConcurrent = True および isConcurrent = False のジョブレベルのステータスは両方ともに IN_PROGRESS です。

アクティブジョブと同時実行ジョブの制限の詳細については、「アクティブなジョブおよび同時ジョブの制限」を参照してください。

モノの動的グループを使用した継続的ジョブのジョブロールアウトレート

継続的なジョブを使用してフリートにリモート操作をロールアウトすると、ジョブはターゲットの Thing AWS IoT グループ内のデバイスに対してジョブ実行をロールアウトします。モノの動的グループに新たに追加されたデバイスについては、ジョブ作成後もこれらのジョブ実行がそれらのデバイスに対して引き続きロールアウトされます。

ロールアウト設定では、ジョブが作成されるまでグループに追加されたデバイスのみ、ロールアウトレートを制御できます。ジョブが作成されると、新しいデバイスについては、デバイスがターゲットグループに参加すると、ジョブ実行がほぼ同時に作成されます。

あらかじめ設定された開始時刻、終了時刻、終了時刻に達した際に各ジョブの実行がどのようになるかを示す終了動作を使用して、最大 1 年先まで連続ジョブまたはスナップショットのジョブをスケジューリングできます。さらに、オプションの定期メンテナンスウィンドウを作成して、継続的なジョブの頻度、開始時間、期間を柔軟に設定して、ジョブドキュメントをターゲットグループ内のすべてのデバイスにロールアウトできます。

ジョブスケジューリングの設定

[開始時刻]

スケジューリングされたジョブの開始時刻は、そのジョブがターゲットグループ内のすべてのデバイスへのジョブドキュメントのロールアウトを開始する将来の日付と時刻です。スケジューリングされたジョブの開始時刻は、連続ジョブとスナップショットジョブに適用されます。スケジューリングされたジョブが最初に作成されると、SCHEDULED のステータスは維持されます。選択した startTime に達すると、IN_PROGRESS に更新され、ジョブドキュメントのロールアウトが開始されます。startTime は、スケジューリングされたジョブを最初に作成した日から 1 年以内にする必要があります。

API startTime コマンドまたはを使用する場合の構文の詳細については AWS CLI、「タイムスタンプ」を参照してください。

夏時間 (DST) が適用されている場所での定期的なメンテナンスウィンドウでオプションのスケジュール設定が選択されているジョブの場合は、DST と標準時間を切り替える際に開始時間が 1 時間変わります。

注記

AWS Management Console に表示されるタイムゾーンは、現在のシステムタイムゾーンです。ただし、これらのタイムゾーンはシステムによって UTC に変換されます。

[終了時刻]

スケジューリングされたジョブの終了時刻は、そのジョブがターゲットグループ内に残っているすべてのデバイスへのジョブドキュメントのロールアウトを停止する将来の日付と時刻です。スケジューリングされたジョブの終了時刻は、連続ジョブとスナップショットジョブに適用されます。スケジューリングされたジョブが選択した endTime に達し、すべてのジョブの実行が終了状態になると、ステータスが IN_PROGRESS から COMPLETED に更新されます。endTime は、スケジューリングされたジョブを最初に作成した日から 2 年以内にする必要があります。startTime と endTime との間の最短時間は 30 分です。ジョブ実行の再試行は、ジョブが endTime に到達するまで行われます。その後、endBehavior が処理方法を決定します。

API endTime コマンドまたはを使用する場合の構文の詳細については AWS CLI、「Timestamp」を参照してください。

夏時間 (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 年

定期メンテナンスウィンドウ

メンテナンスウィンドウは、CreateJobおよび CreateJobTemplate API SchedulingConfig のスケジュール設定内のオプション設定です。 AWS Management Console 開始時間、期間、およびメンテナンスウィンドウが発生する頻度 (毎日、毎週、または毎月) をあらかじめ設定して、定期的なメンテナンスウィンドウを設定できます。メンテナンスウィンドウは連続ジョブにのみ適用されます。定期的なメンテナンスウィンドウの最大所要時間は 23 時間 50 分です。

次のリストでは、オプションのメンテナンスウィンドウを使用したスケジューリングされたさまざまなジョブシナリオのジョブステータスを示しています。

連続ジョブのライフサイクルを示したダイアグラム。特定のイベントが発生すると、「スケジュール済み」、「進行中」、「キャンセル済み」、および「削除中」の各状態へと進行していきます。

ジョブのステータス状態の詳細については、「Jobs とジョブ実行の状態」を参照してください。

注記

メンテナンスウィンドウ中にジョブが endTime に到着すると、そのジョブは IN_PROGRESS から COMPLETED に更新されます。さらに、残りのジョブ実行は、そのジョブの endBehavior 後に実行されます。

Cron 式

メンテナンスウィンドウ中にカスタム頻度でジョブドキュメントをロールアウトするようにスケジュールされたジョブの場合、カスタム頻度は cron 式を使用して入力されます。Cron 式には 6 つの必須フィールドがあり、それらはスペースで区切られます。

[Syntax (構文)]

cron(fields)
フィールド 値 ワイルドカード

分

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

, - * /
ワイルドカード

  • , (カンマ) のワイルドカードには、追加の値が含まれます。月フィールドの、「JAN,FEB,MAR」は、1 月、2 月、3 月を含みます。

  • - (ダッシュ) のワイルドカードは、範囲を指定します。日フィールドの、「1-15」は、指定した月の 1 日から 15 日を含みます。

  • [*] (アスタリスク) のワイルドカードには、フィールドのすべての値が含まれます。時間フィールドの、* にはすべての時間が含まれています。D フィールドと D ay-of-month ay-of-week フィールドの両方に* を使用することはできません。一方に使用する場合は、もう一方に [?] を使用する必要があります。

  • / (スラッシュ) のワイルドカードは、増分を指定します。分フィールドで、「1/10」と入力して、その時間の最初の分から始めて、10 分毎を指定できます (11 分、21 分、31 分など)。

  • [?] (疑問符) のワイルドカードは、任意を意味します。D ay-of-month フィールドには 7 と入力でき、7 日が何曜日であってもかまわない場合は、「?」と入力できます。 D ay-of-week フィールドに。

  • D ay-of-month または D ay-of-week フィールドの L ワイルドカードは、その月または週の最後の日を指定します。

  • D W ay-of-month フィールドのワイルドカードは平日を指定します。D ay-of-month フィールドでは、月の 3 3W 日に最も近い平日を指定します。

  • D ay-of-week フィールドの # ワイルドカードは、1 か月以内の特定の曜日を指定します。例えば、3#2 は、月の第 2 火曜日を示します。3 は週の 3 番目の日 (火曜日) を示し、2 は月のそのタイプの 2 番目の日を示します。

    注記

    '#' 文字を使用する場合、 day-of-week フィールドで定義できる式は 1 つだけです。例えば、"3#1,6#3" は 2 つの式として解釈されるため、無効です。

制限事項

  • D ay-of-month フィールドと D ay-of-week フィールドを同じ cron 式に指定することはできません。一方のフィールドに値 (または *) を指定する場合、もう一方のフィールドで ? を使用する必要があります。

例

定期的なメンテナンスウィンドウの startTime に cron 式を使用する場合は、次の cron 文字列のサンプルを参照してください。

分 時間 日 月 曜日 年 意味
0 10 * * ? *

毎日午前 10:00 (UTC) に実行
15 12 * * ? *

毎日午後 12:15 (UTC) に実行
0 18 ? * MON-FRI *

毎週月曜日から金曜日まで午後 6:00 (UTC) に実行
0 8 1 * ? *

毎月 1 日の午前 8:00 (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 のとき、ジョブ実行の進行状況をモニタリングできます。

ジョブタイムアウトのタイマー

タイマーには、進捗タイマーとステップタイマーの 2 種類があります。

進捗タイマー

ジョブまたはジョブテンプレートを作成するときに、進捗タイマーの値を 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

    値 7 分の新しいステップタイマーを作成します。ジョブの実行は午後 12:12 にタイムアウトします。

  3. 午後 12:10

    値 5 分の新しいステップタイマーを作成します。新しいステップタイマーが作成されると、前のステップタイマーは破棄され、ジョブの実行は午後 12:15 にタイムアウトになります。

  4. 午後 12:13

    値 9 分の新しいステップタイマーを作成します。前のステップタイマーは破棄され、進捗タイマーが午後 12:20 にタイムアウトするため、ジョブの実行は午後 12:20 にタイムアウトします。ステップタイマーは、進捗タイマーによって作成された絶対限度時間を超えることはできません。

再試行設定を使用して、特定の条件セットが満たされたときにジョブの実行を再試行できます。再試行は、ジョブがタイムアウトしたとき、またはデバイスで失敗が発生したときに試行できます。タイムアウト失敗が原因で実行を再試行するには、タイムアウト設定を有効にする必要があります。

再試行設定の使用方法

設定を完了するには、次の手順を再試行します。

  1. FAILED、TIMED_OUT、または両方の失敗基準に対して再試行設定を使用するかどうかを決定します。TIMED_OUTステータスの場合、ステータスが報告されると、 AWS IoT Jobs はデバイスのジョブ実行を自動的に再試行します。

  2. FAILED ステータスの場合、ジョブの実行失敗を再試行できるかどうかを確認します。再試行可能な場合は、FAILURE ステータスを AWS IoTに報告するようデバイスをプログラムします。次のセクションでは、再試行可能な失敗と復元不可能な失敗について詳しく説明します。

  3. 前述の情報を使用して、各失敗タイプに使用する再試行回数を指定します。1 つのデバイスに対して、両方の失敗タイプを合わせて最大 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 Jobs は OR ステータスを検出した場合にのみジョブの実行を再試行するため、ジョブの実行を再試行しません。FAILED TIMED_OUT

ジョブ実行の失敗が再試行可能であると判断した後、再試行が失敗する場合は、デバイスログを確認することを検討してください。

注記

オプションのスケジューリング設定によるジョブが endTime に達すると、選択された endBehavior はターゲットグループ内の残りのすべてのデバイスへのジョブドキュメントのロールアウトを停止し、残りのジョブ実行で再試行を進める方法を指示します。再試行設定で選択した場合、試行は再試行されます。

TIMEOUT の失敗タイプの再試行

ジョブの作成時にタイムアウトを有効にすると AWS IoT 、ステータスがからに変わると、ジョブはデバイスのジョブ実行を再試行します。IN_PROGRESS TIMED_OUTこのステータスの変化は、進捗タイマーがタイムアウトしたとき、または指定したステップタイマーが IN_PROGRESS である場合に発生し、その後タイムアウトします。再試行は、ジョブの実行が成功するか、この失敗タイプの再試行の最大回数に達するまで継続されます。

継続的なジョブとモノグループメンバーシップの更新

継続的なジョブのジョブステータスが IN_PROGRESS の場合、モノグループメンバーシップが更新されると、再試行回数はゼロにリセットされます。例えば、再試行を 5 回指定し、3 回の再試行がすでに実行されているとします。モノがモノグループから削除され、ダイナミックモノグループの場合などで、モノがグループに再登録されると、再試行回数はゼロにリセットされます。これで、残りの 2 回の試行ではなく、モノグループに対して 5 回の再試行を実行できます。さらに、モノがモノグループから削除されると、追加の再試行がキャンセルされます。