Job 워크로드를 위한 EKS Node Group 오토스케일링 도입기 (2026-04)

고정 크기 Job 노드 그룹의 한계

당근의 Job용 Node Group은 고정 크기여서 한가할 때는 비용을 낭비하고, Job이 몰리면 시작이 늦어졌습니다. Server용과 Job용 Node Group을 나눈 것도 실행 중인 Job을 지키기 위해서였습니다. Job은 중단하면 처음부터 다시 실행해야 하고, 1시간 넘게 걸리는 Job도 있어 scale-in 때 노드를 자유롭게 지울 수 없었습니다. 여유 노드를 넉넉히 두고 수동으로 수를 조정하는 부담이 남았습니다.

Pod를 모으고 집중 부하를 제어한 방법

당근은 Job Pod를 소수 노드에 모으는 bin-packing을 선택했습니다. Volcano, YuniKorn, 기본 스케줄러의 MostAllocated 전략을 검토했으나 별도 스케줄러 운영 부담 때문에 채택하지 않았습니다. 대신 같은 Pod가 많은 노드의 점수를 높이는 preferred PodAffinity(weight 100, topologyKey는 hostname)를 적용했습니다. 라벨과 affinity는 Kyverno가 Argo Workflow 소유 Pod에 일괄로 넣는 방식입니다.

노드 축소 때 Job을 보호하는 어노테이션도 같은 방식으로 넣습니다. Cluster Autoscaler에는 safe-to-evict: "false", Karpenter에는 karpenter.sh/do-not-disrupt: "true"를 붙입니다.

Alpha에서는 잘 동작했지만 Production에서는 10분 단위, 특히 정시에 몰리는 Job이 소수 노드에 부하를 집중시켰습니다. 당근이 병목별로 적용한 조치는 다음과 같습니다.

• kubelet 과부하: Job의 CPU request가 실제보다 작아 Pod가 과하게 배치됨. maxPods를 4xlarge 이상 기본값 234에서 Job 노드 60으로 낮춰 해결
• Image Pull 실패: kubelet의 registryPullQPS를 5에서 40으로, registryBurst를 10에서 60으로 상향
• EBS throttling: IOPS를 3,000에서 8,000으로, throughput을 150MB/s에서 800MB/s로 증설
• CNI IP 할당 지연: Host Network Mode를 적용해 IP 할당 생략(Host Network 글 참고)

실행 시간과 운영 부담의 변화

저자는 노드 수를 지켜보며 수동 조정하던 부담이 사라진 점을 가장 큰 이득으로 꼽습니다.

• workflow Pod 평균 Pending 시간: 1.54초 → 0.78초, 약 49% 감소
• workflow Pod Running 시간: 138초 → 72.6초, 약 47% 감소
• job(amd64) 그룹 평균 노드 수: 5개 → 4.198개, 약 16% 감소

적용 범위는 CronJob, Airflow와 Dagster, GitHub Actions Runner 등 모든 Job 워크로드입니다.

Pod 밀도와 이미지 캐시에서 확인할 점

당근에서는 bin-packing으로 노드당 Pod 밀도가 높아지면서 kubelet, 레지스트리 QPS, EBS, CNI가 차례로 병목이 됐습니다. 정시 몰림은 Alpha에서 재현되지 않았고 Production에서 처음 확인한 문제입니다.

당근은 노드 교체가 잦아져 이미지 캐시가 줄어든 것을 Image Pull 시간 증가의 원인으로 봅니다. job에서는 3초에서 7.972초로 늘었습니다. 같은 저자의 Karpenter 발표는 영상 요약에 있습니다.