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

Deadline Cloud에서 작업 예약

작업을 생성한 후 AWS Deadline Cloud는 대기열과 연결된 하나 이상의 플릿에서 처리되도록 예약합니다. 특정 작업을 처리하는 플릿은 일정 구성, 플릿에 대해 구성된 기능 및 특정 단계의 호스트 요구 사항에 따라 선택됩니다.

다음 섹션에서는 작업 예약 프로세스에 대한 세부 정보를 제공합니다.

구성 예약

대기열에서 예약 구성을 설정하여 Deadline Cloud가 대기열에서 작업을 예약하는 방법을 구성할 수 있습니다. 예약 구성은 작업자가 작업 간에 분산되는 방식을 제어합니다.

Deadline Cloud 콘솔을 사용하거나 CreateQueue 또는 UpdateQueue APIs.

다음과 같은 세 가지 예약 구성이 있습니다.

모든 예약 구성에서 진행 중인 작업은 새 예약 결정이 내려지기 전에 완료될 때까지 실행됩니다. 작업이 실행되는 동안 예약 구성을 변경하면 작업자가 다음에 할당될 때만 변경 사항이 적용됩니다. 실행 중인 작업은 중단되거나 재할당되지 않습니다.

우선 순위, first-in-first-out

우선 순위, first-in-first-out(priorityFifo)은 새 대기열의 기본 예약 구성입니다. Deadline Cloud는 우선 순위가 가장 높은 작업에 작업자를 먼저 할당합니다. 여러 작업이 동일한 우선 순위를 공유하는 경우 가장 오래된(가장 빨리 제출된) 작업은 사용 가능한 모든 작업자를 먼저 받습니다.

엄격한 작업 순서를 원하는 경우 우선 순위 FIFO를 사용합니다. 이 구성은 순차적 파이프라인 단계 또는 다음 작업이 시작되기 전에 각 작업이 완료되어야 하는 배치 처리와 같이 작업이 제출된 순서대로 한 번에 하나씩 완료해야 하는 경우에 적합합니다.

이 구성에는 추가 파라미터가 없습니다.

우선순위, 균형

우선순위, 균형(priorityBalanced)은 가장 높은 우선순위 수준에서 모든 작업에 작업자를 균등하게 분산합니다. 우선순위가 가장 높은 작업이 하나만 있는 경우 Deadline Cloud는 해당 작업에 모든 작업자를 할당합니다. 여러 작업이 가장 높은 우선 순위를 공유하면 작업자는 서로 균등하게 분할됩니다. 작업자를 균등하게 나눌 수 없는 경우 추가 작업자는 우선 순위가 가장 높은 작업 간에 분산됩니다.

여러 아티스트 또는 사용자가 동일한 우선 순위로 작업을 제출하고 각 사용자에게 즉각적인 피드백이 필요한 경우 우선 순위 밸런스를 사용합니다. 이 구성을 사용하면 단일 작업이 사용 가능한 모든 작업자를 독점하지 않으므로 제출 직후 모든 사용자에게 작업자가 할당됩니다.

작업에 작업자 공유보다 남은 작업이 적은 경우 잉여 작업자는 동일한 우선 순위 수준에서 다른 작업에 재배포됩니다. 우선 순위가 가장 높은 모든 작업이 완전히 할당되면 잉여 작업자가 다음으로 높은 우선 순위 수준의 작업으로 캐스케이드됩니다.

이 구성에는 다음 파라미터가 있습니다.

가중치, 균형

가중치, 균형(weightedBalanced)은 공식을 사용하여 각 작업의 가중치를 계산합니다. Deadline Cloud는 가장 가중치가 높은 작업에 작업자를 먼저 할당합니다. 여러 작업의 가중치가 동일한 경우 작업자는 그 사이에 분산됩니다.

우선순위, 오류율 및 제출 시간이 다양한 작업 간에 작업자가 분산되는 방식을 세밀하게 제어해야 하는 경우 가중치 밸런스를 사용합니다. 이 구성은 작업 우선 순위, 작업 기간, 오류 처리 및 작업자 고정성 간의 균형을 조정하려는 복잡한 렌더 팜 환경에 적합합니다.

각 작업의 가중치는 다음과 같이 계산됩니다.

weight = (job.Priority * priorityWeight) +
         (job.Errors * errorWeight) +
         ((currentTimeInSeconds - job.SubmissionTime) * submissionTimeWeight) +
         ((job.RenderingTasks - renderingTaskBuffer) * renderingTaskWeight)

