Amazon Aurora MySQL 스토리지 공간 활용도 이해하기

이 글은 AWS Database Delivery Blog에 게시된 Understanding Amazon Aurora MySQL storage space utilization by Raunak Gupta 을 한국어 번역 및 편집하였습니다.

Amazon Aurora는 고급 상용 데이터베이스의 성능, 확장성 및 가용성을 제공하는 동시에 오픈 소스 데이터베이스의 단순성과 비용 효율성을 제공하도록 설계된 완전관리형 관계형 데이터베이스 서비스입니다. Amazon Aurora MySQL-Compatible Edition은 MySQL과 상호 호환되므로 이미 MySQL 기술을 사용하고 있는 기업에게 매력적인 선택입니다.

Amazon Aurora MySQL의 스토리지는 기존 MySQL 데이터베이스와 다르게 관리됩니다. 이 게시물에서는 Amazon Aurora MySQL에서 사용할 수 있는 다양한 스토리지 유형, Aurora가 이러한 스토리지 유형을 사용하는 방법, 스토리지 사용량을 모니터링하는 방법을 살펴봅니다. 또한 Aurora 스토리지 청구액을 추정하는 데 사용할 수 있는 Aurora에 대한 몇 가지 데이터베이스 쿼리와 Amazon CloudWatch 지표를 살펴봅니다.

스토리지 유형

Aurora는 2가지 유형의 스토리지를 사용합니다.

클러스터 볼륨 스토리지 – Amazon Aurora MySQL은 AWS 리전의 3개 가용 영역에 분산된 공유 스토리지 계층을 사용하여 내구성, 내결함성, 데이터 중복성 및 고가용성을 제공합니다. InnoDB 테이블 및 인덱스, 데이터베이스 메타데이터, 함수와 프로시저 같은 저장 객체, 바이너리 로그 및 릴레이 로그를 비롯한 기타 영구 데이터를 저장합니다.
로컬 스토리지 – 클러스터의 각 Aurora MySQL 인스턴스에는 Amazon EBS (Amazon Elastic Block Store) 에서 지원하는 로컬 스토리지 볼륨이 장착되어 있습니다. 이러한 로컬 볼륨을 사용하여 비영구 임시 파일 및 비 InnoDB 임시 테이블을 저장하고, 대규모 데이터 세트를 정렬할 때 사용하는 파일, 오류, 감사 및 일반 로그와 같은 다양한 엔진 로그를 저장할 수 있습니다.자세한 내용은 Aurora MySQL의 임시 스토리지 한도 제한을 참조하십시오.

다음 섹션에서는 Aurora MySQL 클러스터의 스토리지 공간 사용량과 이 사용량을 확인하기 위한 데이터베이스 지표와 메타데이터를 논의합니다.

사용자 테이블, 인덱스 그리고 테이블스페이스

사용자 테이블과 인덱스는 관계형 데이터베이스 시스템의 영구 스토리지 공간 대부분을 차지합니다. MySQL에서 스토리지 엔진은 다양한 유형의 테이블에 대한 SQL 작업을 처리하는 구성 요소입니다. InnoDB는 MySQL에서 디폴트로 사용하는 범용 스토리지 엔진입니다. InnoDB는 Amazon Aurora MySQL에서 영구 데이터베이스 테이블 작업을 지원하는 유일한 스토리지 엔진입니다. 따라서 InnoDB 스토리지 엔진에 한해서 스토리지 공간 사용량에 대해 설명하겠습니다.

전통적인 MySQL에서 InnoDB 스토리지 엔진을 사용하는 테이블은 “.ibd” 파일 확장자로 표시된 테이블스페이스라는 데이터 파일에 저장됩니다. 이와 관련된 자세한 정보는 “InnoDB : 테이블스페이스 공간 관리”를 참조하십시오.

Amazon Aurora는 InnoDB 데이터 스토리지의 전통적인 파일 및 블록 기반 파일 시스템을 사용하지 않지만, 상위 개념은 동일합니다. Aurora는 InnoDB 테이블스페이스의 개념을 따르지만, 이러한 테이블스페이스는 블록 스토리지 디바이스의 파일이 아니라 Aurora 맞춤형으로 설계한 스토리지 볼륨에 있는 객체로 존재합니다.

