AWS EC2(Elastic Compute Cloud)에는 t2, t3, t4g처럼 t로 시작하는 T instance가 있습니다. 이런 T type instance는 공유 코어를 사용한다는 특징이 있는데요, 이로 인하여 항상 높은 CPU 사용률을 보이지 않는 경우 M instance에 비해 비용을 줄일 수 있습니다.
하지만 어느정도 사용할 때 M instance보다 저렴한지 비교하기 어려운데요, 이를 정리해 보았습니다.
시작하기 전에 알아둘 점
1. T instance는 M instance 특정 종류와 동일한 프로세서를 사용합니다.
T instance | M instance | 프로세서 종류 |
T2 | M4 | #2.4GHz 인텔 제온: 하스웰 E5-2676 v3(2.4~3.0Ghz, 15Q4?) 브로드웰 E5-2686 v4(2.3~3.0Ghz, 16Q4?) |
T3 | M5 | #3.1GHz 인텔 제온: 스카이레이크 8175M(2.5Ghz, 18Q3?) 캐스케이드 레이크 8259CL(2.5~3.5Ghz, 19Q2/20Q1?) |
T3a | M5a | #2.5GHz AMD EPYC: AMD EPYC 7571(2.1~2.9Ghz, 19Q3?) |
T4g | M6g | #Arm 기반 AWS Graviton2 프로세서 |
즉 T instance 프로세서를 항상 100% 이용한다면 T instance보다 동일 기종의 M instance를 사용하는 것이 좋을 수 있습니다.
2. T instance는 비교적 구세대의 프로세서를 사용합니다.
현재(2024.04월 기준) 최신 M instance는 M7i, M7a, M7g인데, 해당 프로세서들은 공유 코어인 T instance로는 제공되지 않습니다. 즉 최신의 프로세서를 이용하고 싶다면 T instance 로는 어렵습니다.
3. T instance는 작은 크기의 인스턴스를 지원합니다.
M instance는 ~M7i, ~M6a까지는 large(2vCPU, 8Gib)크기가 가장 작은 크기이고 M7a~, M6g~ 인스턴스부터는 medium(1vCPU, 4Gib)이 가장 작은 크기입니다. 인텔 기준으로는 아무리 작아도 large이고, 다른 종류도 medium을 지원하는 것은 최신 프로세서이기에, 이 정도로 많은 리소스를 필요로 하지 않는다면 nano(2vCPU, 0.5Gib) 까지 지원하는 T instance가 매우 비용 효율적일 수 있습니다.
4. T instance에는 CPU Credit이라는 시스템이 존재합니다.
5. unlimited 모드(무제한 모드)를 사용하면 보유 크레딧 이상으로 CPU 리소스를 사용할 수 있습니다.
이때 추가비용이 발생하는데, Linux 기준으로 T2, T3, T3a는 1 vCPU당 한 시간에 0.05 USD, T4g는 1 vCPU당 0.04 USD의 비용이 발생합니다.
다르게 해석하자면 1vCPU를 100%로 1시간 운용하는데 60 크레딧이 필요하니 60크레딧을 0.05USD에 구매가능한 것과 같습니다.
6. 무제한 모드에서는 잉여 크레딧이라는 시스템이 존재합니다.
이는 크레딧을 모두 사용했을때 대출하듯 크레딧을 사용한다 보면 되는데, 잉여 크레딧의 수가 인스턴스가 24시간 동안 획득할 수 있는 최대 크레딧 수를 초과한 경우 최대 값 이상으로 소비된 잉여 크레딧은 추가 요금으로 부과됩니다.
잉여 크레딧이 요금 부여로 전환되는 자세한 기준은 아래와 같습니다.
- 소비한 잉여 크레딧이 인스턴스가 24시간 동안 획득할 수 있는 최대 크레딧 수를 초과하는 경우. 해당 시간이 끝날 때 최대 값 이상으로 소비한 잉여 크레딧에 요금이 부과됩니다.
- 인스턴스가 중지 또는 종료된 경우.
- 인스턴스가 unlimited에서 standard로 전환됩니다.
7. T2를 제외한 T instance는 기본적으로 무제한 모드로 실행됩니다. T2는 standard로 실행됩니다.
8. T2 instance는 시작 크레딧이라는 시스템이 존재합니다.
9. T2는 T3과 비교해 구세대 인스턴스이고, 특정 단계에서 T3에 비해 CPU Credit이 더 적게 공급되며, nano~small에서 vCPU도 1개(T3은 2개)로 버스트 가능한 최대 성능도 떨어집니다. 또한 가격 또한 T3보다 비싸니, T2보다는 T3을 이용하는 것을 권장합니다.
10. Compute Optimizer를 사용하면 AWS에서 적절한 리소스 선택지를 추천받을 수 있습니다.
T instance는 실제 어느 정도의 vCPU를 가지는가?
무제한 모드를 사용하지 않을 때, T instance의 vCPU는 어느 정도일까요? 이는 인스턴스 크기별로 지급되는 크레딧 양을 통해 계산할 수 있습니다.
인스턴스 | vCPU | 시간당 크레딧 | 메모리(Gib) | vCPU당 기준 사용률 | vCPU 평균 유지량 |
t3.nano | 2 | 6 | 0.5 | 5% | 0.1 |
t3.micro | 2 | 12 | 1 | 10% | 0.2 |
t3.small | 2 | 24 | 2 | 20% | 0.4 |
t3.medium | 2 | 24 | 4 | 20% | 0.4 |
t3.large | 2 | 36 | 8 | 30% | 0.6 |
t3.xlarge | 4 | 96 | 16 | 40% | 1.6 |
t3.2xlarge | 8 | 192 | 32 | 40% | 3.2 |
nano~ large의 인스턴스를 따져볼 때, 이들은 실제로 2vCPU까지 순간적으로 버스트 가능하나, 평균적으로 nano사이즈는 0.1vCPU를 가진 것과 같다고 볼 수 있습니다.
이렇게 보면 large 아래의 인스턴스는 대응되는 M instance가 없다 해도, 0.6vCPU를 가지는 t3.large보다는 2vCPU를 무제한으로 사용할 수 있는 m5.large가 낫다고 볼 수도 있습니다.
그러나 T instance의 장점은 이 0.6vCPU를 원할 때 몰아서 사용(버스트)할 수 있는 능력과, 동일 크기의 M instance와 비교해 다소 저렴한 가격에서 나옵니다.
t3.large를 사용한다 치고, 항상 0.6vCPU(vCPU당 30%)정도를 평균적으로 사용한다면 m5.large보다 항상 저렴하게 사용할 수 있어 T instance가 이득이라 볼 수 있습니다. 하지만 무제한 모드를 이용하여 평균적으로 vCPU당 30%가 아닌, 40%를 사용한다면 어떨까요? 60 크레딧당 0.05USD를 추가적으로 사용해도 M instance보다 이득일까요?
이를 정리한 것이 아래의 손익분기입니다.
T instance의 손익분기
무제한 모드 개념을 포함한 T3 시리즈의 손익분기는 아래에 정리되어 있습니다. 다만 해당 자료는 us-west-1 리전 기준으로 정리되었고, T3 인스턴스 일부에 대해서만 정리되어 있습니다.
T2는 T3에 비해 대부분의 경우에서 하위호환이기에 T3을 기준으로 정리해보았습니다.
아래의 계산은 서울 리전(ap-northeast-2)을 기준으로 합니다.
메모리 비용은 T3/M5에서 1Gib/1h당 0.0055, T4g/M6g에서 1Gib/1h당 0.00425로 계산했습니다.
T3 시리즈
인스턴스 | vCPU | 시간당 크레딧 | 메모리(GiB) | vCPU당 기준 사용률 | vCPU 평균 유지량 | 손익분기 vCPU 기준 사용률 | 손익분기 vCPU 평균 유지 가능량 | M시리즈와 시간당 가격차이(A) | 손익분기 내에서 사용가능한 추가 vCPU(A*20) |
t3.nano | 2 | 6 | 0.5 | 5% | 0.1 | 75.25%(116.5%) | 1.505(2.33) | 0.07025(0.1115) | 1.405(2.23) |
t3.micro | 2 | 12 | 1 | 10% | 0.2 | 76.5%(115%) | 1.53(2.3) | 0.0665(0.105) | 1.33(2.1) |
t3.small | 2 | 24 | 2 | 20% | 0.4 | 79%(112%) | 1.58(2.24) | 0.059(0.092) | 1.18(1.84) |
t3.medium | 2 | 24 | 4 | 20% | 0.4 | 64%(74.4%) | 1.28(1.488) | 0.044(0.0544) | 0.88(1.088) |
t3.large | 2 | 36 | 8 | 30% | 0.6 | 44% | 0.88 | 0.014 | 0.28 |
t3.xlarge | 4 | 96 | 16 | 40% | 1.6 | 54% | 2.16 | 0.028 | 0.56 |
t3.2xlarge | 8 | 192 | 32 | 40% | 3.2 | 54% | 4.32 | 0.056 | 1.12 |
* 괄호 안은 메모리 가격 미보정시 값입니다
계산 시에 large 이상의 크기는 m5시리즈와 1대 1 대응이 가능함으로 그대로 계산했습니다. medium 이하의 경우에는 메모리 가격을 보정하여 손익분기를 계산하였습니다.
위의 표를 해석하자면, t3.large에서 평균 44% 이상의 vCPU 사용을 한다면 m5.large 인스턴스로 이전하는 것이 좋습니다. xlarge와 2xlarge의 경우는 54% 이상일시 이전하는 것이 좋고, 그전에는 T instance가 더 비용 효율적입니다.
medium 이하의 인스턴스는 복잡해지는데, 메모리 가격을 보정해도 64%~79%의 매우 높은 가격 효용을 보여주는 것을 알 수 있습니다. 특히 메모리를 미고려시 small 이하부터는 100%가 넘는 효율을 보여줍니다.
이 값이 말해주는 의미는, 2vCPU를 100% 사용하고, 메모리는 1Gib만 사용하는 작업을 한다면 m5.large(2vCPU, 8Gib)을 사용하는 것보다, t3.micro를 무제한 모드로 이용하는 것이 비용 효율적이라는 것을 의미합니다.
이렇듯 T instance는 nano사이즈도 2vCPU까지 버스팅이 가능하면서, 메모리가 필요 없을 때는 0.5Gib까지 줄일 수 있는, 메모리를 줄일 수 있다는 것에 큰 장점이 있습니다.
즉 T instance를 선택하실 때 2 vCPU 이하, 2Gib 이하의 작업을 하실 때는 메모리 필요양에 따라 nano~small을 선택하시면 됩니다. 항상 무제한 모드를 사용해도 m5.large 사용보다는 가격이 저렴하니까요.
메모리가 4Gib이 필요한 일을 하는 상황에서는 t3.medium을 사용해 보고, 만약 vCPU당 사용률이 74.4%를 넘어갈 경우 무제한 모드를 사용하기보다 차라리 m5.large(또는 c5.large)로 이전하는 것이 비용 효율적입니다.
이때 보면 vCPU당 사용률이 40%, 메모리는 4Gib를 사용하는 작업을 할 때 t3.medium를 버스트해 쓰는 것이 t3.large를 쓰는 것보다 저렴합니다. 이처럼 T instance에서 2vCPU 상황에서 vCPU는 오히려 작은 사이즈로 갈수록 비용효율적이게 됩니다. 즉 T instance를 고를 때는 메모리 사용정도에 따라서 선택하는 것이 좋습니다.
마지막으로 4vCPU이상을 가지는 xlarge급 이상에서 T instance가 효율적인 상황입니다.
t3.xlarge를 볼 때 t3.xlarge는 2.16vCPU에 16Gib 메모리를 가지니 차라리 돈을 조금 더 내고 4vCPU에 16Gib 메모리를 가지는 m5.xlarge를 사용하는 게 좋다고 생각할 수 있습니다. 하지만 지속적으로 계산이 필요하지 않고, 특정 시간에 리소스가 많이 필요한 웹서버등의 용도에서 m5.xlarge를 사용하며 cpu를 놀리는 것보다, 평균적으로 vCPU당 54% 이하로 사용한다면 t3.xlarge를 사용하는 것이 좋습니다.
그렇다면 t3.xlarge대신 m5.large를 사용하는 것은 어떨까요? 메모리는 절반으로 줄어들지만 전체 평균 사용가능 vCPU는 비슷하고, 비용은 절반가까이 줄어듭니다. 하지만 m5.large를 사용한다면 순간적으로 최대 2vCPU까지 밖에 사용하지 못하지만, t3.xlarge는 순간적으로 4vCPU까지 사용할 수 있는 차이점이 있습니다.
즉 T instance의 장점은 버스팅이 가능하다는 것에 있는 것입니다. 이는 마치 Scale-out을 하는 것과 같은 효과를 내줍니다.
T4g 시리즈
인스턴스 | vCPU | 시간당 크레딧 | 메모리(GiB) | vCPU당 기준 사용률 | vCPU 평균 유지량 | 손익분기 vCPU 기준 사용률 | 손익분기 vCPU 평균 유지 가능량 | M시리즈와 시간당 가격차이(A) | 손익분기 내에서 사용가능한 추가 vCPU(A*25) |
t4g.nano | 2 | 6 | 0.5 | 5% | 0.1 | 76.15625%(38.65625%) | 1.523125(0.773125%) | 0.056925(0.026925) | 1.423125(0.673125) |
t4g.micro | 2 | 12 | 1 | 10% | 0.2 | 77.3125%(39.8125%) | 1.54625(0.79625) | 0.05385(0.02385) | 1.34625(0.59625) |
t4g.small | 2 | 24 | 2 | 20% | 0.4 | 79.625%(42.125%) | 1.5925(0.8425) | 0.0477(0.0177) | 1.1925(0.4425) |
t4g.medium | 2 | 24 | 4 | 20% | 0.4 | 64.25%(26.75%) | 1.285(0.535) | 0.0354(0.0054) | 0.885(0.135) |
t4g.large | 2 | 36 | 8 | 30% | 0.6 | 43.5% | 0.87 | 0.094-0.0832=0.0108 | 0.27 |
t4g.xlarge | 4 | 96 | 16 | 40% | 1.6 | 53.5% | 2.14 | 0.188-0.1664 = 0.0216 | 0.54 |
t4g.2xlarge | 8 | 192 | 32 | 40% | 3.2 | 53.5% | 4.28 | 0.376-0.3328 = 0.0432 | 1.08 |
* 괄호는 m6g.medium과 비교 시입니다.
T4g 시리즈는 M6g 시리즈와 같은 프로세서를 사용하는데, 이때 m6g.medium(1vCPU, 4Gib)라는 비교대상이 추가되었기에 조금 더 복잡해집니다.
-- 추후작성 --
부록: 메모리 가격 계산 근거
가격 차이 | 메모리 차이 | 메모리 1Gib당 가격 | ||
m5.large | c5.large | |||
0.118 | 0.096 | 0.022 | 4Gib | 0.0055 |
m5.xlarge | c6.xlarge | |||
0.236 | 0.192 | 0.044 | 8Gib | 0.0055 |
m5.2xlarge | c6.2xlarge | |||
0.472 | 0.384 | 0.088 | 16Gib | 0.0055 |
가격 차이 | 메모리 차이 | 메모리 1Gib당 가격 | ||
m6g.medium | c6g.medium | |||
0.047 | 0.0385 | 0.0085 | 2Gib | 0.00425 |
m6g.large | c6g.large | |||
0.094 | 0.077 | 0.017 | 4Gib | 0.00425 |
m6g.xlarge | c6g.xlarge | |||
0.188 | 0.154 | 0.034 | 8Gib | 0.00425 |
m6g.2xlarge | c6g.2xlarge | |||
0.376 | 0.308 | 0.068 | 16Gib | 0.00425 |
'인프라 (Infra)' 카테고리의 다른 글
AWS ELB 구조 간단 정리 (0) | 2024.04.07 |
---|---|
클라우드 서비스(Azure, AWS, GCP, Oracle) Freetier 비교 (1) | 2022.12.15 |
AWS EC2로 code-server 생성하기 (0) | 2022.08.20 |
EC2 인스턴스 볼륨 확장하기 (0) | 2022.05.13 |