[Cloud] Spot Instance 활용 극대화: 비용 절감과 안정성 확보 전략

목차

• 1. 왜 Spot Instance 활용 전략이 중요한가
• 2. Spot Instance 개념 설명: 쉽게 말해 어떤 자원인가
• 3. 어떤 워크로드에 Spot을 붙여야 하나
• 잘 맞는 경우
• 조심해야 하는 경우
• 4. 실전 구현 1: Auto Scaling으로 Spot과 On-Demand 섞어 쓰기
• 5. 실전 구현 2: Spot 종료 신호 처리와 안전한 Drain
• 6. ⚠️ 주의사항과 트러블슈팅: 제가 실제로 많이 부딪힌 문제
• 문제 1. 로컬 디스크에 상태를 저장했다가 데이터 유실
• 문제 2. Spot 비율을 너무 높게 잡아서 회수 이벤트 때 동시 흔들림
• 문제 3. 특정 인스턴스 패밀리만 고집
• 문제 4. 모니터링 없이 비용만 봄
• 7. 검증과 결과: 무엇을 확인해야 성공인가
• 8. 정리와 FAQ: 비용 절감과 안정성 확보, 둘 다 잡으려면
• 자주 묻는 질문

[클라우드] Spot Instance 활용 전략: 비용 절감과 안정성 확보

Spot Instance 활용 전략은 클라우드 비용 절감을 고민하는 팀이라면 한 번쯤은 반드시 붙잡게 되는 주제입니다. 온디맨드(On-Demand, 필요 시 즉시 쓰는 기본 과금 방식)만으로 운영하면 편하긴 한데, 배치 작업이 늘고 개발 환경이 많아질수록 월말 청구서가 꽤 아프거든요. 저도 홈랩이랑 실제 운영 환경에서 비슷한 고민을 오래 했었습니다. 처음엔 "싸면 좋은 거 아닌가?" 하고 덤볐다가, 중간에 인스턴스가 회수(eviction, 클라우드 제공자가 자원을 다시 가져감)되면서 삽질 좀 했습니다 ㅎㅎ 그런데 구조를 조금만 바꾸니까, 비용 절감과 가용성 관리 두 마리 토끼를 꽤 안정적으로 잡을 수 있더라고요.

이번 글에서는 특정 신제품이나 불확실한 기능 얘기 말고, 이미 널리 알려진 Spot 개념과 검증된 운영 패턴 위주로 정리해보겠습니다. 특히 클라우드 비용 절감, 탄력적 컴퓨팅, 가용성 관리 관점에서 어떤 워크로드에 Spot을 붙여야 하는지, 어디서 사고가 나는지, 그리고 어떻게 안전장치를 걸어야 하는지를 경험 기반으로 풀어볼게요.

Spot Instance와 On-Demand, Auto Scaling, 작업 큐, 모니터링이 연결된 전체 구성 예시입니다.

1. 왜 Spot Instance 활용 전략이 중요한가

쉽게 말해 Spot Instance는 "남는 자원을 할인해서 쓰는 방식"입니다. 다만 조건이 있죠. 클라우드 사업자가 해당 자원이 다시 필요해지면 인스턴스를 종료할 수 있습니다. 이 특징 때문에 아무 데나 넣으면 안 되고, 중단을 감당할 수 있는 구조에 넣어야 합니다.

제가 직접 해보니, Spot은 단순히 인스턴스 타입 하나 바꿔서 끝나는 문제가 아니었습니다. 워크로드 분리, 상태 저장 위치, 종료 신호 처리, 용량 분산, 모니터링까지 같이 가야 비로소 전략이 되더라고요. 여기서 중요한 포인트는 딱 하나입니다. Spot을 믿지 말고, 시스템 설계를 믿어야 합니다.

• 비용에 민감한 배치(Batch, 일괄 처리) 작업에 유리합니다.
• 수평 확장(Horizontal Scaling, 인스턴스를 여러 대 늘리는 방식) 구조와 잘 맞습니다.
• 상태 비저장(Stateless, 개별 서버에 중요한 상태를 남기지 않는 구조) 서비스에서 특히 강합니다.
• 반대로 단일 노드 데이터베이스처럼 중단을 허용하기 어려운 워크로드에는 정말 조심해야 해요.

2. Spot Instance 개념 설명: 쉽게 말해 어떤 자원인가

