Category: EC2 Spot Instance


Amazon EC2 업데이트 – 손 쉬운 스팟 용량 접근 및 가격 변경, 인스턴스 최대 절전 기능 등

EC2 스팟 인스턴스를 통해 AWS 클라우드에서 컴퓨팅 파워를 아낄 수 있습니다. 고객들은 스팟 인스턴스 집합을 사용하여 CI/CD 환경 및 트래픽 생성기, 웹 서버 및 마이크로서비스 호스팅, 영화 렌더링을 구동하고, 많은 유형의 분석 작업을 실행합니다. 그리고 이 모든 것을 온디맨드 인스턴스와 비교하여 크게 절감된 가격으로 실행합니다.

간소화된 접근 방법
오늘은 새롭게 간소화된 스팟 인스턴스 액세스 모델을 소개하겠습니다. 다음을 통해 인스턴스를 시작할 때 스팟 용량을 사용하고 싶어하는 마음이 있을 것입니다. RunInstances 함수, run-instances 명령 또는 AWS 관리 콘솔을 통해 용량을 사용할 수 있는 동안 이행될 요청을 제출하고 싶을 것입니다. 별도의 수고 없이 인스턴스 유형에 대해 온디맨드 가격의 최대 90%를 절감한다면 동일한 예산으로 전체적인 애플리케이션 처리량을 최대 10배 늘릴 수 있는 셈입니다. 이렇게 시작한 인스턴스는 직접 종료하거나 EC2가 이를 온디맨드 사용으로 회수할 때까지 계속해서 실행될 것입니다. 이럴 경우 인스턴스가 일반적으로 2분의 경고가 주어진 다음 회수되기에 애플리케이션 내결함성에 있어 매우 적절합니다.

스팟 시장, 입찰 및 독립 실행형 비동기식 API에 대한 이해가 필요한 이전 모델과는 달리 새로운 모델은 동기식이고 온디맨드만큼 사용하기 쉽습니다. 코드와 스크립트가 인스턴스 ID를 즉시 받고, 요청이 처리 및 수락되었는지 여부를 재확인할 필요가 없습니다.

우리는 이를 최대한 명확하고 간단하게 만들었기 때문에 스팟 용량을 요청하고 사용할 많은 현재 스크립트 및 애플리케이션을 수정하기 쉬울 것으로 기대합니다. 스팟 인스턴스 예산에 대한 추가적인 통제를 행사하고자 한다면 용량 요청을 할 때 최고 가격을 지정하는 옵션이 있습니다. 스팟 용량을 사용하여 Amazon EMR, Amazon ECS 또는 AWS Batch 클러스터를 구동하거나 AWS CloudFormation 템플릿 또는 Auto Scaling 그룹을 통해 스팟 인스턴스를 시작하는 경우 어떠한 변화 없이 이 새로운 모델의 이점을 누릴 수 있습니다.

애플리케이션이 RequestSpotInstances 또는 RequestSpotFleet 를 중심으로 빌드되는 경우 어떠한 변화 없이 계속해서 작동합니다. 하지만 이제 다음 파라미터가 포함되지 않는 요청을 만들 수 있는 옵션이 있습니다. SpotPrice 파라미터입니다.

손쉬운 스팟 가격 변경
오늘 출시의 일환으로 스팟 가격의 변경 방식을 바꾸어 가격이 공급 및 수요의 장기적 추세를 기반으로 점진적으로 변하는 모델로 이동합니다. 앞서 언급한 대로 계속해서 온디맨드 가격의 평균 70~90%를 절감하고, 인스턴스가 실행 중인 기간 동안 적용되는 스팟 가격을 지불하면 됩니다. 스팟 집합 기능을 중심으로 빌드된 애플리케이션은 집합을 생성할 때 지정한 구성을 기반으로 하는 가장 비용 효율적인 풀 전체의 스팟 인스턴스 배치를 자동적으로 다양화합니다.

스팟 실행
명령줄에서 스팟 인스턴스를 시작하려면 스팟 시장을 지정하면 됩니다.

$ aws ec2 run-instances –-market Spot --image-id ami-1a2b3c4d --count 1 --instance-type c3.large 

인스턴스 최대 절전
많은 인 메모리 상태를 유지하는 워크로드를 실행한다면 이 기능이 마음에 드실 것입니다!

인스턴스가 회수될 때에도 인 메모리 상태를 저장하도록 조정하여 용량을 다시 사용할 수 있을 때 인스턴스와 인스턴스에 있는 애플리케이션이 중단된 지점에서 다시 시작하도록 할 수 있습니다. 마치 노트북을 닫았다가 다시 열어서 사용하는 것처럼 말이죠. 이 기능은 Amazon Linux, Ubuntu 또는 Windows Server를 실행하는 C3, C4, 그리고 특정 크기의 R3, R4 및 M4 인스턴스에서 작동하며, EC2 최대 절전 에이전트의 지원을 받습니다.

인 메모리 상태는 인스턴스 시작 시 별도로 확보된 공간을 사용하여 인스턴스의 루트 EBS 볼륨에 기록됩니다. 프라이빗 IP 주소와 탄력적 IP 주소 또한 중지/시작 주기에 걸쳐 유지됩니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 Amazon EC2 Update – Streamlined Access to Spot Capacity, Smooth Price Changes, Instance Hibernation의 한국어 번역입니다.

새 소식 – EC2 스팟 인스턴스의 워크로드 중지 및 재개

EC2 스팟 인스턴스는 EC2 컴퓨팅 파워 요구량의 최대 90%까지 아껴줍니다. 특정 크기와 개수의 인스턴스를 요청할 수 있는 기능은 물론 원하는 수준의 컴퓨팅 파워를 유지할 수 있는 스팟 집합Auto Scaling 스팟 집합까지 지원하여 스팟 인스턴스의 유용성과 유연성을 훨씬 더 높였습니다.

EC2 사용자는 EBS 볼륨을 연결한 상태에서 인스턴스 실행을 멈추었다가 인스턴스가 다시 실행하면 멈췄던 부분에서 자동으로 시작하는 기능을 오래 전부터 사용했습니다.

스팟 워크로드 중지 및 재개
이제부터는 이 두 중요한 기능을 섞어 가용 용량이 없거나 용량이 입찰가 미만일 때 인스턴스를 중지하는(종료하는 대신) 방식으로 대응하는 스팟 입찰과 스팟 집합을 설정할 수 있습니다. 중지된 인스턴스에 연결된 EBS 볼륨은 EBS 기반 루트 볼륨처럼 그대로 유지됩니다. 가용 용량이 생기면 인스턴스가 시작되어 애플리케이션 프로비저닝, EBS 볼륨 설정, 데이터 다운로드, 네트워크 도메인 연결 등에 시간이 소요되지 않고 계속 진행할 수 있습니다.

많은 AWS 고객들이 체크포인트를 생성하고 이용하는 애플리케이션을 향상시켜, 복원력을 강화하고 프로세스에서 EC2 시작/중지 기능을 사용할 수 있게 되었습니다. 이제 이 고객들은 스팟 인스턴스에서 이러한 애플리케이션을 실행하여 평균 70~90%를 절약할 수 있게 됩니다.

