Aurora DB 클러스터의 성능 및 확장 관리 - Amazon Aurora

Aurora DB 클러스터의 성능 및 확장 관리

다음 옵션을 사용해 Aurora DB 클러스터 및 DB 인스턴스의 성능 및 확장을 관리할 수 있습니다.

스토리지 조정

Aurora 스토리지는 클러스터 볼륨에 저장된 데이터에 따라 자동 조정됩니다. 데이터 증가에 따라 클러스터 볼륨 스토리지는 최대 128테비바이트(TiB) 또는 64TiB까지 확장됩니다. 최대 크기는 DB 엔진 버전에 따라 다릅니다. 클러스터 볼륨에 포함되는 데이터 종류를 알아보려면 Amazon Aurora 스토리지 및 안정성 단원을 참조하세요. 특정 버전의 최대 크기에 대한 자세한 내용은 Amazon Aurora 크기 제한 섹션을 참조하세요.

스토리지 비용을 결정하기 위해 클러스터 볼륨 크기가 한 시간 단위로 평가됩니다. 요금에 대한 자세한 내용은 Aurora 요금 페이지를 참조하십시오.

Aurora 클러스터 볼륨의 크기는 수테비바이트까지 확장할 수 있지만 요금은 볼륨에서 사용한 공간에 대해서만 청구됩니다. 요금이 청구되는 스토리지 공간을 결정하는 메커니즘은 Aurora 클러스터 버전에 따라 다릅니다.

  • 클러스터 볼륨에서 Aurora 데이터가 제거되면 비슷한 양만큼 요금이 청구되는 전체 공간이 감소합니다. 이 동적 크기 조정 동작은 기본 테이블스페이스가 삭제되거나 공간이 더 적게 필요하도록 재구성할 때 발생합니다. 따라서 더 이상 필요하지 않은 테이블과 데이터베이스를 삭제하여 스토리지 비용을 줄일 수 있습니다. 동적 크기 조정은 특정 Aurora 버전에 적용됩니다. 다음은 데이터를 제거할 때 클러스터 볼륨의 크기가 동적으로 조정되는 Aurora 버전입니다.

    Aurora MySQL
    • 버전 3(MySQL 8.0과 호환): 지원되는 모든 버전

    • 버전 2 (MySQL 5.7과 호환): 2.11 이상

    Aurora PostgreSQL 지원되는 모든 버전
    Aurora Serverless v2 지원되는 모든 버전
    Aurora Serverless v1 지원되는 모든 버전
  • 위 목록에 있는 Aurora 버전보다 낮은 버전에서는 데이터를 제거할 때 복원된 공간을 클러스터 볼륨이 다시 사용할 수 있지만 볼륨 자체의 크기는 줄어들지 않습니다.

  • 이 기능은 Aurora를 사용할 수 있는 AWS 리전에 단계적으로 배포되고 있습니다. 클러스터가 있는 리전에 따라 이 기능을 아직 사용하지 못할 수도 있습니다.

동적 크기 조정은 클러스터 볼륨 내의 테이블스페이스를 물리적으로 제거하거나 크기를 조정하는 작업에 적용됩니다. 따라서 DROP TABLE, DROP DATABASE, TRUNCATE TABLEALTER TABLE ... DROP PARTITION과 같은 SQL 문에 적용됩니다. DELETE 문을 사용하여 행을 삭제하는 경우에는 적용되지 않습니다. 테이블에서 많은 수의 행을 삭제하는 경우 이후에 Aurora MySQL OPTIMIZE TABLE 확장이나 Aurora PostgreSQL pg_repack 문을 실행해 테이블을 재구성하여 클러스터 볼륨의 크기를 동적으로 조정할 수 있습니다.

참고

Aurora MySQL의 경우 innodb_file_per_table 파라미터는 테이블 스토리지가 구성되는 방식에 영향을 미칩니다. 테이블이 시스템 테이블스페이스의 일부인 경우 테이블을 삭제해도 시스템 테이블스페이스의 크기가 줄어들지 않습니다. 따라서 동적 크기 조정을 최대한 활용하려면 Aurora MySQL DB 클러스터에서 innodb_file_per_table을 1로 설정해야 합니다.

