[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상
l Version : AWS Aurora MySQL 2.10 later
Binlog 복제는 소스 데이터베이스에서 트랜잭션 작업 오프로드, 분석을 실행하기 위한 별도의 전용 시스템으로 변경 사항 복제, 다른 시스템으로 데이터 스트리밍을 포함하여 여러 사용 사례를 제공하는 인기 있는 기능 이지만 무료(기능에 따른 오버헤드 비용으로 해석)로 제공되지 않는다.
바이너리 로깅은 binlog 이벤트에 대한 로깅이 트랜잭션 커밋의 중요한 경로의 일부로 통합되기 대문에 데이터베이스에 오버헤드가 발생할 수 있다. 이 뜻은 더 높은 커밋 대기 시간 및 더 낮은 처리량으로 해석할 수 있다. MySQL 엔진은 추가 정보(binlog 이벤트)를 binlog 파일에 쓰기 시작한다. 일반적으로 binlog 파일은 로컬 스토리지에 기록 되지만 Aurora MySQL-Compatible Edition은 이러한 binlog 파일을 Aurora 스토리지 엔진에 기록 한다. Binlog 파일은 MySQL이 binlog 이벤트를 binlog 파일에 기록 할 뿐만 아니라 동일한 파일에서 binlog 이벤트를 읽기 때문에 MySQL이 이러한 binlog 이벤트를 다른 MySQL 데이터베이스에 복제하기 시작할 때 성능 병목 현상이 될 수 있다.
Aurora MySQL 2.10 릴리스에서는 이 사용 사례를 개선하기 위해 binlog I/O 캐시라는 새로운 기능이 도입되었다. 이 사용 사례에서는 Aurora MySQL이 바이너리 로깅을 켜고 binglog 이벤트를 동일한 파일에 적극적으로 복제한다. 이번 포스트에서는 새로운 binlog I/O 캐시의 성능 향상 및 관련 모니터링 메트릭과 상태 변수에 대해 알아 본다.
Binlog I/O 캐시는 순환 캐시에 가장 최근의 binlog 이벤트를 유지하여 Aurora 스토리지 엔진의 읽기 I/O를 최소화 한다. Binlog I/O 캐시는 db.t2, db.t3 인스턴스를 제외한 대부분의 Aurora MySQL 인스턴스에 대해 활성화 된다. 아래 그래프는 binlog I/O 캐시를 활성(파란선), 비활성(주황선) 했을때 초당 평균 쓰기를 측정한 결과이다. 이 그래프를 통해서 binlog I/O 캐시로 얻을 수 있는 처리량 향상 정도를 확인할 수 있다.
그래프에서 읽기 전용 복제본의 I/O 경합 없이 최적의 성능을 보여주는 “복제본 없음” 설정(회색선)의 처리량도 표시했다. 그림을 보면 binlog I/O 캐시가 활성화 된 경우 쓰기 처리량 증가(파란색)에 따라 원본 인스턴스가 연결된 복제본이 없는 것처럼 (회식) 최적의 쓰기 처리량으로 확장될 수 있음을 보여준다.
Binlog I/O 캐시를 출시하기 전에 aurora_binlog_replication_max_yield_seconds 매개변수를 사용하여 관련 binlog 성능 향상을 구현했으며, 이는 MySQL 5.7(2.04.5 later) 및 5.6(1.17.6)에서 출시 되었다. 이 매개변수는 binlog 덤프 스레드가 “aurora_bin_log_replication_max_yield_seconds” 초까지 기다리도록 지시한다. 덤프 스레드의 이러한 “양보(yield)”를 통해 binlog 기록기 스레드는 binlog 덤프 스레드와의 경합없이 활성 binlog 파일에 쓸 수 있지만 잠재적으로 높은 복제 지연이 발생할 수 있다. Binlog I/O 캐시를 사용하기 위해서는 추가 구성이 필요하지 않지만 이 기능을 최대한 활용하려면 기존 최대 산출량 기능인 aurora_bin_log_replication_max_yield_seconds 를 다시 0으로 재설정 하는 것이 좋다.
Binlog I/O cache에 대한 모니터링을 위해 두가지 상태 변수(aurora_binlog_io_cache_reads, aurora_binlog_io_cache_read_requests)와 새로운 로그인 dump thread metrics 가 도입되었다. aurora_binlog_io_cache_read_requests 변수는 binlog 파일에 대한 총 읽기 I/O수를 보여주고 aurora_binlog_io_cache_reads는 캐시에서 읽을 수 있는 총 읽기 I/O 수를 보여준다. 아래 코드는 binlog I/O 캐시의 적중률을 구하는 예제이다.
| mysql> SELECT(SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')/ (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')*100 as binlog_io_cache_hit_ratio; +-------------------------+ | binlog_io_cache_hit_ratio | +-------------------------+ | 99.99847949080622 | +-------------------------+ 1 row in set, 2 warnings (0.00 sec) |
또한 소스에서 작성된 최신 binlog 이벤트에서 binlog 복제본의 거리(바이트)를 모니터링할 수 있다. 이 정보는 원본에서 가져온 복제본을 읽은 최신 binlog이벤트가 binlog I/O 캐시에서 제공되는지 여부를 분석할 수 있기 때문에 중요하다. 검색 키워드 “dump thread metric”을 사용하여 메트릭을 필터링 할 수 있다. “dump thread”라는 이름은 MySQL 문서의 드binary log dump thread에서 차용했다. 이 지표는 복제본이 소스 인스턴스에 연결될 때 기록되며 1분마다 내보낸다. Aurora MySQL은 log_error_verbosity가 기본값인 3인 경우에만 메시지를 생성한다. Log_error_verbosity값은 Aurora MySQL의 DB 파라미터 그룹 또는 DB 클러스터 파라미터 그룹을 통해 구성할 수 있다.
[참고자료]
2022-05-11 / Sungwook Kang / http://sungwookkang.com
AWS, Aurora, binlog, Binlog I/O cache, Aurora performance, Aurora replication
'AWS' 카테고리의 다른 글
| [AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지 (0) | 2022.07.10 |
|---|---|
| [AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결 (0) | 2022.06.17 |
| [AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리 (0) | 2022.05.08 |
| [AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기 (0) | 2022.04.25 |
| [AWS RDS] Performance Insight로 DB부하의 원인 찾기 (0) | 2022.04.24 |
