EBS 볼륨 종류
1. gp3 (General Purpose SSD)
-
용도: 웹/앱 서버, 중소형 DB 등 대부분의 일반 워크로드
-
특징:
- 비용 효율 최고, 새 프로젝트의 사실상 기본값 / 부팅 가능(SSD)
- IOPS와 처리량을 독립적으로 설정 가능
-
주의: 인스턴스의 EBS 대역폭 한도도 병목이 될 수 있음(인스턴스 스펙 고려)
2. gp2 (General Purpose SSD, 레거시)
-
용도: 기존 레거시 워크로드 호환 / 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에 사용
-
특징:
-
gp2는 레거시 취급이라 새로 선택하진 않음(점진적 gp3 전환 권장) / SSD 타입은 EC2의 루트 볼륨로 쓸 수 있음
-
비용 효율적인 스토리지이면서 낮은 대기시간을 제공
-
IOPS와 처리량이 서로 연결되어 있다
-
3. io1 (Provisioned IOPS SSD)
-
용도: 지연 민감·트랜잭션성 DB(OLTP), I/O 집약 워크로드
-
특징: Multi-Attach 지원(io1/io2 전용) → 같은 AZ의 여러 인스턴스에 동시 연결(특수 파일시스템/클러스터링 전제) / 일부 리전 제약 있음
-
주의: 비용 높음. 부팅 가능(SSD)
4. io2 (Provisioned IOPS SSD)
-
용도: 미션 크리티컬 DB, 높은 내구성과 일관 I/O 필요
-
파생: io2 Block Express(초대형/초고성능 볼륨) 옵션
-
특징: 비용 높음, 부팅 가능(SSD)
5. st1 (Throughput Optimized HDD)
-
용도: 대용량 순차 I/O(로그 처리, 빅데이터, ETL 등) => 큰 파일을 길게/연속으로 읽고 쓰는 작업
-
특징: 부팅 불가(HDD), 랜덤 I/O/저지연에는 부적합 / 저비용 대용량 볼륨
6. sc1 (Cold HDD)
- 용도: 아주 드물게 접근하는 대용량 데이터(콜드/아카이브 성향)
- 특징: 부팅 불가(HDD), 최저 비용/최저 성능
HDD vs SDD
| 구분 | HDD (예: st1, sc1) | SSD (예: gp3, gp2, io1, io2) |
|---|---|---|
| 동작 방식 | 기계식(회전+헤드 이동) | 반도체(전자식) |
| 지연시간(Latency) | 큼(헤드 이동/회전 대기) | 작음(즉시 접근) |
| 랜덤 I/O (IOPS) | 약함 | 강함 |
| 순차 처리량(Throughput) | 큰 파일 연속 처리에 유리 | 충분히 좋지만 비용↑ |
| 내구성/충격 민감 | 기계식이라 상대적 약함 | 기계 부품 없어 유리 |
| 비용/GB | 저렴 | 비쌈 |
| 부팅 볼륨 | 불가(EBS st1/sc1) | 가능(gp3/gp2/io1/io2) |
| 적합 워크로드 | 로그/백업/ETL 같은 대용량 순차 처리 | DB/OLTP/메타데이터/일반 서버 등 랜덤·혼합 I/O |
EBS 볼륨 타입
| 타입 | 성격/용도 | 성능 모델 | 특징(시험 포인트) | 부팅 가능 |
|---|---|---|---|---|
| gp3 (General Purpose SSD) | 대부분의 일반 워크로드, 웹/앱 서버, 중소형 DB | 기본 IOPS/처리량 제공 + 필요량을 별도 프로비저닝 | 비용 효율 최고. IOPS·Throughput을 용량과 독립적으로 설정 가능(베이스라인 존재). 신규 배포의 디폴트. | ✅ |
| gp2 (General Purpose SSD, 레거시) | 기존 레거시 워크로드 호환 | 용량에 비례해 IOPS 증가, 버스트 크레딧 | 새로 쓰진 않음(마이그레이드 대상). 버스트 크레딧 고갈 시 성능 저하. | ✅ |
| io1 (Provisioned IOPS SSD) | 트랜잭션성 DB(OLTP), 지연 민감 워크로드 | IOPS를 명시적으로 프로비저닝 | 고성능/안정적 IOPS 필요 시. 오늘날은 io2 권장. | ✅ |
| io2 (Provisioned IOPS SSD) | 미션 크리티컬 DB, 고내구성 필요 | IOPS 프로비저닝(내구성↑) | io1 대비 내구성 향상. Nitro 기반에서 큰 IOPS/처리량 가능. io2 Block Express로 초대형·초고성능 지원(옵션). | ✅ |
| st1 (Throughput Optimized HDD) | 대용량 순차 I/O(빅데이터, 로그 처리, ETL) | 처리량(Throughput) 중심 + 버스트 | HDD 계열, 비용/GB 저렴. 부팅 볼륨 불가. 랜덤 I/O·저지연에는 부적합. | ❌ |
| sc1 (Cold HDD) | 드물게 접근하는 대용량 데이터(아카이브 성향) | 낮은 처리량 + 버스트 | 가장 저렴한 HDD. 부팅 불가, 성능 낮음. 백업/콜드 데이터에만. | ❌ |
EBS 볼륨중에 루트 볼륨(os가 부팅되는 곳)이 되는게 SSD 계열
EBS 다중 연결
EBS 볼륨 중 io1 및 io2 제품군에서만 사용할 수 있음
각 인스턴스는 고성능 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖게 됨
ex) 인스턴스 A, B, C 모두가 동시에 그 하나의 블록 디바이스에 읽기/쓰기를 할 수 있음
⚠️ 중요한 주의점
일관성/락은 AWS가 보장하지 않음 → 클러스터 파일시스템(GFS2, OCFS2) 또는 애플리케이션 락을 반드시 사용해야 함
Use case
- 클러스터화된 linux 애플리케이션
- 애플리케이션에서 동시 쓰기 작업을 관리하는 경우
다중 연결의 제한
- 지정된 가용 영역 내에서만 사용 가능
- 하나의 볼륨은 한 번에 최대 16개의 EC2 인스턴스에 부착할 수 있다
다중 연결이 동작하려면 클러스터를 인식할 수 있는 파일 시스템을 사용해야 함
=> 일반 ext4/xfs 같은 단일 호스트용 FS를 그대로 공유하면 100% 데이터 손상
why❓
여러 대가 동시에 같은 디스크에 쓰면 서로 누가 먼저/어디에 썼는지 조율이 안 돼서
메타데이터가 꼬이고(저널 충돌),각자 메모리에 들고 있던 캐시 내용이 서로 모순이 되고, 결국 파일시스템이 손상
여러 노드가 동시에 접근하려면, OS/파일시스템 레벨에서 분산 잠금(DLM), 저널 공유/조율, 캐시 무효화 규칙, 펜싱(fencing) 등을 갖춘 “클러스터 인식 파일시스템”이 꼭 필요함
대표 예: GFS2, OCFS2 (여러 노드가 같은 블록 장치를 안전하게 공유하도록 설계됨)
