AWS 스팟 인스턴스는 사전 약정 없이 On-demand 요금보다 70~90% 절감된 비용으로 사용할 수 있는 EC2 Instance(VM)이다.  시작하려는 인스턴스에 대해 현재 시간에 유효한 가격만 지불하면 된다.

주로 Batch Job 등 용도로 사용하는 서버에 잘 어울린다.

장점은 세 가지로 나열할 수 있다.

첫 번째, 용량 활용

EC2 스페어 용량의 수요와 공급량에 따라 가격이 결정되기 때문에 시장 중심의 낮은 가격으로 Amazon EC2의 안정성, 보안성, 성능, 제어 및 탄력성을 제공 받을 수 있다.

두 번째, 운영비용 절감

On-demand Instance와 비교하여 최대 70~90%의 운영 비용을 절감할 수 있다.

세 번째, 처리량 향상

상태 비저장 웹 서비스, 이미지 랜더링, 빅데이터 분석, 대량의 병렬 계산 등 애플리케이션을 실행하고 확장 가능하다.

스팟 인스턴스의 최대 가격 지정이 가능하다.

최고 가격 > 스팟 가격: 인스턴스 시작

최고 가격 < 스팟 가격: 인스턴스 종료

스팟 인스턴스는 애플리케이션에 따른 4가지 종류를 구분해놨지만, 내 생각에 별 의미는 없고 스팟 플릿과 블록만 구분하면 될 거 같다.

각각의 타입은 아래 내용을 참고하자.

- 스팟 플릿

Load balancing workloads : 모든 가용영역에서 동일한 사이즈의 인스턴스 사용. 웹서비스에 적합.

Flexible workloads :  모든 AZ에서 모든 사이즈의 인스턴스 사용. 배치 와 CI/CD 작업에 적합

Big data workloads : 단일 AZ에서 여러사이즈의 인스턴스 사용. MapReduce 작업에 적합.

- 스팟 블록

Defined duration workloads :  1~6시간 동안의 스팟 블록(지정된 지속시간) 인스턴스 사용.

- 스팟 플릿 인스턴스 특징

핵심은 스팟 인스턴스 중단에 항상 대비해야 한다는 것이다.

- 종료시 2분전에 경고하는 공지 제공

- 종료 공지를 이용하여 스팟 인스턴스의 상태를 모니터링

- 합리적인 입찰 가격 사용

- 예상치 못한 인스턴스 종료에 어플리케이션이 대처할 수 있도록 확인

- 스팟 인스턴스가 종료되어도 영향을 받지 않을 장소(S3, EBS)에 중요 데이터 저장

- 스팟 인스턴스 중단 이유는 아래와 같다.

- 가격: 스팟 가격이 최고 가격보다 크다.

- 용량: 미사용 EC2 인스턴스가 스팟 인스턴스의 수요를 충족할 만큼 충분하지 않으면 Amazon EC2에서 스팟 인스턴스를 중단한다. 인스턴스가 중단되는 순서는 Amazon EC2에서 결정된다.

- 제약 조건: 요청에 시작 그룹 또는 가용 영역 그룹과 같은 조건이 더 이상 충족할 수 없으면 중단된다.

- 스팟 집합

스팟 집합은 스팟 인스턴스의 모음으로 스팟 인스턴스가 가격 또는 용량의 변경으로 중단될 경우 목표 용량 집합을 유지하려고 시도한다.

스팟 집합 전략

- lowestPrice (최저가격)

최저 가격의 풀에서 스팟 인스턴스를 가져옴

기본 전략으로 최저가로 입찰 가능

-Diversified (다각화)

- 모든 풀에 분산해서 스팟 인스턴스를 가져옴

- 가용성 및 하나의 풀에서 발생하는 가격상승에 덜 민감해짐

- 온디맨드 가격보다 높은 가격의 풀에서는 시작하지 않음

참고

스팟 할당 전략은 아래 그림과 같이 두 가지가 있다.

스팟 집합에서 온디맨드 용량을 채우려고 시도하는 경우 기본적으로 최저 가격의 인스턴스 유형을 먼저 시작한다.

예를 들어 서로 다른 인스턴스 유형인 c4.large, c5.large를 집합요청으로 설정하는 경우, 1개의 온디맨드를 포함한 총 목표 용량을 5로 설정했을때, 온디맨드 가격은 c5.large (0.096USD) 가 c4.large(0.114USD) 보다 저렴하므로, 온디맨드 용량을 c5.large를 채운 후 나머지를 설정합니다.

