메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

Amazon RDS 스토리지

대부분 Amazon RDS는 데이터베이스와 로그를 저장할 목적으로 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용합니다. 단, AWS의 독자적 스토리지 시스템을 사용하는 Amazon Aurora는 예외입니다. Amazon RDS는 필요한 스토리지 용량에 따라 자동으로 데이터를 여러 Amazon EBS 볼륨에 나누어 저장하여 IOPS 성능을 강화합니다. Amazon RDS는 3가지 유형의 스토리지에 다양한 스토리지 및 성능 옵션들을 제공합니다.

요금에 대한 자세한 내용은 Amazon RDS 요금을 참조하십시오.

Amazon RDS 스토리지 유형

Amazon RDS에서는 일반용(SSD), 프로비저닝된 IOPS(초당 입출력 연산), 마그네틱 등 세 가지 스토리지 유형을 제공합니다. 이 세 가지 유형은 성능 특성과 가격이 다르므로 데이터베이스 워크로드 요건에 따라 스토리지 성능과 비용을 조정할 수 있습니다. 프로비저닝된 IOPS 및 범용(SSD) 스토리지 유형을 사용할 경우 MySQL, MariaDB, PostgreSQL 및 Oracle RDS DB 인스턴스를 최대 6TB의 스토리지까지 생성할 수 있습니다. 반면 Microsoft SQL Server RDS DB 인스턴스는 이러한 스토리지 유형에서 최대 16TB의 스토리지까지 생성이 가능합니다.

  • 범용(SSD) – gp2라고도 하는 범용(SSD) 볼륨은 광범위한 워크로드에 이상적인 비용 효율적 스토리지를 제공합니다. 이러한 볼륨은 시간을 연장할 경우 3,000IOPS의 버스트 기능까지 지원되어 지연 시간이 한 자릿수 밀리초에 불과합니다. 최소 100IOPS(33.33GiB 이하)와 최대 10,000IOPS(3,334GiB 이상) 사이에서 기준 성능은 볼륨 크기의 GiB당 3IOPS로 일정하게 확장됩니다. 중소규모의 데이터베이스에 이상적입니다.

    스토리지 크기 범위를 포함하여 일반용(SSD) 스토리지에 대한 자세한 내용은 범용(SSD) 스토리지 단원을 참조하십시오.

  • 프로비저닝된 IOPS – 프로비저닝된 IOPS 스토리지는 성능에 민감하고 임의 액세스 I/O 처리량이 일정한 I/O 집약적 워크로드, 특히 데이터베이스 워크로드 요구 사항을 충족하도록 설계되었습니다. 먼저 할당하고자 하는 스토리지 용량과 전용 IOPS 용량을 차례대로 지정합니다. Amazon RDS는 프로비저닝된 IOPS 성능의 10% 이내에서 임의의 1년 기간 중 99.9%까지 전송합니다.

    스토리지 크기 범위를 포함하여 프로비저닝된 IOPS 스토리지에 대한 자세한 내용은 성능 개선을 위한 Amazon RDS 프로비저닝된 IOPS 스토리지 단원을 참조하십시오.

  • 마그네틱 – Amazon RDS는 역호환성을 위해 마그네틱 스토리지도 지원합니다. 새 스토리지가 필요할 경우 범용(SSD) 또는 프로비저닝된 IOPS를 사용하는 것이 좋습니다. 마그네틱 스토리지에서는 DB 인스턴스에 허용되는 최대 스토리지 크기가 나머지 스토리지 유형의 크기보다 작습니다.

Amazon EBS 볼륨은 인스턴스 구성, I/O 특성, 워크로드 수요 등 성능에 영향을 끼치는 몇 가지 요인이 있습니다. 프로비저닝된 IOPS 볼륨을 최대한 활용할 수 있는 자세한 내용은 Amazon EBS 볼륨 성능을 참조하십시오.

기존 MySQL, MariaDB, PostgreSQL 및 Oracle DB 인스턴스에서는 스토리지를 확장한 경우 I/O 용량이 늘어난 것을 볼 수도 있습니다. SQL Server DB 인스턴스의 스토리지 용량 또는 유형은 변경할 수 없습니다.

성능 측정치

