Cloud Native Operations

한국어

English

한국어

English

Appearance

EBS gp2 vs gp3 실측 벤치마크 퀴즈 ​

  1. 100 GiB gp2 볼륨에 4k 랜덤 읽기(qd32)를 지속했을 때 실측된 IOPS 변화로 옳은 것은?
    • A) 처음부터 300 IOPS 근처에서 완만하게 오르내렸다
    • B) 약 33분(1,999초)까지 gp3와 같은 3,001 IOPS를 유지하다가 1초 안에 300 IOPS로 떨어졌다
    • C) 3,000 IOPS에서 시작해 45분 동안 서서히 300 IOPS까지 줄어들었다
    • D) 3,000 IOPS를 45분 내내 유지했다
정답 보기

정답: B) 약 33분(1,999초)까지 gp3와 같은 3,001 IOPS를 유지하다가 1초 안에 300 IOPS로 떨어졌다

설명: fio의 초 단위 IOPS 로그에서 1,998초 3,001 → 1,999초 2,659 → 2,000초 300으로 기록되었습니다. gp2는 크레딧이 남아 있는 동안 gp3와 구분되지 않고, 크레딧이 바닥나는 순간 스위치를 내린 듯 90%가 사라집니다. "gp2는 느리다"가 아니라 "gp2는 갑자기 느려진다"가 정확한 표현입니다.

  1. 100 GiB gp2 볼륨의 버스트 지속 시간이 약 2,000초로 계산되는 근거는?
    • A) 5,400,000 크레딧 ÷ (3,000 − 300) IOPS = 2,000초
    • B) 100 GiB × 20초/GiB = 2,000초
    • C) 3,000 IOPS ÷ 1.5 = 2,000초
    • D) AWS가 볼륨 크기와 무관하게 2,000초로 고정한 값이다
정답 보기

정답: A) 5,400,000 크레딧 ÷ (3,000 − 300) IOPS = 2,000초

설명: gp2는 3 IOPS/GiB 베이스라인(100 GiB → 300 IOPS)과 540만 크레딧 버킷을 가집니다. 3,000 IOPS로 버스트하면 베이스라인으로 충전되는 300을 뺀 2,700 크레딧이 매초 소모되므로 5,400,000 ÷ 2,700 = 2,000초입니다. 볼륨이 크면 베이스라인이 올라가 소모 속도가 느려지고, 1,000 GiB 이상이면 베이스라인이 최소 3,000 IOPS여서 절벽이 없습니다.

  1. 크레딧 소진 후 gp2의 qd32 평균 레이턴시가 약 106ms로 측정되었습니다. 이 값을 올바르게 해석한 것은?
    • A) EBS 디바이스의 응답 시간이 100ms 이상으로 느려졌다
    • B) Little의 법칙대로 32개 미결 I/O ÷ 300 IOPS ≈ 106.7ms, 즉 대기와 실제 처리를 포함한 평균 응답시간 근사이다
    • C) 네트워크 지연이 급증한 것이다
    • D) fio의 측정 오류다
정답 보기

정답: B) Little의 법칙대로 32개 미결 I/O ÷ 300 IOPS ≈ 106.7ms, 즉 대기와 실제 처리를 포함한 평균 응답시간 근사이다

설명: 평균 레이턴시 = 미결 I/O 수 ÷ 처리량입니다. 32개를 항상 대기시키면서 초당 300개만 처리되면 각 I/O는 평균 106.7ms를 대기합니다. 3,000 IOPS일 때의 10.4ms도 같은 계산(32 ÷ 3,000 = 10.7ms)입니다. 이 계산은 평균 미결 I/O가 32라고 가정한 전체 응답시간이며 큐 대기와 실제 처리시간을 분리하지 않습니다. qd1도 커널·가상화·EBS 서비스의 지연을 포함합니다.

  1. 크레딧 소진 직후 gp2에서 120초 랜덤 쓰기를 돌렸을 때 300이 아닌 601 IOPS가 측정된 이유는?
    • A) 쓰기는 크레딧을 소모하지 않기 때문에
    • B) 직전 120초 동안 gp2가 쉬면서 300 크레딧/s × 120초 = 36,000 크레딧이 충전되어, 120초 테스트에 300 IOPS가 추가되었기 때문에
    • C) fio가 쓰기 IOPS를 2배로 집계하기 때문에
    • D) gp2의 쓰기 베이스라인이 읽기의 2배이기 때문에
