Amazon Aurora DB와 mysql 차이점

1. Aurora MySQL 5.7과 MySQL 5.7 비교

다음 기능은 MySQL 5.7.12에서 지원되지만 Aurora MySQL 5.7에서는 현재 지원되지 않습니다.

그룹 복제 플러그인
페이지 크기 증가
시작 시 InnoDB 버퍼 풀 로딩
InnoDB 풀 텍스트 구문 분석기 플러그인
멀티 소스 복제
온라인 버퍼 풀 크기 조정
암호 확인 플러그인
쿼리 다시 쓰기 플러그인
복제 필터링
CREATE TABLESPACE SQL 문
X 프로토콜

 

 2. 빠른 입력 기능

빠른 입력 기능은 기본 키에 의해 정렬되는 병렬 입력을 빠르게 처리해 주며, 특히 LOAD DATA 및 INSERT INTO ... SELECT ... 문 사용 시 유용합니다. 빠른 입력 기능은 SQL 구문을 실행할 때 인덱스 순회에서 커서의 위치를 캐싱합니다. 이에 따라 인덱스를 불필요하게 다시 순회하지 않도록 해줍니다.

다음 측정치를 모니터링하면 DB 클러스터에서 빠른 입력 기능의 효과를 확인할 수 있습니다.

• aurora_fast_insert_cache_hits: 캐싱된 커서가 성공적으로 검색 및 확인되면 증가하는 카운터입니다.
• aurora_fast_insert_cache_misses: 캐싱된 커서가 더 이상 유효하지 않고 Aurora가 정상적인 인덱스 순회를 수행하면 증가하는 카운터입니다.

 

다음 명령을 사용하면 빠른 입력 측정치의 현재 값을 검색할 수 있습니다.

mysql> show global status like 'Aurora_fast_insert%';               


+---------------------------------+-----------+
| Variable_name                   | Value     |
+---------------------------------+-----------+
| Aurora_fast_insert_cache_hits   | 3598300   |
| Aurora_fast_insert_cache_misses | 436401336 |
+---------------------------------+-----------+

 

3. 스토리지

Aurora는 Shared Storage를 사용하며 MySQL의 경우 binlog 기반의 replication이 아닌 Storage와 page기반의 replication을 사용합니다.

 

가장 큰 차이점은 스토리지입니다. 위 그림의 위는 MySQL replica, 아래는 AWS aurora입니다.

MySQL의 경우 자신의 EBS로 데이터를 쌓고 쌓은 데이터를 EBS로 미러링 한 다음 replication을 통해 replica로 데이터를 보내고 replica는 받은 데이터를 자신의 스토리지로 쌓습니다. 데이터베이스는 결국 트랜잭션의 결과물이 input/ooutput 형태로 수행되는 것이기에 before & after 작업들이 WAL(Write-Ahead-Log)를 통해 스토리지에 저장됩니다. 이 방식의 단점은 I/O 대역폭과 IOPS가 제한적이고 이부분에 대해 변경이 필요할 경우 사용자가 직접 튜닝해야 합니다.
반면 aurora의 경우에는 4/6 쿼럼을 사용해서 스토리지에 저장하며 replica로 보내는 것은 frm 및 redo log입니다. 그래서 network badwidth 사용도 적으며 빠르게 변경분을 저장하고 반영할 수 있습니다. 인스턴스와 스토리지의 영역을 나눴기 때문에 이와 같은 아키텍쳐를 그릴 수 있습니다. 스토리지 서브 시스템은 segmented 방식이며 EBS가 아닌 고성능 NVMe SSD 를 사용하고 데이터는 지속적으로 S3에 백업 합니다.

이렇게 보면 writer에 많은 DML이 들어오는 인스턴스의 경우 aurora를 사용하면 적은 replica lag을 가지면서 서비스 운영을 할 수 있다는 것으로 보입니다. 이론상으로만 보면 그렇습니다. 하지만 AWS 스토리지 내부 아키텍쳐를 좀 더 보아야 합니다.

MySQL의 경우 read replica도 binlog를 받아서 처리하기 때문에 read 뿐만아니라 write도 같이 처리해야 하는 단점이 있습니다. AWS aurora MySQL의 경우 read replica가 binlog를 읽어서 싱크를 맞추는 것이 아니라 redo log를 받아서 동기화 하기 때문에 read에만 집중할 수 있습니다. 이점이 aurora MySQL 이 더 뛰어난 점이라고 말 할 수 있습니다.

정리 하자면 가장 큰 차이점은 스토리지 및 관리 주체, read replica의 구성 방식 세가지로 볼 수 있습니다.

• 스토리지 : MySQL은 자체 스토리지로 운영하지만 aurora MySQL은 Shared Storage를 사용한다.
• 관리 주체: MySQL은 관리자가 MySQL 버전을 올리면서 사용 하지만 aurora MySQL은 AWS가 개발해서 버전 업그레이드를 주기적으로 하기 때문에 optional 또는 mandatory가 AWS에 의해 정해질 수 있다. (참조 : https://forums.aws.amazon.com/forum.jspa?forumID=60&start=0 )
• read replica 구성 : MySQL은 standby와 read replica를 만들 때 binlog를 사용하지만 aurora의 경우 내부 storage 및 redo log 전송을 통해 빠른 동기화가 가능하며 bandwidth를 줄일 수 있다