기본소득과 대출로 이해하는 T2 Unlimited의 과금 방식
여기서 다루는 내용
· T2 Unlimited 출시
· T2 Standard / Unlimited의 동작 방식
· 활용 방안
T2 Unlimited 출시
T2 인스턴스의 분화: T2 Standard or T2 Unlimited
아시다시피 AWS에서는 매우 다양한 형태의 Instance Type을 제공합니다.
그리고 이 중 가장 특이한 유형의 Instance Family가 하나 있죠. 바로 T2 인스턴스 계열입니다.
Bustable한 성능을 제공하는 T2 계열에는 CPU Credit이라는 개념이 등장합니다.
관련해서 아주 잘 정리된 글이 하나 있는데요. 어차피 제가 적은 글이라.. 시간되시는 분은 아래 링크를 참조하세요.
T2 계열 인스턴스의 CPU Credit 이해하기 – Part1
T2 계열 인스턴스의 CPU Credit 이해하기 – Part2
※ 참고로 똥개 블로그는 조만간 폐쇄 예정입니다. 폐쇄 후에는 본 포스팅의 링크도 삭제됩니다.
내용을 3줄로 요약하면.
- T2 계열에는 CPU Credit이라는 개념이 있으며, 각 Instance Type별로 기본 성능만큼의 Credit을 지속적으로 제공
- CPU 사용량 > 해당 제공량이면 Credit 잔고 감소. 반대로 CPU 사용량 < 제공량이면 Credit 잔고 증가.
- Credit 잔고가 줄어들어 끝내 0이 되면, 순차적으로 CPU 성능 저하 발생
이해하셨죠?
저 포스팅 이후에도 많은 변화가 있었습니다.
우선 T2 계열 내에 새로운 Instance Type이 몇몇 추가되었습니다.
이 포스팅을 작성하고 있는 `17/12 기준으로, 아래 7개 Type을 제공하고 있네요.
[table id=5 /]
그리고 Reinvent2017에 T2 계열과 관련된 새로운 업데이트가 발표되었습니다.
Announcing Amazon EC2 T2 Unlimited for Sustained High CPU Performance
바로 오늘 소개할 주제인 T2 Unlimited 입니다.
T2 Unlimited 사용은 어떻게?
사용자가 T2 계열의 인스턴스를 사용하는 경우
모든 T2 계열 Instance Type의 객체 단위로 T2 Standard를 선택할지, T2 Unlimited를 사용할지 결정할 수 있습니다.
그리고 이 옵션은 최초 EC2 Launch 시점뿐만 아니라, Running 상태일때도 언제든지 변경이 가능합니다. 아래처럼 말이죠.
자, 이제 배경을 알았으니 Standard와 Unlimited가 각각 어떻게 동작하는지 살펴봅시다.
T2 Standard / Unlimited의 동작 방식
T2 Standard의 동작 방식
새로운 개념을 진지하게 설명하면, 재미도 없고 이해도 어렵습니다.
본 포스팅에서는 기본소득과 소비 개념을 가져와, T2 계열 인스턴스의 동작 방식을 살펴보도록 하겠습니다.
-
- 기본소득: Instance Type이 기본적으로 제공하는 CPU Credit
ex) t2.small이면 분당 0.2, 시간당 12, 일당 288이 기본 소득입니다. 단, 소득은 288 이상 저축할 수 없습니다
-
- 소비: 해당 Instance에서 사용하는 실제 CPU 사용량, 많이 쓸때도 있고 적게 쓸때도 있습니다
ex) 예를 들어 vCPU 1개를 100% Load로 계속 쓴다면, 분당 1 / 시간당 60의 Credit을 소모
자, 이제 예를 들어 봅시다. 나는 분단위로 돈을 받는 편의점 알바입니다.
T2.small 출신이라 분당 0.2$, 시간당 12$를 법니다. 한동안 소비(CPU사용)을 전혀 하지 않아 잔고가 100$까지 불었습니다.
마침 크리스마스기도 하고, 갑자기 소비심리가 폭발하여 할 수 있는 최대한의 소비(CPU사용)를 합니다.
분당 1$씩 써서, 정신차려보니 두시간만에 120$를 썼네요.
이 시점에 남은 돈(CPU Credit)은 어떻게 될까요?
- 기존 잔고(Credit Balance): 100$
- 2시간동안 획득한 기본소득: 0.2/분 * 120분 = 24$
- 2시간동안 소비한 량: 1/분 * 120분 = 120$
- 현재 잔고(Credit Balance) = 100 + 24 – 120 = 4$
정신차려보니 잔고가 4$가 남았습니다.
여기서 소비를 멈추지 못하면 어떻게 될까요? 아마 5분 전후로 남은 잔고가 0이 될 것입니다.
그렇다면 남은 잔고가 0이 되면 어떻게 될까요?
더 이상 영혼이 원하는만큼 소비할 수 없습니다. 기본소득만큼(Baseline Performance)만 겨우겨우 소비할 수 있습니다.
이 방식이 T2 Standard입니다. 잔고가 0이 되면 바로 CPU 성능이 저하되고 일체의 대출을 허용하지 않습니다.
반면 대출을 받는 방법도 있습니다. 그것이 바로 이번에 나온 T2 Unlimited 프로그램입니다.
T2 Unlimited의 동작 방식
T2 Unlimited는 일종의 마이너스 통장과 같습니다.
- 잔고가 0이 되어도 계속 소비할 수 있습니다
- 마통 한도는 소득 한도와 동일합니다
- 중도해지시 반드시 대출을 다 갚아야 합니다
예를 들어 봅시다.
- t2.small, 잔고는 20$
- 기본소득은 0.2$/분, 12$/시간
- 1분당 1$씩 지속적으로 소비한다고 가정
1시간이 지난 시점에 잔고(CPU Credit)는 어떻게 될까요?
- 기존 잔고(Credit Balance): 20$
- 1시간동안 획득한 기본소득: 12$
- 1시간동안 소비한 량: 1$/분 * 60분 = 60$
- 현재 잔고(Credit Balance) = 20 + 12 – 60 = -28$
위처럼 마이너스 통장같이 CPU 크레딧을 빌려 쓸 수 있습니다. 이 과정에서 CPU 성능은 저하되지 않는다는 것이 핵심
단, Cloudwatch에서 제공하는 CPUCreditBalance 메트릭값이 마이너스가 되는건 아닙니다.
Cloudwatch의 CPUSurplusCreditBalance 메트릭이 해당 마이너스값을 플러스로 카운트합니다.
즉 해당 시점의 CPUCreditBalance값은 0, CPUSurplusCreditBalance값은 28이 됩니다.
여기서 만일 대출을 해지 – T2 Unlimited에서 T2 Standard로 옵션을 변경 – 하게 되면 어떻게 될까요?
해당 대출액 28에 단가를 곱해 요금을 청구합니다. 즉, AWS 비용에 묻어 청구됩니다.
여기서부터 경우의 수를 2개로 나눠보겠습니다. 하나는 대출을 모두 갚은 경우, 다른 하나는 대출이 점점 늘어나는 경우입니다.
1) 대출을 모두 갚은 경우
김생민의 영수증을 보고 위 케이스 이후로 3시간동안 소비(CPU 사용)를 전혀 하지 않았습니다.
그럼 이 시점의 잔고는 어떻게 될까요?
- 기존 잔고(Credit Balance): -28$ CPUCreditBalance:0, CPUSurplusCreditBalance:28
- 3시간동안 획득한 기본소득: 36$
- 3시간동안 소비한 량: 0$
- 현재 잔고(Credit Balance) = -28 + 36 – 0 = 8$
이 과정에서 AWS 비용이 청구될까요?
청구되지 않습니다. 대출 한도를 넘지 않고 흑자로 전환하면 과거를 묻지 않습니다.
2) 대출이 더욱 증가하는 경우
위 케이스 이후로도 동일한 페이스로 10시간동안 1분당 1$를 소비했습니다.
그럼 이 시점의 잔고는 어떻게 될까요?
- 기존 잔고(Credit Balance): -28$ CPUCreditBalance:0, CPUSurplusCreditBalance:28
- 10시간동안 획득한 기본소득: 120$
- 10시간동안 소비한 량: 600$
- 현재 잔고(Credit Balance) = -28 + 120 – 600 = -508$
이 과정에서 AWS 비용이 청구될까요?
청구됩니다. 왜냐면 마이너스 통장의 대출한도는 저축한도와 동일한 288(t2.small)이기 때문이죠.
해당 시점의 Cloudwatch 메트릭값은 다음과 같습니다.
- CPUCreditBalance: 0
- CPUSurplusCreditBalance: 288
- CPUSurplusCreditsCharged: 한도 288을 초과하는 값(-220 = 288 – 508)은 바로 단가를 곱해 AWS 비용에 청구
너무 설명이 길었네요. 이해가 안가시면 위 글을 다시 순서대로 읽어보시면 됩니다.
활용 방안
T2 Unlimited로 한번 바꿔볼까?
T2 Unlimited는 크게 중요하지 않은 업데이트처럼 보일수도 있지만
제 관점에서는 비용과 효율, 관리편의성이라는 측면에서 매우 획기적인 업데이트입니다.
예를 들어, c4.large(Linux) 2개로 구성된 서비스가 하나 있다고 합시다.
CPU사용률 기반으로 Autoscaling 구성을 해놔서, 필요시 2개씩 인스턴스가 늘어난다고 가정하겠습니다.
- 최대 CPU 성능: 인스턴스당 8ECU, 기본구성시 16ECU, 4개로 늘어날시 32ECU
- 비용: 인스턴스당 0.1$/시간, 기본구성시 0.2$/시간, 4개로 늘어날시 0.4$/시간
이 서비스를 t2.medium(Linux) 기반으로 한번 바꿔보겠습니다.
오토스케일링 구성 없이, 기본적으로 4개의 인스턴스를 항시 사용합니다.
- 최대 CPU 성능: 인스턴스당 ECU성능 * 4, Unlimited 옵션으로 단위 CPU 성능 저하 없음
- 비용: 인스턴스당 0.0464$/시간, 4개 구성이므로 0.1856$/시간, T2 Unlimited에서 추가 비용 발생시 해당 비용 추가
자, 어떤가요? t2.medium이 얼만큼의 CPU성능을 보여주는지는 담보할 수 없지만
T2 인스턴스 기반으로 비슷한 수준의 성능을 제공하면서 더 낮은 비용을 지불할 수 있습니다.
예전에는 이 구성을 할 수 없었습니다.
왜냐하면 T2 Standard의 동작 방식이, CPU 크레딧 잔고가 0이 되면 바로 서비스 성능이 저하되는 형태였기 때문입니다.
하지만 T2 Unlimited가 나오면서 이 성능저하 이슈가 사라졌습니다.
막상 CPU 성능에 대한 수요가 늘어나면, 성능 저하없이 충분한 CPU 파워를 쓰고 그만큼의 비용을 추가로 부담하면 됩니다.
실제 CPU 사용량은 들쭉날쭉하기 때문에 사용량이 적을때 충분한 양의 CPU Credit을 쌓아놔서 추가 부담은 아마 크지 않을 겁니다.
오토스케일링 구성 필요성이 상대적으로 줄어들었습니다. 오토스케일링시 반드시 고려해야만 하는 관리포인트도 없어졌습니다.
마치며
물론 T2 계열 인스턴스의 제약사항이 없는 것은 아닙니다.
- 공유 환경에서 정확히 계량/보증되지 않는 CPU 성능
- 상대적으로 적은 크기의 제공 Memory
- 다른 Instance 계열에 비해 낮은 네트웍 성능
하지만 이런 제약사항이 문제되지 않는 환경이라면 / 상대적으로 가벼운 Workload의 서비스라면
T2 계열 인스턴스로의 전환을 한번쯤 고려해 볼 수 있지 않을까요?
새로운 기능과 비용에 따라 아키텍쳐를 변경해보고, 효과를 확인해볼 수 있는 것이 클라우드의 특징이자 장점이기도 하니까요!
그럼 기나긴 포스팅을 마치도록 하겠습니다.
끝.
최신 댓글