AutoSpot: 회수를 미리 읽는 스팟 인스턴스 자동화
■ 문제: 스팟 인스턴스는 최대 80%까지 쌉니다. 그런데 회수 통보가 떨어지는 순간 워크로드가 끊기니, 프로덕션에는 좀처럼 손이 가지 않습니다.
■ 해결: 스팟 인스턴스 자동화 도구인 AutoSpot이 인스턴스 선택과 회수 대응을 맡습니다. 머신러닝이 회수를 최대 15분 전에 예측하고, 그 사이에 대체 인스턴스로 옮깁니다.
■ 효과: 99.99% SLA를 유지한 채 스팟을 씁니다. 이커머스 O사는 EC2 절반을 스팟으로 돌려 관련 비용을 70% 줄였습니다.
금요일 밤에 돌던 배치 잡이 스팟 회수로 죽었습니다. 재시작 로직이 없어 월요일 아침까지 그대로 멈춰 있었습니다. 그 팀은 지금도 스팟을 개발 환경에만 씁니다.
싸게 쓰려면 끊김을 감수해야 한다는 전제
스팟은 클라우드 사업자가 남는 용량을 할인해 파는 방식입니다. 남는 용량이니 언제든 회수됩니다. 여기까지는 다들 압니다.
문제는 그다음입니다. 회수를 감당하려면 워크로드를 상태 없이 만들고, 중단 신호를 받아 종료 절차를 밟고, 대체 인스턴스 타입 목록을 관리하고, 타입별 중단 확률을 계속 들여다봐야 합니다. 이 일을 상시로 맡길 엔지니어가 있는 팀은 드뭅니다. 그래서 스팟은 대개 개발·테스트 환경에서 멈춥니다.
스팟 인스턴스 자동화가 대신 보는 것
AutoSpot은 이 판단을 사람 손에서 걷어냅니다. 가격과 중단 가능성을 함께 보고 최적의 스팟을 실시간으로 적용합니다. 인스턴스 타입 하나에 묶이지 않고, 그 시점에 조건이 나은 쪽으로 계속 갈아탑니다.
핵심은 예측입니다. 머신러닝 모델이 회수 징후를 읽어 최대 15분 전에 알립니다. 회수 통보를 받고 움직이면 종료 절차를 밟기도 빠듯하지만, 15분을 먼저 벌면 새 인스턴스를 띄우고 트래픽을 옮기고 이전 인스턴스를 비우는 순서를 여유 있게 밟을 수 있습니다.
고정적으로 쓰는 자원은 약정으로 낮추고 변동분을 스팟으로 받는 구성이 흔합니다. 약정 쪽은 AutoSavings가 맡습니다.
실제 적용 사례
이커머스 O사는 EC2 인스턴스의 절반을 스팟으로 전환했습니다. 관련 비용이 70% 줄었고 가용성은 99.99%를 지켰습니다. 실 고객 사례이므로 워크로드 구성에 따라 결과는 달라집니다.
AutoSpot 자체도 99.99% SLA로 제공됩니다. 스팟 도입을 막는 것은 절감폭에 대한 의심이 아니라 가용성에 대한 불안이니, 검토는 대개 이 숫자에서 시작됩니다.
배치, CI 러너, 스테이트리스 API 서버처럼 노드가 바뀌어도 되는 워크로드가 먼저 후보입니다. 라이선스가 인스턴스에 묶여 있거나 로컬 디스크에 데이터를 쌓는 구성이라면 전환 순서를 뒤로 둡니다.
앞의 배치 잡으로 돌아가 봅니다. 회수를 15분 전에 알았다면 월요일 아침에 확인할 일도 없었을 것입니다. 스팟을 쓸지 말지보다, 회수를 누가 지켜볼지가 먼저 정해져야 합니다.
자주 묻는 질문(FAQ)
Q. 프로덕션 워크로드에도 스팟을 쓸 수 있습니까?
가능합니다. AutoSpot은 99.99% SLA로 제공되고, 회수를 최대 15분 전에 예측해 미리 대체합니다. 다만 상태를 인스턴스에 저장하는 워크로드라면 구조를 먼저 손봐야 합니다.
Q. 절감 폭은 어느 정도입니까?
스팟 가격 자체가 최대 80%까지 낮습니다. 이커머스 O사는 EC2 절반을 스팟으로 옮겨 관련 비용을 70% 줄였습니다. 실 고객 사례이고, 구성에 따라 폭은 달라집니다.
Q. 회수 예측 시점이 짧아지면 어떻게 됩니까?
예측은 최대 15분 전을 목표로 합니다. 시점이 짧아지더라도 대체 스팟 적용은 실시간으로 이뤄지며, 서비스 수준은 99.99% SLA로 관리됩니다.