Amazon RDS는 DB 인스턴스의 성능을 측정할 수 있는 몇 가지 측정치가 있습니다. RDS 콘솔에서 DB 인스턴스 선택 후 [Show Monitoring]을 클릭하면 이러한 측정치가 나타납니다. 또한 Amazon CloudWatch를 사용하여 이 측정치를 모니터링할 수도 있습니다. 자세한 내용은 DB 인스턴스 측정치 보기 단원을 참조하십시오. Enhanced Monitoring은 더 자세한 I/O 측정치를 제공합니다. 자세한 내용은 Enhanced Monitoring 단원을 참조하십시오.

  • IOPS - 완료한 초당 I/O 연산 횟수입니다. 이 측정치는 일정한 시간 간격을 두고 평균 IOPS로 보고됩니다. Amazon RDS는 1분의 간격을 두고 읽기 IOPS와 쓰기 IOPS를 따로 보고합니다. 읽기 IOPS와 쓰기 IOPS의 합이 총 IOPS가 됩니다. 일반적으로 IOPS 값은 1초를 기준으로 0에서 수만에 이릅니다.

  • Latency - I/O 요청을 제출하여 완료될 때까지 걸리는 시간입니다. 이 측정치는 일정한 시간 간격을 두고 평균 지연 시간으로 보고됩니다. Amazon RDS는 초 단위로 1분의 간격을 두고 읽기 지연 시간과 쓰기 지연 시간을 따로 보고합니다. 일반적인 지연 시간 값은 밀리 초(ms)를 단위로 사용합니다. 예를 들어 Amazon RDS가 2ms를 보고할 경우 이는 0.002초에 해당합니다.

  • Throughput - 디스크와 송/수신하는 초당 바이트 수입니다. 이 측정치는 일정한 시간 간격을 두고 평균 처리 속도로 보고됩니다. Amazon RDS는 초당 메가바이트(MB/s)의 단위로 1분의 간격을 두고 읽기 처리 속도와 쓰기 처리 속도를 따로 보고합니다. 일반적인 처리 속도 값은 0에서 I/O 채널의 최대 대역폭까지 이릅니다.

  • Queue Depth - 대기열에서 처리를 기다리는 I/O 요청 수입니다. 애플리케이션에서 I/O 요청을 제출하였지만 디바이스가 다른 I/O 요청을 처리하고 있을 때는 전송되지 않는 경우가 있습니다. 이때 대기열에서 기다리게 되는데 이 대기 시간이 지연 시간과 서비스 시간(측정치로 사용하지 않음)을 구성합니다. 이 측정치는 일정한 시간 간격을 두고 평균 대기열 깊이로 보고됩니다.  Amazon RDS는 1분의 간격을 두고 대기열 깊이를 보고합니다. 일반적인 대기열 깊이 값은 0에서 수백에 이릅니다.

Amazon RDS 스토리지 관련 사실

다음은 Amazon RDS 스토리지와 관련하여 반드시 알고 있어야 할 중요한 사실입니다.

  • 최대 채널 대역폭은 DB 인스턴스 클래스에 따라 달라집니다.

  • DB 인스턴스에 이미 할당된 스토리지는 줄일 수 없습니다.

  • 프로비저닝된 IOPS에서 최대 256KB 크기의 I/O 작업이 가능한 반면, 대부분의 데이터베이스는 일반적으로 그와 같은 대용량 I/O는 사용하지 않습니다. 32KB보다 작은 I/O 요청은 하나의 I/O로 처리됩니다. 예를 들어 1000개의 16KB I/O 요청은 1000개의 32KB 요청과 동일하게 취급됩니다. 32KB보다 큰 I/O 요청은 I/O 요청 1건 이상을 사용합니다. 따라서 프로비저닝된 IOPS의 사용량은 32KB를 넘는 I/O 요청 크기에 따라 선형적으로 증가합니다.  예를 들어 48KB I/O 요청이 스토리지 용량의 I/O 요청 1.5건을 사용한다고 가정할 경우 64KB I/O 요청은 I/O 요청 2건을 사용합니다. 프로비저닝된 IOPS에 대한 자세한 정보는 성능 개선을 위한 Amazon RDS 프로비저닝된 IOPS 스토리지 단원을 참조하십시오.

    I/O 크기는 측정치를 기준으로 보고된 IOPS 값에 영향을 끼치지 않습니다. 이 IOPS 값은 오직 시간이 지나면서 I/O의 수에 따라 결정되기 때문입니다.  이 말은 I/O 크기가 32KB보다 클 경우 I/O 수가 지정한 수보다 적기 때문에 프로비저닝된 IOPS를 모두 사용할 수도 있다는 것을 의미합니다.  예를 들어 5,000IOPS가 프로비저닝된 시스템은 최대 처리 속도가 64KB I/O에서는 2,500IOPS, 또는 128KB I/O에서는 1,250IOPS에 이를 수도 있습니다.

    단, 마그네틱 스토리지는 I/O 용량을 프로비저닝하지 않기 때문에 모든 I/O 크기가 단일 I/O로 계수됩니다. 범용 스토리지는 볼륨의 크기에 따라 I/O 용량을 프로비저닝합니다. 범용 스토리지 처리량에 대한 자세한 내용은 범용(SSD) 볼륨을 참조하십시오.

  • Amazon RDS가 DB 인스턴스를 관리하기 때문에 예비할 수 있는 예비 공간을 인스턴스에 남겨두었습니다. 예비 스토리지 용량은 DB 인스턴스 클래스와 다른 요인에 따라 다르지만 전체 스토리지 용량에서 최대 1~2%에 이를 수 있습니다.

  • 프로비저닝된 IOPS는 IOPS를 지정하여 I/O 용량을 예비할 수 있습니다. 다른 시스템 용량 속성과 마찬가지로 재하 시 최대 처리 속도는 처음 사용된 리소스에 따라 제약을 받게 됩니다. 이러한 리소스로는 IOPS, 채널 대역폭, CPU 메모리 또는 데이터베이스 내부 리소스가 있습니다.