인스턴스가 멈춘 상태에서 EBS 최적화, 사용자 데이터, 램디스크 ID, 종료 시 삭제 속성을 수정할 수 있습니다. 중지한 스팟 인스턴스는 컴퓨팅 시간 비용이 발생하지 않으며, 연결된 EBS 볼륨 공간은 정기 요금으로 청구됩니다.

스팟 입찰 또는 스팟 집합을 생성하여 중지/시작 사용을 지정하는 방법은 다음과 같습니다.

알아야 할 것들
이 기능은 현재 사용할 수 있으며, 스팟 인스턴스가 있는 모든 AWS 리전에서 이 기능을 지금 사용할 수 있습니다. 새로운 EC2 인스턴스 및 EBS 볼륨의 초 단위 과금 방식과 연동되도록 설계되어 스팟 인스턴스의 비용 절감 수준을 한 차원 더 높일 수 있습니다.

EBS 볼륨은 항상 특정 가용 영역(AZ) 안에 존재합니다. 따라서 특정 AZ를 지정하는 스팟 및 스팟 집합 요청은 항상 해당 AZ에서 다시 시작합니다.

이 기능을 인스턴스 유형이 다양할 수 있는 스팟 집합과 함께 사용할 때는 주의하십시오. 인스턴스 집합의 구성은 시간이 지나면 변할 수 있기 때문에 계정의 IP 주소와 EBS 볼륨 한계에 신경써야 합니다.

여러분이 앞으로 이 기능을 얼마나 새롭고 기발하게 사용하게 될지 궁금합니다. 사용 중인 애플리케이션이 스팟 인스턴스에 잘 맞지 않다고 생각되거나 중단 문제를 해결하는 데 비용이 너무 많이 든다면 다시 한 번 고려해보십시오.

Jeff;

이 글은 New – Stop & Resume Workloads on EC2 Spot Instances의 한국어 번역입니다.

EC2 스팟 인스턴스로 Amazon ECS 콘테이너 클러스터 운영하기

Amazon EC2 컨테이너 서비스 (Amazon ECS)가 ECS 콘솔에서 Amazon EC2 스팟 인스턴스에 직접 ECS 클러스터를 시작하는 기능을 지원한다는 것을 알리게 되어 매우 기쁩니다.

스팟 인스턴스는 예비 Amazon EC2 컴퓨팅 용량에 입찰 할 수 있게 합니다. 스팟 인스턴스는 일반적으로 온 디맨드 인스턴스보다 50-90 % 저렴합니다. 스팟 인스턴스로 ECS 클러스터를 운영하면 기존의 컨테이너화 된 워크로드를 실행하는 비용을 줄이거나 동일한 예산을 유지하면서 컴퓨팅 용량을 2 ~ 10 배까지 증가시킬 수 있습니다. 혹은 둘 다 조합 할 수 있습니다!

스팟 인스턴스를 사용하면 인스턴스 시간당 지불 할 가격을 지정합니다. 스팟 인스턴스는 언제든지 당신의 입찰가가 현재 스팟 가격을 초과 할 경우 실행됩니다. 더 높은 스팟 가격으로 인해 인스턴스가 회수 된 경우 인스턴스가 실행된 부분 시간에 대해서는 비용이 청구되지 않습니다.

ECS 콘솔은 스팟 집합을 사용하여 스팟 인스턴스를 배포합니다. 스팟 집합은 최적의 가격으로 컨테이너 어플리케이션에 대해 요청한 목표 용량 (인스턴스 또는 vCPU 개수로 표현)을 배포하려고 시도합니다. 현재 입찰 가격 또는 사용 가능한 용량의 변경으로 인해 스팟 인스턴스가 회수 된 경우에도 스팟 집합은 목표 용량을 유지하려고 시도합니다.

컨테이너는 다수의 스팟 집합이 배포되는 여러 종류의 자원 풀과 잘 들어 맞습니다. 스팟 집합을 사용하면 여러 스팟 인스턴스풀 (인스턴스 유형 및 가용 영역 조합)에 용량을 프로비저닝 할 수 있어 애플리케이션 가용성을 향상시키고 시간이 지남에 따라 집합의 운영 비용을 절감할 수 있습니다.  스팟 집합과 함께 ECS가 제공하는 확장 가능하고 유연한 컨테이너 배치 시스템을 결합하면 컨테이너 작업 부하를 효율적으로 배치하고 비용의 일부만으로 규모에 관계없이 쉽게 클러스터를 관리 할 수 있습니다.

이전에는 스팟 인스턴스에 ECS 클러스터를 배포하는 것이 수동 프로세스였습니다. 이 글에서는 ECS 콘솔에서 새로운 스팟 집합 통합을 사용하여 컨테이너 작업 부하에 대한 고 가용성, 확장성 및 비용 절감 방법을 제시합니다. 또한 AWS CloudFormation을 사용하여 스팟 인스턴스에 자신의 ECS 클러스터를 구축하는 방법을 보여줍니다.

스팟 인스턴스에서 실행되는 ECS 클러스터 만들기
AWS 관리 콘솔을 사용하여 ECS 클러스터를 만들 수 있습니다.

  1. https://console.aws.amazon.com/ecs/에서 Amazon ECS 콘솔을 엽니다.
  2. 탐색 창에서 클러스터를 선택하십시오.
  3. 클러스터 페이지에서 클러스터 생성을 선택하십시오.
  4. 클러스터 이름에 이름을 입력하십시오.
  5. 인스턴스 구성에서 프로비저닝 모델에 대해 스팟을 선택하십시오.

스팟 인스턴스 할당 전략 선택하기
두 가지 가능한 스팟 인스턴스 할당 전략은 다각화와 최저 가격입니다.

스팟 집합에 대해 선택한 할당 전략에 따라 가능한 스팟 인스턴스 풀에서 스팟 집합 요청이 어떻게 수행되는지가 결정됩니다. 다양한 전략을 사용하면 스팟 인스턴스가 모든 풀에 분산됩니다. 가장 낮은 가격 전략을 사용하면 스팟 인스턴스는 요청에 지정된 최저 가격의 풀에서 가져옵니다.

모든 리전의 각 가용 영역 안에 있는 각 인스턴스 유형 (각 인스턴스 패밀리 내의 인스턴스 크기, 예 : c4.4xlarge)은 별도의 용량 풀이므로 별도의 스팟 마켓입니다. 가능한 많은 인스턴스 유형과 가용 영역을 다양화함으로써 스팟 집합의 가용성을 향상시킬 수 있습니다. 또한 시간이 지남에 따라 하나의 풀에서 스팟 가격 상승에 집합이 덜 민감해지도록 됩니다.

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2017/06/05/06.06-Spot-3.png

스팟 집합에 사용할 최대 6 개의 EC2 인스턴스 유형을 선택할 수 있습니다. 이 예에서는 크기가 xlarge 인 m3, m4, c3, c4, r3 및 r4 인스턴스 유형을 선택했습니다.

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2017/06/05/06.06-Spot-4.png

인스턴스에 대한 입찰가를 입력해야 합니다. 일반적으로 온 디맨드 인스턴스 가격 또는 그 근처에서의 입찰은 좋은 출발점입니다. 입찰가는 해당 스팟 풀에서 인스턴스 유형에 대해 지불할 최대 가격입니다. 스팟 가격이 입찰가 또는 그 이하인 경우 스팟 가격을 지불합니다. 낮은 입찰가는 낮은 비용을 보장, 높은 입찰가는 중단 가능성을 낮춥니다.

