MyDumper와 MyLoader를 사용하여 대용량 데이터베이스를 HAQM Aurora MySQL로 마이그레이션하기

이 글은 AWS Database Blog에 게시된 Migrate very large databases to HAQM Aurora MySQL using MyDumper and MyLoader by Maria Ehsan 을 한국어로 번역 및 편집하였습니다.

HAQM Aurora는 클라우드를 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스입니다. Aurora는 기존 엔터프라이즈 데이터베이스의 성능과 가용성을 오픈소스 데이터베이스의 단순성 및 비용 효율성과 결합했습니다. Aurora는 클러스터당 최대 15개의 저지연 읽기 복제본을 지원하면서 HAQM Aurora 글로벌 데이터베이스, HAQM Aurora 서버리스 v2, HAQM Aurora 병렬 쿼리, 데이터베이스 복제와 같은 고급 기능을 제공합니다.

과거에는 대규모 MySQL 데이터베이스 Very Large MySQL DataBases (VLDB)가 기업 데이터 센터 내 특수 하드웨어에서 호스팅되어 인프라, 유지보수, 관리에 상당한 초기 투자가 필요했습니다. 완전한 MySQL 호환성, 고가용성 및 글로벌 규모의 성능을 달성하면서 관계형 데이터베이스를 현대화하려면 VLDB를 HAQM Aurora MySQL 호환 버전으로 마이그레이션하는 것을 고려해보세요.

이 글에서는 MyDumper와 MyLoader 도구를 사용하여 자체 관리형 MySQL 데이터베이스에서 HAQM Aurora MySQL 호환 버전으로 MySQL VLDB를 마이그레이션하는 방법을 설명합니다.

이 솔루션을 사용하여 HAQM RDS for MySQL로도 마이그레이션할 수 있습니다.

VLDB 마이그레이션의 도전 과제들

MySQL VLDB를 마이그레이션하기 위해서는 데이터베이스 크기, 데이터 일관성, 복잡성과 같은 여러 중요한 요소들을 신중하게 평가해야 합니다. MySQL VLDB를 마이그레이션하는 가장 일반적인 방법은 물리적 마이그레이션으로, 물리적 바이너리 데이터베이스 파일을 복사하고 네트워크를 통해 전송한 다음 대상 서버에서 복원하는 과정을 포함합니다. 하지만 수많은 객체와 대용량 데이터를 포함하는 VLDB의 경우, 이 방식은 백업과 복원 과정 모두를 크게 늦출 수 있습니다. 또한 물리적 백업 도구들은 백업을 더 작고 관리하기 쉬운 파일들로 나누는 유연성이 부족하여 마이그레이션을 더욱 복잡하게 만듭니다.

VLDB를 마이그레이션하는 또 다른 방식은 논리적 마이그레이션입니다. 이 방식은 데이터베이스 객체(스키마, 테이블, 데이터)를 SQL 문으로 내보내어 대상 시스템에서 실행함으로써 원본 데이터베이스 객체 정의와 테이블 데이터를 재현하는 것입니다. mysqldump와 mysqlpump 같은 전통적인 논리적 마이그레이션 도구들은 단일 스레드로 한 번에 하나의 테이블만 처리하기 때문에 VLDB에 최적화되어 있지 않아 마이그레이션 시간이 더 오래 걸립니다.

이 글에서는 멀티스레드 기능으로 인해 MySQL VLDB 마이그레이션에 더 적합한 오픈소스 도구인 MyDumper와 MyLoader를 사용한 논리적 마이그레이션을 설명합니다.

Solution overview

MyDumper와 MyLoader는 기존의 mysqldump와 mysqlpump 유틸리티에서 자주 발생하는 성능 제한을 해결하기 위해 설계된 오픈소스 MySQL 내보내기/가져오기 도구입니다. 이 도구들은 동시 데이터 내보내기 및 가져오기, 테이블별 덤프 파일 생성, 대용량 테이블의 작은 청크 단위 분할, 간소화된 구문 분석과 관리를 위한 별도의 데이터 및 메타데이터 파일, 가져오기 중 사용자 지정 가능한 트랜잭션 크기 등 다양한 기능을 제공합니다.

