AWS burstable EC2 및 CloudWatch 지표

응용 프로그램의 작업 부하가 보통 일정하지 않을 수도 있고 예측할 수 없을 수도 있습니다.용량이 너무 작으면 비용을 절약할 수 있지만, 러시아워에는 심각한 성능 문제가 발생할 수 있습니다.따라서 피크 워크로드의 용량을 조절해야 합니다. 피크 초과 시 유휴 CPU에 대한 요금을 지불해야 합니다.이것은 가상화와 클라우드의 주요 원인인 탄력성이다.하드웨어는 여러 애플리케이션이 공유하기 때문에 같은 시간에 워크로드 피크를 달성하지 못할 수 있으므로 피크 활동의 합계를 위해 물리적 용량을 조정할 필요가 없으며 각 애플리케이션이 전용 하드웨어에서 실행되는 경우 반드시 그렇게 해야 합니다.AWS에는 예약된 용량과 자동 크기 조절 기능 중에서 선택할 수 있는 많은 기능이 있습니다.여기에 아주 간단한, 심지어 무료층에서도 사용할 수 있는:burstable 컴퓨터가 있습니다.
EC2 t2를 생성했습니다.미실례.CloudWatch에는 다음과 같은 3가지 지표가 나와 있습니다.
나는 32분의 CPU 신용 잔액부터 시작한다.즉, 100% CPU에서 32분 동안 실행할 수 있습니다.내가 CPU를 사용하지 않을 때, 이 포인트는 유지되고 심지어 증가할 것이다.16시 20분에 우리는 프로그램을 시작했는데, 이 프로그램은 CPU yes > /dev/null 에서 완전히 실행되었다.나는 대략 17:00 이전에 100%의 CPU를 사용한 후에'CPU 이용률(%)'이 20% 안팎으로 떨어졌다. 이것은 t2의 기선이다.소액 신용대출이 다 떨어졌을 때.이 기간 동안 CPU 신용 사용률은 5분마다 수집되므로 CPU 신용 사용률은 5입니다. 100% CPU로 실행되는 5분 동안 신용 사용량은 5분입니다.이 기간 동안, 너는 CPU 신용 잔액이 0으로 떨어지는 것을 보게 될 것이다.나는 17:45에 yes 프로세스를 멈추었다.'CPU 이용률'은 0%였다. 아무것도 실행되지 않았기 때문에'CPU 신용 잔액'은 또 천천히 증가하기 시작했다.

이 클라우드 워치의'CPU 이용률'에서 17:05와 17:35 사이에 당신의 CPU 이용률이 20%에 불과하다고 말할 수 없다. 프로세스가 필요하지 않기 때문이냐, 아니면 CPU 부족으로 인해 제한을 받기 때문이냐.그러나 신용 잔액과 사용 상황을 보면서 추측할 수 있다.10분마다 수집되는 기본 SAR 통계를 살펴보겠습니다.

[ec2-user@ip-172-31-42-243 ~]$ sar

04:04:59 PM       LINUX RESTART                                                                                                        

04:10:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:20:01 PM     all      0.02      0.00      0.02      0.00      0.00     99.95
04:30:01 PM     all     45.88      0.00      0.58      0.09      0.01     53.44
04:40:01 PM     all     99.02      0.00      0.96      0.00      0.02      0.00
04:50:01 PM     all     99.03      0.00      0.95      0.00      0.01      0.00
05:00:01 PM     all     99.04      0.00      0.95      0.00      0.01      0.00
05:10:01 PM     all     28.03      0.00      0.23      0.00     71.74      0.00
05:20:02 PM     all     17.50      0.00      0.12      0.00     82.39      0.00
05:30:01 PM     all     18.90      0.00      0.11      0.00     80.99      0.00
05:40:02 PM     all     18.83      0.02      0.16      0.00     81.00      0.00
05:50:01 PM     all      3.45      1.07      1.10      4.60     33.31     56.47
06:00:01 PM     all      0.02      0.00      0.02      0.00      0.00     99.96
06:10:01 PM     all      0.02      0.00      0.02      0.00      0.02     99.94
06:20:01 PM     all      0.03      0.00      0.01      0.00      0.01     99.95
06:30:01 PM     all      0.01      0.00      0.01      0.00      0.00     99.98