Aurora MySQL 버전 2.11 이상의 경우 InnoDB 임시 테이블스페이스가 삭제되고 재시작 시 다시 생성됩니다. 임시 테이블스페이스가 차지하는 공간이 시스템에 릴리스되고 클러스터 볼륨의 크기가 조정됩니다. 동적 크기 조정 기능을 최대한 활용하려면 DB 클러스터를 Aurora MySQL 버전 2.11 이상으로 업그레이드하는 것이 좋습니다.

동적 크기 조정 기능은 테이블스페이스의 테이블이 삭제될 때 즉시 공간을 회수하는 것이 아니라 하루에 약 10TB의 속도로 공간을 점진적으로 확보합니다. 시스템 테이블스페이스는 절대 제거되지 않으므로 시스템 테이블스페이스의 공간은 회수되지 않습니다. 테이블스페이스에서 회수되지 않은 여유 공간은 작업에서 해당 테이블스페이스에 공간이 필요할 때 재사용됩니다. 동적 규모 조정 기능은 클러스터가 사용 가능한 상태일 때만 스토리지 공간을 회수할 수 있습니다.

CloudWatch에서 VolumeBytesUsed 지표를 모니터링하여 클러스터가 사용 중인 스토리지 공간의 양을 확인할 수 있습니다. 스토리지 요금 청구에 대한 자세한 정보는 Aurora 데이터 스토리지 요금이 청구되는 방법 섹션을 참조하세요.

  • AWS Management Console에서는 클러스터에 대한 세부 정보 페이지의 Monitoring 탭에서 차트로 이 그림을 볼 수 있습니다.

  • AWS CLI를 사용하는 경우 다음 Linux 예제와 유사한 명령을 실행하면 됩니다. 이때 시작 및 종료 시간과 클러스터 이름을 해당되는 고유한 값으로 대체합니다.

    aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" \ --statistics Average Maximum Minimum \ --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier

    이 명령을 실행하면 다음과 비슷한 출력이 생성됩니다.

    { "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T21:25:00+00:00", "Average": 182871982080.0, "Minimum": 182871982080.0, "Maximum": 182871982080.0, "Unit": "Bytes" } ] }

다음 예제에서는 Linux 시스템에서 AWS CLI 명령을 사용하여 시간 경과에 따른 Aurora 클러스터의 스토리지 사용량을 추적하는 방법을 보여줍니다. --start-time--end-time 파라미터는 전체 시간 간격을 하루로 정의합니다. --period 파라미터는 한 시간 간격으로 측정값을 요청합니다. 지표가 연속적으로 수집되지 않고 일정 간격으로 수집되기 때문에 작은 --period 값을 선택하는 것은 적절하지 않습니다. 또한 해당 SQL 문이 완료된 후에도 Aurora 스토리지 작업이 백그라운드에서 일정 시간 동안 계속되는 경우가 있습니다.

첫 번째 예제는 출력을 기본 JSON 형식으로 반환합니다. 데이터 포인트는 타임스탬프를 기준으로 정렬되지 않고 임의의 순서로 반환됩니다. 이 JSON 데이터를 차트 도구로 가져와 정렬 및 시각화를 수행할 수 있습니다.

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id { "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T19:40:00+00:00", "Maximum": 182872522752.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-05T00:40:00+00:00", "Maximum": 198573719552.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-05T05:40:00+00:00", "Maximum": 206827454464.0, "Unit": "Bytes" }, { "Timestamp": "2020-08-04T17:40:00+00:00", "Maximum": 182872522752.0, "Unit": "Bytes" }, ... output omitted ...

