AWS EC2 Auto Scaling 그룹 : 최소 및 최대를 얻지 만 원하는 인스턴스 제한은 무엇입니까?
AWS EC2에서 자동 스케일링 그룹 때 당신에게 설치 Min
및 Max
경계는 의미가 같다 :
- 정책에 따라 축소 할 최소 인스턴스 수
- 정책에 따라 확장 할 최대 인스턴스 수
그러나 나는 도대체 Desired
가 영향을 미치려는 것에 내 머리를 감쌀 수 없었습니다 .
일반적으로 가능한 최소 십일조를 Amazon에 지불하고 싶기 때문에 항상 Desired
동일하게 설정 Min
했습니다.로드를 처리 할 인스턴스가 필요하지 않으면 인스턴스 수에 있어야 Min
합니다.
사용 ElasticBeanstalk
하고 a Min
를 1로 설정하고 Max
2로 설정하면 a Desired
를 2로 설정한다는 것을 알고 있습니다 (물론!) Desired
.에 대한 값을 선택할 수 없습니다 .
다른 Desired
수의 인스턴스에 대한 사용 사례는 무엇 이며 어떻게 다릅니 까? 당신은 AWS가보다 낮은 확장 할 것으로 예상 할 때 Desired
필요한 경우보다 더 크다 Min
?
다음은 AWS 지원의 "최소, 희망 및 최대"값에 대한 설명입니다.
MIN : 자동 확장 그룹에서 실행할 수있는 최소 인스턴스 수입니다. 축소 CloudWatch 경보가 트리거되면 자동 확장 그룹이이 수 미만의 인스턴스를 종료하지 않습니다.
원하는 : 스케일 업 이벤트에 대해 CloudWatch 경보를 작동하면 자동 스케일러에 원하는 값을 지정된 더 높은 양으로 변경하도록 알리고 자동 스케일러가 해당 수를 충족하기 위해 인스턴스를 시작합니다. 축소하기 위해 CloudWatch 경보를 작동하면 원하는 자동 확장기를 지정된 더 낮은 숫자로 변경하고 자동 확장기가 해당 숫자에 도달하기 위해 인스턴스를 종료합니다.
MAX : 자동 확장 그룹에서 실행할 수있는 최대 인스턴스 수입니다. 확장 CloudWatch 경보가 계속 트리거되면 자동 확장 그룹은 지정된 최대 양보다 많은 인스턴스를 생성하지 않습니다.
슬라이딩 범위 UI 요소처럼 생각하십시오.
최소 및 최대를 사용하여 인스턴스 확장의 하한을 설정합니다. 원하는 용량으로 현재 인스턴스 수를 가리 키도록 설정합니다.
예 : 마케팅 이메일 또는 제품 출시로 인해 애플리케이션에 과부하가 발생한다는 것을 알고 있습니다 ... 사전에 원하는 용량을 확장하기 만하면됩니다.
aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown
원하는 경우 최소보다 큰 경우 AWS가 Desired보다 낮게 확장 될 것으로 예상되는시기는 언제입니까?
이는 일부 AutoScaling 정책을 기반으로 CloudWatch 경보를 설정할 때 발생합니다. 해당 경보가 트리거 될 때마다 DesiredCount를 구성에 언급 된대로 업데이트합니다.
예를 들어 AutoScalingGroup 구성에 Min = 1, Desired = 3, Max = 5가 있고 AutoScalingPolicy에 경보가 설정되어있는 경우 CPU 사용량이 연속 10 분 동안 50 % 미만 Remove 1 instances
이면 계속해서 인스턴스 수를 줄입니다. DesiredCount = MinCount가 될 때까지 경보가 트리거 될 때마다 1입니다.
학습 한 내용 : MinCount를> 0 또는 = DesiredCount로 설정합니다. 이렇게하면 mincount = 0 및 CPU 사용량이 감소 할 때 응용 프로그램이 중단되지 않습니다.
"Desired"는 (필연적으로) 모호합니다.
- " 초기 "인스턴스 수를 의미합니다. 왜 "초기"가 아닌가? 자동 확장 이벤트에 따라 숫자가 변경 될 수 있기 때문입니다.
- 따라서 " 현재 "인스턴스 수를 의미 합니다. 왜 "현재"가 아닌가? 자동 확장 이벤트 중에 인스턴스가 시작 / 종료되기 때문입니다. 이러한 인스턴스는 "현재"인스턴스 수에 포함되지 않습니다. "현재"에 따라 사용자는 작동 가능한 인스턴스를 기대합니다.
- 따라서 " 대상 "인스턴스 수를 의미 합니다. 그럼 그냥 "표적"하지 않는 이유는 무엇입니까? "target"은 "desired"만큼 좋은 (모호한) 것 같아요 ...
내 독서에 따르면 평신도의 용어 DesiredCapacity
로 스케일 인 및 스케일 아웃 이벤트에서 값이 자동으로 업데이트됩니다.
다시 말해,
Scale-in 또는 Scale-out은 DesiredCapacity
값을 줄이거 나 늘려서 수행됩니다 .
원하는 용량은 단순히 자동 확장을 시작할 때 발생 / 실행될 인스턴스 수를 의미합니다. 즉, 원하는 용량 = 4이면 확장 또는 축소 이벤트가 트리거되지 않는 한 4 개의 인스턴스가 계속 실행됩니다. 스케일 업 이벤트가 발생하면 인스턴스 수가 최대 용량까지 올라가고 스케일 다운 이벤트가 발생하면 최소 용량까지 내려갑니다.
틀렸다면 고마워요.
원하는 용량이 줄어들고 새로운 인스턴스가 나타나지 않는 것을 확인했습니다.
- 인스턴스 중 하나를 대기로 설정했습니다. 계속 실행되었지만 ELB에서 분리되었습니다 (ELB DNS를 통해 액세스 할 때 요청이 해당 특정 인스턴스로 전달되지 않음). AWS에서 시작된 새 인스턴스가 없습니다. 오히려 원하는 용량이 1 감소했습니다.
- 인스턴스 상태를 변경했을 때 (대기에서) 인스턴스가 다시 ELB에 연결되었습니다 (인스턴스는 ELB DNS를 통해 액세스 할 때 요청을 받기 시작했습니다). 원하는 용량이 1 씩 증가하여 2가되었습니다.
따라서 ELB에 연결된 인스턴스는 최소 및 최대로 설정된 임계 값 제한을 초과 할 수 없지만 축소 또는 축소 이벤트 발생에 따라 원하는 용량이 자동으로 조정되거나 변경됩니다. 저에게는 확실히 알려지지 않은 일이었습니다.
이는 주어진 시점에서 각 ELB에 필요한 원하는 용량임을 AWS에 알리는 방법 일 수 있습니다.
'programing' 카테고리의 다른 글
GitLab CI를 사용하여 로컬에서 테스트를 실행 하시겠습니까? (0) | 2021.01.15 |
---|---|
여러 로더가있는 웹팩 로더에 쿼리를 추가하는 방법은 무엇입니까? (0) | 2021.01.15 |
Docker-compose mysql 연결이 준비되었는지 확인 (0) | 2021.01.14 |
C # / F # 성능 비교 (0) | 2021.01.14 |
prototype.constructor.apply를 호출하여 JavaScript 객체 인스턴스화 (0) | 2021.01.14 |