다음 다이어그램은 MyDumper와 MyLoader를 사용한 데이터 마이그레이션의 상위 단계를 보여줍니다.

MyDumper와 MyLoader를 사용한 마이그레이션은 다음 단계들을 포함합니다:

MyDumper를 사용하여 원본 MySQL 데이터베이스의 백업을 생성합니다.
백업 파일들을 HAQM Simple Storage Service(HAQM S3) 버킷에 업로드합니다. 백업 파일을 업로드하는 대체 방법들이 있습니다. 사용자 환경에 맞는 적절한 방법을 선택하려면 AWS Prescriptive Guidance 문서를 참조하세요.
MyLoader를 사용하여 백업 파일들을 복원합니다.
선택적으로, 최소한의 다운타임을 위해 MyDumper가 캡처한 바이너리 로그 위치를 사용하여 원본과 Aurora MySQL DB 클러스터 간의 복제를 설정합니다.

MyDumper와 MyLoader 방식 사용에 대한 단계별 지침은 ‘MyDumper와 MyLoader를 사용한 멀티스레드 마이그레이션‘을 참조하세요. 제한사항에 대한 자세한 내용은 ‘HAQM S3에서 HAQM RDS로 백업 파일 가져오기에 대한 제한사항 및 권장사항‘을 참조하세요.

다음 섹션에서는 VLDB 마이그레이션을 위한 MyDumper와 MyLoader의 성능과 효율성을 최적화하는 방법에 대해 설명하겠습니다.

MyDumper를 사용한 논리적 백업 최적화

MyDumper를 사용할 때 백업 프로세스를 최적화하는 것은 효율적이고 빠르며 신뢰할 수 있는 데이터 백업을 달성하는데 매우 중요합니다. MyDumper는 백업 전략을 최적화하고, 고유한 요구사항을 충족하며, 백업 효율성과 성능을 향상시킬 수 있는 다양한 기능을 제공합니다. 이 섹션에서는 백업 프로세스를 개선하기 위한 몇 가지 주요 기술들을 설명합니다.

백업을 위한 병렬 스레드

백업을 순차적으로 수행하는 대신, 여러 스레드를 사용하여 백업을 병렬로 실행할 수 있습니다. 이러한 동시 접근 방식은 특히 VLDB의 경우 성능과 효율성을 크게 향상시킵니다. 멀티스레드 방식을 사용하면 CPU 코어와 디스크 I/O를 포함한 시스템 리소스를 효율적으로 활용할 수 있습니다. 서버 CPU 코어당 하나의 스레드를 사용하는 것이 좋은 지침이 됩니다.

–-threads (-t)옵션을 통해 MyDumper는 백업 프로세스 중에 사용할 스레드 수를 지정하여 병렬 실행을 할 수 있습니다. 예를 들어, 8개의 스레드를 사용하여 백업을 수행하려면 다음 명령을 실행할 수 있습니다:

mydumper --host=localhost --user=root --password=mypassword --outputdir=path/to/backup --threads=8

대용량 테이블 백업을 더 작은 파일로 분할하기

VLDB는 종종 수백만 또는 수십억 개의 행을 포함하는 테이블을 가지고 있어, 관리, 전송 및 저장이 어려울 정도로 과도하게 큰 백업 파일이 생성될 수 있습니다. 이를 해결하기 위해 청크 크기나 행 수와 같은 요소를 고려하여 대용량 테이블 백업을 더 작고 관리하기 쉬운 청크로 분할할 수 있으며, 이는 관리성을 향상시키고 복원 시간을 줄일 수 있습니다.