이 예제는 이전 예제와 동일한 데이터를 반환합니다. --output 파라미터는 데이터를 압축 일반 텍스트 형식으로 나타냅니다. aws cloudwatch 명령은 해당 출력을 sort 명령에 파이프합니다. -k 명령의 sort 파라미터는 UTC(협정 세계시) 형식의 타임스탬프인 세 번째 필드를 기준으로 출력을 정렬합니다.

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \ --output text | sort -k 3 VolumeBytesUsed DATAPOINTS 182872522752.0 2020-08-04T17:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T18:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T19:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T20:41:00+00:00 Bytes DATAPOINTS 187667791872.0 2020-08-04T21:41:00+00:00 Bytes DATAPOINTS 190981029888.0 2020-08-04T22:41:00+00:00 Bytes DATAPOINTS 195587244032.0 2020-08-04T23:41:00+00:00 Bytes DATAPOINTS 201048915968.0 2020-08-05T00:41:00+00:00 Bytes DATAPOINTS 205368492032.0 2020-08-05T01:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T02:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T03:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T04:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T05:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T06:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T07:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T08:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T09:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T10:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T11:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T12:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T13:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T14:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T15:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T16:41:00+00:00 Bytes

정렬된 출력에는 모니터링 기간의 시작 및 종료 시 사용된 스토리지 양이 표시됩니다. 또한 Aurora가 클러스터에 더 많은 스토리지를 할당한 기간 동안의 데이터 포인트도 찾을 수 있습니다. 다음 예제에서는 Linux 명령을 사용하여 시작 및 종료 VolumeBytesUsed 값을 기가바이트(GB)와 기비바이트(GiB) 형식으로 변경합니다. 기가바이트는 10의 제곱으로 측정된 단위를 나타내며 회전식 하드 드라이브의 스토리지를 논할 때 일반적으로 사용됩니다. 기비바이트는 2의 제곱으로 측정된 단위를 나타냅니다. Aurora 스토리지 측정 및 제한은 일반적으로 기비바이트와 테비바이트와 같은 2의 제곱 단위로 명시됩니다.

$ GiB=$((1024*1024*1024)) $ GB=$((1000*1000*1000)) $ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB" Start: 170 GiB, End: 192 GiB $ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB" Start: 182 GB, End: 206 GB

VolumeBytesUsed 지표는 클러스터에서 요금이 발생하고 있는 스토리지 양을 알려줍니다. 따라서 가능하면 이 수치를 최소화하는 것이 좋습니다. 그러나 이 지표에는 Aurora가 클러스터에서 내부적으로 사용하여 요금을 부과하지 않는 일부 스토리지가 포함되어 있습니다. 클러스터가 스토리지 제한에 근접하여 공간이 부족해질 수 있는 경우 AuroraVolumeBytesLeftTotal 지표를 모니터링하고 이 수치를 최대화하는 것이 더 도움이 됩니다. 다음 예제에서는 AuroraVolumeBytesLeftTotal 대신 VolumeBytesUsed에 대해 이전 계산과 비슷한 계산을 실행합니다.

$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \ --output text | sort -k 3 AuroraVolumeBytesLeftTotal DATAPOINTS 140530528288768.0 2023-02-23T19:25:00+00:00 Count $ TiB=$((1024*1024*1024*1024)) $ TB=$((1000*1000*1000*1000)) $ echo "$((69797067915264 / $TB)) TB remaining for this cluster" 69 TB remaining for this cluster $ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster" 63 TiB remaining for this cluster

Aurora MySQL 버전 2.09 이상이나 Aurora PostgreSQL을 실행하는 클러스터의 경우 데이터가 추가되면 VolumeBytesUsed에서 보고되는 사용 가능한 크기가 증가하고 데이터가 제거되면 사용 가능한 크기가 감소합니다. 다음 예에서는 이 작업을 수행하는 방법을 보여줍니다. 이 보고서는 임시 데이터가 있는 테이블이 생성되고 삭제될 때 15분 간격으로 클러스터의 최대 및 최소 스토리지 크기를 표시합니다. 이 보고서에는 최소 값보다 최대 값이 먼저 나열됩니다. 따라서 15분 간격 내에 스토리지 사용량이 어떻게 변경되었는지 이해하려면 오른쪽에서 왼쪽으로 수치를 해석해야 합니다.