InnoDB 스토리지 엔진은 디폴트로 file-per-table 테이블스페이스에 테이블을 저장합니다.. 이 동작은 innodb_file_per_table 파라미터에 의해 결정됩니다.

innodb_file_per_table=ON으로 설정시 엔진은 아래와 같이 동작합니다.

각 테이블에는 고유한 테이블스페이스가 있습니다. (전통적인 MySQL 용어로 .ibd 파일과 동일)
테이블스페이스가 제거(삭제)되면 비워진 데이터베이스 페이지가 스토리지 볼륨으로 반납되어 새 데이터에 재사용될 수 있습니다.
Aurora는 스토리지 볼륨 사용량을 줄이기 위해 시간이 지남에 따라 여유 페이지를 동적으로 회수요청할 수 있습니다. 이렇게 하면 볼륨에서 사용 가능한 공간이 늘어나고 스토리지 비용이 절감됩니다.

몇 가지 데이터베이스 작업으로 테이블스페이스를 삭제하고, Aurora가 회수할 수 있는 페이지들을 확보할 수 있습니다. 이 방법은 각 파티션이 별도의 테이블스페이스를 사용하기 때문에 테이블 파티션에도 적용됩니다.

테이블 또는 스키마를 DROP하면 관련된 테이블스페이스가 제거됩니다.
테이블을 TRUNCATE하면 기존의 테이블스페이스를 빈 테이블스페이스로 교체합니다. 이 작업은 기술적으로 테이블 DROP과 CREATE 수행하는 방법과 동일합니다.
OPTIMIZE 혹은 ALTER 명령어를 사용하여 테이블을 최적화하면 새로운 테이블스페이스를 만들고, 기존의 테이블스페이스를 삭제합니다.

이러한 작업을 수행한 후에 볼륨 크기가 즉시 줄어들지 않습니다. Aurora는 하루 최대 10TB의 속도로 백그라운드에서 여유 공간을 점진적으로 확보합니다. 동적 크기 조정에 대한 자세한 내용은 스토리지 조정을 참조하십시오.

InnoDB_file_per_table=OFF를 사용하면 동작은 다음과 같습니다.

테이블에는 고유한 개별 테이블스페이스가 없지만 테이블 데이터는 시스템 테이블스페이스 아래에 있습니다.
테이블을 DROP, TRUNCATE 혹은 OPTIMIZE하는 경우, 시스템 테이블스페이스 내에서 연관된 페이지가 비워지지만 시스템 테이블스페이스의 크기는 줄어들지 않습니다. 따라서 Aurora의 동적 볼륨 크기 조정으로는 해당 페이지가 차지하는 공간을 다시 확보할 수 없습니다.

테이블스페이스에서 사용하는 공간을 계산하려면 INFORMATION_SCHEMA.FILES 테이블을 사용할 수 있습니다. INFORMATION_SCHEMA.FILES 테이블은 file-per-table 테이블스페이스, 시스템 테이블스페이스, 글로벌 임시 테이블스페이스 및 undo 테이블스페이스를 비롯한 InnoDB 테이블스페이스 유형에 대한 메타데이터를 제공합니다. InnoDB 테이블스페이스에 대한 자세한 내용은 테이블스페이스를 참조하십시오.

다음 쿼리를 사용하여 테이블스페이스 이름을 사이즈와 함께 나열할 수 있습니다.

SELECT FILE_NAME, TABLESPACE_NAME, ROUND((TOTAL_EXTENTS * EXTENT_SIZE) / 1024 / 1024 / 1024, 4) AS SIZE_GB FROM INFORMATION_SCHEMA.FILES order by size_gb desc limit 10;

이 쿼리는 Amazon Aurora MySQL 버전 2 (MySQL 5.7과 호환) 및 Amazon Aurora MySQL 버전 3 (MySQL 8.0과 호환) 모두에서 작동합니다.

테이블스페이스는 비어 있는 경우에도 일정한 최소 크기가 있다는 점에 유의하십시오. innodb_file_per_table을 ON으로 설정하면 (행이 없는) 빈 테이블이나 파티션이라도 몇 메가바이트 정도의 적은 양의 스토리지를 차지합니다. 단일 Aurora 클러스터에 수천만 개의 테이블을 저장할 계획이 아니라면 이는 일반적으로 문제가 되지 않습니다. 가능하면 innodb_file_per_table의 기본 ON 설정을 사용하는 것을 권장합니다.