MyDumper의 --chunk-filesize (-F) 옵션을 사용하면 지정된 파일 크기를 기준으로 큰 테이블을 별도의 파일로 분할할 수 있습니다. MyDumper에서 청크 파일 크기를 선택할 때는 병렬 복원 요구사항, 스토리지 제약, 네트워크 전송 고려사항, 백업 압축 필요성과 같은 요소들을 기반으로 하되, 다수의 작은 파일과 병렬 복원의 이점 사이의 균형도 고려해야 합니다.

예를 들어, 다음 명령은 큰 테이블을 약 1GB 크기의 파일들로 분할합니다:

mydumper --chunk-filesize=1G --outputdir=/path/to/backup --database=mydatabase

이러한 접근 방식은 단일 대용량 파일에 비해 병렬로 복원할 수 있고 네트워크를 통해 더 효율적으로 전송할 수 있는 관리 가능한 파일 세트를 생성합니다. 일반적으로 1-10GB 사이의 청크 크기가 잘 작동합니다. 1GB보다 작은 파일은 수많은 파일 관리로 인한 오버헤드가 발생할 수 있으며, 10GB보다 큰 파일은 데이터베이스에 부정적인 영향을 미칠 수 있습니다.

또는 --rows (-r) 옵션을 사용하여 SQL 덤프 파일의 각 INSERT 문에 포함될 행 수를 지정할 수 있습니다.

예시:

mydumper --rows=100000 --outputdir=/path/to/backup --database=mydatabase

이 예시에서 각 덤프 파일은 100,000행에 대한 INSERT 문을 포함합니다. 일반적으로 MyDumper의 --rows 옵션 값은 테이블 크기(큰 테이블의 경우 더 높은 값), 사용 가능한 메모리 리소스(제한된 메모리의 경우 더 낮은 값), 병렬 복원 요구사항(여러 스레드나 프로세스에 걸쳐 더 나은 작업량 분배를 위한 더 낮은 값) 사이의 균형을 고려하여 결정해야 합니다.

--chunk-filesize 옵션과 --rows 옵션은 동시에 사용할 수 없으며 둘 중 하나만 사용할 수 있습니다. 두 매개변수가 모두 제공되면 MyDumper는 --rows 옵션을 우선시합니다.

백업 파일 압축하기

압축을 활성화하면 백업 파일 크기가 줄어들어 저장 효율성이 향상되고 네트워크를 통한 파일 전송이 빨라집니다. 이는 특히 제한된 네트워크 대역폭이나 느린 연결 환경에서 다운타임을 최소화하고 성능을 향상시켜 더 빠른 백업 및 복원 작업을 가능하게 합니다. 하지만 압축은 추가적인 CPU 오버헤드를 발생시킵니다. 따라서 잠재적인 병목 현상을 완화하고 압축의 이점을 충분히 활용하기 위해서는 적절한 CPU 리소스가 사용 가능한지 확인하는 것이 중요합니다.

--compress (-c)를 통해 MyDumper는 파일을 압축하는 두 가지 옵션을 제공합니다: gzip과 zstd입니다. 권장되는 압축 방식은 zstd(Zstandard)인데, 이는 gzip에 비해 더 나은 압축률과 함께 더 빠른 압축 및 압축 해제 속도를 제공하기 때문입니다.

MyDumper에서 zstd 압축을 사용하려면 --compress 또는 -c 옵션 뒤에 zstd를 지정하면 됩니다.

예시:

mydumper --compress=zstd --outputdir=/path/to/backup --database=mydatabase

zstd 압축 알고리즘은 높은 압축 해제 속도를 유지하면서도 높은 압축률을 제공하므로, 압축 효율성과 성능의 균형을 맞춰야 하는 백업 시나리오에 적합합니다.

하지만 기존 도구나 시스템과의 특정 요구사항이나 호환성 문제가 있는 경우, --compress=gzip 또는 -c gzip을 지정하여 gzip 압축을 사용할 수 있습니다.

백업에 flat 파일 사용하기

