Amazon Aurora MySQL 버전 3의 바이너리 로깅을 이용한 최적화

이 글은 AWS Database Delivery Blog에 Marc Reilly님이 게시한 Binary logging optimizations in Amazon Aurora MySQL version 3 원문 글을 한국어로 번역 및 편집하였습니다.

MySQL의 바이너리 로그(binlog)는 ‘이벤트’라는 논리적 형식으로 MySQL 서버의 데이터베이스 수정 사항을 캡처하는 데 사용됩니다. 이러한 데이터베이스 수정에는 DCL 문(예: CREATE USER 또는 GRANT), DDL 문(CREATE TABLE, ALTER TABLE) 및 DML 문(INSERT, UPDATE, DELETE)이 포함될 수 있습니다. MySQL에서 이러한 수정 사항이 커밋되면 서버는 2단계 커밋(2PC)을 사용하여 스토리지 엔진 커밋을 통해 트랜잭션의 바이너리 로그 이벤트를 원자적으로 유지합니다. 이러한 ACID(원자성, 일관성, 격리성 및 내구성) 준수 보장과 데이터베이스 변경 사항 로깅을 통해 MySQL은 이 로그를 사용하여 다른 MySQL 서버(읽기 복제본)에 대한 논리적 복제를 용이하게 하고 데이터베이스 복구 프로세스를 지원하며 다음과 같은 기능을 제공합니다. 전체 데이터베이스 백업에 논리적 변경 사항을 다시 적용하여 DB 인스턴스를 특정 시점으로 복원합니다.

그러나 이 ACID 규정 준수를 시행하려면 쓰기 증폭, 데이터베이스 복구 시간 연장, 높은 동시성에서 잠금 경합 등의 대가를 치르게 될 수 있습니다. PITR(특정 시점 복원) 및 읽기 전용 복제본을 사용한 수평 확장의 경우 바이너리 로그가 데이터베이스 서버에서 논리적으로 재생되어야 합니다. 이로 인해 쓰기 작업량이 많은 경우 지연이 발생하고 RTO(복구 시간 목표)가 증가할 수 있습니다. 예를 들어 DDL 문을 읽기 전용 복제본이나 대기 복제본으로 복제해야 하는 경우 완료될 때까지 다른 로그 이벤트 적용이 차단될 수 있습니다.

2015년 Amazon Aurora MySQL 호환 에디션이 출시되면서 고객은 이러한 요구 사항을 충족하기 위해 더 이상 바이너리 로깅에 의존할 필요가 없습니다. 맞춤형 Amazon Aurora 스토리지 아키텍처에서는 복제, 복구 및 PITR이 모두 바이너리 로깅을 활성화할 필요 없이 스토리지 계층에서 투명하게 처리됩니다. 이러한 혁신을 통해 복구 시간이나 ACID 규정 준수를 희생하지 않으면서도 가용 영역과 AWS 리전 전반에 걸쳐 밀리초의 복제 지연을 통해 고도의 동시 워크로드를 초당 수십만 쓰기로 확장할 수 있습니다.

이 게시물에서는 Amazon Aurora MySQL의 바이너리 로깅 사용 사례, 수년에 걸쳐 Amazon Aurora MySQL에 추가된 향상된 바이너리 로깅 기능, MySQL 기본 바이너리 로깅 기능에 대한 추가 지원에 대해 설명합니다.

바이너리 로깅 사용 사례

고가용성 또는 수평적 확장성을 위해 Amazon Aurora MySQL에서 바이너리 로깅이 필요하지 않음에도 불구하고 다음과 같이 이 데이터베이스 변경 로그를 활용할 수 있는 사용 사례가 있습니다.

• Amazon Aurora MySQL로 마이그레이션할 때 바이너리 로그 복제를 활용하면 Amazon Aurora MySQL을 MySQL 데이터베이스 인스턴스의 바이너리 로그 읽기 복제본으로 구성하여 마이그레이션 중단 시간을 최소화할 수 있습니다. 자세한 내용은 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션에서 확인할 수 있습니다.
• Amazon RDS 블루/그린 배포를 사용하면 논리적 바이너리 로그 복제를 사용하여 메이저 버전 업그레이드와 같은 프로덕션 시스템의 가동 중지 시간 변경을 최소화할 수 있습니다.
• Amazon Redshift 또는 Maxwell 및 Debezium과 같은 도구와 Amazon Aurora 제로 ETL 통합을 사용하여 Aurora MySQL 데이터베이스 클러스터에서 캐시, 데이터 웨어하우스 또는 데이터레이크와 같은 다른 소스로 데이터베이스 변경 사항을 스트리밍할 수 있습니다.
• Spirit 및 gh-ost와 같은 온라인 스키마 변경 도구를 사용하면 애플리케이션에 미치는 영향을 최소화하면서 스키마 변경 사항을 프로덕션 시스템에 배포할 수 있습니다.