INFORMATION_SCHEMA.TABLES 테이블은 메타데이터를 읽기 전에 테이블을 ANALYZE하지 않을 경우 오래 전에 캐시된 통계가 포함되어 있으므로 INFORMATION_SCHEMA.TABLES 대신 (또는 추가로) INFORMATION_SCHEMA.FILES 테이블을 사용하여 테이블, 인덱스 및 스키마에서 사용하는 저장 공간을 계산하는 것도 고려해야 합니다. information_schema_stats_expiry 시스템 변수 (Aurora MySQL 버전 3에 적용) 는 캐시된 통계가 자동으로 만료되기 전의 기간을 정의합니다. 디폴트값은 86,400초 (24시간) 입니다. 지정된 테이블의 캐시된 값을 강제로 업데이트하려면 ANALYZE TABLE 명령을 사용한 다음 나중에 INFORMATION_SCHEMA.TABLES에서 통계를 확인하십시오. ANALYZE TABLE의 정확도는 innodb_stats_persistent 및 innodb_stats_transient_sample_pages 파라미터의 설정에 따라 달라진다는 점에 유의하십시오.

임시 테이블과 임시 테이블스페이스

임시 테이블스페이스에 대해 설명하기 전에 먼저 임시 테이블, 사용 시기, Amazon Aurora MySQL 버전 2와 버전 3 간의 임시 테이블 처리의 차이점을 이해해야 합니다.

Aurora MySQL에는 다음과 같은 두 가지 유형의 임시 테이블이 있습니다.

Internal (or implicit) temporary tables(내부, 암시적 임시 테이블) – 이런 테이블은 정렬(sort), 집계(aggregation), 파생 테이블(derived tables), 공통 테이블 표현식 (Common Table Expression, CTE) 과 같은 작업을 처리하기 위해 데이터베이스 엔진 자체에서 생성됩니다. 데이터베이스 사용자는 이러한 테이블을 직접 제어할 수 없습니다. MySQL 5.7의 내부 임시 테이블에 대한 자세한 내용은 MySQL에서의 내부 임시 테이블 사용을 참조하고, MySQL 8.0의 경우 MySQL에서의 내부 임시 테이블 사용을 참조하십시오.
User-created (or explicit) temporary tables(사용자가 만든, 명시적 임시 테이블) – 이런 테이블은 데이터베이스 클라이언트가 CREATE TEMORATORY TABLE 문을 사용하여 생성합니다. 명시적 임시 테이블은 해당 테이블을 생성한 데이터베이스 세션 (연결) 내에서만 볼 수 있으며, 세션이 닫히면 자동으로 삭제됩니다. 이런 테이블은 복잡한 SQL 프로세스를 실행하는 동안 중간 데이터를 저장하는 데 유용하며, 영구 저장할 필요가 없는 데이터에 사용합니다. MySQL 5.7의 이런 임시 테이블에 대한 자세한 내용은 CREATE TEMPORARY TABLE을 참조하고, MySQL 8.0의 경우 CREATE TEMPORARY TABLE을 참조하십시오.

Amazon Aurora MySQL 2에 임시 테이블을 저장하는 방법은 Aurora MySQL 3과 비교하여 차이가 있습니다. 이런 차이점 중 일부는 성능에 영향을 주지만, 다른 일부는 스토리지 사용에 영향을 미칩니다. 다음 섹션에서는 스토리지와 관련된 차이점을 간략하게 설명합니다. 자세한 내용은 MySQL 및 Amazon Aurora MySQL용 Amazon RDS의 임시 테이블 스토리지 엔진 사용을 참조하십시오.

Aurora version 2 (compatible with MySQL 5.7)

Aurora 버전 2에서는 내부 임시 테이블을 메모리에 보관하고 MEMORY 스토리지 엔진으로 처리할 수 있습니다. 메모리에 생성된 내부 임시 테이블이 너무 커지면 MySQL은 이를 자동으로 디스크 기반 테이블로 변환합니다. 어떤 경우에는 쿼리에 MEMORY 엔진에서 지원하지 않는 데이터 유형(예: BLOB 또는 TEXT)이 포함되는 경우와 같이 데이터베이스가 처음부터 바로 디스크 기반 테이블을 사용할 수 있습니다. 디스크 내부 임시 테이블의 스토리지 엔진은 Internal_tmp_disk_storage_engine 설정에 따라 InnoDB(기본값) 또는 MyISAM입니다.