SQL dumps와 비교하여 데이터 가져오기에 플랫 파일을 사용하면 프로세스 속도를 높일 수 있습니다. LOAD DATA LOCAL INFILE 문이나 MyLoader 가져오기 도구를 사용하여 플랫 파일을 데이터베이스에 로드할 수 있는데, 이는 텍스트 파일의 행을 고속으로 테이블에 효율적으로 읽어들입니다. 여러 플랫 파일을 생성함으로써 테이블을 병렬로 복원할 수 있어 성능이 더욱 향상됩니다.

플랫 파일을 생성하려면 MyDumper의 --load-data 옵션을 사용할 수 있습니다. MyDumper는 각 테이블에 대한 플랫 파일을 생성하여 데이터베이스로의 병렬 데이터 로딩을 지원합니다.

예를 들어, MyDumper를 사용하여 플랫 파일을 생성하려면 다음 명령을 실행할 수 있습니다:

mydumper --load-data --outputdir=/path/to/backup --database=mydatabase

또한 파일이 작성된 후 STDOUT을 통해 --stream을 사용하거나, 파일이 생성된 후 —exec을 사용하여 명령을 실행하는 옵션이 있습니다.
예시:

mydumper --stream --outputdir=/path/to/backup --database=mydatabase | mysql -u user -p mydatabase

이 명령은 플랫 파일 없이 데이터를 MySQL 데이터베이스로 직접 스트리밍합니다. 더 자세한 지침은 MyDumper 사용법을 참조하세요.

다음 예시 명령은 mysql, information_schema,performance_schema 를 제외한 MySQL 데이터베이스의 백업 파일을 생성합니다:

mydumper --host=<source_server_address> --user=<source_user> \
--password=<source_user_password> --directory=<output-dir> --rows=500000 \
--threads=16 --compress ZSTD --events --triggers --routines \
--regex ‘^(?!(mysql|information_schema|performance_schema))’ \
--logfile /<output_dir> /mydumper-logs.txt

지원되는 매개변수와 기본값의 전체 목록을 보려면 내장된 도움말을 사용하세요:

Mydumper --help

위 명령을 실행하면 MyDumper가 전역 변수를 설정하고 스레드를 생성합니다. 스레드가 동기화된 후에 일관된 백업 프로세스가 시작됩니다.

MyLoader를 사용한 논리적 백업 복원 최적화

MyLoader는 MySQL 데이터베이스로의 데이터 로딩을 단순화하고 가속화하는 오픈소스 MySQL 가져오기 유틸리티입니다. MyDumper의 보조 도구로 개발된 MyLoader는 MyDumper를 사용해 내보낸 데이터를 가져오는데 원활하고 효율적인 솔루션을 제공합니다.

멀티스레드 아키텍처를 통해 병렬 실행이 가능하여 리소스 활용을 극대화하고 데이터 가져오기 작업을 가속화합니다. MyLoader는 MyDumper로 생성된 SQL 파일, CSV 파일, TSV 파일을 포함한 다양한 데이터 형식을 지원하여 데이터 가져오기 소스의 유연성을 제공합니다. MyLoader는 데이터 가져오기 작업에 대한 트랜잭션 지원을 제공하여 데이터 일관성과 무결성을 보장합니다. 데이터 가져오기 작업을 트랜잭션 내에서 캡슐화함으로써 오류나 실패 발생 시 변경 사항을 롤백할 수 있어 데이터 손상의 위험을 최소화합니다.

백업 복원 시 MyLoader를 사용할 때 복원 프로세스를 최적화하는 것은 더 빠르고 효율적이며 신뢰할 수 있는 데이터 복구를 달성하는데 매우 중요합니다. MyLoader는 데이터 가져오기 프로세스를 조정할 수 있는 다양한 구성 옵션을 제공합니다. 이 섹션에서는 복원 프로세스를 최적화하기 위한 주요 기술들을 설명합니다.

복원을 위한 병렬 스레드

MyLoader는 여러 테이블이나 데이터 파일의 동시 처리를 가능하게 하여 여러 스레드에 걸쳐 작업량을 분산함으로써 복원 성능을 향상시킵니다. 이는 리소스 활용을 극대화하고 전체 복원 시간을 줄입니다. 그러나 성능 저하를 일으킬 수 있는 리소스 경쟁을 피하기 위해 사용 가능한 시스템 리소스를 고려하고 시스템 용량에 맞게 스레드 수의 균형을 맞추는 것이 중요합니다.

