스팟(Spot) 인스턴스로 비용 효율적으로 서버 운영하기 [HPA + Karpenter]

우리는 AWS EKS 환경에서 백엔드 서버를 운영하고 있다.

트래픽은 꾸준히 증가하고 있고, 서비스 개발 사이클도 빨라서 하루에도 여러 차례 배포가 이루어진다. 이런 환경에서는 안정적인 인프라 구성과 동시에 비용 최적화가 중요한 과제로 떠오른다.

이번 글에서는 우리가 실제로 운영하고 있는 Spot 인스턴스 기반의 비용 절감 전략과 EKS에서 이를 안정적으로 활용하는 방법을 정리해보았다.

시작에 앞서, 우리 클러스터 인프라는 아래 원칙에 맞추어 배포를 하고 있다.

1. 기본 원칙: 한 노드에는 Pod 하나만
우리는 백엔드 서버 특성상 한 노드에 Pod 1개 배치(one-pod-per-node) 를 원칙으로 한다.

이 전략은 다음과 같은 장점이 있다.

노드 하나가 죽어도 영향 범위가 명확함
Pod 간 리소스 경합 없음 (CPU/메모리 스로틀링 방지)
디버깅 및 장애 분석이 쉬움
노드 스케일아웃이 직관적으로 트래픽과 연결됨

대신 서버 트래픽에 맞는 인스턴스 타입을 골라, 최대한 인스턴스 스펙에 맞게 백엔드 Pod을 운영하려고 하였다.

2. 백엔드 서버는 최소 3개 운영한다
단일 서버(또는 노드)로 백엔드를 운영하는 것은 매우 위험하다.
 따라서 우리는 최소 한 서버 당 3개 Pod 구성을 기본값으로 운영한다.

1개 노드 장애 → 서비스 영향 없음
1개 노드 교체 중이어도 안정적
Rolling Update 시에도 유저 영향 최소화

EKS 환경에서는 이 3개 노드가 모두 동일하게 로드밸런서 뒤에서 트래픽을 받기 때문에 실 운영에서도 부하가 자연스럽게 분산된다.

하지만 한 서버 당 노드를 3개 운영할 때 모두 온디맨드(On-Demand) 로 사용하면 비용이 상당히 부담된다.

따라서 우리는 온디맨드 인스턴스와 스팟 인스턴스를 함께 사용해서 비용 효율적으로 운영하고 있다.

가격은 예약 인스턴스(Reserved Instance)가 가장 저렴한데, 서비스의 성장을 고려해서 예약 인스턴스는 고려 대상에서 제외하였다.

스팟 인스턴스는 보통 온디맨드 인스턴스의 30%-60% 정도 되는 가격으로 쓸 수 있는데, 그러면 모든 Pod를 스팟 인스턴스에 띄우면 되지 않나?

하지만 스팟 인스턴스는 언제든지 꺼질 수 있기 때문에, 모든 Pod을 스팟 인스턴스에 띄우는 것은 매우 위험한 선택이다.
타이밍이 안 맞아 동시에 특정 백엔드 서비스 노드가 다 꺼지면 서비스가 중단될 수도 있기 때문이다.

따라서 서비스 안정성을 위해 항상 돌아가는 온디맨드 인스턴스 1개, 나머지는 모두 스팟 인스턴스로 띄우는 전략을 선택했다.

t4g.medium 인스턴스 기준 우리가 운영했던 us-west-1 리전에서 3개 모두 온디맨드를 썼을 때와 온디맨드 인스턴스 1개, 스팟 인스턴스 2개로 돌렸을 때 비용을 계산해보자.

t4g.medium의 가격 정책은 아래와 같다. (us-west-1 기준)

온디맨드 인스턴스의 경우 시간 당 $0.04
스팟 인스턴스의 경우 시간 당 $0.016

모두 온디맨드
$0.04 * 24 * 30 * 3 = 약 $86.4
온디맨드 1개, 스팟 2개
($0.04 + $0.016 * 2) * 24 * 30 = $51.84

따라서 전부 온디맨드 인스턴스로 운영할 때의 60%의 가격으로 서버를 운영할 수 있게 된다.

하지만 Spot 인스턴스는 언제든지 AWS가 회수할 수 있다는 단점이 있다. 그러나 우리는 Karpenter + Helm Spot Termination Handler 조합을 통해 이를 안정적으로 처리한다.