그 밖에 스토리지 성능에 영향을 끼치는 요인

다음 시스템 작업은 모두 I/O 용량을 사용하기 때문에 진행 중일 때는 데이터베이스 인스턴스 성능이 떨어질 수 있습니다.

  • DB 스냅샷 생성

  • 야간 백업

  • 다중 AZ 피어 생성

  • 읽기 전용 복제본 생성

  • 스토리지 조정

시스템 리소스가 DB 인스턴스의 처리 속도를 제한할 수도 있지만 그 밖에 병목 현상을 일으키는 원인이 또 있습니다. 다음과 같은 상황에서는 데이터베이스가 문제가 되기도 합니다.

  • 채널 처리 속도가 최대치에 이르지 않은 경우

  • 대기열 깊이가 일관적으로 낮은 경우

  • CPU 사용률이 80% 미만인 경우

  • 이용 가능한 여유 메모리가 있는 경우

  • 스왑 작업이 없는 경우

  • 여유 디스크 공간이 많은 경우

  • 수십 개의 애플리케이션 스레드가 모두 데이터베이스와 똑같은 처리 속도로 트랜잭션을 제출하고 있지만 분명 사용하지 않는 I/O 용량이 있는 경우

최대치에 이르거나 가까운 시스템 리소스가 단 하나도 없고, 스레드를 추가하더라도 데이터베이스의 트랜잭션 터리 속도가 증가하지 않는 경우에는 병목 현상의 원인이 데이터베이스에 있을 가능성이 높습니다. 가장 공통적인 원인은 행 잠금과 인덱스 페이지 잠금이지만 그 밖에 다른 가능성도 있습니다. 이런 경우에는 데이터베이스 성능 튜닝 전문가에게 조언을 구해야 합니다.

스토리지 추가 및 스토리지 유형 변경

기존 MySQL, MariaDB, PostgreSQL 및 Oracle DB 인스턴스에서는 스토리지를 확장한 경우 I/O 용량이 늘어난 것을 볼 수도 있습니다. 단, SQL Server DB 인스턴스는 스트라이프 스토리지를 Windows Server 환경에 연결할 때 확장성 제한으로 인해 스토리지 용량이나 스토리지 유형을 변경할 수 없습니다.

DB 인스턴스의 설정을 변경하여 스토리지를 추가 사용하거나 다른 스토리지 유형으로 전환할 수 있습니다. 스토리지를 추가하거나 다른 스토리지 유형으로 전환할 경우 시간이 다소 걸리고 DB 인스턴스 성능이 저하될 수 있으므로 계획을 세워야 합니다.

스토리지를 추가할 때도 DB 인스턴스의 읽기 및 쓰기는 가능하지만 추가 프로세스가 끝날 때까지 성능 저하가 발생할 수도 있습니다. 스토리지 추가는 몇 시간이 걸릴 수도 있지만 데이터베이스 부하, 스토리지 크기, 스토리지 유형, 프로비저닝된 IOPS 용량(있는 경우) 등 몇 가지 요인에 따라 달라집니다. 일반적인 스토리지 조정 시간은 24시간 미만이지만, 경우에 따라 며칠이 걸릴 수도 있습니다. 조정 중에 DB 인스턴스를 사용할 수 있겠지만, 성능 저하가 발생할 수 있습니다. 스토리지가 추가되는 동안 야간 백업이 일시 중단되고, 읽기 전용 복제본 수정, 재부팅, 삭제, 생성 및 DB 스냅샷 생성을 포함한 다른 Amazon RDS 작업은 수행할 수 없습니다.