MySQL 5.7의 InnoDB 임시 테이블의 경우 엔진은 단일 임시 테이블스페이스를 사용합니다. 이는 ibtmp1이라는 자동 확장 크기를 가진 공유 임시 테이블스페이스입니다. 자세한 내용은 임시 테이블스페이스를 참조하세요.

임시 테이블스페이스의 크기를 확인하려면 다음 쿼리를 사용하여 Information_Schema.Files 테이블을 쿼리할 수 있습니다.

SELECT FILE_NAME, 
    TABLESPACE_NAME, 
    ENGINE, 
    INITIAL_SIZE, 
    TOTAL_EXTENTS*EXTENT_SIZE AS TotalSizeBytes, 
    DATA_FREE, 
    MAXIMUM_SIZE FROM INFORMATION_SCHEMA.FILESWHERE TABLESPACE_NAME = 'innodb_temporary'

기본적으로 임시 테이블스페이스 데이터 파일은 자동으로 확장되며 디스크에 있는 임시 테이블을 수용하기 위해 필요에 따라 크기가 늘어납니다.

임시 테이블스페이스가 차지하는 디스크 공간을 회수하려면 Aurora 클러스터의 쓰기 인스턴스를 다시 시작하십시오. 쓰기 인스턴스를 다시 시작하면 임시 테이블스페이스 데이터 파일이 제거되고 다시 생성됩니다.

기본적으로 Aurora 버전 2에서는 InnoDB 온디스크 내부 임시 테이블(임시 테이블스페이스 내부)이 Aurora 클러스터 볼륨에 상주합니다. InnoDB가 아닌 임시 테이블은 Amazon Aurora MySQL 인스턴스에서 제공하는 로컬 스토리지에 있습니다.

Aurora version 3 (compatible with MySQL 8.0)

Aurora 버전 3에서는 내부 임시 테이블을 메모리에 보관하고 TempTable 스토리지 엔진(기본값) 또는 MEMORY 엔진에 의해 처리될 수 있습니다. TempTable 스토리지 엔진 제한 및 스토리지 할당 동작은 tmp_table_size, temptable_max_ram, temptable_use_mmap 및 temptable_max_mmap과 같은 구성 매개변수에 의해 제어됩니다. 메모리에 생성된 내부 임시 테이블이 이러한 매개변수에 의해 제어될 만큼 충분히 커지면 MySQL은 해당 테이블을 디스크에 있는 임시 테이블로 변환합니다. 3.x 이전의 Aurora MySQL 버전에서는 온디스크 내부 임시 테이블에 사용되는 스토리지 엔진을 InnoDB 또는 MyISAM으로 정의할 수 있습니다. Aurora MySQL 버전 3.x 이상에서는 디스크 내부 임시 테이블에만 InnoDB 스토리지 엔진을 사용합니다.

MySQL 8.0 및 Aurora MySQL 버전 3에서 InnoDB는 두 가지 유형의 임시 테이블스페이스를 사용합니다.

세션 임시 테이블스페이스 – 이 테이블스페이스는 InnoDB가 온디스크 내부 임시 테이블의 스토리지 엔진으로 구성된 경우 사용자가 생성한 임시 테이블과 온디스크 내부 임시 테이블을 저장합니다. 세션 임시 테이블스페이스는 임시 테이블스페이스 풀에서 세션에 할당됩니다. 세션 연결이 끊어지면 해당 임시 테이블스페이스가 잘리고 풀로 다시 해제됩니다. 이전 릴리스에서는 임시 테이블이 잘리거나 삭제된 후 운영 체제에 디스크 공간을 반환하지 않은 전역 임시 테이블스페이스(ibtmp1)에 임시 테이블이 생성되었습니다.
전역 임시 테이블스페이스 – 전역 임시 테이블스페이스(ibtmp1)는 이제 사용자가 생성한 임시 테이블에 대한 변경 사항에 대한 롤백 세그먼트를 저장합니다. 이 임시 테이블스페이스 데이터 파일은 자동으로 확장되며 필요에 따라 크기가 늘어납니다. 위에 나열된 동일한 쿼리(Aurora 버전 2의 경우)를 사용하여 이 전역 임시 테이블스페이스의 크기를 확인할 수 있습니다.

