gp3 vs io2: EBS 볼륨 선택 기준

인프라 AWS 비용
5 분 소요

EBS 볼륨 타입 선택은 두 질문으로 좁혀졌습니다. “gp3로 충분한가?“와 “io2가 필요한 조건은 무엇인가?“입니다. 이 글은 그 두 질문에 답하는 실무 기준을 정리합니다. 결론을 먼저 적으면, 대부분의 워크로드는 gp3가 정답이고, io2는 필요 조건이 명확할 때만 선택합니다. 스펙과 실측의 차이(fsync, 큐 깊이)는 서버가 느린 이유 #3에서 다뤘고, 여기서는 AWS 쪽 선택 기준에 집중합니다. 가격은 us-east-1 기준입니다.

gp2의 유산: 왜 아직도 gp2가 많은가 #

gp2는 성능이 크기에 묶인 모델이었습니다. GB당 3 IOPS가 기본이라 성능이 필요하면 용량을 불려야 했고, 작은 볼륨은 버스트 크레딧으로 버티다 크레딧이 마르면 성능이 계단으로 떨어졌습니다. “며칠은 멀쩡했는데 갑자기 느려졌다"는 EBS 사연의 대부분이 이 크레딧 소진입니다.

gp3는 이 결합을 끊었습니다. 그런데 gp2 시절에 만든 볼륨과 그 시절 템플릿·AMI가 지금도 gp2를 만들어 내고 있어서, 많은 계정에 gp2가 남아 있습니다. gp3가 GB당 약 20% 저렴하고 전환이 무중단이므로, 남은 gp2는 사실상 정리 대상입니다(점검 목록 참조).

gp3: 독립 프로비저닝과 상향된 상한 #

gp3의 구조는 세 줄로 요약됩니다.

  • 저장 용량(약 $0.08/GB·월)과 성능을 따로 삽니다.
  • 볼륨 크기와 무관하게 3,000 IOPS와 125MiB/s가 기본 포함입니다. 버스트 크레딧 개념이 없습니다.
  • 더 필요하면 추가 IOPS(3,000 초과분, IOPS당 약 $0.005/월)와 추가 처리량(125MiB/s 초과분, MB/s당 약 $0.04/월)을 얹습니다.

상한도 상향됐습니다. 볼륨당 최대 80,000 IOPS, 2,000MB/s까지 프로비저닝할 수 있습니다(한동안 16,000 IOPS·1,000MB/s였고, 오래된 자료에는 옛 상한이 남아 있습니다). 이 상향으로 “gp3 상한 때문에 io2로 간다"는 판단 기준선이 크게 올라갔습니다. 웬만한 데이터베이스급 워크로드도 gp3 범위 안에 들어옵니다.

한 가지 주의할 점은 볼륨 상한과 별개로 인스턴스 쪽 EBS 대역폭·IOPS 상한이 있다는 것입니다. 작은 인스턴스에 80,000 IOPS를 프로비저닝해도 인스턴스 한도에서 잘립니다. 볼륨을 키우기 전에 인스턴스 타입의 EBS 최적화 스펙을 먼저 확인합니다.

io2 Block Express: 필요한 조건이 명확한 프리미엄 #

현행 io2는 Block Express 아키텍처로, 다음 조건에서 선택합니다.

  • 매우 높은 IOPS: 볼륨당 최대 256,000 IOPS, 4,000MB/s. gp3 상한(80,000)을 실측으로 넘는 워크로드를 위한 선택지입니다.
  • 일관된 초저지연: Nitro 인스턴스 조합에서 밀리초 미만의 안정적인 I/O 지연을 제공합니다. 지연 스파이크에 민감한 트랜잭션 데이터베이스가 대상입니다.
  • 높은 내구성 요구: io2는 99.999% 내구성으로 gp3(99.8〜99.9%)보다 자릿수가 높습니다. 볼륨 손실이 곧 사고인 단일 볼륨 구성이라면 의미 있는 차이입니다.
  • IOPS 밀도: GB당 1,000 IOPS까지 걸 수 있어, 작은 용량에 높은 IOPS가 필요한 경우 gp3보다 유리한 구간이 있습니다.