마그네틱 스토리지와 범용(SSD) 스토리지를 서로 전환할 때는 초기에 범용(SSD) 스토리지에 할당된 540만 개의 I/O 크레딧(3,000IOPS X 30분)이 잠재적으로 고갈될 수도 있습니다. 이러한 스토리지 전환을 실행할 때는 먼저 82GB 데이터가 약 3,000IOPS의 속도로 전환됩니다. 나머지 데이터는 할당된 범용(SSD) 스토리지에서 GB당 100IOPS의 기본 속도로 전환됩니다. 이로 인해 전환 시간이 길어질 수 있습니다. 이때는 범용(SSD) 스토리지를 추가로 프로비저닝하여 기본 I/O 속도를 높여 전환 시간을 단축할 수도 있습니다. 하지만 이미 할당된 스토리지는 크기를 줄일 수 없습니다.

범용(SSD) 스토리지

범용(SSD) 스토리지는 비용 효율적이어서 중소규모의 데이터베이스 워크로드에 이상적입니다. 다음은 범용(SSD) DB 인스턴스의 스토리지 크기 범위입니다.

  • MySQL, MariaDB, PostgreSQL DB 인스턴스: 20GB–6TB

  • SQL Server Enterprise 및 Standard Edition: 200GB–16TB

  • SQL Server Web 및 Express Edition: 20GB–16TB

  • Oracle DB 인스턴스: 20GB–6TB

범용(SSD) 스토리지는 지연 시간이 한 자릿수 밀리초로서, 시간을 연장할 경우 3,000IOPS까지 버스트 능력을 발휘합니다. 최소 100IOPS(33.33GiB 이하)와 최대10,000IOPS(3,334GiB 이상) 사이에서 기준 성능은 볼륨 크기의 GiB당 3IOPS로 일정하게 확장됩니다.

워크로드의 처리 속도를 높이기 위해 범용(SSD) 스토리지를 100GB 미만으로 프로비저닝하여 초기 범용(SSD) I/O 크레딧 밸런스가 차감되면 오히려 지연 시간이 늘어날 수 있습니다.

I/O 크레딧 및 버스트 성능

범용(SSD) 스토리지 성능은 볼륨 크기에 따라 결정됩니다. 그 이유는 볼륨 크기가 볼륨의 기본 성능과 I/O 크레딧의 누적 속도에 영향을 미치기 때문입니다. 즉, 볼륨이 클수록 기본 성능이 높아지고 I/O 크레딧의 누적 속도도 빨라집니다. I/O 크레딧이란 범용(SSD) 스토리지에서 기본 성능 이상이 필요할 때 대용량 I/O를 버스트하는 데 사용할 수 있는 가용 대역폭을 의미합니다. 스토리지에 I/O 크레딧이 많을수록 더 높은 성능이 필요할 때 기본 성능 이상으로 버스트하는 시간이 길어질 뿐만 아니라 성능도 좋아집니다.

범용(SSD) 스토리지를 사용할 경우 DB 인스턴스에 초기 I/O 크레딧 밸런스로 540만 I/O 크레딧이 제공됩니다. 이는 30분 동안 3,000IOPS로 버스트 성능을 유지할 수 있는 수입니다. 이러한 초기 크레딧 밸런스는 부트 볼륨에 빠른 초기 부팅 주기를 제공하고 기타 애플리케이션에 좋은 부트스트래핑 환경을 제공하도록 설계되었습니다. 볼륨은 볼륨 크기의 GB 당 3 IOPS의 기준 성능 비율로 I/O 크레딧을 획득합니다. 예를 들어 100GB SSD 볼륨의 기준 성능은 300IOPS입니다.

스토리지에 기본 성능 I/O 이상이 필요한 경우 크레딧 밸런스에서 I/O 크레딧을 사용하여 최대 3,000IOPS까지 필요한 성능을 버스트할 수 있습니다. 1,000GB가 넘는 스토리지는 기본 성능이 최대 버스트 성능 이상이기 때문에 I/O 크레딧 밸런스가 절대 차감되는 일 없이 무제한 버스트가 가능합니다. 스토리지가 초당 획득한 I/O 크레딧 이하를 사용하는 경우 미사용 I/O 크레딧은 I/O 크레딧 밸런스에 가산됩니다. 범용(SSD) 스토리지를 사용하는 DB 인스턴스에서 최대 I/O 크레딧 밸런스는 초기 크레딧 밸런스(540만 I/O 크레딧)와 동일합니다.

스토리지가 I/O 크레딧 밸런스를 모두 사용하면 I/O 수요가 기본 성능 밑으로 떨어져서 미사용 크레딧이 I/O 크레딧 밸런스에 가산될 때까지 최대 성능은 기본 성능과 동일한 수준을 유지합니다. (여기에서 기본 성능 수준이란 스토리지가 크레딧을 획득하는 속도를 말합니다.) 스토리지가 클수록 기본 성능이 높아지고 크레딧 밸런스의 보충 속도도 빨라집니다.

참고