전역 임시 테이블스페이스 데이터 파일이 차지하는 디스크 공간을 회수하려면 Aurora 클러스터의 쓰기 인스턴스를 다시 시작해야 합니다. 쓰기 인스턴스를 다시 시작하면 전역 임시 테이블스페이스 데이터 파일이 제거되고 다시 생성됩니다.

Aurora 버전 3에서는 기본적으로 InnoDB 온디스크 내부 임시 테이블과 임시 테이블스페이스 파일이 Aurora 클러스터 볼륨에 있고, InnoDB가 아닌 임시 테이블과 파일은 Amazon Aurora MySQL 인스턴스에서 제공하는 로컬 스토리지에 있습니다.

바이너리 로그

바이너리 로그 (또는 binlog) 에는 테이블 생성 작업이나 테이블 데이터 변경과 같은 데이터베이스 변경 사항을 설명하는 이벤트가 포함됩니다.

Aurora MySQL에서 바이너리 로그는 다음과 같은 경우에 유용합니다.
Aurora MySQL에서 다른 MySQL 호환 데이터베이스로 복제
AWS Database Migration Service (AWS DMS) 와 같은 변경 데이터 캡처 (CDC) 도구를 사용하여 Aurora MySQL에서 비 MySQL 데이터베이스로 복제
Aurora와 다운스트림 메시지/이벤트 기반 시스템 간의 통합 설정과 같은 다양한 목적으로 Aurora MySQL에서 CDC 레코드를 추출

Amazon Aurora MySQL에서는 기본적으로 바이너리 로깅이 비활성화되어 있습니다 (log_bin = OFF). 클러스터 레벨 파라미터 그룹에서 binlog_format을 MIXED, STATEMENT 또는 ROW로 설정하여 바이너리 로그를 활성화할 수 있습니다.

클러스터에서 binlog가 활성화된 경우 클러스터 볼륨에서 binlog가 소비하는 공간은 다음을 포함한 다양한 요인에 따라 달라집니다.

구성된 바이너리 로그 보존 기간입니다.
테이블 생성 작업이나 테이블 데이터 변경 등의 변경으로 인해 생성된 변경 볼륨입니다.
경우에 따라 연결된 바이너리 로그 복제본 문제로 인해 클러스터 볼륨에서 binlog 공간이 늘어날 수 있습니다. 예를 들어, binlog 기반 교차 리전 읽기 전용 복제본을 사용하고 어떤 이유로든 읽기 전용 복제본이 binlog 적용에 뒤처지는 경우 Aurora는 소스에 필요한 것보다 임시로 더 많은 binlog를 저장해야 할 수 있습니다.

mysql.rds_show_configuration 저장 프로시저를 실행하여 바이너리 로그 보존 설정을 확인할 수 있습니다.

CALL mysql.rds_show_configuration;

보존 기간은 시간 단위로 표시됩니다. 필요한 경우 mysql.rds_set_configuration 저장 프로시저를 사용하여 binlog 보존 기간을 변경할 수 있습니다. 다음 예에서는 바이너리 로그의 보존 기간을 24시간으로 설정합니다.

CALL mysql.rds_set_configuration('binlog retention hours', 24);

기본 인스턴스에서 SHOW BINARY LOGS 명령을 실행하면 각 로그의 크기와 함께 존재하는 바이너리 로그를 볼 수 있습니다.

SHOW BINARY LOGS

Amazon Aurora MySQL의 클러스터 수준에서 다음 CloudWatch 지표를 사용하여 바이너리 로그 수와 크기를 모니터링할 수 있습니다.

SumBinaryLogSize – 바이너리 로그의 총 크기(바이트)
NumBinaryLogFiles – 클러스터에 저장된 바이너리 로그 수

릴레이 로그

MySQL의 바이너리 로그 복제 중에 복제 서버의 I/O 수신자 스레드는 기본 서버에 연결하고 기본 서버에서 바이너리 로그 이벤트를 읽고 이를 릴레이 로그라고 하는 로컬 로그에 복사합니다. SQL 적용자 스레드는 릴레이 로그에서 이벤트를 읽고 최대한 빠르게 적용합니다. 즉, 릴레이 로그는 복제본에 적용되기를 기다리는 바이너리 로그의 복사본입니다.

