기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 작업 작업은에서 시작하는 작업 단위입니다 AWS Batch. 작업은 ECS 클러스터의 Amazon ECS 컨테이너 인스턴스에서 실행 중인 컨테이너화된 애플리케이션으로 실행될 수 있습니다. 컨테이너화된 작업은 컨테이너 이미지, 명령 및 파라미터를 참조할 수 있습니다. 자세한 내용은 [JobDefinition](https://docs.aws.amazon.com/batch/latest/APIReference/API_JobDefinition.html)을 참조하세요. 많은 수의 독립적인 단순 작업을 제출할 수 있습니다. **Topics** + [자습서: 작업 제출](submit_job.md) + [의 서비스 작업 AWS Batch](service-jobs.md) + [작업 상태](job_states.md) + [AWS Batch 작업 환경 변수](job_env_vars.md) + [작업 자동 재시도](job_retries.md) + [작업 종속성](job_dependencies.md) + [작업 제한 시간](job_timeouts.md) + [Amazon EKS 작업](eks-jobs.md) + [다중 노드 병렬 작업](multi-node-parallel-jobs.md) + [Amazon EKS의 다중 노드 병렬 작업](mnp-eks-jobs.md) + [배열 작업](array_jobs.md) + [GPU 작업 실행](gpu-jobs.md) + [AWS Batch 작업 대기열에서 작업 보기](view-jobs.md) + [작업 대기열에서 작업 AWS Batch 검색](searching-filtering-jobs.md) + [AWS Batch 작업에 대한 네트워킹 모드](networking-modes-jobs.md) + [CloudWatch Logs에서 AWS Batch 작업 로그 보기](review-job-logs.md) + [AWS Batch 작업 정보 검토](review-job-info.md) # 자습서: 작업 제출 작업 정의를 등록한 후 AWS Batch 작업 대기열에 작업으로 제출할 수 있습니다. 작업 정의에 지정된 많은 파라미터는 실행 시간에 재정의될 수 있습니다. **작업을 제출하는 방법** 1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) AWS Batch 콘솔을 엽니다. 1. 탐색 모음에서 사용할 AWS 리전 를 선택합니다. 1. 탐색 창에서 **작업**을 선택합니다. 1. **작업 제출**을 선택합니다. 1. **이름(Name)**에 고유한 작업 정의 이름을 입력합니다. 각 이름의 최대 길이는 128자입니다. 대문자 및 소문자, 숫자, 하이픈(-) 및 밑줄(\$1)을 포함할 수 있습니다. 1. **작업 정의**에서 작업에 대해 이전에 생성한 작업 정의를 선택합니다. 자세한 내용은 [단일 노드 작업 정의 생성](create-job-definition.md) 단원을 참조하십시오. 1. **작업 대기열**에서 기존 작업 대기열을 선택합니다. 자세한 내용은 [작업 대기열 생성](create-job-queue.md) 단원을 참조하십시오. 1. **작업 종속성**에서 **작업 종속성 추가**를 선택합니다. 1. **작업 ID**에는 모든 종속성에 대한 작업 ID를 입력합니다. 그런 다음 **작업 종속성 추가**를 선택합니다. 작업에는 최대 20개의 종속성이 있을 수 있습니다. 자세한 내용은 [작업 종속성](job_dependencies.md) 단원을 참조하십시오. 1. (배열 작업만 해당)**배열 크기**에서 배열 크기를 2\$110,000 사이로 지정합니다. 1. (선택 사항) **태그**를 확장한 다음 **태그 추가**를 선택하여 리소스에 태그를 추가합니다. 키와 선택 값을 입력하고 **태그 추가**를 선택합니다. 1. **다음 페이지**를 선택합니다. 1. **작업 재정의** 섹션에서: 1. (선택 사항) **예약 우선 순위**에 0에서 100 사이의 예약 우선 순위 값을 입력합니다. 값이 높을수록 우선 순위가 높습니다. 1. (선택 사항) **작업 시도**에 AWS Batch (이)가 작업을 특정 `RUNNABLE` 상태로 전환하기 위해 시도하는 최대 횟수를 입력합니다. 1\$110 사이의 숫자를 입력합니다. 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오. 1. (선택 사항) **실행 제한 시간**에 제한 시간 값(초)을 입력합니다. 실행 제한 시간은 완료되지 않은 작업이 종료되기까지의 시간입니다. 시도가 제한 시간을 초과하면 중지되고 상태가 `FAILED`(으)로 변경됩니다. 자세한 내용은 [작업 제한 시간](job_timeouts.md) 단원을 참조하십시오. 최솟값은 60초입니다. **중요** Fargate 리소스에서 실행되는 작업이 14일 이상 실행될 것이라고 기대하지 마세요. 14일이 지나면 작업이 종료되어 Fargate 리소스를 더 이상 사용할 수 없게 될 수 있습니다. 1. (선택 사항) 작업 및 작업 정의에서 Amazon ECS 태스크로 태그를 전파하려면 **태그 전파**를 활성화합니다. 1. **추가 구성**을 확장합니다. 1. (선택 사항) **재시도 전략 조건**의 경우 **종료 시 평가 추가**를 선택합니다. 파라미터 값을 하나 이상 입력한 다음 **작업**을 선택합니다. 각 조건 세트에 대해 **작업**을 **재시도** 또는 **종료**로 설정해야 합니다. 이러한 작업은 다음을 의미합니다. + **재시도** - 지정한 작업 시도 횟수에 도달할 때까지 AWS Batch 재시도합니다. + **종료** - 작업 재시도를 AWS Batch 중지합니다. **중요** **종료 시 평가 추가**를 선택한 경우 하나 이상의 파라미터를 구성하고 **작업**을 선택하거나 **종료 시 평가 제거**를 선택합니다. 1. **파라미터**에서 **파라미터 추가**를 선택하여 파라미터 대체 자리 표시자를 추가합니다. **키**와 선택 사항으로 **값**을 입력합니다. 1. **컨테이너 재정의**의 섹션에서: 1. **명령**에서 필드에 명령을 **JSON** 문자열 배열 형식으로 입력합니다. 이 파라미터는 [도커 원격 API(Docker Remote API)](https://docs.docker.com/engine/api/v1.38/)의 [컨테이너 생성(Create a container)](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) 섹션에 있는 `Cmd`(와)과 [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/)의 `COMMAND` 파라미터로 매핑됩니다. 도커 `CMD` 파라미터에 대한 자세한 정보는 [https://docs.docker.com/engine/reference/builder/\$1cmd](https://docs.docker.com/engine/reference/builder/#cmd)를 참조하세요. **참고** 이 파라미터는 빈 문자열을 포함할 수 없습니다. 1. **vCPU**에서 컨테이너에 예약할 vCPU 수를 지정합니다. 이 파라미터는 [Docker 원격 API(Docker Remote API)](https://docs.docker.com/engine/api/v1.38/)의 [컨테이너 생성(Create a container)](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) 섹션에 있는 `CpuShares`(와)과 [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/)에 대한 `--cpu-shares` 옵션에 매핑됩니다. 각 vCPU는 1,024개의 CPU 공유와 동일합니다. vCPU를 최소 하나 이상 지정해야 합니다. 1. **메모리**에는 컨테이너에 사용할 수 있는 메모리 한도를 입력합니다. 컨테이너가 여기에 지정된 메모리를 초과하려 하면 해당 컨테이너가 중지됩니다. 이 파라미터는 [Docker 원격 API(Docker Remote API)](https://docs.docker.com/engine/api/v1.38/)의 [컨테이너 생성(Create a container)](https://docs.docker.com/engine/api/v1.38/#operation/ContainerCreate) 섹션에 있는 `Memory`(와)과 [https://docs.docker.com/engine/reference/commandline/run/](https://docs.docker.com/engine/reference/commandline/run/)에 대한 `--memory` 옵션에 매핑됩니다. 한 작업에 대해 메모리를 최소한 4MiB 지정해야 합니다. **참고** 리소스 사용률을 극대화하려면 특정 인스턴스 유형의 작업에 메모리 우선 순위를 지정합니다. 자세한 내용은 [컴퓨팅 리소스 메모리 관리](memory-management.md) 단원을 참조하십시오. 1. (선택 사항)**GPU 수**에 컨테이너에 예약할 GPU 수를 선택합니다. 1. (선택 사항) **환경 변수**의 경우 **환경 변수 추가**를 선택하여 환경 변수를 이름-값 쌍으로 추가합니다. 이러한 변수는 컨테이너로 전달됩니다. 1. **다음 페이지**를 선택합니다. 1. **작업 검토(Job review)**에서 구성 단계를 검토하세요. 변경해야 하는 경우 **편집**을 선택합니다 작업을 마쳤으면 **작업 정의 생성**을 선택합니다. # 의 서비스 작업 AWS Batch AWS Batch 서비스 작업을 사용하면 AWS Batch 작업 대기열을 통해 AWS 서비스에 요청을 제출할 수 있습니다. 현재는 SageMaker 훈련 작업을 서비스 작업으로 AWS Batch 지원합니다. 가 기본 컨테이너 실행을 AWS Batch 관리하는 컨테이너화된 작업과 달리 서비스 작업은 대상 서비스 AWS (예: SageMaker AI)가 실제 작업 실행을 처리하는 동안가 작업 예약 및 대기열 기능을 AWS Batch 제공할 수 있도록 허용합니다. AWS Batch SageMaker 훈련 작업용를 사용하면 데이터 과학자가 우선순위가 있는 훈련 작업을 구성 가능한 대기열에 제출할 수 있으므로 리소스를 사용할 수 있게 되는 즉시 개입 없이 워크로드가 실행되도록 할 수 있습니다. 이 기능은 리소스 조정, 우발적인 과다 지출 방지, 예산 제약 조건 충족, 예약 인스턴스 비용 최적화, 팀원 간의 수동 조정 필요 제거와 같은 일반적인 문제를 해결합니다. 서비스 작업은 다음과 같은 몇 가지 주요 측면에서 컨테이너화된 작업과 다릅니다. + **작업 제출**: 서비스 작업은 [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) API를 사용하여 제출해야 합니다. 서비스 작업은 AWS Batch 콘솔을 통해 제출할 수 없습니다. + **작업 실행**: 서비스 작업을 AWS Batch 예약하고 대기열에 추가하지만 대상 AWS 서비스는 실제 작업 워크로드를 실행합니다. + **리소스 식별자**: 서비스 작업은 'job' 대신 'service-job'이 포함된 ARN을 사용하여 컨테이너화된 작업과 구분됩니다. SageMaker 훈련을 위한 AWS Batch 서비스 작업을 시작하려면 섹션을 참조하세요[SageMaker AI AWS Batch 에서 시작하기](getting-started-sagemaker.md). **Topics** + [의 서비스 작업 페이로드 AWS Batch](service-job-payload.md) + [에서 서비스 작업 제출 AWS Batch](service-job-submit.md) + [AWS Batch 서비스 작업 상태를 SageMaker AI 상태로 매핑](service-job-status.md) + [의 서비스 작업 재시도 전략 AWS Batch](service-job-retries.md) + [AWS Batch 대기열의 서비스 작업 모니터링](monitor-sagemaker-job-queue.md) + [서비스 작업 종료](terminate-service-jobs.md) # 의 서비스 작업 페이로드 AWS Batch [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)을 사용하여 서비스 작업을 제출할 때는 작업을 정의하는 두 가지 주요 파라미터인 `serviceJobType`과 `serviceRequestPayload`를 제공합니다. + 는 작업을 실행할 AWS 서비스를 `serviceJobType` 지정합니다. SageMaker 훈련 작업의 경우 이 값은 `SAGEMAKER_TRAINING`입니다. + `serviceRequestPayload`는 일반적으로 대상 서비스로 직접 전송되는 전체 요청을 포함하는 JSON 인코딩 문자열입니다. SageMaker 훈련 작업의 경우 이 페이로드에는 SageMaker AI [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html) API와 함께 사용되는 것과 동일한 파라미터가 포함됩니다. 사용 가능한 모든 파라미터의 전체 목록과 해당 설명은 SageMaker AI [CreateTrainingJob](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html) API 레퍼런스를 참조하세요. `CreateTrainingJob`에서 지원하는 모든 파라미터를 서비스 작업 페이로드에 포함할 수 있습니다. 추가 훈련 작업 구성의 예제는 [SageMaker AI 개발자 안내서](https://docs.aws.amazon.com/sagemaker/latest/dg/gs.html)의 [API, CLI 및 SDK](https://docs.aws.amazon.com/sagemaker/latest/dg/api-and-sdk-reference-overview.html)를 참조하세요. PySDK에는 헬퍼 클래스와 유틸리티가 있으므로 서비스 작업 생성에 PySDK를 사용할 것이 권장됩니다. PySDK 사용에 대한 예제는 GitHub의 [SageMaker AI 예제](https://github.com/aws/amazon-sagemaker-examples)를 참조하세요. ## 서비스 작업 페이로드 예제 다음 예제는 'hello world' 훈련 스크립트를 실행하는 SageMaker 훈련 작업에 대한 간단한 서비스 작업 페이로드를 보여줍니다. 이 페이로드는 `SubmitServiceJob`을 호출할 때 `serviceRequestPayload` 파라미터에 JSON 문자열로 전달됩니다. ``` { "TrainingJobName": "my-simple-training-job", "RoleArn": "arn:aws:iam::123456789012:role/SageMakerExecutionRole", "AlgorithmSpecification": { "TrainingInputMode": "File", "TrainingImage": "763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-cpu-py310", "ContainerEntrypoint": [ "echo", "hello world" ] }, "ResourceConfig": { "InstanceType": "ml.c5.xlarge", "InstanceCount": 1, "VolumeSizeInGB": 1 }, "OutputDataConfig": { "S3OutputPath": "s3://your-output-bucket/output" }, "StoppingCondition": { "MaxRuntimeInSeconds": 30 } } ``` # 에서 서비스 작업 제출 AWS Batch 서비스 작업을 제출하려면 [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html) API를 AWS Batch사용합니다. AWS CLI 또는 SDK를 사용하여 작업을 제출할 수 있습니다. 아직 실행 역할이 없는 경우 먼저 실행 역할을 생성해야 서비스 작업을 제출할 수 있습니다. SageMaker AI 실행 역할을 생성하려면 *[SageMaker AI 개발자 안내서](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)*의 [SageMaker AI 실행 역할을 사용하는 방법](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html)을 참조하세요. ## 서비스 작업 제출 워크플로 서비스 작업을 제출하면는 다음 워크플로를 AWS Batch 따릅니다. 1. AWS Batch 는 `[SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)` 요청을 수신하고 AWS Batch특정 파라미터를 검증합니다. `serviceRequestPayload`는 검증 없이 전달됩니다. 1. 작업이 `SUBMITTED` 상태로 전환되고 지정된 작업 대기열에 배치됩니다. 1. AWS Batch 는 대기열 앞에 있는 `RUNNABLE` 작업에 대해 서비스 환경에 사용 가능한 용량이 있는지 평가합니다. 1. 용량을 사용할 수 있는 경우 작업이 `SCHEDULED`로 이동하고 작업이 SageMaker AI로 전달됩니다. 1. 용량을 획득하고 SageMaker AI가 서비스 작업 데이터를 다운로드하면 서비스 작업이 초기화를 시작하고 작업이 `STARTING`으로 변경됩니다. 1. SageMaker AI가 작업을 실행하기 시작하면 상태가 `RUNNING`으로 변경됩니다. 1. SageMaker AI가 작업을 실행하는 동안는 진행 상황을 AWS Batch 모니터링하고 서비스 상태를 AWS Batch 작업 상태에 매핑합니다. 서비스 작업 상태가 매핑되는 방식에 대한 자세한 내용은 [AWS Batch 서비스 작업 상태를 SageMaker AI 상태로 매핑](service-job-status.md) 섹션을 참조하세요. 1. 서비스 작업이 완료되면 `SUCCEEDED`로 이동하고 출력을 다운로드할 준비가 됩니다. ## 사전 조건 서비스 작업을 제출하기 전에 다음을 갖추어야 합니다. + **서비스 환경** - 용량 제한을 정의하는 서비스 환경. 자세한 내용은 [에서 서비스 환경 생성 AWS Batch](create-service-environments.md) 단원을 참조하십시오. + **SageMaker 작업 대기열** - 작업 예약을 제공하는 SageMaker 작업 대기열. 자세한 내용은 [AWS Batch에서 SageMaker 훈련 작업 대기열 생성](create-sagemaker-job-queue.md) 단원을 참조하십시오. + **IAM 권한** - AWS Batch 작업 대기열 및 서비스 환경을 생성하고 관리할 수 있는 권한. 자세한 내용은 [AWS Batch IAM 정책, 역할 및 권한](IAM_policies.md) 단원을 참조하십시오. ## AWS CLI를 사용하여 서비스 작업 제출 다음은 AWS CLI를 사용하여 서비스 작업을 제출하는 방법을 보여줍니다. ``` aws batch submit-service-job \ --job-name "my-sagemaker-training-job" \ --job-queue "my-sagemaker-job-queue" \ --service-job-type "SAGEMAKER_TRAINING" \ --service-request-payload '{\"TrainingJobName\": \"sagemaker-training-job-example\", \"AlgorithmSpecification\": {\"TrainingImage\": \"123456789012.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.8.0-cpu-py3\", \"TrainingInputMode\": \"File\", \"ContainerEntrypoint\": [\"sleep\", \"1\"]}, \"RoleArn\":\"arn:aws:iam::123456789012:role/SageMakerExecutionRole\", \"OutputDataConfig\": {\"S3OutputPath\": \"s3://example-bucket/model-output/\"}, \"ResourceConfig\": {\"InstanceType\": \"ml.m5.large\", \"InstanceCount\": 1, \"VolumeSizeInGB\": 1}}' --client-token "unique-token-12345" ``` `serviceRequestPayload` 파라미터에 대한 자세한 내용은 [의 서비스 작업 페이로드 AWS Batch](service-job-payload.md)을 참조하세요. # AWS Batch 서비스 작업 상태를 SageMaker AI 상태로 매핑 [SubmitServiceJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitServiceJob.html)을 사용하여 SageMaker 작업 대기열에 작업을 제출하면는 작업 수명 주기를 AWS Batch 관리하고 AWS Batch [작업 상태를](job_states.md) 동등한 SageMaker 훈련 작업 상태로 매핑합니다. SageMaker 훈련 작업과 같은 서비스 작업은 기존 컨테이너 작업과 다른 상태 수명 주기를 따릅니다. 서비스 작업은 대부분의 상태를 컨테이너 작업과 공유하지만 `SCHEDULED` 상태를 사용하며 특히 대상 서비스의 용량 부족 오류 처리 등을 위해 다양한 재시도 동작을 보여줍니다. 다음 표에는 AWS Batch 작업 상태와 해당 SageMaker 상태/SecondaryStatus가 나와 있습니다. | Batch 상태 | SageMaker AI 기본 상태 | SageMaker AI 보조 상태 | 설명 | | --- | --- | --- | --- | | SUBMITTED | 해당 사항 없음 | 해당 사항 없음 | 작업이 대기열에 제출되었으며 스케줄러 평가를 기다리는 중입니다. | | RUNNABLE | 해당 사항 없음 | 해당 사항 없음 | 작업이 대기열에 있고 예약 준비가 되었습니다. 이 상태의 작업은 작업 대기열에 매핑된 서비스 환경에 충분한 리소스를 사용할 수 있게 되면 바로 시작됩니다. 사용 가능한 리소스가 충분하지 않으면 작업이 이 상태로 무기한 남아 있을 수 있습니다. | | SCHEDULED | InProgress | Pending | 서비스 작업이 SageMaker AI에 성공적으로 제출되었습니다. | | STARTING | InProgress | Downloading | SageMaker 훈련 작업이 데이터 및 이미지를 다운로드하는 중입니다. 훈련 작업 용량이 획득되고 작업 초기화가 시작됩니다. | | RUNNING | InProgress | Training | SageMaker 훈련 작업 실행 알고리즘 | | RUNNING | InProgress | Uploading | SageMaker 훈련 작업이 훈련 완료 후 출력 아티팩트를 업로드하는 중입니다. | | SUCCEEDED | Completed | Completed | SageMaker 훈련 작업이 성공적으로 완료되었습니다. 출력 아티팩트의 업로드가 완료되었습니다. | | FAILED | Failed | Failed | SageMaker 훈련 작업에서 복구할 수 없는 오류가 발생했습니다. | | FAILED | Stopped | Stopped | StopTrainingJob을 사용하여 SageMaker 훈련 작업을 수동으로 중지했습니다. | # 의 서비스 작업 재시도 전략 AWS Batch 서비스 작업 재시도 전략을 사용하면 AWS Batch 가 특정 조건에서 실패한 서비스 작업을 자동으로 재시도할 수 있습니다. 서비스 작업은 몇 가지 이유로 여러 번 시도해야 할 수 있습니다. + **일시적인 서비스 문제**: 내부 서비스 오류, 스로틀링 또는 일시적인 중단으로 인해 제출 또는 실행 중에 작업이 실패할 수 있습니다. + **훈련 초기화 실패**: 이미지 가져오기 문제 또는 초기화 오류와 같은 작업 시작 중 문제는 재시도를 통해 해결될 수 있습니다. 적절한 재시도 전략을 구성하면 특히 장기 실행 훈련 워크로드의 경우 작업 성공률을 높이고 수동 개입의 필요성을 줄일 수 있습니다. **참고** 서비스 작업은 구성된 재시도를 사용하지 않고도 용량 부족 오류와 같은 특정 실패 유형의 경우 자동으로 재시도를 실행합니다. 재시도 전략은 주로 알고리즘 오류 또는 서비스 문제와 같은 다른 유형의 실패를 다룹니다. ## 재시도 전략 구성 서비스 작업 재시도 전략은 단순 재시도 횟수와 조건부 재시도 로직을 모두 지원하는 [ServiceJobRetryStrategy](https://docs.aws.amazon.com/batch/latest/APIReference/API_ServiceJobRetryStrategy.html)를 사용하여 구성됩니다. ### 재시도 구성 가장 간단한 재시도 전략은 서비스 작업이 실패할 경우 수행해야 하는 재시도 횟수를 지정합니다. ``` { "retryStrategy": { "attempts": 3 } } ``` 이 구성을 사용하면 서비스 작업이 실패할 경우 최대 3회까지 재시도할 수 있습니다. **중요** `attempts` 값은 초기 시도를 포함하여 작업을 `RUNNABLE` 상태에 배치할 수 있는 총 횟수를 나타냅니다. 값이 3이면 작업이 처음에 한 번 시도된 다음 실패할 경우 최대 2회 더 시도됩니다. ### evaluateOnExit를 사용하여 구성 재시도 `evaluateOnExit` 파라미터를 사용하여 작업을 재시도하거나 실패하도록 허용하는 조건을 지정할 수 있습니다. 이는 다양한 유형의 장애에 서로 다른 처리가 필요한 경우에 유용합니다. `evaluateOnExit` 배열은 최대 5개의 재시도 전략을 포함할 수 있으며, 각 전략은 상태 사유를 기반으로 작업(`RETRY` 또는 `EXIT`)과 조건을 지정합니다. ``` { "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "action": "RETRY", "onStatusReason": "Received status from SageMaker: InternalServerError*" }, { "action": "EXIT", "onStatusReason": "Received status from SageMaker: ValidationException*" }, { "action": "EXIT", "onStatusReason": "*" } ] } } ``` 이 구성은 다음과 같습니다. + SageMaker AI 내부 서버 오류로 인해 실패한 작업에 대해 재시도 실행 + 검증 예외(다시 시도해도 해결되지 않는 클라이언트 오류)가 발생하는 작업은 즉시 실패 + 다른 모든 장애 유형에 대해 종료 처리하는 포괄적 규칙 포함 #### 상태 사유 패턴 일치 `onStatusReason` 파라미터는 최대 512자의 패턴 일치를 지원합니다. 패턴은 와일드카드(\$1)를 사용하고 SageMaker AI에서 반환한 상태 사유에 일치시킬 수 있습니다. 서비스 작업의 경우 SageMaker AI의 상태 메시지 앞에 "Received status from SageMaker: " 접두사가 붙어 AWS Batch생성된 메시지와 구분합니다. 일반적인 패턴은 다음과 같습니다. + `Received status from SageMaker: InternalServerError*` - 내부 서비스 오류 일치 + `Received status from SageMaker: ValidationException*` - 클라이언트 검증 오류 일치 + `Received status from SageMaker: ResourceLimitExceeded*` - 리소스 제한 오류 일치 + `*CapacityError*` - 용량 관련 실패 일치 **작은 정보** 특정 패턴 일치를 사용하면 다양한 오류 유형을 적절하게 처리할 수 있습니다. 예를 들어 내부 서버 오류는 재시도하지만 작업 파라미터 문제를 나타내는 검증 오류는 즉시 실패 처리할 수 있습니다. # AWS Batch 대기열의 서비스 작업 모니터링 `list-service-jobs` 및 `get-job-queue-snapshot`을 사용하여 SageMaker 훈련 작업 대기열의 작업 상태를 모니터링할 수 있습니다. 대기열에서 실행 중인 작업 보기: ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status RUNNING ``` 대기열에서 대기 중인 작업을 봅니다. ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status RUNNABLE ``` SageMaker에 제출되었지만 아직 실행되지 않은 작업 보기: ``` aws batch list-service-jobs \ --job-queue my-sm-training-fifo-jq \ --job-status SCHEDULED ``` 대기열 앞에 있는 작업의 스냅샷을 가져옵니다. ``` aws batch get-job-queue-snapshot --job-queue my-sm-training-fifo-jq ``` 이 명령은 대기열에서 예정된 서비스 작업의 순서를 보여줍니다. ## 자세한 서비스 작업 정보 가져오기 [https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeServiceJob.html) 작업을 사용하여 현재 상태, 서비스 리소스 식별자 및 자세한 시도 정보를 포함하여 특정 서비스 작업에 대한 포괄적인 정보를 가져옵니다. 특정 작업에 대한 세부 정보를 봅니다. ``` aws batch describe-service-job \ --job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d ``` 이 명령은 다음을 포함하여 작업에 대한 포괄적인 정보를 반환합니다. + 작업 ARN 및 현재 상태 + 서비스 리소스 식별자(예: SageMaker 훈련 작업 ARN) + 예약 우선 순위 및 재시도 구성 + 원래 서비스 파라미터를 포함하는 서비스 요청 페이로드 + 시작 및 중지 시간이 포함된 자세한 시도 정보 + 대상 서비스의 상태 메시지 ## SageMaker 훈련 작업 모니터링 를 통해 SageMaker 훈련 작업을 모니터링할 때 AWS Batch 작업 정보와 기본 SageMaker 훈련 작업 세부 정보에 모두 액세스할 AWS Batch수 있습니다. 작업 세부 정보의 서비스 리소스 식별자에는 SageMaker 훈련 작업 ARN이 포함됩니다. ``` { "latestAttempt": { "serviceResourceId": { "name": "TrainingJobArn", "value": "arn:aws:sagemaker:us-east-1:123456789012:training-job/my-training-job" } } } ``` 이 ARN을 사용하여 SageMaker에서 추가 세부 정보를 직접 가져올 수 있습니다. ``` aws sagemaker describe-training-job \ --training-job-name my-training-job ``` AWS Batch 상태와 SageMaker 훈련 작업 상태를 모두 확인하여 작업 진행 상황을 모니터링합니다. AWS Batch 작업 상태에는 전체 작업 수명 주기를 표시하는 반면, SageMaker 훈련 작업 상태는 훈련 프로세스에 대한 서비스별 세부 정보를 제공합니다. # 서비스 작업 종료 [https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_TerminateServiceJob.html) 작업을 사용하여 실행 중인 서비스 작업을 중지합니다. 특정 서비스 작업을 종료합니다. ``` aws batch terminate-service-job \ --job-id a4d6c728-8ee8-4c65-8e2a-9a5e8f4b7c3d \ --reason "Job terminated by user request" ``` 서비스 작업을 종료하면가 작업을 AWS Batch 중지하고 대상 서비스에 알립니다. SageMaker 훈련 작업의 경우, SageMaker AI의 훈련 작업도 중지됩니다. # 작업 상태 작업을 작업 AWS Batch 대기열에 제출하면 작업이 `SUBMITTED` 상태로 전환됩니다. 그런 다음 작업은 성공(`0` 코드와 함께 종료)하거나 실패(0이 아닌 코드와 함께 종료)할 때까지 다음 상태를 통과합니다. AWS Batch 작업은 다음 상태일 수 있습니다. `SUBMITTED` 대기열에 제출되었으며 스케줄러에서 아직 평가되지 않은 작업입니다. 스케줄러는 작업을 평가하여 다른 작업이 성공적으로 완료되어야 하는 종속성이 남아 있는지를 확인합니다. 종속성이 있으면 작업이 `PENDING` 상태로 됩니다. 종속성이 없으면 작업이 `RUNNABLE` 상태로 됩니다. `PENDING` 대기열에 있지만 다른 작업이나 리소스에 대한 종속성으로 인해 아직 실행할 수 없는 작업입니다. 종속성이 해결되면 작업이 `RUNNABLE` 상태로 됩니다. 배열 작업 상위는 하위 작업이 로 업데이트될 `PENDING` 때 로 업데이트되고 하위 작업이 실행되는 동안 `PENDING` 상태를 `RUNNABLE` 유지합니다. 이러한 작업을 보려면 모든 하위 작업이 터미널 상태에 도달할 때까지 `PENDING` 상태를 기준으로 필터링합니다. `RUNNABLE` 대기열에 있으며 남아 있는 종속성이 없어서 호스트로 예약된 작업입니다. 이 상태의 작업은 해당 작업 대기열에 매핑된 컴퓨팅 환경 중 하나에서 리소스가 충분해지자마자 시작됩니다. 그러나 사용 가능한 리소스가 충분하지 않으면 작업이 이 상태로 무기한 남아 있을 수 있습니다. 작업이 `STARTING`(으)로 진행되지 않으면 문제 해결 섹션의 [`RUNNABLE` 상태에서 정체된 작업](job_stuck_in_runnable.md)을 참조하세요. `STARTING` 이러한 작업은 호스트로 일정이 예약되었고 관련 컨테이너 개시 작업이 진행 중입니다. 컨테이너 이미지를 가져와서 컨테이너가 가동 및 실행되면 작업이 `RUNNING` 상태로 전환됩니다. 이미지 가져오기 지속 시간, Amazon EKS initContainers 완료 지속 시간 및 Amazon ECS containerDependency 해결 지속 시간은 STARTING 상태에서 발생합니다. 작업의 이미지를 가져오는 데 소요되는 시간은 작업이 STARTING 상태에 있는 시간과 동일합니다. 예를 들어, 작업의 이미지를 가져오는 데 3분이 걸리는 경우 작업은 3분 동안 STARTING 상태가 됩니다. initContainers를 완료하는 데 총 10분이 걸리면 Amazon EKS 작업은 10분 동안 STARTING 상태가 됩니다. Amazon ECS 작업에 Amazon ECS containerDependencies 세트가 있는 경우 모든 컨테이너 종속성(런타임)이 해결될 때까지 작업이 STARTING 상태가 됩니다. STARTING 상태는 제한 시간에 포함되지 않습니다. 이 기간은 RUNNING 상태에서 시작됩니다. 자세한 내용은 [작업 상태](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html) 섹션을 참조하세요. `RUNNING` 작업이 컴퓨팅 환경 내의 Amazon ECS 컨테이너 인스턴스에서 컨테이너 작업으로 실행 중입니다. 작업의 컨테이너가 종료되면 프로세스가 종료 코드에 따라 작업의 성공 또는 실패가 결정됩니다. 종료 코드 `0`(은)는 성공을 나타내고, 0이 아닌 다른 코드는 실패를 나타냅니다. 실패한 시도와 연결된 작업의 재시도 전략 구성(선택 사항)에 재시도 횟수가 남아 있으면 작업이 다시 `RUNNABLE` 상태로 됩니다. 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오. `RUNNING` 작업 로그는 CloudWatch Logs에서 확인할 수 있습니다. 로그 그룹은 `/aws/batch/job`이며 로그 스트림 이름 형식은 `first200CharsOfJobDefinitionName/default/ecs_task_id`입니다. 그러나 이 점은 추후 개선될 것입니다. 작업이 `RUNNING` 상태에 도달한 후에는 [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업을 사용하여 프로그래밍 방식으로 해당 로그 스트림 이름을 검색할 수 있습니다. 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch Logs에 보낸 로그 데이터 보기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) 섹션을 참조하세요. 기본적으로 이러한 로그는 만료되지 않습니다. 그러나 백업 보존 기간은 수정할 수 있으며, 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch에서 로그 데이터 보존 기간 변경](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)을 참조하세요. `SUCCEEDED` 작업이 종료 코드 `0`(와)과 함께 성공적으로 완료되었습니다. 작업의 `SUCCEEDED` 작업 상태는 최소 7일 AWS Batch 동안에 유지됩니다. `SUCCEEDED` 작업 로그는 CloudWatch Logs에서 확인할 수 있습니다. 로그 그룹은 `/aws/batch/job`이며 로그 스트림 이름 형식은 `first200CharsOfJobDefinitionName/default/ecs_task_id`입니다. 이 형식은 향후 변경될 수 있습니다. 작업이 `RUNNING` 상태에 도달한 후에는 [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업을 사용하여 프로그래밍 방식으로 해당 로그 스트림 이름을 검색할 수 있습니다. 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch Logs에 보낸 로그 데이터 보기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) 섹션을 참조하세요. 기본적으로 이러한 로그는 만료되지 않습니다. 그러나 백업 보존 기간은 수정할 수 있으며, 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch에서 로그 데이터 보존 기간 변경](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)을 참조하세요. `FAILED` 작업이 사용 가능한 모든 시도에서 실패했습니다. `FAILED` 작업의 작업 상태는 AWS Batch 에서 최소 7일 동안 지속됩니다. `FAILED` 작업 로그는 CloudWatch Logs에서 확인할 수 있습니다. 로그 그룹은 `/aws/batch/job`이며 로그 스트림 이름 형식은 `first200CharsOfJobDefinitionName/default/ecs_task_id`입니다. 이 형식은 향후 변경될 수 있습니다. 작업이 `RUNNING` 상태에 도달한 후에는 [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업을 사용하여 프로그래밍 방식으로 해당 로그 스트림을 검색할 수 있습니다. 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch Logs에 보낸 로그 데이터 보기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) 섹션을 참조하세요. 기본적으로 이러한 로그는 만료되지 않습니다. 그러나 백업 보존 기간은 수정할 수 있으며, 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [CloudWatch에서 로그 데이터 보존 기간 변경](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)을 참조하세요. # AWS Batch 작업 환경 변수 AWS Batch 는 컨테이너 작업에서 특정 환경 변수를 설정합니다. 이러한 환경 변수는 작업 내 컨테이너에 대한 내부 검사를 제공합니다. 애플리케이션 로직에서 이러한 변수 값을 사용할 수 있습니다. 를 AWS Batch 설정하는 모든 변수는 `AWS_BATCH_` 접두사로 시작합니다. 이는 보호되는 환경 변수 접두사입니다. 작업 정의 또는 재정의의 자체 변수에는 이 접두사를 사용할 수 없습니다. 다음 환경 변수는 작업 컨테이너에서 사용할 수 있습니다. `AWS_BATCH_CE_NAME` 이 변수는 작업이 배치되는 컴퓨팅 환경의 이름으로 설정됩니다. `AWS_BATCH_JOB_ARRAY_INDEX` 이 변수는 하위 배열 작업에서만 지정됩니다. 배열 작업 인덱스는 0에서 시작하며, 각 하위 작업은 고유의 인덱스 번호를 받습니다. 예를 들면 하위가 10개인 배열 작업의 인덱스 값은 0\$19입니다. 이 인덱스 값을 사용하여 차별화된 배열 작업 하위에 따라 관리할 수 있습니다. 자세한 내용은 [배열 작업 인덱스를 사용한 작업 차별화 관리](array_index_example.md) 단원을 참조하십시오. `AWS_BATCH_JOB_ARRAY_SIZE` 이 변수는 상위 배열 작업의 크기로 설정됩니다. 상위 배열 작업의 크기는 이 변수의 하위 배열 작업에 전달됩니다. `AWS_BATCH_JOB_ATTEMPT` 이 변수는 작업 시도 횟수로 지정됩니다. 첫 번째 시도는 번호 1입니다. 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오. `AWS_BATCH_JOB_ID` 이 변수는 AWS Batch 작업 ID로 설정됩니다. `AWS_BATCH_JOB_KUBERNETES_NODE_UID` 이 변수는 포드가 실행되는 Kubernetes 클러스터에 있는 노드 객체의 Kubernetes UID로 설정됩니다. 이 변수는 Amazon EKS 리소스에서 실행되는 작업에만 설정됩니다. 자세한 내용은 *Kubernetes 설명서*의 [UDI(UIDs)](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids)를 참조하세요. `AWS_BATCH_JOB_MAIN_NODE_INDEX` 이 변수는 다중 노드 병렬 작업에서만 설정됩니다. 이 변수는 작업 기본 노드의 인덱스 번호로 설정됩니다. 애플리케이션 코드는 `AWS_BATCH_JOB_MAIN_NODE_INDEX`(을)를 개별 노드의 `AWS_BATCH_JOB_NODE_INDEX`(와)과 비교하여 이 노드가 기본 노드인지를 확인할 수 있습니다. `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` 이 변수는 다중 노드 병렬 작업 하위 노드에서만 설정됩니다. 이 변수는 기본 노드에 존재하지 않지만 작업 기본 노드의 프라이빗 IPv4 주소로 설정됩니다. 하위 노드의 애플리케이션 코드는 이 주소를 사용하여 기본 노드와 통신할 수 있습니다. `AWS_BATCH_JOB_NODE_INDEX` 이 변수는 다중 노드 병렬 작업에서만 설정됩니다. 이 변수는 노드의 노드 인덱스 번호로 설정됩니다. 노드 인덱스는 0에서 시작하며, 각 노드는 고유의 인덱스 번호를 받습니다. 예를 들면 하위가 10개 있는 다중 노드 병렬 작업의 인덱스 값은 0\$19입니다. `AWS_BATCH_JOB_NUM_NODES` 이 변수는 다중 노드 병렬 작업에서만 설정됩니다. 이 변수는 다중 노드 병렬 작업에 대해 요청한 노드 수로 설정됩니다. `AWS_BATCH_JQ_NAME` 이 변수는 작업이 제출된 대상 작업 대기열의 이름으로 설정됩니다. # 작업 자동 재시도 실패한 작업을 자동으로 작업을 재시도하도록 허용하는 재시도 전략을 작업 및 작업 정의에 적용할 수 있습니다. 작업이 실패하는 상황은 다음과 같습니다. + 컨테이너 작업에서 0이 아닌 종료 코드 반환 + Amazon EC2 인스턴스 실패 또는 종료 + 내부 AWS 서비스 오류 또는 중단 작업이 작업 대기열로 제출되어 `RUNNING` 상태가 되면 한 번의 시도로 간주됩니다. 기본적으로 각 작업에는 `SUCCEEDED` 또는 `FAILED` 작업 상태가 되기 위해 한 번의 시도가 주어집니다. 그러나 작업 정의와 작업 제출 워크플로를 통해 1회부터 10회까지 재시도 전략을 지정할 수 있습니다. [evaluateOnExit](job_definition_parameters.md#retryStrategy-evaluateOnExit)를 지정하는 경우 최대 5개의 재시도 전략을 포함할 수 있습니다. [evaluateOnExit](https://docs.aws.amazon.com/batch/latest/APIReference/API_EvaluateOnExit.html)를 지정했지만 일치하는 재시도 전략이 없는 경우 작업이 다시 시도됩니다. 종료와 일치하지 않는 작업의 경우 어떤 이유로든 종료되는 최종 항목을 추가하세요. 예를 들어, 이 `evaluateOnExit` 객체에는 `RETRY` 작업이 있는 두 개의 항목과 `EXIT` 작업이 있는 최종 항목이 있습니다. ``` "evaluateOnExit": [ { "action": "RETRY", "onReason": "AGENT" }, { "action": "RETRY", "onStatusReason": "Task failed to start" }, { "action": "EXIT", "onReason": "*" } ] ``` 실행 시간 시 `AWS_BATCH_JOB_ATTEMPT` 환경 변수가 컨테이너의 해당 작업 시도 횟수에 설정됩니다. 첫 번째 시도에 `1`(이)가 지정되고 이후 시도는 2, 3, 4 등과 같이 오름차순으로 횟수가 지정됩니다. 예를 들어, 어떤 이유로든 작업 시도가 실패하고 재시도 구성에 지정된 시도 횟수가 `AWS_BATCH_JOB_ATTEMPT` 수보다 크다고 가정해 보겠습니다. 그러면 작업이 다시 `RUNNABLE` 상태로 돌아옵니다. 자세한 내용은 [작업 상태](job_states.md) 단원을 참조하십시오. **참고** 취소되거나 종료된 작업은 재시도되지 않습니다. 잘못된 작업 정의로 인해 실패한 작업도 재시도되지 않습니다. 자세한 내용은 [재시도 전략](job_definition_parameters.md#retryStrategy), [단일 노드 작업 정의 생성](create-job-definition.md), [자습서: 작업 제출](submit_job.md) 및 [중지된 태스크 오류 코드](https://docs.aws.amazon.com/AmazonECS/latest/userguide/stopped-task-error-codes.html)를 참조하세요. # 작업 종속성 AWS Batch 작업을 제출할 때 작업이 의존하는 작업 IDs를 지정할 수 있습니다. 이렇게 하면 AWS Batch 스케줄러는 지정된 종속성이 성공적으로 완료된 후에만 작업이 실행되도록 합니다. 성공한 이후 종속된 작업은 `PENDING`에서 `RUNNABLE`(으)로, 그런 다음 `STARTING` 및 `RUNNING`(으)로 전환합니다. 어떠한 작업 속성이 실패한 경우 종속된 작업은 자동적으로 `PENDING`에서 `FAILED`(으)로 전환합니다. 예를 들어 Job A는 최대 20개의 다른 작업에 대한 종속성을 나타낼 수 있으며, 이는 실행 전에 성공해야 합니다. 그런 다음 Job A와 최대 19개의 다른 작업에 대해 종속성을 갖는 추가 작업을 제출할 수 있습니다. 배열 작업의 경우 작업 ID를 입력하지 않고 `SEQUENTIAL` 유형 종속성을 지정할 수 있습니다. 그러면 각 하위 배열 작업은 인덱스 0부터 순차적으로 완료됩니다. 작업 ID를 사용하여 `N_TO_N` 유형 종속성을 지정할 수도 있습니다. 이 방법을 사용하면 이 작업의 각 인덱스 하위는 각 종속성의 해당 인덱스 하위가 완료될 때까지 기다린 후에만 시작할 수 있습니다. 자세한 내용은 [배열 작업](array_jobs.md) 단원을 참조하십시오. 종속성이 있는 AWS Batch 작업을 제출하려면 섹션을 참조하세요[자습서: 작업 제출](submit_job.md). [리소스 인식 일정 예약](resource-aware-scheduling.md)을 사용하면 작업을 실행하는 데 필요한 소모성 리소스를 기반으로 작업을 예약할 수 있습니다. 작업을 실행하는 데 필요한 소모성 리소스를 지정하면 Batch는 작업을 예약할 때 이러한 리소스 종속성을 고려합니다. 필요한 모든 리소스를 사용할 수 있는 작업만 할당하여 컴퓨팅 리소스의 활용도 저하를 줄일 수 있습니다. 리소스 인식 예약은 FIFO 및 공정 공유 예약 정책 모두에 사용할 수 있으며 EKS, ECS 및 Fargate를 포함하여 Batch에서 지원하는 모든 컴퓨팅 플랫폼에서 사용할 수 있습니다. 배열 작업, 다중 노드 병렬(MNP) 작업 및 일반 배치 작업과 함께 사용할 수 있습니다. # 작업 제한 시간 작업이 더 오래 실행되면 AWS Batch (이)가 작업을 종료하도록 작업의 제한 시간을 구성할 수 있습니다. 예를 들어, 15분이면 완료되는 작업이 있을 수 있습니다. 경우에 따라 애플리케이션이 루프에서 정체되고 끝없이 실행되면 30분의 제한 시간을 설정하여 정체된 작업을 종료할 수 있습니다. **중요** 기본적으로 AWS Batch 에는 작업 제한 시간이 없습니다. 작업 제한 시간을 정의하지 않으면 컨테이너가 종료될 때까지 작업이 실행됩니다. 작업 정의 또는 작업 제출 시 `attemptDurationSeconds` 파라미터(최소 60초여야 함)를 지정합니다. 작업 시도의 `startedAt` 타임스탬프 이후이 초가 경과하면가 작업을 AWS Batch 종료합니다. 컴퓨팅 리소스에서 작업 컨테이너는 애플리케이션에 정상적으로 종료할 수 있는 기회를 주기 위해 `SIGTERM` 신호를 수신합니다. 컨테이너가 30초 후에도 여전히 실행 중이면 컨테이너를 강제로 종료하기 위해 `SIGKILL` 신호가 전송됩니다. 제한 시간 종료는 최선의 방식으로 처리됩니다. 작업 시도의 시간이 초과될 때 제한 시간이 정확히 종료될 것으로 기대해서는 안됩니다(몇 초 정도 더 오래 걸릴 수 있음). 애플리케이션에 정확한 제한 시간 실행이 필요한 경우 애플리케이션 내에서 이 로직을 구현해야 합니다. 다수의 작업이 동시에 시간 초과되는 경우, 제한 시간 종료는 작업이 일괄적으로 종료되는 FIFO(선입선출) 대기열로 작동합니다. **참고** AWS Batch 작업에 대한 최대 제한 시간 값은 없습니다. 제한 시간을 초과하여 작업이 종료되면 재시도되지 않습니다. 작업 시도가 자체적으로 실패하면 재시도가 활성화된 경우 재시도할 수 있으며 새로운 시도를 위해 제한 시간 카운트다운이 다시 시작됩니다. **중요** Fargate 리소스에서 실행되는 작업은 14일 이상 실행되지 않습니다. 제한 시간이 14일을 초과하면 Fargate 리소스를 더 이상 사용할 수 없으며 작업이 종료됩니다. 배열 작업의 경우 하위 작업은 상위 작업과 제한 시간 구성이 동일합니다. 제한 시간 구성을 사용하여 AWS Batch 작업을 제출하는 방법에 대한 자세한 내용은 섹션을 참조하세요[자습서: 작업 제출](submit_job.md). # Amazon EKS 작업 작업은에서 가장 작은 작업 단위입니다 AWS Batch. Amazon EKS의 AWS Batch 작업에는 Kubernetes 포드에 대한 one-to-one 매핑이 있습니다. AWS Batch 작업 정의는 AWS Batch 작업에 대한 템플릿입니다. AWS Batch 작업을 제출할 때 작업 정의를 참조하고, 작업 대기열을 대상으로 지정하고, 작업 이름을 제공합니다. Amazon EKS AWS Batch 에서 작업의 작업 정의에서 [eksProperties](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html) 파라미터는 AWS Batch Amazon EKS에서가 지원하는 파라미터 세트를 정의합니다. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) 요청에서 [eksPropertiesOverride](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html) 파라미터를 사용하면 일부 공통 파라미터를 재정의할 수 있습니다. 이렇게 하면 여러 작업에 대한 작업 정의 템플릿을 사용할 수 있습니다. 작업이 Amazon EKS 클러스터로 디스패치되면는 작업을 `podspec` ()로 AWS Batch 변환합니다`Kind: Pod`. 는 몇 가지 추가 AWS Batch 파라미터를 `podspec` 사용하여 작업이 올바르게 조정되고 예약되도록 합니다.는 레이블과 테인트를 AWS Batch 결합하여 작업이 AWS Batch 관리형 노드에서만 실행되도록 하고 다른 포드는 해당 노드에서 실행되지 않도록 합니다. **중요** Amazon EKS 작업 정의에서 `hostNetwork` 파라미터가 명시적으로 설정되지 않은 경우의 포드 네트워킹 모드는 AWS Batch 기본적으로 호스트 모드로 설정됩니다. 보다 구체적으로 `hostNetwork=true` 및 `dnsPolicy=ClusterFirstWithHostNet`(와)과 같은 설정이 적용됩니다. AWS Batch 는 포드가 작업을 완료한 직후 작업 포드를 정리합니다. 포드 애플리케이션 로그를 보려면 클러스터의 로깅 서비스를 구성하세요. 자세한 내용은 [CloudWatch Logs를 사용하여 Amazon EKS 작업 AWS Batch 에서 모니터링](batch-eks-cloudwatch-logs.md) 단원을 참조하십시오. **Topics** + [자습서: 실행 중인 작업을 포드 및 노드에 매핑하기](eks-jobs-map-running-job.md) + [자습서: 실행 중인 포드를 해당 작업에 다시 매핑하기](eks-jobs-map-running-pod-to-job.md) # 자습서: 실행 중인 작업을 포드 및 노드에 매핑하기 실행 중인 작업의 `podProperties`에는 현재 작업 시도에 대해 설정된 `podName` 및 `nodeName` 파라미터가 있습니다. 이러한 파라미터를 보려면 [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업을 사용하세요. 다음은 예제 출력입니다. ``` $ aws batch describe-jobs --job 2d044787-c663-4ce6-a6fe-f2baf7e51b04 { "jobs": [ { "status": "RUNNING", "jobArn": "arn:aws:batch:us-east-1:123456789012:job/2d044787-c663-4ce6-a6fe-f2baf7e51b04", "jobDefinition": "arn:aws:batch:us-east-1:123456789012:job-definition/MyJobOnEks_SleepWithRequestsOnly:1", "jobQueue": "arn:aws:batch:us-east-1:123456789012:job-queue/My-Eks-JQ1", "jobId": "2d044787-c663-4ce6-a6fe-f2baf7e51b04", "eksProperties": { "podProperties": { "nodeName": "ip-192-168-55-175.ec2.internal", "containers": [ { "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "resources": { "requests": { "cpu": "1", "memory": "1024Mi" } } } ], "podName": "aws-batch.b0aca953-ba8f-3791-83e2-ed13af39428c" } } } ] } ``` 재시도가 활성화된 작업의 경우 완료된 모든 시도 `podName` 및 `nodeName`(은)는 [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업의 `eksAttempts` 목록 파라미터에 있습니다. 현재 실행 중인 시도의 `podName` 및 `nodeName`(은)는 `podProperties` 객체에 있습니다. # 자습서: 실행 중인 포드를 해당 작업에 다시 매핑하기 포드에는 포드가 속한 컴퓨팅 환경`uuid`의 `jobId` 및를 나타내는 레이블이 있습니다.는 작업의 런타임이 작업 정보를 참조할 수 있도록 환경 변수를 AWS Batch 삽입합니다. 자세한 내용은 [AWS Batch 작업 환경 변수](job_env_vars.md) 단원을 참조하십시오. 다음 명령을 실행하여 이 작업을 수행할 수 있습니다. 출력값은 다음과 같습니다. ``` $ kubectl describe pod aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 -n my-aws-batch-namespace Name: aws-batch.14638eb9-d218-372d-ba5c-1c9ab9c7f2a1 Namespace: my-aws-batch-namespace Priority: 0 Node: ip-192-168-45-88.ec2.internal/192.168.45.88 Start Time: Wed, 26 Oct 2022 00:30:48 +0000 Labels: batch.amazonaws.com/compute-environment-uuid=5c19160b-d450-31c9-8454-86cf5b30548f batch.amazonaws.com/job-id=f980f2cf-6309-4c77-a2b2-d83fbba0e9f0 batch.amazonaws.com/node-uid=a4be5c1d-9881-4524-b967-587789094647 ... Status: Running IP: 192.168.45.88 IPs: IP: 192.168.45.88 Containers: default: Image: public.ecr.aws/amazonlinux/amazonlinux:2 ... Environment: AWS_BATCH_JOB_KUBERNETES_NODE_UID: a4be5c1d-9881-4524-b967-587789094647 AWS_BATCH_JOB_ID: f980f2cf-6309-4c77-a2b2-d83fbba0e9f0 AWS_BATCH_JQ_NAME: My-Eks-JQ1 AWS_BATCH_JOB_ATTEMPT: 1 AWS_BATCH_CE_NAME: My-Eks-CE1 ... ``` **AWS Batch Amazon EKS 작업이 지원하는 기능** 다음은 Amazon EKS에서 실행되는 Kubernetes 작업에도 일반적인 AWS Batch 특정 기능입니다. + [작업 종속성](job_dependencies.md) + [배열 작업](array_jobs.md) + [작업 제한 시간](job_timeouts.md) + [작업 자동 재시도](job_retries.md) + [공정 공유 일정을 사용하여 작업 예약 지원](fair-share-scheduling.md) **Kubernetes 및 `Secrets``ServiceAccounts`** AWS Batch 는 Kubernetes `Secrets` 및 참조를 지원합니다`ServiceAccounts`. 서비스 계정에 Amazon EKS IAM 역할을 사용하도록 포드를 구성할 수 있습니다. 자세한 내용은 [https://docs.aws.amazon.com/eks/latest/userguide/](https://docs.aws.amazon.com/eks/latest/userguide/)의 [포드를 구성하여 Kubernetes 서비스 계정 사용하기](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html)를 참조하세요. **관련 문서** + [Amazon EKS의 AWS Batch에 대한 메모리 및 vCPU 고려 사항](memory-cpu-batch-eks.md) + [GPU 작업 실행](gpu-jobs.md) + [`RUNNABLE` 상태에서 정체된 작업](job_stuck_in_runnable.md) # 다중 노드 병렬 작업 다중 노드 병렬 작업을 사용하면 여러 Amazon EC2 인스턴스에 걸쳐 단일 작업을 실행할 수 있습니다. AWS Batch 다중 노드 병렬 작업(단체 예약이라고도 함)을 사용하면 Amazon EC2 리소스를 직접 시작, 구성 및 관리할 필요 없이 긴밀하게 결합된 대규모 고성능 컴퓨팅 애플리케이션과 분산 GPU 모델 학습을 실행할 수 있습니다.** AWS Batch 다중 노드 병렬 작업은 IP 기반 노드 간 통신을 지원하는 모든 프레임워크와 호환됩니다. Apache MXNet, TensorFlow, Caffe2 또는 Message Passing Interface (MPI) 등을 예로 들 수 있습니다. 다중 노드 병렬 작업은 단일 작업으로 제출됩니다. 하지만 작업 정의(또는 작업 제출 노드 재정의)는 작업에 생성할 노드 수와 생성할 노드 그룹을 지정합니다. 각 다중 노드 병렬 작업에는 처음에 시작되는 **기본 노드**가 포함됩니다. 기본 노드가 가동된 후 하위 노드가 시작됩니다. 메인 노드가 종료되는 경우에만 작업이 완료됩니다. 그러면 모든 하위 노드가 중지됩니다. 자세한 내용은 [노드 그룹](mnp-node-groups.md) 단원을 참조하십시오. 다중 노드 병렬 작업 노드는 단일 테넌트입니다. 즉, 각 Amazon EC2 인스턴스에서 작업 컨테이너가 하나만 실행됩니다. 최종 작업 상태(`SUCCEEDED` 또는 `FAILED`)는 기본 노드의 최종 작업 상태에 따라 결정됩니다. 다중 노드 병렬 작업의 상태를 가져오려면 작업을 제출할 때 반환된 작업 ID를 사용하여 작업을 설명할 수 있습니다. 하위 노드에 대한 세부 정보가 필요한 경우 각 하위 노드를 개별적으로 설명해야 합니다. `#N` 표기법(0부터 시작)을 사용하여 노드에 주소를 지정할 수 있습니다. 예를 들어 작업의 두 번째 노드에 대한 세부 정보에 액세스하려면 AWS Batch [DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html) API 작업을 사용하여 *aws\$1batch\$1job\$1id*\$11을 설명합니다. 다중 노드 병렬 작업에 대한 `started`, `stoppedAt`, `statusReason` 및 `exit` 정보는 기본 노드에서 채워집니다. 작업 재시도를 지정하는 경우 메인 노드 장애로 인해 또 다른 시도가 발생합니다. 하위 노드 장애로 인해 추가 시도가 발생하지는 않습니다. 다중 노드 병렬 작업의 새로운 시도가 발생할 때마다 연결된 하위 노드의 해당 시도가 업데이트됩니다. 에서 다중 노드 병렬 작업을 실행하려면 AWS Batch애플리케이션 코드에 분산 통신에 필요한 프레임워크와 라이브러리가 포함되어야 합니다. **Topics** + [환경 변수](mnp-env-vars.md) + [노드 그룹](mnp-node-groups.md) + [MNP 작업의 작업 수명 주기](job-lifecycle.md) + [를 사용하여 MNP에 대한 컴퓨팅 환경 고려 사항 AWS Batch](mnp-ce.md) # 환경 변수 런타임 시 각 노드는 모든 AWS Batch 작업이 수신하는 표준 환경 변수로 구성됩니다. 또한 노드는 다중 노드 병렬 작업과 관련된 다음과 같은 환경 변수로 구성됩니다. `AWS_BATCH_JOB_MAIN_NODE_INDEX` 이 변수는 작업 기본 노드의 인덱스 번호로 설정됩니다. 애플리케이션 코드는 `AWS_BATCH_JOB_MAIN_NODE_INDEX`(을)를 개별 노드의 `AWS_BATCH_JOB_NODE_INDEX`(와)과 비교하여 이 노드가 기본 노드인지를 확인할 수 있습니다. `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` 이 변수는 다중 노드 병렬 작업 하위 노드에서만 설정됩니다. 이 변수는 메인 노드에는 없습니다. 이 변수는 작업 기본 노드의 프라이빗 IPv4 주소로 설정됩니다. 하위 노드의 애플리케이션 코드는 이 주소를 사용하여 기본 노드와 통신할 수 있습니다. `AWS_BATCH_JOB_NODE_INDEX` 이 변수는 노드의 노드 인덱스 번호로 설정됩니다. 노드 인덱스는 0에서 시작하며, 각 노드는 고유의 인덱스 번호를 받습니다. 예를 들면 하위가 10개 있는 다중 노드 병렬 작업의 인덱스 값은 0\$19입니다. `AWS_BATCH_JOB_NUM_NODES` 이 변수는 다중 노드 병렬 작업에 대해 요청한 노드 수로 설정됩니다. # 노드 그룹 노드 그룹은 모두 동일한 컨테이너 속성을 공유하는 작업 노드의 동일한 그룹입니다. AWS Batch 를 사용하여 각 작업에 대해 최대 5개의 개별 노드 그룹을 지정할 수 있습니다. 각 그룹에는 고유의 컨테이너 이미지, 명령, 환경 변수 등이 있을 수 있습니다. 예를 들어, 메인 노드용 단일 `c5.xlarge` 인스턴스와 다섯 개의 `c5.xlarge` 인스턴스 하위 노드가 필요한 작업을 제출할 수 있습니다. 이러한 개별 노드 그룹 각각은 각 작업에 대해 실행할 다른 컨테이너 이미지 또는 명령을 지정할 수 있습니다. 또는 작업의 모든 노드가 단일 노드 그룹을 사용할 수도 있습니다. 또한 애플리케이션 코드는 메인 노드 및 하위 노드와 같은 노드 역할을 구분할 수 있습니다. `AWS_BATCH_JOB_MAIN_NODE_INDEX` 환경 변수를 `AWS_BATCH_JOB_NODE_INDEX`에 대한 자체 값과 비교하여 이를 수행합니다. 단일 작업에 최대 1,000개의 노드가 있을 수 있습니다. 이는 Amazon ECS 클러스터 내 인스턴스에 대한 기본 제한입니다. [이 한도를 늘리도록 요청](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)할 수 있습니다. **참고** 현재 다중 노드 병렬 작업의 모든 노드 그룹은 동일한 인스턴스 유형을 사용해야 합니다. # MNP 작업의 작업 수명 주기 다중 노드 병렬 작업을 제출하면 작업이 `SUBMITTED` 상태가 됩니다. 그런 다음 작업은 모든 작업 종속성이 완료될 때까지 대기합니다. 또한 작업이 `RUNNABLE` 상태로 전환합니다. 마지막으로, 작업을 실행하는 데 필요한 인스턴스 용량을 AWS Batch 프로비저닝하고 이러한 인스턴스를 시작합니다. 각 다중 노드 병렬 작업에는 **기본 노드**가 포함되어 있습니다. 기본 노드는가 제출된 다중 노드 작업의 결과를 확인하기 위해 AWS Batch 모니터링하는 단일 하위 작업입니다. 기본 노드가 처음에 시작되고 `STARTING` 상태로 이동합니다. `attemptDurationSeconds` 파라미터에 지정된 제한 시간 값은 노드가 아닌 전체 작업에 적용됩니다. 기본 노드가 `RUNNING` 상태에 도달하면(노드의 컨테이너가 실행된 후) 하위 노드가 시작되고 하위 노드도 `STARTING` 상태로 이동합니다. 하위 노드는 임의의 순서로 나타납니다. 하위 노드가 시작되는 시간이나 순서는 보장할 수 없습니다. 작업의 모든 노드가 `RUNNING` 상태인지 확인하려면(노드 컨테이너가 실행된 후) 애플리케이션 코드가 AWS Batch API를 쿼리하여 기본 노드 및 하위 노드 정보를 가져올 수 있습니다. 또는 애플리케이션 코드가 모든 노드가 온라인 상태가 될 때까지 기다린 후 분산 처리 태스크를 시작할 수도 있습니다. 기본 노드의 프라이빗 IP 주소를 각 하위 노드에서 `AWS_BATCH_JOB_MAIN_NODE_PRIVATE_IPV4_ADDRESS` 환경 변수로 사용할 수 있습니다. 애플리케이션 코드는 이 정보를 사용하여 각 태스크 간에 데이터를 조정하고 통신할 수 있습니다. 개별 노드가 종료되면 종료 코드에 따라 `SUCCEEDED` 또는 `FAILED`(으)로 이동합니다. 기본 노드가 종료되면 작업이 완료된 것으로 간주되고 모든 하위 노드가 중지됩니다. 하위 노드가 죽으면 AWS Batch 는 작업의 다른 노드에 대해 어떤 작업도 수행하지 않습니다. 감소된 수의 노드로 작업을 계속하지 않으려는 경우 이러한 요인을 애플리케이션 코드에 반영해야 합니다. 이렇게 하면 작업이 종료되거나 취소됩니다. # 를 사용하여 MNP에 대한 컴퓨팅 환경 고려 사항 AWS Batch AWS Batch(을)를 사용하여 다중 노드 병렬 작업을 실행하도록 컴퓨팅 환경을 구성할 때 몇 가지 고려할 점이 있습니다. + 다중 노드 병렬 작업은 `UNMANAGED` 컴퓨팅 환경에서 지원되지 않습니다. + 다중 노드 병렬 작업을 컴퓨팅 환경에 제출하려는 경우 단일 가용 영역에서 *클러스터* 배치 그룹을 생성하고 이 그룹을 컴퓨팅 리소스와 연결합니다. 이렇게 하면 높은 네트워크 흐름 잠재력으로 가깝게 인접한 인스턴스를 논리적으로 그룹화할 때 다중 노드 병렬 작업이 그대로 유지됩니다. 자세한 내용을 알아보려면 *Amazon EC2 사용 설명서*의 [배치 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)을 참조하세요. + 스팟 인스턴스를 사용하는 컴퓨팅 환경에서는 다중 노드 병렬 작업이 지원되지 않습니다. + AWS Batch 다중 노드 병렬 작업은 다중 노드 병렬 작업 컨테이너에 Amazon EC2 인스턴스와 동일한 네트워킹 속성을 제공하는 Amazon ECS `awsvpc` 네트워크 모드를 사용합니다. 각 다중 노드 병렬 작업 컨테이너는 고유의 탄력적 네트워크 인터페이스, 기본 프라이빗 IP 주소, 내부 DNS 호스트 이름을 가져옵니다. 네트워크 인터페이스는 호스트 컴퓨팅 리소스와 동일한 VPC 서브넷에서 생성됩니다. + 컴퓨팅 환경에는 최대 5개의 보안 그룹을 연결할 수 있습니다. 생성되어 MNP 태스크에 연결되는 탄력적 네트워크 인터페이스는 컴퓨팅 환경에 지정된 보안 그룹을 사용합니다. 보안 그룹을 지정하지 않는 경우, VPC의 기본 보안 그룹이 사용됩니다. + `awsvpc` 네트워크 모드는 다중 노드 병렬 작업에 대한 탄력적 네트워크 인터페이스에 퍼블릭 IP 주소를 제공하지 않습니다. 인터넷에 액세스하려면 NAT 게이트웨이를 사용하도록 구성된 프라이빗 서브넷에서 컴퓨팅 리소스를 시작해야 합니다. 자세한 정보는 *Amazon VPC 사용 설명서*의 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 섹션을 참조하세요. 노드 간 통신은 노드의 프라이빗 IP 주소 또는 DNS 호스트 이름을 사용해야 합니다. 퍼블릭 서브넷 내의 컴퓨팅 리소스에서 실행하는 다중 노드 병렬 작업은 아웃바운드 네트워크 액세스를 수행할 수 없습니다. 프라이빗 서브넷과 NAT 게이트웨이를 사용하여 VPC를 생성하려면 [Virtual Private Cloud 생성](create-public-private-vpc.md) 섹션을 참조하세요. + 생성하여 컴퓨팅 리소스에 연결하는 탄력적 네트워크 인터페이스는 계정에서 수동으로 분리하거나 수정할 수 없습니다. 이러한 제한 사항은 실행 중인 작업과 연결된 탄력적 네트워크 인터페이스의 우발적인 삭제를 방지하기 위한 것입니다. 태스크에 대한 탄력적 네트워크 인터페이스를 해제하려면 작업을 종료합니다. + 컴퓨팅 환경에는 다중 노드 병렬 작업을 지원하기에 충분한 최대 vCPU가 있어야 합니다. + Amazon EC2 인스턴스 할당량에는 작업을 실행하는 데 필요한 인스턴스 수가 포함됩니다. 예를 들어, 작업에 30개의 인스턴스가 필요하지만 계정이 20개의 인스턴스만 실행할 수 있는 경우 작업은 지원합니다. 그러면 작업이 그대로 `RUNNABLE` 상태로 유지됩니다. + 다중 노드 병렬 작업의 노드 그룹에 인스턴스 유형을 지정하는 경우 컴퓨팅 환경에서 해당 인스턴스 유형을 시작할 수 있어야 합니다. # Amazon EKS의 다중 노드 병렬 작업 Amazon Elastic Kubernetes Service AWS Batch 에서를 사용하여 관리형 Kubernetes 클러스터에서 다중 노드 병렬(MNP) 작업(*그룹 스케줄링*이라고도 함)을 실행할 수 있습니다. 이 옵션은 일반적으로 단일 Amazon Elastic Compute Cloud 인스턴스에서 실행할 수 없는 긴밀하게 결합된 대규모 고성능 작업에 사용됩니다. 자세한 내용은 [다중 노드 병렬 작업](multi-node-parallel-jobs.md) 단원을 참조하십시오. 이 기능을 사용하여 Amazon EKS 관리형 Kubernetes 전용 고성능 컴퓨팅 애플리케이션, 대규모 언어 모델 훈련 및 기타 인공 지능(AI)/기계 학습(ML) 작업을 실행할 수 있습니다. **Topics** + [MNP 작업 실행](mnp-eks-running-mnp-jobs.md) + [Amazon EKS MNP 작업 정의 생성](mnp-eks-create-eks-mnp-job-definition.md) + [Amazon EKS MNP 작업 제출](mnp-eks-submit-eks-mnp-job.md) + [Amazon EKS MNP 작업 정의 재정의](mnp-eks-override-eks-mnp-job-definition.md) # MNP 작업 실행 AWS Batch 는 Amazon EC2를 사용하여 Amazon Elastic Container Service 및 Amazon EKS에서 MNP 작업을 지원합니다. 다음은 이 기능의 인스턴스 및 컨테이너 파라미터에 대한 자세한 내용입니다. ## Amazon EKS의 MNP에 대한 인스턴스 할당량 + 단일 MNP 작업에 최대 1,000개의 인스턴스를 사용할 수 있습니다. + 단일 Amazon EKS 클러스터에 최대 5,000개의 인스턴스를 조인할 수 있습니다. + 최대 5개의 컴퓨팅 환경을 클러스터링하여 작업 대기열에 연결할 수 있습니다. 예를 들어, 한 작업 대기열에서 클러스터링된 컴퓨팅 환경을 최대 5개까지 확장하고 각 컴퓨팅 환경에서 인스턴스를 1,000개까지 확장할 수 있습니다. 인스턴스 파라미터 외에도 두 서비스 모두 MNP 작업에 Fargate를 사용할 수 없다는 점에 유의해야 합니다. 각 MNP 작업에는 인스턴스 유형을 하나만 사용할 수 있습니다. 컴퓨팅 환경을 업데이트하거나 새 컴퓨팅 환경을 정의할 때 인스턴스 유형을 변경할 수 있습니다. 작업 정의를 생성할 때 인스턴스 유형을 지정하고 vCPU 및 메모리 요구 사항을 제공할 수도 있습니다. ## Amazon EKS의 MNP에 대한 컨테이너 할당량 + 다중 노드 병렬(MNP) 작업은 노드당 하나의 포드를 지원합니다. + 각 포드는 최대 10개의 컨테이너(또는 10개의 Init 컨테이너)를 지원합니다. 자세한 내용은 *Kubernetes 설명서*의 [Init 컨테이너](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)를 참조하세요. + 각 MNP 작업에서 최대 5개의 노드 범위를 지원합니다. + 각 노드 범위에서 최대 10개의 고유한 컨테이너 이미지를 지원합니다. 예를 들어, 5개의 노드 범위와 총 50개의 고유 이미지가 포함된 단일 MNP 작업에서 최대 10,000개의 컨테이너를 실행할 수 있습니다. ## 프라이빗 Amazon VPC 및 Amazon EKS 클러스터에서 MNP 작업 실행 MNP 작업은 퍼블릭 인터넷 지원 여부와 관계없이 모든 Amazon EKS 클러스터에서 실행할 수 있습니다. 프라이빗 네트워크 액세스만 있는 Amazon EKS 클러스터를 사용하는 경우가 Amazon EKS 컨트롤 플레인 및 관리형 Kubernetes API 서버에 액세스할 AWS Batch 수 있는지 확인합니다. Amazon Virtual Private Cloud 엔드포인트를 통해 필요한 액세스 권한을 부여할 수 있습니다. 자세한 내용은 [엔드포인트 서비스 구성](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html)을 참조하세요. 프라이빗 VPC는 인터넷에 액세스할 수 없으므로 Amazon EKS 클러스터 포드는 퍼블릭 소스에서 이미지를 다운로드할 수 없습니다. Amazon EKS 클러스터는 Amazon VPC 내에 있는 컨테이너 레지스트리에서 이미지를 가져와야 합니다. Amazon VPC에서 [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html)를 생성하고 노드에서 액세스할 수 있도록 여기에 컨테이너 이미지를 복사할 수 있습니다. Amazon ECR을 사용하여 풀스루 캐시 규칙을 생성할 수도 있습니다. 외부 퍼블릭 레지스트리에 대한 풀스루 캐시 규칙이 생성되면 Amazon ECR 프라이빗 레지스트리 URI를 사용하여 해당 외부 퍼블릭 레지스트리에서 이미지를 가져오면 됩니다. 그러면 Amazon ECR이 리포지토리를 생성하고 해당 이미지를 캐시합니다. Amazon ECR 프라이빗 레지스트리 URI를 사용하여 캐시된 이미지를 가져오면 Amazon ECR은 원격 레지스트리를 점검하여 이미지의 새 버전이 있는지 확인하며, 최대 24시간마다 한 번씩 프라이빗 레지스트리를 업데이트합니다. 자세한 내용은 [Amazon ECR에서 풀스루 캐시 규칙 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html)을 참조하세요. ## 오류 알림 MNP 작업이 차단된 경우 AWS Management Console 및 Amazon EventBridge를 통해 알림을 받을 수 있습니다. 예를 들어, MNP 작업이 대기열 상단에서 멈춘 경우 작업 대기열 차단을 해결하기 위한 즉각적인 조치를 취할 수 있도록 문제에 대한 알림과 함께 문제 원인에 대한 정보를 받을 수 있습니다. 선택적으로, 작업 대기열 템플릿에서 정의할 수 있는 별도의 시간 내에 조치가 취해지지 않으면 MNP 작업을 자동으로 종료할 수 있습니다. 자세한 내용은 [작업 대기열 차단 이벤트](batch-job-queue-blocked-events.md) 섹션을 참조하세요. # Amazon EKS MNP 작업 정의 생성 Amazon EKS에서 MNP 작업을 정의하고 실행할 수 있도록 [https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_RegisterJobDefinition.html) 및 [https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) API 작업 내에 새로운 파라미터가 있습니다. + [https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_NodeProperties.html) 섹션 아래에서 [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksProperties.html)를 사용하여 MNP 작업 정의를 정의합니다. + [https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html](https://docs.aws.amazon.com//batch/latest/APIReference/API_NodePropertyOverride.html) 섹션 아래에서 [https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksPropertiesOverride.html)를 사용하여 MNP 작업을 제출할 때 작업 정의에 정의된 파라미터를 재정의합니다. 이러한 작업은 API 작업 및 AWS Management Console을 통해 정의할 수 있습니다. ## 참조: Amazon EKS MNP 작업 정의 요청 페이로드 등록 다음 예제에서는 Amazon EKS MNP 작업 정의를 두 노드에 등록하는 방법을 보여줍니다. ``` { "jobDefinitionName": "MyEksMnpJobDefinition", "type": "multinode", "nodeProperties": { "numNodes": 2, "mainNode": 0, "nodeRangeProperties": [ { "targetNodes" : "0:", "eksProperties": { "podProperties": { "containers": [ { "name": "test-eks-container-1", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "command": [ "sleep", "60" ], "resources": { "limits": { "cpu": "1", "memory": "1024Mi" } }, "securityContext":{ "runAsUser":1000, "runAsGroup":3000, "privileged":true, "readOnlyRootFilesystem":true, "runAsNonRoot":true } } ], "initContainers": [ { "name":"init-ekscontainer", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "command": [ "echo", "helloWorld" ], "resources": { "limits": { "cpu": "1", "memory": "1024Mi" } } } ], "metadata": { "labels": { "environment" : "test" } } } } } ] } } ``` 를 사용하여 작업 정의를 등록하려면 정의를 *MyEksMnpJobDefinition.json*이라는 로컬 파일에 AWS CLI복사하고 다음 명령을 실행합니다. ``` aws batch register-job-definition --cli-input-json file://MyEksMnpJobDefinition.json ``` 다음과 같은 JSON 응답이 반환됩니다. ``` { "jobDefinitionName": "MyEksMnpJobDefinition", "jobDefinitionArn": "arn:aws:batch:us-east-1:0123456789:job-definition/MyEksMnpJobDefinition:1", "revision": 1 } ``` # Amazon EKS MNP 작업 제출 등록된 작업 정의를 사용하여 작업을 제출하려면 다음 명령을 입력합니다. 값을 Amazon EKS 컴퓨팅 환경과 연결된 기존 작업 대기열의 이름 또는 ARN으로 바꿉니다. ``` aws batch submit-job --job-queue \ --job-definition MyEksMnpJobDefinition \ --job-name myFirstEksMnpJob ``` 다음과 같은 JSON 응답이 반환됩니다. ``` { "jobArn": "arn:aws:batch:region:account:job/9b979cce-9da0-446d-90e2-ffa16d52af68", "jobName": "myFirstEksMnpJob", "jobId": "" } ``` 반환된 jobId와 다음 명령을 사용하여 작업 상태를 확인할 수 있습니다. ``` aws batch describe-jobs --jobs ``` # Amazon EKS MNP 작업 정의 재정의 선택적으로, MNP 작업 크기나 하위 작업 세부 정보를 변경하는 것처럼 작업 정의 세부 정보를 재정의할 수 있습니다. 다음은 5개 노드 MNP 작업과 `test-eks-container-1` 컨테이너의 명령 변경 사항을 제출하기 위한 예제 JSON 요청 페이로드입니다. ``` { "numNodes": 5, "nodePropertyOverrides": [ { "targetNodes": "0:", "eksPropertiesOverride": { "podProperties": { "containers": [ { "name": "test-eks-container-1", "command": [ "sleep", "150" ] } ] } } } ] } ``` 이러한 재정의가 있는 작업을 제출하려면 예제를 로컬 파일인 *eks-mnp-job-nodeoverride.json* AWS CLI 에 저장하고를 사용하여 재정의가 있는 작업을 제출합니다. # 배열 작업 배열 작업은 작업 정의, vCPU 및 메모리와 같은 공통 파라미터를 공유하는 작업입니다. 여러 호스트에 걸쳐 배포될 수 있으며 동시에 실행할 수 있는 관련 개별 기본 작업의 모음으로 실행됩니다. 배열 작업은 Monte Carlo 시뮬레이션, 파라미터 스윕 또는 대규모 렌더링 작업과 같이 고도의 병렬 작업을 처리하는 가장 효율적인 방법입니다. AWS Batch 배열 작업은 일반 작업과 마찬가지로 제출됩니다. 하지만 배열 크기(2\$110,000)를 지정하여 얼마나 많은 하위 작업이 배열에서 실행되어야 하는지를 정의합니다. 배열 크기가 1,000인 작업을 제출하는 경우 단일 작업은 1,000개의 하위 작업을 실행 및 생성합니다. 배열 작업은 모든 하위 작업을 관리하는 참조 또는 포인터입니다. 이를 통해 단일 쿼리를 포함한 대규모 워크로드를 제출할 수 있습니다. `attemptDurationSeconds` 파라미터에 지정된 제한 시간은 각 하위 작업에 적용됩니다. 상위 배열 작업에는 제한 시간이 없습니다. 배열 작업을 제출하면 상위 배열 작업은 일반 AWS Batch 작업 ID를 가져옵니다. 각 하위 작업의 기본 ID는 동일합니다. 각 하위 작업은 동일한 기본 ID를 갖지만 하위 작업에 대한 배열 인덱스는 상위 ID의 끝에 추가됩니다(예: 배열의 첫 번째 하위 작업의 경우 `example_job_ID:0`). 상위 배역 작업은 `SUBMITTED`, `PENDING`, `FAILED` 또는 `SUCCEEDED` 상태를 입력할 수 있습니다. 하위 작업이 `RUNNABLE`(으)로 업데이트되면 상위 배열 작업이 `PENDING`(으)로 업데이트됩니다. 이러한 종속성에 대한 자세한 내용은 [작업 종속성](job_dependencies.md) 섹션을 참조하세요. 실행 시간 시 `AWS_BATCH_JOB_ARRAY_INDEX` 환경 변수가 컨테이너의 해당 배열 인덱스 번호에 설정됩니다. 첫 번째 배열 작업 인덱스에는 `0`(이)가 지정되고 이후 시도는 1, 2, 3 등과 같이 오름차순으로 횟수가 지정됩니다. 이 인덱스 값을 사용하여 차별화된 배열 작업 하위에 따라 관리할 수 있습니다. 자세한 내용은 [배열 작업 인덱스를 사용한 작업 차별화 관리](array_index_example.md) 단원을 참조하십시오. 배열 작업 종속성의 경우 `SEQUENTIAL` 또는 `N_TO_N`(와)과 같이 종속성의 유형을 지정할 수 있습니다. 작업 ID를 입력하지 않고 `SEQUENTIAL` 유형 종속성을 지정할 수 있습니다. 그러면 각 하위 배열 작업은 인덱스 0부터 순차적으로 완료됩니다. 예를 들어 배열 크기가 100인 배열 작업을 제출하고, 종속성 유형을 `SEQUENTIAL`(으)로 지정한 경우 100개의 하위 작업이 순차적으로 생성됩니다. 그리고 첫 번째 하위 작업이 성공해야 다음 하위 작업이 시작됩니다. 아래 그림은 배열 크기가 10인 배열 작업, Job A를 보여줍니다. Job A의 하위 인덱스에 있는 각 작업은 이전 하위 작업에 종속적입니다. Job A:0이 완료된 이후에 Job A:1이 시작할 수 있습니다. ![\[Flowchart showing Job-A with sequential child jobs A:0 through A:9, connected by arrows.\]](http://docs.aws.amazon.com/ko_kr/batch/latest/userguide/images/sequential-dep.png) 배열 작업의 작업 ID로 `N_TO_N` 유형의 종속성을 지정할 수도 있습니다. 이 방법을 사용하면 이 작업의 각 인덱스 하위는 각 종속성의 해당 인덱스 하위가 완료될 때까지 기다린 후에만 시작할 수 있습니다. 아래 그림은 배열 크기가 각각 10,000인 2개의 배열 작업, Job A와 Job B를 보여줍니다. Job B의 하위 인덱스에 있는 각 작업은 Job A의 해당 인덱스에 종속적입니다. Job B:1은 Job A:1이 완료될 때까지 시작할 수 없습니다. ![\[Two array jobs, Job-A and Job-B, with 10,000 indexed tasks each, showing N_TO_N dependency.\]](http://docs.aws.amazon.com/ko_kr/batch/latest/userguide/images/n-to-n-dep.png) 상위 배열 작업을 취소 또는 종료한 경우 모든 하위 작업이 함께 취소 또는 종료됩니다. 다른 하위 작업에 영향을 미치지 않고 개별 하위 작업을 취소 또는 종료할 수 있습니다(`FAILED` 상태로 변경됨). 하지만 하위 배열 작업이 실패(자체적으로 실패하거나 수동으로 작업을 취소 또는 종료하여 실패)한 경우 상위 작업 또한 실패합니다. 이 시나리오에서는 모든 하위 작업이 완료될 때 상위 작업이 `FAILED`로 전환됩니다. 배열 작업 검색 및 필터링에 대한 자세한 내용은 섹션을 참조하세요[작업 대기열에서 작업 검색](searching-filtering-jobs.md). **Topics** + [배열 작업 워크플로의 예](example_array_job.md) + [배열 작업 인덱스를 사용한 작업 차별화 관리](array_index_example.md) # 배열 작업 워크플로의 예 AWS Batch 고객의 일반적인 워크플로는 사전 조건 설정 작업을 실행하고 많은 수의 입력 작업에 대해 일련의 명령을 실행한 다음 결과를 집계하고 요약 데이터를 Amazon S3, DynamoDB, Amazon Redshift 또는 Aurora에 쓰는 작업으로 끝나는 것입니다. 예제: + `JobA`: Amazon S3 버킷인 `BucketA`에 있는 객체의 빠른 나열과 메타데이터 검증을 수행하는 표준 비 배열 작업입니다. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) JSON 구문은 다음과 같습니다. ``` { "jobName": "JobA", "jobQueue": "ProdQueue", "jobDefinition": "JobA-list-and-validate:1" } ``` + `JobB`: `JobA`에 종속적인 10,000개의 작업 부수가 포함된 배열 작업. `BucketA`의 각 객체에 대한 CPU 집약적 명령을 실행하고 `BucketB`에 결과를 업로드합니다. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) JSON 구문은 다음과 같습니다. ``` { "jobName": "JobB", "jobQueue": "ProdQueue", "jobDefinition": "JobB-CPU-Intensive-Processing:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "4096" }, { "type": "VCPU", "value": "32" } ] } "arrayProperties": { "size": 10000 }, "dependsOn": [ { "jobId": "JobA_job_ID" } ] } ``` + `JobC`: `N_TO_N` 종속성 모델을 사용하여 `JobB`에 종속되는 또 다른 10,000 부 배열 작업입니다. 이 작업은 `BucketB`의 각 항목에 대한 메모리 집약적 명령을 실행하고, 메타데이터를 DynamoDB에 쓴 다음, 결과 출력을 `BucketC`에 업로드합니다. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) JSON 구문은 다음과 같습니다. ``` { "jobName": "JobC", "jobQueue": "ProdQueue", "jobDefinition": "JobC-Memory-Intensive-Processing:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "32768" }, { "type": "VCPU", "value": "1" } ] } "arrayProperties": { "size": 10000 }, "dependsOn": [ { "jobId": "JobB_job_ID", "type": "N_TO_N" } ] } ``` + `JobD`: 10개의 검증 단계를 수행하는 배열 작업입니다. 각 단계는 DynamoDB에 쿼리해야 하고, 위의 Amazon S3 버킷 중 어떠한 버킷과도 상호 작용할 수 있습니다. `JobD`의 각 단계는 동일한 명령을 실행합니다. 그러나 동작은 작업의 컨테이너 내 `AWS_BATCH_JOB_ARRAY_INDEX` 환경 변수의 값에 따라 다릅니다. 이러한 검증 단계는 순차적으로 작동합니다(예: `JobD:0` 이후 `JobD:1`). [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) JSON 구문은 다음과 같습니다. ``` { "jobName": "JobD", "jobQueue": "ProdQueue", "jobDefinition": "JobD-Sequential-Validation:1", "containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "32768" }, { "type": "VCPU", "value": "1" } ] } "arrayProperties": { "size": 10 }, "dependsOn": [ { "jobId": "JobC_job_ID" }, { "type": "SEQUENTIAL" }, ] } ``` + `JobE`: 몇 가지 단순한 정리 작업을 수행하고 파이프라인이 완료되었다는 메시지와 출력 URL 링크가 포함된 Amazon SNS 알림을 전송하는 최종 비 배열 작업입니다. [SubmitJob](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html) JSON 구문은 다음과 같습니다. ``` { "jobName": "JobE", "jobQueue": "ProdQueue", "jobDefinition": "JobE-Cleanup-and-Notification:1", "parameters": { "SourceBucket": "s3://amzn-s3-demo-source-bucket", "Recipient": "pipeline-notifications@mycompany.com" }, "dependsOn": [ { "jobId": "JobD_job_ID" } ] } ``` # 배열 작업 인덱스를 사용한 작업 차별화 관리 이 자습서에서는 `AWS_BATCH_JOB_ARRAY_INDEX` 환경 변수를 사용하여 하위 작업을 구분하는 방법을 설명합니다. 각 하위 작업이 이 변수에 할당됩니다. 이 예제에서는 하위 작업의 인덱스 번호를 사용하여 파일의 특정 줄을 읽습니다. 그런 다음 해당 줄 번호와 관련된 파라미터를 작업 컨테이너 내의 명령으로 대체합니다. 결과적으로 동일한 Docker 이미지 및 명령 인수를 실행하는 여러 AWS Batch 작업을 가질 수 있습니다. 하지만 배열 작업 인덱스가 한정자로 사용되므로 결과가 달라집니다. 이 자습서에서는 각 줄에 무지개색 텍스트 파일을 만듭니다. 그런 다음 Docker 컨테이너용 진입점 스크립트를 만들어 색상 파일의 줄 번호에 사용 가능한 값(인덱스는 0부터 시작하지만 줄 번호는 1부터 시작)으로 인덱스를 변환합니다. 인덱스는 0에서 시작하지만 줄 번호는 1부터 시작합니다. 색상과 인덱스 파일을 컨테이너 이미지에 복사하고 이미지의 `ENTRYPOINT`(을)를 진입점 스크립트에 지정하는 Dockerfile을 만듭니다. Dockerfile 및 리소스를 도커 이미지에 만들어 Amazon ECR로 푸시합니다. 그런 다음 새 컨테이너 이미지를 사용하는 작업 정의를 등록하고, 해당 작업 정의와 함께 AWS Batch 배열 작업을 제출하고, 결과를 봅니다. **Topics** + [사전 조건](array-tutorial-prereqs.md) + [컨테이너 이미지 빌드](build-index-container.md) + [이미지를 Amazon ECR로 푸시](push-array-image.md) + [작업 정의 생성 및 등록](create-array-job-def.md) + [AWS Batch 배열 작업 제출](submit-array-job.md) + [배열 작업 로그 보기](#array-tutorial-logs) # 사전 조건 이 자습서 워크플로의 사전 요구 사항은 다음과 같습니다. + AWS Batch 컴퓨팅 환경. 자세한 내용은 [컴퓨팅 환경 생성](create-compute-environment.md) 단원을 참조하십시오. + AWS Batch 작업 대기열 및 관련 컴퓨팅 환경. 자세한 내용은 [작업 대기열 생성](create-job-queue.md) 단원을 참조하십시오. + 로컬 시스템에 AWS CLI 설치된 . 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS Command Line Interface설치](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)를 참조하세요. + 로컬 시스템에 설치한 도커입니다. 자세한 내용은 Docker 설명서의 [Docker CE 소개](https://docs.docker.com/install/)를 참조하세요. # 컨테이너 이미지 빌드 명령 파라미터의 작업 정의에 `AWS_BATCH_JOB_ARRAY_INDEX`를 사용할 수 있습니다. 하지만 진입점 스크립트에서 변수를 사용하는 컨테이너 이미지를 대신 생성하는 것이 좋습니다. 이 섹션에서는 이러한 컨테이너 이미지를 만드는 방법을 설명합니다. **Docker 컨테이너 이미지를 빌드하려면** 1. 도커 이미지 작업 영역으로 사용할 새 디렉터리를 만들고 여기로 이동합니다. 1. 작업 영역 디렉터리에 이름이 `colors.txt`인 파일을 만들고 그 아래에 내용을 붙여 넣습니다. ``` red orange yellow green blue indigo violet ``` 1. 작업 영역 디렉터리에 이름이 `print-color.sh`인 파일을 만들고 그 아래에 내용을 붙여 넣습니다. **참고** 배열 인덱스는 0에서 시작하지만 줄 번호는 1에서 시작하므로 `LINE` 변수가 `AWS_BATCH_JOB_ARRAY_INDEX`\$11로 지정됩니다. `COLOR` 변수가 줄 번호와 연결된 `colors.txt`의 색으로 지정됩니다. ``` #!/bin/sh LINE=$((AWS_BATCH_JOB_ARRAY_INDEX + 1)) COLOR=$(sed -n ${LINE}p /tmp/colors.txt) echo My favorite color of the rainbow is $COLOR. ``` 1. 작업 영역 디렉터리에 이름이 `Dockerfile`인 파일을 만들고 다음 콘텐츠를 붙여 넣습니다. 이 Dockerfile이 이전 파일을 컨테이너에 복사하고 컨테이너가 시작하면 진입점 스크립트를 실행하도록 지정합니다. ``` FROM busybox COPY print-color.sh /tmp/print-color.sh COPY colors.txt /tmp/colors.txt RUN chmod +x /tmp/print-color.sh ENTRYPOINT /tmp/print-color.sh ``` 1. 도커 이미지를 빌드합니다. ``` $ docker build -t print-color . ``` 1. 다음 스크립트로 컨테이너를 테스트합니다. 이 스크립트는 로컬에서 `AWS_BATCH_JOB_ARRAY_INDEX` 변수를 0으로 지정한 다음 증분하여 하위가 7개인 배열 작업을 시뮬레이션합니다. ``` $ AWS_BATCH_JOB_ARRAY_INDEX=0 while [ $AWS_BATCH_JOB_ARRAY_INDEX -le 6 ] do docker run -e AWS_BATCH_JOB_ARRAY_INDEX=$AWS_BATCH_JOB_ARRAY_INDEX print-color AWS_BATCH_JOB_ARRAY_INDEX=$((AWS_BATCH_JOB_ARRAY_INDEX + 1)) done ``` 출력 값은 다음과 같습니다. ``` My favorite color of the rainbow is red. My favorite color of the rainbow is orange. My favorite color of the rainbow is yellow. My favorite color of the rainbow is green. My favorite color of the rainbow is blue. My favorite color of the rainbow is indigo. My favorite color of the rainbow is violet. ``` # 이미지를 Amazon ECR로 푸시 이제 Docker 컨테이너를 구축하고 테스트했으므로 이미지 리포지토리에 푸시해야 합니다. 이 예제는 Amazon ECR을 사용하지만, DockerHub 같은 다른 레지스트리를 선택해도 됩니다. 1. 컨테이너 이미지를 저장할 Amazon ECR 이미지 리포지토리를 생성합니다. 이 예제에서는 만 사용하지만 AWS CLI도 사용할 수 있습니다 AWS Management Console. 자세한 내용은* Amazon Elastic Container Registry 사용 설명서*의 [리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)을 참조하세요. ``` $ aws ecr create-repository --repository-name print-color ``` 1. 이전 단계에서 반환된 Amazon ECR 리포지토리 URI로 `print-color` 이미지에 태그를 지정합니다. ``` $ docker tag print-color aws_account_id.dkr.ecr.region.amazonaws.com/print-color ``` 1. Amazon ECR 레지스트리에 로그인합니다. 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*의 [레지스트리 권한](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html#registry_auth)을 참조하세요. ``` $ aws ecr get-login-password \ --region region | docker login \ --username AWS \ --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com ``` 1. 이미지를 Amazon ECR로 푸시합니다. ``` $ docker push aws_account_id.dkr.ecr.region.amazonaws.com/print-color ``` # 작업 정의 생성 및 등록 이제 Docker 이미지가 이미지 레지스트리에 있으므로 AWS Batch 작업 정의에서 지정할 수 있습니다. 그런 다음 나중에 이를 사용하여 배열 작업을 실행할 수 있습니다. 이 예제에서는 AWS CLI(을)를 사용합니다. 하지만 AWS Management Console(을)를 사용할 수도 있습니다. 자세한 내용은 [단일 노드 작업 정의 생성](create-job-definition.md) 단원을 참조하십시오. **작업 정의를 생성하려면** 1. 작업 영역 디렉터리에 이름이 `print-color-job-def.json`인 파일을 만들고 그 아래에 내용을 붙여 넣습니다. 이미지 리포지토리 URI를 고유의 이미지 URI로 바꿉니다. ``` { "jobDefinitionName": "print-color", "type": "container", "containerProperties": { "image": "aws_account_id.dkr.ecr.region.amazonaws.com/print-color", "resourceRequirements": [ { "type": "MEMORY", "value": "250" }, { "type": "VCPU", "value": "1" } ] } } ``` 1. 작업 정의를에 등록합니다 AWS Batch. ``` $ aws batch register-job-definition --cli-input-json file://print-color-job-def.json ``` # AWS Batch 배열 작업 제출 작업 정의를 등록한 후 새 컨테이너 이미지를 사용하는 AWS Batch 배열 작업을 제출할 수 있습니다. **AWS Batch 배열 작업을 제출하려면** 1. 작업 영역 디렉터리에 이름이 `print-color-job.json`인 파일을 만들고 그 아래에 내용을 붙여 넣습니다. **참고** 이 예에서는 [사전 조건](array-tutorial-prereqs.md) 섹션에 언급된 작업 대기열을 사용합니다. ``` { "jobName": "print-color", "jobQueue": "existing-job-queue", "arrayProperties": { "size": 7 }, "jobDefinition": "print-color" } ``` 1. 작업을 AWS Batch 작업 대기열에 제출합니다. 출력에서 반환된 작업 ID를 기록합니다. ``` $ aws batch submit-job --cli-input-json file://print-color-job.json ``` 1. 작업의 상태를 설명하고 이 작업이 `SUCCEEDED`(으)로 이동하기를 기다립니다. ## 배열 작업 로그 보기 작업이 `SUCCEEDED` 상태에 도달한 후 작업의 컨테이너에서 CloudWatch Logs를 볼 수 있습니다. **CloudWatch Logs에서 작업 로그를 보려면** 1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) AWS Batch 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **작업**을 선택합니다. 1. **Job queue(작업 대기열)**에서 대기열을 선택합니다. 1. **상태** 섹션에서 **성공**을 선택합니다. 1. 배열 작업의 하위 작업을 모두 표시하려면 이전 섹션에서 반환된 작업 ID를 선택합니다. 1. 작업의 컨테이너에서 로그를 보려면 하위 작업 중 하나 선택하고 **로그 보기**를 선택합니다. ![\[배열 작업 컨테이너 로그\]](http://docs.aws.amazon.com/ko_kr/batch/latest/userguide/images/array-logs.png) 1. 다른 하위 작업의 로그를 봅니다. 각 작업은 다른 무지개색을 반환합니다 . # GPU 작업 실행 GPU 작업을 통해 인스턴스의 GPU를 사용하는 작업을 실행할 수 있습니다. 다음과 같은 Amazon EC2 GPU 기반 인스턴스 유형이 지원됩니다. 자세한 내용은 [Amazon EC2 G3 인스턴스](https://aws.amazon.com/ec2/instance-types/g3/), [Amazon EC2 G4 인스턴스](https://aws.amazon.com/ec2/instance-types/g4/), [Amazon EC2 G5 인스턴스](https://aws.amazon.com/ec2/instance-types/g5/),[Amazon EC2 G6 인스턴스](https://aws.amazon.com/ec2/instance-types/g6/) , [Amazon EC2 P2 인스턴스](https://aws.amazon.com/ec2/instance-types/p2/), [Amazon EC2 P3 인스턴스](https://aws.amazon.com/ec2/instance-types/p3/), [Amazon EC2 P4d 인스턴스](https://aws.amazon.com/ec2/instance-types/p4/), [Amazon EC2 P5 인스턴스](https://aws.amazon.com/ec2/instance-types/p5/), [Amazon EC2 P6 인스턴스](https://aws.amazon.com/ec2/instance-types/p6/), [Amazon EC2 Trn1 인스턴스](https://aws.amazon.com/ec2/instance-types/trn1/), [Amazon EC2 Trn2 인스턴스](https://aws.amazon.com/ec2/instance-types/trn2/), [Amazon EC2 Inf1 인스턴스](https://aws.amazon.com/ec2/instance-types/inf1/), [Amazon EC2 Inf2 인스턴스](https://aws.amazon.com/ec2/instance-types/inf2/), [Amazon EC2 Dl1 인스턴스](https://aws.amazon.com/ec2/instance-types/dl1/) 및 [Amazon EC2 Dl2 인스턴스](https://aws.amazon.com/ec2/instance-types/dl2q/)를 참조하세요. | 인스턴스 유형 | GPU | GPU 메모리 | vCPU | Memory | 네트워크 대역폭 | | --- | --- | --- | --- | --- | --- | | g3s.xlarge | 1 | 8GiB | 4 | 30.5GiB | 10Gbps | | g3.4xlarge | 1 | 8GiB | 16 | 122GiB | 최대 10Gbps | | g3.8xlarge | 2 | 16GiB | 32 | 244GiB | 10Gbps | | g3.16xlarge | 4 | 32GiB | 64 | 488GiB | 25Gbps | | g4dn.xlarge | 1 | 16GiB | 4 | 16GiB | 최대 25Gbps | | g4dn.2xlarge | 1 | 16GiB | 8 | 32GiB | 최대 25Gbps | | g4dn.4xlarge | 1 | 16GiB | 16 | 64GiB | 최대 25Gbps | | g4dn.8xlarge | 1 | 16GiB | 32 | 128GiB | 50Gbps | | g4dn.12xlarge | 4 | 64GiB | 48 | 192GiB | 50Gbps | | g4dn.16xlarge | 1 | 16GiB | 64 | 256GiB | 50Gbps | | g5.xlarge | 1 | 24GiB | 4 | 16GiB | 최대 10Gbps | | g5.2xlarge | 1 | 24GiB | 8 | 32GiB | 최대 10Gbps | | g5.4xlarge | 1 | 24GiB | 16 | 64GiB | 최대 25Gbps | | g5.8xlarge | 1 | 24GiB | 32 | 128GiB | 25Gbps | | g5.16xlarge | 1 | 24GiB | 64 | 256GiB | 25Gbps | | g5.12xlarge | 4 | 96GiB | 48 | 192GiB | 40Gbps | | g5.24xlarge | 4 | 96GiB | 96 | 384GiB | 50Gbps | | g5.48xlarge | 8 | 192GiB | 192 | 768GiB | 100Gbps | | g5g.xlarge | 1 | 16GiB | 4 | 8GiB | 최대 10Gbps | | g5g.2xlarge | 1 | 16GiB | 8 | 16GiB | 최대 10Gbps | | g5g.4xlarge | 1 | 16GiB | 16 | 32GiB | 최대 10Gbps | | g5g.8xlarge | 1 | 16GiB | 32 | 64GiB | 12Gbps | | g5g.16xlarge | 2 | 32GiB | 64 | 128GiB | 25Gbps | | g5g.metal | 2 | 32GiB | 64 | 128GiB | 25Gbps | | g6.xlarge | 1 | 24GiB | 4 | 16GiB | 최대 10Gbps | | g6.2xlarge | 1 | 24GiB | 8 | 32GiB | 최대 10Gbps | | g6.4xlarge | 1 | 24GiB | 16 | 64GiB | 최대 25Gbps | | g6.8xlarge | 1 | 24GiB | 32 | 128GiB | 25Gbps | | g6.16xlarge | 1 | 24GiB | 64 | 256GiB | 25Gbps | | g6.12xlarge | 4 | 96GiB | 48 | 192GiB | 40Gbps | | g6.24xlarge | 4 | 96GiB | 96 | 384GiB | 50Gbps | | g6.48xlarge | 8 | 192GiB | 192 | 768GiB | 100Gbps | | g6e.xlarge | 1 | 48GiB | 4 | 32GiB | 최대 20Gbps | | g6e.2xlarge | 1 | 48GiB | 8 | 64GiB | 최대 20Gbps | | g6e.4xlarge | 1 | 48GiB | 16 | 128GiB | 20Gbps | | g6e.8xlarge | 1 | 48GiB | 32 | 256GiB | 25Gbps | | g6e.16xlarge | 1 | 48GiB | 64 | 512GiB | 35Gbps | | g6e.12xlarge | 4 | 192GiB | 48 | 384 GiB | 100Gbps | | g6e.24xlarge | 4 | 192GiB | 96 | 768GiB | 200Gbps | | g6e.48xlarge | 8 | 384 GiB | 192 | 1536GiB | 400Gbps | | gr6.4xlarge | 1 | 24GiB | 16 | 128GiB | 최대 25Gbps | | gr6.8xlarge | 1 | 24GiB | 32 | 256GiB | 25Gbps | | p2.xlarge | 1 | 12GiB | 4 | 61GiB | 높음 | | p2.8xlarge | 8 | 96GiB | 32 | 488GiB | 10Gbps | | p2.16xlarge | 16 | 192GiB | 64 | 732GiB | 20Gbps | | p3.2xlarge | 1 | 16GiB | 8 | 61GiB | 최대 10Gbps | | p3.8xlarge | 4 | 64GiB | 32 | 244GiB | 10Gbps | | p3.16xlarge | 8 | 128GiB | 64 | 488GiB | 25Gbps | | p3dn.24xlarge | 8 | 256GiB | 96 | 768GiB | 100Gbps | | p4d.24xlarge | 8 | 320GiB | 96 | 1152GiB | 400Gbps | | p4de.24xlarge | 8 | 640GiB | 96 | 1152GiB | 400Gbps | | p5.48xlarge | 8 | 640GiB | 192 | 2TiB | 3200Gbps | | p5e.48xlarge | 8 | 1128GiB | 192 | 2TiB | 3200Gbps | | p5en.48xlarge | 8 | 1128GiB | 192 | 2TiB | 3200Gbps | | p6-b200.48xlarge | 8 | 1440GiB | 192 | 2TiB | 100Gbps | | trn1.2xlarge | 1 | 32GiB | 8 | 32GiB | 최대 1.25Gbps | | trn1.32xlarge | 16 | 512GiB | 128 | 512GiB | 800Gbps | | trn1n.32xlarge | 16 | 512GiB | 128 | 512GiB | 1600Gbps | | trn2.48xlarge | 16 | 1.5TiB | 192 | 2TiB | 3.2Tbps | | inf1.xlarge | 1 | 8GiB | 4 | 8GiB | 최대 25Gbps | | inf1.2xlarge | 1 | 8GiB | 8 | 16GiB | 최대 25Gbps | | inf1.6xlarge | 4 | 32GiB | 24 | 48GiB | 25Gbps | | inf1.24xlarge | 16 | 128GiB | 96 | 192GiB | 100Gbps | | inf2.xlarge | 1 | 32GiB | 4 | 16GiB | 최대 15Gbps | | inf2.8xlarge | 1 | 32GiB | 32 | 128GiB | 최대 25Gbps | | inf2.24xlarge | 6 | 192GiB | 96 | 384GiB | 50Gbps | | inf2.48xlarge | 12 | 384 GiB | 192 | 768GiB | 100Gbps | | dl1.24xlarge | 8 | 256GiB | 96 | 768GiB | 400Gbps | | dl2q.24xlarge | 8 | 128GiB | 96 | 768GiB | 100Gbps | **참고** GPU 작업의 경우 NVIDIA GPUs가 있는 인스턴스 유형 AWS Batch 만 지원합니다. 예를 들어 [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances) 패밀리는 GPU 예약에 지원되지 않습니다. 작업 정의에서 vcpu 및 메모리 요구 사항만 정의 AWS Batch 한 다음 Amazon ECS 또는 Amazon EKS 컴퓨팅 최적화 AMI 또는 AMD GPUs 사용을 위한 사용자 지정 AMI를 사용하여 Amazon EC2 [시작 템플릿 사용자 데이터의](launch-templates.md#lt-user-data.title) 사용자 지정을 통해 호스트 GPU에 직접 액세스하여 [https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances](https://aws.amazon.com/ec2/instance-types/g4/#Amazon_EC2_G4ad_instances)에서를 계속 사용할 수 있습니다. Amazon EC2 GPUs ARM64 아키텍처를 사용하는 인스턴스 유형은 AWS Batch 또는 Amazon EC2 사용자 데이터에 제공된 사용자 지정 AMIs의 GPU 작업에서 사용자 지정 코드 및 구성을 통해 GPUs에 액세스할 수 있도록 지원됩니다. [https://aws.amazon.com/ec2/instance-types/g5g/](https://aws.amazon.com/ec2/instance-types/g5g/) 인스턴스 패밀리를 그 예로 들 수 있습니다. 작업 정의에 대한 [resourceRequirements](job_definition_parameters.md#ContainerProperties-resourceRequirements) 파라미터는 컨테이너에 고정되며 해당 작업 기간 동안 해당 인스턴스에서 실행 중인 다른 작업에서는 사용할 수 없는 GPU 수를 지정합니다. 이 수의 GPU는 해당 작업이 진행되는 동안 해당 인스턴스에서 실행되는 다른 작업에서는 사용할 수 없습니다. GPU 작업을 실행하는 컴퓨팅 환경의 모든 인스턴스 유형은 `p3`, `p4`, `p5`, `p6`, `g3`, `g3s`, `g4`, `g5` 또는 `g6` 인스턴스 패밀리의 인스턴스 유형이어야 합니다. 그렇지 않으면 GPU 작업이 `RUNNABLE` 상태로 고착될 수 있습니다. GPU를 사용하지 않는 작업은 GPU 인스턴스에서 실행할 수 있습니다. 하지만 유사한 비 GPU 인스턴스보다 GPU 인스턴스에서 실행하는 경우 비용이 더 많이 들 수 있습니다. 특정 vCPU, 메모리 및 필요한 시간에 따라 이러한 비 GPU 작업은 GPU 작업의 실행을 차단할 수 있습니다. **Topics** + [Amazon EKS에서 GPU 기반 Kubernetes 클러스터 생성](create-gpu-cluster-eks.md) + [Amazon EKS GPU 작업 정의 생성](create-eks-gpu-job-definition.md) + [Amazon EKS 클러스터에서 GPU 작업 실행](run-gpu-job-eks-cluster.md) # Amazon EKS에서 GPU 기반 Kubernetes 클러스터 생성 Amazon EKS에서 GPU 기반 Kubernetes 클러스터를 생성하려면 먼저 [Amazon EKS AWS Batch 에서 시작하기](getting-started-eks.md)의 단계를 완료해야 합니다. 추가적으로 다음 사항도 고려하세요. + AWS Batch 는 NVIDIA GPUs에서 인스턴스 유형을 지원합니다. + 기본적으로는 Amazon EKS 클러스터 컨트롤 플레인 Kubernetes 버전과 일치하는 버전으로 Amazon EKS 가속 AMI를 AWS Batch 선택합니다. ``` $ cat < ./batch-eks-gpu-ce.json { "computeEnvironmentName": "My-Eks-GPU-CE1", "type": "MANAGED", "state": "ENABLED", "eksConfiguration": { "eksClusterArn": "arn:aws:eks:::cluster/", "kubernetesNamespace": "my-aws-batch-namespace" }, "computeResources": { "type": "EC2", "allocationStrategy": "BEST_FIT_PROGRESSIVE", "minvCpus": 0, "maxvCpus": 1024, "instanceTypes": [ "p3dn.24xlarge", "p4d.24xlarge" ], "subnets": [ "" ], "securityGroupIds": [ "" ], "instanceRole": "" } } EOF $ aws batch create-compute-environment --cli-input-json file://./batch-eks-gpu-ce.json ``` AWS Batch 는 사용자를 대신하여 NVIDIA GPU 디바이스 플러그인을 관리하지 않습니다. 이 플러그인을 Amazon EKS 클러스터에 설치하고 AWS Batch 노드를 대상으로 지정할 수 있도록 허용해야 합니다. 자세한 내용은 GitHub의 [Kubernetes에서 GPU 지원 활성화](https://github.com/NVIDIA/k8s-device-plugin#enabling-gpu-support-in-kubernetes)를 참조하세요. AWS Batch 노드를 대상으로 하도록 NVIDIA 디바이스 플러그인(`DaemonSet`)을 구성하려면 다음 명령을 실행합니다. ``` # pull nvidia daemonset spec $ curl -O https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.12.2/nvidia-device-plugin.yml # using your favorite editor, add Batch node toleration # this will allow the DaemonSet to run on Batch nodes - key: "batch.amazonaws.com/batch-node" operator: "Exists" $ kubectl apply -f nvidia-device-plugin.yml ``` 동일한 컴퓨팅 환경과 작업 대기열의 쌍에서 컴퓨팅 기반(CPU 및 메모리) 워크로드와 GPU 기반 워크로드를 함께 사용하지 않는 것이 좋습니다. 컴퓨팅 작업이 GPU 용량을 소모할 수 있기 때문입니다. 작업 대기열을 연결하려면 다음 명령을 실행합니다. ``` $ cat < ./batch-eks-gpu-jq.json { "jobQueueName": "My-Eks-GPU-JQ1", "priority": 10, "computeEnvironmentOrder": [ { "order": 1, "computeEnvironment": "My-Eks-GPU-CE1" } ] } EOF $ aws batch create-job-queue --cli-input-json file://./batch-eks-gpu-jq.json ``` # Amazon EKS GPU 작업 정의 생성 현재는 `nvidia.com/gpu`만 지원되며, 설정하는 리소스 값은 정수여야 합니다. GPU의 일부만 사용할 수는 없습니다. 자세한 내용은 *Kubernetes 설명서*의 [GPU 예약](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/)을 참조하세요. Amazon EKS용 GPU 작업 정의를 등록하려면 다음 명령을 실행합니다. ``` $ cat < ./batch-eks-gpu-jd.json { "jobDefinitionName": "MyGPUJobOnEks_Smi", "type": "container", "eksProperties": { "podProperties": { "hostNetwork": true, "containers": [ { "image": "nvcr.io/nvidia/cuda:10.2-runtime-centos7", "command": ["nvidia-smi"], "resources": { "limits": { "cpu": "1", "memory": "1024Mi", "nvidia.com/gpu": "1" } } } ] } } } EOF $ aws batch register-job-definition --cli-input-json file://./batch-eks-gpu-jd.json ``` # Amazon EKS 클러스터에서 GPU 작업 실행 GPU 리소스는 압축할 수 없습니다. **요청** 값이 **제한** 값과 동일한 GPU 작업에 대한 포드 사양을 AWS Batch 생성합니다. 이는 Kubernetes 요구 사항입니다. 작업을 다시 시작하려면 다음 명령을 실행합니다. ``` $ aws batch submit-job --job-queue My-Eks-GPU-JQ1 --job-definition MyGPUJobOnEks_Smi --job-name My-Eks-GPU-Job # locate information that can help debug or find logs (if using Amazon CloudWatch Logs with Fluent Bit) $ aws batch describe-jobs --job | jq '.jobs[].eksProperties.podProperties | {podName, nodeName}' { "podName": "aws-batch.f3d697c4-3bb5-3955-aa6c-977fcf1cb0ca", "nodeName": "ip-192-168-59-101.ec2.internal" } ``` # AWS Batch 작업 대기열에서 작업 보기 AWS Batch에서 작업을 보고 필터링할 수 있습니다. 이 기능은 기존 작업 대기열을 보고 세 가지 옵션 중 하나를 사용하여 작업을 필터링하는 옵션을 제공합니다. 검색 및 필터는 최종 상태(`SUCCEEDED` 또는 `FAILED`)가 아닌 작업을 검색할 수 있습니다. 작업 상태가 `SUCCEEDED` 또는 `FAILED`가 되면 최대 7일 동안 작업을 검색할 수 있습니다. 여전히 작업의 CloudWatch 또는 Amazon EventBridge 로그를 볼 수 있습니다. 이 절차를 사용하여 AWS Batch 콘솔의 작업 대기열에 있는 모든 작업을 나열합니다. 선택적으로, **필터 결과** 필드를 지정한 기준에 따라 결과의 범위를 좁힙니다. 1. [AWS Batch 콘솔](https://console.aws.amazon.com/batch/home)로 이동합니다. 1. 탐색 창에서 **작업**을 선택합니다. 1. **작업 대기열** 드롭다운 목록을 확장하고 검색할 작업 대기열을 선택합니다. **참고** 한 번에 하나의 작업 대기열 내에서만 작업을 검색할 수 있습니다. 1. **결과 필터링** 필드에 결과에 포함할 키워드를 입력합니다. 이 필드를 사용하여 **작업 이름**, **상태** 또는 **작업 ID**를 기준으로 필터링할 수 있습니다. 속성에 따라서는 같음(=) 또는 포함(^)과 같은 추가 연산자를 정의해야 할 수 있습니다. **참고** SageMaker 훈련 작업 대기열은 **작업 이름** 및 **작업 ID**별 필터링만 지원합니다. 1. **검색**을 선택합니다. # 작업 대기열에서 작업 AWS Batch 검색 작업 검색을 AWS Batch 사용하여에서 작업을 검색하고 필터링할 수 있습니다. 이 기능은 기존 작업 대기열에서 작업을 검색하고 필터링하는 옵션을 제공합니다. 검색 및 필터는 최종 상태(`SUCCEEDED` 또는 `FAILED`)가 아닌 작업을 검색할 수 있습니다. 작업 상태가 `SUCCEEDED` 또는 `FAILED`가 되면 최대 7일 동안 작업을 검색할 수 있습니다. 여전히 작업의 CloudWatch 또는 Amazon EventBridge 로그를 볼 수 있습니다. 여러 기준을 동시에 사용하여 검색하려면 **고급 검색** 기능을 사용합니다. 예를 들어 **상태**, **날짜 범위** 및 **추가 기준**(예: 작업 이름, 작업 정의, 작업 ID)과 같은 필터 중 일부 또는 전부를 포함할 수 있습니다. ## 검색 AWS Batch 작업(AWS 콘솔) 이 절차를 사용하여 AWS Batch 콘솔의 작업 대기열에서 작업을 검색합니다. 1. [AWS Batch 콘솔](https://console.aws.amazon.com/batch/home)로 이동합니다. 1. 탐색 창에서 **작업**을 선택합니다. 1. **고급 검색**을 켭니다. 1. **작업 대기열** 드롭다운 목록을 확장하고 검색할 작업 대기열을 선택합니다. **참고** 한 번에 하나의 작업 대기열 내에서만 작업을 검색할 수 있습니다. 1. **검색 옵션**: 1. **상태** 드롭다운 목록에서 필터링할 상태를 하나 이상 선택할 수 있습니다. 자세한 내용은 [작업 상태](job_states.md) 및 [서비스 작업 상태](service-job-status.md) 섹션을 참조하세요. **참고** 배열 작업 상위는 하위 작업이 로 업데이트될 `PENDING` 때 로 업데이트되고 하위 작업이 실행되는 동안 `PENDING` 상태를 `RUNNABLE` 유지합니다. 이러한 작업을 보려면 모든 하위 작업이 터미널 상태에 도달할 때까지 `PENDING` 상태를 기준으로 필터링합니다. 1. **날짜 범위**를 선택하여 날짜 및 시간 범위를 기준으로 결과를 필터링합니다. + **상대 모드**를 선택하여 현재 날짜 및 시간에서 역순으로 계산한 시간 범위 내에 생성 날짜를 가진 작업을 검색합니다. + **절대 모드**를 선택하여 지정한 날짜 및 시간 범위 내에 생성 날자를 가진 작업을 검색합니다. 1. **추가 기준** 필드에 검색 결과에 포함할 키워드를 입력합니다. 예를 들어이 필드를 사용하여 **작업 이름**, **작업 정의**, **작업 ID** 또는 **공유 식별자**로 검색할 수 있습니다. 속성에 따라서는 같음(=) 또는 포함(^)과 같은 추가 연산자를 정의해야 할 수 있습니다. **참고** SageMaker 훈련 작업 대기열은 **작업 이름** 및 **작업 ID**별 필터링만 지원합니다. **참고** **공유 식별자**를 기준으로 필터링할 때 작업 상태를 지정할 수도 있습니다. 이는 다른 필터가 작업 상태 필터링을 제외하는 제한에 대한 예외입니다. 1. **검색**을 선택합니다. ## AWS Batch 작업 검색 및 필터링(AWS CLI) 이 절차를 사용하여 AWS CLI로 작업 대기열에 있는 모든 작업을 나열합니다. 선택적으로, **-filters** 파라미터를 사용하여 지정한 기준에 따라 결과의 범위를 좁힙니다. ------ #### [ Search job queue (AWS CLI) ] [list-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-jobs.html) 명령을 사용하여 작업 대기열을 검색하고 필터링할 수 있습니다. 예를 들어 작업 이름을 기반으로 작업 대기열을 검색할 수 있습니다. ``` aws batch list-jobs \ --job-queue my-job-queue \ --filters name=JOB_NAME,values="my-job" ``` 공유 식별자를 기준으로 작업을 필터링합니다. ``` aws batch list-jobs \ --job-queue my-job-queue \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 공유 식별자를 기준으로 필터링할 때 작업 상태를 포함할 수 있습니다. ``` aws batch list-jobs \ --job-queue my-job-queue \ --job-status RUNNING \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 위의 명령에서 다음과 같이 변경합니다. + *my-job-queue*를 작업 대기열의 이름으로 바꿉니다. + *my-job*을 작업의 이름으로 바꿉니다. + *my-share*를 필터링하려는 공유 식별자로 바꿉니다. ------ #### [ Search service job queue (AWS CLI) ] [list-service-jobs](https://docs.aws.amazon.com/cli/latest/reference/batch/list-service-jobs.html) 명령을 사용하여 서비스 작업 대기열을 검색하고 필터링할 수 있습니다. 예를 들어 작업 이름을 기반으로 서비스 작업 대기열을 검색할 수 있습니다. ``` aws batch list-service-jobs \ --job-queue my-sm-queue \ --filters name=JOB_NAME,values="my-sm-job" ``` 공유 식별자를 기준으로 서비스 작업을 필터링합니다. ``` aws batch list-service-jobs \ --job-queue my-sm-queue \ --filters name=SHARE_IDENTIFIER,values="my-share" ``` 위의 명령에서 다음과 같이 변경합니다. + *my-sm-queue*를 서비스 작업 대기열의 이름으로 바꿉니다. + *my-sm-job*을 서비스 작업의 이름으로 바꿉니다. + *my-share*를 필터링하려는 공유 식별자로 바꿉니다. ------ # AWS Batch 작업에 대한 네트워킹 모드 다음 표에서는 네트워킹 모드와 AWS Batch 작업 유형의 일반적인 사용에 대해 설명합니다. 고려 사항 및 동작에 대한 자세한 내용은 '작업 유형' 열의 링크를 참조하세요. | 작업 유형 | 지원되는 네트워크 모드 | 일반적인 사용 | | --- | --- | --- | | [ECS-EC2 단순 작업](jobs.md) | host | 컴퓨팅 환경에 정의된 vpc로의 송신만 필요한 가장 확장 가능한 처치 곤란 병렬 배치 워크로드에 사용됩니다. | | [ECS-EC2 다중 노드 병렬 작업](multi-node-parallel-jobs.md) | awsvpc | 태스크 노드 간의 조정된 통신을 통해 단일 작업으로 모델링된 긴밀하게 결합된 다중 호스트(노드) 분산 워크로드에 사용됩니다. | | [ECS-Fargate 단순 작업](when-to-use-fargate.md) | awsvpc | 처치 곤란 병렬 배치 워크로드를 위한 트루 서버리스입니다. 일반적으로 가장 낮은 TCO 및 가장 높은 컨테이너 격리 작업 모델입니다. | | [EKS-EC2 단순 작업](eks-jobs.md) | 호스트 및 포드 | 컴퓨팅 환경에 정의된 vpc로의 송신만 필요한 고확장성의 처치 곤란 병렬 배치 워크로드에 사용됩니다. 기본값은 호스트 네트워킹입니다. | | [EKS-EC2 다중 노드 병렬 작업](mnp-eks-jobs.md) | 호스트 및 포드 | 포드 노드 간의 조정된 통신을 통해 단일 작업으로 모델링된 긴밀하게 결합된 다중 호스트(노드) 분산 워크로드에 사용됩니다. 기본값은 호스트 네트워킹입니다. | # CloudWatch Logs에서 AWS Batch 작업 로그 보기 Amazon CloudWatch Logs로 로그 정보를 전송하도록 [AWS Batch 작업을 구성할 수 있습니다](using_cloudwatch_logs.md#using_cloudwatch_logs.title). 이렇게 하면 한 곳에서 작업의 다양한 로그를 편리하게 볼 수 있습니다. 자세한 내용은 [에서 CloudWatch Logs 사용 AWS Batch](using_cloudwatch_logs.md) 단원을 참조하십시오. AWS Batch 콘솔에서 **작업 로그**를 사용하여 AWS Batch 작업을 모니터링하거나 문제를 해결할 수도 있습니다. 1. [AWS Batch 콘솔](https://console.aws.amazon.com/batch/home)을 엽니다. 1. **작업**을 선택합니다. 작업 대기열의 정렬 및 필터링 작업에 대한 자세한 내용은 [AWS Batch 작업 대기열에서 작업 보기](view-jobs.md) 및 [작업 대기열에서 작업 검색](searching-filtering-jobs.md) 섹션을 참조하세요. 1. **작업 대기열**에서 원하는 작업 대기열을 선택합니다. **작은 정보** 작업 대기열에 여러 작업이 있는 경우 **검색 및 필터링** 기능을 켜서 작업을 더 빨리 찾을 수 있습니다. 자세한 내용은 [작업 대기열에서 작업 AWS Batch 검색](searching-filtering-jobs.md) 단원을 참조하십시오. 1. **상태**에서 원하는 작업 상태를 선택합니다. 1. 원하는 작업을 선택하면 **세부 정보** 페이지가 열립니다. 1. **세부 정보** 페이지에서 아래의 **로그 스트림 이름**으로 스크롤하여 링크를 선택합니다. 링크를 클릭하면 작업에 대한 Amazon CloudWatch Logs 페이지가 열립니다. 1. (선택 사항) 이번이 로그를 처음 보는 경우라면 승인 요청 메시지가 표시될 수 있습니다. **필요한 승인**에 **OK**(을)를 입력한 다음 **승인**을 선택하여 Amazon CloudWatch 요금을 수락합니다. **참고** CloudWatch 요금에 대한 승인을 취소하려면: 왼쪽 탐색 창에서 **권한**을 선택합니다. **작업 로그**에서 **편집**을 선택합니다. **CloudWatch를 사용하도록 배치에 승인** 확인란을 해제합니다. **변경 사항 저장**을 선택합니다. # AWS Batch 작업 정보 검토 상태, 작업 정의, 컨테이너 정보와 같은 AWS Batch 작업 정보를 검토할 수 있습니다. 1. [AWS Batch 콘솔](https://console.aws.amazon.com/batch/home)을 엽니다. 1. **작업**을 선택합니다. 1. **작업 대기열**에서 원하는 작업 대기열을 선택합니다. **작은 정보** 작업 대기열에 여러 작업이 있는 경우 **검색 및 필터**를 설정하여 작업을 더 빨리 찾을 수 있습니다. 자세한 내용은 [작업 대기열에서 작업 AWS Batch 검색](searching-filtering-jobs.md) 단원을 참조하십시오. 1. 원하는 색상을 선택합니다. **참고** AWS Command Line Interface (AWS CLI)를 사용하여 AWS Batch 작업에 대한 세부 정보를 볼 수도 있습니다. 자세한 내용은 [AWS CLI 명령 레퍼런스](https://docs.aws.amazon.com/cli/latest/reference/)에서 [describe-domain](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/batch/describe-jobs.html)을 참조하세요.