스팟 및 온 디맨드 인스턴스를 사용한 EC2 자동 확장?


13

Auto-Scaling EC2 그룹이 주문형 인스턴스 대신 스팟 인스턴스를 시작하도록하여 비용을 최적화하려고합니다.

내가 정말로 원하는 것은 스팟 인스턴스 요금 시장에 어떤 영향을 미치는지에 관계없이 그룹의 일부 서버를 주문형 인스턴스로 유지하는 것입니다. 그런 다음 구성된 최소값 이상의 그룹에있는 추가 서버를 스팟 인스턴스로 만들고 싶습니다. 스팟 요청을 통해 서버를 추가하는 데 지연이 발생하는 것이 일반적입니다.

나는 이것을 할 수있는 방법을 찾지 못하는 것 같으며 AWS 설명서를 닦으려고 노력했습니다. ASG는 주문형 또는 스팟 일 수 있지만 하이브리드는 아닙니다.

자동 스케일링 그룹에 할당 된 Elastic Load Balancer에 온 디맨드 인스턴스를 수동으로 추가 할 수 있지만 해당 서버의로드는 자동 스케일링 측정 및 트리거에 포함되지 않습니다.

필자는 항상 필요한 서버를 확보하기 위해 엄청나게 높은 입찰 가격을 입력 할 수 있다고 생각하지만 가격 책정 내역을보고 가끔 급증하는 것을 볼 수 있습니다.

한 곳에서 서버 최소값을 입력하면 해당 숫자가 "확보"되었다고 말하기 때문에 AWS 설명서는 그 자체와 상충됩니다. 그러나 스팟 인스턴스에 대해 읽을 때는 보장이 없습니다. 현물에 대한 가격 차이는 매력적이므로 항상 기준을 유지하면서 최대한 많이 활용하고 싶습니다. 이게 가능해?

답변:


1

현재 단일 ASG에서 온 디맨드 인스턴스와 스팟 인스턴스혼합 할 수 있습니다.

Amazon EC2 Auto Scaling을 사용하면 단일 Auto Scaling 그룹 (ASG)의 구매 옵션, 가용 영역 (AZ) 및 인스턴스 제품군에서 인스턴스를 프로비저닝하고 자동으로 확장하여 규모, 성능 및 비용을 최적화 할 수 있습니다. 이제 단일 ASG에 온 디맨드 및 RI가있는 스팟 인스턴스를 포함시켜 컴퓨팅 비용을 최대 90 % 절약 할 수 있습니다.


예-이 질문을 업데이트 해 주셔서 감사합니다. 나는 이것에 대한 새로운 정식 답변으로 당신을 표시했습니다.
플랫폼

15

위에서 논의한 접근 방식은 약간 복잡하고 유연하지 않습니다. 더 많은 표준 접근 방식은 2 ASGs (자리 하나, 주문형 하나)를 만든 다음이를 등록하는 것 모두 같은 ELB (논의와 여기 ). 이를 통해 단일 ASG에서 LC 스왑을 사용하지 않고 각각을 독립적으로 제어 할 수 있습니다.


7

하이브리드 Auto Scaling 접근 방식은 불행히도 실제로 사용 가능한 것으로 보이지 않습니다.

그러나이 제한을 다음과 같이 해결할 수 있습니다 (잠시 동안 저글링 한 시스템 설계는 아닙니다).

잠재적 해결 방법

Auto Scaling을 사용하여 스팟 인스턴스 시작에 설명 된대로 스팟 가격 입찰은 사용중인 시작 구성 의 매개 변수입니다 . 지적했듯이 사용 가능한 하이브리드 시작 구성 은 없으며 주문형 또는 스팟이어야합니다. 즉, 사용 사례에는 두 가지 다른 시작 구성이 필요합니다.

다음과 같은 (부분적으로 오래된) 제약 조건으로 한 번에 하나의 시작 구성 만 Auto Scaling 그룹에 연결할 수 있기 때문에 즉시 도움이되지 않는 것 같습니다 ( 시작 구성 참조 ).

Auto Scaling 그룹에 새로운 시작 구성 또는 업데이트 된 시작 구성을 연결하면 새로운 구성 매개 변수를 사용하여 새 인스턴스가 시작됩니다. 기존 인스턴스는 영향을받지 않습니다 . Auto Scaling을 축소해야하는 경우 먼저 이전 시작 구성이있는 인스턴스를 종료합니다 . [강조 광산]

