EKS Node Group 설계 가이드 - On-Demand, Spot, 시스템 워크로드를 어떻게 나눌까

EKS 비용과 안정성은 Node Group 설계에서 갈린다

EKS를 처음 운영할 때 흔한 패턴은 노드 그룹 하나에 모든 워크로드를 올리는 것입니다.

하지만 서비스가 커지면 문제가 생깁니다.

시스템 파드와 앱 파드가 자원 경쟁
Spot 중단 영향이 전체로 퍼짐
비용 절감과 안정성 요구를 동시에 맞추기 어려움

Node Group은 단순 인프라 구성이 아니라 운영 정책의 일부입니다.

system node group은 왜 따로 두는가

클러스터 필수 컴포넌트는 안정성이 가장 중요합니다.

시스템 컴포넌트를 앱 노드와 섞으면:

앱 spike로 인한 자원 경쟁
대규모 배포 시 eviction 증가
Spot 노드 중단 시 클러스터 핵심 기능 영향

따라서 system용 On-Demand 그룹을 별도로 두는 편이 좋습니다.

예시:

nodeSelector:
  workload: system

tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "system"
    effect: "NoSchedule"

Spot 노드는 어디에 써야 하나

Spot은 비용 절감 효과가 크지만 중단 가능성이 있습니다.

적합한 워크로드:

queue 기반 worker
batch
stateless background job
재시작 허용 가능한 inference worker

부적합한 워크로드:

ingress
stateful 핵심 API
cluster 필수 시스템 컴포넌트

즉, Spot은 “싼 서버”가 아니라 “중단을 견딜 수 있는 워크로드”에만 써야 합니다.

taint / label은 어떻게 나눌까

Node Group 분리를 실제 스케줄링에 반영하려면 label과 taint를 같이 써야 합니다.

예:

system-ng
- label: workload=system
- taint: dedicated=system:NoSchedule

spot-ng
- label: lifecycle=spot
- taint: spot=true:NoSchedule

그리고 워크로드에 맞는 toleration을 부여합니다.

tolerations:
  - key: "spot"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

이런 구조가 있어야 의도하지 않은 파드 배치가 줄어듭니다.

인스턴스 타입은 어떻게 고를까

노드 그룹별로 기준이 다릅니다.

system-ng

소수의 안정적인 On-Demand
메모리/CPU 과도하지 않게

app-ng

서비스 특성에 맞는 범용/메모리 최적화
예측 가능한 확장

spot-ng

여러 instance family 혼합
capacity-optimized 전략

Spot에서는 인스턴스 타입을 다양하게 섞는 것이 중요합니다. 그래야 중단 리스크와 스케줄링 실패를 줄일 수 있습니다.

autoscaling과 같이 봐야 한다

Node Group 설계는 Cluster Autoscaler나 Karpenter 전략과도 연결됩니다.

봐야 할 것:

min/max node
scale up 속도
spot replacement
pod disruption budget

예를 들어 batch가 몰릴 때 app-ng까지 같이 커지면 비용 구조가 깨질 수 있습니다.

흔한 실수

1. 모든 워크로드를 하나의 노드 그룹에 배치

운영은 단순해 보이지만, 장애 격리와 비용 최적화가 어려워집니다.

2. Spot에 ingress까지 올림

중단 시 외부 트래픽 진입점까지 흔들릴 수 있습니다.

3. taint 없이 label만 사용

의도치 않은 파드가 배치될 가능성이 남습니다.

마무리

EKS Node Group 설계의 핵심은 인스턴스를 나누는 것이 아니라 워크로드 성격을 분리하는 것입니다.

시스템, 일반 서비스, 비용 민감 워커를 나누고 각자에 맞는 label, taint, autoscaling 정책을 붙이면 비용과 안정성을 함께 잡을 수 있습니다.