Spot Termination Handler의 핵심 역할

AWS가 Spot 노드 종료를 2분 전에 알림(termination notice)
이 이벤트를 감지해:

해당 노드를 cordon (스케줄링 불가)
기존 Pod를 다른 노드로 drain (옮기기)
Karpenter가 새로운 노드를 즉시 프로비저닝

즉, Spot 노드가 종료되더라도 Pod는 다른 노드로 빠르게 옮겨가고, 새로운 Spot 노드가 자동 생성되어 서비스에는 영향이 없다.

실제로 운영하면서, Spot 종료 이벤트가 오더라도 유저 단에서의 장애는 한 번도 발생하지 않았다.

트래픽 증가 시 Pod · Node 자동 확장 (HPA + Karpenter)

트래픽이 증가하면 서버가 자동으로 확장되어야 한다. 우리 시스템은 다음과 같은 구조로 구성되어 있다:

HPA (Horizontal Pod Autoscaler) → Pod 자동 증가
Karpenter → Pod 스케줄링이 부족하면 노드를 자동 증설

즉 부하가 오면,

HPA가 Pod 수를 늘림
Pod가 배치될 자리가 없으면 Karpenter가 새 노드를 생성
노드가 준비되면 자연스럽게 Pending 상태인 Pod가 배치

이 부분은 내용이 길어져서, 별도의 글에서 따로 다루기로 한다.

Spot 인스턴스는 인스턴스 타입에 따라 할인율이 다르고, 최대 70%까지도 할인이 되기 때문에 다중 Pod 환경에서는 비용 절감을 위해 반드시 도입해야 한다고 생각한다.

심지어는 GPU가 있는 인스턴스도 Spot 인스턴스를 쓸 수 있기 떄문에 AI를 직접 서빙해야 한다면 선택이 아닌 필수가 될 것이다.

참고로, GPU 인스턴스의 프로비저닝은 AWS에 요청을 해서 권한을 얻어내야 한다. 기억으로는 용도 등을 명시해서 AWS 측에 문의를 해야 한다.

우리가 실제 EKS 운영에서 경험한 결론은 다음과 같다.

Spot은 잘만 운영하면 안정성을 해치지 않는다
On-Demand + Spot 혼합 전략이 가장 현실적인 비용 최적화 전략
Spot Termination Handler 도입 시 장애 없이 안정적
Karpenter와 함께 쓰면 자동화 수준이 매우 높다

특히 머신 러닝 추론 서버, 웹 백엔드, API 서버 등 상태가 없는(Stateless) 워크로드라면 Spot 활용이 매우 쉽고 효율적이다.
지금도 우리는 다음과 같은 목표를 유지하며 운영 중이다:

안정성은 On-Demand로 지원
비용 절감은 Spot으로 해결
자동화는 Karpenter로 극대화

결과적으로, Spot 전략은 단순한 비용 절감이 아니라 구조적 효율성을 가져다주는 중요한 요소가 되었다.

Spot 인스턴스를 활용한 EKS 운영 전략은 단순히 비용을 줄이기 위한 전략이 아니라, 우리가 실제 서비스 운영 환경에서 안정성과 효율성을 동시에 확보하기 위해 선택한 구조적 접근이다.

한 노드에 하나의 Pod만 배치하는 운영 방식은 장애 범위를 최소화하여 서비스 신뢰도를 높였고, On-Demand와 Spot을 혼합한 노드 구성은 핵심 트래픽을 안정적으로 처리하면서도 전체 인프라 비용을 크게 절감하는 데 기여했다.

여기에 Spot Termination Handler와 Karpenter를 결합함으로써, 예측 불가능한 Spot 회수 이벤트조차도 서비스 영향 없이 자연스럽게 처리할 수 있는 수준의 자동화를 갖추게 되었다.

트래픽 변화에 따라 Pod과 노드가 자동으로 확장되는 구조까지 더해지면, 우리는 더 이상 서버 한 대에 의존하는 불안한 운영을 하지 않아도 되고, 필요할 때 필요한 만큼 유연하게 리소스를 사용할 수 있다.

결국 이러한 아키텍처 선택들은 우리 서비스가 성장함에 따라 발생하는 부담을 줄여주었고, 더 안정적인 사용자 경험을 제공하는 데 직접적인 기반이 되었다.