마그네틱 스토리지와 범용(SSD) 스토리지를 서로 전환할 때는 초기에 범용(SSD) 스토리지에 할당된 540만 개의 I/O 크레딧(3,000IOPS X 30분)이 잠재적으로 고갈될 수도 있습니다. 이러한 스토리지 전환을 실행할 때는 먼저 82GB 데이터가 약 3,000IOPS의 속도로 전환되고, 나머지 데이터는 할당된 범용(SSD) 스토리지에서 GB당 100IOPS의 기본 성능으로 전환됩니다. 이로 인해 전환 시간이 길어질 수 있습니다. 이때는 범용(SSD) 스토리지를 추가로 프로비저닝하여 기본 I/O 속도를 높여 전환 시간을 단축할 수도 있지만 이미 할당된 스토리지는 크기를 줄일 수 없습니다.

다음 표에는 몇 가지 스토리지 크기가 나와 있습니다. 각 크기마다 스토리지의 기본 성능, 즉 I/O 크레딧이 누적되는 속도가 표시되어 있습니다. 또한 크레딧 밸런스가 가득 찬 상태에서 시작할 경우 최대 3,000IOPS일 때 버스트 지속 시간도 나열되어 있습니다. 그 밖에 비어있는 크레딧 밸런스를 스토리지가 다시 채우는 데 걸리는 시간(초)도 확인할 수 있습니다.

스토리지 크기(GB) 기본 성능(IOPS) 최대 버스트 지속 시간 @ 3,000IOPS(초) 고갈된 크레딧 밸런스를 보충하는 데 소요되는 시간(초)
1 100 1,862 54,000
100 300 2,000건 18,000
250 750 2,400 7,200
500 1,500 3,600 3,600
750 2,250 7,200 2,400
1,000 3,000 무제한 해당 사항 없음

스토리지의 버스트 지속 시간은 스토리지 크기, 필요한 버스트 IOPS, 그리고 버스트 실행 시 크레딧 밸런스에 따라 달라집니다. 이 관계는 아래 방정식과 같습니다.

Copy
(Credit balance) Burst duration =  ------------------------------------ (Burst IOPS) - 3(Storage size in GB)

I/O 크레딧 밸런스의 고갈로 인해 스토리지 성능이 기본 성능으로 제한되는 경우가 잦으면 범용(SSD) 스토리지를 추가 할당하여 기본 성능을 높이는 것을 고려해야 합니다. 또는 IOPS 성능을 유지해야 하는 워크로드인 경우에는 Provisioned IOPS 스토리지로 전환하는 것도 좋습니다.

I/O 성능이 꾸준하게 요구되는 워크로드인 경우 100GB 미만의 범용(SSD) 스토리지를 프로비저닝하면 I/O 버스트 크레딧 밸런스가 고갈되어 오히려 지연 시간이 늘어날 수도 있습니다.

성능 개선을 위한 Amazon RDS 프로비저닝된 IOPS 스토리지

빠르고 일관적인 I/O 성능이 필요한 프로덕션 애플리케이션의 경우에는 프로비저닝된 IOPS(초당 입/출력 연산 수) 스토리지를 권장합니다. 프로비저닝된 IOPS 스토리지는 처리 속도가 빠르고, 예측 가능하며, 일관적인 성능의 스토리지입니다. 프로비저닝된 IOPS 스토리지는 일관적인 성능이 필요한 온라인 트랜잭션 프로세싱(OLTP) 워크로드에 이상적일 뿐만 아니라 성능 튜닝에도 효과적입니다.

DB 인스턴스를 생성할 때는 IOPS 속도와 스토리지 공간 할당량을 지정합니다. Amazon RDS는 DB 인스턴스 수명이 다 할 때까지, 혹은 DB 인스턴스를 변경할 때까지 IOPS와 스토리지를 프로비저닝합니다.

참고

실제 체감 IOPS는 데이터베이스 워크로드, DB 인스턴스 크기, 그리고 DB 엔진에서 이용 가능한 페이지 크기와 채널 대역폭에 따라 지정 값과 차이가 날 수 있습니다. 자세한 내용은 체감 IOPS 속도에 영향을 끼치는 요인 단원을 참조하십시오.

다음 표는 데이터베이스 엔진에 따른 IOPS와 스토리지 범위를 나타냅니다.

프로비저닝된 IOPS 범위 스토리지 범위 IOPS와 스토리지(GB) 비율 범위
MariaDB 1000–30,000IOPS 100GB–6TB 3:1–10:1
Microsoft SQL Server, Enterprise 및 Standard Edition 1000–20,000IOPS 200GB–16TB 1:1–50:1
Microsoft SQL Server, Web 및 Express Edition 1000–20,000IOPS 100GB–16TB 1:1–50:1
MySQL 1000–30,000IOPS 100GB–6TB 3:1–10:1
Oracle 1000–30,000IOPS 100GB–6TB 3:1–10:1
PostgreSQL 1000–30,000IOPS 100GB–6TB 3:1–10:1

