AWS EBS(Elastic Block Storage) 비용 최적화
[원본글] https://ericygkim.wordpress.com/2019/07/11/aws-ebselastic-block-storage-의-비용-최적화/
애플리케이션 개발 후 AWS에 애플리케이션을 설치할 때 성능, 가용성, 확장성, 비용, 서비스 특성등 많은 요구사항들을 고려하여 복잡한 고민을 거쳐 EC2 인스턴스 사이즈등 AWS 자원들을 선택하게 됩니다. 그 중 중요한 요소 중 하나가 EC2인스턴스나 RDS에 연결되는 스토리지인 EBS(Elastic Block Storage)를 선택하는 일인데, 성능 및 비용까지 고려해서 선택하는 과정은 많은 고민을 할 수 밖에 없습니다. EBS 볼륨의 크기를 정하는 것도 중요하지만 그것보다 더 중요한 것은 EBS 볼륨의 종류를 선택하고 성능과 비용 최적화 하는 것입니다. 얼마나 빠른 EBS 볼륨을 선택하는냐에 따라 애플리케이션, 데이터베이스의 성능에 큰 영향을 미치게 됩니다. 또한 EBS 볼륨의 유형에 따라 비용이 크게 달라집니다. 그러므로 요구되는 성능과 비용을 고려하여 적절한 스토리지 유형과 크기를 현명하게 선택하여야 합니다. 이와 관련된 기본 지식과 약간의 노하우를 공유할까 합니다.
IOPS(Input/Output Operation Per Second)란?
Amazon 클라우드 저장장치의 성능을 나타내는 가장 중요한 지표가 초당 입출력 속도인 IOPS 입니다. 특히, RDS (Relational Database Service) 인스턴스 설정시 최대 IOPS가 정해진 스토리지를 선택하게 되는데 일단 선택이 되면 할당된 최대 IOPS를 넘을 수 없으므로 신중하게 선택해야 합니다. IOPS는 RDS를 중심으로 먼저 설명해보겠습니다. RDS에서 한번에 전송할 수 있는 데이터 크기는 RDS 데이터베이스 엔진의 페이지 사이즈가 다릅니다. 얼마나 많은 IOPS가 필요한지 이해하기 위해서는 먼저 얼마나 높은 처리량(Throughput)이 필요한지 먼저 이해해야 합니다. MySQL과 MariaDB는 16KB 크기의 페이지를 사용합니다. 그래서 입출력 한번 당 16KB 단위로 전송합니다. 반면 Oracle, PostgreSQL, Microsoft SQL은 8KB 크기의 페이지를 사용합니다. 그래서 16KB데이터를 전송하기 위해서는 두번의 입출력 동작이 필요합니다. 즉, 페이지 사이즈가 클수록 한번의 입출력 동작으로 더 많은 데이터를 전송할 수 있습니다.
예를 들면, 매초 102,400KB (100MB)의 읽기 동작이 필요한 애플리케이션인 경우 16KB 페이지 크기의 데이터 베이스를 사용할 경우 초당 6,400 번의 읽기 동작을 해야 합니다. 즉 6,400 IOPS 이상의 성능을 가진 EBS볼륨이 필요합니다.
EBS 스토리지 유형
AWS는 다음과 같은 EBS 스토리지 유형들을 제공합니다.
범용(General Purpose) SSD (gp2)
대부분의 애플리케이션에서는 gp2로 어느 정도 충분한 성능을 낼 수 있습니다. gp2는 지연시간(latency)이 한자리 밀리초(1 ~ 9 ms)가 가능한 매우 빠른 스토리지입니다. 볼륨크기는 16TB까지 가능하고 기가바이트 당 3배의 IOPS (3 IOPS/GB)를 할당할 받을 수 있으며 볼륨당 16,000 IOPS까지 가능합니다. 예를 들면, 100GB 크기의 볼륨을 설정하면 최대 300 IOPS를 할당 받습니다. 즉 볼륨크기가 클수록 더욱 빠른 IOPS를 할당 받을 수 있다는 의미입니다.
gp2의 최대 대역폭은 2,000 Mbps (250 MBps) 입니다. 이 속도를 내기 위해서는 몇가지 조건을 고려해야 합니다. 첫번째로 EC2 인스턴스 타입이 최대 처리량을 감당할 수 있을 정도의 충분한 크기이어야 합니다. 두번째로는 충분한 IOPS를 할당 받아야 합니다. 예를 들면, 페이지크기가 16KB (128Kb = 0.128 Mb)인 MariaDB를 사용할 경우 최대 대역폭을 페이지 사이즈로 나누면 15,625 IOPS가 필요합니다.
2,000 Mbps / 0.128 Mb = 15,625 IOPS
그러므로 최대 성능을 내려면 15,625 IOPS / 3 = 5,208.33 GB (약 5.2TB) 볼륨을 할당해야 합니다.
만일 스토리지는 많이 필요하지 않으나 (1TB이하인 경우) 높은 IOPS가 가끔씩만 필요하다면 굳이 필요한 IOPS만큼 볼륨을 할당할 필요는 없습니다. gp2의 IOPS는 버스트 버킷이라는 모델을 지원하고 있습니다. Amazon에서는 크레딧 발란스를 이용하여 최대 3000 IOPS 수준의 버스트 버킷을 사용할 수 있다. 버스트 전송할 수 있는 시간을 계산하면 다음과 같다.
Burst duration in seconds = (Credit balance)/ [3,000 - 3 * (storage size in GB)]
데이터베이스 인스턴스를 초기화하면 5,400,000 IOPS 크레딧 밸런스가 주어진다. 언제든 기본으로 주어진 IOPS이상을 사용할 수 있다. 예를 들면, 200GB 볼륨 크기를 설정하면
5,400,000 / [ 3,0000 - 3 * 200] = 2250초
2,250초 (37.5분) 동안 버스트를 사용할 수 있습니다.
볼륨에 기준 성능 I/O 수준 이상이 필요한 경우 크레딧 밸런스에서 I/O 크레딧을 사용하여 최대 3,000 IOPS까지 필요한 성능 수준을 버스트할 수 있습니다. 아래 차트에서 1,000GiB 이상의 볼륨은 이미 기준 IOPS가 최대 버스트 성능 이상의 성능을 가지게 되므로 I/O 크레딧 밸런스는 차감되지 않습니다.
크레딧은 매초 베이스라인의 기준 성능에 비례하여 추가가 되며, 주어진 크레딧을 다쓰게 되면 볼륨의 베이스라인으로 할당된 IOPS ( 3 IOPS/GB)이상 주어지지 않습니다. 예를 들어, 200GB볼륨이면 베이스라인으로 600 IOPS가 주어지며 매초 600 IOPS씩 크레딧이 최대 5,400,000까지 쌓입니다.
프로비전된(Provisioned) IOPS SSD(io1)
gp2 스토리지는 성능을 계산하기 위해서는 버스트 벗킷이라는 매우 복잡한 구조를 가지고 있습니다. 버스트 버킷와 같은 머리 아픈 계산법 없이 단순하게 접근하려면 프로비젼된 IOPS SSD (io1)을 선택하면 매우 단순해집니다. 이 형태의 볼륨은 가장 비싼 형대로 지불한 만큼 미리 정해진 IOPS를 확보할 수있는 스토리지가 io1입니다. 이 스토리지는 지속적으로 낮은 응답 지연시간(Low latency)가 필요한 OLTP형 데이터베이스에 유용하게 사용할 수 있다. 스토리지 볼륨 크기와 프로비전된 IOPS양으로 비용이 청구되므로 사용할 때 비용 고민을 심각하게 해야 한다.
4,000 Mbps를 지원하는 표준 인스턴스를 사용하고 16KB 페이지 사이즈를 데이터베이스 엔진을 사용한다고 가정하면, (4,000 / 0.128 = 31,250) 최대 31,250 IOPS가 있어야 하므로 인스턴스를 생성할때 1,000정도를 더해서 32,000 IOPS로 프로비전을 해야 한다. IOPS와 스토리지 용량은 약 50:1 비율로 정하도록 규정하고 있습니다. 예를 들면 32,000 IOPS를 원한다면 640GB 정도를 프로비전해야 합니다.
100 IOPS부터 nitro 인스턴스 패밀리에서는 볼륨당 최대 64,000 IOPS, 그리고 다른 인스턴스 패밀리에서는 최대 32,000 IOPS까지 프로비저닝할 수 있습니다. 최대 32,000 IOPS로 프로비저닝된 io1 볼륨은 최대 256KiB의 I/O 크기를 지원하고 최대 500MiB/s의 처리량을 제공합니다. I/O 크기가 최대일 때 2,000 IOPS에서 피크 처리량에 도달합니다.
처리량 최적화된(Throughput Optimized) HDD (st1)
IOPS가 아닌 처리량(Throughput)으로 성능을 정의하는 저비용 HDD 스토리지로 AWS EMR, 빅데이터, Analytics 같은 애플리케이션에 적합합니다.
gp2는 IOPS 버스트 버킷 모델로 제공하는 반면 st1은 처리량에 대한 버스트 버킷 모델로 제공을 하고 있습니다. gp2와 비슷하게 볼륨 크기가 클수록 더 많은 기준 처리량(baseline throughput)과 버스트 처리량이 비례하여 결정됩니다.
AWS에서 기준 처리량(baseline throughput)은 TiB당 40 MiB/s로 크레딧이 채워지며 크래딧은 최대 500 MiB/s까지 주어집니다.
Baseline throughput = Volume size per TiB * 40 MiB/s
최대 버스트 처리량(Burst throughput)은 TiB당 250 MiB가 주어지면 최대 500 MiB/s까지 주어진다. 그러므로 2 TiB 이상의 볼륨은 최대 500 MiB/s 이상 넘을 수 없게된다.
12.5 TiB이상의 볼륨 크기에서는 기본 처리량이 최대 500 MiB/s되므로 버스트 처리량이 의미가 없어진다.
이를 그래프로 그려보자면 다음과 같다.
Cold HDD (sc1)
자주 액세스하지 않는 애플리케이션에 적합하고 처리량으로 성능을 정의하는 저비용 HDD 스토리지를 제공합니다. sc1은 대용량 데이터를 랜덤이 아닌 순차적으로 액세스하는 애플리케이션에 매우 적합니다.
sc1은 st1과 같이 처리량으로 버스트 버킷 모델로 제공을 하고 있습니다. gp2와 비슷하게 볼륨 크기가 클수록 더 많은 기준 처리량(baseline throughput)과 버스트 처리량이 비례하여 결정됩니다.
AWS에서 기준 처리량(baseline throughput)은 TiB당 12 MiB/s로 크레딧이 채워지며 크래딧은 최대 250 MiB/s까지 주어집니다.
Baseline throughput = Volume size per TiB * 12 MiB/s
최대 버스트 처리량(Burst throughput)은 TiB당 80 MiB가 주어지면 최대 500 MiB/s까지 주어진다. 그러므로 2 TiB 이상의 볼륨은 최대 250 MiB/s 이상 넘을 수 없게된다.
EBS의 선택 방법
EBS 볼륨 종류 요약
EBS 선택 방법을 소개하기 전에 우선 EBS 볼륨 별로 요약을 해보겠습니다.
| 볼륨유형 | 범용SSD(gp2) | 프로비젼된IOPS SSD(io1) | 처리량 최적화된 HDD(sc1) | Cold HDD(st1) |
| 설명 | 다양한 워크로드에 사용할 수 있으며 가격 대비 성능이 우수한 범용 SSD 볼륨 | 지연 시간이 짧거나 처리량이 많은 미션 크리티컬 워크로드에 적합한 고성능 SSD 볼륨 | 자주 액세스하는 처리량 집약적 워크로드에 적합한 저비용 HDD 볼륨 | 자주 액세스하지 않는 워크로드에 적합한 최저 비용 HDD 볼륨 |
| 사용예 | * 대부분의 워크로드에 추천
* 시스템 부트 볼륨 * 가상 데스크톱 * 지연 시간이 짧은 대화형 앱 * 개발 및 테스트 환경 |
* 지속적인 IOPS 성능이나 16,000 IOPS 또는 250MiB/s 이상의 볼륨당 처리량을 필요로 하는 중요한 비즈니스 애플리케이션
*대용량 데이터베이스 * MongoDB * Cassandra * Microsoft SQL Server * MySQL * PostgreSQL * Oracle |
* 저비용으로 일관되고 높은 처리량을 요구하는 스트리밍 워크로드
* 빅 데이터 데이터 웨어하우스 * 로그 처리 * 부트 볼륨이 될 수 없음 |
* 자주 액세스하지 않는 대용량 데이터를 위한 처리량 중심의 스토리지
* 스토리지 비용이 최대한 낮아야 하는 시나리오 * 부트 볼륨이 될 수 없음 |
| 볼륨크기 | 1GiB - 16TiB | 4GiB - 16TiB | 500GiB - 16TiB | 500GiB - 16TiB |
| 최대 IOPS/볼륨 | 16,000 | 64,000 | 500 | 250 |
| 최대처리량/볼륨 | 250 MiB/s | 1,000 MiB/s | 500 MiB/s | 250 MiB/s |
EBS 선택시 우선 개발한 애플리케이션이 IOPS 가 중요한지 처리량(Throughput)이 중요한지 먼저 고려를 해야 한다.
IOPS가 80,000 이상 요구 경우는 SSD 인스턴스 스토어 볼륨인 NVMe를 사용해야 하며 이를 지원하는 인스턴스인 i3, c5d, m5d, r5d등을 사용해야 한다. 80,000 IOPS 이하인데 1 ms이하의 지연시간(latency)을 요구하는 경우에도 SSD인스턴스 스토어 볼륨을 사용해야 합니다. 지연시간이 수 ms 정도 빠른 응답속도를 원하는 경우에도 gp2나 io2를 사용하여 합니다. 지속적으로 고속의 IOPS를 요구하는 애플리케이션이 아닌 경우는 가격이 낮은 gp2사용하기를 권합니다.
만일 처리량이 중요한 경우 큰 데이터를 순차적으로 액세스하는 애플리케이션인 경우 HDD기반의 볼륨을 권합니다. 1,750 MiB/s이상인 경우 HDD 인스턴스 스토어 볼륨을 지원하는 h1, d2 인스턴스 사용을 권하고 그 외에는 sc1, st1을 가격과 성능을 비교하여 선택하십시요.
EBS 종류별 가격 비교
기본적으로 애플리케이션의 IOPS성능에 따라 EBS 볼륨의 종류만 잘 선택해도 상당한 비용 절감을 할 수 있습니다. AWS의 프로비전된 볼륨인 gp2, io1은 빠르고 성능도 좋지만 상대적으로 비쌉니다. 그러나, 데이터 베이스 혹은 부트 디스크를 제외하고 대부분의 애플리케이션에서는 HDD인 sc1이나 st1으로도 충분히 성능을 만족시키는 경우가 많이 있습니다. 아래 도표를 보면 EBS 종류별로 서울 리전의 GB당 가격차이를 한눈에 비교할 수 있습니다.
비용 최적화에 사용하는 유용한 툴
CloudWatch
CloudWatch는 EBS동작에 관한 많은 수치들을 제공합니다. 비용 최적화에 있어서 다음과 같은 세가지 지표가 있습니다.
- VolumeReadOps: 주어진 시간당 총 읽기 동작 횟수
- VolumeWriteOps: 주어진 시간당 총 쓰기 동작 횟수
- VolumeThroughputPercentage (Provisioned IOPS SSD only): 프로비젼된 IOPS대비 IOPS 전달 횟수의 퍼센트
CloudWatch는 직접적으로 IOPS를 표시하지 않아서 표시된 수치들로 IOPS 계산을 해야 합니다. CloudWatch는 5분마다 데이터를 수집하므로 읽은 동작 횟수와 쓰기 동작횟수를 더한 후 300초(5분)으로 나누어야 IOPS를 계산 할 수 있습니다. 그래서 IOPS를 구하는 식은 다음과 같습니다.
IOPS = (VolumeReadOps + VolumeWriteOps) / 300
CloudWatch에 IOPS 값과 처리량 수치로 EBS 볼륨이 덜 사용되는지 초과 사용되는지 판단할 수 있습니다. 그리고 볼륨의 크기가 가격대비 성능의 적절한 균형을 가지고 있는지 볼륨 크기 조정이 필요한지 판단할 수 있는 기준이 되기도 합니다. 또한 작은 여러개의 볼륨을 합치거나 볼륨 형태를 바꾸거나 하는 판단의 기준이 됩니다.
특히, 프로비젼된 IOPS SSD인 io1은 고가이므로 항상 IOPS 소모 비용에 대하여 관심을 가지고 보면서 비용 절감 방법에 대하여 항시 검토해야 합니다.
디스크 사용량(Disk Utilization)
디스크 사용량은 AWS CloudWatch에서 지원하지 않는 수치 중 하나입니다. 프로비젼한 불륨을 얼마나 사용하는지 알기 위해서는 Newrelic이나 Datadog같은 툴을 사용하는 방법이 있습니다.
AWS 디스크 사용량 모니터링을 위해 수동으로 설치하여 동작시키는 스크립트를 제공합니다. 아래 웹사이트를 참조하세요.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html
다시 한번 강조하지만 프로비젼된 IOPS SSD인 io1은 고가이므로 볼륨 사용량도 수시로 점검을 하고 최적화를 해야 합니다.
아래 공개 소프트웨어는 AWS에서 제공하는 모니터링 툴로 참고 하시면 좋습니다.
https://github.com/aws-samples/aws-elastic-volumes
가격 최적화 방법
사용하지 않는 볼륨과 스냅샷
가장 빠르고 쉽게 할 수 있는 비용 절감 방법이 사용하지 않은 볼륨과 볼륨의 스냅샷을 찾아내는 것입니다. 주기적인 스냅샷이 필요할 경우 스크립트나 Lambda서비스를 이용하여 주기적으로 스냅샷을 지우면 많은 비용 절감을 할 수 있습니다. 볼륨을 사용하지 않는 경우는 다음과 같이 두가지 경우가 있습니다.
- EC2 인스턴스와 연결되어 있지 않은 경우 - 개발자들이 가장 실수를 많은 하는 부분으로 EC2 인스턴스를 제거하게 되면 디스크 볼륨도 지워질 것으로 생각하는 사람이 많습니다. EC2 인스턴스를 제거한 후에 반드시 연결되어 있던 디스크 볼륨도 지우세요. 그리고, 수시로 볼륨리스트를 보고 연결되지 않은 볼륨은 지우시기를 바랍니다.
- 사용하지 않는 경우 -볼륨 중에 한동안 IOPS 값과 사용량(Throughput)이 0인 볼륨을 찾아 보세요. 이런 한 볼륨은 지우거나 크기를 최소화 하세요.
볼륨의 유형 바꾸기
AWS 클라우드를 운영하다 보면 대부분의 애플리케이션이 sc1이나 st1으로 충분한 성능이 나옵니다. 그러나, 애플리케이션을 론치하는 초기에는 예상되는 요구성능에 대한 불확실성때문에 gp2로 시작하는 경우가 많습니다. 1~2개월 운영하다 보면 어느 정도 성능이 요구되는지 알게되므로 볼륨 유형을 낮출 수 있는지 판단됩니다. 이때 판단 기준이 필요합니다. 경험으로 비추어 보면, 평균 IOPS가 85를 넘지 않고 순간 최고 IOPS가 200을 넘지 않는 경우에 sc1이나 st1으로 볼륨 유형을 변경해보십시요. 해당 볼륨 비용이 반이하로 절감됩니다.
볼륨의 크기 조절
2017년 초에 Amazon에서는 탄력적 볼륨이라는 기능을 발표했습니다. 이전에는 볼륨의 크기를 조절하려면 EC2 인스턴스에서 동작하는 애플리케이션을 정지 시킨 후 볼륨 조정 후에 재시작을 했으나, 신세대 EC2 인스턴스에서는 애플리케이션 정지 없이 볼륨의 크기를 조절할 수 있습니다. 볼륨의 사용량과 볼륨 크기에 따라 결정되는 기본 IOPS를 수치를 확인하여 유동적으로 조절하십시요. 이를 통해 많은 비용을 절감할 수 있습니다.
io1의 집중관리
io1은 가장 비싼 볼륨으로 볼륨의 크기 뿐만 아니라 I/O연산량에 비례하여 비용을 지불해야 합니다. 상시 수 ms의 응답시간이 필요한지, 프로비젼된 볼륨을 대부분 사용하지는 수시로 확인하고 평균 IOPS와 순간 IOPS를 수시로 점검하여 gp2의 버스트 버킷으로 전환이 가능한지 항상 체크하시기를 바랍니다.
또한 볼륨 사용량을 수시로 체크하여 사용하지 않는 용량은 항시 AWS 탄력적 볼륨을 사용하여 수시로 조정할 수 있습니다.
참고
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
- https://aws.amazon.com/ko/premiumsupport/knowledge-center/optimize-ebs-provisioned-iops/
- https://www.cloudhealthtech.com/blog/best-practices-optimizing-amazon-ebs-volumes
- https://www.youtube.com/watch?v=zLGKZwUXvV8
- https://blog.cloudability.com/control-amazon-ebs-costs/
- https://github.com/aws-samples/aws-elastic-volumes