AWS CPU 버스트 편집하기

AWS CPU 버스트란 AWS의 서버 자원에서 CPU 사용률이 일정 수준 이상 올라가지 못하도록 제한하는 정책이 있는데, CPU 사용률이 기준치 이상을 초과하는 것을 CPU 버스트라고 한다. 

* CPU 버스트가 지속되면 서비스 성능에 제약이 가해지거나 초과 비용이 부과될 수 있다.

== 예시 ==
'''기준치가 10%로 제한된 서버는 CPU 사용률이 10% 이상 넘어가면 CPU 버스트 상태'''인 것인데, 일반적으로 CPU 사용률이 10%를 넘어간다고 해서 서버에 문제가 생기는 것은 아니나 이를 허용하지 않는다. 일정 시간 이상 CPU 버스트 상태가 지속되면 제약이 가해진다. 대략 아래와 같은 규칙이다.

* CPU가 기준치 보다 낮게 유지되면 낮은 만큼 크레딧이 쌓인다.
* 크레딧은 누적 한도가 있다. 한도만큼 쌓고 나면 CPU가 낮게 유지되어도 더이상 쌓이지 않는다.
* CPU가 기준치를 초과하면 초과한만큼 크레딧이 사용된다.
* CPU가 기준치를 잠깐씩 초과한다면 크레딧이 조금 사용됐다가 금방 다시 복구된다.
* 하지만 CPU가 기준치를 오랫동안 초과하거나 자주 초과한다면 크레딧이 쌓이지 않고 계속 소모만 되거나, 크레딧이 쌓이는 속도보다 소모되는 속도가 더 빨라진다.
* 크레딧이 0이 되면 CPU 성능이 제한되거나 초과 비용이 발생하기 시작한다.

== 이유 및 한계 ==
가상화 공유 자원을 운용하는 클라우드 특성상 CPU가 1% ~ 100%를 넘나들며 사용량이 예측불가능한 서버들이 많아지게 되면 해당 가상서버가 아닌 물리적 자원을 공유하는 다른 서버에도 영향을 줄 수 있다. 그래서 CPU 사용률이 5~20% 이내로 유지되는 수준으로 서비스를 운영하고, 이를 넘어설 정도로 서비스가 커진다면 그에 걸맞는 높은 용량의 서버를 사용하도록 하는 것이다. 그래도 피크 시간대나 특정 작업에서 CPU가 많이 사용될 수 있으므로, 어느정도의 CPU 초과는 허용해주되, 많이는 초과하지 말라는 것이다.

정석대로라면 평균 CPU 사용률이 20%를 넘어가는 것은 바람직하지 않으므로, 바람직한 서버 운영을 도모한다고 볼 수도 있으나. 기존에 서버를 직접 운영하거나 가상서버 호스팅을 사용했을 떄에 비하면 사용자 입장에서 상당히 큰 제약이다. 기존엔 비수기엔 CPU가 1~2%대로 유지되다가 성수기나 이벤트 시기엔 20~30%정도로 몰릴 수도 있는데 그렇다고 서버거 과부화로 죽는 상황까진 이르지 않는다. 하지만 AWS의 이런 제약 아래선 성수기에 CPU가 높은 수준으로 며칠 이상 유지될 경우 CPU 버스트 크레딧이 모두 소진되어 갑자기 CPU 성능이 급감하고, 특정 서버의 성능이 급감을 하게 되면 연쇄적인 시스템 장애로 번질 수 있다. 실제로 이런 사고를 한번 겪고 나서 CPU 버스트에 대해 알게 되는 경우도 많다.

사용자는 당연히 CPU의 100%를 사용할 수 있을 것이라 생각하고 서비스를 신청했는데 실제로는 CPU의 10~20%밖에 못쓰도록 제한이 있는 것이니 과대포장 같은 느낌이기도 하다.

== 비판 ==
'''불가피한 조치인가 상술인가'''

