Amazon Aurora 정리 (요약)

Aurora 란?

• Amazon Aurora(이하 Aurora)는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진
• 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공
• Aurora는 관리형 데이터베이스 서비스 Amazon Relational Database Service(Amazon RDS)의 일부
  

 

Aurora DB 클러스터

Aurora DB cluster는 하나 이상의 DB 인스턴스와 데이터를 관리하는 클러스터 볼륨으로 구성

 DB 인스턴스 2가지 유형

• 기본 DB 인스턴스 
  • 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 수정을 실행
  • Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 존재
• Aurora 복제본 
  • 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원 
  • 최대 15개까지 Aurora 복제본을 구성
    

 

리전 및 가용 영역

Aurora는 세계 각지의 여러 곳에서 호스팅되고, 위치들은 AWS 리전과 가용 영역으로 구성
AWS 리전은 개별 지리 영역
각 AWS 리전은 가용 영역이라고 알려진 격리된 위치를 여러 개 가지고 있음 
가용 영역은 AWS 리전 코드와 식별 문자의 조합으로 표시 (예: us-east-1a)

 

Aurora 만의 특징

랩 모드 사용

• 기본적으로 비활성화
• 사용자 지정 파라미터 그룹에서 aurora_lab_mode 파라미터를 1(활성)로 설정
  

랩모드 기능

배치화 스캔	in memory 쿼리의 속도를 크게 높임 full table scan, index full scan 및 index range scan 성능을 향샹
hash join	동등 조인을 사용하여 많은 양의 데이터를 조인해야 하는 경우 쿼리 성능을 향상
빠른 DDL	ALTER TABLE tbl_name ADD COLUMN col_name column_definition 작업을 거의 동시에 실행 테이블 끝에서 기본값 없이 null이 허용된 열에 대해서만 지원

 

Async Key Prefetch(비동기식 키 미리 가져오기)

• Async Key Prefetch(AKP)를 사용하여 여러 인덱스 사이에 테이블을 조인하는 쿼리 성능 향상
• JOIN 쿼리에서 Batched Key Access(BKA) 조인 알고리즘과 Multi-Range Read(MRR) 최적화 기능을 사용하여 필요한 행을 예측
• AKP 기능이 테이블에 적용되는 경우 plan extra 열에 다음 값 중 하나가 포함

• • Using Key Prefetching
  • Using join buffer (Batched Key Access with Key Prefetching)

AKP 사용 예제

mysql> explain extended select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

 

Hash Join

동등 조인을 사용하여 많은 양의 데이터를 조인해야 하는 경우 쿼리 성능을 향상

Aurora MySQL의 hash join 제한 사항

• left/right outer 조인은 지원하지 않음
• Semijoin은 지원 안함
• 다중 테이블의 업데이트 또는 삭제는 지원 안됨
• BLOB 및 공간 데이터 타입 열은 해시 조인 할 수 없음

해시 조인이 테이블에 적용되는 경우 plan extra 열에 다음 값이 포함

• Using where; Using join buffer (Hash Join Outer table table1_name)
• Using where; Using join buffer (Hash Join Inner table table2_name)

hash join 쿼리 예제

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

 

Aurora MySQL 힌트

HASH_JOIN, NO_HASH_JOIN	쿼리에 해시 조인 최적화 방법을 사용할지 여부를 선택
HASH_JOIN_PROBING, NO_HASH_JOIN_PROBING	해시 조인 쿼리에서 조인의 프로브 측에 지정된 테이블을 사용할지 여부를 지정
HASH_JOIN_BUILDING, NO_HASH_JOIN_BUILDING	해시 조인 쿼리에서 조인의 빌드 측에 지정된 테이블을 사용할지 여부를 지정
JOIN_FIXED_ORDER	쿼리의 테이블이 나열된 순서에 따라 조인되도록 지정 MySQL STRAIGHT_JOIN 힌트를 대체
JOIN_ORDER	쿼리의 테이블에 대한 조인 순서를 지정
JOIN_PREFIX	조인 순서에서 먼저 넣을 테이블을 지정
JOIN_SUFFIX	조인 순서에 마지막으로 넣을 테이블을 지정

 

 Aurora 스토리지

