EKS Auto Mode와 Karpenter로 AI/ML 워크로드 컴퓨팅 관리하기

팁

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

이 섹션은 Amazon EKS Auto Mode 또는 자체 관리 Karpenter를 사용해서 AI 학습·추론 워크로드를 위한 가속 컴퓨팅(AWS Trainium, NVIDIA GPUs)을 관리하는 방법을 다룹니다.

EKS Auto Mode와 Karpenter는 동적 프로비저닝(dynamic provisioning)과 정적 프로비저닝(static provisioning)이라는 두 가지 프로비저닝 모드를 지원해요. 동적 프로비저닝에서는 워크로드가 클러스터에 스케줄링됨에 따라 EKS Auto Mode와 Karpenter가 가속 컴퓨팅 인스턴스를 프로비저닝하고 확장합니다. 정적 프로비저닝에서는 EKS Auto Mode와 Karpenter가 고정된 수의 노드를 프로비저닝하고 유지해요. 동적·정적 프로비저닝은 같은 클러스터에서 함께 사용해서 일정한 기준 용량 풀을 유지하면서 워크로드 수요에 따라 확장할 수 있습니다.

EKS Auto Mode와 Karpenter는 네 가지 용량 구매 옵션(On-Demand, Spot, Capacity Blocks, ODCRs)을 모두 지원하며, 항상 예약 용량을 먼저 프로비저닝한 다음 Spot 또는 On-Demand를 사용해요.

EKS Auto Mode vs Karpenter

두 접근 방식 모두 NodePool API를 공유하지만 운영 소유권, 리소스 API, 운영체제 지원, Spot 중단 처리, 구성 유연성에서 차이가 있어요.

기능	EKS Auto Mode	자체 관리 Karpenter
가장 적합한 경우	최소한의 운영 오버헤드로 관리형 인프라를 선호하는 팀	노드 수명 주기, AMI, OS 튜닝, 패칭을 완전히 제어하기를 선호하는 팀
운영 모델	AWS가 Karpenter 컨트롤러, GPU/Trainium 드라이버, device plugins, OS 패칭, Spot 중단 처리를 프로비저닝·관리합니다.	클러스터에 Karpenter 컨트롤러를 직접 설치·운영하고 GPU/Trainium 드라이버, device plugins, AMI 수명 주기, 패칭, Spot 중단 처리를 직접 소유합니다.
컴퓨팅 옵션	On-Demand, Spot, ODCRs, Capacity Blocks for ML	On-Demand, Spot, ODCRs, Capacity Blocks for ML
리소스 API	`NodePool` (`karpenter.sh/v1`), `NodeClass` (`eks.amazonaws.com/v1`)	`NodePool` (`karpenter.sh/v1`), `EC2NodeClass` (`karpenter.k8s.aws/v1`)
노드 운영체제	Bottlerocket만. NVIDIA GPU, AWS Trainium, EFA 종속성 포함.	AL2023, Bottlerocket, Windows, 또는 자체 AMI.
노드 수명	보안 패칭을 위해 최대 21일 노드 수명. 워크로드는 노드 교체를 견뎌야 함.	NodePool `expireAfter`와 disruption budgets로 노드 수명 주기를 직접 정의.
Spot 중단 처리	네이티브. SQS queue나 Node Termination Handler 필요 없음.	직접 구성·활성화해야 함.
빠른 컨테이너 풀	모든 G, P, Trn 패밀리 인스턴스에 SOCI parallel pull 포함	직접 구성·활성화해야 함.
EC2 배치 그룹	Cluster, partition, spread	Cluster, partition, spread
네트워크 인터페이스 구성	`interface` 또는 `EFA-only` 유형별 인터페이스 구성	`interface` 또는 `EFA-only` 유형별 인터페이스 구성
노드 복구	기본 활성화, EKS node monitoring agent 포함	선택적으로 활성화, EKS node monitoring agent 자체 관리
가격	기본 EC2 인스턴스 비용에 더한 EKS Auto Mode 관리 수수료	오픈소스. 기본 EC2 인스턴스 비용만 지불.

