EKS Auto Mode의 비용 최적화
EKS Auto Mode의 비용 최적화
EKS Auto Mode가 통합(consolidation), 빈 패킹(bin-packing), 적정 규모 조정(right-sizing)을 통해 클러스터의 컴퓨팅 비용을 지속적으로 최적화하는 방법과, 어떤 워크로드 구성이 이런 최적화를 방해할 수 있는지 알아봐요. 비용 효율을 유지하도록 클러스터를 구성하는 법도 다뤄요.
출처: 문서
본문
EKS Auto Mode는 통합, 빈 패킹, 적정 규모 조정을 통해 클러스터의 컴퓨팅 비용을 지속적으로 최적화해요. 하지만 특정 워크로드 구성은 이런 최적화를 방해할 수 있어요. 이 토픽은 비용 최적화가 어떻게 동작하는지, 무엇이 이를 막을 수 있는지, 그리고 비용 효율을 유지하도록 클러스터를 구성하는 방법을 설명해요.
EKS Auto Mode가 비용을 최적화하는 방법 (How EKS Auto Mode optimizes cost)
EKS Auto Mode는 다음 메커니즘으로 컴퓨팅 비용을 줄여요:
- 빈 패킹 (Bin-packing) — 파드를 노드에 스케줄링할 때 EKS Auto Mode는 전체 리소스 요청을 가장 잘 맞추는 인스턴스 유형을 선택해 미사용 용량을 최소화해요.
- 통합 (Consolidation) — EKS Auto Mode는 실행 중인 노드를 주기적으로 평가해 워크로드를 더 적거나 저렴한 인스턴스에서 실행할 수 있으면 노드를 교체하거나 제거해요.
- 적정 규모 조정 (Right-sizing) — 워크로드가 축소되면 EKS Auto Mode는 파드를 더 작은 노드로 통합하고 활용도가 낮은 인스턴스를 종료해요.
이런 최적화는 수동 개입 없이 지속적으로 실행돼요. 하지만 일부 파드 어노테이션과 NodePool 구성은 통합이 적용되는 것을 막을 수 있어요.
내장 Node Pool과 비용 가드레일 (Built-in node pools and cost guardrails)
내장 general-purpose와 system Node Pool은 이미 여러 비용 보호 기본값을 적용해요:
- C, M, R 인스턴스 패밀리로 제한 — 가속화(P, G, Inf, Trn) 또는 이국적인 인스턴스 유형은 허용되지 않아요.
- 온디맨드 용량만 허용 — Spot 인스턴스가 없어서 중단으로 인한 변동은 피하지만 Spot 할인도 받지 못해요.
- 5세대 이상 — 더 오래되고 비용 효율이 낮은 인스턴스 세대는 제외돼요.
내장 Node Pool만 사용한다면 이미 이런 가드레일의 혜택을 보고 있어요. 인스턴스 패밀리 제외와 인스턴스 크기 제한에 대한 이 토픽의 지침은 이런 제한을 상속받지 않는 사용자 지정 NodePool을 만들 때 가장 관련이 있어요.
하지만 내장 Node Pool을 사용하더라도 다음 섹션은 여전히 적용돼요:
- 통합을 막는 것 (What blocks consolidation) —
do-not-disrupt어노테이션과 제한적인 PDB는 어떤 NodePool이 노드를 프로비저닝했든 통합을 막아요. - NodePool 한도를 비용 상한선으로 사용하기 (Use NodePool limits as a cost ceiling) — 내장 Node Pool에는 리소스
limits가 구성되어 있지 않아요. 워크로드가 크게 확장될 수 있다면 무제한인 내장 풀에 의존하는 대신 limits가 있는 사용자 지정 NodePool을 만드는 걸 고려해 주세요. - 노드 수명과 비용 (Node lifecycle and cost) — 노드 교체 오버랩은 내장 풀이 프로비저닝한 노드를 포함해 모든 노드에 적용돼요.
| 가드레일 | 내장 Node Pool | 사용자 지정 NodePool |
|---|---|---|
| 가속화 인스턴스 제외 | 적용됨 (Enforced) | 직접 구성해야 함 |
| 인스턴스 크기 한도 | 설정 안 됨 (Not set) | 직접 구성해야 함 |
리소스 limits (CPU/메모리 상한) |
설정 안 됨 (Not set) | 직접 구성해야 함 |
| 온디맨드 전용 | 적용됨 (Enforced) | 선택 (Spot/On-Demand) |
통합 보호 (do-not-disrupt/PDB) |
사용자 책임 | 사용자 책임 |
통합을 막는 것 (What blocks consolidation)
EKS Auto Mode가 노드를 중단하면 워크로드의 가용성 요구 사항을 위반할 것이라고 판단하면 통합이 차단돼요. 다음 구성은 통합을 방지해요:
do-not-disrupt 어노테이션
karpenter.sh/do-not-disrupt 어노테이션은 어노테이션이 달린 파드가 노드에서 실행되는 동안 EKS Auto Mode가 그 노드를 유지하도록 지시해요. 이렇게 하면 노드가 활용도가 낮더라도 통합·교체·종료되지 않아요.
metadata:
annotations:
karpenter.sh/do-not-disrupt: "true"
중요 — 비용 영향 (Cost implication): 파드가
do-not-disrupt어노테이션을 가지면 그 파드가 실행되는 노드는 통합에서 제외돼요. 즉:
- 노드는 실제 활용도와 관계없이 현재 인스턴스 크기로 계속 실행돼요.
- 워크로드 수요가 줄어도 해당 노드의 vCPU와 메모리 사용량이 높게 유지될 수 있어요.
- 여러 노드의 많은 파드가 이 어노테이션을 가지면 클러스터 전체 통합이 크게 줄어 지속적으로 더 높은 비용이 발생해요.
do-not-disrupt 어노테이션은 가용성 메커니즘이에요. 비용을 고려하지 않아요. 실행 중 중단이 데이터 손실이나 큰 재작업을 유발하는 워크로드 — 예를 들어 장기 실행 배치 작업이나 체크포인트가 없는 상태 저장 프로세스 — 에만 사용해 주세요.
대안으로 고려할 것 (Alternatives to consider):
- Pod Disruption Budgets (PDBs) — 중단을 완전히 차단하는 대신 중단 비율을 제어하는 데 PDB를 사용해요. PDB는 최소 replica 수가 유지되도록 하면서 통합이 진행되게 해요.
- 수명이 짧은 워크로드 (Shorter-lived workloads) — CI/CD 러너와 빌드 에이전트에서는 중단을 허용하고
do-not-disrupt대신 CI 시스템의 내장 재시도 로직에 의존해요. - 시간 제한 어노테이션 (Time-limited annotations) — 중요한 작업이 진행되는 동안에만
do-not-disrupt를 적용하고, 작업이 완료되면 프로그래밍 방식으로 제거해요.
Pod Disruption Budgets (PDBs)
maxUnavailable: 0을 설정하거나 minAvailable이 현재 replica 수와 같은 PDB는 영향을 받는 파드의 모든 통합을 사실상 차단해요. PDB를 검토해 최소한 파드 하나는 한 번에 중단될 수 있도록 해 주세요.
NodePool 한도를 비용 상한선으로 사용하기 (Use NodePool limits as a cost ceiling)
NodePool limits는 NodePool이 프로비저닝할 수 있는 총 컴퓨팅 리소스에 하드 상한선을 설정해요. 한도에 도달하면 EKS Auto Mode는 해당 NodePool에 대해 새 노드를 시작하는 것을 멈춰요. 파드가 대기 중(pending)이더라도 그래요.
특히 무제한 확장이 적절하지 않은 비프로덕션, 테스트, 버스트성 워크로드를 서비스하는 NodePool에는 limits를 비용 가드레일로 사용해 주세요.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: ci-runners
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
limits:
cpu: "500"
memory: 1000Gi
이 예시에서 ci-runners NodePool은 프로비저닝하는 모든 노드 전체에서 500 vCPUs 또는 1000 GiB 메모리를 초과할 수 없어요. 이 한도를 초과하는 파드는 용량이 확보될 때까지 Pending 상태로 남아요.
팁 (Tip): 예상 최대 버스트 크기에 노드 교체용 버퍼를 더해
limits를 설정해 주세요. NodePool 활용도를 정기적으로 검토하고 워크로드 패턴이 바뀌면 한도를 조정해 주세요.
비용 제어를 위해 인스턴스 패밀리 제외하기 (Exclude instance families for cost control)
기본적으로 EKS Auto Mode는 스케줄링 유연성을 최대화하기 위해 광범위한 인스턴스 유형에서 선택해요. 특수 하드웨어가 필요 없는 워크로드의 경우 비싼 인스턴스 유형이 시작되지 않도록 인스턴스 패밀리를 제한해 주세요.
가속화 인스턴스 제외하기 (Exclude accelerated instances)
워크로드가 GPU나 액셀러레이터 리소스를 요청하지 않으면 NodePool에서 가속화 인스턴스 패밀리를 제외해 주세요. 이렇게 하면 용량 제약 중에 가속화 인스턴스가 선택되는 시나리오를 방지할 수 있어요.
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
컴퓨트 최적화, 범용, 메모리 최적화 카테고리만 지정하면 가속화(P, G, Inf, Trn) 및 기타 특수 인스턴스 패밀리를 선택에서 제외할 수 있어요.
인스턴스 선택이 용량 제약과 상호작용하는 방법 (How instance selection interacts with capacity constraints)
EKS Auto Mode는 일반 인스턴스 선택 중에 가속화 및 이국적인 인스턴스 유형을 우선순위에서 내려요. 하지만 지속적인 시작 실패가 발생하면 워크로드 가용성을 우선시하기 위해 남은 사용 가능한 인스턴스 유형 중 아무거나 시작해요. 예를 들어 일부 선호 인스턴스 유형의 EC2 서비스 할당량이 일시적으로 소진됐을 때 그렇죠.
이런 폴백 동작을 방지하려면 NodePool 요구 사항을 워크로드에 필요한 인스턴스 카테고리로만 명시적으로 제약해 주세요. 선호 유형을 사용할 수 없고 NodePool 구성이 다른 유형도 허용하지 않으면 파드는 비싼 인스턴스에 스케줄링되는 대신 Pending 상태로 남아요.
인스턴스 크기 제한하기 (Constrain instance sizes)
인스턴스 패밀리를 제한하는 것 외에도 NodePool 내 최대 인스턴스 크기를 제한할 수 있어요. 인스턴스 크기를 제약하면 통합할 수 없는 단일 노드의 비용 노출을 제한할 수 있어요. 예를 들어 do-not-disrupt 어노테이션으로 차단된 노드는 워크로드가 작아도 줄어들 수 없어요.
NodePool 요구 사항에서 eks.amazonaws.com/instance-cpu 라벨로 최대 인스턴스 크기를 제한해 주세요:
requirements:
- key: "eks.amazonaws.com/instance-cpu"
operator: Lte
values: ["32"]
이 구성은 EKS Auto Mode가 이 NodePool에서 32 vCPUs보다 큰 인스턴스를 시작하지 못하게 해요.
기존 클러스터의 최적화 기회를 식별하려면 가장 큰 실행 중인 인스턴스를 검토해 주세요. 대형 노드가 지속적으로 통합에서 차단되면 그 유휴 용량의 노드당 비용은 비례적으로 더 높아져요.
버스트성 워크로드를 위한 권장 패턴 (Recommended patterns for bursty workloads)
CI/CD 파이프라인, 배치 작업, 임시 러너는 버스트와 유휴 패턴을 만들어 비용 효율을 유지하려면 특정 구성이 필요해요.
버스트성 워크로드의 권장 기본값 (Recommended defaults for bursty workloads)
| 구성 | 권장 사항 |
|---|---|
do-not-disrupt |
CI/CD 러너에는 사용하지 마세요. 대신 CI 시스템의 재시도 및 큐 메커니즘에 의존하세요. |
NodePool limits |
예상 최대 동시성에 노드 교체 오버랩용 버퍼를 더해 CPU/메모리 상한을 설정하세요. |
| 인스턴스 카테고리 | c와 m 패밀리로 제한하세요. 비-GPU 워크로드에는 가속화 인스턴스 패밀리(P, G, Inf, Trn)를 제외하세요. |
| 인스턴스 크기 | 중간 크기(예: 4–32 vCPUs)로 제한해 통합에서 차단되는 단일 노드의 비용 노출을 줄이는 걸 고려하세요. |
| 통합 타이밍 | 기본 consolidateAfter 설정을 사용하세요. 러너 완료 후 버스트 용량을 계속 온라인 상태로 두는 긴 지연은 피하세요. |
| 용량 유형 | 내결함성이 있는 러너에는 Spot 인스턴스를 사용하세요. 실행 중 상태를 유지하는 빌드 에이전트에는 온디맨드와 결합하세요. |
예시: CI 러너 NodePool (Example: CI runner NodePool)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: ci-runners
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: Lte
values: ["32"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
limits:
cpu: "500"
memory: 1000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 30s
이 구성은:
- 비용 효율적인 인스턴스 패밀리로 제한해요.
- 총 NodePool 용량을 500 vCPUs로 제한해요.
- 적극적인 통합(파드 제거 후 30초)을 허용해요.
- Spot과 온디맨드 용량을 모두 허용해요.
노드 수명과 비용 (Node lifecycle and cost)
EKS Auto Mode는 노드가 원하는 사양에서 벗어날 때(예: 새 Auto Mode AMI 릴리스 후)나 노드 수명이 만료에 가까워질 때 정상 중단(graceful disruption)으로 노드를 교체해요. 정상 교체 중에는:
- 새 교체 노드가 시작되어 준비 상태가 돼요.
- Pod Disruption Budgets를 존중하며 구 노드에서 파드가 드레이닝돼요.
- 잠시 동안 구 노드와 교체 노드가 동시에 실행돼요.
크거나 많은 노드가 있는 클러스터에서는 이 오버랩이 주기적인 비용 증가를 만들 수 있어요. 영향을 최소화하려면:
- 중단 예산 검토 (Review disruption budgets) — 중단 예산이 시기적절한 드레이닝을 허용하는지 확인해 주세요. 제한적인 예산은 구 노드와 새 노드가 동시에 실행되는 오버랩 기간을 늘려요.
- 인스턴스 적정 규모 조정 (Right-size instances) — 더 작은 인스턴스는 오버랩 창의 절대 비용을 줄여요.
- 최대 노드 수명 줄이기 (Reduce maximum node lifetime) — 더 짧은 만료 값(예: 7일)은 더 빈번하지만 더 작은 교체 이벤트를 만들어요. 이렇게 하면 비용이 한 번에 집중되는 대신 시간에 걸쳐 더 고르게 분산돼요.
노드 수명에 대한 자세한 내용은 Learn about Amazon EKS Auto Mode Managed instances를 참고해 주세요.