요청한 IOPS 속도와 할당된 스토리지 용량의 비율은 매우 중요하며, 데이터베이스 엔진에 따라 다릅니다. 예를 들어 Oracle 엔진일 때는 비율이 3:1-10:1이 되어야 합니다. Oracle DB 인스턴스는 처음에는 1,000IOPS와 200GB 스토리지(5:1)로 프로비저닝할 수 있습니다. 그런 다음 나중에 2,000IOPS와 200GB 스토리지(10:1)로 확장할 수 있습니다. Oracle DB 인스턴스는 최대 30,000IOPS와 6TB(6000GB) 스토리지(5:1)까지 확장 가능합니다.

기존 Oracle, MySQL 또는 MariaDB DB 인스턴스에서도 수정을 통해 프로비저닝된 IOPS 스토리지를 사용할 수 있습니다. 또한 프로비저닝된 IOPS 스토리지 설정도 수정할 수 있습니다.

다중 AZ, 읽기 전용 복제본, 스냅샷, VPC 및 DB 인스턴스 클래스에서 프로비저닝된 IOPS 스토리지 사용하기

프로덕션 OLTP 사용 사례에서 내결함성을 높이는 것이 목적일 때는 다중 AZ 배포를, 빠르고 예측 가능한 성능이 목적일 때는 프로비저닝된 IOPS 스토리지를 사용하는 것이 바람직합니다. 프로비저닝된 IOPS 스토리지는 다중 AZ 배포에 더하여 다음과 같은 기능을 추가 지원합니다.

  • 네트워크 격리 및 보안 강화를 위한 Amazon VPC

  • 읽기 전용 복제본 - 읽기 전용 복제본의 스토리지 유형은 마스터 DB 인스턴스의 스토리지와 독립되어 있습니다. 예를 들면, 마스터 DB 인스턴스가 마그네틱 스토리지를 사용하더라도 프로비저닝된 IOPS 스토리지를 사용하는 읽기 전용 복제본을 추가할 수 있으며, 그 반대로도 가능합니다. 프로비저닝된 IOPS 스토리지를 사용하는 마스터 DB 인스턴스에는 마그네틱 스토리지 기반 읽기 전용 복제본을 사용할 수 있습니다. 이때는 마스터 DB 인스턴스와 읽기 전용 복제본이 모두 프로비저닝된 IOPS 스토리지를 사용할 경우 읽기 전용 복제본의 성능이 큰 차이를 보일 수 있습니다.

  • DB 스냅샷 - 프로비저닝된 IOPS 스토리지 기반 DB 인스턴스를 사용하는 경우, 대상 DB 인스턴스에서 마그네틱 스토리지 또는 프로비저닝된 IOPS 스토리지를 사용하는지 여부에 관계없이 DB 스냅샷을 이용해 동일한 구성의 DB 인스턴스를 복구할 수 있습니다. 하지만 DB 인스턴스가 마그네틱 스토리지를 사용할 경우, 마그네틱 스토리지를 사용하는 DB 인스턴스만 DB 스냅샷을 이용해 복구할 수 있습니다.

  • 프로비저닝된 IOPS 스토리지는 DB 인스턴스 클래스에 상관없이 사용할 수 있습니다. 하지만 DB 인스턴스 클래스가 작을수록 프로비저닝된 IOPS 스토리지를 지속적으로 최대한 활용하기는 어렵습니다. 따라서 최고의 성능을 위해서는 프로비저닝된 IOPS 스토리지에 최적화된 DB 인스턴스 유형을 하나 사용하는 것이 좋습니다.

프로비저닝된 IOPS 스토리지 비용

프로비저닝된 IOPS 스토리지는 향후 사용을 위한 예비 리소스까지 할당하기 때문에 한 달간 사용 여부에 상관없이 할당된 리소스에 대한 요금이 청구됩니다. 프로비저닝된 IOPS 스토리지를 사용하면 매월 Amazon RDS I/O 비용은 청구되지 않습니다. 사용한 I/O에 대해서만 비용을 지불하려면 마그네틱 스토리지를 사용하는 DB 인스턴스가 이상적입니다.

요금에 대한 자세한 내용은 Amazon RDS 요금을 참조하십시오.

Amazon RDS 프로비저닝된 IOPS 최대한 활용하기

프로비저닝된 IOPS 스토리지를 사용하면 시스템이 동시에 처리할 수 있는 I/O 요청 수가 증가합니다. 이처럼 동시 처리 가능한 수가 증가하면 대기열의 I/O 요청 시간이 줄어들어 지연 시간이 감소하는 효과가 있습니다. 지연 시간 감소는 데이터베이스 커밋 속도의 향상으로 이어져 응답 시간이 개선되고 데이터베이스 처리 속도가 빨라집니다.