하이버파이저 가상화를 잘만 운영하면 특정 가상환경에서 발생하는 부하가 다른 환경에 번지지 않도록 차단하는 것이 불가능한 것도 아니다. 그런데도 그런 운영능력 부족으로 이렇게 사용자에게 사고를 유발하고 필요보다 더 큰 용량의 서버 인스턴스를 구매하여 사용하도록 하는 것은, 안정성 유지라는 허울 좋은 핑계로 사용료를 더 받겠다는 상술에 불가능하다는 견해가 있다.

'''미리 제대로 공지하였는가'''

CPU 버스트에 대해선 조금만 검색하면 나오긴 하지만 CPU 버스트라는 이름만으로 이런 제한 정책을 미리 예측하긴 어렵다. 분명히 CPU 버스트에 대한 매뉴얼이 있긴 할지라도 서버 인스턴스를 신정하는 과정에서 이에 대한 경고나 안내가 명확하게 나오는 것은 아니다. 클라우드에 익숙한 많은 사용자는 기존에 안정적으로 운영해왔던 성능으로 인스턴스를 구성할 것이나 AWS의 이런 제약으로 전혀 예상치 못한 사고를 겪에 된다.

== 핵심 개념 및 정의 ==

; CPU 사용률
: CPU 사용률은 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛의 비율(%)입니다. 이 지표는 인스턴스에서 사용되고 있는 할당된 CPU 사이클의 비율을 측정합니다. CPU 사용률 CloudWatch 지표는 코어당 CPU 사용량이 아니라 인스턴스당 CPU 사용량을 나타냅니다. 인스턴스의 기준 CPU 사양도 인스턴스당 CPU 사용량을 기준으로 합니다. AWS Management Console 또는 AWS CLI를 사용하여 CPU 사용률을 측정하려면 특정 인스턴스에 대한 통계 가져오기 섹션을 참조하세요.
; CPU 크레딧
: vCPU 시간의 단위입니다.  예:  CPU 크레딧 1개 = vCPU 1개 * 100% 사용률 * 1분  CPU 크레딧 1개 = vCPU 1개 * 50% 사용률 * 2분  CPU 크레딧 1개 = vCPU 2개 * 25% 사용률 * 2분
; 기준 사용률
: 기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준입니다. 기준 사용률을 기준이라고도 합니다. 기준 사용률은 vCPU 사용률의 백분율로 표시되며 기준 사용률(%) = (획득한 크레딧 수/vCPU 수)/60분으로 계산됩니다.  각 버스트 가능한 성능 인스턴스 유형의 기준 사용률은 크레딧 표를 참조하세요.
; 획득 크레딧
: 인스턴스가 실행 중일 때 지속적으로 적립되는 크레딧입니다.  시간당 적립되는 크레딧 수 = 기준 사용률(%) * vCPU 수 * 60분  예:  vCPU가 2개인 t3.nano는 기본 사용률이 5%로, 시간당 6 크레딧을 획득하며, 다음과 같이 계산됩니다.  vCPU 2개 * 5% 기준 * 60분 = 시간당 6 크레딧
; 소비 또는 사용되는 크레딧
: 인스턴스가 실행 중일 때 지속적으로 소비되는 크레딧입니다.  분당 소비되는 CPU 크레딧 = vCPU 수 * CPU 사용률 * 1분
; 획득한 크레딧
: 인스턴스가 기준 사용률에 필요한 것보다 적은 크레딧을 사용하는 경우 사용되지 않은 CPU 크레딧입니다. 즉, 획득한 크레딧 = (적립되는 크레딧 - 기준 미만으로 사용되는 크레딧)입니다.  예:  t3.nano가 한 시간 동안 5% 기준보다 적은 2% CPU 사용률로 실행될 경우 획득한 크레딧은 다음과 같이 계산됩니다.  획득한 CPU 크레딧 = (시간당 적립되는 크레딧 - 시간당 소비되는 크레딧) = 6 - 2 vCPU * 2% CPU 사용률 * 60분 = 6 - 2.4 = 시간당 획득한 크레딧 3.6입니다.
; 크레딧 누적 한도
: 인스턴스 크기에 따라 다르지만 일반적으로 24시간 동안 적립되는 최대 크레딧 수와 같습니다.  예:  t3.nano의 경우 크레딧 누적 한도 = 24 * 6 = 144 크레딧입니다.
; 시작 크레딧
: 표준 모드로 구성된 T2 인스턴스에만 적용됩니다. 시작 크레딧은 새 T2 인스턴스에 할당되는 제한된 수의 CPU 크레딧으로, 표준 모드로 시작할 때 기준 이상으로 버스트할 수 있습니다.
; 잉여 크레딧
: 획득한 크레딧 잔액이 소진된 후 인스턴스가 소비하는 크레딧입니다. 잉여 크레딧은 버스트 가능 인스턴스가 오랜 기간 동안 고성능을 유지할 수 있도록 고안되었으며 무제한 모드에서만 사용됩니다. 잉여 크레딧 잔액은 인스턴스가 무제한 모드에서 버스트하기 위해 소비한 크레딧 수를 확인하는 데 사용됩니다.
; 스탠다드 모드
: 크레딧 구성 모드로, 크레딧 잔액에 적립된 크레딧을 사용하여 인스턴스를 기준 이상으로 버스트할 수 있습니다.
; 무제한 모드
: 크레딧 구성 모드로, 필요할 때마다 원하는 기간 동안 높은 CPU 사용률을 유지하여 인스턴스를 기준 이상으로 버스트할 수 있습니다. 24시간 동안 또는 인스턴스 수명(더 짧음) 동안 인스턴스의 평균 CPU 사용률이 기준 이하인 경우에 모든 CPU 사용량 급증에 대해 시간당 CPU 인스턴스 요금이 적용됩니다. 인스턴스 실행에 장기간 높은 CPU 사용률이 필요한 경우, vCPU-시간당 추가 고정 요금으로 인스턴스를 실행할 수 있습니다.

