Amazon EKS에서 AI/ML 워크로드를 위한 가속 컴퓨팅 관리하기

Amazon EKS에서 AI/ML 워크로드를 위한 가속 컴퓨팅 관리하기

팁

예정된 Amazon EKS AI/ML 워크숍에 등록하세요.

이 섹션은 Amazon EKS에서 AI/ML 학습·추론 워크로드를 위해 EC2 가속 컴퓨팅 인스턴스를 구매하고 프로비저닝하는 방법을 다룹니다. 대규모 모델을 학습하든, 실시간 추론을 실행하든, 생성형 AI 애플리케이션을 배포하든, 올바른 NVIDIA GPU 또는 AWS Trainium 용량을 사용하는 것은 워크로드 성능의 기반이 돼요.

EC2 인스턴스 유형 선택

사용 가능한 Amazon EC2 가속 컴퓨팅 인스턴스에 대한 자세한 내용은 Specifications for Amazon EC2 accelerated computing instances를 참고하세요. 여기에는 P-family와 G-family의 NVIDIA GPU 인스턴스와 AWS가 설계한 가속기인 Trainium, Inferentia가 포함됩니다.

EC2 구매 옵션 이해

워크로드에 필요한 가속 인스턴스를 알게 되면 다음 단계는 이러한 가속 인스턴스 유형을 확보하기 위한 구매 옵션을 이해하는 일이에요. AWS는 네 가지 컴퓨팅 용량 구매 옵션을 제공합니다. On-Demand Instances, Spot Instances, Capacity Blocks for ML, On-Demand Capacity Reservations (ODCRs)입니다. 각 옵션은 서로 다른 워크로드 패턴, 비용 프로필, 가용성 요구 사항에 대응합니다. Amazon EC2 Instance Purchasing Options 문서는 각 옵션이 어떻게 작동하는지, 가격 모델, 언제 사용해야 하는지 설명해요.

  • On-Demand Instances: 약정 없이 초 단위로 지불하며 용량이 있으면 즉시 사용할 수 있어요. 개발, 프로토타이핑, 예측 불가능한 추론 확장, 중단 위험 없이 즉시 컴퓨팅이 필요한 모든 워크로드에 가장 적합합니다.
  • Spot Instances: 사용하지 않는 EC2 용량을 사용해서 On-Demand 대비 최대 90% 절감되며, 2분의 중단 고지가 있어요. 내구성 있는 스토리지에 체크포인트하는 내결함성 워크로드(하이퍼파라미터 튜닝, 주기적 체크포인트가 있는 분산 학습, 배치·오프라인 추론, 데이터 전처리 파이프라인)에 가장 적합합니다.
  • Capacity Blocks for ML: 고정 기간(24시간, 최대 6개월) 동안 P-family 및 Trainium 인스턴스를 예약하고, 최대 8주 전에 예약할 수 있어요. 계획된 대규모 학습 실행, 시간 제한이 있는 파인튜닝 실험, 알려진 일정과 함께 GPU 클러스터에 예측 가능한 접근이 필요한 연구 프로젝트에 사용하세요.
  • On-Demand Capacity Reservations (ODCRs): 장기 약정 없이 특정 가용 영역에서 가속 용량을 예약하며, 용량을 사용하든 사용하지 않든 표준 On-Demand 요율로 청구됩니다. 스케줄링 지연이나 용량 부족이 허용되지 않는 프로덕션 추론, SLA로 묶인 서비스, 비즈니스에 중요한 애플리케이션에 가장 적합해요. Capacity Blocks와 달리 ODCR은 P-family와 G-family 인스턴스를 모두 지원합니다.

구매 옵션을 워크로드 요구 사항에 매칭

이제 가속 인스턴스 유형과 구매 옵션을 이해했으니, 다음 단계는 올바른 구매 옵션을 워크로드별 요구 사항에 매칭하는 일이에요. 인스턴스 유형, 리전, 시점에 걸쳐 더 큰 유연성을 가진 워크로드는 더 많은 구매 옵션과 더 낮은 가격의 혜택을 받습니다.