클러스터에 포함할 인스턴스 수를 구성하십시오. 스팟 집합은 요청에 지정된 목표 용량을 충족시키는 데 필요한 스팟 인스턴스 수를 배포하려고 시도합니다. 또한 스팟 집합은 스팟 가격이나 사용 가능한 용량이 변경되어 스팟 인스턴스가 회수되는 경우 대상 용량을 유지하려고 시도합니다.

ECS–optimized AMI가 인스턴스가 배포될 때 사용됩니다.

저장소 및 네트워크 설정을 구성하십시오. 다양화 및 고 가용성을 활성화하려면 여러 가용 영역에서 서브넷을 선택해야합니다. 단일 Spot Fleet에서 동일한 가용 영역에서 여러 서브넷을 선택할 수 없습니다.

ECS 컨테이너 에이전트는 사용자를 대신하여 ECS API 작업을 호출합니다. 에이전트를 실행하는 컨테이너 인스턴스에는 에이전트가 사용자에게 속한 것을 알 수 있도록 서비스에 대한 ecsInstanceRole IAM 정책 및 롤이 필요합니다. ecsInstanceRole이 없는 경우 ECS 콘솔을 사용하여 ecsInstanceRole을 만들 수 있습니다.

스팟 집합을 사용하는 관리형 컴퓨트 환경을 만드는 경우, 스팟 집합에 인스턴스에 대한 입찰, 실행 및 종료 권한을 부여하는 롤을 만들어야 합니다. ECS 콘솔을 사용하여 롤을 만들 수도 있습니다.

여기까지입니다! ECS 콘솔에서 생성을 선택하여 스팟 인스턴스에서 실행되는 새 ECS 클러스터를 시작하십시오.

AWS CloudFormation 사용하여 스팟 인스턴스에 ECS 클러스터 배포
이제 CloudFormation 스택을 쉽게 시작하고 스팟 인스턴스에 ECS 클러스터를 배포하는 방법을 보여주는 참조 아키텍처 AWS CloudFormation 템플릿을 게시했습니다.

CloudFormation 템플릿에는 앞서 언급한 스팟 인스턴스 종료 알림 스크립트뿐만 아니라 신속한 시작을 위한 몇 가지 추가 로깅 및 기타 예제 기능이 포함되어 있습니다. Amazon EC2 스팟 인스턴스 GitHub 레포에서 CloudFormation 템플릿을 찾을 수 있습니다.

시험해보고 당신의 환경에 필요에 맞게 사용자 정의하십시오.

 

Spot Fleet Architecture 종료 처리
스팟 인스턴스를 사용하면 지정한 가격 이상을 절대 지불하지 않습니다. 스팟 가격이 주어진 인스턴스의 입찰 가격을 초과하면 자동으로 종료됩니다.

스팟 인스턴스 중단을 방지하는 가장 좋은 방법은 컨테이너 애플리케이션을 내결함성으로 설계하는 것입니다. 또한 스팟 인스턴스 종료 통지라는 기능을 활용할 수 있습니다. EC2가 스팟 인스턴스를 종료하기 2 분전에 경고를 제공합니다.

이 경고는 인스턴스 메타 데이터의 항목을 사용하여 스팟 인스턴스의 어플리케이션에서 사용할 수 있습니다. 콘솔을 사용하여 스팟 인스턴스에 ECS 클러스터를 배포하면 AWS는 5 초마다 스팟 인스턴스 종료 알림을 확인하는 스크립트를 설치합니다. 통지가 감지되면 스크립트는 컨테이너 인스턴스 상태를 드레이닝으로 즉시 업데이트합니다.

스팟 인스턴스 종료 통지 스크립트의 단순화 된 버전은 다음과 같습니다.

Bash
#!/bin/bash