SQL 스레드가 특정 릴레이 로그 파일의 이벤트를 처리하면 해당 파일이 더 이상 필요하지 않으므로 자동으로 삭제됩니다.

어떤 경우에는 Aurora 클러스터가 활발하게 복제되지 않는 경우에도 릴레이 로그가 스토리지 공간을 차지하는 것을 볼 수 있습니다. 예를 들어, 과거에 Aurora 클러스터를 다른 MySQL 서버의 복제본으로 구성했지만 완전히 재설정하지 않고 복제를 중지했을 수 있습니다. 이러한 경우 스토리지 공간을 차지하는 Aurora MySQL 클러스터 볼륨에 여전히 릴레이 로그가 있을 수 있습니다.

이를 확인하려면 SHOW REPLICA STATUS 명령(또는 5.7 호환 버전에서는 SHOW SLAVE STATUS)을 실행하여 복제가 활발하게 실행되고 있지 않더라도 구성되어 있는지 확인할 수 있습니다. 명령이 빈 출력을 생성하는 경우 복제가 구성되지 않았음을 의미하므로 클러스터에 릴레이 로그가 포함되어서는 안 됩니다.

일부 복제 구성(다음 예 참조) 및 기타 복제 상태 카운터를 표시하는 출력이 표시되면 복제가 중지되었을 수 있지만 복제 메타데이터가 여전히 존재하며 클러스터에 계속 사용 중인 Aurora 클러스터 볼륨의 공간에 릴레이 로그가 포함될 수 있음을 의미합니다.

*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.136.6.91
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysqld@sam_prd2-bin.000712
Read_Master_Log_Pos: 418325560
Relay_Log_File: relaylog.066015
Relay_Log_Pos: 4
Relay_Master_Log_File: mysqld@sam_prd2-bin.000712
Slave_IO_Running: No
Slave_SQL_Running: No
....
**********************************************************

안타깝게도 MySQL은 릴레이 로그 파일에 대한 세부적인 메타데이터를 제공하지 않기 때문에 클러스터 내부에 저장된 릴레이 로그의 정확한 개수나 크기를 확인할 수 없습니다.

복제 메타데이터를 지우고 릴레이 로그 파일을 삭제하려면 Aurora 클러스터의 라이터 인스턴스에서 다음 저장 프로시저를 호출하면 됩니다.

Amazon Aurora MySQL 버전 2의 경우 mysql.rds_reset_external_master 프로시저를 사용하세요.
Amazon Aurora MySQL 버전 3의 경우 mysql.rds_reset_external_source 프로시저를 사용하세요.

Aurora 클론

Aurora 클론은 중복된 Aurora 클러스터 볼륨, 데이터를 생성하는 빠르고 비용 효율적인 방법입니다.

Aurora는 쓰기 중 복사 프로토콜을 사용하여 클러스터 클론 복제본을 생성합니다. 복제본이 생성되면 Aurora는 새로운 독립형 클러스터 스토리지 볼륨을 생성하지만 모든 원본 데이터 페이지를 새 볼륨에 복사하지는 않습니다. 대신 페이지가 수정되지 않은 상태로 유지되는 한 복제된 페이지는 단순히 원본 페이지에 대한 포인터일 뿐입니다. 페이지가 한쪽에서 수정되면 Aurora는 복제본에 해당 페이지의 복사본을 생성하므로 ‘기록 중 복사’라는 용어가 사용됩니다. 이렇게 하면 스냅샷 복원, PITR(지정 시점 복원) 또는 논리적 덤프 및 복원과 같은 다른 기술을 사용하여 데이터를 물리적으로 복사하는 것보다 클론을 더 빠르게 생성하고 공간 효율성을 높일 수 있습니다. 또한 클론 체인(클론의 클론)을 생성할 수도 있고, 여러 AWS 계정에 걸쳐 클론 클러스터를 생성할 수도 있습니다.

