티스토리 뷰

Data & MarTech/AWS

AWS Solution Architect 준비: EBS - IOPS

Jason Nam 2025. 12. 13. 15:53

AWS EBS IOPS

클라우드 스토리지 성능의 핵심 지표, IOPS를 제대로 이해하고 활용하는 방법

🎯 들어가며

AWS에서 애플리케이션을 운영하다 보면 "IOPS"라는 용어를 자주 접하게 됩니다. 특히 데이터베이스나 ETL 작업처럼 디스크 I/O가 중요한 워크로드에서는 IOPS 설정이 성능과 비용을 좌우하는 핵심 요소가 됩니다. 이 글에서는 EBS IOPS의 개념부터 실전 최적화 전략까지 상세히 알아보겠습니다.

📖 IOPS란 무엇인가?

**IOPS(Input/Output Operations Per Second)**는 스토리지 볼륨이 초당 처리할 수 있는 읽기/쓰기 작업의 수를 의미합니다.

핵심 특징

측정 기준: 16KiB I/O 작업 단위로 측정
워크로드 유형: 데이터베이스, 가상 데스크톱, 부트 볼륨 등 transactional workload에 중요
성능 지표: SSD 기반 볼륨의 주요 성능 측정 기준

쉽게 말해, IOPS는 스토리지의 "처리 속도"를 나타내는 지표입니다. 높은 IOPS는 더 많은 데이터 요청을 동시에 처리할 수 있음을 의미합니다.

🗂️ EBS 볼륨 타입별 IOPS 성능 비교

AWS EBS는 워크로드 특성에 따라 다양한 볼륨 타입을 제공합니다.

SSD 기반 볼륨 (Transactional Workload)

1. gp3 (General Purpose SSD) - 권장 옵션

최대 IOPS: 80,000
기본 제공: 3,000 IOPS (추가 비용 없음)
용량: 1 GB ~ 64 TB
가격: $0.08/GB-month + 추가 IOPS 비용
특징: 가장 비용 효율적, 대부분의 워크로드에 적합

비용 구조:

기본 3,000 IOPS 무료
3,000 IOPS 초과 시: $0.005/provisioned IOPS-month
125 MB/s 무료, 초과 시: $0.04/provisioned MB/s-month

2. gp2 (General Purpose SSD) - 레거시

최대 IOPS: 16,000
성능 확장: 3 IOPS/GiB (용량에 비례)
용량: 1 GB ~ 16 TB
특징: Burst 크레딧 시스템, gp3로 마이그레이션 권장

성능 계산:

33.33 GiB 이하: 최소 100 IOPS
33.33 GiB 초과: 용량(GiB) × 3 IOPS
5,334 GiB에서 최대 16,000 IOPS 도달

3. io2 Block Express - 최고 성능

최대 IOPS: 256,000
IOPS/GiB 비율: 1,000:1
용량: 최대 64 TB
처리량: 4,000 MB/s
레이턴시: 평균 500 마이크로초 미만
가격: $0.125/GB-month + $0.065/provisioned IOPS-month

최적 사용 케이스:

SAP HANA, Oracle, Microsoft SQL Server
Mission-critical 데이터베이스
99.999% 내구성 요구 워크로드

4. io1 - 고성능

최대 IOPS: 64,000
IOPS/GiB 비율: 50:1
용량: 4 GB ~ 16 TB
특징: io2로 업그레이드 권장 (동일 가격에 더 나은 성능)

HDD 기반 볼륨 (Throughput 중심)

st1 (Throughput Optimized): MapReduce, 로그 처리
sc1 (Cold HDD): 아카이브, 저빈도 액세스

⚡ 실제 IOPS 성능 결정 요소

프로비저닝한 IOPS를 모두 활용하려면 세 가지 요소를 고려해야 합니다.

1. 볼륨 설정

볼륨 타입과 크기, 프로비저닝한 IOPS 값

