Amazon EC2 스팟 모범 사례 - Amazon Elastic Compute Cloud

Amazon EC2 스팟 모범 사례

Amazon EC2는 AWS 클라우드의 예비 EC2 컴퓨팅 용량을 온디맨드 요금에 비해 최대 90% 할인된 가격으로 사용할 수 있도록 제공합니다. 온디맨드 인스턴스와 스팟 인스턴스 간의 유일한 차이점은 Amazon EC2에서 용량을 다시 회수해야 할 때 Amazon EC2가 2분 전 알림을 통해 스팟 인스턴스를 중단할 수 있다는 것입니다. 스팟 인스턴스를 최상의 상태로 사용하려면 사용 모범 사례를 이해하고 적용하는 것이 중요합니다.

스팟 인스턴스는 유연한 상태 비저장, 내결함성 애플리케이션에 권장됩니다. 예를 들어 스팟 인스턴스는 빅 데이터, 컨테이너화된 워크로드, CI/CD, 상태 비저장 웹 서버, 고성능 컴퓨팅(HPC), 렌더링 워크로드에 적합합니다.

스팟 인스턴스는 실행 중인 동안에는 온디맨드 인스턴스와 정확히 동일합니다. 그러나 스팟은 실행 중인 인스턴스를 워크로드를 완료할 수 있을 만큼 충분히 오래 유지할 수 있다고 보장하지 않습니다. 또한 스팟은 찾고 있는 인스턴스의 즉각적인 가용성을 보장하거나 요청한 총 용량을 항상 확보할 수 있다고 보장하지 않습니다. 또한 스팟 인스턴스 가용성은 수요와 공급에 따라 달라지기 때문에 스팟 인스턴스 중단 및 용량은 시간이 지남에 따라 변할 수 있으며 과거의 성능이 미래의 결과를 보장하지 않습니다.

스팟 인스턴스는 유연성이 없거나 상태 저장이거나 내결함성이 없거나 인스턴스 노드 간에 밀접하게 연결된 워크로드에 적합하지 않습니다. 수시로 전체 목표 용량을 완전히 사용할 수 없는 경우를 허용하지 않는 워크로드에는 스팟 인스턴스를 권장하지 않습니다. 스팟 모범 사례를 따라 인스턴스 유형과 가용 영역을 유연하게 조정하면 고가용성을 확보할 수 있는 최상의 기회를 제공하지만, 온디맨드 인스턴스에 대한 수요가 급증하면 스팟 인스턴스의 워크로드가 중단될 수 있으므로 용량을 사용할 수 있다고 보장할 수는 없습니다.

이러한 워크로드에 스팟 인스턴스를 사용하거나 중단이나 가용성 손실을 처리하기 위해 온디맨드 인스턴스로 장애 조치를 시도하지 마세요. 온디맨드 인스턴스로 장애 조치하면 실수로 다른 스팟 인스턴스가 중단될 수도 있습니다. 또한 인스턴스 유형과 가용 영역 조합의 스팟 인스턴스가 중단되면 동일한 조합으로 온디맨드 인스턴스를 구하기가 어려워질 수도 있습니다.

숙련된 스팟 사용자인지 또는 스팟 인스턴스를 처음 사용하는지 관계없이 현재 스팟 인스턴스 중단 또는 가용성에 문제가 발생하는 경우 다음 모범 사례를 따라 스팟 서비스를 사용하는 최상의 환경을 제공하는 것이 좋습니다.

개별 인스턴스에서 중단 대비

스팟 인스턴스 중단을 정상적으로 처리하는 가장 좋은 방법은 내결함성이 있도록 애플리케이션을 설계하는 것입니다. EC2 인스턴스 리밸런싱 권고 및 스팟 인스턴스 중단 공지를 활용하여 이를 달성할 수 있습니다.

