1. Amazon Aurora
신규 서비스 알아보기
최유정 / AWS 데이터베이스 솔루션즈 아키텍트

2. 목차
>
>
>
Aurora 기본소개
최근 개선사항
출시 예정 신기능

3. AURORA 기본소개

4. Amazon Aurora
클라우드에 최적화된 관계형 데이터베이스
R 하이엔드 상용 데이터베이스의 성능 과 가용성
R 오픈소스 데이터베이스의 비용효율성 과 간단함
R MySQL, PostgreSQL와의 호환성
R Pay as you go 가격정책
관리형 서비스로 제공

5. 클라우드용으로 설계되지 않은 관계형 데이터베이스
• Monolithic 아키텍처
• 넓은 장애 영향 범위
SQL
TRANSACTIONS
CACHING
LOGGING

6. 스케일 아웃 가능한 분산 아키텍처
• 데이터베이스용으로 설계된 로그 구조
기반의 분산형 스토리지 시스템
• 3개의 가용영역에 걸친 수백개 이상의
스토리지 노드로 스트라이핑
• 총 6개의 복제본 유지 (각각의 가용
영역에 2개의 복제)
Master Replica Replica Replica
AVAILABILITY
ZONE 1
SHARED STORAGE VOLUME
AVAILABILITY
ZONE 2
AVAILABILITY
ZONE 3
STORAGE NODES WITH SSDs
SQL
TRANSACTIONS
CACHING
SQL
TRANSACTIONS
CACHING
SQL
TRANSACTIONS
CACHING

7. 왜 6개의 복제본이 필요한가?
§ 대규모 분산환경에서는 항상 어딘가에 장애가
발생할 수 있음
§ AZ 장애는 ”운명을 공유”
§ AZ+1 장애에도 문제 없이 운영 및 복구
가능해야 함
§ 3 AZ인 경우 6 복제본이 필요
AZ 1 AZ 2 AZ 3
AZ 장애 시
Quorum
손실
2/3 read
2/3 write
AZ 1 AZ 2 AZ 3
AZ 장애 시
Quorum
정상
3/6 read
4/6 write
3개 복제본
6개 복제본
(Aurora)

8. Aurora의 장애 복구
CRASH
Log records Gaps
Volume Complete
LSN (VCL)
장애 시
장애 복구 후
Consistency Point
LSN (CPL)
Consistency Point
LSN (CPL)
§ 모든 로그 레코드는 LSN(Log Sequence Number)
를 가짐
§ Volume Complete LSN (VCL)은 모든 레코드가 쿼럼
을 충족한 가장 최신 시점
§ Consistency Point LSN (CPL)는 VCL보다 작은 가장
최신의 커밋 레코드.
§ 인스턴스는 볼륨의 모든 스토리지 노드를 열어 CPL
과 VCL확인
§ 장애 복구 시 CPL이후의 모든 변경사항은 삭제 됨
• 매 커밋마다 스토리지 노드들을 위한 2 Phase Commit이
불필요.
• 데이터베이스 오픈 전 redo 또는 undo 프로세싱이 불필요

9. 최근 개선 사항

10. 빠른 데이터베이스 복제 - Aug 2017
스토리지 중복 비용 없이 데이터베이스 복제본을 생성
§ 복제본은 거의 즉시 생성 – 데이터를 복제 하지 않음
§ 데이터 복제는 쓰기작업 시 발생 – 오리지널과
복제볼륨데이터가 다른 경우
주요 사용 사례:
§ 테스트를 위해 운영 DB 복제
§ 데이터베이스 재구성
§ 운영 DB의 부하 없이, 분석을 위한 특정시점의 스냅샷
저장
PRODUCTION DATABASE
CLONE CLONE
CLONE
DEV/TEST
APPLICATIONS
BENCHMARKS
PRODUCTION
APPLICATIONS
PRODUCTION
APPLICATIONS