클론은 볼륨을 인스턴스화하기 위해 소량의 추가 공간을 사용합니다. 이러한 작은 오버헤드 외에 소스 또는 복제된 클러스터가 변경된 경우에만 추가 스토리지가 할당됩니다. 클론은 데이터 복제 및 성능 측면에서 원본 클러스터 및 서로 독립적입니다. Aurora는 이러한 엔터티 간에 데이터를 자동으로 복제하지 않으며 복제본(또는 원본 클러스터)의 워크로드는 서로 영향을 미치지 않습니다.

복제된 클러스터 스토리지 볼륨은 원래 소스 볼륨과 페이지의 대부분을 공유하므로 해당 페이지는 소스 볼륨의 VolumeBytesUsed 지표에만 포함됩니다. 복제된 클러스터에서 VolumeBytesUsed 지표는 처음에는 0에 가깝습니다. 이 게시물의 뒷부분에서 측정항목에 대해 논의합니다. 클론 볼륨의 VolumeBytesUsed 지표에는 클론이 생성된 후 발생한 데이터 변경으로 인해 할당된 추가 스토리지만 포함됩니다.

소스 클러스터가 삭제되면 여전히 공유된 페이지는 나머지 활성(라이브) 클론에 요금이 청구됩니다. 이는 복제된 클러스터에 대한 실질적인 쓰기 없이도 VolumeBytesUsed가 크게 증가할 수 있음을 의미합니다.

해당 체인에서 추가 클론을 삭제하거나 생성하면 나머지 클론에 페이지가 다시 재배포됩니다. 자세한 내용은 Aurora 복제 작동 방식을 참조하세요.

따라서 클러스터의 VolumeBytesUsed와 실제 테이블스페이스 크기 사이에 큰 차이가 있는 경우 클러스터가 복제 체인의 일부인지 확인하는 것이 좋습니다.

CloudWatch 지표

로컬 스토리지와 클러스터 볼륨 스토리지 사용량을 분석할 때 유용한 CloudWatch 지표는 아래와 같습니다.

FreeLocalStorage – 이 지표를 사용하면 각 Aurora 인스턴스와 연결된 로컬 스토리지 공간을 모니터링할 수 있습니다. 로컬 스토리지의 양은 인스턴스 클래스에 따라 달라지므로 로컬 스토리지가 더 필요한 경우 더 큰 인스턴스를 사용해야 합니다. 자세한 내용은 Aurora MySQL 호환 로컬 스토리지에 저장되는 내용과 로컬 스토리지 문제를 해결하는 방법을 참조하십시오.
VolumeBytesUsed – 이 지표는 Aurora DB 클러스터에서 요금이 발생하고 있는 스토리지 사용량을 표시합니다. 앞서 설명한 것처럼 클러스터 볼륨 사용량에는 InnoDB 테이블스페이스, 바이너리 로그, 릴레이 로그가 포함됩니다. 참고로, 이 청구 지표는 기록 중 복사(copy-on-write) 복제를 사용하는 클러스터에서는 실제로 존재하는 데이터의 양과 차이가 있을 수 있습니다.
AuroraVolumeBytesLeftTotal – 이 지표는 최대 128TB 중 클러스터 볼륨에 사용 가능한 남은 공간을 보여줍니다. 클러스터 볼륨이 커지면 이 값은 감소합니다. 이 값이 0에 도달하면 클러스터는 공간 부족 오류를 보고합니다. 참고로 이 지표에는 내부 정리에 사용되는 스토리지와 스토리지 요금이 발생하지는 않는 기타 할당이 포함됩니다. 따라서 이 지표 값은 “128TB에서 사용된 볼륨바이트를 뺀 값”과 정확히 같지 않습니다.

이 지표에 대한 자세한 사항은 “Amazon Aurora에 대한 Amazon CloudWatch 지표”를 참조하십시오.

결론

이 포스트에서는 Aurora MySQL 클러스터 볼륨의 사용량에 대한 일반적인 이해와 볼륨 사용량에 대한 근본 원인을 찾거나 스토리지 사용 요금을 이해를 돕는 쿼리들과 환경 설정에 대해서 알아보았습니다. AWS Aurora MySQL에 대해서 좀 더 알아보시려면 “Amazon Aurora MySQL 작업”을, Aurora 스토리지 볼륨 관련 정보는 “Aurora 스토리지 엔진” 블로그를 참조하시기 바랍니다.

AWS 기술 블로그