구성 renderingTaskBuffer 요소는 작업자가 현재 작업 중인 경우에만 적용됩니다. renderingTaskWeight는 일반적으로 음수 값으로 설정되어 할당된 작업자가 있는 작업이 더 낮은 가중치를 받아 다른 작업을 대기열의 맨 앞으로 가져옵니다. 또한 errorWeight는 일반적으로 음수이므로 오류가 있는 작업의 우선 순위가 해제됩니다. 최소 및 최대 우선 순위 작업에 일정 재정의를 사용할 수 있습니다.

이 구성에는 다음과 같은 파라미터가 있습니다.

플릿 호환성 확인

작업을 생성한 후 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.

플릿 설계 모범 사례

스케줄러는 플릿 수준에서 호환성을 평가하기 때문에 선언된가 플릿 내 모든 작업자의 보장된 최소 하드웨어 특성을 workerCapabilities 나타내도록 고객 관리형 플릿을 설계합니다.

예를 들어 GPU가 1개인 작업자(24 GiB VRAM)와 GPUs가 4개인 작업자(96 GiB VRAM)가 있는 경우 두 개의 개별 플릿을 생성합니다. 하나는 최소 1 개의 GPU 및 24 GiB GPU 메모리를 선언하고 다른 하나는 최소 4개의 GPUs 및 96 GiB GPU 메모리를 선언합니다. 그런 다음 두 플릿을 동일한 대기열에 연결합니다. GPU 4 GPUs 필요한 단계는 GPU가 많은 플릿으로 자동 라우팅됩니다.

고객 관리형 플릿 생성에 대한 자세한 내용은 섹션을 참조하세요고객 관리형 플릿 생성.

사용자 지정 기능

기본 제공 작업자 기능(vCPU, 메모리, GPU, 운영 체제 및 CPU 아키텍처) 외에도 플릿에서 사용자 지정 양과 사용자 지정 속성을 정의하여 추가 예약 제약 조건을 표현할 수 있습니다.

플릿 수준에서 소프트웨어 또는 하드웨어 조합이 해당 플릿의 모든 작업자에 존재하도록 보장되는 경우에만 사용자 지정 기능으로 소프트웨어 또는 하드웨어 조합을 선언합니다.

플릿 수준 사용자 지정 기능에는 다음과 같은 제한이 있습니다.

amount.worker.* 및 형식의 이름은 기본 제공 기능을 위해 서비스에서 예약attr.worker.*합니다. 사용자 지정 기능에 다른 접두사를 사용합니다.

플릿을 생성할 때 사용자 지정 기능을 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요고객 관리형 플릿 생성.

GPU 메모리 보고

특정 GPU당 VRAM 임계값이 필요한 GPU 집약적 워크로드에 대해 플릿을 구성할 때 작업자 에이전트가 GPU 메모리를 보고하는 방법을 이해합니다.

Deadline Cloud 작업자 에이전트는 작업자의 모든 GPU에서 최소 GPUs 메모리를 합계가 amount.worker.gpu.memory아닌 로 보고합니다. 이 동작을 통해 특정 GPU당 VRAM 양이 필요한 작업이 모든 GPU가 해당 요구 사항을 충족하는 작업자에게 라우팅됩니다.

예를 들어 작업자가 VRAM이 각각 24 GiB 및 48 GiB인 GPUs 2개를 가지고 있는 경우 작업자 에이전트는 GPU 메모리 값으로 24 GiB를 보고합니다.

플릿 수준에서 acceleratorTotalMemoryMiB 최소를 플릿의 모든 작업자가 보유하도록 보장되는 GPU당 VRAM 중 가장 낮은 로 설정합니다.

작업자당 기능

일정 결정에 영향을 주지 않고 개별 작업자의 운영 상태를 추적해야 하는 경우 작업자당 기능을 사용합니다. 예를 들어 유지 관리를 위해 작업자에 플래그를 지정하거나, 소프트웨어 롤아웃 상태를 추적하거나, 상태 확인 표시기를 기록할 수 있습니다.

UpdateWorker API 작업을 사용하여 개별 작업자에 대한 기능을 설정할 수 있습니다. 작업자별 기능은 예약 계약으로 사용되지 않습니다. 스케줄러는 플릿 수준 workerCapabilities 선언에 대해서만 호환성을 평가합니다.

GetWorker 및 ListWorkers 작업은를 통해 설정된 작업자 기능을 반환하지 않습니다UpdateWorker.

자세한 내용은 Deadline Cloud API 참조의 UpdateWorker를 참조하세요.

플릿 조정

호환되는 서비스 관리형 플릿에 작업이 할당되면 플릿이 자동으로 조정됩니다. 플릿의 작업자 수는 플릿이 실행할 수 있는 작업 수에 따라 변경됩니다.