모범 사례는 vCPU 2개당 하나의 스레드를 할당하는 것입니다.

--threads (-t) 옵션을 사용하면 데이터 가져오기 프로세스 중에 사용할 스레드 수를 지정할 수 있어, 여러 데이터 파일이나 테이블을 동시에 처리함으로써 병렬 처리가 가능하고 가져오기 성능을 더욱 최적화할 수 있습니다. 다음은 4개의 스레드로 MyLoader를 사용하는 예시 명령입니다:

myloader --threads=4 --directory=/path/to/backup --database=mydatabase

배치 크기 최적화

배치 크기를 최적값으로 구성하면 트랜잭션 크기와 커밋 빈도 사이의 균형을 맞출 수 있습니다. 큰 배치 크기는 트랜잭션 오버헤드를 줄여 성능을 향상시킬 수 있지만 메모리 고갈이나 트랜잭션 로그 제한에 도달할 수 있습니다. 작은 배치 크기는 제한된 메모리나 특정 구성을 가진 시스템에 유용합니다.

MyLoader의 --queries-per-transaction (-q) 옵션의 최적값을 결정하기 위해서는 트랜잭션 크기, 사용 가능한 메모리, 데이터베이스 구성을 고려해야 합니다. 예를 들어, 64GB RAM을 가진 Aurora MySQL 데이터베이스의 경우 50,000이나 100,000과 같은 값으로 시작할 수 있습니다. 매우 큰 테이블이나 데이터셋의 경우, 과도한 메모리 문제를 피하기 위해 값을 줄이세요. 데이터 로딩 프로세스가 여전히 느리다면 메모리 사용량과 트랜잭션 로그 증가를 모니터링하면서 값을 증가시키세요.

배치 크기를 최적화하는 과정은 다음 단계들을 포함합니다:

데이터베이스 크기와 사용 가능한 메모리에 따라 적절한 값(1,000이나 10,000과 같은)으로 시작합니다.
성능, 메모리 사용량, 메모리 부족 문제나 트랜잭션 로그 크기 제한과 같은 잠재적 오류에 대해 복원 프로세스를 모니터링합니다.
복원 프로세스가 원활하게 실행되고 충분한 메모리 리소스가 있다면, 성능 향상 여부를 확인하기 위해 --queries-per-transaction 값을 점진적으로 증가(50,000이나 100,000과 같이)시킵니다.
메모리 부족 오류나 트랜잭션 로그 크기 제한에 도달하는 등의 문제가 발생하면 --queries-per-transaction 값을 줄입니다(100이나 1,000과 같이).
리소스 제한이나 오류를 발생시키지 않으면서 성능을 최대화하는 최적값을 찾을 때까지 2-4단계를 반복합니다.

인덱스 최적화

데이터베이스 테이블에 데이터를 로드할 때, 데이터베이스 관리 시스템(DBMS)은 데이터 자체뿐만 아니라 관련 인덱스도 유지해야 합니다. 인덱스는 특정 열이나 열 조합을 기반으로 데이터의 정렬된 표현을 생성하여 효율적인 데이터 검색을 용이하게 하는 데이터 구조입니다.

데이터 로딩 중 인덱스를 유지하는 오버헤드는 특히 대용량 테이블이나 복잡한 인덱스 구조를 가진 데이터베이스의 경우 상당할 수 있습니다. 이러한 오버헤드가 발생하는 이유는 DBMS가 새로운 데이터가 삽입될 때 인덱스를 업데이트해야 하며, 특히 비클러스터형 인덱스의 경우 리소스를 많이 사용하기 때문입니다.