정답 보기

정답: B) 직전 120초 동안 gp2가 쉬면서 300 크레딧/s × 120초 = 36,000 크레딧이 충전되어, 120초 테스트에 300 IOPS가 추가되었기 때문에

설명: gp2 크레딧 버킷은 한 번 비면 끝이 아니라 볼륨이 쉴 때마다 초당 3 크레딧/GiB(100 GiB → 300/s)씩 다시 채워지는 통장입니다. 36,000 크레딧을 120초에 나눠 쓰면 300 IOPS가 베이스라인 300에 더해져 정확히 600이 됩니다(실측 601). qd1 측정에서 603 IOPS가 나온 것도 60초 휴식 동안 충전된 18,000 크레딧으로 같은 계산입니다. 간헐적 트래픽에서 gp2가 "어떤 날은 빠르고 어떤 날은 느린" 이유입니다.

  1. qd1 4k 랜덤 읽기에서 스로틀 중인 gp2의 p50은 0.602ms, p95는 3.391ms였습니다. 이 분포가 말해주는 것은?
    • A) gp2 디바이스가 gp3보다 근본적으로 느리다
    • B) 비슷한 p50에도 꼬리 지연이 커서 스로틀 대기 해석과 일치하지만, 물리 디바이스가 같다는 증거는 아니다
    • C) 측정 중 다른 파드가 볼륨을 공유했다
    • D) 랜덤 읽기는 항상 이중 분포를 보인다
정답 보기

정답: B) 비슷한 p50에도 꼬리 지연이 커서 스로틀 대기 해석과 일치하지만, 물리 디바이스가 같다는 증거는 아니다

설명: gp2 I/O의 절반은 gp3와 똑같이 0.6ms에 끝났습니다. 나머지 절반이 3.4~3.6ms로 밀린 것은 초당 허용량(약 603 IOPS)을 넘은 I/O가 스로틀 큐에서 기다렸기 때문입니다. 평균만 보면 1.65ms로 "약간 느린" 정도지만 p95는 6배 뛰었습니다. 스토리지 대시보드에 p50과 p95/p99를 함께 두어야 하는 이유입니다.

  1. 1 MiB 순차 읽기/쓰기에서 gp2와 gp3가 모두 125~130 MiB/s에서 멈춘 이유로 옳은 것은?
    • A) gp3는 125 MiB/s 베이스라인, gp2(≤170 GiB)는 128 MiB/s 상한에 각각 걸렸고, 두 값이 우연히 비슷하다
    • B) m5.xlarge 인스턴스의 네트워크 대역폭 한도 때문이다
    • C) fio의 iodepth=8이 병목이었다
    • D) gp2의 크레딧이 바닥나서 두 볼륨 모두 느려졌다
정답 보기

정답: A) gp3는 125 MiB/s 베이스라인, gp2(≤170 GiB)는 128 MiB/s 상한에 각각 걸렸고, 두 값이 우연히 비슷하다