2. EC2 인스턴스 제한

중요: 인스턴스의 EBS 성능은 인스턴스 타입의 성능 제한 또는 연결된 볼륨의 총합 성능 중 더 작은 값으로 제한됩니다.

예시: r6i.16xlarge에서 80,000 IOPS 달성

옵션 1: gp2 볼륨 5개 × 16,000 IOPS = 80,000 IOPS
옵션 2: gp3 볼륨 1개를 80,000 IOPS로 프로비저닝
옵션 3: io2 Block Express 1개

3. 네트워크 대역폭

EBS-Optimized 인스턴스 사용 필수
인스턴스별 "Dedicated EBS Bandwidth" 확인
예: m7i.large는 10 Gbps 전용 EBS 대역폭 제공

📊 IOPS 모니터링 및 최적화 전략

CloudWatch 핵심 메트릭

필수 모니터링 메트릭:
  VolumeReadOps/VolumeWriteOps:
    설명: 실제 읽기/쓰기 작업 수
    활용: 초로 나누어 실제 IOPS 계산
    
  VolumeThroughputPercentage:
    설명: IOPS 사용률 (%)
    알람 기준: 80% 초과 시 알림
    
  VolumeQueueLength:
    설명: 대기 중인 I/O 작업 수
    알람 기준: 10 초과 시 병목 가능성
    
  BurstBalance:
    설명: gp2 볼륨의 burst 크레딧 잔량
    알람 기준: 20% 미만 시 성능 저하 경고

CloudWatch 알람 설정 예시

# IOPS 사용률 높음 알람
aws cloudwatch put-metric-alarm \
  --alarm-name high-iops-usage \
  --metric-name VolumeThroughputPercentage \
  --namespace AWS/EBS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

# gp2 Burst Balance 낮음 알람
aws cloudwatch put-metric-alarm \
  --alarm-name low-burst-balance \
  --metric-name BurstBalance \
  --namespace AWS/EBS \
  --statistic Average \
  --period 300 \
  --threshold 20 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1

💰 비용 최적화 실전 가이드

1. gp2 → gp3 마이그레이션

절감 효과: 약 20%

# 마이그레이션 전 (gp2)
volume_size = 1000  # GB
cost_gp2 = 1000 * 0.10  # $100/month
auto_iops = 1000 * 3    # 3,000 IOPS

# 마이그레이션 후 (gp3)
cost_gp3_storage = 1000 * 0.08  # $80/month
cost_gp3_iops = 0                # 3,000 IOPS는 무료
total_cost_gp3 = 80              # $80/month

# 절감: $20/month (20%)

2. 과다 프로비저닝 방지

많은 팀이 "혹시 몰라서" 10,000~16,000 IOPS를 프로비저닝하지만, 실제 사용량은 2,000 IOPS 미만인 경우가 많습니다.

최적화 절차:

1. CloudWatch에서 지난 2주간 메트릭 확인
2. 95th percentile IOPS 확인
3. 프로비저닝 값이 95th percentile보다 훨씬 높으면 감축
4. 30% 여유분만 유지 (예: 95th percentile이 2,000이면 2,600 IOPS)

3. 인스턴스 타입 매칭

안티패턴:

❌ io2 Block Express (64,000 IOPS) + t3.medium 인스턴스
→ t3.medium은 최대 2,880 IOPS만 지원
→ 비싼 볼륨 비용 낭비

권장:

✅ 워크로드 분석 → 필요 IOPS 산정 → 적절한 인스턴스 선택
✅ EBS-Optimized 인스턴스 사용
✅ 인스턴스 스펙 페이지에서 "Maximum IOPS" 확인

🏗️ 실전 사례: ETL 워크로드 IOPS 설계

시나리오

GCP BigQuery → AWS Redshift 데이터 마이그레이션

임시 프로젝트 (6개월)
이벤트 기반 처리
레코드별 처리 (배치 아님)
VPN 터널링 환경

