Lend and borrow resources across teams with AWS Batch’s quota management for SageMaker Training jobs

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS Batch의 SageMaker Training 작업용 quota management는 팀별 GPU 용량 할당과 유휴 자원 대여·차용, 선점을 결합해 자원 활용도와 작업 우선순위를 조정한다.

📌 핵심 요약

• AWS Batch는 Amazon SageMaker Training 작업의 대기열 관리·스케줄링·재시도를 완전관리형으로 제공하며, quota management는 팀·프로젝트·워크로드별 용량 할당과 유휴 GPU 공유를 지원한다.
• Quota share는 작업 대기열 아래의 가상 대기열로, RESERVE는 유휴 용량을 예약하고 LEND는 다른 share에 빌려주며 LEND_AND_BORROW는 대여와 차용을 모두 허용한다. AWS Batch는 용량 한도 미만인 share를 우선하며, 대여한 share에 작업이 들어오면 cross-share preemption으로 자원을 회수한다.
• In-share preemption을 활성화하면 같은 share에서 SCHEDULED·STARTING·RUNNING 상태인 낮은 우선순위 작업을 선점해 높은 우선순위 작업이 더 빨리 실행되도록 할 수 있다.
• 예제는 SageMaker Python SDK v3를 사용하고 전체 용량을 ml.g5.xlarge 3대로 설정한다. QS1·QS2·QS3의 할당 한도는 각각 1대이며, QS1은 LEND_AND_BORROW와 in-share preemption을 사용하고 모든 작업에 체크포인트를 적용한다. QS2는 LEND를 사용하며, QS3는 RESERVE를 사용하고 두 share 모두 in-share preemption을 끈다.
• QS1에 우선순위 3·2·1인 작업을 제출하면 상위 두 작업이 QS1의 자체 용량과 QS2의 유휴 용량으로 먼저 배정될 것으로 설명한다. 이후 QS2에 작업을 제출하면 QS1이 빌린 용량을 회수하는 cross-share preemption이 발생한다고 설명하지만, 제공된 원문은 해당 단계의 코드 도입부에서 끝난다.

🧩 주요 포인트

1. 팀별 할당과 유휴 자원 공유의 결합 → 기본 용량을 되찾을 수 있게 하면서 다른 팀이 쉬는 동안 추가 작업을 실행할 여지를 제공한다.
2. QS1·QS2·QS3의 서로 다른 정책 → 체크포인트를 사용하는 배경 작업, 추가 선점보다 대기를 선호하는 작업, 빠른 시작과 중단 최소화가 필요한 작업에 맞춰 활용도와 실행 안정성을 조정한다.
3. Cross-share preemption과 in-share preemption의 역할 분리 → 팀 간 용량 회수와 팀 내부 우선순위 처리를 각각 제어하지만, 예제의 최종 실행 결과는 제공된 원문만으로 확인할 수 없다.

🧠 상세 정리

1. 다중 팀 학습 환경의 자원 조정 문제

AWS Batch의 Amazon SageMaker Training 작업 지원으로 고객은 자체 인프라를 구축하지 않고도 머신러닝 학습 작업의 대기열 관리, 스케줄링, 재시도를 완전관리형으로 처리할 수 있게 됐다. 조직의 AI/ML 운영 규모가 커지고 참여 팀이 늘어나면 공유 GPU 용량에 대한 접근을 조정하는 과정에서 관리자에게 추가적인 소통·조정·설정 부담이 생긴다. 원문은 별도 대기열 구성, 용량 한도 조절, 적절한 작업에 적절한 시점에 자원을 배정하는 일을 이러한 부담의 예로 제시한다. 고객들이 공통으로 요청한 것은 팀이나 프로젝트별 할당량을 정의하고, 유휴 용량을 자동으로 공유하며, 우선순위가 높은 작업부터 실행하는 기능이었다. AWS Batch의 quota management는 이 요구에 대응해 마련된 스케줄링 기능으로, 팀별 할당을 존중하면서 기존 컴퓨팅 자원의 활용도를 높이는 것을 목표로 한다.

2. Quota share와 세 가지 자원 공유 전략

