Amazon EC2 Spot 모범 사례

Amazon EC2 Spot 모범 사례 (Best practices for Amazon EC2 Spot)

Amazon EC2는 스팟 인스턴스(Spot Instance)를 통해 AWS 클라우드의 여유 EC2 컴퓨팅 용량에 액세스할 수 있게 해주며, On-Demand 가격 대비 최대 90%까지 절약할 수 있어요. On-Demand 인스턴스와 스팟 인스턴스의 유일한 차이는, Amazon EC2가 용량을 회수해야 할 경우 스팟 인스턴스를 2분 사전 통지와 함께 중단(interrupt)할 수 있다는 점이에요. 스팟 인스턴스로 최상의 경험을 얻으려면 그 사용에 대한 모범 사례를 이해하고 적용하는 것이 중요해요.

스팟 인스턴스는 무상태(stateless), 내결함성(fault-tolerant), 유연한 애플리케이션에 권장돼요. 예를 들어 스팟 인스턴스는 빅 데이터, 컨테이너화된 워크로드, CI/CD, 무상태 웹 서버, 고성능 컴퓨팅(HPC), 렌더링 워크로드에 잘 맞아요.

실행 중일 때 스팟 인스턴스는 On-Demand 인스턴스와 정확히 같아요. 그러나 스팟은 실행 중인 인스턴스를 워크로드를 끝낼 만큼 오래 유지할 수 있음을 보장하지 않아요. 또한 스팟은 찾는 인스턴스를 즉시 사용할 수 있음이나 요청한 총 용량을 항상 얻을 수 있음을 보장하지 않아요. 게다가 스팟 인스턴스 중단과 용량은 시간이 지나며 바뀔 수 있어요. 스팟 인스턴스 가용성은 수요와 공급에 따라 달라지고, 과거 성과가 미래 결과를 보장하지 않기 때문이에요.

스팟 인스턴스는 유연성이 없거나, 상태가 있거나(stateful), 결함에 견디지 못하거나, 인스턴스 노드 간에 긴밀하게 결합된 워크로드에는 적합하지 않아요. 전체 대상 용량이 완전히 가용하지 않은 일시적인 상황을 견디지 못하는 워크로드에는 스팟 인스턴스를 권장하지 않아요. 스팟 모범 사례를 따라 인스턴스 유형과 가용 영역에 유연하게 대응하는 것이 고가용성 가능성을 높여주지만, On-Demand 인스턴스에 대한 수요 급증이 스팟 인스턴스의 워크로드를 방해할 수 있으므로 용량이 가용할 것이라는 보장은 없어요.

이러한 워크로드에 스팟 인스턴스를 사용하거나, 중단·비가용 기간을 처리하기 위해 On-Demand 인스턴스로 장애 조치(failover)를 시도하는 것은 강력히 권장하지 않아요. On-Demand 인스턴스로의 장애 조치는 다른 스팟 인스턴스의 중단을 의도치 않게 유발할 수 있어요. 또한 인스턴스 유형과 가용 영역의 조합에 대한 스팟 인스턴스가 중단되면, 같은 조합의 On-Demand 인스턴스를 얻기 어려워질 수 있어요.

스팟의 경험이 풍부한 사용자든 스팟 인스턴스가 처음이든, 현재 스팟 인스턴스 중단이나 가용성 문제를 겪고 있다면 다음 모범 사례를 따라 스팟 서비스를 최상으로 경험해 보세요.

스팟 모범 사례 (Spot best practices)

  • 개별 인스턴스를 중단에 대비하기
  • 인스턴스 유형과 가용 영역에 유연하게 대응하기
  • 속성 기반 인스턴스 유형 선택 사용하기
  • 스팟 배치 점수로 최적 리전·가용 영역 식별하기
  • EC2 Auto Scaling 그룹이나 EC2 Fleet으로 총 용량 관리하기
  • 가격 및 용량 최적화 할당 전략 사용하기
  • 통합 AWS 서비스를 사용해 스팟 인스턴스 관리하기
  • 어떤 스팟 요청 방법이 가장 좋은가?

개별 인스턴스를 중단에 대비하기

