[ AWS ] RDS 에서 gp2 gp3

1. gp2 gp3 차이

아래는 aws 공홈에서 말하는 gp2, gp3 의 비교이다.

비용은 gp3 가 gp2 보다 20% 저렴한 것으로 나오는데, 이는 버지니아 기준이다. 

문서에는 말하는 최대 IOPS 와 최대 처리량은 단일 볼륨의 성능 한계를 말하고 있다. 

RDS 의 경우 일정 사이즈 이상 (oracle 은 200GB) 이면 자동 스트라이핑 되어 (문서의) 한계 이상까지 사용 가능하다.

예를 들면 oracle RDS 가 gp2 300 GB 사용중이면, 4 개 볼륨 스트라이핑되어 처리량은

250 * 4 = 1000 mib/s 

그렇지만 실제 성능의 병목은 EBS 성능 한계이다.

예를 들면  4xlarge 사용중일때는 593.8 mib/s 가 실제 처리량 한계이다. 

이것을 넘어서 사용하고 싶다면 인스턴스 업그레이드 (4x => 8x)  또는 타입 변경 ( ex. nitro system) 이 필요하다.

 

2. gp3 프로비저닝 

 gp2 는 성능과 볼륨이 비례하게 되는데 이 차이로 인해서 작은 사이즈에서는 gp3 성능이 더 좋다고 이야기 한다. 

다만 특정 볼륨 이상(5.3 TB) 에서는 gp2 도 성능의 한계치에 도달하여 실제로는 gp3 와 성능의 차이가 없다. 

그러나 위에 언급한것처럼 실제로는 EBS 의 성능 한계에 먼저 도달하여 성능의 리밋은 그보다 더 적게 된다. 

gp3 는 볼륨의 사이즈와 독립적으로 성능 (iops, throughput) 을 프로비저닝 가능하다. 

아래는 그 예시이다.  

# DB 인스턴스 식별자
DB_INSTANCE_IDENTIFIER="my-oracle-db"

# 원하는 IOPS 및 처리량 (예: 5000 IOPS, 200 MiB/s)
NEW_IOPS=5000
NEW_THROUGHPUT=200

# gp3로 스토리지 유형 변경 시 IOPS, 처리량 변경 명령
aws rds modify-db-instance \
    --db-instance-identifier $DB_INSTANCE_IDENTIFIER \
    --storage-type gp3 \
    --iops $NEW_IOPS \
    --throughput $NEW_THROUGHPUT \
    --apply-immediately

gp3 는 기본 3000 iops, 125 mib/s 처리량을 제공하고, (기본 제공량에서는 추가요금 발생이 없다.)

최대 16000 iops, 1000 mib/s 까지 프로비저닝 가능하다. 

기본에서 추가되는 부분까지는 비용이 추가적으로 발생한다. 그렇지만 볼륨에 따른 비용차이에 비하면 무시할만한 수준이라

가급적 최고 성능으로 프로비저닝하는 것이 좋다. 

다만 어차피 EBS 성능한계 이상은 성능이 나오지 않으니 잘 계산해서, 쓰지도 못할 비용을 굳이 오버차지할 필요는 없다. 

(aws 는 gp2 의 성능한계나 EBS 의 한계등 독립적인 구성의 한계는 문서로 제공하지만

실제로 사용하게 되는 구성들의 조합으로 인한 실제 성능 한계에 대한 문서는 제공하지 않는다. )

예를들면 처리량의 경우 125 mib/s (기본) * 4 (RDS 스트라이핑) = 500 mib/s 인데, 4xlarge 의 리밋인 593 mib/s 와 별 차이없다.

그래서 PI 에서 처리량을 확인하고, 프로비저닝을 잘 계산해보자. 

 

3. RDS 에서 nitro system 

RDS 의 경우 메모리(ram) 를 더 많이 쓰는것이 유리하기에 보통 r 타입을 많이 사용한다.  
이때 EBS 의 처리량 리밋에 계속 걸린다면 nitro system 을 사용하는 인스턴스 타입으로 변경을 고려해볼만 하다. 

예를들면, r5b는 AWS Nitro 시스템을 기반으로 구축되어 EC2에서 가장 높은 EBS(Elastic Block Store) 성능을 제공하도록 설계된 타입이고, 현재는 RDS 에서도 선택이 가능하다. 

이 인스턴스 타입은 일반적인 r 타입 인스턴스보다 최대 3배 더 높은 EBS 성능을 제공하는데, (ex. r5b.4xlarge 최대처리량은 1250 mib/s ) 이는 Nitro 시스템의 전용 하드웨어 카드가 EBS I/O 처리를 전담하여 호스트 서버의 리소스 부담을 덜어주기 때문이다. 
따라서 대용량 관계형 데이터베이스와 같이 스토리지 I/O 성능이 중요한 워크로드에 최적화되어 있다.