翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Deadline Cloud でジョブをスケジュールする ジョブを作成すると、 AWS Deadline Cloud はキューに関連付けられた 1 つ以上のフリートで処理されるようにスケジュールします。特定のタスクを処理するフリートは、スケジューリング設定、フリート用に設定された機能、および特定のステップのホスト要件に基づいて選択されます。 以下のセクションでは、ジョブをスケジュールするプロセスの詳細について説明します。 ## 設定のスケジューリング Deadline Cloud がキューでジョブをスケジュールする方法を設定するには、キューのスケジュール設定を行います。スケジューリング設定は、ワーカーをジョブ間で分散する方法を制御します。 スケジューリング設定は、Deadline Cloud コンソールを使用するか[CreateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_CreateQueue.html) API または [UpdateQueue](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateQueue.html) 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、バランス 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`。さらに、ジョブの残りのステップはキャンセルされます。 フリートの機能はフリートレベルで設定されます。フリート内のワーカーがジョブの要件を満たしていても、フリートがジョブの要件を満たしていない場合、ジョブからタスクは割り当てられません。 **重要** フリートレベルの`workerCapabilities`宣言は、スケジューリング契約です。スケジューラは、フリートレベルの機能に対してのみステップの互換性を評価します。個々のワーカーは検査されません。ステップの がフリートの で宣言された最小値`hostRequirements`を超えると`workerCapabilities`、フリート内の一部の個々のワーカーが要件を満たす場合でも、フリートは互換性がないと評価されます。 次のジョブテンプレートには、ステップのホスト要件を指定するステップがあります。 ``` 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. ``` ### フリート設計のベストプラクティス スケジューラはフリートレベルで互換性を評価するため、宣言された がフリート内のすべてのワーカーの保証された最小ハードウェア特性`workerCapabilities`を表すように、カスタマーマネージドフリートを設計します。 + 広範な 1 つの異種フリートを使用するのではなく、保証された最小ハードウェア特性 (GPU 数、VRAM、CPU 数など) に基づいてワーカーを複数のフリートに分割します。 + ワーカーに同一のハードウェアがない場合でも、フリート内の各ワーカーが宣言された最小値以上であることを確認します。 + 複数のフリートを 1 つのキューに関連付けると、スケジューラは各ステップの に基づいて互換性のあるフリートを選択します`hostRequirements`。 たとえば、1 つの GPU (24 GiB VRAM) を持つワーカーと 4 つの GPUs (96 GiB VRAM) を持つワーカーがある場合、2 つの異なるフリートを作成します。1 つは最低 1 つの GPU と 24 GiB GPU メモリを宣言し、もう 1 つは最低 4 つの GPU と 96 GiB GPU メモリを宣言 GPUs。次に、両方のフリートを同じキューに関連付けます。4 つの GPUs を必要とするステップは、高 GPU フリートに自動的にルーティングされます。 カスタマーマネージドフリートの作成の詳細については、「」を参照してください[カスタマーマネージドフリートを作成する](create-a-cmf.md)。 ### カスタム機能 組み込みワーカー機能 (vCPU、メモリ、GPU、オペレーティングシステム、CPU アーキテクチャ) に加えて、フリートでカスタム量とカスタム属性を定義して、追加のスケジューリング制約を表現できます。 + **カスタム量** – 使用可能なディスク容量や特殊なハードウェアカウンターなどの数値。 + **カスタム属性** – インストールされたソフトウェア、ソルバーバージョン、サイトラベルなどの文字列値。たとえば、 のような値`attr.sw.solvers`で を定義`["vray-6", "arnold-7"]`して、特定のソフトウェアを必要とするジョブをルーティングできます。 フリートレベルでは、そのフリート内のすべてのワーカーに存在することが保証されている場合にのみ、カスタム機能でソフトウェアまたはハードウェアの組み合わせを宣言します。 フリートレベルのカスタム機能には、次の制限があります。 + フリートあたり最大 15 個のカスタム金額 + フリートあたり最大 15 個のカスタム属性 フォーム内の名前`amount.worker.*`と `attr.worker.*`は、組み込み機能用に サービスによって予約されます。カスタム機能には他のプレフィックスを使用します。 フリートの作成時にカスタム機能を設定する方法の詳細については、「」を参照してください[カスタマーマネージドフリートを作成する](create-a-cmf.md)。 ### GPU メモリレポート GPU あたりの特定の VRAM しきい値を必要とする GPU 集約型ワークロードのフリートを設定するときは、ワーカーエージェントが GPU メモリを報告する方法を理解します。 Deadline Cloud ワーカーエージェントは、ワーカー上のすべての GPU の*最小* GPUs メモリを、合計ではなく `amount.worker.gpu.memory`にレポートします。この動作により、特定の GPU あたりの VRAM 量を必要とするジョブは、すべての GPU がその要件を満たすワーカーにルーティングされます。 たとえば、ワーカーにそれぞれ 24 GiB と 48 GiB の VRAM を持つ 2 つの GPUs がある場合、ワーカーエージェントは GPU メモリ値として 24 GiB を報告します。 フリートレベルで、フリート内のワーカーが持つことが保証されている GPU VRAM あたりの最小値`acceleratorTotalMemoryMiB`に設定します。 ### ワーカーごとの機能 スケジュールの決定に影響を与えることなく、個々のワーカーの運用状態を追跡する必要がある場合は、ワーカーごとの機能を使用します。たとえば、ワーカーにメンテナンスのフラグを付けたり、ソフトウェアのロールアウト状態を追跡したり、ヘルスチェックインジケータを記録したりできます。 `UpdateWorker` API オペレーションを使用して、個々のワーカーに機能を設定できます。ワーカーごとの機能は、スケジューリング契約として使用*されません*。スケジューラは、フリートレベルの`workerCapabilities`宣言に対してのみ互換性を評価します。 `GetWorker` および `ListWorkers`オペレーションは、 で設定されたワーカー機能を返しません`UpdateWorker`。 詳細については、*Deadline Cloud API リファレンス*の[UpdateWorker](https://docs.aws.amazon.com/deadline-cloud/latest/APIReference/API_UpdateWorker.html)」を参照してください。 ## フリートスケーリング ジョブが互換性のあるサービスマネージドフリートに割り当てられると、フリートは自動スケーリングされます。フリート内のワーカーの数は、フリートが実行できるタスクの数に基づいて変わります。 ジョブがカスタマーマネージドフリートに割り当てられると、ワーカーがすでに存在しているか、イベントベースの自動スケーリングを使用して作成できます。詳細については、*Amazon EC2 Auto Scaling * [ユーザーガイド」のEventBridge を使用して自動スケーリングイベントを処理する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html)」を参照してください。 ## セッション ジョブのタスクは 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! ```