== 인스턴스별 기준 ==
{| class="wikitable"
!인스턴스 유형
!시간당 지급되는 CPU 크레딧
!누적 가능한 최대 지급된 크레딧*
!vCPU***
!vCPU당 기준 사용률
|-
|T2
|
|
|
|
|-
|<code>t2.nano</code>
|3
|72
|1
|5%
|-
|<code>t2.micro</code>
|6
|144
|1
|10%
|-
|<code>t2.small</code>
|12
|288
|1
|20%
|-
|<code>t2.medium</code>
|24
|576
|2
|20%**
|-
|<code>t2.large</code>
|36
|864
|2
|30%**
|-
|<code>t2.xlarge</code>
|54
|1296
|4
|22.5%**
|-
|<code>t2.2xlarge</code>
|81.6
|1958.4
|8
|17%**
|-
|T3
|
|
|
|
|-
|<code>t3.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3.small</code>
|24
|576
|2
|20%**
|-
|<code>t3.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3.large</code>
|36
|864
|2
|30%**
|-
|<code>t3.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T3a
|
|
|
|
|-
|<code>t3a.nano</code>
|6
|144
|2
|5%**
|-
|<code>t3a.micro</code>
|12
|288
|2
|10%**
|-
|<code>t3a.small</code>
|24
|576
|2
|20%**
|-
|<code>t3a.medium</code>
|24
|576
|2
|20%**
|-
|<code>t3a.large</code>
|36
|864
|2
|30%**
|-
|<code>t3a.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t3a.2xlarge</code>
|192
|4608
|8
|40%**
|-
|T4g
|
|
|
|
|-
|<code>t4g.nano</code>
|6
|144
|2
|5%**
|-
|<code>t4g.micro</code>
|12
|288
|2
|10%**
|-
|<code>t4g.small</code>
|24
|576
|2
|20%**
|-
|<code>t4g.medium</code>
|24
|576
|2
|20%**
|-
|<code>t4g.large</code>
|36
|864
|2
|30%**
|-
|<code>t4g.xlarge</code>
|96
|2304
|4
|40%**
|-
|<code>t4g.2xlarge</code>
|192
|4608
|8
|40%**
|}