예를 들어 채널의 읽기 처리 속도를 계속해서 105Mbps로 제한하여 실행되는 10,000 프로비저닝된 IOPS에 데이터 수요가 지나치게 많이 발생하는 OLTP 데이터베이스를 프로비저닝한다고 가정하겠습니다. 워크로드의 균형도 불안하여 일부 쓰기 채널 대역폭은 미사용 상태입니다. 인스턴스가 사용하는 IOPS 수가 10,000건 미만이더라도 용량을 20,000 프로비저닝된 IOPS로 늘려서 이점을 이용할 수는 있습니다.

프로비저닝된 IOPS 용량을 10,000에서 20,000으로 늘리면 시스템에서 동시 처리 가능한 I/O 용량도 2배가 됩니다. 여기서 동시 처리 가능한 용량이 늘어난다는 말은 지연 시간의 감소를 의미하여 트랜잭션 완료 시간이 더욱 빨라지고 데이터베이스 트랜잭션 속도가 증가합니다. 이처럼 읽기 및 쓰기 지연 시간은 용량을 늘려 개선할 수 있으며, 시스템은 어떤 리소스가 먼저 제한을 받든지 상관없이 새로운 균형 상태로 안정됩니다.

데이터베이스 트랜잭션 속도가 더욱 높아지더라도 다음과 같은 조건에서는 프로비저닝된 IOPS 처리량이 실제로 줄어들 수 있습니다. 예를 들어 쓰기 처리 속도의 증가로 읽기 요청 수가 감소할 수 있습니다. 이는 데이터베이스가 그룹 커밋을 효과적으로 사용한다는 것을 의미하는 좋은 징표입니다.  쓰기 처리 속도가 늘어나도 쓰기 IOPS가 동일할 경우에는 로그 쓰기가 커졌지만 여전히 256KB 미만인 것을 의미합니다. 그 밖에 쓰기 처리 속도가 늘어나고 쓰기 I/O는 줄어든 경우에는 로그 쓰기가 커지면서 I/O 요청이 사용하는 프로비저닝된 IOPS 용량의 I/O가 1개를 넘어서기 때문에 평균 용량도 32KB 이상이라는 것을 의미합니다.

AWS CLI 및 Amazon RDS API를 통한 프로비저닝된 IOPS 스토리지 지원

AWS CLI는 다음 명령을 통해 프로비저닝된 IOPS 스토리지를 지원합니다.

Amazon RDS API는 다음 작업을 통해 프로비저닝된 IOPS 스토리지를 지원합니다.

체감 IOPS 속도에 영향을 끼치는 요인

실제 체감 IOPS 속도는 페이지 크기 및 네트워크 대역폭에 따라 프로비저닝 용량과 차이가 날 수 있습니다. 페이지 크기와 네트워크 대역폭은 일부분 DB 엔진에 따라 결정됩니다. 또한 DB 인스턴스 크기와 데이터베이스 워크로드도 체감 속도에 영향을 끼칩니다.

페이지 크기 및 채널 대역폭

이론적으로 IOPS 최대 속도는 데이터베이스 I/O 페이지 크기와 가용한 채널 대역폭에 따라 달라집니다. MySQL 및 MariaDB가 사용하는 페이지 크기는 16KB인 반면 Oracle, PostgreSQL(기본) 및 SQL Server는 8KB를 사용합니다. DB 인스턴스의 전이중 I/O 채널 대역폭이 1,000Mbps인 경우 페이지 I/O의 최대 IOPS는 16KB I/O에서 양방향(입/출력 채널) 총합 8,000IOPS이고, 8KB I/O에서 양방향 총합 16,000IOPS입니다.

채널 하나의 트래픽이 용량을 모두 채우면 나머지 채널의 가용 IOPS는 재할당할 수 없습니다. 결과적으로 가능한 IOPS 속도는 프로비저닝된 IOPS 속도에 미치지 못합니다.

각 페이지 읽기 또는 쓰기 작업은 I/O 연산 1회로 구성됩니다. 따라서 데이터베이스 연산에서 단일 페이지 이상을 읽고 쓸 때는 각 데이터베이스 연산마다 다중 I/O 연산을 사용합니다. 32KB가 넘는 I/O 요청은 PIOPS 용량 사용 원칙에 따라 I/O 1회 이상으로 간주합니다. 이에 따라 40KB I/O 요청은 I/O 1.25회를, 48KB 요청은 I/O 1.5회를, 그리고 64KB 요청은 I/O 2회를 사용하는 셈입니다. I/O 요청은 따로 분할하지 못하기 때문에 모두 스토리지 변경 없이 그대로 디바이스에 보내집니다. 예를 들어 데이터베이스가 128KB I/O 요청을 제출할 경우 128KB I/O 단일 요청으로 스토리지 디바이스에 보내집니다. 하지만 사용되는 PIOPS 용량은 32KB I/O 요청 4건과 동일합니다.

