클라우드 블록 스토리지: EBS, Persistent Disk, Azure Disk 운영

클라우드 블록 스토리지를 데이터베이스에 쓸 때 알아야 할 것

온프레미스와 클라우드 블록 스토리지의 가장 큰 차이는 스토리지가 네트워크로 연결된다는 점이다. EBS, GCP Persistent Disk, Azure Managed Disk는 모두 인스턴스와 물리적으로 분리된 스토리지 서버에 존재한다. 이 네트워크 경로가 레이턴시와 처리량의 상한을 결정한다.

그 대신 클라우드 블록 스토리지는 몇 가지 실질적인 장점을 제공한다.

• 인스턴스 교체 없이 스냅샷·볼륨 확장
• 복수의 가용 영역에 걸친 데이터 내구성
• IOPS와 처리량을 용량과 독립적으로 조정 가능 (최신 세대)
• 인스턴스 장애 시 볼륨을 다른 인스턴스에 재연결

데이터베이스 운영자에게는 이 장점과 네트워크 경유의 레이턴시 페널티 사이에서 적절한 볼륨 타입을 골라야 하는 판단이 요구된다.

AWS EBS

볼륨 타입 개요

gp3 vs gp2: 왜 gp3가 유리한가

gp2는 IOPS가 볼륨 크기에 종속된다(3 IOPS/GB, 최대 16,000). 1,000 IOPS가 필요한 데이터베이스에 333GB 볼륨이 강제로 할당되는 상황이 생긴다. gp3는 IOPS와 처리량을 볼륨 크기와 독립적으로 설정한다. 2025년 9월 업그레이드로 gp3는 최대 80,000 IOPS, 2,000 MB/s, 64 TiB까지 확장되었다.

예시: 500GB 데이터베이스, 8,000 IOPS 필요

gp2: 8,000 IOPS를 위해 2,667GB 볼륨 필요 → 공간 낭비 + 비용 증가
gp3: 500GB + 8,000 IOPS 직접 설정 → 필요한 만큼만 비용 지불

2026년 서울 리전 기준:
  gp3 기본 사양 (500GB): ~$0.08/GB/월 = $40/월
  추가 IOPS (5,000 IOPS): ~$0.005/IOPS/월 = $25/월
  합계: ~$65/월

gp2 동일 IOPS (2,667GB): ~$0.10/GB/월 = ~$267/월
→ gp3가 약 76% 절감

EBS 버스트 크레딧 (gp2 주의사항)

gp2 볼륨은 크기가 1TB 미만이면 버스트 크레딧으로 최대 3,000 IOPS까지 일시적으로 높이는 메커니즘을 사용한다. 개발 환경에서는 문제가 없지만, 지속적인 IOPS가 필요한 프로덕션 데이터베이스에서 버스트 크레딧이 소진되면 성능이 기준 IOPS(용량 × 3)로 급격히 떨어진다.

# CloudWatch로 버스트 크레딧 잔량 모니터링
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-xxxxxxxx \
  --start-time 2026-07-07T00:00:00Z \
  --end-time 2026-07-07T23:00:00Z \
  --period 3600 --statistics Average

gp3로 마이그레이션하면 버스트 크레딧 개념이 사라진다. gp3는 항상 프로비저닝된 IOPS를 제공한다.

io2 Block Express: 언제 사용하는가

io2 Block Express는 AWS 자체 개발 프로토콜(SRD)을 통해 훨씬 낮은 레이턴시를 달성한다.

• 최대 256,000 IOPS, 4,000 MB/s (C7gn·R7g·X2idn 등 지원 인스턴스 필요)
• 99.999% 내구성 (gp3/io1의 99.8~99.9% 대비)
• Multi-Attach: 최대 16개 Nitro 인스턴스가 동일 볼륨 공유 (Oracle RAC 등 클러스터링)
• EBS-optimized 인스턴스 필수: 전용 네트워크 대역폭이 없으면 io2 성능이 보장되지 않음

Oracle RAC, 고성능 SAP HANA, 수십만 IOPS가 필요한 금융 OLTP 시스템 정도가 io2의 실질 사용처다.

EBS 스냅샷과 운영

EBS 스냅샷은 증분 방식이다. 첫 스냅샷 이후 변경된 블록만 S3에 저장된다. 단, 스냅샷이 누적되면 각각 독립적으로 복원 가능한 완전한 시점이 되도록 내부적으로 관리된다.