아키텍처별 IOPS 설정

1. Lambda 함수 (데이터 추출 → S3)

lambda_storage_config = {
    "volume_type": "gp3",
    "size_gb": 100,
    "iops": 3000,        # 기본값, 추가 비용 없음
    "throughput_mbps": 125,  # 기본값
    "rationale": "짧은 실행 시간, 가벼운 I/O, 비용 효율성"
}

# 예상 비용
monthly_cost = 100 * 0.08  # $8/month

2. Glue ETL 작업 (데이터 변환)

glue_storage_config = {
    "volume_type": "gp3",
    "size_gb": 500,
    "iops": 5000,        # 3,000 초과 시 비용 발생
    "throughput_mbps": 250,
    "rationale": "중간 크기 변환 작업, 확장 가능성"
}

# 예상 비용
storage_cost = 500 * 0.08           # $40/month
iops_cost = (5000 - 3000) * 0.005   # $10/month
throughput_cost = (250 - 125) * 0.04 # $5/month
total_cost = 55  # $55/month

3. Redshift (대상 데이터베이스)

Redshift는 자체 managed storage 사용
별도 EBS 볼륨 불필요

모니터링 전략

Phase 1 - 초기 배포:
  - 보수적 IOPS 설정 (3,000~5,000)
  - CloudWatch 상세 모니터링 활성화
  - 1주일간 실제 사용 패턴 수집

Phase 2 - 최적화:
  - 95th percentile 기준 IOPS 조정
  - VolumeQueueLength > 5이면 IOPS 증가
  - VolumeThroughputPercentage < 50%이면 IOPS 감소

Phase 3 - 안정화:
  - 주간 리뷰로 지속 최적화
  - 프로젝트 종료 시 리소스 즉시 삭제

🔐 하이브리드 클라우드 환경 고려사항

VPN 터널링과 IOPS

GCP-AWS 간 VPN 연결 시:

EBS IOPS는 로컬 성능만 보장
네트워크 레이턴시 추가 발생
io2 Block Express의 500 마이크로초 레이턴시 + VPN 레이턴시

권장 사항:

1. 엔드투엔드 성능 테스트 필수
2. 네트워크 병목 vs 스토리지 병목 구분
3. CloudWatch Logs로 전체 파이프라인 레이턴시 추적

보안과 성능

암호화 영향:
  EBS 암호화: IOPS 성능 영향 거의 없음
  AWS KMS: 투명하게 적용
  전송 중 암호화: VPN/TLS 오버헤드 고려

권장 설정:
  - EBS 기본 암호화 활성화
  - KMS Customer Managed Key 사용
  - 암호화로 인한 IOPS 손실 걱정 불필요

📈 성능 벤치마킹 가이드

FIO를 이용한 IOPS 테스트

# 랜덤 읽기 IOPS 테스트
sudo fio --filename=/dev/xvdf \
  --direct=1 \
  --rw=randread \
  --bs=16k \
  --ioengine=libaio \
  --iodepth=256 \
  --runtime=120 \
  --numjobs=4 \
  --time_based \
  --group_reporting \
  --name=iops-test-job

# 랜덤 쓰기 IOPS 테스트
sudo fio --filename=/dev/xvdf \
  --direct=1 \
  --rw=randwrite \
  --bs=16k \
  --ioengine=libaio \
  --iodepth=256 \
  --runtime=120 \
  --numjobs=4 \
  --time_based \
  --group_reporting \
  --name=iops-test-job

결과 해석

예상 결과:
  gp3 (3,000 IOPS): ~2,800-3,000 IOPS
  gp3 (10,000 IOPS): ~9,500-10,000 IOPS
  io2 (50,000 IOPS): ~48,000-50,000 IOPS