설명: gp3 기본 처리량은 125 MiB/s, gp2는 170 GiB 이하에서 128 MiB/s가 상한입니다. gp2의 빈 크레딧 버킷이 순차 테스트를 느리게 하지 않은 이유는 EBS가 1 MiB I/O를 256 KiB 4개로 계산해 130 MiB/s ≈ 520 IOPS에 불과하고, 직전 휴식으로 충전된 36,000 크레딧 안에 충분히 들어가기 때문입니다. 처리량 상한이 IOPS 상한보다 먼저 걸렸습니다. 참고로 m5.xlarge의 인스턴스 EBS 대역폭(≈137 MiB/s)은 이보다 조금 높아 이 테스트의 병목은 아니었지만, gp3를 250 MiB/s로 올리면 인스턴스 버스트 동안 이 값을 넘을 수 있지만 지속 계획에는 약 137 MiB/s 베이스라인을 사용합니다.

  1. 서울 리전 기준으로 이 문서의 2026-09 단가로 100 GiB 데이터셋에 지속 3,000 IOPS가 필요할 때 비용 비교로 옳은 것은?
    • A) gp2 100 GiB($11.40)로 충분하다
    • B) gp3 100 GiB($9.12)가 버스트 크레딧 없이 3,000 IOPS를 제공하고, gp2로 같은 베이스라인을 얻으려면 1,000 GiB($114.00)가 필요해 약 12배 차이가 난다
    • C) gp3에 IOPS를 별도로 추가해야 하므로 gp2보다 비싸다
    • D) 두 볼륨의 월 비용은 동일하다
정답 보기

정답: B) gp3 100 GiB($9.12)가 버스트 크레딧 없이 3,000 IOPS를 제공하고, gp2로 같은 베이스라인을 얻으려면 1,000 GiB($114.00)가 필요해 약 12배 차이가 난다

설명: gp2 100 GiB는 $11.40에 300 IOPS 베이스라인을 가지며 초기 크레딧이 가득 찬 3,000 IOPS 부하에서는 약 33분간 버스트합니다. gp2 시대에는 IOPS를 얻기 위해 용량을 1,000 GiB로 키우는 것이 관행이었고 그 비용이 $114.00입니다. gp3는 IOPS를 용량과 분리해 100 GiB $9.12로 같은 3,000 IOPS를 제공합니다. 필요하면 6,000 IOPS(+$17.10)나 250 MiB/s(+$5.70)를 따로 살 수도 있습니다.

  1. 이미 데이터가 들어 있는 gp2 PVC를 파드 재시작 없이 gp3로 바꾸는 Kubernetes 네이티브 방법은?
    • A) StorageClass의 type 파라미터를 gp3로 수정하면 기존 PV가 자동으로 바뀐다
    • B) VolumeAttributesClass(storage.k8s.io/v1, Kubernetes 1.34 GA)를 만들고 PVC의 volumeAttributesClassName을 지정하면 EBS CSI 드라이버가 ModifyVolume을 호출한다
    • C) PVC를 삭제하고 gp3 StorageClass로 다시 만들어야 한다
    • D) 노드에서 aws ec2 modify-volume을 실행하는 것만이 유일한 방법이다
정답 보기

정답: B) VolumeAttributesClass(storage.k8s.io/v1, Kubernetes 1.34 GA)를 만들고 PVC의 volumeAttributesClassName을 지정하면 EBS CSI 드라이버가 ModifyVolume을 호출한다

설명: StorageClass의 파라미터는 새 볼륨 생성 시에만 적용되고 기존 PV에는 영향이 없습니다. VolumeAttributesClass는 type, iops, throughput을 파드 실행 중에 변경할 수 있게 해 주며 내부적으로 EBS Elastic Volumes를 사용합니다. 단, EBS는 같은 볼륨의 다음 수정을 이전 수정이 completed된 뒤에만 허용하고(1 TiB 볼륨은 최대 6시간 소요) 24시간 롤링 구간에 볼륨당 최대 4회까지만 수정할 수 있으므로 타입·IOPS·처리량 변경을 한 번의 요청에 묶어야 하고, 1.31~1.33에서는 v1beta1 API와 피처 게이트가 필요합니다. VAC를 사용해도 기존 storageClassName은 자동으로 바뀌지 않습니다. PVC 변경 상태와 실제 EBS 속성을 함께 확인합니다.