스팟 인스턴스 중단을 우아하게 처리하는 가장 좋은 방법은 애플리케이션을 내결함성 있게 아키텍처링하는 거예요. 이를 위해 EC2 인스턴스 재조정 권장(instance rebalance recommendations)과 스팟 인스턴스 중단 통지(interruption notices)를 활용할 수 있어요.

EC2 인스턴스 재조정 권장은 스팟 인스턴스가 중단 위험이 높을 때 알려주는 신호예요. 이 신호는 2분 스팟 인스턴스 중단 통지보다 먼저 스팟 인스턴스를 사전에 관리할 기회를 제공해요. 중단 위험이 높지 않은 새 스팟 인스턴스나 기존 스팟 인스턴스로 워크로드를 재조정하기로 결정할 수 있어요. Auto Scaling 그룹과 EC2 Fleet의 Capacity Rebalancing 기능을 사용해 이 신호를 쉽게 활용할 수 있게 했어요.

스팟 인스턴스 중단 통지는 Amazon EC2가 스팟 인스턴스를 중단하기 2분 전에 발행하는 경고예요. 워크로드가 "시간에 유연한(time-flexible)" 경우, 중단 시 스팟 인스턴스가 종료되는 대신 중지(stop)되거나 최대 절전(hibernate)되도록 구성할 수 있어요. Amazon EC2는 중단 시 스팟 인스턴스를 자동으로 중지하거나 최대 절전하고, 용량을 사용할 수 있게 되면 인스턴스를 자동으로 재개해요.

재조정 권장과 중단 통지를 캡처한 뒤 워크로드 진행 상황의 체크포인트를 트리거하거나 중단을 우아하게 처리하는 규칙을 Amazon EventBridge에 만드는 걸 권장해요. 자세한 내용은 '재조정 권장 신호 모니터링하기'를 참고하세요. 이벤트 규칙을 만들고 사용하는 방법을 안내하는 상세 예시는 'Amazon EC2 스팟 인스턴스 중단 통지 활용하기'를 참고하세요. 자세한 내용은 'EC2 인스턴스 재조정 권장'과 '스팟 인스턴스 중단'을 참고하세요.

인스턴스 유형과 가용 영역에 유연하게 대응하기

스팟 용량 풀(Spot capacity pool)은 같은 인스턴스 유형(예: m5.large)과 같은 가용 영역(예: us-east-1a)의 사용되지 않은 EC2 인스턴스 집합이에요. 요청하는 인스턴스 유형과 워크로드를 배포할 수 있는 가용 영역에 유연하게 대응해야 해요. 이렇게 하면 스팟이 필요한 컴퓨팅 용량을 찾아 할당할 더 나은 기회를 얻게 돼요. 예를 들어 c4, m5, m4 패밀리의 large를 기꺼이 사용할 수 있다면 단순히 c5.large만 요청하지 마세요.

특정 필요에 따라 컴퓨팅 요구를 충족하기 위해 어떤 인스턴스 유형에 대해 유연할 수 있는지 평가할 수 있어요. 워크로드를 수직 확장(vertically scaled)할 수 있다면 요청에 더 큰 인스턴스 유형(vCPU와 메모리 증가)을 포함해야 해요. 수평 확장만 할 수 있다면, On-Demand 고객의 수요가 적기 때문에 이전 세대 인스턴스 유형을 포함해야 해요.

좋은 기준은 각 워크로드에 대해 최소 10개의 인스턴스 유형에 대해 유연하게 대응하는 것이에요. 또한 모든 가용 영역이 VPC에서 사용하도록 구성되고 워크로드에 선택되었는지 확인하세요.

속성 기반 인스턴스 유형 선택 사용하기

속성 기반 인스턴스 유형 선택(attribute-based instance type selection)을 사용하면 실행하려는 워크로드에 대해 vCPU, 메모리, 스토리지 같은 인스턴스 속성을 지정할 수 있어요. 그러면 EC2 Auto Scaling이나 EC2 Fleet이 지정한 속성과 일치하는 인스턴스를 자동으로 식별하고 시작해요. 이렇게 하면 각 인스턴스 유형의 제공 사항을 깊이 이해해야 하는 특정 인스턴스 유형을 수동으로 선택하는 수고가 사라져요.