스팟 요금 History

스팟 인스턴스의 입찰 가격 정책에 도움을 주기 위해 생긴 기능이다.

지난 90일 동안의 스팟 가격 기록을 인스턴스 유형, 운영 체제 및 가용 영역을 기준으로 확인하여 스팟 인스턴스의 비용에 대한 인사이트를 얻을 수 있다.

스팟 인스턴스에 대한 CloudWatch 메트릭은 아래와 같다.

AvailableInstancePoolsCount

- 스팟 집합 요청에 지정된 스팟 인스턴스 풀. (단위 : 수)

BidsSummittedForCapacity

- Amazon EC2가 입찰을 제출한 용량. (단위 : 수)

EligibleInstancePoolCount

- Amazon EC2가 입찰을 이행할 수 있는 스팟 집합 요청에 지정된 스팟인스턴스 풀.

- Amazon EC2는 입찰가격이 스팟가격보다 낮거나 스팟 가격이 On-Demand 인스턴스 가격보다 높은 경우

풀에서 입찰을 이행하지 않습니다. (단위 : 수)

FulfilledCapacity

- Amazon EC2가 달성한 용량.  (단위 : 수)

MaxPercentCapacityAllocation

- 스팟 집합 요청에 지정된 모슨 스팟 인스턴스 풀에 걸친 PercentCapacityAllocation의 최대값. (단위 : 백분율)

PendingCapacity

- TargetCapacity와 FulfilledCapacity의 차이점. (단위 : 수)

PercentCapacityAllocation

- 지정된 차원의 스팟인스턴스 풀에 할당된 용량.

- 모든 스팟 인스턴스 풀에 기록된 최대값을 얻으려면 MaxPercentCapacityAllocation을 사용하십시오. (단위 : 백분율)

TargetCapacity

- 스팟 집합 요청의 목표 용량. (단위 : 수)

TerminatingCapacity

- 스팟 인스턴스 간섭으로 인해 종료되고 있는 용량. (단위 : 수)

스팟 플릿을 지속적으로 유지하기 위해서는?

스팟 플릿의 경우 가용량 혹은 비딩으로 인해 언제 중단될 지 알 수 없다.

따라서 describeSpotInstanceRequests(스팟상태체크) / describespotPriceHistory(스팟비딩체크) API를 통해 주기적으로 스팟 상태를 체크하고 새로운 스팟 요청을 해줘야 한다.

위 방식을 통해 Auto Scaling Group을 온디맨드/스팟을 혼용하여 사용하기도 한다.

초기 다수의 스팟 요청이 실패할 수 있는데, 대개 스팟 제한으로 인해 발생된다. 가시적으로 스팟 제한 가용량을 확인하기 위해서는 Service Quotas -> EC2 항목에서 각 타입에 맞는 스팟 인스턴스 vCPU 할당량을 확인할 수 있다.

또한 각 타입에 요청을 확인하면 아래와 같이 스팟 제한에 따른 가용성을 가시적으로도 볼 수 있다.

스팟 항목에서 히스토리를 보면 아래와 같이 가용성 문제로 스팟 생성이 실패된 것을 알 수 있다.

Repeated errors have occurred processing the launch specification "g4dn.xlarge, ami-01748a72bed07727c, Linux/UNIX, ap-northeast-1a while launching spot instance". It will not be retried for at least 13 minutes. Error message: Max spot instance count exceeded (Service: AmazonEC2; Status Code: 400; Error Code: MaxSpotInstanceCountExceeded; Proxy: null)

타입에 따른 스팟 가용량 증설 요청은 Service Quotas 를 통해 쉽게 가능하다.

그러나 계정에 가용량을 증설했어도 AWS 내의 자체 물량이 부족하면 스팟은 중단될 경우도 있으니, 꼭 스팟 상태를 체크하는 것이 필요하다.

스팟 블록의 경우 최소 1시간에서 최대 6시간까지 인스턴스 가동이 가능하다.

다만 스팟 플릿과 블록의 AWS 할당량이 다른 것인지 동일한 타입의 AZ에서 스팟 플릿은 생성되지만, 스팟 블록은 생성되지 않기도 한다. 

해당 내용을 AWS 서포트에 문의했는데, 스팟 플릿/블록 가용량 기준은 동일하다고 답변 받았다...

그러나 지금도 플릿은 생성되나 블록은 생성되지 않는 것을 봤을 때, 가용량에 대한 다른 기준이 있는 듯 보이긴 한다.