스팟 인스턴스 활용 — 비용 절감과 중단 대응 설계

같은 인스턴스를 온디맨드 대비 최대 90% 싸게 쓸 수 있는 게 스팟 인스턴스입니다. 대신 클라우드가 여유 용량을 회수할 때 2분 전 통보만 주고 인스턴스를 가져갑니다. 핵심은 "싸다"가 아니라 언제 회수돼도 괜찮은 워크로드인지를 먼저 가르는 것입니다.

스팟에 맞는 워크로드 vs 아닌 것

배치 처리·CI 빌드·동영상 인코딩·웹 서버 오토스케일링 그룹의 추가 용량은 스팟의 단골 후보입니다. 반면 상태를 로컬에 들고 있거나 중단 시 복구가 불가능한 워크로드는 온디맨드나 예약 인스턴스로 둡니다.

중단 통보 처리

스팟이 회수될 때 인스턴스 메타데이터에 종료 시각이 게시됩니다. 애플리케이션은 이를 폴링하다가 신호가 잡히면 안전하게 마무리합니다.

# 중단 예고 확인 (있으면 종료 시각 JSON, 없으면 404)
curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

{ "action": "terminate", "time": "2028-02-07T10:32:00Z" }

이 신호를 받으면 약 2분 안에 진행 중 작업을 체크포인트로 저장하고, 로드밸런서에서 자신을 빼고, 처리 중인 큐 메시지를 반환(가시성 타임아웃 해제)해 다른 워커가 이어받게 합니다.

중단에 견디는 설계

1. 인스턴스 타입·AZ 분산 — 한 종류에 몰면 동시 회수 위험이 커진다. 여러 타입과 가용영역에 걸쳐 풀을 넓혀 회수 충격을 분산한다.
2. 온디맨드와 혼합 — 오토스케일링 그룹에서 기본 용량(base)은 온디맨드로 깔고, 그 위 확장분만 스팟으로 채워 최소 가용성을 보장한다.
3. 작업을 잘게·멱등하게 — 큰 작업을 체크포인트가 있는 작은 단위로 쪼개면 중단돼도 마지막 지점부터 재개된다. 재시도가 중복을 일으키지 않도록 멱등하게 만든다.
4. 자동 대체 — 회수 시 다른 풀에서 새 인스턴스를 띄우도록 구성해 사람 개입 없이 용량을 회복한다.

요점 정리

• 스팟 = 저렴하지만 2분 통보 후 회수되는 여유 용량.
• 무상태·재시도 가능·체크포인트 있는 워크로드에만 쓴다.
• instance-action 메타데이터를 감시해 종료 전 정리한다.
• 타입/AZ 분산 + 온디맨드 혼합으로 동시 회수 위험을 낮춘다.

스팟 중단 신호를 감지해 워크로드를 안전하게 비우는 흐름을 직접 구성하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.