향상된 바이너리 로그 기능

Amazon Aurora MySQL 팀은 지난 수년간의 고객 사용 사례와 피드백을 바탕으로 추가 커뮤니티 기능 지원을 통해 바이너리 로그 기능을 추가하고 Amazon Aurora MySQL의 바이너리 로깅 구현을 최적화하여 확장성이 뛰어난 Aurora 스토리지의 분산 기능을 활용해 왔습니다. 다음 각 릴리스에서는 네 가지 주요 영역에서 바이너리 로깅의 효율성과 성능을 향상시키기 위해 점진적인 변경이 이루어졌습니다.

바이너리 로그 복제 소비자(Consumer) 스레드

Amazon Aurora MySQL 버전 2.10에서는 바이너리 로그 I/O 캐시를 도입했습니다. 바이너리 로그 I/O 캐시는 쓰기 DB 인스턴스의 순환 캐시에 최신 바이너리 로그 변경 이벤트를 보관하여 Aurora 스토리지 계층의 읽기 I/O를 최소화하는 것을 목표로 합니다. I/O 대기 시간의 이러한 개선은 복제 소비자 스레드가 변경 로그 이벤트를 가져올 수 있는 속도를 향상시키고 특히 앞단의 트랜잭션과 바이너리 로그 소비자가 활성 바이너리 로그 파일에 대한 잠금을 놓고 경쟁할 수 있는 동시 쓰기 워크로드에서 잠금 경합을 줄이는 데 도움이 됩니다. 이러한 개선 사항에 대한 자세한 내용은 Amazon Aurora MySQL에 binlog I/O 캐시를 도입하여 binlog 성능 향상을 참조하십시오.

앞서 언급했듯이 이진 로깅의 일반적인 사용 사례 중 하나는 Aurora MySQL 데이터베이스 클러스터에서 데이터 웨어하우스와 같은 다른 소스로 데이터베이스 변경 사항을 스트리밍하는 것입니다. Amazon Aurora MySQL 버전 3.05에서는 Amazon Redshift와 Amazon Aurora 제로 ETL 통합을 도입했습니다. Amazon Aurora 제로 ETL과 Amazon Redshift의 통합을 통해 페타바이트 규모의 트랜잭션 데이터에 대해 Amazon Redshift를 사용하여 거의 실시간 분석 및 기계 학습(ML)이 가능합니다. 트랜잭션 데이터가 Aurora에 기록된 지 몇 초 만에 제로 ETL은 Amazon Redshift에서 데이터를 사용할 수 있게 하므로 ETL(추출, 변환 및 로드) 작업을 수행하는 복잡한 데이터 파이프라인을 구축하고 유지 관리할 필요가 없습니다. Amazon Redshift와 Amazon Aurora 제로 ETL 통합을 사용하면 더 이상 Maxwell 및 Debezium과 같은 도구를 사용하여 변경 데이터 캡처 인프라를 설정하고 구성할 필요가 없습니다. Amazon Aurora MySQL은 변경 데이터 캡처 인프라를 자동으로 설정, 구성 및 관리하여 변경 사항을 Aurora 스토리지 계층에서 Amazon Redshift 데이터 웨어하우스로 직접 스트리밍합니다.

바이너리 로그 복제 적용자(Applier) 스레드

Amazon Aurora MySQL 버전 3.05에서는 Amazon Aurora MySQL 바이너리 로그 복제본을 위한 인 메모리 릴레이 로그 캐시도 도입했습니다. 이러한 개선을 통해 릴레이 로그 캐시를 활성화하지 않은 데이터베이스 클러스터에 비해 이진 로그 복제 처리량을 최대 40% 늘릴 수 있습니다. 이 향상된 기능은 단일 스레드 바이너리 로그 복제를 사용하거나 GTID 자동 위치 지정이 활성화된 다중 스레드 복제를 사용할 때 자동으로 활성화됩니다.