MyLoader는 보조 인덱스 없이 데이터를 로드하는 옵션을 제공하여 이 문제를 해결합니다. 데이터 로딩 프로세스 중에 보조 인덱스의 생성이나 유지를 비활성화함으로써, MyLoader는 인덱스 관리와 관련된 오버헤드를 줄일 수 있습니다. DBMS가 데이터 삽입과 동시에 인덱스를 업데이트하는 데 리소스를 사용할 필요가 없기 때문에 이러한 최적화로 더 빠른 데이터 복원 시간을 달성할 수 있습니다.

그러나 대용량 테이블의 보조 인덱스를 재생성하는 것은 그 자체로 여러 과제가 있습니다. 인덱스 생성 프로세스는 리소스를 많이 사용하고 시간이 오래 걸리며 상당한 임시 디스크 공간이 필요합니다. 테이블 크기와 보조 인덱스의 복잡성에 따라 인덱스 생성에 몇 시간이 걸릴 수 있습니다.

복원 성능과 인덱스 가용성 사이의 균형을 분석하는 것이 중요합니다. 고려해야 할 요소로는 데이터셋 크기, 보조 인덱스 수, 인덱스 복잡성, 복원된 데이터 조회의 긴급성이 있습니다.

MyLoader의 --innodb-optimize-keys 옵션은 데이터 가져오기 프로세스 중 InnoDB 보조 인덱스의 생성을 최적화합니다. 활성화되면 MyLoader는 InnoDB 테이블에 데이터를 로드한 후까지 보조 인덱스 생성을 연기합니다. 이 옵션은 복원 성능을 향상시키기 때문에 VLDB 복원에 권장됩니다.

다음은 MyLoader에서 --innodb-optimize-keys 옵션을 사용하는 예시입니다:

myloader --directory=/path/to/backup --database=mydatabase --innodb-optimize-keys

트랜잭션 관리

행당 트랜잭션 수(--rows)와 같은 트랜잭션 관리 매개변수를 미세 조정하면 복원 프로세스 중 트랜잭션 동작을 최적화할 수 있습니다. 이 옵션은 효율적인 병렬 로딩을 위해 여러 트랜잭션으로 분할해야 하는 대용량 테이블에 특히 유용합니다. 트랜잭션당 행 수를 제한함으로써 리소스 활용을 최적화하고, 메모리 소비를 줄이며, 트랜잭션 처리량을 향상시킬 수 있습니다.

--rows (-r) 옵션을 사용하면 데이터 가져오기 중 트랜잭션당 처리되는 최대 행 수를 정의할 수 있습니다.

예를 들어, 1억 개의 행이 있는 대용량 테이블이 있고 여러 MyLoader 스레드를 사용하여 데이터를 병렬로 복원하려 한다고 가정해보겠습니다. 또한 병렬 복원 중 MyLoader 프로세스를 위해 전체 시스템 메모리의 25-50%를 할당할 수 있는 충분한 메모리가 있습니다. 이러한 할당은 다른 시스템 프로세스를 위한 충분한 메모리를 확보하고 과도한 스왑이나 메모리 부족 문제를 방지하는 데 도움이 됩니다. 이 시나리오에서는 성능과 메모리 사용량의 균형을 맞추면서도 병렬 복원을 가능하게 하기 위해 —rows 매개변수를 100,000이나 1,000,000과 같은 값으로 설정할 수 있습니다.

다음은 --rows 매개변수를 1,000,000으로 설정한 MyLoader 사용 예시 명령입니다:

myloader --directory=/path/to/backup --overwrite-tables --rows=1,000,000

이 명령은 MyLoader에게 INSERT 문당 최대 1,000,000행의 데이터를 로드하도록 지시합니다. 작은 테이블의 경우 --rows 값에 관계없이 전체 테이블을 단일 트랜잭션으로 로드할 수 있습니다. 예를 들어, 테이블에 1,000행만 있고 --rows=1,000,000으로 설정했다면, MyLoader는 1,000행을 포함하는 단일 INSERT 문을 생성할 것입니다.

메모리 사용량과 트랜잭션 처리량을 최적화하기 위해서는 테스트 환경에서 --rows 값을 실험해보는 것이 중요합니다.

