[Cloud Computing] Storage
EBS Storage
gp2·gp3부터 io1·io2, st1·sc1까지 — 개념, 계산법, 아키텍처, 그리고 언제 무엇을 써야 하는지. 스토리지는 이 글 하나로 끝낸다.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · Storage | 중급 | 약 20분 | VERIFIED |
EBS(Elastic Block Store)란?
EBS는 EC2에 붙여 쓰는 네트워크 기반 블록 스토리지다. 물리적으로는 EC2와 분리된 별도의 저장 장치인데, 마치 로컬 하드디스크처럼 동작한다.
"블록 스토리지"란 데이터를 정해진 크기의 블록 단위로 쪼개 저장하는 방식이다. S3 같은 "객체 스토리지"가 파일 하나를 통째로 하나의 객체로 다루는 것과 달리, 블록 스토리지는 OS가 파일시스템을 얹어서 마치 일반 디스크처럼 자유롭게 읽고 쓸 수 있다. 그래서 EBS는 OS·DB 파일처럼 수시로 부분 수정이 필요한 데이터에 적합하다.
EBS가 제공하는 저장 공간 하나의 단위. EC2에 "붙였다 뗄 수 있는" 가상의 하드디스크라고 보면 된다.
EBS(블록)는 파일의 일부만 수정 가능, S3(객체)는 파일 전체 단위로 다룬다. 그래서 OS 부팅 디스크는 EBS, 정적 파일 보관은 S3가 적합하다.
아키텍처 — EC2와 EBS는 어떻게 연결되나
EBS는 EC2 내부 디스크가 아니라, 같은 가용영역(AZ) 안의 네트워크를 통해 연결되는 별도의 스토리지다. 그래서 EBS 볼륨은 특정 AZ에 종속되며, 다른 AZ의 EC2에는 바로 붙일 수 없다(다른 AZ로 옮기려면 스냅샷을 거쳐야 한다).
OS 입장에서 EBS 볼륨은 디바이스 이름으로 보인다. 루트 볼륨(OS가 설치된 볼륨)은 보통 /dev/xvda이고, 추가로 붙이는 볼륨은 /dev/sdf, /dev/sdg 순으로 이름이 붙는다(Nitro 기반 인스턴스에서는 실제로 /dev/nvme1n1 같은 이름으로 매핑되기도 한다).
EC2와 EBS 사이의 네트워크 대역폭을 별도로 보장해주는 인스턴스 옵션. 이게 없으면 일반 네트워크 트래픽과 EBS I/O가 대역폭을 다퉈서 스토리지 성능이 불안정해질 수 있다.
IOPS와 처리량(Throughput)
IOPS(Input/Output Operations Per Second)는 초당 처리할 수 있는 입출력 작업의 횟수다. 처리량(Throughput)은 초당 옮길 수 있는 데이터의 양(MB/s)이다. 이 둘은 하나의 식으로 연결된다.
같은 IOPS라도 한 번에 옮기는 블록이 크면 처리량은 커진다. 그래서 작은 파일을 자주 여닫는 DB 트랜잭션은 IOPS가 중요하고, 큰 파일을 순차적으로 읽는 빅데이터 분석은 처리량이 중요하다 — 같은 "빠르다"도 워크로드에 따라 봐야 할 지표가 다르다.
처리를 기다리며 대기 중인 I/O 요청의 수. 이 값이 계속 쌓인다는 건 볼륨의 IOPS·처리량이 워크로드를 못 따라간다는 신호다.
gp2 — 범용 SSD (구세대)
gp2는 볼륨 크기에 비례해서 성능이 정해지는 범용 SSD다. 볼륨을 키우면 자동으로 IOPS도 늘어난다.
최소 100 IOPS, 최대 16,000 IOPS (5,334 GiB에서 도달)
예시 100 GiB → 300 IOPS · 500 GiB → 1,500 IOPS · 5,334 GiB 이상 → 16,000 IOPS(최대)
1TiB 미만 볼륨은 버스트(Burst)가 가능하다. 평소 baseline IOPS만큼 "크레딧"이 쌓이고, 순간적으로 트래픽이 몰리면 이 크레딧을 소모해 최대 3,000 IOPS까지 순간적으로 낼 수 있다. 문제는 크레딧을 다 쓰면 baseline 성능으로 뚝 떨어진다는 것 — 작은 볼륨일수록 이 "성능 절벽"을 자주 만난다.
- 설정이 단순함(용량만 정하면 끝)
- 가벼운 워크로드엔 비용 효율적
- 작은 볼륨은 크레딧 고갈 시 성능 급락
- 성능을 늘리려면 용량도 함께 키워야 함
gp2가 순간적으로 baseline 이상 성능을 낼 때 소모하는 크레딧. 평소 baseline 속도로 조금씩 쌓이고, 버스트 시 빠르게 소모된다. 다 떨어지면 baseline까지 성능이 떨어진다.
gp3 — 범용 SSD (현세대, 기본 권장)
gp3는 gp2의 가장 큰 불만 — "성능을 늘리려면 용량도 늘려야 한다" — 을 없앴다. 용량과 성능(IOPS·처리량)을 서로 독립적으로 조절할 수 있다.
추가 프로비저닝 가능 범위 최대 80,000 IOPS · 최대 2,000 MiB/s (2025년 확장 이후 기준, 최대 볼륨 크기 64 TiB)
→ 용량을 늘리지 않고도 IOPS·처리량만 따로 돈을 더 내고 늘릴 수 있다
- 용량과 성능을 독립적으로 조절 가능
- gp2 대비 GB당 비용이 더 저렴함
- burst 걱정 없이 항상 예측 가능한 성능
- 추가 IOPS·처리량은 별도 비용
- 극한의 고성능(80,000 IOPS 이상)은 여전히 io2가 필요
사용 이유 — 특별한 이유가 없다면 이제 gp2 대신 gp3를 기본으로 선택한다. 웹서버, 대부분의 DB, 일반 애플리케이션 서버의 기본 볼륨으로 적합하다.
io1 / io2 — 프로비저닝된 IOPS SSD
gp 시리즈가 "적당히 빠른 범용"이라면, io 시리즈는 내가 원하는 IOPS를 직접 지정하는 고성능 전용 볼륨이다. 데이터베이스처럼 일관되고 예측 가능한 초고성능이 필요할 때 쓴다.
io2 Block Express (차세대) 최대 256,000 IOPS · 최대 4,000 MiB/s · 99.999% 내구성 · 서브 밀리초 지연시간
io2는 io1과 같은 요금으로 내구성과 IOPS당 성능이 더 개선된 후속 버전이다. 굳이 io1을 새로 선택할 이유는 거의 없고, 신규 구축이라면 io2가 기본 선택지다.
- 가장 높고 예측 가능한 IOPS·처리량
- 낮고 일관된 지연시간
- Multi-Attach로 여러 인스턴스가 하나의 볼륨을 동시에 사용 가능(io1/io2)
- GB당·IOPS당 비용이 gp 시리즈보다 훨씬 비쌈
- 대부분의 워크로드엔 과한 스펙
사용 이유 — 대규모 트랜잭션 DB(Oracle, SAP HANA 등), 지연시간에 극도로 민감한 서비스, 혹은 gp3의 최대치(80,000 IOPS)로도 부족한 초고성능 워크로드.
하나의 io1/io2 볼륨을 여러 EC2 인스턴스에 동시에 연결하는 기능. 클러스터형 애플리케이션이 하나의 스토리지를 공유해야 할 때 쓰인다(단, 애플리케이션이 직접 동시 쓰기 충돌을 제어해야 한다).
st1 / sc1 — 처리량 최적화 HDD
SSD가 아니라 HDD 기반이다. IOPS가 아니라 순차적인 대용량 처리량에 최적화되어 있고, GB당 비용이 SSD보다 훨씬 저렴하다.
빅데이터 처리, 로그 처리, 데이터 웨어하우스처럼 큰 파일을 순차적으로 많이 읽고 쓰는 워크로드에 적합. 부팅 볼륨으로는 사용 불가.
가장 저렴한 볼륨 타입. 자주 접근하지 않는 데이터를 보관하는 용도(콜드 스토리지). 성능보다 비용이 최우선일 때.
스냅샷 — 볼륨의 백업
EBS 스냅샷은 특정 시점의 볼륨 상태를 S3에 저장하는 백업이다. 처음엔 전체를, 이후엔 변경된 블록만 저장하는 증분 방식이라 비용과 시간이 절약된다. 다른 AZ나 리전으로 볼륨을 옮기려면 이 스냅샷을 거쳐서 새 볼륨을 만들어야 한다.
운영 중인 볼륨을 중단 없이 실시간으로 크기·타입·성능을 변경할 수 있는 기능. gp2에서 gp3로의 무중단 전환도 이 기능 덕분에 가능하다.
종합 비교
| 구분 | gp2 | gp3 | io2 | st1 / sc1 |
|---|---|---|---|---|
| 타입 | 범용 SSD | 범용 SSD | 프로비저닝 IOPS SSD | HDD |
| 성능 결정 방식 | 용량에 비례 | 독립적으로 지정 | 독립적으로 지정 | 용량에 비례 |
| 기본/최대 IOPS | 3/GiB · 최대 16,000 | 3,000 무료 · 최대 80,000 | 최대 256,000(Block Express) | IOPS보다 처리량 중심 |
| 최대 처리량 | 250 MiB/s | 2,000 MiB/s | 4,000 MiB/s | ~500 MiB/s |
| 부팅 볼륨 | 가능 | 가능 | 가능 | 불가능 |
| 비용 | 중간 | gp2보다 저렴 | 가장 비쌈 | 가장 저렴 |
| 적합한 워크로드 | 레거시, 일반 용도 | 대부분의 범용 워크로드 | 대규모 트랜잭션 DB | 빅데이터, 로그, 콜드 보관 |
언제 무엇을 써야 할까
- 특별한 이유가 없다면 → gp3. 대부분의 웹서버, 애플리케이션 서버, 중소규모 DB에 충분하다.
- 초고성능·초저지연 DB → io2(필요시 Block Express). gp3의 최대치로도 부족한 트랜잭션 집약적 워크로드.
- 대용량 순차 처리(빅데이터·로그) → st1. IOPS보다 처리량이 중요할 때.
- 거의 안 쓰는 콜드 데이터 → sc1. 비용이 최우선일 때.
- gp2를 아직 쓰고 있다면 → gp3로 전환. 무중단으로 전환 가능하고, 대부분 성능은 그대로거나 더 좋아지면서 비용은 낮아진다.