내 프로그램을 시작하기 전에 CPU는 16:20까지 거의 100% 비어 있었다.그리고 CPU가 실행될 때 사용자 공간에서 17:00까지 거의 100%의 CPU를 사용합니다.그런 다음 17:45에 프로세스를 중지할 때까지 CPU 사용률이 20%에 육박합니다.이는 CloudWatch가 표시하는 것과 동일합니다.그러나SAR는 여기에'%steal'이라는 추가 지표가 있다. 이것이 바로 내가 그것이 한가한 것이 아니라 가상 기기 모니터링 프로그램에 의해 제한된 것임을 어떻게 알았는가이다.내 프로세스는 100% 실행 중이지만 이는 20%의 CPU 사용률과 80%의 도난을 나타냅니다.그리고 프로세스를 멈추었습니다.%user와%steal은 0으로 떨어졌습니다. 모든 시간이 비어 있습니다.
CPU가 비어 있으면 CPU 포인트가 증가합니다.

24시간 후에 나는 144분의 CPU를 얻었다.나는 더 이상 벌지 않을 것이다. 이것은 최고 임금이다.물론 이 모든 것은 실례 유형 설명(https://aws.amazon.com/ec2/instance-types/))과Burstable CPU 설명(https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html)에 기록되어 있습니다: 빈 t2.마이크로는 시간당 6분, 최대 144분의 학점을 받는다.나의 예에서 문서와 다른 것은 기선이다. 학점이 부족할 때 기선은 10%가 되어야 하지만 나는 위에 있다.왜 그런지 모르겠다.
나는 또 잠도 자지 않고 쉬지 않는 과정을 시작했다.

그것은 100%의 속도로 144분을 운행할 수 있지만, 나는 여기서 멈추었다. 이것은 위의 모델과 같다.
클라우드워치는 알려주지 않지만, 'CPU 이용률%' 는 커널에서 실행되는 시간 (% 시스템) 을 포함합니다.나는 yes > /dev/null를 실행하지 않고 dd if=/dev/urandom of=/dev/null bs=1M를 운행한다. 주로 내부 공간에서 운행한다.

03:20:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:00:01 PM     all      0.02      0.00     99.96      0.00      0.02      0.00
Average:        all      7.73      0.00      1.26      0.00      0.01     91.00

관계 데이터베이스 서비스

데이터베이스에 있어서 이것은 매우 재미있을 수 있다. 일부 RDS 실례 유형은burstable(db.t3.*)이다.데이터베이스는 같은 구성의 활동이 거의 없지만, 러시아워에 사용할 수 있는 CPU 자원이 있어야 한다.데이터베이스는 데이터를 공유하기 때문에 잠금 레지스터와 회전 자물쇠로 데이터 구조를 보호한다. CPU가 부족한 상황에서 CPU 밖에서 스케줄링하는 프로세스는 독점 자원을 가지고 있을 수 있지만 다른 프로세스는 실행 상태에 들어가 CPU에서 회전해서 이 자원을 얻기 위한 것이다.이것은 다른 프로세스가 실행 대기열에 있을 때 자원을 사용할 수 없기 때문에 CPU 주기에 대한 낭비입니다.
Aurora는db에서 실행할 수 있습니다.t3 중형과 대형.그러나 너도 자동 저울을 볼 수 있다. 아마도 서버가 없는 것일 것이다.Oracle 데이터베이스는burstable 실례에서 많은 이익을 얻지 못했다. 소프트웨어 허가증은 프로세서 지표에 따라 지불되고 프로세서 지표는 완전한 vCPU에 의해 결정되기 때문에 기준이 아니라 필요할 때 100%의 프로세서를 사용하기를 원할 수도 있다.