작업이 고객 관리형 플릿에 할당되면 작업자가 이미 존재하거나 이벤트 기반 Auto Scaling을 사용하여 생성할 수 있습니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 EventBridge를 사용하여 Auto Scaling 이벤트 처리를 참조하세요. Amazon EC2 Auto Scaling

세션

작업의 작업은 하나 이상의 세션으로 나뉩니다. 작업자는 세션을 실행하여 환경을 설정하고 작업을 실행한 다음 환경을 해제합니다. 각 세션은 작업자가 수행해야 하는 하나 이상의 작업으로 구성됩니다.

작업자가 섹션 작업을 완료하면 추가 세션 작업을 작업자에게 보낼 수 있습니다. 작업자는 세션의 기존 환경과 작업 연결을 재사용하여 작업을 보다 효율적으로 완료합니다.

서비스 관리형 플릿 작업자의 경우 세션이 종료된 후 세션 디렉터리가 삭제되지만 다른 디렉터리는 세션 간에 유지됩니다. 이 동작을 사용하면 여러 세션에서 재사용할 수 있는 데이터에 대한 캐싱 전략을 구현할 수 있습니다. 세션 간에 데이터를 캐싱하려면 작업을 실행하는 사용자의 홈 디렉터리 아래에 저장합니다. 예를 들어 conda 패키지는 작업자 및 Windows 작업자의에 C:\Users\job-user\.conda-pkgs 있는 작업 사용자의 홈 디렉터리 /home/job-user/.conda-pkgs 아래에 캐시됩니다Linux. 이 데이터는 작업자가 종료될 때까지 계속 사용할 수 있습니다.

작업 첨부 파일은 Deadline Cloud CLI 작업 번들의 일부로 사용하는 제출자가 생성합니다. create-job AWS CLI 명령 --attachments 옵션을 사용하여 작업 첨부 파일을 생성할 수도 있습니다. 환경은 특정 대기열에 연결된 대기열 환경과 작업 템플릿에 정의된 작업 및 단계 환경의 두 위치로 정의됩니다.

세션 작업 유형에는 네 가지가 있습니다.

다음 작업 템플릿에는 단계 환경이 있습니다. 단계 환경을 설정하는 onEnter 정의, 실행할 작업을 정의하는 onRun 정의, 단계 환경을 제거하는 onExit 정의가 있습니다. 이 작업에 대해 생성된 세션에는 envEnter 작업, 하나 이상의 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분 미만의 작업의 경우 스케줄러는 Power-of-2 성장 패턴을 사용합니다. 예를 들어 1초 태스크의 경우 스케줄러는 2개의 새 태스크를 할당한 다음 4개, 8개를 할당합니다. 1분 이상 태스크의 경우 스케줄러는 새 태스크를 하나만 할당하고 파이프라이닝은 비활성화된 상태로 유지됩니다.

파이프라인 크기를 계산하기 위해 스케줄러는 다음을 수행합니다.

세션 작업 피플라이닝을 사용하면 작업자가 즉시 새 작업을 시작하고 스케줄러 요청 사이에 대기 시간이 없습니다. 또한 장기 실행 프로세스를 위해 작업자 효율성과 작업 분산을 개선합니다.

또한 사용 가능한 우선순위가 더 높은 새 작업이 있는 경우 작업자는 현재 세션이 종료되고 우선순위가 더 높은 작업의 새 세션이 할당되기 전에 이전에 할당된 모든 작업을 완료합니다.

단계 종속성

Deadline Cloud는 한 단계가 시작하기 전에 다른 단계가 완료될 때까지 대기하도록 단계 간 종속성 정의를 지원합니다. 단계에 대한 종속성을 두 개 이상 정의할 수 있습니다. 종속성이 있는 단계는 모든 종속성이 완료될 때까지 예약되지 않습니다.

작업 템플릿이 순환 종속성을 정의하면 작업이 거부되고 작업 상태가 로 설정됩니다CREATE_FAILED.

다음 작업 템플릿은 두 단계로 작업을 생성합니다.는에 StepB 따라 달라집니다StepA.는가 성공적으로 StepA 완료된 후에StepB만 실행됩니다.

작업이 생성된 후 StepA는 READY 상태가 되고 StepB는 PENDING 상태가 됩니다. 가 StepA 완료되면 READY 상태로 StepB 이동합니다. 가 StepA 실패하거나이 취소되면 StepA가 CANCELED 상태로 StepB 전환됩니다.

여러 단계에 종속성을 설정할 수 있습니다. 예를 들어 StepC가 StepA 및에 모두 의존하는 경우 StepBStepC는 다른 두 단계가 완료될 때까지 시작되지 않습니다.

단계 종속성에는 다음과 같은 제한이 있습니다.

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!