성능 미달 시 체크리스트:
  ☐ EBS-Optimized 인스턴스인가?
  ☐ 인스턴스 최대 IOPS 제한은?
  ☐ 다른 볼륨이 대역폭을 소비하는가?
  ☐ gp2의 Burst Balance가 고갈되었는가?

🎯 워크로드별 IOPS 권장사항

데이터베이스

OLTP (트랜잭션 처리):
  추천: io2 Block Express
  IOPS: 10,000 ~ 64,000
  이유: 낮은 레이턴시, 일관된 성능

OLAP (분석):
  추천: gp3
  IOPS: 5,000 ~ 16,000
  이유: 순차 읽기 중심, 비용 효율적

개발/테스트:
  추천: gp3
  IOPS: 3,000 (기본값)
  이유: 프로덕션 대비 저비용

빅데이터 & ETL

Spark/Hadoop:
  추천: st1 (Throughput Optimized HDD)
  이유: 대용량 순차 I/O, MB/s 중심

Lambda 기반 ETL:
  추천: gp3
  IOPS: 3,000 ~ 5,000
  이유: 짧은 실행, 비용 효율

Glue/EMR:
  추천: gp3
  IOPS: 5,000 ~ 10,000
  이유: 중간 크기 변환, 확장 가능

웹/애플리케이션 서버

프로덕션:
  추천: gp3
  IOPS: 3,000 ~ 5,000
  이유: 적절한 성능, 비용 효율

고트래픽:
  추천: gp3
  IOPS: 10,000+
  이유: 동시 요청 처리

부트 볼륨:
  추천: gp3
  IOPS: 3,000 (기본값)
  크기: 30-50 GB

🚨 흔한 실수와 해결책

실수 1: Burst Balance 무시 (gp2)

문제:

gp2 100GB 볼륨
→ 기본 300 IOPS (100GB × 3)
→ Burst로 3,000 IOPS 가능
→ Burst 크레딧 고갈 시 300 IOPS로 급락

해결:

✅ gp3로 마이그레이션
✅ 또는 볼륨 크기를 1,000GB로 증가 (3,000 IOPS 보장)

실수 2: 인스턴스 타입 미스매치

문제:

io2 Block Express 64,000 IOPS + t3.large
→ t3.large는 최대 2,780 IOPS
→ 61,220 IOPS 낭비

해결:

✅ 인스턴스 타입 업그레이드 (예: m6i.4xlarge)
✅ 또는 볼륨 IOPS를 인스턴스 한계에 맞춤

실수 3: 과다 프로비저닝

문제:

"혹시 몰라" 16,000 IOPS 프로비저닝
→ 실제 사용: 평균 800 IOPS
→ 불필요한 비용 발생

해결:

✅ 2주간 모니터링 후 적정 크기 산정
✅ 95th percentile + 30% 여유분
✅ Auto Scaling 고려 (Elastic Volumes)

🔄 Elastic Volumes로 동적 조정

EBS Elastic Volumes 기능으로 중단 없이 IOPS 조정 가능:

# 볼륨 IOPS 증가 (gp3)
aws ec2 modify-volume \
  --volume-id vol-12345678 \
  --iops 10000

# 볼륨 타입 변경 (gp2 → gp3)
aws ec2 modify-volume \
  --volume-id vol-12345678 \
  --volume-type gp3 \
  --iops 5000

# 변경 상태 확인
aws ec2 describe-volumes-modifications \
  --volume-id vol-12345678

주의사항:

6시간에 한 번만 수정 가능
일부 변경은 파일시스템 확장 필요
프로덕션 환경은 점진적 변경 권장

📚 핵심 정리

IOPS 선택 체크리스트

☐ 워크로드 유형 파악 (OLTP vs OLAP vs ETL)
☐ 필요 IOPS 산정 (CloudWatch 기반)
☐ 볼륨 타입 선택 (gp3 vs io2)
☐ 인스턴스 타입 호환성 확인
☐ 비용 대비 성능 평가
☐ 모니터링 및 알람 설정
☐ 정기적 리뷰 및 최적화