11. Asynchronous key prefetch - Oct 2017
지연시간 개선 효과 vs. Batched Key Access (BKA) 조인 알고리즘.
의사결정 벤치마크(Decision support benchmark), R3.8xlarge
14.57
-
2.00
4.00
6.00
8.00
10.00
12.00
14.00
16.00
Query-1
Query-2
Query-3
Query-4
Query-5
Query-6
Query-7
Query-8
Query-9
Query-10
Query-11
Query-12
Query-13
Query-14
Query-15
Query-16
Query-17
Query-18
Query-19
Query-20
Query-21
Query-22
Cold buffer
Batched Key Access (BKA) 조인 알고리즘 +
Multi-Range Read (MRR) 최적화를 사용하는
쿼리에 적용
조인 시, 보조인덱스가 PK인덱스를 조회할때
수행
백그라운드 쓰레드가 비동기로 페이지를 메
모리로 로드
AKP used in queries 2, 5, 8, 9, 11, 13, 17, 18, 19, 20, 21

12. Aurora PostgreSQL - Oct 2017
+
Amazon Aurora Storage
PostgreSQL 9.6 + 호환 Amazon Aurora
§ 성능: 일반 PostgreSQL 대비 최대 2배 이상 개선
§ 가용성 : 일반적으로 30 초 이내 Failover 완료
§ 내구성 : 3 개 가용영역에 걸친 6개 복제본
§ 읽기 복제본: 매우 낮은 복제 지연 시간을 제공하며 최대 15개까지 구성

13. 읽기 복제본 Auto-scaling - Nov 2017
최대 15개 읽기 복제본을 여러 가용영역에 구성 가능
일반적으로 10ms 이내의 지연시간으로 리두로그 기반 복제
로드밸런싱과 auto-scaling 을 지원하는 읽기 엔드포인트 * NEW *
MASTER
READ
REPLICA
READ
REPLICA
READ
REPLICA
SHARED DISTRIBUTED STORAGE VOLUME
READER END-POINT

14. MySQL 5.7.12+ 호환 Aurora - Dec 2017
MySQL 5.7 compatible Aurora는
§ JSON 지원
§ Generated Column 지원
§ Spatial 인덱스 (Aurora 5.6에서 이미 지원 중)
§ MySQL 5.7 대비 5배 이상의 성능개선
현재 US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Montreal) 에서 Preview 버전 사용 가능

15. 해쉬 조인 - Dec 2017
지연시간 개선 효과 vs. Batched Key Access (BKA) 조인 알고리즘
의사결정 벤치마크(Decision support benchmark), R3.8xlarge, cold buffer cache (모든 데이터가 캐싱 되어 있는 경우는 개선효과 줄어듬)
8.22
-
1.00
2.00
3.00
4.00
5.00
6.00
7.00
8.00
9.00
Hash join used in queries 2, 3, 5, 7, 8, 9, 10, 11, 12, 15, 16, 17,18, 19, 21

16. 출시 예정 신기능

17. 온라인 DDL: Aurora vs. MySQL *Coming soon*
§ 백그라운드로 전체 테이블 복사
§ 모든 인덱스 리빌드 – 수시간 또는 수일 소요될 수 있음
§ DDL 작업이 DML 성능에 영향
§ DML 변경 사항 적용 시 테이블 Lock 발생
§ 스키마 버저닝 사용
§ Modify-On-Write 적용을 통한 실제 데이터 변경시에 스키마 적용
§ 현재는 테이블 끝에 NULLable 컬럼 추가 지원
§ 위치에 관계없는 컬럼 추가와 기본값 설정은 곧 지원 예정
INDEX
LEAFLEAFLEAF LEAF
INDEX
ROOT
테이블명 작업 컬럼명 타임스탬프
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
MySQL Amazon Aurora

18. r3.large
r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB 테이블 0.27 sec 3,960 sec 1,600 sec
50GB 테이블 0.25 sec 23,400 sec 5,040 sec
100GB 테이블 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB 테이블 0.06 sec 900 sec 1,080 sec
50GB 테이블 0.08 sec 4,680 sec 5,040 sec
100GB 테이블 0.15 sec 14,400 sec 9,720 sec
온라인 DDL 성능