프로비저닝된 IOPS용 DB 인스턴스 클래스

프로비저닝된 IOPS 스토리지를 사용하는 경우, M4, M3, R3 및 M2 DB 인스턴스 클래스를 사용합니다. 이러한 인스턴스 클래스들은 프로비저닝된 IOPS 스토리지에 최적화되어 있지만 기타 인스턴스 클래스는 그렇지 않습니다.

프로비저닝된 IOPS에 최적화된 DB 인스턴스 클래스 전용 EBS 처리 속도(Mbps) 16k IOPS 최대 속도** 최대 대역폭(MB/s)**
db.m1.large 500Mbps 4000 62.5
db.m1.xlarge 1,000Mbps 8000 125
db.m2.2xlarge 500Mbps 4000 62.5
db.m2.4xlarge 1,000Mbps 8000 125
db.m3.xlarge 500Mbps 4000 62.5
db.m3.2xlarge 1,000Mbps 8000 125
db.r3.xlarge 500Mbps 4000 62.5
db.r3.2xlarge 1,000Mbps 8000 125
db.r3.4xlarge 2000Mbps 16000 250
db.r3.8xlarge * * *
db.r4.large 425Mbps 3000 50
db.r4.xlarge 850Mbps 6000 100
db.r4.2xlarge 1700Mbps 12000 200
db.r4.4xlarge 3500Mbps 18750 437
db.r4.8xlarge 7000Mbps 37500 875
db.r4.16xlarge 14000Mbps 75000 1750
db.m4.large 450Mbps 3600 56.25
db.m4.xlarge 750Mbps 6000 93.75
db.m4.2xlarge 1,000Mbps 8000 125
db.m4.4xlarge 2000Mbps 16000 250
db.m4.10xlarge 4000Mbps 32000 500
db.m4.16xlarge 10000Mbps 65000 1250

* r3.8xlarge DB 인스턴스 클래스에는 Amazon EBS 최적화를 제공하지 않는 10기가비트 네트워크 인터페이스가 있습니다. 따라서 r3.8xlarge DB 인스턴스 클래스에서는 전용 EBS 대역폭을 사용할 수 없습니다. 그러나 애플리케이션이 EBS와 경합하는 다른 네트워크 트래픽을 보내지 않는다면 EBS로의 트래픽에 할당된 모든 대역폭을 사용할 수 있습니다.

** 이 값은 100% 읽기 전용 작업을 기준으로 반올림한 근사치이며, 기준 구성을 보조할 목적으로 제공됩니다. EBS에 최적화된 연결은 전이중 모드로서, 두 통신 경로를 모두 사용하는 경우 50/50 읽기/쓰기 작업으로 균형을 이뤄 처리 속도와 IOPS가 향상됩니다. 네트워크, 파일 시스템 및 EBS 암호화 오버헤드로 인해 가용한 최대 처리량과 IOPS가 줄어드는 경우도 있습니다.

데이터베이스 워크로드

자동 백업, DB 스냅샷 및 스토리지 조정 등의 시스템 작업은 일부 I/O를 사용하기 때문에 정상적인 데이터베이스 연산에서 가용한 전체 용량이 줄어듭니다. 데이터베이스 설계에 따라 동시 처리 가능한 연산 문제, 잠금 또는 그 밖에 데이터베이스 논쟁을 불러일으키는 원인이 있는 경우에는 프로비저닝한 대역폭 중 일부는 직접 사용하지 못할 수도 있습니다.

최대 워크로드 수요를 만족하도록 IOPS 용량을 프로비저닝한 경우 수요가 적을 때는 애플리케이션이 프로비저닝한 IOPS보다 평균적으로 적은 수를 사용합니다.

프로비저닝된 IOPS 스토리지의 효율적인 사용 여부를 검증할 수 있도록 디스크 대기열 깊이라고 불리는 CloudWatch 측정치를 새로 추가하였습니다. 애플리케이션이 평균적으로 1,000IOPS를 프로비저닝할 때마다 약 5건의 I/O 연산으로 대기열 깊이를 유지할 경우 프로비저닝한 용량을 사용하고 있다고 말할 수 있습니다. 예를 들어 10,000IOPS를 프로비저닝하였다면 최소 50건의 I/O 연산이 대기 중이어야만 프로비저닝한 용량을 사용하고 있는 셈입니다.