이 페이지 개선에 도움 주기
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.
EKS Auto Mode 및 Karpenter를 사용하여 AI/ML 워크로드용 컴퓨팅 관리
작은 정보
향후 예정된 Amazon EKS AI/ML 워크숍에 등록
이 섹션에서는 Amazon EKS Auto Mode 또는 자체 관리형 Karpenter를 사용하여 AI 훈련 및 추론 워크로드를 위한 가속 컴퓨팅(AWS Trainium, NVIDIA GPU)을 관리하는 방법을 다룹니다.
EKS Auto Mode 및 Karpenter는 동적 프로비저닝과 정적 프로비저닝이라는 두 가지 프로비저닝 모드를 지원합니다. 동적 프로비저닝을 사용하면 워크로드가 클러스터에 예약될 때 EKS Auto Mode 및 Karpenter가 가속 컴퓨팅 인스턴스를 프로비저닝하고 규모를 조정합니다. 정적 프로비저닝을 사용하면 EKS Auto Mode 및 Karpenter는 고정된 수의 노드를 프로비저닝하고 유지합니다. 동일한 클러스터에서 동적 프로비저닝과 정적 프로비저닝을 함께 사용하여 워크로드 수요에 따라 규모를 조정하면서 일정한 기준 용량 풀을 유지할 수 있습니다.
EKS Auto Mode 및 Karpenter는 네 가지 용량 구매 옵션(온디맨드, 스팟, 용량 블록, ODCR)을 모두 지원하며 항상 예약 용량을 먼저 프로비저닝한 다음 스팟 또는 온디맨드를 프로비저닝합니다.
EKS Auto Mode와 Karpenter 비교
두 접근 방식 모두 NodePool API를 공유하지만 운영 소유권, 리소스 API, 운영 체제 지원, 스팟 중단 처리, 구성 유연성이 서로 다릅니다.
| 기능 | EKS Auto Mode | 자체 관리형 Karpenter |
|---|---|---|
|
최적의 용도 |
운영 오버헤드를 최소화하는 관리형 인프라를 선호하는 팀 |
노드 수명 주기, AMI, OS 튜닝, 패치 적용에 대한 완전한 제어를 선호하는 팀. |
|
운영 모델 |
AWS는 Karpenter 컨트롤러, GPU/Trainium 드라이버, 디바이스 플러그인, OS 패치 및 스팟 중단 처리를 프로비저닝하고 관리합니다. |
사용자는 클러스터에 Karpenter 컨트롤러를 설치하고 운영하며 GPU/Trainium 드라이버, 디바이스 플러그인, AMI 수명 주기, 패치 적용 및 스팟 중단 처리를 직접 관리합니다. |
|
컴퓨팅 옵션 |
온디맨드, 스팟, ODCR, ML용 용량 블록 |
온디맨드, 스팟, ODCR, ML용 용량 블록 |
|
리소스 API |
|
|
|
노드 운영 체제 |
Bottlerocket만 해당됩니다. NVIDIA GPU, AWS Trainium 및 EFA 종속성이 포함되어 있습니다. |
AL2023, Bottlerocket, Windows 또는 자체 AMI. |
|
노드 수명 |
보안 패치를 위한 최대 노드 수명 21일. 워크로드는 노드 교체를 허용해야 합니다. |
사용자가 NodePool |
|
스팟 중단 처리 |
네이티브. SQS 대기열 또는 노드 종료 핸들러가 필요하지 않습니다. |
구성 및 활성화는 사용자의 책임입니다. |
|
빠른 컨테이너 풀 |
모든 G, P 및 Trn 패밀리 인스턴스에 포함된 SOCI 병렬 풀 |
구성 및 활성화는 사용자의 책임입니다. |
|
EC2 배치 그룹 |
클러스터, 파티션, 분산 |
클러스터, 파티션, 분산 |
|
네트워크 인터페이스 구성 |
|
|
|
노드 복구 |
기본적으로 활성화됨, EKS 노드 모니터링 에이전트 포함 |
선택적으로 활성화됨, EKS 노드 모니터링 에이전트 자체 관리형 |
|
가격 책정 |
기본 EC2 인스턴스 비용 외에 EKS Auto Mode 관리 요금 |
오픈 소스입니다. 기본 EC2 인스턴스에 대한 비용을 지불합니다. |
일반적인 AI/ML 관련 잘 알려진 레이블
EKS Auto Mode 및 Karpenter는 인스턴스 유형을 하드 코딩하지 않고 워크로드를 타겟팅하기 위해 NodePool requirements 및 포드 nodeSelector 또는 nodeAffinity에서 사용할 수 있는 인스턴스 레이블을 제공합니다. 레이블 접두사는 서로 다릅니다. EKS Auto Mode는 eks.amazonaws.com/을 사용하고 자체 관리형 Karpenter는 karpenter.k8s.aws/를 사용합니다.
아래 표에는 NodePool에서 사용할 수 있는 관련 레이블이 나와 있습니다. 또한 EKS Auto Mode 및 Karpenter는 워크로드 타겟팅에 추가로 사용할 수 있는 프로비저닝 프로세스의 일부로 Karpenter 설명서
예약 용량에 대한 예약 레이블
EKS Auto Mode 또는 Karpenter가 노드를 예약으로 시작하면 다음 레이블이 추가됩니다. nodeSelector, 노드 선호도 또는 NodePool 요구 사항에서 이를 사용하여 워크로드를 라우팅합니다.
-
karpenter.sh/capacity-type:reserved,on-demand또는spot. 노드를 지원하는 용량을 나타냅니다. -
karpenter.k8s.aws/capacity-reservation-id: 노드가 시작된 특정 예약 ID입니다. -
karpenter.k8s.aws/capacity-reservation-type: ODCR의 경우default, 용량 블록의 경우capacity-block입니다.
다음 예제에서는 일반적인 예약 패턴을 보여줍니다.
포드를 특정 예약 하나에 고정(폴백 없음):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-id: "cr-0123456789abcdef0"
ODCR 노드만 타겟팅(용량 블록이 아닌 모든 ODCR):
spec: nodeSelector: karpenter.sh/capacity-type: reserved karpenter.k8s.aws/capacity-reservation-type: default
모든 예약 용량(ODCR 또는 용량 블록)을 타겟팅:
spec: nodeSelector: karpenter.sh/capacity-type: reserved
예약을 선호하지만 사용할 수 없는 경우 스팟 또는 온디맨드로 폴백:
spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: karpenter.sh/capacity-type operator: In values: ["reserved"]
예약 만료 동작
ODCR과 용량 블록은 예약이 종료될 때 다르게 동작합니다. 예약 및 체크포인팅 전략이 워크로드를 지원하는 예약 유형과 일치하는지 확인합니다.
ODCR
ODCR로 시작된 인스턴스는 해당 ODCR에 무기한으로 유지되지 않습니다. ODCR은 만료되거나 취소될 수 있으며, 인스턴스가 ODCR에서 수동으로 제거될 수도 있습니다. 이러한 상황이 발생하여 인스턴스가 더 이상 ODCR에 속하지 않게 되면 EKS Auto Mode/Karpenter는 이를 감지하여 노드의 karpenter.sh/capacity-type 레이블을 reserved에서 on-demand로 업데이트합니다. 인스턴스는 표준 온디맨드 용량으로 계속 실행되며 기존 포드는 중단 없이 계속 실행됩니다.
참고
엄격한 nodeSelector: karpenter.sh/capacity-type: reserved로 예약된 포드는 레이블이 다시 지정된 경우 노드에 예약되지 않습니다. 워크로드가 ODCR 만료 또는 취소 후에도 유지되도록 하려면 nodeSelector 대신 위에 표시된 preferredDuringSchedulingIgnoredDuringExecution 패턴을 사용합니다.
용량 블록
ODCR과 달리 용량 블록은 항상 종료 시간이 있으며 EC2는 종료 시간 30분 전에 용량 블록 인스턴스를 종료합니다(UltraServer 인스턴스 유형의 경우 60분). 예약 기간이 종료되기 전에 훈련 및 추론 작업이 완료되거나 상태를 저장하도록 계획합니다. 특정 capacity-reservation-id에 대해 엄격한 nodeSelector를 사용하는 포드는 블록이 만료되면 Pending 상태가 되며 다른 곳에서 다시 예약되지 않습니다. 용량 블록 만료 중에 워크로드를 다른 용량으로 이동해야 하는 경우 체크포인팅을 위의 유연한 선호도 패턴과 결합합니다.
-
예약 인스턴스는 대부분의 인스턴스 유형에서 용량 블록 종료 시간 30분 전까지, UltraServer 인스턴스 유형에서 종료 시간 60분 전까지 사용할 수 있습니다.
-
EKS Auto Mode 및 Karpenter는 EC2가 종료를 시작하기 10분 전에 용량 블록의 노드 드레이닝을 선제적으로 시작하므로 워크로드를 체크포인트하고 정상적으로 종료할 시간이 확보됩니다.
정적 용량 NodePool
EKS Auto Mode 및 Karpenter는 워크로드 수요에 관계없이 고정된 수의 노드를 유지 관리하는 정적 용량 NodePool을 지원합니다. 정적 풀은 지연 시간에 민감한 추론에서 콜드 스타트 지연을 없애고 클러스터에 최소 인프라 공간을 예약할 수 있게 해줍니다.
정적 용량은 NodePool에서 replicas 필드를 설정하여 구성됩니다.
고려 사항
-
replicas가 NodePool에 한 번 설정되면 제거할 수 없습니다. 단일 NodePool은 정적 용량 프로비저닝과 동적 용량 프로비저닝 간에 전환할 수 없습니다. -
정적 용량 NodePool은 통합 시 고려되지 않습니다. AMI 드리프트 또는 만료 중에 임시 규모 조정을 허용하려면
replicas위에limits.nodes를 설정합니다. -
예측 가능한 가용 영역(AZ) 배포를 위해 단일 풀의 여러 영역에 걸치는 대신 AZ당 하나의 정적 용량 NodePool을 생성합니다.
ML용 용량 블록
ML용 용량 블록을 사용하면 정의된 미래 기간에 대해 P 패밀리 및 Trainium 인스턴스를 예약할 수 있습니다. 인스턴스가 선결제되어 있으므로 EKS Auto Mode 및 Karpenter는 이를 무료로 모델링하고 온디맨드 및 스팟보다 우선시합니다. ML용 용량 블록의 예약 기간은 1~14일 또는 7일의 배수로 최대 182일(6개월)입니다.
EKS Auto Mode 또는 Karpenter에서 ML용 용량 블록을 사용하려면 NodeClass에서 용량 예약 ID로 capacityReservationSelectorTerms를 구성합니다. ML용 용량 블록에는 개방형 예약 일치를 사용할 수 없습니다. 조건에서 선택할 ID, 태그 세트 또는 인스턴스 일치 기준을 지정할 수 있습니다. 태그를 지정하면 일치하는 태그가 있는 계정에서 액세스할 수 있는 모든 용량 예약을 선택합니다. 소유자 계정 ID를 지정하여 이를 추가로 제한할 수 있습니다.
자세한 예시는 Karpenter documentation
온디맨드 용량 예약(ODCR)
ODCR은 장기 약정 없이 특정 가용 영역(AZ)의 용량을 보장합니다. 용량 사용 여부에 관계없이 표준 온디맨드 요금이 청구됩니다. ODCR은 ML용 용량 블록에서 지원하지 않는 G 패밀리 인스턴스를 포함하여 모든 NVIDIA GPU 패밀리를 지원합니다. ODCR이 선결제되므로 EKS Auto Mode 및 Karpenter는 이러한 인스턴스를 무료로 모델링하고 온디맨드 및 스팟보다 우선시합니다.
ODCR은 예약 종료 시 ML용 용량 블록과 다르게 작동합니다. ODCR이 만료되거나 취소되면 인스턴스는 표준 온디맨드로 계속 실행됩니다. 세부 정보는 예약 만료 동작 섹션을 참조하세요.
EKS Auto Mode 또는 Karpenter에서 ODCR을 사용하려면 NodeClass에서 capacityReservationSelectorTerms를 용량 예약 조건으로 구성합니다. 조건에서 선택할 ID, 태그 세트 또는 인스턴스 일치 기준을 지정할 수 있습니다. 태그를 지정하면 일치하는 태그가 있는 계정에서 액세스할 수 있는 모든 용량 예약을 선택합니다. 인스턴스 일치 기준을 지정하면 Open(호환되는 모든 인스턴스와 일치) 또는 Targeted(명시적으로 타겟팅된 인스턴스만 일치) 동작에 따라 예약을 선택합니다. 소유자 계정 ID를 지정하여 이를 추가로 제한할 수 있습니다.
자세한 예시는 Karpenter documentation
온디맨드
온디맨드는 기본 용량 유형이며 EKS Auto Mode 및 Karpenter에서 정적 또는 동적 프로비저닝과 함께 사용할 수 있습니다. NodePool에서 karpenter.sh/capacity-type: on-demand를 설정하여 온디맨드 인스턴스를 명시적으로 요청할 수 있습니다. EKS Auto Mode 및 Karpenter는 포드의 리소스 요청을 충족하는 최저 가격의 인스턴스를 선택합니다. 온디맨드를 개발, 프로토타이핑, 예측할 수 없는 추론 규모 조정, 중단 위험 없이 즉시 가용성이 필요한 워크로드에 사용합니다.
스팟
스팟은 여유 EC2 용량을 사용하여 온디맨드에 비해 최대 90%의 비용 절감 효과를 제공합니다. AWS는 2분 중단 통지를 통해 스팟 인스턴스를 회수할 수 있습니다. NodePool에 여러 인스턴스 패밀리를 나열하여 가용성을 극대화합니다. 스팟 워크로드를 PodDisruptionBudget 및 체크포인트와 페어링하고 정기적으로 내구성 있는 스토리지(Amazon S3 또는 Amazon EFS)에 저장하여 포드가 드레이닝 기간 동안 상태를 저장할 수 있도록 합니다.
스팟은 상당한 비용 절감을 위해 간헐적 중단이 허용되는 재개 가능한 내결함성 훈련 및 추론 워크로드에 적합합니다.
일반적인 후보는 다음과 같습니다.
-
하이퍼파라미터 튜닝 및 스윕: 중단될 경우 재시도할 수 있는 짧은 병렬 시도가 많습니다.
-
체크포인팅을 사용한 분산 훈련: 상태를 S3 또는 FSx에 주기적으로 저장하고 노드 손실 후 마지막 체크포인트에서 재개할 수 있는 장기 실행 작업입니다.
-
배치 및 오프라인 추론: 엔드 투 엔드 지연 시간이 초가 아닌 시간으로 측정되는, 데이터세트에 대한 대규모 채점 작업입니다.
-
데이터 전처리 및 특성 엔지니어링 파이프라인: 대규모 데이터세트에 대한 병렬 변환입니다.
-
모델 평가 및 벤치마킹: 멱등성 결과를 생성하는 반복 가능한 작업입니다.
-
개발, 프로토타이핑 및 노트북: 사용자가 수시로 재시작을 허용할 수 있는 대화형 실험입니다.
지연 시간에 민감한 실시간 추론, SLA 준수가 필요한 프로덕션 엔드포인트, 체크포인트가 없거나 재시작을 허용할 수 없는 워크로드에는 스팟을 사용하지 마세요.
NodePool에서 karpenter.sh/capacity-type: spot을 설정하여 스팟 인스턴스를 명시적으로 요청할 수 있습니다.