EC2 인스턴스 리밸런싱 권고는 스팟 인스턴스의 중단 위험이 높아질 때 알림을 보내는 신호입니다. 이 신호는 스팟 인스턴스 중단 2분 전 공지에 앞서 스팟 인스턴스를 사전에 관리할 수 있는 기회를 제공합니다. 중단 위험이 높아지지 않는 신규 또는 기존 스팟 인스턴스에 대한 워크로드를 리밸런싱하도록 결정할 수 있습니다. Auto Scaling 및 EC2 플릿의 용량 리밸런싱 특성을 사용하여 이 신호를 손쉽게 사용할 수 있습니다.

스팟 인스턴스 중단 공지는 Amazon EC2에서 스팟 인스턴스를 중단하기 2분 전에 생성되는 경고입니다. 워크로드가 '시간에 유연'한 경우 중단 시 스팟 인스턴스를 종료하는 대신 중지하거나 최대 절전 모드로 전환하도록 구성할 수 있습니다. Amazon EC2는 스팟 인스턴스 중단 시 자동으로 중지하거나 최대 절전 모드로 전환하며 가용 용량이 있을 때 인스턴스를 자동으로 다시 시작합니다.

Amazon EventBridge에서 리밸런싱 권고 및 중단 알림을 캡처하는 규칙을 생성한 다음 워크로드 진행에 대한 검사점을 트리거하거나 중단을 정상적으로 처리하는 것이 좋습니다. 자세한 내용은 리밸런싱 권고 신호 모니터링 섹션을 참조하세요. 이벤트 규칙을 생성하고 사용하는 방법을 안내하는 자세한 예제는 Amazon EC2 스팟 인스턴스 중단 공지 활용을 참조하세요.

자세한 내용은 EC2 인스턴스 리밸런싱 권고스팟 인스턴스 중단 섹션을 참조하세요.

인스턴스 유형 및 가용 영역에 대한 유연성 유지

스팟 용량 풀은 인스턴스 유형(예: m5.large)과 가용 영역(예: us-east-1a)이 동일한 미사용 EC2 인스턴스의 집합입니다. 요청하는 인스턴스 유형과 워크로드를 배포할 수 있는 가용 영역에 대한 유연성이 있어야 합니다. 그러면 스팟에서 필요한 컴퓨팅 용량을 찾고 할당할 가능성이 높아집니다. 예를 들어 c4, m5 및 m4 제품군의 large를 사용해도 무방하면 c5.large를 요청하지 마세요.

특정 요구 사항에 따라 컴퓨팅 요구 사항을 충족하기 위해 유연하게 선택할 수 있는 인스턴스 유형을 평가할 수 있습니다. 워크로드를 수직으로 확장할 수 있는 경우 요청에 더 큰 인스턴스 유형(vCPU 및 메모리 추가)을 포함해야 합니다. 수평으로만 확장할 수 있는 경우 이전 세대 인스턴스 유형을 포함해야 합니다. 이러한 인스턴스는 온디맨드 고객의 수요가 적기 때문입니다.

일반적으로 각 워크로드에 대해 최소 10개의 인스턴스 유형을 유연하게 선택할 수 있어야 합니다. 또한 모든 가용 영역이 사용자의 VPC에서 사용하도록 구성되고 워크로드에 맞게 선택되어야 합니다.

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

속성 기반 인스턴스 유형 선택을 통해 실행하려는 워크로드의 인스턴스 속성(예: vCPU, 메모리, 스토리지)을 지정할 수 있습니다. 그러면 EC2 Auto Scaling 또는 EC2 플릿이 지정된 속성과 일치하는 인스턴스를 자동으로 식별하여 시작합니다. 이렇게 하면 특정 인스턴스 유형을 수동으로 선택하는 데 드는 수고를 덜 수 있지만, 이를 위해서는 각 인스턴스 유형을 심층적으로 이해해야 합니다.