리소스 할당

CPU, 메모리, 디스크 I/O와 같은 충분한 시스템 리소스를 할당하는 것은 복원 프로세스를 최적화하는데 매우 중요합니다. MyLoader가 적절한 리소스를 가지고 있는지 확인하면 데이터 복원 중 병목 현상을 최소화하고 성능을 극대화할 수 있습니다. 데이터베이스 인스턴스를 일시적으로 확장하면 더 원활한 가져오기 프로세스를 진행할 수 있습니다. 데이터 가져오기는 증가된 CPU 사용량, HAQM Elastic Block Store(HAQM EBS) 대역폭, 메모리와 같은 추가 리소스가 필요할 수 있습니다. 가져오기가 완료되면 인스턴스를 일반적인 구성으로 다시 축소할 수 있습니다.

다음 명령은 100,000행 단위로 데이터를 로드하고 트랜잭션당 1,500개의 삽입 쿼리를 그룹화하여 백업 파일을 Aurora MySQL 데이터베이스로 가져옵니다. 성능 향상을 위해 16개의 스레드를 사용하여 병렬 데이터 로딩을 수행하며, 더 나은 효율성을 위해 로드 중에 보조 인덱스 생성을 연기합니다.

myloader --host=<host_name> --user=<source_user> \
--password=<source_user_password> --directory=<output-dir> \
--queries-per-transaction=1500 --rows=100000 --threads=16 --innodb-optimize-keys--verbose=3 --logfile=/<output_dir>/MyLoader-logs.txt

옵션에 대한 최적값은 데이터베이스의 특성, 하드웨어 리소스, 복원 요구사항에 따라 달라질 수 있습니다. 일반적으로 다양한 값을 시험해보고 복원 성능과 메모리 사용량에 미치는 영향을 관찰하여 특정 사용 사례에 맞는 최적값을 찾는 것이 권장됩니다.

매개변수와 사용법의 전체 목록은 MyLoader 사용법을 참조하세요.

다음으로, mysqldump와 MyDumper 및 MyLoader 도구를 사용한 백업 및 복원 프로세스의 벤치마크 결과를 비교해보겠습니다.

벤치마크 결과

우리는 온프레미스 MySQL 데이터베이스를 백업하고 Aurora MySQL DB 클러스터로 복원하기 위해 mysqldump와 MyDumper/MyLoader를 사용했습니다. 벤치마킹 테스트는 64 vCPU, 512GB RAM, 45,000 프로비저닝된 IOPS, 8,000GB EBS 볼륨을 갖춘 r7a.16xlarge 타입의 HAQM Elastic Compute Cloud(HAQM EC2) 인스턴스를 사용하여 수행했습니다. 사용된 MySQL 버전은 8.0.36이었으며, 테스트에 사용된 데이터셋은 약 1.6TB 크기의 900개 객체로 구성되었습니다.

다양한 스레드 구성에서 mysqldump와 MyDumper의 백업 성능을 비교했습니다. MyDumper는 다양한 스레드 수에서 일관성과 효율성을 보여주며 모든 상황에서 mysqldump를 능가했습니다. 스레드 수가 16에서 32, 64로 증가함에 따라 MyDumper는 백업 속도에서 지속적으로 mysqldump보다 우수한 성능을 보였습니다. 이러한 결과는 적절한 백업 도구 선택의 중요성을 강조합니다. MyDumper는 멀티스레드, 효율적이고 고성능 데이터베이스 백업 작업을 찾는 조직들에게 중요한 선택지입니다.

다음 그래프에서는 다양한 스레드 수에 따른 MyDumper의 백업 완료 시간을 보여주기 위해 mysqldump 시간을 제외했습니다.

성능 결과는 작업량과 인스턴스 구성에 따라 달라질 수 있습니다.