Spot Instance는 할인 폭이 큰 대신, 언제든 회수될 수 있는 가변 자원입니다. AWS에서는 EC2 Spot Instances가 대표적이고, 다른 클라우드에도 비슷한 개념이 있습니다. 이름은 조금씩 달라도 핵심은 같습니다. 싸지만 보장되지 않는 자원입니다.

저도 처음엔 헷갈렸는데, 아래처럼 구분하면 훨씬 이해가 잘 돼요.

구분	On-Demand	Reserved/Savings 계열	Spot
비용	기본	장기 약정 시 절감	높은 할인 가능
가용성	높음	높음	회수 가능성 있음
적합한 워크로드	핵심 서비스	예측 가능한 상시 부하	배치, CI, 렌더링, 워커
운영 난이도	낮음	중간	높음

Spot Instance 활용 전략의 핵심은 "Spot만 쓰겠다"가 아니라, 기본 용량은 안정적인 방식으로 확보하고, 변동 용량만 Spot으로 가져가는 것입니다. 이 조합이 실제로 가장 덜 아픕니다.

3. 어떤 워크로드에 Spot을 붙여야 하나

여기서 방향을 잘못 잡으면 비용은 줄었는데 장애 대응 시간만 늘어납니다. 실제로 써보니까 아래 기준이 꽤 명확했습니다.

잘 맞는 경우

• 큐(Queue, 작업 대기열) 기반 워커
• CI 빌드 에이전트
• 로그 처리, 이미지 변환, 데이터 분석 배치
• 오토스케일링이 잘 되는 웹 애플리케이션의 일부 용량
• 개발/테스트 환경

조심해야 하는 경우

• 단일 인스턴스 데이터베이스
• 세션(Session, 사용자 상태)이 로컬 메모리에 강하게 묶인 서비스
• 종료 전 정리 시간이 거의 없는 실시간 처리
• 라이선스나 초기화 시간이 긴 상용 소프트웨어

혹시 이런 경험 있으신가요? CPU는 넉넉한데 서버 비용이 계속 오르는 상황이요. 그런 경우 대부분은 피크 부하 대응용 여유분이 상시 켜져 있는 패턴이 많습니다. 이런 부분을 Spot으로 치환하면 효과가 잘 납니다. 대신 핵심 트래픽 바닥 용량(base capacity)은 On-Demand나 예약형으로 두는 게 안전합니다.

4. 실전 구현 1: Auto Scaling으로 Spot과 On-Demand 섞어 쓰기

실전에서는 혼합 운영이 기본입니다. 예를 들어 웹 워커 풀(worker pool)을 10대로 운영한다고 치면, 최소 3대는 On-Demand로 깔고 나머지 7대는 Spot으로 채우는 식이죠. 이렇게 하면 Spot 회수가 와도 서비스 전체가 바로 흔들리지는 않습니다.

1. 서비스를 상태 비저장으로 정리합니다. 세션은 Redis 같은 외부 저장소로 뺍니다.
2. Auto Scaling Group을 구성합니다.
3. 기본 용량은 On-Demand로 확보합니다.
4. 추가 확장분은 여러 인스턴스 타입의 Spot으로 분산합니다.
5. 로드 밸런서와 헬스 체크를 연결합니다.

아래 예시는 개념 전달용 설정 예시입니다. 핵심은 여러 타입, 여러 가용 영역, 혼합 용량입니다.

spot_strategy:
  base_on_demand_capacity: 3
  desired_capacity: 10
  spot_pools:
    - c6i.large
    - c5.large
    - m6i.large
    - m5.large
  availability_zones:
    - ap-northeast-2a
    - ap-northeast-2c
  allocation_strategy: capacity-optimized

제가 처음에 했던 실수는 인스턴스 타입을 하나만 넣은 겁니다. 그랬더니 특정 타입 수급이 불안정할 때 대체가 안 되더라고요. 반면 타입과 가용 영역을 넓혀두면 Spot 회수 이벤트가 와도 전체 풀은 훨씬 덜 흔들립니다. 탄력적 컴퓨팅은 결국 선택지를 많이 주는 설계에서 나옵니다.

aws ec2 create-launch-template \
  --launch-template-name web-spot-template \
  --launch-template-data '{
    "ImageId":"ami-xxxxxxxx",
    "InstanceType":"m5.large",
    "SecurityGroupIds":["sg-xxxxxxxx"],
    "IamInstanceProfile":{"Name":"ec2-app-role"}
  }'