while sleep 5; do
  if [ -z $(curl -Isf http://169.254.169.254/latest/meta-data/spot/termination-time) ]; then
    /bin/false
  else
    ECS_CLUSTER=$(curl -s http://localhost:51678/v1/metadata | jq .Cluster | tr -d \") CONTAINER_INSTANCE=$(curl -s http://localhost:51678/v1/metadata \ | jq .ContainerInstanceArn | tr -d \")
    aws ecs update-container-instances-state --cluster $ECS_CLUSTER \
      --container-instances $CONTAINER_INSTANCE --status DRAINING
  fi
done

컨테이너 인스턴스를 드레이닝으로 설정하면 ECS는 새 작업이 컨테이너 인스턴스에 배치되지 않도록 합니다. 리소스가 가용한 경우, 교체 서비스 작업이 클러스터의 다른 컨테이너 인스턴스에서 시작됩니다. 컨테이너 인스턴스 드레이닝을 사용하면 클러스터의 작업에 영향을 미치지 않고 클러스터에서 컨테이너 인스턴스를 제거 할 수 있습니다. PENDING 상태에 있는 컨테이너 인스턴스의 서비스 작업은 즉시 중지됩니다.

RUNNING 상태에 있는 컨테이너 인스턴스의 서비스 작업은 서비스의 배치 구성 매개 변수 minimumHealthyPercent 및 maximumPercent에 따라 중지 및 교체됩니다.

스팟 인스턴스에 ECS 실제 작동
고객들이 어떻게 이미 스팟 인스턴스 위에 ECS 클러스터를 운영하고 있는지 알고 싶습니까? Mapbox에 있는 우리 친구들이 그 일을 하고 있습니다.

Mapbox는 맞춤 지도를 디자인하고 게시하기 위한 플랫폼입니다. 이 회사는 ECS를 사용하여 전체 일괄 처리 아키텍처에 전력을 공급하여 일일 1 억 마일이 넘는 센서 데이터를 수집하고 처리하여 지도에 사용합니다. 또한 스팟 인스턴스를 사용하여 ECS에서 일괄 처리 아키텍처를 최적화합니다.

Mapbox 플랫폼은 매달 5,000 개가 넘는 앱과 2 억 명 이상의 사용자에게 서비스를 제공합니다. 백엔드는 ECS에서 실행되므로 하루 13 억 건의 요청을 처리 할 수 있습니다. 그들의 ECS 로의 최근 이전에 대한 자세한 내용을 보려면 최근 블로그 게시물, We Switched to Amazon ECS, and You Won’t Believe What Happened Next를 읽으시기 바랍니다. 그리고 후속 블로그 게시물인 Caches to Cash에서 어떻게 그들의 전체 플랫폼을 스팟 인스턴스에서 운영하면서 EC2 비용을 50-90%이상 절약할 수 있었는지 배워보세요.

결론
스팟 인스턴스를 사용하여 규모가 크고 비용 효율적으로 컨테이너 응용 프로그램을 운영하는 것에 대해 우리만큼 흥분을 느끼시길 바랍니다. 자세한 내용은 다음 페이지를 참조하십시오.

의견이나 제안이 있으시면, 의견 부탁드립니다.

Chad Schmutzer, Solutions Architect Shawn O'Conner, Enterprise Solutions Architect
Chad Schmutzer
Solutions Architect
Shawn O’Connor
Solutions Architect

원문: Powering your Amazon ECS Cluster with Amazon EC2 Spot Instances

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 이창수 솔루션즈 아키텍트께서 번역해주셨습니다.

EC2 Spot Fleets – 신규 자동 스케일링 기능

EC2 Spot Fleet API – 한번에 수천개의 스팟 인스턴스 관리하기 글을 통해 한번의 요청에서 EC2 스팟 인스턴스 집합을 만들 수 있습니다. 스팟 집합 대상 용량을 지정하고 시간 당 입찰 가격을 입력하고, 인스턴스 유형을 선택하면됩니다.

백그라운드 작업을 통해 AWS는 최저가 스팟 인스턴스를 시작하여 필요한 대상 용량 (인스턴스 또는 가상 vCPU의 숫자로 표기)을 유지합니다. 인스턴스 집합 가격 상승으로 종료되면, 그 시점에서 최저가 인스턴스 교체가 시작됩니다.

신규 자동 확장 기능
오늘 스팟 집합 모델에 Auto Scaling을 추가함으로서 기능을 더욱 강화하였습니다. Amazon CloudWatch 메트릭을 기반으로 스팟 집합을 스케일-업 혹은 다운 할 수 있게되었습니다. 본 통계치를 통해 EC2, Amazon EC2 Container Service, 또는 Amazon Simple Queue Service (SQS) 등의 AWS 서비스 역시 사용할 수 있습니다. 또한, 응용 프로그램에서 만든 맞춤 통계수치를 사용하여 자동 스케일링이 시작되도록 할 수도 있습니다. 따라서, 이러한 통계 수치를 사용하여 스팟 집합의 크기 제어, 조건이나 부하가 바뀌더라도 응용 프로그램 가용성 및 성능과 비용을 세부적으로 제어 할 수 있습니다.

아래는 스팟 집합 자동 스케일링에 사용할 수 있는 애플리케이션의 예제들입니다.

  • 콘테이너 동작Amazon ECS에서 CPU 및 메모리 사용량을 기반한 콘테이너 기반 애플리케이션의 확장
  • 일괄 작업SQS 큐의 메시지 수를 기반한 일괄 작업의 확장
  • 스팟 집합MaxPercentCapacityAllocation와 같은 스팟 집합 통계를 기반한 집합 확장
  • 웹 서비스 – 초당 평균 요청 및 반응 시간에 따른 웹 서비스 확장

스팟 인스턴스 콘솔이나 AWS Command Line Interface (CLI), AWS CloudFormation, 및 AWS SDKs API 호출을 자동 스케일링을 설정할 수 있습니다.

잠깐 실제 콘솔에서 설정 방법을 살펴 보고자 합니다. 스팟 집합을 시작하고 이를 스케일업/다운을 하기 위해 Request and maintain 요청 형식을 선택합니다.

스팟 집합이 1분내로 올라옵니다.

예제로 SQS 큐를 만들고 일부 메시지를 큐에 넣은 다음 CloudWatch 알람​​(AppQueueBackingUp)을 정의했습니다. 메시지 큐에 10 건 이상의 메시지가 들어가면 알람이 시작됩니다.

또한, 알람 (AppQueueNearlyEmpty)도 정의했습니다. 이는 메시지 큐에 메시지가 2 건 이하가 될 때, 취소되는 것입니다.

마지막으로, 알람을 스팟 집합의 ScaleUpScaleDown 정책에 연결했습니다.

이 글을 쓰기 전에 SQS 대기열에 5개의 메시지를 넣었습니다. 스팟 집합을 시작하고 스케일링 정책을 설정한 후, 추가로 5개의 메시지를 보내 알람이 시작되는 것을 기다렸습니다.

스팟 함대 용량이 예상대로 증가한 것으로 나타났습니다. 이 결과는 History 탭에 표시되었습니다 ( “New targetCapacity : 5”).

마무리로 큐에서 모든 메시지를 삭제하고, 돌아 가면 스팟 집합이 예상대로 축소 된것을 알 수 있습니다 ( “New targetCapacity : 2”).

정식 출시
스팟 집합 자동 스케일링 기능은 스팟 인스턴스가 지원되는 모든 리전에서 지금 부터 바로 이용할 수 있습니다.

Jeff;

본 글은 New – Auto Scaling for EC2 Spot Fleets의 한국어 번역입니다.

EC2 스팟 인스턴스, 서울 리전 서비스 개시!

지난 서울 리전 론칭 이후 국내 고객들이 많이 기다리시던 소식입니다! 바로 오늘 부터 Amazon EC2 Spot instances를 Asia Pacific (Seoul) 리전에서 사용할 수 있습니다. (영문 공지 참고)

AWS 고객들은 특정 분야의 IT 업무를 수행하기 위해, 경매 방식을 통해 AWS의 유휴 자원을 온디멘드 인스턴스 보다 최대 90% 이상 저렴한 스팟 인스턴스로 활용할 수 있습니다. 저렴한 가격 뿐만 아니라 컴퓨팅 자원 확장성과 성능을 비용 대비 최대 효과를 얻어 새로운 형태의 클라우드 기반 애플리케이션을 구축할 수 있습니다.

Spot Instances를 통해 확장성을 높임과 동시에 비용 효율적인 애플리케이션 구축을 원하신다면   AdRoll, National Instruments, Lyft, Novartis, 및 Fin Design + Effects 같은 고객 사례를 확인해 보시면, 빅데이터 분석, 과학 연구 및 비디오 인코딩 등 다방면에 사용하고 있습니다.

특히 한국 고객 중 무료 음악 스트리밍 서비스를 제공하는 모바일 앱인 Beat를 개발 운영하는 비트패킹컴퍼니의 경우, EC2 스팟 인스턴스를 매우 잘 활용하는 고객사입니다. 지난 AWS Cloud 2016에서 관련 사례 발표를 하신 정민영 CTO의 발표를 아래의 동영상을 통해 확인하실 수 있습니다.

스팟 인스턴스에 대해 자세히 알고 싶으신 분은 EC2 문서의 스팟 인스턴스를 참조하시고, 비용에 대해서는 Amazon EC2 Spot 요금표를 참고하시기 바랍니다.

더 자세한 정보

스팟 집합 작업

관련 블로그 글

– AWS 코리아 마케팅 팀

EC2 스팟 인스턴스에서 자원 중심 입찰 기능 제공

올해 초에 EC2 Spot 집합 API를 소개했습니다. 이전 글에서 언급했듯이 한번의 API 요청으로 Spot 집합 인스턴스를 시작하고 관리 할 수 있습니다. 스팟 인스턴스 집합 구성을 필요로 하는 용량 시간 당 입찰 가격 인스턴스 유형을 지정하면, Spot 집합은 최저가의 EC2 용량을 찾아 내고 그 용량을 유지 합니다.

오늘은 기존 입찰 방식에 가중치를 적용하여 Spot 집합 API 기능을 더욱 강화했습니다. 새로운 기능을 통해 인스턴스 유형 및 가용 영역 안에서 애플리케이션에 가장 적합한 입찰을 진행할 수 있습니다. RequestSpotFleet API를 호출 할 때 (인스턴스 당) 입찰 가격을 지정합니다. 하지만, 요구하는 자원에 대한 자세한 조건을 주면 더 좋을 것입니다. 예를 들어, 최소 488GiB 메모리를 2개 이상의 R3(메모리 최적화) 인스턴스를 원하거나 최소 128vCPU을 C3와 C4(컴퓨팅 최적화) 인스턴스 조합으로 원하는 경우 등입니다.

신규 자원 중심 입찰 방식
새로운 자원 중심의 입찰 모델은 이러한 종류의 스팟 집합 인스턴스 요청이 가능합니다. 각 인스턴스는 만들어질 집합 크기에 영향을 주는 여러 가지 자원을 “용량 단위(capacity units)”로 유지합니다. 앞의 예제처럼 몇 GB의 RAM 또는 얼마의 vCPU 자원이 필요한가? 또는 EBS 최적 대역폭 계산 능력, 네트워크 성능 및 기타 응용 프로그램 고유 단위 등이 많습니다. 이러한 용량 단위 Spot 인스턴스 집합의 요청 매개 변수로 사용 용량 단위 전체에 대한 각 인스턴스 비율도 알려드립니다.

이를 통해 각 인스턴스 유형을 실제로 사용할 수 있는지 여부에 신경 쓰지 않고, 여러 인스턴스 유형의 자원을 경우에 따라서는 여러 가용 영역에 걸쳐 사용할 수 있습니다. 각 RequestSpotFleet 요청에는 여러 시작 설정 (launch specification)을 지정할 수 있고, 요청한 인스턴스 유형에 따라 AMI를 지정할 수 있습니다. 각 시작 설정 (launch specification)에는 다음과 같은 값을 지정할 수 있습니다 :

  • WeightedCapacity – 지정된 인스턴스 유형이 전체 용량 중 얼마나 차지하게 할지를 지정합니다. Spot 인스턴스 입찰을 할 때 유닛마다 입찰 가격을 계산합니다. 예를 들어, 15.25GB 메모리 r3.large 인스턴스에 비해서, 30.5GB 메모리를 탑재 한 r3.xlarge 인스턴스에 대해 2배의 비용을 지불한다는 입찰이 가능합니다.
  • SpotPrice – 특정 유닛 단위의 입찰 가격으로 인스턴스의 입찰가보다 우선합니다. 이 값을 사용하면 특정 인스턴스 유형, 가용 영역이나 서브넷을 선택하거나 하지 않도록 하는 것이 가능합니다.

아래는 메모리 기반의 시작 설정의 한 사례입니다.

Instance Type Instance Weight
 r3.large  15.25
 r3.xlarge  30.5
 r3.2xlarge  61
 r3.4xlarge  122
 r3.8xlarge  244

먼저 원하는 용량인 488GB를 지정하고 이에 대한 대상 용량에 대한 입찰 가격 (GB/시간)을 RequestSpotFleet를 실행하면, 이 경우 r3.large에 비해 r3.8xlarge는 16배 높은 가격을 지불하고 선언 한 것입니다.

EC2 서비스에서는 이 정보를 바탕으로 유닛 당 Spot 가격이 최저에서 사용 가능한 인스턴스를 찾아 가장 경제적인 조합의 스팟 인스턴스 집합을 구축합니다. 다음과 같이 단일 인스턴스 유형을 사용한 간단한 구성이 가능합니다 :

  • 2 x r3.8xlarge
  • 4 x r3.4xlarge
  • 8 x r3.2xlarge
  • 16 x r3.xlarge
  • 32 x r3.large

조금 더 복잡하게 한다면 다음과 같습니다.

  • 1 x r3.8xlarge and 2 x r3.4xlarge
  • 2 x r3.4xlarge and 8 x r3.xlarge
  • 8 x r3.xlarge and 16 x r3.large

시간이 지남에 따라 스팟 가격 상승으로 인스턴스가 중단 된 경우, 필요한 자원을 보충하기 위한 대체 인스턴스가 시작됩니다. 이 경우, 여러분의 애플리케이션은 인스턴스 유형 (및 사용할 수 있는 메모리 용)을 감지하여 조정해야 합니다. 스팟 집합에서는 사용 가능한 리소스를 사용하여 지정된 용량을 달성하기 위해 최대 인스턴스를 추가로 확보하게 됩니다. 이전 예제에서는 512GiB 전체 집합 인스턴스의 용량을 요청했을 때 발생합니다. 또한, 작은 요청이나 용량이 큰 인스턴스가 최저가(유닛 당) 가격인 경우에도 비슷한 일이 발생합니다.

용량 단위에 대해
용량 단위는 사전에 정해져 있으며, 인스턴스의 물리적 특성과 직접 매핑할 필요는 없습니다. 몇 가지 벤치 마크 테스트를 하여 인스턴스 유형별 트랜잭션 비율(TPS)을 측정하고 있다면, 필요한 TPS를 처리 할 수​​있는 전체 용량을 요청하는 그 시점에서 가장 경제적인 EC2 인스턴스 유형을 제시합니다. 사실 스팟 인스턴스 기법은 기술과 비즈니스의 교차점에 있습니다. 여러분의 비즈니스 경제성을 개선할 수 있고, (온디멘드 인스턴스 가격보다 90% 이상 비용 절감하기 위해) 창의적이고 혁신적인 여지가 많이 있습니다.

이러한 입찰 메커니즘을 사용하면 원하는 가용 영역의 WeightedCapacity 값을 높이고, 우선 순위를 제어할 수 있습니다. 예를 들어, 동일한 인스턴스 유형으로 여러 설정을 해두고, 다른 가용 영역에 서로 다른 가중치를 설정 할 수 있습니다.

API 요청은 AWS Command Line Interface (CLI)를 사용하거나 RequestSpotFleet API를 호출하십시오.

이 기능은 모든 리전에서 스팟 인스턴스를 사용할 때 사용 가능합니다.

Jeff;

PS – EC2 스팟 인스턴스에 대한 자세한 사항은 스팟 인스턴스 분류글을 참고하시기 바랍니다.

본 글은 New – Resource-Oriented Bidding for EC2 Spot Instances의 한국어 번역입니다.

EC2 Spot 인스턴스를 통해 가격에 민감한 앱 만들기

지난번에 EC2 Spot 인스턴스의 모범 사례 에 대한 기사를 연재할 계획을 말씀드린 바 있습니다. 그 첫번째로 Spot 인스턴스를 사용하여 어떻게 하면 가격 기반 응용 프로그램을 개발할 것인가? 라는 주제로 EC2 Spot 팀의 2 명의 시니어 개발자와 함께 이야기를 하였습니다. Dmitry Pushkarev (기술 개발 담당)와 Joshua Burgin(제품 관리자)과의 대화를 인터뷰 형식으로 편집해서 제공해 드립니다.



Jeff : Spot 인스턴스 가격의 진정한 의미는 무엇일까요?

Joshua : Spot 기반 무장애 응용 프로그램을 구축 할 때, 현재 가격과 과거 가격 기록은 중요한 고려 사항입니다. 가격을 잘 살펴봄으로서 가장 가능성 높은 용량 풀(Capacity Pool)에 응용 프로그램을 배포하거나, 서비스가 방해 받을 가능성을 줄이고 가격 성능을 전반적으로 향상시킬 수 있습니다.

Spot 시장에서 인스턴스 가격은 수요와 공급으로 정해집니다. 낮은 가격이라는 것은 수요보다 많은 용량이 있다는 것을 의미합니다. 낮은 가격이거나 낮은 변동폭으로 일정한 것은 그 용량 풀은 수요가 적다는 것을 의미합니다. 예를 들어, 이전 세대의 인스턴스가 그런 경향을 가집니다.(m1.small, c1.xlarge, cc2.8xlarge 등)


Jeff : 고객이 어떻게 (가격에 따라 인스턴스가 변동될 수 있는) 환경에서 애플리케이션을 구축할 수 있을까요?

Dmitry : (Spot 인스턴스를 이용하여) 장애가 나지 않도록 응용 프로그램을 설계할 때 ‘가격 기록’을 잘 사용하는 것은 중요합니다. 고객에게도 각각 배치 전략이있습니다만 일반적으로 두 가지 개의 성공 패턴이 있습니다. 하나는 가격 변동폭이 적은 용량 풀 (인스턴스 유형 및 가용 영역)을 선택하거나, 여러 용량 풀에 필요한 용량을 분산 배치하는 것입니다.

주식 시장이라는 좋은 예가 있습니다. “가장 좋은 성능”의 용량 풀을 찾아 정기적으로 그 선택에 대해 다시 확인 할 수 있으며, 관련이 없는 풀에 걸쳐 분산시켜 장애 위험을 크게 줄일 수 있습니다.


Jeff : 용량 풀의 배치 전략에 대해 자세히 알려주세요.

Joshua : 가격 변동 폭이 안정적인 풀을 찾기 위해 최근 Spot 가격 기록을 분석하는 아이디어가 있습니다. 용량 풀에서 입찰 희망 가격(매 시간에 지불한 최대 가격)을 초과 한 최근 시점부터 현재까지 기간으로 분석하는 방법입니다. 과거의 경향이 결코 미래의 결과를 보장하는 것은 아니지만, 처음 패턴을 보기에 좋은 방법입니다. 이 전략은 개발 테스트 환경이나 장시간 분석 작업을 하는 인스턴스에 좋습니다. Amazon EMR 클러스터에 용량을 추가하는 방법으로도 좋구요. 이익을 극대화하면서 용량 풀을 계속 사용하실 거라면, 입찰 후 어느 정도 경과 한 후에는 가격을 재검토하는 것도 추천합니다.

Jeff : 고객들이 Spot 가격 기록을 어떻게 볼 수 있습니까?
Dmitry : 콘솔 또는 SDK 및 AWS 명령어 인터페이스 (CLI) 프로그램에서 볼 수 있습니다.
또한, Spot 페이지에서 접근 가능한 웹 기반 Spot Bid Advisor을 새롭게 만들었습니다. 이 도구는 여러 가용 영역 평균 통계를 표시하고 가격 변동이 작은 인스턴스 유형을 찾아기 쉽습니다. 리전, 운영 체제, 입찰 가격 (온 디멘드의 25 %, 50 %, 100 %)을 선택하면 지난 주 또는 매월 변화, 과거 빈도를 표시합니다.

GitHub의 저장소 aws-spot-labs 에 또 다른 예가 있습니다. get_spot_duration.py 스크립트로 Spot 가격 정보를 취득하여 입찰 희망 가격을 초과한 기간에 근거하여 인스턴스 유형 및 가용 영역을 사용할 수 있습니다.


Jeff : 그렇군요. 큰 인스턴스 풀을 선택하고 정기적으로 다시 살펴봐야 하는군요.

Dmitry : 네. 그게 좋은 출발점입니다. Spot을 보다 쾌적하게 사용하는 다음 단계로는 동시에 여러 풀을 사용하는 용량을 분산하는 것입니다. 왜냐하면 각 용량 풀은 물리적으로 분리되어, 가격에 관련된 이슈가 거의 없기 때문입니다. 여러 용량풀이 단기간에 동시에 가격이 상승하는 일은 매우 드뭅니다. 이를 통해 문제가 발생할 영향을 줄일 수 되고, 필요한 용량을 확보하는 데 충분한 시간을 얻을 수 있습니다.

Joshua : 이러한 용량 분산 방법은 장기적인 가격 대비 성능도 개선합니다. 만약 여러 인스턴스 유형 및 가용 영역에 균등하게 용량을 분산하고 시간 단가는 여러 풀에서 과금되므로 결과적으로 좋은 가격 대비 성능입니다.


Jeff : 너무 좋네요. 그 다음 단계가 될 입찰 전략은 어떨까요?
Joshua : 지불하고자하는 가격에 적절하게 입찰하는 것이 중요합니다. 부당하게 높은 Spot 입찰을 하는 것보다 여러 용량 풀을 신중하게 선택하고 거기에 애플리케이션을 분산 배치하여 고가용성을 제공하는 것이 좋습니다. 현재 용량 풀 가격이 상승하고 있다는 것을 발견하면, 그것은 수요가 증가하고 있다는 의미입니다. 문제를 피하기 위해 더 저렴한 풀에 업무를 마이그레이션하거나 높은 가격으로 놀고 있는 인스턴스를 종료할 것을 추천합니다.


Jeff : 더 정교한 입찰 전략을 사용하는 고객이 있습니까?

Dmitry : 많은 고객이 Spot을 사용할 수록 경쟁력 면에서 중요합니다. 프로덕션 환경을 모두 Spot에서 실행하는 고객도 있습니다. 물론 그들의 SLA를 충족하도록 추가 엔지니어링이 필요하지만… Spot에 대한 생각에 대해 의미 있는 이야기는 “클라우드 친화적” 응용 프로그램이 Spot에 의한 효과를 얻고 있다는 것입니다. 설계에 의한 복원력, 유연성, 가격을 인식하고 있다는 것을 의미합니다. 가격을 인식하고 가장 비어있는 용량 풀에 응용 프로그램을 배포 할 수 있습니다. 특히 신생 기업은 빨리 확장시키고 보다 저렴 컴퓨팅 인프라를 사용하기 위해 독창적으로 Spot을 사용하고 있습니다.

Joshua : Auto Scaling, Spot 모음, Elastic MapReduce와 같은 도구는 Spot을 조합 할 수 있으며, 특별한 추가 개발을 하지 않고 여러 용량 풀을 동시에 사용할 수 있습니다.

Spot 인스턴스에 대한 정보를 얻기 위해 앞으로도 블로그를 계속확인해 주십시오! 언제든지 여러분의 Tips(과 질문)을 댓글에 써주세요.

– Jeff ;

이 글은 Building Price-Aware Applications Using EC2 Spot Instances의 한국어 번역입니다.

EC2 스팟 인스턴스 – 베스트 프랙티스 소개

Amazon EC2 스팟 인스턴스가 글로벌 규모의 다양한 활용성이 높은 서비스를 구현할 수 있는 기능이라고 자주 언급했습니다.

전 세계에 걸쳐 많은 사용자와 업무 그리고 이를 위한 대규모 컴퓨팅 자원을 가지고 있지 않다면, 시장을 창출하는데 필요한 수요와 공급에 있어 변화에 크게 영향을 받을 필요가 없습니다. 이를 위한 해법인 스팟 인스턴스는 EC2 용량을 경매를 통해 구매해서 온디멘드 가격 보다 90% 정도 저렴하고, 누군가 여러분의 가격 보다 높은 가격을 쓰면, 2분 정도의 경고 시간을 가지고 인스턴스가 종료됩니다.

스팟 인스턴스는 바로 쓰고 버려지기 때문에, 이를 잘 활용해서 가치를 극대화하기 위해 지속적인 운영을 위한 경매 전략을 철저히 세울 필요가 있습니다. 여러분이 만약 제대로 응용 프로그램을 구축하고 있다면, 최대 90%의 비용 절감 효과(또는 고정 예산으로 10배의 계산 능력)를 얻을 수 있습니다. 여러분이 클라우드 아키텍트라면, 매우 흥미로운 사실로서 가격을 고려하면서 탄력성 높은 응용 프로그램을 만들거나 컴퓨팅 연산 능력의 비용을 줄이는 방법을 직접 훈련해 볼 수 있습니다. 스팟 인스턴스의 장점과 단점을 학습하면, 여러분에게 큰 이익을 드릴 수 있을 것입니다.

명확한 새로운 기술 경향
EC2의 과거를 돌아보면 (온 디맨드 인스턴스, 스팟 인스턴스, 컨테이너, 스팟 그룹), 기술 트렌드는 명확합니다. 지금까지 오랜 시간 실행 중인 인스턴스와 가격표에 신경 써 왔다면, 앞으로는 (동일한 속성을 공유하는 인스턴스 그룹)의 개별 처리 용량 내에서 수요와 공급에 따라 가장 최적의 가격을 제공하는 중간 단계의 라이프타임을 가지는 인스턴스의 집합을 생각해 볼 필요가 있습니다. 이러한 새로운 아이디어는 과거의 사고 패턴에서 좀 더 열린 방식으로 대량 컴퓨팅 용량을 빠르고 싸게 얻기 위해 새롭게 매력적인 방법으로 가격에서도 정말 멋진 응용 프로그램을 구축 할 수 있습니다.

스팟 인스턴스를 쓰기 시작하면 상호 윈윈 모델이라는 것을 말씀 드려야 할 것 같습니다. 그 시점에서 가장 경제적인 가격으로 컴퓨팅 파워를 얻을 수 있습니다. 이와 마찬가지로 아마존은 소유하고 있는 서버군(참고 : AWS 글로벌 인프라 페이지)에 대해 높은 가동률을 유지 할 수 있습니다. 높은 가동률은 아마존의 비용 구조를 개선하고 친환경적인 혜택도 제공합니다.

스팟 인스턴스 모범 사례
몇 개월 내에 EC2 스팟팀의 지원을 통해 스팟 인스턴스 활용에 대한 모범 사례를 공개할 계획입니다. 대부분은 실제로 우리 고객들이 공유해 주신 예제를 기반으로 합니다(이론이나 학술 적인 것은 아닙니다). 오늘은 몇 가지 모범 사례에 대한 간략한 개요를 소개하고자 합니다.

용량 풀(Pool)에 대한 정의 – 앞서 살펴본 봐와 같이 용량 풀은 지역(Region), 가용존(Availability Zone) 운영 시스템 (Linux/Unix 또는 Windows) 인스턴스 유형이 동일한 EC2 부팅 인스턴스의 모음입니다. 각 EC2 용량 풀은 가용성(그 시점에서 부팅 가능한 인스턴스 수), 수요와 공유를 통해 가격이 책정됩니다. 나중에 살펴 보겠지만, 하나 이상의 용량 풀에 걸쳐 실행 가능한 응용 프로그램은 저렴하게 컴퓨팅 파워를 접근할 수 있는 상태에 있고 풀의 용량은 온 디멘드와 스팟 인스턴스로 공유되기 때문에, 스팟 인스턴스의 수요와 온디맨드 인스턴스 수요에 따라 가격이 조금 올라갈 수는 있습니다.

이제 스팟 인스턴스의 몇 가지 모범 사례를 소개합니다.

가격 기반 응용 프로그램 구축 – 이전에도 언급 한대로 클라우드 컴퓨팅은 비즈니스 모델과 기술의 조합입니다. 가격을 고려하여 코드를 작성 (또는 시스템을 설계)할 수 있으며, 향후에 더 많은 클라우드 예산을 얻을 수 있는 가능성이 있습니다. 많은 개발자에 있어서 새로운 영역입니다. 여러분의 이력서나 직무 영역에 비용 절감을 위한 인프라 설계를 포함해보시기 바랍니다.

여러분의 시간을 투자하여 (EC2 API , AWS Command Line Interface (CLI) 등을 사용하여 도구를 만들어) 응용 프로그램이 사용하는 리전의 용량 풀을 이용해 볼 수 있습니다. 높은 가격과 높은 가격 변동성을 가진 경우, 같은 용량 풀에 경쟁이 많다는 것을 의미합니다. 보다 효과적이고 낮은 인터럽트 비율을 얻기 위해 (현재 또는 과거의) 더 저렴하고 안정적​​인 할인 가격을 가진 풀을 찾아보세요.

과거 가격 기록 확인하기 – 지난 90일(3 개월)에 거슬러 용량 풀 당 가격 기록을 볼 수 있습니다. 현재 고객에게 매우 인기 있는 인스턴스 (이 블로그를 작성하는 시점에서는 R3)는 스팟 가격이 불안정합니다. 이전 세대 (c1.xlarge, m1.small, cr1.8xlarge, cc2.8xlarge 등)은 비교적 안정된 경향을 가지고 있습니다. 일반적으로 이전 세대의 인스턴스를 선택하면 저렴한 가격으로 방해를 적게 받을 수 있습니다.

다중 용량 풀을 사용하기 – 다양한 응용 프로그램은 다중 용량 풀에 나눠져 실행할(또는 실행 할 수 있도록 쉽게 적용 가능) 수 있습니다. 다중 용량 풀에서 실행할 수 있게 되면, 어떠한 용량 풀 또는 두 개 용량 풀에 영향을 주는 가격 변동에 대한 과민도를 줄일 수 있습니다 (일반적으로 서로 다른 용량 풀 사이에 가격 상관 관계는 거의 없습니다). 예를 들어, 다섯 개의 용량 풀을 사용하면 가격 변동 및 방해 정도는 80% 가까이 감소합니다.

이러한 몇 가지 베스트 프랙티스를 통한 높은 수준의 접근 방식은 활용하면, 유연성 등 여러 측면에서 많은 용량 풀에 접근할 수 있습니다. 여러 AZ에 걸쳐 앱을 실행할 수 있고(실제로 Auto Scaling 및 스팟 그룹 API를 조합 가능), 또는 동일한 인스턴스 패밀리 중에서도 여러 인스턴스 타입에 걸쳐서 실행할 수 있습니다 (Amazon EMR 역시 같은 접근 방법입니다.) 예를 들어, 응용 프로그램이 필요한 vCPU 수를 알고 있다면 그 수를 확보하여 충분한 작업자 스레드를 시작할 수 있습니다.

이러한 모범 사례를 준수하는 것은 각 용량 풀이 거의 같은 양을 사용하도록 노력할 필요가 있습니다. 이것은 스팟 용량과 스팟 가격 변동에 의한 영향을 최소화할 수 있습니다.

더 자세히 알고 싶으신 분은 EC2 문서의 스팟 인스턴스를 참조하십시오.

더 자세한 정보를 기대하세요!

이미 언급했듯이 이 글은 서론이며, 앞으로 많은 아이디어와 실제 코드를 제공하고자 합니다. 의견이 있는 경우 또는 여러분의 스팟 Tips를 제공하고 싶은 경우 awseditor@amazon.com에 문의하십시오.

– Jeff ;

이 글은 Focusing on Spot Instances – Let’s Talk About Best Practices 한국어 번역입니다.

EC2 Spot Fleet API – 한번에 수천개의 스팟 인스턴스 관리하기

지난 9년간 Amazon Elastic Compute Cloud (EC2)의 서비스 진화를 살펴 보는 것은 매우 흥미롭습니다. 초기에는 단일 인스턴스 타입을 단일 리전에서 사전에 정해진 주문형 가격에서 시작하였습니다. 지금은 다양한 인스턴스 타입이 11개의 리전 (AWS GovCloud (US) 포함)에서 시작할 수 있으며, 예약 인스턴스 및 스팟 인스턴스(현재 9 지역)를 선택할 수 있습니다. 그동안 EC2에 많은 기능을 추가했고, Amazon EMR, AWS Elastic Beanstalk, Amazon WorkSpaces, Amazon EC2 Container Service, AWS Lambda 등 다른 서비스의 빌딩 블록으로 사용되고 있습니다.

신규 스팟 집합 API
오늘 스팟 인스턴스의 집합을 바로 시작하고 제어 할 수 있는 새로운 API를 추가하였으며, 이를 통해 더욱 쉽게 스팟 인스턴스를 사용할 수 있게 되었습니다. (스팟 집합은 분산 응용 프로그램에서 병렬로 작동하는 스팟 인스턴스의 집합입니다. 스팟 집합으로는 일괄 처리 작업 및 Hadoop 워크 플로우, HPC 그리드 컴퓨팅 작업을 할 수 있습니다.) 많은 AWS 고객은 가장 낮은 비용으로 다양한 업무 영역(분자 생물학 시뮬레이션 연구에서 지속적인 통합 환경에 이르기까지)을 수행하기 위해 여러 인스턴스 유형과 가용 영역에서 사용 가능한 컴퓨팅 용량을 찾고, 시장 가격을 모니터링하여 입찰 가격을 관리하는 자체 코드를 만들어 적게는 몇 백에서 몇 천의 인스턴스 그룹을 시작할 수 있습니다.

새로 공개한 API RequestSpotFleet를 통해 스팟 집합의 대상 용량 시간 당 입찰 가격 및 부팅 인스턴스 유형을 지정하기만 하면 인스턴스를 띄울 수 있습니다. 최저가의 용량을 찾아 스팟 집합의 목표 용량을 유지할 수 있습니다. 일단 API 호출에서 이러한 모든합니다.

API 요청 시작하기

한 리전에서 최대 1000개의 활성 스팟 집합을 가질 수 있습니다. 하나의 스팟 집합과 한 개의 리전에 대해 3000개의 인스턴스 제한이 있습니다 (일반 계정이나 리전마다 있는 EC2의 상한도 그대로 유효하므로, 부팅할 인스턴스 갯수나 만들 수 있는 Amazon Elastic Block Store (EBS) 볼륨 수에도 제한이 걸립니다).

API 및 CLI를 통해 각 요청은 다음 값을 지정 해야 합니다 :

  • 대상 용량 – 스팟 집합에 넣고 싶은 EC2 인스턴스 수 (지정하지 않으면 기본값은 1)
  • 최대 입찰가 – 지불하려고 최대 입찰가
  • 시작 설정 – 시작하려는 인스턴스 수와 인스턴스 유형 및 시작 설정 (AMI Id, VPC 서브넷과 가용영역, 보안 그룹, 블록 디바이스 매핑 사용자 데이터 등). 더 싸고 사용하기 위해서는 일반적으로 부팅 설정에서는 특정 서브넷이나 가용 영역을 지정하지 않습니다.
  • IAM 역할 이름 – EC2가 스스로 종료하기 위해 필요합니다.

각 요청은 다음의 옵션 값을 포함 할 수 있습니다.

  • 클라이언트 토큰 –호출을 식별하는 고유한 문자열 (대소 문자 구분). 스팟 집합 요청을 위한 멱등 보장을 위해 사용할 수 있습니다.
  • 유효 기간 시작 날짜 – 호출 시작 날짜 및 시간
  • 유효 기간 종료 날짜 – 호출 종료 시간
  • 유효 기간 종료시 종결 – TRUE를 지정하면 호출 종료 시간에 스팟 집합의 모든 인스턴스가 종료됩니다. FALSE(기본값)으로 스팟 인스턴스는 그대로 실행을 계속하지만, 새로운 인스턴스를 시작합니다.

RequestSpotFleet API가 성공적으로 호출 되면 스팟 집합 요청 ID를 반환하며, 요청이 이상한 경우는 오류를 반환합니다. 사용할 수 없는 인스턴스 유형을 요청한 경우에도 오류를 받게됩니다.스팟 집합 요청 ID를 사용하여 DescribeSpotFleetRequests, DescribeSpotFleetInstances, DescribeSpotFleetRequestHistory, CancelSpotFleetRequests 등 기타 스팟 집합 API를 호출 할 수 있습니다 (각 API는 명령 줄에서도 동일한 기능이 있습니다).

더 자세히 살펴 보기
일단 호출이 접수된 날짜가 정해지면 EC2 스팟 가격이 달라졌다 해도 요청한 용량을 유지하게 됩니다. 시작 설정에 따라 현재 현물 가격을 모니터링하기 시작합니다. 최저가로 용량을 확보하기 위해 상한에 들어가고 있으며 입찰 제한에 들어가고있는 경우 스팟 인스턴스 시작합니다. 스팟 가격이 상승하면 스팟 집합의 인스턴스는 종료됩니다, 그 시점에서 최저가의 시작 설정으로 교체됩니다.
이 설정은 요청이 만료 될 때까지 또는 취소 할 때까지 활성화됩니다. 스팟 집합의 인스턴스는 의도적으로 종결하지 않는 한 계속 실행됩니다. 앞서 언급 한 바와 같이, IAM 역할을 포함해야 합니다. 이를 통해 EC2는 자신을 종료할 수 있습니다.

고려해야 할 사항
다른 신규 AWS 기능과 마찬가지로 첫 번째 출시한 상태에서 해야 할 많은 기능을 계속해서 구현해 나갈 예정입니다. 예를 들어, 우리는 인스턴스 가중치 시스템을 추가할 계획을 가지고 있습니다. 이것은 각 부팅 설정의 상대적인 우선 순위를 수식으로 표현할 수 있도록 합니다. 대상 용량이라는 기능은 계산에 필요한 스팟 집합의 “마력”을 나타낼 수 단위를 표현합니다. 각 스팟 집합는 특정 AWS 지역에서 실행합니다. 장래 적으로는 두 개 이상의 지역에 걸쳐 스팟 집합을 지원할 예정입니다.

바로 이용 가능
오늘부터 공용 AWS 지역에서 스팟 집합 기능을 출시 할 수 있습니다. 스팟 집합의 기능은 무료로 시작한 EC2 인스턴스 현물 가격과 기타 이용한 자원에 대해서 지불합니다.

Jeff;

이 글은 Amazon EC2 Spot Fleet API – Manage Thousands of Spot Instances with one Request의 한국어 번역입니다.