공통 AI/ML 잘 알려진 라벨 (Common AI/ML well-known labels)

EKS Auto Mode와 Karpenter는 인스턴스 유형을 하드코딩하지 않고 워크로드를 타겟팅할 수 있도록 NodePool requirements와 Pod nodeSelector 또는 nodeAffinity에서 사용할 수 있는 인스턴스 라벨을 노출해요. 라벨 접두사는 둘 사이에 차이가 있습니다. EKS Auto Mode는 eks.amazonaws.com/을, 자체 관리 Karpenter는 karpenter.k8s.aws/를 사용해요.

아래 표는 NodePool에서 사용할 수 있는 관련 라벨을 보여줍니다. EKS Auto Mode와 Karpenter는 프로비저닝 과정의 일부로 Karpenter 문서에 나열된 라벨도 워크로드 타겟팅에 추가로 사용할 수 있도록 노드에 적용합니다.

예약 용량 스케줄링 라벨

EKS Auto Mode나 Karpenter가 예약(reservation)에 노드를 시작하면 다음 라벨을 추가해요. nodeSelector, 노드 선호도(node affinity), 또는 NodePool requirements에서 이를 사용해서 워크로드를 라우팅할 수 있습니다.

karpenter.sh/capacity-type: reserved, on-demand, spot. 노드를 뒷받침하는 용량을 나타냅니다.
karpenter.k8s.aws/capacity-reservation-id: 노드가 시작된 특정 예약 ID.
karpenter.k8s.aws/capacity-reservation-type: ODCR의 경우 default, Capacity Blocks의 경우 capacity-block.

다음 예시는 일반적인 스케줄링 패턴을 보여줍니다.

Pod를 하나의 특정 예약에 고정(폴백 없음):

spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved
    karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"

ODCR 노드만 타겟팅(Capacity Blocks 제외):

spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved
    karpenter.k8s.aws/capacity-reservation-type: default

모든 예약 용량 타겟팅(ODCR 또는 Capacity Block):

spec:
  nodeSelector:
    karpenter.sh/capacity-type: reserved

예약을 선호하되 사용 불가 시 Spot 또는 On-Demand로 폴백:

spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: karpenter.sh/capacity-type
                operator: In
                values: ["reserved"]

예약 만료 동작 (Reservation expiration behavior)

ODCR과 Capacity Blocks는 예약이 끝날 때 다르게 동작해요. 스케줄링·체크포인팅 전략이 워크로드를 뒷받침하는 예약 유형과 일치하는지 확인하세요.

ODCR

ODCR에 시작된 인스턴스는 해당 ODCR에 무기한 속하지 않아요. ODCR은 만료되거나 취소될 수 있고, 인스턴스가 ODCR에서 수동으로 제거될 수도 있습니다. 이 중 어떤 일이 발생하고 EKS Auto Mode/Karpenter가 인스턴스가 더 이상 ODCR에 속하지 않음을 감지하면, 노드의 karpenter.sh/capacity-type 라벨을 reserved에서 on-demand로 업데이트합니다. 인스턴스는 표준 On-Demand 용량으로 계속 실행되고 기존 Pod도 중단 없이 계속 실행돼요.

참고

nodeSelector: karpenter.sh/capacity-type: reserved로 엄격히 스케줄링된 모든 Pod는 라벨이 다시 지정되면 해당 노드에 스케줄링되지 않습니다. 워크로드가 ODCR 만료나 취소를 견디려면 nodeSelector 대신 위에 보여준 preferredDuringSchedulingIgnoredDuringExecution 패턴을 사용하세요.

Capacity Blocks