Amazon Aurora MySQL 버전 3.06 이상에서는 두 개 이상의 보조 인덱스가 있는 대규모 테이블의 트랜잭션을 복제할 때 바이너리 로그 복제본의 성능을 향상시키는 최적화 기능을 도입했습니다. 이 기능은 복제 적용자 스레드에 이미 사용 가능한 Replica_parallel_workers를 보완하는 Aurora MySQL 바이너리 로그 복제본에 보조 인덱스 변경 사항을 병렬로 적용하기 위한 백그라운드 스레드 풀을 도입합니다. 이 최적화 기능 활성에 대한 자세한 내용은 바이너리 로그 복제 최적화를 참조하세요.

DML 처리량 및 대기 시간

바이너리 로그 커밋 프로세스를 최적화하기 위해 MySQL은 이벤트 순서에 영향을 주지 않으면서 바이너리 로그에 변경 사항을 더 효율적으로 기록하려는 시도로 바이너리 로그 그룹 커밋과 같은 여러 가지 최적화를 구현했습니다. 그러나 이 동기화 지점으로 인해 쓰기 처리량 워크로드가 높은 DB 인스턴스에 경합 영역이 발생할 수 있습니다.

Amazon Aurora MySQL 버전 3.03.1에서는 Amazon Aurora MySQL 향상된 이진 로그(향상된 이진 로그)를 도입했습니다. Amazon Aurora MySQL의 향상된 이진 로그를 사용하면 데이터베이스 엔진이 커밋 순서나 커밋된 트랜잭션의 내구성을 희생하지 않고도 Aurora 분산 스토리지를 최대한 활용하여 이진 로그 변경 이벤트의 순서를 Aurora 스토리지 계층으로 오프로드함으로써 이러한 경합을 줄일 수 있습니다. Amazon Aurora MySQL 향상된 이진 로그(binlog) 소개에 설명된 테스트를 기반으로 이러한 최적화는 향상된 이진 로깅을 활성화하지 않은 데이터베이스 클러스터에 비해 동시 쓰기 워크로드에서 최대 40%의 처리량 증가를 제공하는 데 도움이 되었습니다.

바이너리 로그 복구

트랜잭션 커밋 시 바이너리 로그 이벤트는 활성 바이너리 로그 파일에 올바른 커밋 순서로 기록되고 지속 가능해야 합니다. 대량의 바이너리 로그 데이터를 생성하는 트랜잭션의 경우 시작 중 바이너리 로그 복구 프로세스에는 전체 바이너리 로그 파일을 스캔하여 트랜잭션에 대한 메타데이터를 수집하고 이를 사용하여 스토리지 엔진(InnoDB) 데이터와의 일관성을 보장하는 작업이 포함됩니다. 바이너리 로그 파일 크기가 큰 경우 몇 분 이상 걸릴 수 있으며 이는 바이너리 로그 복구 시간에 비례적으로 영향을 미칩니다.

위에서 설명한 Amazon Aurora MySQL의 향상된 바이너리 로그는 MySQL 바이너리 로그 복구 프로세스의 복구 시간도 향상시킵니다. 향상된 바이너리 로그를 사용하면 Aurora 분산 스토리지 계층의 최적화를 통해 바이너리 로그 파일의 시간 소모적인 스캔을 피할 수 있습니다.

이러한 개선으로 인해 바이너리 로그 복구 시간은 최대 몇 분에서 몇 초까지 최대 99%까지 단축될 수 있습니다. 다음 표에는 이러한 복구 시간이 요약되어 있습니다.

자세한 내용은 Amazon Aurora MySQL 향상된 바이너리 로그(binlog) 소개를 참조하십시오.

추가 MySQL 지원

이미 논의한 Amazon Aurora MySQL 최적화 외에도 Aurora MySQL 버전 1 및 2에서 이미 사용할 수 있었던 기능 외에 기본 MySQL 커뮤니티 기능에 대한 지원도 추가되었습니다.