강조된 부분은 중요하지만, 전자는 각각의 초기 주문형 시작 구성에서 추가 스팟 시작 구성으로 변경 한 후 주문형 인스턴스를 계속 실행해야하는 요구 사항을 다루고 있으며 , 후자는 더 이상 사실이 아니어야 합니다. Auto Scaling 그룹의 인스턴스 종료 정책에 문서화되어 있는 최근에 도입 된 Auto Scaling 종료 정책 (변경 사항은 일반적으로 동봉 된 AWS 블로그 게시물을 통한 팬 패가 없었 음)은 다음과 같습니다.

Auto Scaling은 종료 할 인스턴스를 선택하기 전에 먼저 그룹에서 사용하는 다른 가용 영역보다 인스턴스가 더 많은 가용 영역을 식별합니다. 모든 가용 영역에 동일한 수의 인스턴스가있는 경우 임의 가용 영역을 식별합니다. 식별 된 가용 영역 내에서 Auto Scaling은 종료 정책을 사용하여 종료 할 인스턴스를 선택합니다 . [강조 광산]

에 설명 된대로 어떻게 귀하의 종료 정책 작품 , 당신은 지금 지정할 수 있습니다 NewestInstance을 , 마지막 발사 인스턴스를 종료 할 경우 더 최근에 출시 스팟 인스턴스 중 하나가 될 것이다 :

Auto Scaling은 인스턴스 시작 시간을 사용하여 마지막으로 시작된 인스턴스를 식별합니다.

물론보기에 조금있을 수 있습니다, 예를 들어, 당신도 독립 정책으로 정책 중 하나를 지정하거나 정렬 된 목록에서 여러 정책을 나열 할 수 있지만,이 방법은되는 모든 인스턴스의 부하를 확인해야합니다 에 반영 자동 스케일링 측정 및 트리거 ; 그러나 한 가지 경고가 남아 있습니다.

경고

로드 밸런서가 다른 이유로 온 디맨드 인스턴스 중 하나를 종료하는 경우 (예 : 자체적으로 상태가 나빠져서) 온 디맨드 인스턴스로 자동 대체되지 않습니다. 따라서 주문형 시작 구성을 일시적으로 다시 활성화하는 등이 이벤트를 별도로 모니터링하고 설명해야합니다.

행운을 빕니다!


2
이것은 의미가 있습니다-훌륭한 형사 일. 여전히 정전 위험이 있지만 그 위험을 줄이기위한 몇 가지 새로운 방법을 발견 한 것으로 보입니다. 언젠가 ASG에 대한 간단한 확인란이있을 것입니다. "서버 최소값 이하의 인스턴스는 온 디맨드 인스턴스입니다." 감사!
플랫폼

1

https://github.com/ashwanthkumar/matsya 를 생각해 내기 위해 여기에서 답변을 얻었습니다.

다음을 수행하는 데 도움이됩니다.

  • Hadoop / Mesos / YARN 클러스터 요구 사항을 충족하려면 항상 여러 대의 시스템이 필요합니다.
  • SLA를 충족하기 위해 처리 능력이 필요하므로 스팟을 사용하여 비용을 절약하고 OD로 대체하려는 경우
  • OD에서 스팟으로 다시 전환하여 비용을 다시 절약하십시오.


답은 도움이 될 것이라는 좋은 의도와 공유되었습니다. 자체 프로모션으로 찾은 경우 답변을 삭제할 수 있습니다.
ashwanthkumar

답변이 실제 스팸이라고 생각했다면 이미 스팸으로 표시했을 것이므로 게시물을 삭제할 필요가 없습니다. 제품 프로모션 링크는 이러한 답변이 가치가있을 수 있지만 자신과 같은 비교적 새로운 사용자가 종종 알지 못하는 균형이 있습니다. 그리고 중재자로서 저는 당신에게 존재하지 않은 선을 넘어 가기 전에 (불행히도 반복되는 패턴입니다)
HBruijn

맞는 말이다. 정책에 대한 감사의 말을 전합니다.
ashwanthkumar

1

정적 온 디맨드 인스턴스 수를 가진 1 개의 ASG 만 원하는 경우 다음이 작동합니다.

  • 스팟 인스턴스 시작 구성을 기반으로 Auto Scaling 그룹을 생성합니다.

  • ASG에서 Auto Scaling 일시 중단

  • 주문형 인스턴스 (정적 기본로드)를 ASG에 수동으로 추가하고 해당 인스턴스에 대한 인스턴스 보호를 켭니다.

  • ASG에서 자동 확장 재개

  • 기본 자동 조정 정책은 이제 보호로 인해 주문형 인스턴스를 무시하고 원하는 수의 그룹을 달성하기 위해 주문형 인스턴스와 동일한 수의 스팟 인스턴스를 종료합니다. 스케일 인 또는 아웃 활동은 스팟 인스턴스 만 시작하거나 종료합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.