ODCR과 달리 Capacity Blocks에는 항상 종료 시간이 있으며, EC2는 종료 시간 30분 전에 Capacity Block 인스턴스를 종료해요(UltraServer 인스턴스 유형은 60분 전). 예약 창이 닫히기 전에 학습·추론 작업이 완료되거나 상태를 저장하도록 계획하세요. 특정 capacity-reservation-id에 대해 엄격한 nodeSelector를 사용하는 Pod는 블록이 만료되면 Pending 상태가 되고 다른 곳으로 재스케줄링되지 않습니다. Capacity Block 만료 중에 워크로드를 다른 용량으로 이동해야 한다면 체크포인팅을 위의 유연한 선호도 패턴과 결합하세요.

대부분의 인스턴스 유형에서는 Capacity Block 종료 시간 30분 전까지, UltraServer 인스턴스 유형에서는 종료 시간 60분 전까지 예약 인스턴스를 사용할 수 있어요.

EKS Auto Mode와 Karpenter는 EC2가 종료를 시작하기 10분 전에 Capacity Block의 노드 드레이닝을 선제적으로 시작하므로, 워크로드가 체크포인트하고 정상 종료할 시간을 갖습니다.

정적 용량 NodePool (Static capacity NodePools)

EKS Auto Mode와 Karpenter는 워크로드 수요와 무관하게 고정된 수의 노드를 유지하는 정적 용량 NodePool을 지원해요. 정적 풀은 지연 시간에 민감한 추론에서 콜드 스타트 지연을 없애고, 클러스터에 최소 인프라 풋프린트를 예약할 수 있게 해 줍니다.

정적 용량은 NodePool의 replicas 필드를 설정해서 구성합니다.

고려 사항

NodePool에 replicas를 설정하면 제거할 수 없어요. 단일 NodePool은 정적·동적 용량 프로비저닝 사이를 전환할 수 없습니다.
정적 용량 NodePool은 통합(consolidation)에 고려되지 않아요. AMI 드리프트나 만료 중 임시 확장을 허용하려면 limits.nodes를 replicas보다 높게 설정하세요.
예측 가능한 가용 영역(AZ) 분포를 위해 단일 풀에서 여러 영역에 걸치지 말고 AZ마다 정적 용량 NodePool을 하나씩 만드는 게 좋아요.

Capacity Blocks for ML

Capacity Blocks for ML을 사용하면 정의된 미래 기간 동안 P-family 및 Trainium 인스턴스를 예약할 수 있어요. 선불(pre-paid)이므로 EKS Auto Mode와 Karpenter는 이를 무료로 취급하고 On-Demand와 Spot보다 우선합니다. Capacity Blocks for ML의 예약 기간은 1~14일 또는 7일의 배수로, 최대 182일(6개월)까지 설정할 수 있습니다.

EKS Auto Mode 또는 Karpenter에서 Capacity Blocks for ML을 사용하려면 NodeClass의 capacityReservationSelectorTerms에 용량 예약 ID를 구성하세요. Capacity Blocks for ML에는 열린 예약 매칭(open reservation matching)을 사용할 수 없어요. 용어(term)는 ID, 태그 집합, 또는 인스턴스 매칭 기준을 지정해서 선택할 수 있습니다. 태그를 지정하면 계정에서 접근 가능한 일치하는 태그가 있는 모든 용량 예약을 선택해요. 소유자 계정 ID를 지정하면 추가로 제한할 수 있습니다.

더 많은 예시는 Karpenter 문서를 참고하세요.

On-Demand Capacity Reservations (ODCRs)

ODCR은 장기 약정 없이 특정 가용 영역(AZ)에서 용량을 보장해요. 용량을 사용하든 사용하지 않든 표준 On-Demand 요금으로 청구됩니다. ODCR은 Capacity Blocks for ML이 지원하지 않는 G-family 인스턴스를 포함한 모든 NVIDIA GPU 패밀리를 지원해요. ODCR은 선불이므로 EKS Auto Mode와 Karpenter는 이를 무료로 취급하며 On-Demand와 Spot보다 우선합니다.

