翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Deadline Cloud でジョブをスケジュールする
ジョブを作成すると、 AWS Deadline Cloud はキューに関連付けられた 1 つ以上のフリートで処理されるようにスケジュールします。特定のタスクを処理するフリートは、スケジューリング設定、フリート用に設定された機能、および特定のステップのホスト要件に基づいて選択されます。
以下のセクションでは、ジョブをスケジュールするプロセスの詳細について説明します。
設定のスケジューリング
Deadline Cloud がキューでジョブをスケジュールする方法を設定するには、キューのスケジュール設定を行います。スケジュール設定は、ワーカーをジョブ間で分散する方法を制御します。
スケジューリング設定は、Deadline Cloud コンソールを使用するかCreateQueue API または UpdateQueue APIs を呼び出して設定できます。
使用可能なスケジューリング設定は 3 つあります。
-
Priority, first-in-first-out (
priorityFifo) – 最も優先度が高く、最も早く送信されたジョブを最初にスケジュールします (デフォルト)。 -
Priority, balanced (
priorityBalanced) – ジョブ間でワーカーを最も高い優先度で均等に分散します。 -
加重、バランス (
weightedBalanced) – 加重式を使用して、ワーカーがジョブ間でどのように分散されるかを決定します。
すべてのスケジューリング設定で、進行中のタスクは、新しいスケジューリング決定が行われる前に完了するまで実行されます。タスクの実行中にスケジューリング設定を変更した場合、その変更は次にワーカーが割り当てられた場合にのみ適用されます。実行中のタスクは中断または再割り当てされません。
Priority、first-in-first-out
Priority、first-in-first-out (priorityFifo) は、新しいキューのデフォルトのスケジューリング設定です。Deadline Cloud は、最初に最も優先度の高いジョブにワーカーを割り当てます。複数のジョブが同じ優先度を共有する場合、最も古い (最も早く送信された) ジョブは、使用可能なすべてのワーカーを最初に受け取ります。
ジョブの厳密な順序付けが必要な場合は、優先度 FIFO を使用します。この設定は、シーケンシャルパイプラインステージやバッチ処理など、送信された順序でジョブを一度に 1 つずつ完了する必要がある場合に適しています。バッチ処理では、次のジョブを開始する前に各ジョブを終了する必要があります。
この設定には追加のパラメータはありません。
優先度、バランス
Priority, balanced (priorityBalanced) は、優先度が最も高いすべてのジョブにワーカーを均等に分散します。優先度が最も高いジョブが 1 つしか存在しない場合、Deadline Cloud はそのジョブにすべてのワーカーを割り当てます。複数のジョブが最も高い優先度を共有する場合、ワーカーはジョブ間で均等に分割されます。ワーカーを均等に分割できない場合、追加のワーカーは最も優先度の高いジョブに分散されます。
複数のアーティストまたはユーザーが同じ優先度でジョブを送信し、各ユーザーがすぐにフィードバックを必要とする場合は、優先度バランスを使用します。この設定により、使用可能なすべてのワーカーが 1 つのジョブで独占されないため、送信後すぐにすべてのユーザーにワーカーが割り当てられます。
ジョブの残りのタスクがワーカーの割合よりも少ない場合、余剰ワーカーは同じ優先度レベルで他のジョブに再分散されます。優先度が最も高いすべてのジョブが完全に割り当てられている場合、余剰ワーカーは優先度が次に高いジョブにカスケードされます。
この設定には、次のパラメータがあります。
renderingTaskBuffer-
ワーカーの維持を制御します。ワーカーは、レンダリングタスクの差が
renderingTaskBuffer値を超えた場合にのみ、現在のジョブから別のジョブに同じ優先度で切り替えます。値を大きくすると、ワーカーの現在のジョブの時間が長くなり、コンテキストの切り替えが減少します。デフォルト値は1です。
加重、分散
加重、分散 (weightedBalanced) は、式を使用して各ジョブの重みを計算します。Deadline Cloud は、最初にワーカーを最上位のジョブに割り当てます。複数のジョブの重みが同じ場合、ワーカーはそれらのジョブ間で分散されます。
優先順位、エラー率、送信時間が異なるジョブ間でワーカーを分散する方法をきめ細かく制御する必要がある場合は、加重分散を使用します。この設定は、ジョブの優先度、ジョブの経過時間、エラー処理、ワーカーの維持性のバランスを調整する複雑なレンダーファーム環境に適しています。
各ジョブの重みは次のように計算されます。
weight = (job.Priority * priorityWeight) +
(job.Errors * errorWeight) +
((currentTimeInSeconds - job.SubmissionTime) * submissionTimeWeight) +
((job.RenderingTasks - renderingTaskBuffer) * renderingTaskWeight)
renderingTaskBuffer コンポーネントは、ワーカーが現在ジョブを処理している場合にのみ適用されます。通常、 renderingTaskWeightは負の値に設定されます。これにより、割り当てられたワーカーを持つジョブの重みが低くなり、他のジョブがキューの先頭に配置されます。また、 errorWeightは通常負であるため、エラーのあるジョブの優先順位は解除されます。スケジューリングオーバーライドは、最小優先度ジョブと最大優先度ジョブに使用できます。
この設定には、次のパラメータがあります。
priorityWeight-
ジョブの優先度に適用される重み。正の値は、優先度の高いジョブが最初にスケジュールされることを意味します。デフォルト値は
100.0です。範囲:0~10000。 errorWeight-
ジョブのエラー数に適用される重み。負の値は、エラーのないジョブが最初にスケジュールされることを意味します。デフォルト値は
-10.0です。範囲:-10000~10000。 submissionTimeWeight-
ジョブの送信時間に適用される重み (秒単位)。正の値は、以前に送信されたジョブが最初にスケジュールされることを意味します。デフォルト値は
3.0です。範囲:0~10000。 renderingTaskWeight-
ジョブに対して現在レンダリングしているタスクの数に適用される重み。負の値は、ワーカー数が少ないジョブが次にスケジュールされることを意味します。デフォルト値は
-100.0です。範囲:-10000~10000。 renderingTaskBuffer-
レンダリングタスクの重みが有効になる前のレンダリングタスクの数。正の値は、ワーカーを現在のジョブに維持します。デフォルト値は
1です。範囲:0~1000。 maxPriorityOverride-
オプション。に設定すると
alwaysScheduleFirst、重み付け式に関係なく、優先度が最も高いジョブ (100) が他のジョブよりも常にスケジュールされます。複数のジョブの優先度が最大の場合、標準の加重式を使用してタイが壊れます。オーバーライドがない場合、最大優先度のジョブは、特別な処理なしで標準の加重式を使用します。 minPriorityOverride-
オプション。に設定すると
alwaysScheduleLast、加重式に関係なく、最小優先度 (0) のジョブが他のジョブの後に常にスケジュールされます。複数のジョブの優先度が最小の場合、標準の加重式を使用してタイが壊れます。オーバーライドがない場合、最小優先度ジョブは、特別な処理なしで標準の加重式を使用します。
フリートの互換性を確認する
ジョブを作成すると、Deadline Cloud はジョブの各ステップのホスト要件を、ジョブが送信されたキューに関連付けられたフリートの機能と照合します。フリートがホスト要件を満たしている場合、ジョブは READY状態になります。
ジョブ内のいずれかのステップに、キューに関連付けられたフリートが満たすことができない要件がある場合、ステップのステータスは に設定されますNOT_COMPATIBLE。さらに、ジョブの残りのステップはキャンセルされます。
フリートの機能はフリートレベルで設定されます。フリートのワーカーがジョブの要件を満たしていても、フリートがジョブの要件を満たしていない場合、ジョブからタスクは割り当てられません。
次のジョブテンプレートには、ステップのホスト要件を指定するステップがあります。
name: Sample Job With Host Requirements specificationVersion: jobtemplate-2023-09 steps: - name: Step 1 script: actions: onRun: args: - '1' command: /usr/bin/sleep hostRequirements: amounts: # Capabilities starting with "amount." are amount capabilities. If they start with "amount.worker.", # they are defined by the OpenJD specification. Other names are free for custom usage. - name: amount.worker.vcpu min: 4 max: 8 attributes: - name: attr.worker.os.family anyOf: - linux
このジョブは、次の機能を備えたフリートにスケジュールできます。
{
"vCpuCount": {"min": 4, "max": 8},
"memoryMiB": {"min": 1024},
"osFamily": "linux",
"cpuArchitectureType": "x86_64"
}
このジョブは、次のいずれかの機能を持つフリートにスケジュールすることはできません。
{
"vCpuCount": {"min": 4},
"memoryMiB": {"min": 1024},
"osFamily": "linux",
"cpuArchitectureType": "x86_64"
}
The vCpuCount has no maximum, so it exceeds the maximum vCPU host requirement.
{
"vCpuCount": {"max": 8},
"memoryMiB": {"min": 1024},
"osFamily": "linux",
"cpuArchitectureType": "x86_64"
}
The vCpuCount has no minimum, so it doesn't satisfy the minimum vCPU host requirement.
{
"vCpuCount": {"min": 4, "max": 8},
"memoryMiB": {"min": 1024},
"osFamily": "windows",
"cpuArchitectureType": "x86_64"
}
The osFamily doesn't match.
フリートスケーリング
ジョブが互換性のあるサービスマネージドフリートに割り当てられると、フリートは自動スケーリングされます。フリート内のワーカーの数は、フリートが実行できるタスクの数に基づいて変わります。
ジョブがカスタマーマネージドフリートに割り当てられると、ワーカーがすでに存在しているか、イベントベースの自動スケーリングを使用して作成できます。詳細については、Amazon EC2 Auto Scaling ユーザーガイド」のEventBridge を使用して自動スケーリングイベントを処理する」を参照してください。
セッション
ジョブのタスクは 1 つ以上のセッションに分割されます。ワーカーはセッションを実行して環境をセットアップし、タスクを実行し、環境を破棄します。各セッションは、ワーカーが実行する必要がある 1 つ以上のアクションで構成されます。
ワーカーがセクションアクションを完了すると、追加のセッションアクションをワーカーに送信できます。ワーカーは、セッション内の既存の環境とジョブアタッチメントを再利用して、タスクをより効率的に完了します。
サービスマネージドフリートワーカーでは、セッションディレクトリはセッション終了後に削除されますが、他のディレクトリはセッション間で保持されます。この動作により、複数のセッションで再利用できるデータのキャッシュ戦略を実装できます。セッション間でデータをキャッシュするには、ジョブを実行しているユーザーのホームディレクトリに保存します。たとえば、conda パッケージは、ワーカーの とWindowsワーカーの C:\Users\job-user\.conda-pkgsのジョブユーザーのホームディレクトリ/home/job-user/.conda-pkgsにキャッシュされますLinux。このデータは、ワーカーがシャットダウンするまで引き続き使用できます。
ジョブアタッチメントは、Deadline Cloud CLI ジョブバンドルの一部として使用する送信者によって作成されます。create-job AWS CLI コマンドの --attachmentsオプションを使用してジョブアタッチメントを作成することもできます。環境は、特定のキューにアタッチされたキュー環境と、ジョブテンプレートで定義されたジョブ環境とステップ環境の 2 つの場所で定義されます。
セッションアクションには 4 つのタイプがあります。
-
syncInputJobAttachments– 入力ジョブの添付ファイルをワーカーにダウンロードします。 -
envEnter– 環境のonEnterアクションを実行します。 -
taskRun– タスクのonRunアクションを実行します。 -
envExit– 環境のonExitアクションを実行します。
次のジョブテンプレートにはステップ環境があります。ステップ環境を設定するonEnter定義、実行するタスクを定義するonRun定義、ステップ環境を破棄するonExit定義があります。このジョブ用に作成されたセッションには、 envEnterアクション、1 つ以上の taskRun アクション、 envExitアクションが含まれます。
name: Sample Job with Maya Environment specificationVersion: jobtemplate-2023-09 steps: - name: Maya Step stepEnvironments: - name: Maya description: Runs Maya in the background. script: embeddedFiles: - name: initData filename: init-data.yaml type: TEXT data: | scene_file: MyAwesomeSceneFile renderer: arnold camera: persp actions: onEnter: command: MayaAdaptor args: - daemon - start - --init-data - file://{{Env.File.initData}} onExit: command: MayaAdaptor args: - daemon - stop parameterSpace: taskParameterDefinitions: - name: Frame range: 1-5 type: INT script: embeddedFiles: - name: runData filename: run-data.yaml type: TEXT data: | frame: {{Task.Param.Frame}} actions: onRun: command: MayaAdaptor args: - daemon - run - --run-data - file://{{ Task.File.runData }}
セッションアクションのパイプライン化
セッションアクションのパイプライン化により、スケジューラは複数のセッションアクションをワーカーに事前割り当てできます。その後、ワーカーはこれらのアクションを順番に実行し、タスク間のアイドル時間を短縮または排除できます。
初期割り当てを作成するには、スケジューラは 1 つのタスクでセッションを作成し、ワーカーはタスクを完了してから、スケジューラはタスクの期間を分析して今後の割り当てを決定します。
スケジューラを有効にするには、タスク期間ルールがあります。1 分未満のタスクの場合、スケジューラは Power-of-2 成長パターンを使用します。たとえば、1 秒のタスクの場合、スケジューラは 2 つの新しいタスクを割り当て、次に 4、次に 8 を割り当てます。1 分間のタスクの場合、スケジューラは新しいタスクを 1 つだけ割り当て、パイプライン作成は無効のままになります。
パイプラインサイズを計算するために、スケジューラは以下を実行します。
-
完了したタスクの平均タスク期間を使用します
-
ワーカーを 1 分間ビジー状態に保つことを目指します。
-
同じセッション内のタスクのみを考慮します
-
ワーカー間で期間データを共有しない
セッションアクションが枯渇すると、ワーカーは新しいタスクをすぐに開始し、スケジューラリクエスト間の待機時間はありません。また、長時間実行されるプロセスのワーカー効率が向上し、タスク分散が向上します。
さらに、新しい優先度の高いジョブが使用可能な場合、ワーカーは現在のセッションが終了し、優先度の高いジョブからの新しいセッションが割り当てられる前に、以前に割り当てられたすべての作業を完了します。
ステップの依存関係
Deadline Cloud はステップ間の依存関係の定義をサポートしているため、あるステップは別のステップが完了するまで待機してから開始します。ステップには複数の依存関係を定義できます。依存関係を持つステップは、すべての依存関係が完了するまでスケジュールされません。
ジョブテンプレートが循環依存関係を定義している場合、ジョブは拒否され、ジョブのステータスは に設定されますCREATE_FAILED。
次のジョブテンプレートは、2 つのステップでジョブを作成します。 StepBは に依存しStepAます。 が正常にStepA完了した後にStepBのみ実行されます。
ジョブが作成されると、 は StepA READY状態になり、 StepBは PENDING状態になります。StepA が終了すると、 は READY状態StepBに移行します。がStepA失敗した場合、または StepAがキャンセルされた場合、 は CANCELED状態StepBに移行します。
複数のステップに依存関係を設定できます。たとえば、 StepCが StepAと の両方に依存する場合StepB、 StepCは他の 2 つのステップが完了するまで開始しません。
ステップの依存関係には以下の制限があります。
-
ステップあたりの依存関係 – ステップは、最大 128 個の他のステップに依存します。
-
ステップあたりのコンシューマー – 1 つのステップに応じて、最大 32 の他のステップを指定できます。
name: Step-Step Dependency Test specificationVersion: 'jobtemplate-2023-09' steps: - name: A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task A Done! - name: B dependencies: - dependsOn: A # This means Step B depends on Step A script: actions: onRun: command: bash args: ['{{ Task.File.run }}'] embeddedFiles: - name: run type: TEXT data: | #!/bin/env bash set -euo pipefail sleep 1 echo Task B Done!