# 스냅샷 생성 (인스턴스 실행 중에도 가능, 단 DB는 버퍼 플러시 권장)
aws ec2 create-snapshot \
  --volume-id vol-xxxxxxxx \
  --description "mysql-primary-2026-07-07" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=mysql-daily}]'

# 교차 리전 복사
aws ec2 copy-snapshot \
  --source-region ap-northeast-2 \
  --source-snapshot-id snap-xxxxxxxx \
  --destination-region us-east-1 \
  --description "DR copy"

GCP Persistent Disk와 Hyperdisk

제품 계층 구조

Google Cloud는 두 세대의 블록 스토리지를 제공한다.

Persistent Disk (1세대)

Hyperdisk (2세대, GCE 전용)

Hyperdisk는 IOPS·처리량·용량을 완전 독립적으로 프로비저닝한다.

데이터베이스 권장 타입

• OLTP (MySQL, PostgreSQL): pd-ssd 또는 Hyperdisk Balanced. pd-extreme은 고성능 워크로드에 적합하지만 비용이 높다.
• 대규모 OLAP (ClickHouse, BigQuery 연계): Hyperdisk Balanced 또는 Hyperdisk Throughput
• Kafka: Hyperdisk Throughput 또는 pd-standard (순차 쓰기 최적)
• 백업 볼륨: pd-standard (HDD)

디스크 크기와 성능 관계

pd-ssd는 IOPS가 용량에 비례한다(1 GB = 최대 30 IOPS 읽기, 30 IOPS 쓰기). Hyperdisk는 이 제약이 없다. pd-ssd로 높은 IOPS가 필요하면 실제 데이터보다 큰 볼륨이 강제된다 — Hyperdisk로 전환하면 필요한 IOPS만 프로비저닝할 수 있다.

Azure Managed Disk

제품 계층 구조

Azure는 워크로드 등급에 따라 다섯 가지 Managed Disk 타입을 제공한다.

Ultra Disk: 재연결 없이 성능 변경

Ultra Disk의 가장 큰 특징은 볼륨을 분리하거나 VM을 재시작하지 않고 IOPS와 처리량을 실시간으로 변경할 수 있다는 점이다.

# Ultra Disk IOPS를 실시간으로 변경 (Azure CLI)
az disk update \
  --resource-group myRG \
  --name myUltraDisk \
  --disk-iops-read-write 50000 \
  --disk-mbps-read-write 1000

이 기능은 배치 처리 시간에 IOPS를 높이고, 유휴 시간에 낮추는 비용 최적화 전략을 가능하게 한다.

Ultra Disk 제약: 가용성 영역이 있는 리전에서만 지원. ZRS(Zone-Redundant Storage) 기능 없음 — 단일 존 내에서만 내구성 보장. VM이 Azure 가용성 영역에 배치되어야 사용 가능.

Premium SSD v2

Ultra Disk보다 낮은 비용으로 Premium SSD 대비 훨씬 높은 IOPS를 제공한다.

• 최대 80,000 IOPS, 최대 2,000 MB/s
• 용량·IOPS·처리량 독립 프로비저닝
• Sub-millisecond 레이턴시 (p99 기준)
• LRS(로컬 중복)만 지원 — ZRS 미지원 (2025년 7월 기준 확인)

일반적인 OLTP MySQL/PostgreSQL에 Ultra Disk까지는 필요 없는 경우 Premium SSD v2가 비용 효율적인 선택이다.

Shared Disk (클러스터링)

Premium SSD와 Ultra Disk는 Shared Disk 기능을 통해 최대 10개 VM이 동일 디스크를 공유할 수 있다. WSFC(Windows Server Failover Cluster), Pacemaker 기반 Linux HA 구성에 사용된다. 단, 동시 쓰기 조율은 클러스터 소프트웨어의 책임이다.

클라우드별 성능 비교 요약

클라우드 블록 스토리지 운영 패턴

I/O 스케줄러 설정

클라우드 블록 스토리지는 네트워크 경유이므로 OS의 I/O 스케줄러 개입이 이점을 주지 않는다. 스케줄러를 none으로 설정해 불필요한 큐잉 지연을 제거한다.

# 영구 설정 (/etc/udev/rules.d/60-io-scheduler.rules)
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="xvd*|sd*", ATTR{queue/scheduler}="none"

# 현재 설정 확인
cat /sys/block/nvme1n1/queue/scheduler

큐 깊이(Queue Depth) 튜닝

EBS io2나 GCP pd-extreme 같은 고성능 볼륨은 충분한 큐 깊이가 있어야 최고 IOPS를 달성할 수 있다.

# 큐 깊이 확인
cat /sys/block/nvme1n1/queue/nr_requests