실무에서는 이걸 Terraform이나 CloudFormation 같은 IaC(Infrastructure as Code, 코드형 인프라)로 관리하는 편이 더 낫습니다. 사람이 콘솔에서 몇 번 누르다 보면 언젠가 drift(설정 불일치)가 생기거든요.

기본 용량은 On-Demand로 유지하고, 확장분을 여러 Spot 풀로 분산하는 구성 예시입니다.

5. 실전 구현 2: Spot 종료 신호 처리와 안전한 Drain

Spot을 오래 쓰려면 종료 신호를 꼭 다뤄야 합니다. AWS의 경우 Spot interruption notice(중단 예고 알림)를 메타데이터에서 확인할 수 있는 패턴이 널리 알려져 있습니다. 이 신호를 감지하면 인스턴스는 새 작업을 받지 않고, 처리 중인 작업을 정리한 뒤 빠지도록 만들어야 합니다.

특히 큐 기반 워커에서는 효과가 큽니다. 작업을 꺼내기 전에 락(lock)이나 가시성 타임아웃(visibility timeout)을 잘 설정해두면, 종료 중인 노드가 빠져도 다른 워커가 이어받을 수 있거든요. 이거 진짜 편하더라고요.

#!/usr/bin/env bash
set -euo pipefail

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

while true; do
  ACTION=$(curl -sf -H "X-aws-ec2-metadata-token: ${TOKEN}" \
    http://169.254.169.254/latest/meta-data/spot/instance-action || true)

  if [ -n "${ACTION}" ]; then
    echo "Spot interruption detected: ${ACTION}"
    touch /tmp/stop-accepting-jobs
    systemctl stop my-worker.service
    sleep 20
    shutdown -h now
  fi

  sleep 5
done

웹 서비스라면 로드 밸런서에서 먼저 빼고, 워커라면 큐 소비를 중단하는 식으로 접근하시면 됩니다. 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션)를 쓰는 분들은 노드 축출(eviction)과 파드 재스케줄링 쪽도 함께 봐야 하고요. 이 부분은 다음 글에서 따로 다뤄볼 예정입니다.

if [ -f /tmp/stop-accepting-jobs ]; then
  echo "Node is draining. Skip new job fetch."
  exit 0
fi

여기서 중요한 포인트! 작업을 중간에 잃어버리지 않도록 재시도 가능(idempotent, 여러 번 실행돼도 결과가 꼬이지 않는)하게 만드는 것이 Spot 운영의 핵심입니다.

6. ⚠️ 주의사항과 트러블슈팅: 제가 실제로 많이 부딪힌 문제

Spot은 싸지만, 운영 습관이 잘못 잡혀 있으면 바로 티가 납니다. 아래는 제가 직접 해보니 자주 터졌던 문제들입니다.

문제 1. 로컬 디스크에 상태를 저장했다가 데이터 유실

처음엔 캐시 파일 정도는 괜찮겠지 했었는데, 재시작 시 복구 시간이 길어져서 결국 더 느려졌습니다. 해결은 단순했습니다. 중요한 상태는 오브젝트 스토리지(Object Storage, 객체 저장소)나 DB, 공유 스토리지로 빼고, 인스턴스는 최대한 가볍게 만들었습니다.

문제 2. Spot 비율을 너무 높게 잡아서 회수 이벤트 때 동시 흔들림

비용 욕심이 과하면 바로 대가를 치릅니다. 핵심 서비스는 최소한의 On-Demand 바닥 용량을 두세요. 저는 초기에 거의 전부 Spot으로 돌렸다가 특정 시간대에 용량 확보가 안 되면서 식은땀 좀 났습니다.

문제 3. 특정 인스턴스 패밀리만 고집

컴퓨트 최적화(Compute Optimized)만, 또는 메모리 최적화(Memory Optimized)만 고집하면 대체 폭이 줄어듭니다. 애플리케이션이 허용한다면 비슷한 스펙 계열을 넓게 열어두는 편이 훨씬 안정적입니다.

문제 4. 모니터링 없이 비용만 봄

클라우드 비용 절감만 보면 반쪽짜리입니다. 회수 횟수, 재시작 빈도, 작업 실패율, 평균 처리 시간, 큐 적체량도 같이 봐야 합니다. 비용은 내려갔는데 SLA(Service Level Agreement, 서비스 수준 목표)가 망가지면 의미가 없거든요.