관리자는 팀이나 프로젝트처럼 구분되는 주체마다 quota share를 정의하고, 각 share에 컴퓨팅 용량 한도와 유휴 자원 공유 전략을 설정할 수 있다. Quota share는 연결된 작업 대기열 아래에 계층적으로 배치되는 가상 대기열이며, AWS Batch는 해당 대기열의 share들을 살펴보면서 용량 한도에 못 미치는 share를 우선한다. RESERVE는 작업이 도착할 때까지 유휴 용량을 예약하고, LEND는 실행할 작업이 있는 다른 share에 유휴 용량을 빌려주는 전략이다. LEND_AND_BORROW는 유휴 상태에서는 용량을 빌려주고, 자신의 작업에 도움이 될 때는 다른 share의 유휴 용량을 빌려 쓸 수 있게 한다. 이미 용량 한도에 도달했거나 이를 초과한 share에 작업이 들어오면 AWS Batch는 다른 share에서 차용할 수 있는 용량이 있는지 확인하므로, 추가 실행 여부는 실제로 이용 가능한 유휴 자원에 달려 있다.

3. 팀 간 용량 회수와 share 내부 우선순위 선점

용량을 다른 share에 빌려준 share에 새 작업이 들어오면 AWS Batch는 cross-share preemption을 수행해 빌려준 자원을 회수한다. 이 기능은 관리자가 차용 중인 작업을 직접 찾아 종료하지 않아도 원래 용량을 할당받은 share가 필요한 자원을 되찾을 수 있게 한다. 별도로 quota share를 구성할 때 우선순위 기반 in-share preemption을 활성화하면, 같은 share 내부의 낮은 우선순위 작업을 선점할 수 있다. 이때 대상이 될 수 있는 작업 상태는 SCHEDULED, STARTING, RUNNING이며, 목적은 대기열 앞쪽의 높은 우선순위 작업이 더 빨리 실행되도록 하는 것이다. 따라서 cross-share preemption은 share 사이에서 대여한 용량을 회수하는 기능이고, in-share preemption은 한 share 안에서 작업 우선순위에 따라 실행 기회를 조정하는 기능으로 구분된다.

4. 사전 조건과 quota management 리소스 구성

예제를 진행하려면 AWS Batch 리소스를 생성하고 관리할 권한이 있는 AWS 계정이 필요하며, 원문은 AWS Batch와 SageMaker API 호출에 필요한 샘플 IAM 권한을 안내한다. 예제는 SageMaker Python SDK v3를 사용하고, 호환되는 SDK를 설치하기 위한 명령으로 pip install sagemaker를 제시한다. Quota management를 사용하려면 quotaSharePolicy를 포함한 Scheduling Policy와 특정 인스턴스 기준으로 용량 한도를 지정한 Service Environment를 생성해야 한다. 여기에 두 리소스와 연결된 SageMaker Training 작업 대기열을 만들고 quota share들을 연결하는 구성이 필요하다. 원문은 사용자 가이드의 AWS CLI·콘솔 예제와 SDK v3의 aws_batch 모듈을 통합한 샘플 노트북을 안내하며, 본문에서는 노트북의 도우미 함수를 이용해 주요 리소스와 세 quota share를 구성한다.

5. QS1·QS2·QS3의 정책과 작업 특성

예제의 세 프로젝트는 각각 ml.g5.xlarge 인스턴스 1대를 용량 한도로 갖고, 이들을 연결하는 Service Environment의 전체 용량 한도는 3대로 설정된다. 배경 작업용 QS1은 중요한 작업을 먼저 실행하고 유휴 용량을 최대한 활용하려는 설정으로, LEND_AND_BORROW, in-share preemption 활성화, borrow_limit=200을 사용하며 모든 작업이 체크포인트를 사용해 선점을 수용한다. 중간 우선순위 작업용 QS2는 LEND를 사용하고 in-share preemption을 끄며, 차용 용량 회수나 내부 우선순위 선점으로 추가 중단을 겪기보다 용량이 생길 때까지 기다리려는 경우에 적합하다고 설명한다. QS2에서도 작업 배정 시 우선순위는 고려되며, 짧은 작업이나 제출 작업들의 우선순위가 대체로 비슷한 경우를 적용 예로 든다. 빠른 시작과 중단 최소화가 필요한 QS3는 RESERVE를 사용하고 대여·차용 및 in-share preemption을 모두 사용하지 않으므로, 용량 한도가 바뀌지 않는 한 AWS Batch가 해당 작업을 선점하지 않는다고 설명한다.

6. SageMaker Python SDK로 학습 작업 준비