가격 구조는 저장(약 $0.125/GB·월)에 프로비저닝한 IOPS 요금이 더해지는 방식이고, IOPS 요금은 구간제(32,000까지 IOPS당 약 $0.065, 초과 구간은 단가 인하)입니다. 같은 성능을 걸었을 때 gp3보다 몇 배 비싸므로, “혹시 몰라서 io2"는 낭비입니다.

선택 기준: 실측이 먼저입니다 #

타입 선택의 순서는 스펙 비교가 아니라 실측입니다.

  1. 현재 소비량을 잽니다: CloudWatch의 볼륨 지표(VolumeReadOps+VolumeWriteOps를 초당으로 환산, VolumeThroughputPercentage, gp2라면 BurstBalance)로 피크 IOPS·처리량을 확인합니다. OS 쪽에서는 iostat -x의 IOPS와 aqu-sz, await로 실제 병목 여부를 봅니다. 읽는 법은 서버가 느린 이유 #3에서 다뤘습니다.
  2. 피크가 3,000 IOPS·125MiB/s 안이면 gp3 기본형으로 끝입니다. 대부분의 웹·API 서버, 소규모 DB가 여기 해당합니다.
  3. 피크가 그 위라면 gp3에 필요한 만큼 IOPS·처리량을 얹습니다. 80,000 IOPS·2,000MB/s까지는 gp3가 io2보다 거의 항상 쌉니다.
  4. io2로 넘어가는 조건은 실측 요구가 gp3 상한을 넘거나, 밀리초 미만 지연의 일관성·99.999% 내구성·GB당 IOPS 밀도라는 명시적 요구가 있을 때입니다.
  5. 처리량 중심(순차 대용량)이라면 st1 같은 HDD 계열이 남아 있지만, gp3 처리량 단가가 낮아진 뒤로는 gp3로 통일하는 쪽이 운영상 단순한 경우가 많습니다.

전환 실무: Elastic Volumes로 무중단 #

볼륨 타입·크기·성능 변경은 Elastic Volumes로 인스턴스를 세우지 않고 적용됩니다. aws ec2 modify-volume으로 gp2 → gp3 전환, IOPS 증설 모두 온라인으로 되고, 변경 후 최적화 상태(optimizing)가 끝날 때까지 성능이 점진적으로 적용됩니다. 주의점은 두 가지입니다. 같은 볼륨의 변경은 6시간에 한 번만 가능하고, 크기는 키울 수만 있습니다(축소는 새 볼륨으로 옮겨야 합니다).

gp2 → gp3 일괄 전환 시에는 gp2 크기 비례로 받던 IOPS보다 gp3 기본(3,000)이 낮아지는 큰 볼륨(1TB 초과)이 없는지만 확인합니다. 있다면 그 볼륨만 IOPS를 얹어 기존 성능을 맞춥니다.

정리 #

  • 기본값은 gp3입니다. 크기와 성능을 따로 사고, 버스트 크레딧이 없으며, 3,000 IOPS·125MiB/s가 기본 포함입니다.
  • gp3 상한은 80,000 IOPS·2,000MB/s로 상향됐습니다. 옛 상한(16,000)을 기준으로 io2를 고르는 자료는 낡았습니다.
  • io2 Block Express는 초고IOPS(최대 256,000), 밀리초 미만 지연 일관성, 99.999% 내구성, GB당 IOPS 밀도가 필요할 때의 선택입니다.
  • 타입 선택은 스펙표가 아니라 실측(CloudWatch 볼륨 지표, iostat)에서 시작합니다. 볼륨 상한 못지않게 인스턴스 쪽 EBS 한도도 확인합니다.
  • gp2 잔존 볼륨은 Elastic Volumes로 무중단 전환이 되므로, 20% 절감을 미룰 이유가 없습니다.
X