더욱이 속성 기반 인스턴스 유형 선택을 통해 새로 릴리스된 인스턴스 유형이 제공되면 자동으로 사용할 수 있습니다. 이를 통해 점점 더 다양해지는 스팟 인스턴스 용량에 원활하게 액세스할 수 있습니다.

속성 기반 인스턴스 유형 선택은 고성능 컴퓨팅(HPC) 및 빅 데이터 워크로드 등 실행되는 인스턴스 유형에 대해 유연한 워크로드 및 프레임워크에 이상적입니다.

자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성과 이 설명서에서 EC2 플릿 또는 스팟 플릿의 인스턴스 유형 선택에 대한 속성 지정의 내용을 참조하세요.

스팟 배치 점수를 사용하여 최적의 리전 및 가용 영역 식별

스팟 인스턴스는 미사용 EC2 용량이고, 이 용량은 EC2 공급 및 수요에 따라 변동됩니다. 따라서 특정 시간의 특정 위치에 필요한 정확한 스팟 용량을 항상 확보하지 못할 수도 있습니다. 이러한 예측 불가능성을 완화하기 위해 스팟 배치 점수 기능을 사용할 수 있습니다. 이 기능은 먼저 해당 위치에서 스팟 인스턴스를 시작할 필요 없이 필요한 스팟 용량을 충족하기에 충분한 용량을 보유할 가능성이 높은 리전 또는 가용 영역에 대한 권장 사항을 제공합니다.

스팟 배치 점수는 인스턴스 유형과 해당 인스턴스가 사용할 수 있는 리전 또는 가용 영역을 유연하게 조정할 수 있는 워크로드에 가장 적합합니다. 필요한 스팟 용량, 인스턴스 유형 요구 사항, 리전 또는 가용 영역에 대한 권장 사항 등을 지정하기만 하면 됩니다. 그에 따라 각 리전 또는 가용 영역에 대해 1~10점 범위의 점수를 받게 되는데, 이는 해당 위치에서 요청된 스팟 용량을 성공적으로 프로비저닝할 가능성을 나타냅니다. 10점은 스팟 요청이 성공할 가능성이 높음을 나타냅니다.

용량이 시간에 따라 달라질 수 있으므로 스팟 배치 점수는 특정 시점의 권장 사항이라는 점에 유의해야 합니다. 사용 가능한 용량을 보장하거나 중단 위험을 예측하지는 못합니다.

Amazon EC2 콘솔, AWS CLI, 또는 SDK에서 스팟 배치 점수 기능을 사용할 수 있습니다. 자세한 내용은 스팟 배치 점수 단원을 참조하십시오.

EC2 Auto Scaling 또는 EC2 플릿을 사용하여 총 용량 관리

스팟을 사용할 때는 개별 인스턴스가 아니라 총 용량(vCPU, 메모리, 스토리지 또는 네트워크 처리량이 포함된 단위)의 측면에서 생각할 수 있습니다. Auto Scaling과 EC2 플릿을 사용하면 목표 용량을 시작하고 유지 관리할 수 있으며 중단되거나 수동으로 종료된 모든 항목을 대체할 리소스를 자동으로 요청할 수 있습니다. Auto Scaling 또는 EC2 플릿을 구성할 때는 애플리케이션 요구 사항에 따라 인스턴스 유형과 목표 용량만 지정하면 됩니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서Auto Scaling 그룹과 이 사용 설명서의 EC2 집합 생성 섹션을 참조하세요.

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

Auto Scaling 그룹의 할당 전략은 예비 용량이 있는 스팟 용량 풀을 수동으로 찾을 필요 없이 목표 용량을 프로비저닝하는 데 도움이 됩니다. price-capacity-optimized 전략은 가장 사용 가능하고 가격도 가장 낮을 수 있는 스팟 용량 풀에서 인스턴스를 자동으로 프로비저닝하므로 이 전략을 사용하는 것이 좋습니다. EC2 플릿에서 price-capacity-optimized 할당 전략을 활용할 수도 있습니다. 스팟 인스턴스 용량이 최적의 용량을 가진 풀에서 소싱되기 때문에 스팟 인스턴스가 회수될 가능성이 줄어듭니다. 할당 전략에 대한 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서스팟 인스턴스와 이 사용 설명서의 워크로드의 중단 비용이 높은 경우 섹션을 참조하세요.

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

