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

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에서 사용하도록 구성되고 워크로드에 맞게 선택되어야 합니다.

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 사용 설명서스팟 인스턴스와 이 사용 설명서의 워크로드의 중단 비용이 높은 경우 섹션을 참조하세요.

사전 예방적 용량 리밸런싱 사용

용량 리밸런싱을 사용하면 실행 중인 스팟 인스턴스에 스팟 인스턴스 중단 2분 전 공지가 수신되기 전에 미리 새 스팟 인스턴스로 플릿을 보강할 수 있으므로 워크로드 가용성을 유지하는 데 도움이 됩니다. 용량 리밸런싱이 활성화된 경우 Auto Scaling 또는 EC2 플릿에서는 리밸런싱 권고를 수신하는 스팟 인스턴스의 사전 교체를 시도하여 중단 위험이 높아지지 않는 새 스팟 인스턴스로 워크로드를 리밸런싱할 기회를 제공합니다.

용량 리밸런싱은 가격 및 용량 최적화 할당 전략(최적의 예비 용량을 찾는 데 도움이 되도록 설계됨)과 혼합 인스턴스 정책(여러 가용 영역에서 실행되는 다수의 인스턴스 유형에 인스턴스를 배포하여 가용성을 개선하도록 설계됨)을 보완합니다.

자세한 내용은 용량 리밸런싱 단원을 참조하십시오.

통합 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입니다.

아니요