하드웨어 기초 #9 클라우드 인스턴스 사양 읽는 법 — 워크로드에 맞춰 고르기
#8에서 IaaS를 쓰면 결국 인스턴스 타입을 직접 고른다고 했습니다. 이 마지막 글은 그 고르는 일을 다룹니다. c5.xlarge 같은 이름은 처음 보면 암호 같지만, 이 시리즈를 따라왔다면 그 안의 모든 글자가 #1의 네 자원으로 풀립니다. 사양표를 읽고 워크로드에 맞는 타입을 고르는 것으로 시리즈를 닫겠습니다.
하드웨어 기초 시리즈에서 이번 글의 위치입니다.
- #1 컴퓨터를 움직이는 네 가지 자원 — CPU / 메모리 / 스토리지 / 네트워크
- #2 CPU — 코어 / 스레드 / 클럭 / 캐시, 그리고 vCPU의 정체
- #3 메모리 — RAM과 계층 구조, 스왑이 시작되면 벌어지는 일
- #4 스토리지 ① 장치 — HDD / SSD / NVMe와 IOPS / 처리량 / 지연시간
- #5 스토리지 ② 구성과 연결 — RAID와 DAS / NAS / SAN
- #6 네트워크 — 대역폭과 지연시간, NIC에서 데이터센터까지
- #7 가상화와 컨테이너 — 물리 서버 한 대가 여러 대가 되는 원리
- #8 클라우드 — 소유에서 임대로, 온프레미스부터 IaaS / PaaS / SaaS까지
- #9 클라우드 인스턴스 사양 읽는 법 — 워크로드에 맞춰 고르기 ← 이번 글
인스턴스 이름 해부하기 #
AWS의 인스턴스 이름은 규칙이 있습니다. c5.xlarge를 예로 들면 세 조각으로 나뉩니다.
c 5 xlarge
패밀리 세대 크기
(용도) (몇 세대) (얼마나 큰가)- 패밀리 — 어느 자원에 치우친 타입인가(
c는 컴퓨트 최적화) - 세대 — 몇 세대인가(숫자가 클수록 최신, 대체로 더 빠르고 효율적)
- 크기 — 자원이 얼마나 많은가(
large→xlarge→2xlarge로 커짐)
이름만 읽어도 “최신 세대의 컴퓨트 중심 중간 크기"라는 성격이 드러납니다. 다른 클라우드도 표기는 다르지만 패밀리,크기를 나눠 부르는 구조는 비슷합니다.
패밀리 — 어느 자원에 치우쳤나 #
패밀리는 #1의 네 자원 중 어디에 무게를 뒀는지를 나타냅니다. 같은 vCPU라도 메모리 비율과 스토리지 성격이 달라집니다.
| 패밀리 | 성격 | 치우친 자원 | 맞는 워크로드 |
|---|---|---|---|
t | 버스터블,범용 | 평소 적게, 잠깐 더 | 트래픽 적은 소규모 |
m | 범용 | vCPU와 메모리 균형 | 일반 웹,앱 서버 |
c | 컴퓨트 최적화 | CPU 비중 높음 | 계산 위주, 배치 |
r | 메모리 최적화 | 메모리 비중 높음 | 데이터베이스,캐시 |
i | 스토리지 최적화 | 빠른 로컬 NVMe | 대용량,고 IOPS |
c 계열은 메모리 대비 vCPU가 많고, r 계열은 그 반대입니다. #2의 CPU와 #3의 메모리 중 무엇이 병목이 될지에 따라 패밀리가 갈립니다.
크기 — 같은 패밀리 안의 배수 #
크기는 같은 패밀리 안에서 자원의 양을 정합니다. 한 단계 커질 때마다 vCPU와 메모리가 대체로 두 배씩 늘고, 가격도 그만큼 오릅니다.
| 크기 | vCPU | 메모리 | 가격 |
|---|---|---|---|
large | 2 | 기준 | 기준 |
xlarge | 4 | 2배 | 약 2배 |
2xlarge | 8 | 4배 | 약 4배 |
vCPU가 #2에서 본 대로 보통 하이퍼스레드 단위라는 점을 떠올리면, xlarge의 4vCPU는 대체로 물리 코어 2개에 해당합니다.
네 자원으로 사양표 읽기 #
인스턴스 상세 페이지의 사양표는 결국 이 시리즈의 네 자원입니다. 각 항목을 어느 글에서 다뤘는지로 정리하면 사양표가 한눈에 들어옵니다.
| 사양표 항목 | 무엇인가 | 다룬 글 |
|---|---|---|
| vCPU | 하이퍼스레드 단위의 계산 능력 | #2 |
| 메모리(GiB) | 작업 공간의 양 | #3 |
| 스토리지 | EBS 전용인지 로컬 NVMe인지 | #4 , #5 |
| 네트워크 대역폭 | 최대 Gbps | #6 |
“EBS 최적화"나 “최대 10Gbps” 같은 표기도 이제 해석됩니다. 전자는 #5의 네트워크 블록 스토리지에 더 많은 대역폭을 보장한다는 뜻이고, 후자는 #6의 NIC 상한입니다.
워크로드별로 고르기 #
워크로드마다 병목이 되는 자원이 다릅니다. 그 자원에 치우친 패밀리를 고르는 것이 출발점입니다.
| 워크로드 | 주된 병목 | 권하는 패밀리 |
|---|---|---|
| 일반 웹,앱 서버 | 균형 | m(범용) |
| 계산 위주 배치,인코딩 | CPU | c(컴퓨트) |
| 데이터베이스,인메모리 캐시 | 메모리 | r(메모리) |
| 대용량,고 IOPS 저장 | 스토리지 | i(스토리지) |
| 트래픽 적은 소규모 | 평소 낮음 | t(버스터블) |
고르는 순서 #
순서는 #1의 병목 원칙을 그대로 따릅니다.
- 병목 자원을 정합니다. 이 워크로드가 CPU,메모리,스토리지,네트워크 중 무엇에 가장 민감한지 봅니다.
- 패밀리를 고릅니다. 그 자원에 치우친 패밀리를 선택합니다.
- 크기를 고릅니다. 필요한 vCPU와 메모리에 맞게 정하고, 처음에는 작게 잡습니다.
- 측정하고 조정합니다. 실제 부하에서 어느 자원이 먼저 한계에 닿는지 보고 크기나 패밀리를 바꿉니다.
핵심은 추측으로 크게 잡지 않는 것입니다. 작게 시작해 측정으로 키우는 편이, 처음부터 크게 잡아 비용을 흘리는 것보다 낫습니다.
자주 만나는 함정 #
“넉넉하게 큰 걸로 잡자” #
가장 흔한 비용 낭비입니다. 대부분의 인스턴스는 평소 자원이 남습니다. 작게 시작해 측정으로 키우는 순서가 비용을 아낍니다.
“vCPU 수만 보고 골랐다” #
같은 vCPU라도 패밀리에 따라 메모리 비율이 다릅니다. 데이터베이스를 c 계열에 올리면 메모리가 먼저 모자라 #3의 스왑으로 빠질 수 있습니다.
“버스터블(t)로 상시 부하를 돌렸다”
#
#2에서 짚었듯 t 계열은 크레딧이 떨어지면 성능이 제한됩니다. 꾸준히 CPU를 쓰는 워크로드에는 맞지 않습니다.
“한 번 고르면 끝이다” #
워크로드는 변합니다. 측정값을 보고 주기적으로 타입을 재검토하는 것이 과대,과소 프로비저닝을 막습니다.
정리 — 시리즈를 닫으며 #
이번 글에서 잡은 그림입니다.
- 인스턴스 이름은 패밀리(용도),세대,크기로 해부됩니다.
- 패밀리는 네 자원 중 어디에 치우쳤는지를(
m,c,r,i,t), 크기는 자원의 양을 정합니다. - 사양표의 vCPU,메모리,스토리지,네트워크는 각각 #2,#3,#4,#6에서 다룬 그 자원입니다.
- 고르는 순서는 병목 자원 → 패밀리 → 크기 → 측정 후 조정입니다. 작게 시작해 측정으로 키웁니다.
아홉 편에 걸쳐 네 자원에서 출발해 클라우드 인스턴스 사양표까지 왔습니다. 이제 “느리다"와 “비싸다"는 추측이 아니라 진단의 대상입니다.
다음 — AWS로 #
이 시리즈가 사양표를 읽는 법까지였다면, 인스턴스를 실제로 띄우고 운영하는 법은 AWS 시리즈의 몫입니다. AWS 기초에서 계정과 리전을 잡고, AWS 중급의 EC2,VPC에서 이번 글의 인스턴스를 직접 띄우고, 스토리지(S3)로 연결하는 흐름으로 이어가면, 하드웨어 지식이 실제 운영으로 연결됩니다.