다른 AWS 서비스가 스팟과 통합되어 개별 인스턴스 또는 플릿을 관리할 필요 없이 전체 컴퓨팅 비용을 절감할 수 있습니다. 해당 워크로드에 대해 Amazon EMR, Amazon Elastic Container Service, AWS Batch, Amazon Elastic Kubernetes Service, Amazon SageMaker, AWS Elastic Beanstalk 및 Amazon GameLift와 같은 솔루션을 고려하는 것이 좋습니다. 이러한 서비스의 스팟 모범 사례에 대한 자세한 내용은 Amazon EC2 스팟 인스턴스 워크샵 웹 사이트를 참조하세요.

어느 스팟 요청 방법을 사용하는 것이 최선인가요?

다음 표를 사용하여 스팟 인스턴스를 요청할 때 어느 API를 사용할지 결정합니다.

API 언제 사용해야 하나요? 사용 사례 이 API를 사용해야 하나요?

CreateAutoScalingGroup

  • 단일 구성 또는 혼합 구성을 사용하는 여러 인스턴스가 필요합니다.

  • 구성 API를 통해 수명 주기 관리를 자동화하려고 합니다.

원하는 인스턴스 수를 유지하면서 인스턴스의 수명 주기를 관리하는 Auto Scaling 그룹을 생성합니다. 지정된 최소 및 최대 한도 사이의 수평적 크기 조정(인스턴스 추가)을 지원합니다.

CreateFleet
  • 단일 구성 또는 혼합 구성을 사용하는 여러 인스턴스가 필요합니다.

  • 인스턴스 수명 주기를 자체 관리하려고 합니다.

  • Auto Scaling이 필요하지 않은 경우 instant 유형 플릿을 사용하는 것을 권장합니다.

인스턴스 유형, AMI, 가용 영역 또는 서브넷에 따라 바뀌는 여러 출시 사양을 사용하여 단일 요청으로 온디맨드 인스턴스와 스팟 인스턴스의 플릿을 생성합니다. 스팟 인스턴스 할당 전략의 기본값은 단위당 lowest-price이지만, price-capacity-optimized, capacity-optimized 또는 diversified로 변경할 수 있습니다.

예 - instant 모드에서(Auto Scaling이 필요하지 않은 경우)

RunInstances
  • 이미 RunInstances API를 사용하여 온디맨드 인스턴스를 시작하고 있으며 단일 파라미터를 변경하여 스팟 인스턴스 시작으로 변경하려고 합니다.

  • 인스턴스 유형이 다른 여러 인스턴스는 필요하지 않습니다.

AMI와 하나의 인스턴스 유형을 사용하여 지정된 수의 인스턴스를 시작합니다.

아니요 - RunInstances가 단일 요청에서 혼합 인스턴스 유형을 허용하지 않기 때문

RequestSpotFleet
  • RequestSpotFleet API는 계획된 투자가 없는 레거시 API이므로 사용하지 않는 것이 좋습니다.

  • 인스턴스 수명 주기를 관리하려면 CreateFleet API를 사용하세요.

  • 인스턴스 수명 주기를 관리하지 않으려면 CreateAutoScalingGroup API를 사용하세요.

사용하지 않습니다. RequestSpotFleet은 계획된 투자가 없는 레거시 API입니다.

아니요
RequestSpotInstances
  • RequestSpotInstances API는 계획된 투자가 없는 레거시 API이므로 사용하지 않는 것이 좋습니다.

사용하지 않습니다. RequestSpotInstances는 계획된 투자가 없는 레거시 API입니다.

아니요