19. 거의 즉각적인 복원을 제공하는 Backtrack *Coming soon*
Backtrack은 신속하게 데이터베이스를 원하는 시점으로 복원
백업본으로부터의 복원 없음. 데이터 복제 없음. 여러번 되돌아갈 수 있음.
의도하지 않은 DML/DDL작업으로부터 신속하게 복구
T0 T1 T2
T0 T1
T2
T3 T4
T3
T4
REWIND TO T1
REWIND TO T3
INVISIBLE INVISIBLE

20. AURORA SERVERLESS

21. Aurora Serverless
§ 인스턴스 용량 및 워크로드 산정 불필요
§ 온디맨드로 시작하고, 사용하지 않을 시 종료
§ 자동으로 스케일 업/다운
§ 스케일링 시 어플리케이션 영향 없음
§ 최소 1분 후 초단위 과금
인스턴스
WARM POOL
어플리케이션
데이터베이스 스토리지
확장가능한 DB 용량
REQUEST ROUTER
데이터베이스 엔드포인트

22. 데이터베이스 엔드포인트 프로비저닝
데이터베이스 생성 시, Aurora Serverless는:
§ 어플리케이션 커넥터를 위한 VPC 엔드포인
트 생성
§ 접속 처리를 위한 request routers를 초기화
§ Aurora 스토리지 볼륨 생성
데이터베이스 인스턴스는 첫번째 요청이 발생할때
프로비저닝
APPLICATION
고객 VPC
VPC
엔드포인트
VPC
엔드포인트
네트워크 로드 밸런서
스토리지
볼륨
REQUEST
ROUTERS

23. 인스턴스 프로비저닝과 스케일링
§ 첫번째 요청이 인스턴스를 프로비저닝 하며,
보통 1-3 초 소요
§ 인스턴스는 작업부하에 따라 자동 스케일 업
/다운되며, 보통 1-3 초 소요
§ 사용자가 지정한 비활성화 기간 후 인스턴스
는 중단
§ 스케일링 작업은 사용자 세션을 종료하지 않
고 어플리케이션에 투명하게 수행
§ 데이터베이스 스토리지는 사용자가 명시적
으로 삭제할때까지 유지
Aurora
데이터베이스 스토리지
WARM POOL
어플리케이션
REQUEST
ROUTER
현재
인스턴스
신규
인스턴스

24. AURORA MULTI-MASTER

25. 클러스터 내 다수의 Writer
Application
Master
Node
Read
Replica 1
Read
Replica 2
Shared distributed storage volume
Availability
Zone 1
Availability
Zone 2
Availability
Zone 3
읽기 성능 확장
Application
Read/Write
Master 1
Read/Write
Master 2
Read/Write
Master 3
Shared distributed storage volume
Availability
Zone 1
Availability
Zone 2
Availability
Zone 3
읽기 및 쓰기 성능 확장
여러 데이터 센터에 걸쳐, 읽기 및 쓰기 확장 가능한 첫번째 관계형 DB서비스

26. 분산된 Lock Manager
GLOBAL
RESOURCE
MANAGER
SQL
TRANSACTIONS
CACHING
LOGGING
SQL
TRANSACTIONS
CACHING
LOGGING
SHARED DISK CLUSTER
STORAGE
APPLICATION
LOCKING PROTOCOL MESSAGES
SHARED STORAGE
M1 M2 M3
M1 M1 M1M2 M3 M2
§ 단점
§ Lock 단위의 캐시 일관성을 위한 많은 트래픽 발생
§ 네트워크 비용이 많이 들 수 있음
§ Hot 블럭 발생 시 성능 저하
§ 장점
§ 모든 노드에서 모든 데이터를 사용 가능
§ Application 개발 용이
§ 멀티 프로세서와 비슷한 캐시 일관성