다음으로, Aurora MySQL r7g.16xlarge 인스턴스에서 mysqldump와 MyLoader 도구를 사용하여 가져오기를 수행했습니다. MyDumper 결과와 유사하게, MyLoader는 비슷한 작업을 완료하는 데 75시간 이상 걸린 mysqldump와 비교하여 더 짧은 시간 안에 Aurora MySQL로 데이터베이스를 복원할 수 있었습니다.

다음 그래프에서는 다양한 스레드 수에 따른 MyLoader의 백업 완료 시간을 보여주기 위해 mysqldump 시간을 제외했습니다.

더 많은 스레드를 사용한 복원 프로세스가 실제로 더 느렸습니다. 이는 여러 스레드 사용이 작업량을 병렬화하는 데 도움이 될 수 있지만, 스레드 간의 증가된 리소스 경쟁과 조정으로 인해 오버헤드가 발생하기 때문입니다. 스레드 수가 주어진 작업량과 시스템 구성에 대한 최적 수준을 초과하면, 스레드 관리와 리소스 경쟁의 오버헤드가 병렬화의 이점을 상쇄하여 전체적인 성능이 저하될 수 있습니다.

특정 사용 사례에 대한 최적의 스레드 수를 결정하기 위해서는 다양한 스레드 구성으로 벤치마킹 테스트를 수행하고 CPU 사용률, 메모리 사용량, I/O 처리량과 같은 관련 성능 지표를 모니터링하는 것이 권장됩니다. 이러한 지표들을 분석함으로써 복원 프로세스가 성능과 리소스 효율성 사이의 원하는 균형을 달성하는 최적의 설정을 식별할 수 있습니다.

AWS DMS

MySQL과 호환되는 MariaDB와 같은 데이터베이스를 기본 내보내기/가져오기 도구를 사용하여 마이그레이션할 수 없는 경우, AWS Database Migration Service(AWS DMS)가 좋은 대안이 됩니다. AWS DMS는 데이터베이스를 AWS로 빠르고 안전하게 마이그레이션하는 데 도움이 되는 관리형 데이터베이스 마이그레이션 서비스입니다. 스키마 리매핑, 고급 필터링, 여러 데이터베이스 서버를 하나의 Aurora MySQL 클러스터로 병합하는 것을 포함한 다양한 데이터 마이그레이션 옵션을 사용할 수 있습니다. AWS DMS는 변경 데이터 캡처(CDC) 복제를 사용하여 최소한의 다운타임으로 간단한 마이그레이션을 가능하게 합니다. 자세한 내용은 ‘AWS DMS의 소스로 MySQL 호환 데이터베이스 사용하기‘를 참조하세요.

Conclusion

온프레미스 대용량 데이터베이스를 Aurora로 마이그레이션하는 것은 클라우드 기반 인프라의 이점을 활용하기 위한 중요한 결정입니다. 하지만 이러한 마이그레이션 프로세스는 본질적으로 시간이 많이 걸리고 복잡합니다. 데이터베이스의 크기와 복잡성을 평가하는 것부터 성능 요구사항과 규정 준수 기준을 지키는 것까지 다양한 요소들을 신중하게 고려해야 합니다. 이 글에서는 온프레미스 대용량 데이터베이스를 Aurora MySQL 호환 버전으로 마이그레이션하기 위한 MyDumper와 MyLoader 내보내기/가져오기 오픈소스 도구와 그 다양한 옵션들에 대해 설명했습니다.

MyDumper는 병렬 백업(--threads), 테이블 청크화(--chunk-filesize), 압축(--compress with zstd 권장), 더 빠른 복원을 위한 플랫 파일 생성(--load-data)을 지원합니다. MyLoader는 효율적인 복원을 위해 병렬 데이터 가져오기(--threads), 인덱스 최적화(--innodb-optimize-keys), 배치 크기 구성(--queries-per-transaction, --rows)을 제공합니다. 벤치마크 결과는 이 도구들이 mysqldump보다 성능이 우수하여 VLDB를 Aurora MySQL 호환 버전으로 마이그레이션하는 데 적합하다는 것을 보여줍니다.

AWS 기술 블로그