SageMaker Python SDK의 aws_batch 모듈은 quota management가 활성화된 AWS Batch 작업 대기열에 SageMaker Training 작업을 프로그램으로 제출할 수 있도록 확장됐다. 예제는 Hello World를 실행하는 ModelTrainer를 사용하며, 먼저 선택한 리전과 인스턴스 유형에 맞는 학습 이미지 URI를 조회한다. 이미지 조회에는 PyTorch 버전 2.5와 training 범위를 지정하고, 학습 코드로는 echo 명령을 통해 Hello World를 출력하도록 구성한다. ModelTrainer에는 이 이미지와 소스 코드, 컴퓨팅 설정을 전달하고, StoppingCondition의 최대 실행 시간을 300초로 지정한다. 이어서 aws_batch 모듈의 TrainingQueue 생성자에 작업 대기열 이름을 전달해 제출에 사용할 객체를 만들며, 원문은 이 예제에는 데이터가 필요 없지만 일반적인 ModelTrainer 학습에는 데이터가 필요하다고 덧붙인다.

7. QS1의 작업 우선순위와 QS2 유휴 용량 차용

준비한 TrainingQueue를 이용해 배경 작업용 QS1에 세 작업을 제출하며, 먼저 제출하는 작업부터 우선순위를 각각 3, 2, 1로 설정한다. 작업 이름은 qs1_job_high, qs1_job_med, qs1_job_low이고, 제출 시 동일한 ModelTrainer와 QS1의 quota share 이름을 지정한다. 원문은 QS1과 QS2에서 실행 중인 작업이 없는 상황을 전제로, 상대 우선순위가 높은 첫 번째와 두 번째 작업에 인스턴스 2대분의 용량이 배정될 것으로 설명한다. 가장 높은 우선순위 작업은 QS1 자체 용량을 사용하고, 중간 우선순위 작업은 QS2가 빌려주는 유휴 용량을 사용하는 흐름이다. QS3는 RESERVE로 구성되어 차용 가능한 용량을 제공하지 않으며, 예제 코드는 상위 두 작업이 배정 또는 종료 상태로 전환될 때까지 기다린 뒤 각 share의 활성 작업을 조회하도록 작성되어 있다.

8. QS2 작업 도착에 따른 용량 회수와 자료의 범위

다음 단계는 QS2를 소유한 팀이 수행할 작업을 발견하고 QS2에 새 작업을 제출하는 상황으로 전환된다. 이때 QS1은 QS2의 용량을 빌려 사용 중이므로, 원문은 QS2의 작업 제출이 해당 용량을 되찾는 cross-share preemption을 일으킨다고 설명한다. QS3의 용량은 다른 share가 빌릴 수 없도록 설정되어 있어, 이 단계의 회수 대상은 QS1이 QS2에서 차용한 용량이다. 이 흐름은 유휴 상태에서는 다른 프로젝트가 자원을 활용하되 원래 할당받은 프로젝트에 작업이 생기면 용량을 돌려주는 quota management의 동작을 보여준다. 다만 제공된 원문은 이 단계의 코드가 시작되는 주석 부분에서 끝나므로, 이후의 구체적인 제출 코드, 선점된 작업의 처리 과정, 실제 실행 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Quota share의 용량 한도와 공유 전략을 함께 보면, 팀별 할당을 유지하는 방식과 유휴 GPU를 활용하는 방식을 별도로 조정할 수 있다.
• QS1의 체크포인트 사용과 QS2·QS3의 선점 억제 설정은 자원 활용도뿐 아니라 작업이 중단을 감수할 수 있는 정도가 정책 선택의 기준임을 보여준다.
• 작업 배정 시 우선순위를 고려하는 것과 이미 배정되거나 실행 중인 작업을 선점하는 것은 구분된다. QS2는 in-share preemption을 꺼도 배정 시 우선순위를 반영한다.

✅ 액션 아이템

• 팀·프로젝트별 GPU 용량 할당과 유휴 자원 공유 필요를 기준으로 RESERVE, LEND, LEND_AND_BORROW의 적용을 검토한다.
• 체크포인트 사용 여부와 중단 허용 수준을 기준으로 QS1·QS2·QS3의 정책 및 in-share preemption 설정을 비교한다.
• QS2 작업 제출 시 cross-share preemption으로 QS1의 차용 용량이 회수되는지 확인하고, 제공된 원문에서 확인되지 않은 최종 실행 결과를 검증한다.

❓ 열린 질문

• 팀·프로젝트별 GPU 용량 할당에서 RESERVE, LEND, LEND_AND_BORROW 중 어떤 전략이 각 작업의 요구에 적합한가?
• QS1처럼 체크포인트를 사용하는 배경 작업은 in-share preemption에 따른 중단을 어느 정도 허용할 수 있는가?
• QS2 작업 제출로 cross-share preemption이 발생할 때 QS1 작업은 실제로 어떻게 처리되며 최종 실행 결과는 어떠한가?