27. Two phase 또는 Paxos commit을 통한 일관성
DATA
RANGE #1
DATA
RANGE #2
DATA
RANGE #4
DATA
RANGE #3
DATA
RANGE #5
L
L L
L
L
SHARED NOTHING
SQL
TRANSACTIONS
CACHING
LOGGING
SQL
TRANSACTIONS
CACHING
LOGGING
APPLICATION
STORAGE STORAGE
§ 단점
§ Two phase 커밋과 멤버쉽 변경으로 인한 많은 트래픽
§ 범위 파티셔닝은 단순히 hot 블럭이 아닌 hot 파티션 유
발할 수 있음 – 비싼 파티션 재구성
§ 크로스 파티션 작업은 비용이 많이 발생하므로, 작은 범위
처리에 적합
§ 장점
§ 쿼리가 Data 노드별로 분리되어 실행
§ 적은 캐시 일관성 트래픽 – 커밋시 만 필요
§ 많은 노드로 확장 가능

28. 분산 원장을 통한 Conflict 해결
Aurora에는 일관성 처리를 위한 많
은 요소들이 있음
데이터베이스 노드는 각자의 노드
에서 발생한 트랜잭션의 순서를 인
지
스토리지 노드는 각 노드에 적용된
트랜잭션의 순서를 인지
2개 이상의 데이터베이스가 2개 이
상의 스토리지 노드의 데이터(Page)
를 변경하려고 할때만 Conflict 발생
조정 작업이 훨씬 적게 필요함
2 3 4 5 61
BT1 [P1]
BT2 [P1]
BT3 [P1]
BT4 [P1]
BT1
BT2
BT3
BT4
Page1
Quorum
OT1
OT2
OT3
OT4
Page 1 Page 2
2 3 4 5 61
OT1[P2]
OT2[P2]
OT3[P2]
OT4[P2]
PAGE1 PAGE2
MASTER
MASTER
Page 2

29. 계층적 conflict 해결
양쪽 master들은 P1과 P2 페이지 모
두를 작성하려고 함
BLUE master는 P1에 대한 쿼럼을 획
득하고, ORANGE master는 P2에 대
한 쿼럼을 획득함
양쪽 master는 conflict를 확인 후 2개
중 선택: (1) 트랜잭션 롤백 또는 (2) re
gional resolver에 이관
Regional 중재자가 순서를 결정
(Dead lock처리와 유사, Victim 결정)
2 3 4 5 61
BT1 [P1]
OT1 [P1]
2 3 4 5 61
OT1[P2]
BT1[P2]
PAGE1 PAGE2
MASTER
MASTER
BT1 OT1
Regional
resolver
Page 1 Page 2 Page 1 Page 2
Quorum
X X

30. Multi-master 장애 복구
CRASH
MULTI-MASTERSINGLE MASTER
Log records Gaps
Volume Complete
LSN (VCL)
장애 발생 시
복구 후
MASTER 1
장애 시
GAPS
장애 발생 시
Consistency Point
LSN(CPL)
VCLVCL
CPL CPL
MASTER 1
MASTER 2
복구 후
Gap filled 신규 LSNs
과 Gaps
Master 1
Recovery Point
Consistency Point
LSN(CPL)

31. 멀티-리전 멀티-마스터 (향후 출시 예정)
쓰기 작업은 로컬 리전에서 수행
낙관적 동시성 제어
– 분산 lock manager 및 lock management 프로토콜
없음
REGION 1 REGION 2
HEAD NODES HEAD NODES
MULTI-AZ STORAGE VOLUME MULTI-AZ STORAGE VOLUME
LOCAL PARTITION LOCAL PARTITIONREMOTE PARTITION REMOTE PARTITION
계층적 Conflicts 처리 – head 노드, 스토리지 노드, AZ
및 region 레벨 중재자
Conflict가 없거나 낮은 경우, 거의 선형 성능 확장

32. AURORA PARALLEL QUERY