• 권장 메트릭: 인스턴스 교체 횟수, 헬스 체크 실패율, 평균 대기 시간, 작업 재시도 횟수
• 권장 로그: 종료 예고 감지 시점, drain 시작/종료 시점, 작업 재할당 기록
• 권장 알람: 원하는 용량 미달, 큐 적체 급증, 에러율 상승

7. 검증과 결과: 무엇을 확인해야 성공인가

Spot을 붙이고 나면 "청구서가 줄었다"만 보면 안 됩니다. 저는 보통 아래 3가지를 같이 확인합니다.

1. 월별 또는 주별 인프라 비용 추이
2. 장애나 성능 저하 없이 목표 처리량을 유지했는지
3. 회수 이벤트가 와도 자동 복구가 되는지

가장 쉬운 검증 방법은 작은 워커 풀부터 시작하는 겁니다. 예를 들어 전체 20대 중 2대만 Spot으로 시작해보세요. 그다음 20%, 40%, 60% 식으로 천천히 올리면서 실패율과 큐 적체를 같이 봅니다. 실제로 써보니까 한 번에 크게 바꾸는 것보다 이 방식이 훨씬 덜 아픕니다.

검증 항목	확인 포인트	성공 기준 예시
비용	Spot 도입 전후 비교	유의미한 절감 추세 확인
안정성	회수 시 자동 복구 여부	수동 개입 최소화
성능	처리량, 지연 시간	기존 목표 유지
운영성	알람, 로그, 런북	장애 대응 절차 정립

비용 절감 효과와 함께 작업 성공률, 재시도 횟수, 큐 적체량을 함께 보는 검증 화면 예시입니다.

🎉 잘 설계된 Spot Instance 활용 전략은 비용만 줄이는 게 아니라, 오히려 아키텍처를 더 탄탄하게 만드는 계기가 되기도 합니다. 중단을 전제로 설계하다 보니 시스템이 전반적으로 단단해지거든요.

8. 정리와 FAQ: 비용 절감과 안정성 확보, 둘 다 잡으려면

정리하면 이렇습니다. Spot은 마법의 할인 버튼이 아니라, 중단 가능성을 시스템 설계로 흡수하는 방식입니다. 저도 처음엔 할인율만 보고 달려들었다가, 종료 처리와 상태 분리의 중요성을 몸으로 배웠습니다. 근데 그 과정을 한번 넘고 나니 운영이 훨씬 유연해지더라고요.

도입 대상 선정, 혼합 비율, 종료 처리, 모니터링까지 한 장으로 정리한 체크리스트 이미지입니다.

자주 묻는 질문

• Q. Spot을 핵심 서비스에도 쓸 수 있나요?
  A. 가능합니다. 다만 전체를 맡기기보다는 일부 확장 용량에 제한적으로 넣는 방식이 현실적입니다.
• Q. 가장 먼저 붙여볼 대상은 뭔가요?
  A. 배치, 워커, CI처럼 재시도가 쉬운 작업이 좋습니다.
• Q. 가용성 관리는 어떻게 시작하면 좋을까요?
  A. 종료 예고 감지, drain, 재시도, 외부 상태 저장 이 네 가지부터 챙기시면 됩니다.

마지막으로 추천드리고 싶은 순서는 이렇습니다.

1. 개발/배치 환경부터 Spot을 적용합니다.
2. 혼합 비율을 낮게 시작합니다.
3. 중단 처리 자동화를 먼저 완성합니다.
4. 모니터링과 런북(runbook, 대응 절차 문서)을 정리합니다.
5. 그다음에 프로덕션 확장 용량으로 넓힙니다.

Spot Instance 활용 전략은 결국 "싼 자원을 안전하게 쓰는 설계"입니다. 여기만 잡히면 클라우드 비용 절감이 꽤 현실적으로 보이기 시작합니다. 이전 글에서 다뤘던 오토스케일링 기본기와 함께 보시면 더 이해가 잘 되실 거고, 다음 글에서는 쿠버네티스 환경에서 Spot 노드 운영 팁을 이어서 다뤄보겠습니다.

📚 함께 읽으면 좋은 글

• Cloudflare Workers AI 활용 사례: 엣지 AI 서비스 구축기
• Argo CD vs Spinnaker: CI/CD 파이프라인 구축 비교 분석
• Cloudflare WAF vs AWS WAF: 장애 사례와 트러블슈팅