# MySQL InnoDB: innodb_io_capacity, innodb_io_capacity_max 조정
# PostgreSQL: effective_io_concurrency 조정 (SSD: 200, HDD: 2)

IOPS 소비 모니터링

AWS CloudWatch:

# 볼륨 IOPS 소비량 확인
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS \
  --metric-name VolumeReadOps \
  --dimensions Name=VolumeId,Value=vol-xxxxxxxx \
  --start-time 2026-07-07T00:00:00Z \
  --end-time 2026-07-07T01:00:00Z \
  --period 60 --statistics Sum

GCP 모니터링: Cloud Monitoring의 compute.googleapis.com/instance/disk/read_ops_count 및 write_ops_count 메트릭을 대시보드에 추가.

Azure Monitor: Disk Read Operations/Sec 및 Disk Write Operations/Sec 메트릭을 통해 프로비저닝 IOPS 대비 실제 소비량을 추적.

스냅샷 라이프사이클 관리

# AWS: Data Lifecycle Manager로 스냅샷 자동화
aws dlm create-lifecycle-policy \
  --description "daily-db-snapshot" \
  --state ENABLED \
  --execution-role-arn arn:aws:iam::123456789:role/AWSDataLifecycleManagerDefaultRole \
  --policy-details '{"PolicyType":"EBS_SNAPSHOT_MANAGEMENT","ResourceTypes":["VOLUME"],"TargetTags":[{"Key":"Backup","Value":"daily"}],"Schedules":[{"Name":"DailySnapshot","CreateRule":{"Interval":24,"IntervalUnit":"HOURS","Times":["02:00"]},"RetainRule":{"Count":7}}]}'

비용 고려사항: 스냅샷은 증분이지만 오래된 스냅샷 체인이 쌓이면 총 스토리지 비용이 증가한다. 보존 정책(7일, 30일, 분기 등)을 명시적으로 설정하고 자동 삭제한다.

온프레미스 NVMe와의 레이턴시 비교

클라우드 블록 스토리지는 네트워크 경유라는 근본적인 제약이 있다.

레이턴시가 1ms를 초과하면 트랜잭션 수가 많은 OLTP에서 병목이 될 수 있다. 수십만 TPS가 필요하다면 로컬 NVMe(인스턴스 스토어 또는 베어메탈) + 별도 복제 전략을 검토한다.

운영 체크리스트

□ 볼륨 타입 선택
    신규: gp3(AWS) / Hyperdisk Balanced(GCP) / Premium SSD v2(Azure) 기준으로 시작
    gp2 사용 중이면 gp3 마이그레이션 검토 (비용 절감 + 버스트 제거)

□ I/O 스케줄러 none 설정 확인
    cat /sys/block/nvme*/queue/scheduler

□ 프로비저닝 IOPS vs 실제 소비량 대시보드 구성
    CloudWatch / Cloud Monitoring / Azure Monitor

□ 버스트 크레딧 잔량 모니터링 (gp2 사용 중인 경우)
    BurstBalance < 20% 알림 설정

□ 스냅샷 보존 정책 자동화
    DLM(AWS) / Cloud Scheduler+gcloud(GCP) / Backup Policy(Azure)

□ EBS-optimized 또는 동급 네트워크 대역폭 확인
    인스턴스의 EBS 최대 대역폭 > 볼륨 프로비저닝 처리량

□ 장애 대응 계획
    볼륨 교체 절차 문서화 (detach → attach → mount → DB 재시작)
    스냅샷 복원 시간 측정 (RTO 검증)

Open Questions

• Azure Ultra Disk의 p99 레이턴시는 VM 타입과 리전에 따라 차이가 크다. 실제 워크로드 기준의 공식 SLA 수치가 명시되지 않아 사전 벤치마크가 필요하다.
• GCP Hyperdisk Extreme의 350,000 IOPS는 특정 인스턴스 패밀리(C3 이상)에서만 달성 가능하며, 모든 리전에서 지원되지 않는다. 사용 전 리전별 가용성을 확인해야 한다.

References

• Amazon EBS Volume Types — AWS Documentation
• Amazon EBS io2 Block Express — AWS Documentation
• Google Cloud Persistent Disk Overview
• Google Cloud Hyperdisk Overview
• Azure Managed Disk Types — Microsoft Learn
• Azure Ultra Disk — Microsoft Learn
• Azure Premium SSD v2 — Microsoft Learn
• EBS Performance Best Practices — AWS
• Configuring Disk Performance — GCP Documentation