aurora 스토리지는 개념적으로 Amazon Aurora 스토리지 엔진은 한 리전(Region)의 여러 AWS 가용 영역(Availability Zone)에 걸친 분산된 SAN

1. Amazon Aurora는 보호 그룹(protection groups) 이라고 하는 10GB 논리 블록에 스토리지 볼륨을 구축
2. 각 보호 그룹의 데이터는 6개의 스토리지 노드에 복제
3. 스토리지 노드는 Amazon Aurora 클러스터가 운영되는 리전의 3개 AZ에 할당
4. 데이터 양이 증가하여 현재 할당된 스토리지를 넘어서면 Aurora는 요건을 충족시키기 위해 볼륨을 자연스럽게 확장하고 필요에 따라 새로운 보호 그룹을 추가

 

Aurora 쓰기 처리 방법

Primary Instance(Master)에서 write가 발생하면 데이터를 쓰면 6개의 스토리지 노드로 병렬로 전송

1. 각 스토리지 노드에서 로그 레코드를 수신하고 Incoming queue에 추가하고 지속적으로 레코드를 유지
2. 데이터베이스에 대한 ACK
3. 레코드를 정리하고 로그의 gap 확인
4. 보관할 레코드는 핫 로그(hot log)에서 디스크에 저장하고 하나 이상의 로그 시퀀스 번호(LSN)가 누락 된 것으로 판단되면 스토리지 노드는 볼륨의 다른 노드에서 누락 된 LSN을 검색
5. 로그 레코드를 병합하여 데이터 페이지로 만듦
6. S3에 주기적으로 로그 및 새 페이지 버전 전송
7. 데이터 페이지가 갱신 된 후 로그 레코드가 백업되고 이전 버전에 대한 가비지 컬렉션 진행
   
8. 데이터 블록의 CRC 코드를 주기적으로 검증

 

Aurora replica

Aurora는 MySQL의 binlog 기반의 replication이 아닌 Storage와 page 기반의 replication을 사용

RDS MySQL replica는 Primary Instance(Master)에서 write가 발생하면

1. 데이터를 EBS로 데이터를 저장
2. 쌓은 데이터를 EBS로 미러링
3. replication을 통해 replica로 데이터를 보냄
4. replica는 받은 데이터를 자신의 EBS로 저장
5. 쌓은 데이터를 EBS로 미러링

데이터베이스는 결국 트랜잭션의 결과물이 input/output 형태로 수행되는 것이기에 before & after 작업들이 WAL(Write-Ahead-Log)를 통해 스토리지에 저장

단점은 I/O 대역폭과 IOPS가 제한적이고, 변경이 필요할 경우 사용자가 직접 튜닝 필요

 

Aurora MySQL replica는 Primary Instance(Master)에서 write가 발생하면 4/6 쿼럼을 사용해서 스토리지에 저장하며, frm 및 redo log를 replica로 전송

• Auroroa의 경우 6개의 스토리지 영역이 static하게 설정되어 있기 때문에 write는 4/6, read는 3/6 쿼럼을 사용
  (write가 6개 중에 4개의 스토리지에 성공해야 완료이고, read 는 6개중 3개의 스토리지에 성공해야 완료)
• Aurora는 내부적으로 스토리지의 latency를 측정하고 있고 응답이 가장 빠르게 오는 스토리지에 write를 시도

 

 

MySQL의 경우 read replica도 binlog를 받아서 처리하기 때문에 read 뿐만아니라 write도 같이 처리

aurora MySQL의 경우 read replica가 binlog를 읽어서 싱크를 맞추는 것이 아니라 redo log를 받아서 동기화 하기 때문에 read만 처리

 

MySQL과 Aurora MySQL 차이

MySQLAurora MySQL스토리지 관리 주체read replica 구성

자체 storage	Cloud Shared Storage
디비 관리자	AWS
binlog를 사용	내부 storage 및 redo log 전송을 통해 빠른 동기화가 가능하며 bandwidth 줄어듬