다음과 같은 요소를 기준으로 결정하세요.

  • 전략적 중요성과 SLA 약정
  • 수요 예측 가능성과 스케줄링 유연성
  • 예약 용량을 미리 약정할 의향
  • 인스턴스 유형, 리전, 시점에 걸친 유연성
  • 비용 절감 대비 중단 허용도

실무에서 팀은 여러 구매 옵션을 결합한 하이브리드 방식을 채택해서 워크로드 포트폴리오 전반에서 비용과 가용성, 신뢰성을 균형 잡아요. How to Get GPU Capacity on AWS 문서는 다양한 유형의 워크로드에 올바른 구매 옵션을 선택하기 위한 의사 결정 트리, 가격 비교, 실제 사례를 제공합니다.

EC2 서비스 할당량 확인

EKS 클러스터에서 어떤 용량 구매 옵션을 구현하기 전에 AWS 계정에 계획한 GPU 인스턴스 패밀리에 충분한 vCPU 할당량이 있는지 확인하세요. 할당량이 충분하지 않으면 어떤 구매 옵션을 선택하든 Karpenter NodePools, EKS Auto Mode 프로비저닝, EKS 노드 그룹이 가속 컴퓨팅 노드를 시작하지 못합니다.

  • AWS는 인스턴스 패밀리와 구매 모델별로 별도의 vCPU 할당량을 적용해요. 가속 컴퓨팅 인스턴스의 기본 할당량을 이해하려면 Amazon EC2 instance type quotas를 검토하세요.

이 할당량은 인스턴스 수가 아니라 vCPU 수를 기준으로 합니다. 예를 들어 p6-b300.48xlarge 인스턴스 10개를 시작하려면 1,920 vCPU(10 × 192)가 필요해요. 새 계정의 기본 GPU 할당량은 종종 0으로 설정되어 있으므로 인스턴스 배포를 시도하기 전에 증액을 요청하세요.

Capacity Block 예약 생성, On-Demand 인스턴스 시작, Spot 요청 제출 시 할당량 제한이 발생하면 AWS Support 또는 AWS 계정 팀에 문의해서 요구 사항을 논의하고 요구에 가장 적합한 가속 컴퓨팅 용량을 확보할 방법을 모색하세요.

Amazon EKS와 함께 EC2 구매 옵션 사용

EC2 가속 컴퓨팅 구매 옵션을 선택한 후에는 Amazon EKS 클러스터가 용량을 사용하도록 구성하세요. Amazon EKS는 각각 제어와 자동화의 균형이 다른 세 가지 프로비저닝 방법을 제공합니다.

  • Amazon EKS Auto Mode: AWS 관리형 컴퓨팅으로 노드를 자동으로 프로비저닝·확장·패치합니다. 내장 Karpenter로 프로비저닝하고 NVIDIA 드라이버와 device plugins이 포함된 Bottlerocket 운영체제를 사용해요. 최소한의 운영 오버헤드로 관리형 인프라를 원할 때 가장 적합합니다. 정적·동적 용량 프로비저닝을 모두 지원합니다.
  • Karpenter (자체 관리): Amazon EKS 클러스터에 직접 설치·운영하는 오픈소스 상위 프로젝트예요. EKS Auto Mode와 동일한 프로비저닝 모델을 제공하며 운영체제, AMI, 커널 튜닝, 노드 수명 주기를 완전히 제어할 수 있습니다. EKS Auto Mode가 기본 제공하지 않는 요구 사항이 있는 플랫폼 팀에 가장 적합해요.
  • 노드 그룹 (관리형 및 자체 관리): EC2 Auto Scaling Groups (ASG)로 뒷받침되며, EC2 런치 템플릿을 통해 용량이 사전에 정의됩니다. 기존 EKS 관리형 또는 자체 관리 노드 그룹이 있는 플랫폼 팀과 알려지고 정적인 가속 컴퓨팅 풋프린트로 예측 가능한 크기의 학습 워크로드에 가장 적합해요.

아래 페이지는 각 프로비저닝 옵션을 자세히 다룹니다.

  • Manage compute for AI/ML workloads with EKS Auto Mode and Karpenter
  • Manage compute for AI/ML workloads on Amazon EKS with node groups

혼합 전략: 구매 옵션 결합