ODCR은 예약 종료 시 Capacity Blocks for ML과 다르게 동작해요. ODCR이 만료되거나 취소되면 인스턴스는 표준 On-Demand로 계속 실행됩니다. 자세한 내용은 Reservation expiration behavior를 참고하세요.

EKS Auto Mode 또는 Karpenter에서 ODCR을 사용하려면 NodeClass의 capacityReservationSelectorTerms에 용량 예약 조건을 구성하세요. 용어는 ID, 태그 집합, 또는 인스턴스 매칭 기준을 지정해서 선택할 수 있어요. 태그를 지정하면 계정에서 접근 가능한 일치하는 태그가 있는 모든 용량 예약을 선택합니다. 인스턴스 매칭 기준을 지정하면 매칭 동작으로 예약을 선택해요. open(호환되는 모든 인스턴스 매칭) 또는 targeted(명시적으로 타겟팅된 인스턴스만 매칭)입니다. 소유자 계정 ID를 지정하면 추가로 제한할 수 있어요.

더 많은 예시는 Karpenter 문서를 참고하세요.

On-Demand

On-Demand는 기본 용량 유형이며 EKS Auto Mode와 Karpenter에서 정적 또는 동적 프로비저닝과 함께 사용할 수 있어요. NodePool에 karpenter.sh/capacity-type: on-demand를 설정해서 On-Demand 인스턴스를 명시적으로 요청할 수 있습니다. EKS Auto Mode와 Karpenter는 Pod의 리소스 요청을 충족하는 가장 저렴한 인스턴스를 선택해요. 개발, 프로토타이핑, 예측 불가능한 추론 확장, 중단 위험 없이 즉시 가용성이 필요한 모든 워크로드에 On-Demand를 사용하세요.

Spot

Spot은 사용하지 않는 EC2 용량을 사용해서 On-Demand 대비 최대 90% 절감을 제공해요. AWS는 2분의 중단 고지와 함께 Spot 인스턴스를 회수할 수 있습니다. NodePool에 여러 인스턴스 패밀리를 나열해서 가용성을 극대화하세요. Spot 워크로드에 PodDisruptionBudget을 연결하고 정기적으로 내구성 있는 스토리지(Amazon S3 또는 Amazon EFS)에 체크포인트해서 Pod가 드레인 창 동안 상태를 저장할 수 있게 해요.

Spot은 가끔 중단을 허용하고 큰 비용 절감을 바라는 내결함성 있고 재개 가능한 학습·추론 워크로드에 잘 맞아요.

일반적인 후보로는 다음이 있어요.

하이퍼파라미터 튜닝과 스윕(sweeps): 중단되면 재시도할 수 있는 짧고 병렬적인 많은 시도.
체크포인팅이 있는 분산 학습: 주기적으로 S3나 FSx에 상태를 저장하고 노드 손실 후 마지막 체크포인트에서 재개할 수 있는 장기 실행 작업.
배치 및 오프라인 추론: 엔드투엔드 지연 시간이 초 단위가 아닌 시간 단위로 측정되는 데이터셋에 대한 대규모 점수 계산 작업.
데이터 전처리와 피처 엔지니어링 파이프라인: 대규모 데이터셋에 대한 병렬 변환.
모델 평가와 벤치마킹: 멱등 결과를 생성하는 반복 가능한 작업.
개발, 프로토타이핑, 노트북: 사용자가 가끔 재시작을 견딜 수 있는 대화형 실험.

지연 시간에 민감한 실시간 추론, SLA로 묶인 프로덕션 엔드포인트, 체크포인트하지 않거나 재시작을 견딜 수 없는 워크로드에는 Spot을 피하세요.

NodePool에 karpenter.sh/capacity-type: spot을 설정해서 Spot 인스턴스를 명시적으로 요청할 수 있어요.

더 알아보기 (Learn more)

공식 문서

출처: 문서