볼륨 타입 선택 플로우차트

시작
 ├─ 임시/개발 환경? → gp3 (3,000 IOPS)
 ├─ 범용 웹/앱? → gp3 (3,000-10,000 IOPS)
 ├─ 데이터베이스?
 │   ├─ OLTP? → io2 Block Express (10,000-64,000 IOPS)
 │   └─ OLAP? → gp3 (5,000-16,000 IOPS)
 ├─ 빅데이터 순차 I/O? → st1 (HDD)
 └─ Mission-critical? → io2 Block Express (최고 성능)

🎓 결론

EBS IOPS는 단순한 숫자가 아니라, 애플리케이션 성능과 비용을 직접 좌우하는 핵심 요소입니다.

성공적인 IOPS 관리의 3대 원칙:

측정 우선: 추측이 아닌 데이터 기반 결정
점진적 최적화: 작게 시작해서 필요에 따라 확장
지속적 모니터링: 워크로드 변화에 맞춰 조정

특히 하이브리드 클라우드 환경이나 ETL 워크로드에서는 초기 보수적 설정으로 시작해, 실제 사용 패턴을 수집한 후 최적화하는 것이 가장 안전하고 비용 효율적입니다.

AWS는 Elastic Volumes 기능을 통해 중단 없는 IOPS 조정을 지원하므로, 과도한 오버 프로비저닝보다는 적정 수준에서 시작해 필요시 확장하는 전략을 추천합니다.

📎 참고 자료

이 글이 도움이 되셨다면 공유해주세요! 궁금한 점은 댓글로 남겨주시면 답변드리겠습니다. 💬

저작자표시 비영리 동일조건 (새창열림)

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2026/01 »
일	월	화	수	목	금	토
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

글 보관함

티스토리 뷰

AWS Solution Architect 준비: EBS - IOPS

AWS EBS IOPS

🎯 들어가며

📖 IOPS란 무엇인가?

핵심 특징

🗂️ EBS 볼륨 타입별 IOPS 성능 비교

SSD 기반 볼륨 (Transactional Workload)

1. gp3 (General Purpose SSD) - 권장 옵션

2. gp2 (General Purpose SSD) - 레거시

3. io2 Block Express - 최고 성능

4. io1 - 고성능

HDD 기반 볼륨 (Throughput 중심)

⚡ 실제 IOPS 성능 결정 요소

1. 볼륨 설정

2. EC2 인스턴스 제한

3. 네트워크 대역폭

📊 IOPS 모니터링 및 최적화 전략

CloudWatch 핵심 메트릭

CloudWatch 알람 설정 예시

💰 비용 최적화 실전 가이드

1. gp2 → gp3 마이그레이션

2. 과다 프로비저닝 방지

3. 인스턴스 타입 매칭

🏗️ 실전 사례: ETL 워크로드 IOPS 설계

시나리오

아키텍처별 IOPS 설정

1. Lambda 함수 (데이터 추출 → S3)

2. Glue ETL 작업 (데이터 변환)

3. Redshift (대상 데이터베이스)

모니터링 전략

🔐 하이브리드 클라우드 환경 고려사항

VPN 터널링과 IOPS

보안과 성능

📈 성능 벤치마킹 가이드

FIO를 이용한 IOPS 테스트

결과 해석

🎯 워크로드별 IOPS 권장사항

데이터베이스

빅데이터 & ETL

웹/애플리케이션 서버

🚨 흔한 실수와 해결책

실수 1: Burst Balance 무시 (gp2)

실수 2: 인스턴스 타입 미스매치

실수 3: 과다 프로비저닝

🔄 Elastic Volumes로 동적 조정

📚 핵심 정리

IOPS 선택 체크리스트

볼륨 타입 선택 플로우차트

🎓 결론

📎 참고 자료

티스토리툴바