$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id --output text | sort -k 4 VolumeBytesUsed DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T20:49:00+00:00 Bytes DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T21:19:00+00:00 Bytes DATAPOINTS 22022176768.0 14545305600.0 2020-08-05T21:49:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:19:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:49:00+00:00 Bytes DATAPOINTS 22022176768.0 15614263296.0 2020-08-05T23:19:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-05T23:49:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-06T00:19:00+00:00 Bytes

다음 예시에서는 Aurora MySQL 버전 2.09 이상이나 Aurora PostgreSQL을 실행하는 클러스터의 경우 AuroraVolumeBytesLeftTotal에서 보고하는 사용 가능한 크기에 128TiB 크기 제한이 어떻게 반영되는지 보여줍니다.

$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \ --output text | sort -k 3 AuroraVolumeBytesLeftTotal DATAPOINTS 140515818864640.0 2020-08-05T20:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:26:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:56:00+00:00 Count DATAPOINTS 140514866757632.0 2020-08-05T22:26:00+00:00 Count DATAPOINTS 140511020580864.0 2020-08-05T22:56:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:26:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-06T00:26:00+00:00 Count $ TiB=$((1024*1024*1024*1024)) $ TB=$((1000*1000*1000*1000)) $ echo "$((140515818864640 / $TB)) TB remaining for this cluster" 140 TB remaining for this cluster $ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster" 127 TiB remaining for this cluster

인스턴스 조정

필요에 따라 DB 클러스터의 DB 인스턴스마다 DB 인스턴스 클래스를 수정하여 Aurora DB 클러스터의 크기를 조정할 수 있습니다. Aurora는 데이터베이스 엔진 호환성에 따라 Aurora에 최적화된 여러 DB 인스턴스 클래스를 지원합니다.

읽기 확장

DB 클러스터에서 Aurora 복제본을 최대 15개까지 생성하여 Aurora DB 클러스터에 대한 읽기 조정을 수행할 수 있습니다. 각 Aurora 복제본은 복제본 지연 시간—을 최소화하여 클러스터 볼륨에서 동일한 데이터를 반환합니다(일반적으로 이 지연 시간은 기본 인스턴스가 업데이트를 적용한 후 100밀리초 미만입니다). 읽기 트래픽이 증가하면 Aurora 복제본을 추가 생성하여 직접 연결함으로써 DB 클러스터의 읽기 부하를 분산시키는 것도 가능합니다. Aurora 복제본의 DB 인스턴스 클래스가 기본 인스턴스의 DB 인스턴스 클래스와 같을 필요는 없습니다.

DB 클러스터에 Aurora 복제본을 추가하는 방법에 대한 자세한 내용은 DB 클러스터에 Aurora 복제본 추가 단원을 참조하십시오.

연결 관리

Aurora DB 인스턴스에 대해 허용되는 최대 연결 수는 DB 인스턴스의 인스턴스 수준 파라미터 그룹의 max_connections 파라미터로 결정됩니다. 파라미터 기본값은 DB 인스턴스에 사용되는 DB 인스턴스 클래스와 데이터베이스 엔진 호환성에 따라 달라집니다.

데이터베이스 엔진 max_connections 기본값

Amazon Aurora MySQL

Aurora MySQL DB 인스턴스에 대한 최대 연결섹션을 참조하십시오.

Amazon Aurora PostgreSQL

Aurora PostgreSQL DB 인스턴스에 대한 최대 연결 섹션을 참조하세요.

작은 정보

애플리케이션이 연결을 자주 열고 닫거나, 수명이 긴 연결을 많이 열어 두는 경우, Amazon RDS 프록시를 사용하는 것이 좋습니다. RDS 프록시는 데이터베이스 연결을 효율적으로 안전하게 공유하기 위해 연결 풀링을 사용하는 완전관리형 고가용성 데이터베이스 프록시입니다. RDS 프록시에 대한 자세한 내용은 Aurora용 Amazon RDS 프록시 사용 섹션을 참조하세요.

쿼리 실행 계획 관리

Aurora PostgreSQL용 쿼리 계획 관리 기능을 사용하면 최적화 프로그램에서 실행할 계획을 제어할 수 있습니다. 자세한 내용은 Aurora PostgreSQL용 쿼리 실행 계획 관리 섹션을 참조하세요.