또한 속성 기반 인스턴스 유형 선택을 사용하면 새로 출시된 인스턴스 유형을 사용할 수 있게 되는 즉시 자동으로 사용할 수 있어요. 이는 점점 더 넓어지는 스팟 인스턴스 용량에 원활하게 액세스할 수 있게 보장해요.

속성 기반 인스턴스 유형 선택은 HPC(고성능 컴퓨팅)와 빅 데이터 워크로드처럼 실행되는 인스턴스 유형에 유연할 수 있는 워크로드와 프레임워크에 이상적이에요. 자세한 내용은 Amazon EC2 Auto Scaling User Guide의 '속성 기반 인스턴스 유형 선택을 사용한 혼합 인스턴스 그룹 만들기'와 이 가이드의 'EC2 Fleet 또는 Spot Fleet용 인스턴스 유형 선택 속성 지정하기'를 참고하세요.

스팟 배치 점수로 최적 리전·가용 영역 식별하기

스팟 인스턴스는 사용되지 않은 EC2 용량이며, 이 용량은 EC2 공급과 수요에 따라 변동돼요. 그 결과 특정 위치·특정 시점에 정확히 필요한 스팟 용량을 항상 얻지 못할 수 있어요. 이 비예측성을 완화하기 위해 스팟 배치 점수(Spot placement score) 기능을 사용할 수 있어요. 이 기능은 먼저 해당 위치에 스팟 인스턴스를 시작하지 않고도 스팟 용량 요구를 충족할 충분한 용량이 있을 가능성이 더 높은 리전이나 가용 영역에 대한 권장 사항을 제공해요.

스팟 배치 점수는 사용할 수 있는 인스턴스 유형과 리전·가용 영역에 유연할 수 있는 워크로드에 가장 잘 사용돼요. 필요한 스팟 용량, 인스턴스 유형 요구 사항, 그리고 리전에 대한 권장을 원하는지 가용 영역에 대한 권장을 원하는지만 지정하면 돼요. 그 대가로 각 리전이나 가용 영역에 대해 1에서 10까지의 점수를 받는데, 이는 해당 위치에서 요청한 스팟 용량을 성공적으로 프로비저닝할 가능성을 나타내요. 점수 10은 스팟 요청이 성공할 가능성이 매우 높다는 것을 나타내요.

스팟 배치 점수는 용량이 시간이 지나며 변할 수 있으므로 특정 시점의 권장이라는 점을 기억하세요. 가용 용량을 보장하거나 중단 위험을 예측하지는 않아요. Amazon EC2 콘솔, AWS CLI, SDK에서 스팟 배치 점수 기능을 사용할 수 있어요. 자세한 내용은 '스팟 배치 점수(Spot placement score)'를 참고하세요.

EC2 Auto Scaling 그룹이나 EC2 Fleet으로 총 용량 관리하기

스팟을 사용하면 개별 인스턴스가 아니라 총 용량(aggregate capacity)의 관점에서 생각할 수 있어요. 총 용량 단위에는 vCPU, 메모리, 스토리지, 네트워크 처리량이 포함돼요. Auto Scaling 그룹과 EC2 Fleet을 사용하면 대상 용량을 시작·유지하고, 중단되거나 수동으로 종료된 리소스를 대체할 리소스를 자동으로 요청할 수 있어요. Auto Scaling 그룹이나 EC2 Fleet을 구성할 때는 애플리케이션 요구 사항에 따라 인스턴스 유형과 대상 용량만 지정하면 돼요. 자세한 내용은 Amazon EC2 Auto Scaling User Guide의 'Auto Scaling 그룹'과 이 사용자 가이드의 'EC2 Fleet 만들기'를 참고하세요.

가격 및 용량 최적화 할당 전략 사용하기