단일 Amazon EKS 클러스터 안에서 여러 용량 구매 옵션을 결합하는 것은 흔한 일이에요. 이 접근 방식은 서로 다른 워크로드를 가장 적절한 용량 소스로 라우팅해서 비용과 가용성, 신뢰성을 동시에 최적화합니다. 고객들은 세 가지 EKS 컴퓨팅 관리 접근 방식(EKS Auto Mode, Karpenter, Node Groups) 중 하나를 사용하거나 같은 클러스터 안에서 이들을 결합해서 이 하이브리드 전략을 구현해요.

EKS Auto Mode와 Karpenter는 항상 예약 용량(ODCRs 및 Capacity Blocks)을 먼저 프로비저닝하고 그다음 Spot 또는 On-Demand를 사용합니다. 이 인스턴스 프로비저닝 우선순위를 결합해서 중요 워크로드는 예약 용량에, 유연한 워크로드는 Spot 또는 On-Demand 인스턴스에 스케줄링할 수 있어요. 워크로드 라우팅은 Kubernetes 네이티브 스케줄링 기본 요소로 제어합니다. nodeSelector는 특정 용량 유형을 타겟팅하고, taints와 tolerations는 NVIDIA GPU 또는 AWS Trainium 노드를 격리하며, topologySpreadConstraints는 높은 가용성을 위해 워크로드를 가용 영역 전반에 분산해요.

잘 설계된 Amazon EKS 클러스터는 가속 컴퓨팅 NodePools 또는 노드 그룹을 Reserved와 Burst라는 두 범주로 구성합니다. 각 범주는 용량 전략에 가장 적합한 워크로드 패턴에 맞춰집니다. 예시는 아래와 같습니다.

  • 예약 용량 (Reserved Capacity): gpu-reserved NodePool 또는 노드 그룹은 SLA로 묶인 서비스와 계획된 컴퓨팅 집약 작업을 위해 예약 용량(ODCRs 및 Capacity Blocks)에서 프로덕션 추론과 예약된 대규모 학습을 실행해요. 이 NodePool 또는 노드 그룹은 추론·프로덕션 워크로드, 즉 실시간 추론 엔드포인트, 프로덕션 모델 서빙, 예측 가능한 성능으로 항상 켜진 GPU 가용성이 필요한 비즈니스에 중요한 애플리케이션을 서빙합니다. 또한 예약된 컴퓨팅 집약 작업, 즉 계획된 분산 학습, 대규모 파인튜닝 실험, 시간 제한이 있는 연구 프로젝트, 시작 시간과 기간을 미리 아는 모든 워크로드도 지원해요.
  • 버스트 용량 (Burst Capacity): gpu-burst NodePool 또는 노드 그룹은 실험, 임시 워크로드, 배치 처리를 처리합니다. On-Demand 폴백과 함께 Spot 인스턴스를 기본 용량 유형으로 사용해요. 이 조합은 내결함성 워크로드의 비용 절감을 극대화하고 Spot을 사용할 수 없을 때 용량을 보장합니다. 이 NodePool 또는 노드 그룹은 배치 오프라인 추론, 데이터 전처리 파이프라인, 모델 평가 작업, 개발·프로토타이핑, 예측 불가능한 추론 확장, 수명이 짧은 디버깅 세션, 그리고 체크포인팅을 구현해서 Spot 중단을 처리할 수 있거나 예약을 정당화하지 않지만 예약 창을 기다릴 수 없는 모든 워크로드를 서빙해요. 이 NodePool 또는 노드 그룹의 워크로드는 2분 Spot 중단 창 안에서 노드 손실을 처리하도록 체크포인팅과 정상 종료를 구현합니다.

워크로드에 원하는 용량 유형을 nodeSelector: karpenter.sh/capacity-type: [spot, on-demand, reserved]로 지정하세요. 가중치 기반 프로비저닝은 모든 용량 풀에 걸쳐 클러스터를 효율적으로 확장합니다. 이 아키텍처로 실험용 노트북부터 프로덕션 추론까지 다양한 AI/ML 워크로드를 단일 Amazon EKS 클러스터 안에서 비용을 최적화하며 실행할 수 있어요.

더 알아보기 (Learn more)

출처: 문서