.png){kind=small}
안녕하세요. AWS 청구서를 볼 때마다 가장 큰 비중을 차지하는 EC2-Running-Hours 비용 때문에 한숨 쉬신 적 있나요?
비용을 줄이려면 약정(RI/Savings Plans)을 걸어야 하는데, 1~3년 약정은 부담스럽고 트래픽은 예측하기 어렵죠. 이때 우리의 구세주가 되어주는 것이 바로 스팟 인스턴스(Spot Instance)입니다.
"최대 90% 저렴하다"는 엄청난 장점이 있지만, “AWS가 필요하면 언제든 회수해 간다”는 치명적인 단점 때문에 도입을 망설이는 분들이 많습니다.
오늘은 이 '양날의 검'인 스팟 인스턴스를 프로덕션 환경에서도 안전하고 우아하게(Gracefully) 사용하는 아키텍처 전략을 A to Z로 정리해 드립니다.
1. 스팟 인스턴스, 도대체 왜 이렇게 쌀까?
AWS 데이터센터에는 수많은 물리 서버가 있습니다. 하지만 이 서버들이 24시간 100% 돌아가지는 않죠. 남는 잉여 자원(Spare Capacity)이 필연적으로 발생합니다.
AWS 입장에서는 이 서버들을 놀리느니 헐값에라도 빌려주는 게 이득입니다. 마치 호텔이 빈방을 당일 특가("땡처리")로 내놓는 것과 같습니다.
On-Demand (정가): 내가 원할 때 언제든 쓰고, 내가 끌 때까지 유지됨. (비쌈)
Spot Instance (할인가): 남는 자원을 쓰되, AWS가 "방 빼!" 하면 2분 안에 비워줘야 함. (최대 90% 저렴)
2. 공포의 "2분 경고" (Spot Instance Interruption Notice)
스팟 인스턴스를 쓸 때 가장 무서운 상황은 “서버가 갑자기 사라지는 것”입니다. 하지만 AWS는 최소한의 예의로 2분(120초)의 유예 시간을 줍니다.
이를 ITN (Instance Termination Notice)라고 부릅니다.
AWS가 신호를 보내는 방식
AWS가 해당 인스턴스를 회수하기로 결정하면, 인스턴스 내부의 메타데이터 서비스(IMDS)로 신호를 보냅니다.
URL: http://169.254.169.254/latest/meta-data/spot/instance-action
신호 내용: "2분 뒤에 종료(Terminate) 될 거야."
우리는 이 신호를 감지해서 2분 안에 짐을 싸서 도망가야(Draining) 합니다.
3. 전략 1: "계란을 한 바구니에 담지 마라" (Diversification)
스팟 인스턴스가 회수되는 이유는 **"해당 가용 영역(AZ)의 특정 인스턴스 타입 재고가 부족해서"**입니다. 예를 들어 ap-northeast-2a의 m5.large 재고가 동날 수 있습니다.
이때 우리가 m5.large만 고집하고 있었다면? 우리 서비스의 모든 서버가 동시에 죽을 수도 있습니다. 이를 방지하기 위해 **다양성(Diversification)**을 확보해야 합니다.
추천 설정: Mixed Instances Policy
Auto Scaling Group(ASG)이나 EC2 Fleet을 설정할 때 다음 전략을 사용하세요.
여러 가용 영역(Multi-AZ) 사용: A존이 부족해도 C존은 남을 수 있습니다.
여러 인스턴스 타입 혼용:
m5.large (2 vCPU, 8GB)
m5d.large (비슷한 스펙)
m4.large (구형이지만 스펙 비슷)
t3.large (버스트 가능)
위 4개를 후보군으로 등록해 두면, AWS가 "이 중에 재고가 넉넉하고 싼 걸로 알아서 골라서" 띄워줍니다. (Capacity-Optimized 전략)
4. 전략 2: "2분 안에 짐 싸기" (Graceful Shutdown)
AWS가 "나가!"라고 신호를 보냈을 때, 아무 조치도 안 하면 하던 작업이 날아가고 DB 연결이 비정상 종료되겠죠? 이를 방지하기 위해 자동화된 스크립트가 필요합니다.
AWS Node Termination Handler (NTH)
쿠버네티스(EKS)나 일반 EC2 환경에서 데몬으로 띄워두는 오픈소스 도구입니다.
감시: 계속해서 메타데이터 URL(169.254...)을 찌르면서 감시합니다.
감지: "어? 종료 신호(ITN)가 왔다!"
조치 (Cordon & Drain):
Cordon: 로드밸런서에게 "이 서버 이제 죽을 거니까, 새로운 트래픽 보내지 마"라고 알립니다.
Drain: 현재 처리 중인 요청(Request)이 끝날 때까지 기다리거나, 파드(Pod)를 다른 안전한 노드로 대피시킵니다.
종료: 2분이 지나거나 작업이 끝나면 인스턴스를 반납합니다.
5. 전략 3: "Karpenter와의 환상적인 궁합" (Game Changer)
EKS(쿠버네티스)를 쓰고 계신다면, Karpenter는 스팟 인스턴스 운영의 혁명과도 같습니다. 기존 Cluster Autoscaler(CA)보다 훨씬 빠르고 똑똑하게 대처합니다.
Karpenter가 스팟을 다루는 방식
Karpenter는 AWS EventBridge와 연동하여 중단 신호를 거의 실시간(수 밀리초)으로 감지합니다.
선제적 대응: "이 노드 2분 뒤에 죽는다"는 신호를 받자마자, Karpenter는 즉시 새로운 대체 노드(Spot)를 띄우기 시작합니다.
빠른 합류: 기존 노드가 죽기 전에 새 노드가 준비될 확률이 높습니다. (Just-in-Time)
Spot-to-Spot Consolidation (비용 최적화):
Karpenter는 심지어 중단 신호가 없어도, **"지금 쓰고 있는 스팟보다 더 싼 스팟 인스턴스 재고가 나왔네?"**라고 판단되면,
실행 중인 파드를 그쪽으로 옮겨서 비용을 더 깎아버립니다. (적극적인 비용 절감)
6. 어떤 워크로드에 써야 할까?
스팟 인스턴스가 90% 싸다고 해서 DB 서버에 쓰면 절대 안 됩니다. (데이터 날아갑니다!)
✅ 강력 추천 (Best Fit)
무상태(Stateless) 웹 서버: 웹/앱 API 서버, 프론트엔드 서버. (서버가 죽어도 다른 서버가 요청을 받으면 되는 구조)
CI/CD 파이프라인: Jenkins Agent, GitHub Actions Runner. (빌드하다가 죽으면 다시 돌리면 됨)
배치(Batch) 및 데이터 분석: 대용량 로그 처리, 이미지 렌더링, 동영상 인코딩.
AI/ML 학습: 모델 학습 (Checkpoint 기능으로 중간 저장 필수).
EKS 노드: Karpenter와 함께라면 운영계(Production) 워커 노드도 충분히 가능!
❌ 비추천 (Don't Do This)
데이터베이스 (RDBMS): RDS, MySQL, Redis 등. (데이터 유실 및 정합성 깨짐)
단일 서버 어플리케이션: 서버가 1대뿐인데 스팟으로 돌리면 서비스 장애 직행입니다.
배포 시간이 2분 넘게 걸리는 앱: 서버 뜨는 데 10분 걸리는데, 2분 만에 나가라고 하면 대처 불가능합니다.
마치며
"스팟 인스턴스는 '위험한' 것이 아니라 '관리해야 할' 리소스입니다."
처음에는 개발(Dev) 환경의 EKS 노드 그룹부터 스팟으로 바꿔보세요. 비용이 획기적으로 줄어드는 것을 볼 수 있습니다. 그 다음 Mixed Instances Policy와 Karpenter 같은 안전장치를 마련한 뒤, 운영(Prod) 환경의 Stateless 서버까지 확장해 보세요.
여러분의 AWS 청구서 앞자리가 바뀌는 기적을 경험하실 수 있을 겁니다.