Amazon Aurora MySQL 버전 3.01.0에는 바이너리 로그 복제 필터에 대한 지원이 추가되었습니다. 복제 필터를 사용하면 바이너리 로그 파일에 기록되는 내용과 바이너리 로그 읽기 전용 복제본에 적용되는 내용을 구성할 수 있습니다. 이 기능은 특정 테이블이나 데이터베이스를 선택적으로 복제하여 복제본 DB 인스턴스를 읽는 등의 사용 사례에 유용할 수 있습니다. 복제 필터에 대한 자세한 내용은 Aurora MySQL을 사용하여 복제 필터 구성을 참조하십시오.

MySQL 8에 동적 권한이 추가되면서 SESSION_VARIABLES_ADMIN 데이터베이스 권한에서 일부 제한된 세션 변수를 사용할 수 있게 되었습니다. Amazon Aurora MySQL 버전 3에서 이 권한을 가진 사용자는 세션 수준에서 다음을 수행할 수 있습니다.

• 이제 sql_log_bin을 수정할 수 있습니다. 이는 보관 작업이나 바이너리 로그 소비자에게 복제하고 싶지 않은 DDL 문과 같이 바이너리 로그에 기록하고 싶지 않은 작업을 수행하려는 경우에 유용합니다. Amazon Aurora MySQL 버전 2에서는 기본적으로 sql_log_bin을 설정할 수 없지만 버전 2.12에서는 설정 할 수 있도록 mysql.rds_disable_session_binlog 및 mysql.rds_enable_session_binlog 저장 프로시저가 추가되었습니다.
• 또한 세션 수준에서 binlog_format을 수정할 수 있습니다. 세 가지 바이너리 로그 형식이 있습니다. ROW, MIXED 및 STATEMENT. 대부분의 사용 사례에서는 MySQL 서버에서 행이 변경될 때마다 변경 이벤트를 기록하는 ROW 기반 로깅이 권장됩니다. 그러나 보관 또는 데이터 삭제 중에 대량 UPDATE/DELETE 작업을 수행하는 경우와 같이 일부 경우에는 이로 인해 팽창이 발생할 수 있습니다. 또 다른 널리 사용되는 사용 사례는 binlog_format을 구문으로 설정해야 하는 pt-table-checksum과 같은 오픈 소스 도구를 사용하는 것입니다. binlog_format을 사용하면 이제 이러한 작업에 대한 세션 수준에서 binlog 형식을 기본적으로 변경할 수 있습니다. Amazon Aurora MySQL 버전 2에서는 기본적으로 세션 수준에서 binlog_format을 설정할 수 없지만, 버전 2.12에서는 설정 할 수 있도록 mysql.rds_set_session_binlog_format 저장 프로시저가 추가되었습니다.

Amazon Aurora MySQL 버전 3.04에는 mysql.rds_gtid_purged 저장 프로시저가 추가되었습니다. gtid_purged 시스템 변수는 서버에서 커밋되었지만 서버의 바이너리 로그 파일에는 존재하지 않는 모든 트랜잭션의 GTID로 구성된 GTID 세트입니다. 이는 두 개의 MySQL 데이터베이스 서버 간에 바이너리 로그 복제 자동 위치 지정을 구성할 때 일반적으로 사용되므로 사용자는 복제를 보다 쉽게 구성할 수 있습니다. MySQL의 GTID에 대한 자세한 내용은 전역 트랜잭션 식별자(Global Transaction Identifier)를 사용한 복제를 참조하세요.

결론

이 게시물에서는 지난 몇 년 동안 Amazon Aurora MySQL의 바이너리 로깅에 대한 몇 가지 최적화 및 개선 사항에 대해 논의했습니다. 이러한 점진적인 변화를 통해 고객은 변경 데이터를 활용하여 새로운 사용 사례를 활용하고 데이터베이스 성능과 복구 시간을 향상시킬 수 있었습니다.

새로운 Amazon Aurora MySQL 릴리스 및 기능에 대해 자세히 알아보려면 릴리스 노트를 참조하고 RSS 피드를 구독하여 새 릴리스에 대한 알림을 받으십시오.

Amazon Aurora MySQL의 이진 로깅에 대한 자세한 내용은 Aurora MySQL 이진 로깅 구성을 참조하십시오.

Amazon Aurora MySQL 버전 3으로 업그레이드하는 방법에 대한 자세한 내용은 MySQL 8.0과 호환되는 Aurora MySQL 버전 3 및 Amazon Aurora MySQL 버전 3(MySQL 8.0과 호환됨)으로 업그레이드를 참조하십시오.