Auto Scaling 그룹의 할당 전략은 여유 용량이 있는 스팟 용량 풀을 수동으로 찾을 필요 없이 대상 용량을 프로비저닝하는 데 도움을 줘요. price-capacity-optimized 전략을 사용할 것을 권장해요. 이 전략은 가장 가용성이 높으면서도 가능한 가장 낮은 가격의 스팟 용량 풀에서 인스턴스를 자동으로 프로비저닝하기 때문이에요. EC2 Fleet에서도 price-capacity-optimized 할당 전략을 활용할 수 있어요. 스팟 인스턴스 용량이 최적의 용량을 가진 풀에서 조달되므로 스팟 인스턴스가 회수될 가능성이 줄어들어요. 자세한 내용은 Amazon EC2 Auto Scaling User Guide의 '여러 인스턴스 유형에 대한 할당 전략'과 이 사용자 가이드의 '워크로드가 중단 비용이 높은 경우'를 참고하세요.

통합 AWS 서비스를 사용해 스팟 인스턴스 관리하기

다른 AWS 서비스들이 스팟과 통합되어 개별 인스턴스나 플릿을 관리할 필요 없이 전체 컴퓨팅 비용을 줄여줘요. 적용 가능한 워크로드에 대해 다음 솔루션을 고려할 것을 권장해요: Amazon EMR, Amazon Elastic Container Service, AWS Batch, Amazon Elastic Kubernetes Service, Amazon SageMaker AI, AWS Elastic Beanstalk, Amazon GameLift Servers. 이러한 서비스의 스팟 모범 사례에 대해 더 알아보려면 Amazon EC2 Spot Instances Workshops 웹사이트를 참고하세요.

어떤 스팟 요청 방법이 가장 좋은가?

다음 표로 스팟 인스턴스를 요청할 때 어떤 API를 사용할지 결정하세요.

API 언제 사용하나요? 사용 사례 이 API를 사용해야 하나요?
CreateAutoScalingGroup 단일 구성이나 혼합 구성을 가진 여러 인스턴스가 필요할 때. 구성 가능한 API를 통해 수명 주기 관리를 자동화하고 싶을 때. 인스턴스의 수명 주기를 관리하면서 원하는 인스턴스 수를 유지하는 Auto Scaling 그룹을 만들어요. 지정된 최소·최대 한도 사이에서 수평 확장(인스턴스 추가)을 지원해요. 예
CreateFleet 단일 구성이나 혼합 구성을 가진 여러 인스턴스가 필요할 때. 인스턴스 수명 주기를 직접 관리하고 싶을 때. 자동 확장이 필요 없다면 instant 유형 플릿을 사용하는 걸 권장해요. 인스턴스 유형, AMI, 가용 영역, 서브넷별로 다른 여러 시작 사양으로 단일 요청에서 On-Demand 인스턴스와 스팟 인스턴스 플릿을 만들어요. 스팟 인스턴스 할당 전략은 기본적으로 단위당 최저 가격(lowest-price)이지만, price-capacity-optimized, capacity-optimized, diversified로 변경할 수 있어요. 예 – 자동 확장이 필요 없다면 instant 모드에서
RunInstances 이미 RunInstances API로 On-Demand 인스턴스를 시작하고 있고, 매개변수 하나만 바꿔 스팟 인스턴스 시작으로 전환하려 할 때. 서로 다른 인스턴스 유형의 여러 인스턴스가 필요하지 않을 때. AMI와 하나의 인스턴스 유형으로 지정된 수의 인스턴스를 시작해요. 아니요 – RunInstances는 단일 요청에서 혼합 인스턴스 유형을 허용하지 않기 때문
RequestSpotFleet RequestSpotFleet API는 레거시 API로 예정된 투자가 없으므로 사용을 강력히 권장하지 않아요. 인스턴스 수명 주기를 관리하려면 CreateFleet API를 사용하세요. 수명 주기를 관리하고 싶지 않다면 CreateAutoScalingGroup API를 사용하세요. 사용하지 마세요. RequestSpotFleet는 예정된 투자가 없는 레거시 API예요. 아니요
RequestSpotInstances RequestSpotInstances API는 레거시 API로 예정된 투자가 없으므로 사용을 강력히 권장하지 않아요. 사용하지 마세요. RequestSpotInstances는 예정된 투자가 없는 레거시 API예요. 아니요

더 알아보기 (Learn more)