33. 수천개 스토리지 CPU를 활용한 쿼리
Aurora 스토리지에는 수천개의 CPU가 있음
§ 스토리지를 활용하여 쿼리 프로세싱을 병렬화
§ 스토리지에서 데이터를 처리함으로써 네트워크
트래픽 및 지연시간을 줄임
그러나, 주요 고려사항이 있음
§ 스토리지 노드의 데이터가 범위로 파티셔닝 되어
있지 않으면, Full 스캔 해야 함.
§ 데이터가 현재 반영(in-flight) 중일 수 있음
§ 읽기 뷰가 최신 데이터를 반영하지 않을 수 있음
§ 모든 함수가 스토리지 노드로 전달되지는 않음
데이터베이스 노드
스토리지 노드
쿼리 술어
전달
결과 취합

34. Head 노드의 프로세싱
STORAGE NODES
OPTIMIZER
EXECUTOR
INNODB
NETWORK STORAGE DRIVER
AGGREGATOR
APPLICATION
부분
결과
스트림
결과
IN-FLIGHT
DATA
PQ CONTEXT
PQ 실행계획
쿼리 옵티마이저는 PQ 실행계획을
작성하고 리프 페이지 정보를 기반으로 PQ
context를 생성
PQ 요청은 PQ context와 함께 스토리지
노드로 전달
스토리지 노드는
§ 기처리된(stable) row들에 대한 부분
결과 스트림을 생성
§ 아직 처리되지 않은(unprocessed)
row들의 Raw 스트림을 undo정보와
함께 생성
Head 노드는 이러한 데이터 스트림들을
취합하여 최종 결과를 생성

35. 스토리지 노드의 프로세싱
각 스토리지 노드는 parallel query와 연관된
최대 16개 PQ 프로세스를 실행
PQ 프로세스는 PQ context를 전달받음
§ 스캔해야할 페이지 리스트
§ 읽기 뷰와 조회 컬럼(projections)
§ 표현식 바이트 코드
PQ 프로세스는 페이지 리스트를 두번 조회
§ 조회 1: InnoDB 형식의 raw 데이터에
대한 필터 처리
§ 조회 2: MySQL 형식 데이터에 대한
표현식 처리
PQ 프로세스
PQ 프로세스
최대 16
TO/FROM HEAD 노드
스토리지 노드
프로세스
페이지 리스트

36. 예제: 병렬 해쉬 조인
Head 노드는 해쉬 조인 context를 스토리지
노드에 전달:
§ 페이지 리스트– 페이지 ID 와 LSN 정보
§ 조인 표현식 바이트 코드
§ 읽기 뷰 – 포함할 행(row)
§ 추출(projections)– 선택한 열(column)
PQ 프로세스는 다음 단계 수행:
§ 페이지 리스트를 스캔
§ 부분 블룸필터 생성; 통계정보 수집
§ Head노드로 2개 스트림 전달
§ 해쉬정보와 일치하는 Rows
§ Undo 프로세싱이 필요한 Rows (unprocessed
rows)
Head 노드는 각각의 스토리지 노드로부터의
데이터 스트림들을 합친 후 조인함수를 수행
조인 CONTEXT
페이지 스캔
STABLE ROWS
ROWS WITH
PENDING UNDO
BLOOM
FILTER
필터링 되고 및 선택된 열들로 구성된
ROW STREAM
아직 처리되지 않은
ROW 스트림

37. Parallel query 성능
지연시간 (초)
의사결정 벤치마크(Decision support benchmark), R3.8xlarge, buffer cache에 캐싱되지 않은 경우
Parallel Query
개선 효과
24.6x
18.3x
5.0x
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Aggregate + 2-table join
Aggregate query
Point query on non-indexed column
With Parallel Query Without Parallel Query

38. 본 강연이 끝난 후…
Preview 신청 링크안내
• Aurora with MySQL 5.7 Compatibility
https://pages.awscloud.com/amazon-aurora-mysql57-preview.html
• Aurora Serverless
https://aws.amazon.com/rds/aurora/serverless/
• Aurora Multi-master
https://pages.awscloud.com/amazon-aurora-multimaster-preview.html
• Aurora Parallel Query
향후 제공 예정

39. 함께 해주셔서 감사합니다.