Amazon Aurora 는 엔터프라이즈급의 가용성과 성능을 제공합니다. 실제 적용에서 Aurora성능 개선을 위해 무엇을 해야하는지, 그에 따른 모범 사례는 무엇이 있는지 본 세션에서 살펴봅니다. 또한 AWS Lambda 및 Amazon S3 와 같은 AWS의 다양한 서비스와 통합하는 최근 기능들에 대하여 상세하게 살펴보고 한국 고객들이 Aurora를 도입 및 마이그레이션한 사례를 통해 어떻게 마이그레이션에 접근해야 하는지를 살펴봅니다. 연사: 구승모, 아마존 웹서비스 솔루션즈 아키텍트

1. Amazon Aurora
자세히 알아보기
구승모, AWS
서기언, 삼성전자

2. Amazon Aurora 자세히 알아보기
AGENDA
• Amazon Aurora 개요
• Amazon Aurora의 빠른 성능
• Amazon Aurora의 고가용성
• Amazon Aurora 운영 모범 사례
• Amazon Aurora for PostgreSQL
• Amazon Aurora 고객 사례: Samsung Members

3. Amazon Aurora 개요

4. Amazon Aurora?
• 오픈 소스 호환 관계형 데이터베이스
• MySQL, PostgreSQL
• 상용 데이터베이스의 성능과 가용성 제공
• 오픈소스 데이터베이스의 비용 효율성과 간단함

5. 기존의 관계형 DBMS를 재구성
• SQL+TRANX를 스토리지와 분리:
로깅 및 스토리지를 스케일-아웃 가
능한 스토리지 서비스로 전환
• 서비스 내부에 Amazon EC2, VPC,
DynamoDB, SWF 및 Route 53 등
다른 AWS 서비스들 사용
• 연속적인 백업을 위한 Amazon S
3 와 통합으로 99.999999999% 내
구성 제공
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route
53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3

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. Aurora is used by:
2/3 of top 100 AWS customers
8 of top 10 gaming customers
Aurora 사용 고객
AWS 역사상 가장 빠르게 성장하는 서비스

8. 누가 왜 Aurora로 옮겨오는가?
기존의 상용 DBMS 사용 고객
기존의 MySQL 사용 고객
 최대 5배 빠른 성능
 최대 60%의 비용 절감
 애플리케이션 변경 없이 쉽게 마이그레이션
 라이선스 비용 없이 1/10의 운용 비용
 클라우드와 유기적인 결합
 고성능과 가용성
 마이그레이션 도구와 서비스 지원

9. Amazon Aurora 성능

10. WRITE PERFORMANCE READ PERFORMANCE
MySQL SysBench results
R3.8XL: 32 cores / 244 GB RAM
RDS MySQL에 비해 5배의 성능
Based on industry standard benchmarks
0
25,000
50,000
75,000
100,000
125,000
150,000
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
Aurora MySQL 5.6 MySQL 5.7

11. Aurora의 확장성
With user connection With number of tables
With database size - SYSBENCH With database size - TPCC
Connections
Amazon Auro
ra
RDS MySQL
w/ 30K IOPS
50 40,000 10,000
500 71,000 21,000
5,000 110,000 13,000
Tables
Amazon Aur
ora
MySQL
I2.8XL
local SSD
RDS MySQL
w/ 30K IOPS
(single AZ)
10 60,000 18,000 25,000
100 66,000 19,000 23,000
1,000 64,000 7,000 8,000
10,000 54,000 4,000 5,000
8x
U P T O
F A S T E R
11x
U P T O
F A S T E R
DB Size
Amazon Auro
ra
RDS MySQL
w/ 30K IOPS
1GB 107,000 8,400
10GB 107,000 2,400
100GB 101,000 1,500
1TB 26,000 1,200
DB Size Amazon Aurora
RDS MySQL
w/ 30K IOPS
80GB 12,582 585
800GB 9,406 69
21x
U P T O
F A S T E R
136x
U P T O
F A S T E R

12. 실제 데이터 – 게임 워크로드
Aurora vs. RDS MySQL – r3.4XL
Aurora 3X faster on r3.4xlarge

13. BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F WR I T E
MYSQL WITH STANDBY
EBS 볼륨에 쓰기 수행 - EBS 는 미러에 쓰기 수행, 둘 다 종료
시 ACK
스탠바이 인스턴스에 쓰기 복제
IO FLOW
1, 3, 4 단계는 순차 및 동기
응답 속도 및 지터(Jitter) 가 증대
각 사용자 오퍼레이션을 위한 다양한 쓰기 작업들은 두 번
쓰기
OBSERVATIONS
780K 트랜잭션
1백만 TX 당 7,388K I/Os (미러 및 스탠바이 제외)
TX 당 평균 7.4 I/Os
PERFORMANCE
30분 SysBench 쓰기-전용 워크로드, 100 GB 데이터 셋, RDS SingleAZ, 30K PIOPS
EBS 미러EBS 미러
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
프라이머리
인스턴스
스탠바이
인스턴스
1
2
3
4
5
RDS MySQL I/O 트래픽

14. AZ 1 AZ 3
프라이머리
인스턴스
Amazon S3
AZ 2
복제
인스턴스
AMAZON AURORA
비동기
4/6 쿼럼
분산 쓰기
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F WR I T E
30분 SysBench 쓰기-전용 워크로드, 100 GB 데이터 셋
IO FLOW
오직 Redo 로그 레코드만 쓰기, 모든 단계는 비동기화
데이터 블록 쓰기 없음 (체크포인트, 캐시 대체 등)
6X 로그 쓰기 향상, 9X 네트워크 트래픽 감소
네트워크 및 스토리지 응답속도 증가에 내구성
OBSERVATIONS
27,378K 트랜잭션 35X 향상
1백만 TX 당 950K I/Os (6X amplification) 7.7X 감소
PERFORMANCE
Redo 로그 레코드 전송 – LSN(Log Sequence Number)에
의해 전체 순서화
독립적인 캐시 프로세스에 업데이트
스토리지 노드에 전송 후 쓰기 수행
Aurora I/O 트래픽

15. LOG 레코드
프라이머리
인스턴스
INCOMING QUEUE
스토리지 노드
S3 백업
1
2
3
4
5
6
7
8
업데이트
큐
ACK
핫 로그
데이터
블록
POINT IN TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER-TO-PEER GOSSIP동료
스토리지
노드
모든 단계는 비동기 수행
1단계 및 2단계만 응답속도에 영향 주는 경로
입력 큐는 MySQL 대비 46X 미만 (unamplified, per node)
응답속도-중심 오퍼레이션에 적합
디스크 공간을 스파이크에 대응하기 위한 버퍼로 사용
OBSERVATIONS
IO FLOW
① 로그 레코드 수신 후 인-메모리 큐에 추가
② 업데이트 큐에 로그 레코드 보존하고 바로 ACK 해줌
③ 레코드 구성(grouping) 및 로그의 간극 파악
④ 동료 스토리지 노드와 통신하여 간극 동기화
⑤ 로그 레코드를 신규 데이터 블록 버전으로 통합
⑥ 주기적으로 로그 및 신규 블록 버전을 S3로 전송
⑦ 주기적으로 기존 버전의 블록에 가비지 콜렉션 수행
⑧ 주기적으로 블록에 대한 CRC 검증
Aurora I/O 트래픽 – 스토리지 계층

16. 비동기 그룹 커밋
• TRADITIONAL APPROACH
Read
Write
Commit
Read
Read
T1
Commit (T1)
Commit (T2)
Commit (T3)
LSN 10
LSN 12
LSN 22
LSN 50
LSN 30
LSN 34
LSN 41
LSN 47
LSN 20
LSN 49
Commit (T4)
Commit (T5)
Commit (T6)
Commit (T7)
Commit (T8)
LSN GROWTH
Durable LSN at head node
COMMIT QUEUE
Pending commits in LSN order
TIME
GROUP
COMMIT
TRANSACTIONS
Read
Write
Commit
Read
Read
T1
Read
Write
Commit
Read
Read
Tn
AMAZON AURORA
디스크에 쓰기 위한 로그 레코드의 버퍼 관리
쓰기 작업을 위한 버퍼 풀(Full) 또는 타임아웃 발생 시 쓰기 작업
수행
쓰기 비율이 낮을 때 첫번째 쓰기에 응답속도 페널티
첫번째 쓰기에 I/O 요청.
개별 쓰기는 6개 스토리지 노드 중 4개 쓰기 ACK 시 처리
(내구성을 위한 쿼럼 구성)
비동기식 트랜잭션 처리로 성능 및 효율성 제공

17. Aurora I/O 트래픽 – 읽기 복제
• Logical: SQL 문을 복제에 적용
• 쓰기 부하는 양쪽 노드에서 유사
• 별도 스토리지
• 마스터 및 복제 사이에 데이터 차이 존재
페이지 캐시
업데이트
Aurora 마스터
30% 읽기
70% 쓰기
Aurora 복제
100% 신규 읽기
공유 Multi-AZ 스토리지
MySQL 마스터
30% 읽기
70% 쓰기
MySQL 복제
30% 신규 읽기
70% 쓰기
싱글-스레드
BINLOG 전송
데이터 볼륨 데이터 볼륨
Physical: 마스터에서 복제로 redo를 전송
복제는 스토리지를 공유
쓰기 수행 없음
캐시된 페이지는 Redo 적용
MYSQL READ SCALING AMAZON AURORA READ SCALING

18. • 다중 스레드풀과 멀티플렉싱을 통한 처리
• 커널 영역의 epoll() 통한 latch-free 이벤트 큐 입력
• 스레드 풀 크기 동적 조정
• 5000+ 동시 클라이언트 세션을 r3.8xl에서 처리
적응형 스레드풀
표준 MySQL— 접속 당 스레드
접속 수 증가에 확장되지 않음
MySQL EE — 접속은 스레드 그룹에 할당
스레드 블로킹 되는 경우에 효율 저하
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL

19. Scan
Delete
Aurora 잠금(lock) 관리
 SQL 레벨에서의 락 개념은 MySQL과 같음
 내부적으로는 Lock-chain에 동시 접근 가능하도록 수정됨
 각각의 Lock-chain 내에서도 다수의 읽기 가능
 내부적으로 Lock-free 자료 구조 적극 활용을 통한 Deadlock 방지
Scan
Delete
Insert
Scan Scan
Insert
Delete
Scan
Insert
Insert
MySQL lock manager Aurora lock manager
많은 동시 세션들 지원을 위해 최적화  높은 업데이트 출력량(throughput)

20. Cached 데이터 읽기 성능 개선
• Catalog concurrency: 데이터 딕셔너리 동기
화와 캐시 퇴거(eviction)를 개선
• NUMA 인식 스케줄러: Aurora scheduler는 이
제 NUMA를 고려함. 멀티 소켓 인스턴스의 확
장성에 도움
• 읽기 뷰(Read views): 읽기 뷰 생성시 잠금 없
는 (latch-free) 동시성 읽기 알고리즘을 이용함
0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora
2015
Aurora
2016
In thousands of read requests/sec
* R3.8xlarge instance, <1GB dataset using Sysbench
25% 출력량 증가

21. • Smart scheduler: Aurora 스케줄러가 스레드
를 처리할 때, I/O heavy 인가 CPU heavy 인가
에 따라 동적 할당
• Smart selector: Aurora는 카피된 스토리지 노
드중 가장 성능이 좋은 것을 자동 선택함으로
써 읽기 지연을 감소시킴
• 논리적 선행읽기(LRA): B트리 안에서 페이지
를 순서대로 메모리에 prefetch 함으로써 읽기
I/O를 줄임
Non-cached 데이터 읽기 성능 개선
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora
2015
Aurora
2016
In thousands of requests/sec
* R3.8xlarge instance, 1TB dataset using Sysbench
10% 출력량 증가

22.  Primary Key 정렬로 배치 삽입 가속: 인덱
스 경유하지 않고 커서 포지션을 캐싱함으로써
동작
 데이터 패턴에 따라 동적으로 스스로 기
능을 끄거나 켬
 트리를 따라 내려가는 동안 Lock을 획득
하기 위한 경합을 피함
 모든 INSERT 구문에서 작동
• LOAD INFILE
• INSERT INTO SELECT
• INSERT INTO REPLACE
• Multi-value 삽입시
배치 삽입(Insert) 성능 향상
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL: B-tree 루트로부터 시작 인서트 최종까지 경유
Aurora: 인덱스 경유를 피함

23. 더 빠른 인덱스 빌드
 MySQL 5.6은 Linux의 선행읽기(read ahead)
적용: 이 방식은 결국 B트리내의 블록별
주소를 요구
 Aurora는 B트리 안의 위치에 기반한 미리
가져온(prefetch) 블록을 스캔하며, 이는 블록
주소를 요구하지 않음
 Aurora는 B트리의 Leaf 블록을 먼저 빌드하고
Branch를 빌드함
• 빌드중 트리 분할 없음
• 각각의 페이지는 한번씩만 터치
• 페이지당 하나의 로그 레코드
2-4X better than MySQL 5.6 or MySQL 5.7
0
2
4
6
8
10
12
r3.large on
10GB dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours
RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

24. 공간 인덱스
• 공간 데이터 저장의 필요성
• 예: “병원으로부터 1KM내의 모든 사람을 찾아라＂
• 공간 데이터는 다중 차원(multi-dimensional)
• B-Tree 인덱스는 단차원(one-dimensional)
• Aurora 공간 데이터 타입 지원 (point/polygon)
• GEOMETRY 데이터 타입 지원 (from MySQL 5.6)
• 원래 이런 타입의 공간 데이터는 인덱스 불가
• 두 가지 가능한 방법
• 공간 데이터를 위한 접근 방법 특화 (예: R-Tree)
• 다중 차원의 공간 데이터를 B-Tree 단차원 공간으로 맵핑할
수 있는 메커니즘 적용 (Z-index)
A
B
A A
A A
A A A
B
B
B
B
B
A COVERS B
COVEREDBY A
A CONTAINS B
INSIDE A
A TOUCH B
TOUCH A
A OVERLAPBDYINTERSECT B
OVERLAPBDYINTERSECT A
A OVERLAPBDYDISJOINT B
OVERLAPBDYDISJOINT A
A EQUAL B
EQUAL A
A DISJOINT B
DISJOINT A
A COVERS B
ON A

25. Aurora에서의 공간 인덱스
Z-index used in Aurora
R-Tree의 문제
• 잘 균형 잡혀있을 때 효율적
• 사각형이 중첩되거나 빈 공간을 덮으면 안됨
• 시간이 지남에 따라 악화
• 재 인덱싱 비용이 높음
R-Tree used in MySQL 5.7
Z-index (z-order-curve)
• 저장, 인덱싱에 기본적인 B-Tree 사용
• 공간을 차원적으로 순서화해서 곡선 형태로 표현
• 데이터 지역성(locality) 보존: 캐시 친화적

26. 공간 인덱스 벤치마크
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . .. .
. . . . . . . . . . . . .
• Sysbench: points 및 Polygons 대상
• r3.8xlarge using Sysbench on <1GB dataset
• Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS
0
20000
40000
60000
80000
100000
120000
140000
Select-only (reads/sec) Write-only (writes/sec)
Aurora
MySQL 5.7

27.  Full Table 복사: 인덱스 재구성 (수시간 이상 소요)
 DML을 위한 임시 공간 필요
 DDL은 DML 스루풋에 큰 영향을 줌
 DML을 통한 변경시 테이블 단위의 잠금(lock) 걸림
 메타데이터 테이블에 변경 항목을 기록을 통한 버저닝:
변경 사항을 차례대로 읽어와서 적용
 Modify-On-Write 적용을 통한 실제 데이터 변경시에
스키마 적용
 현재는 테이블 끝에 NULLable 컬럼 추가 지원
 (곧) 다른 타입의 컬럼 추가 지원, 컬럼 드랍 및 순서 바
꿈, 데이터 타입 변경 지원
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
MySQL Amazon Aurora
Online DDL: Aurora vs MySQL

28. On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec
Online DDL 성능
https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-fast-ddl/

29. Amazon Aurora 가용성

30. 스토리지 자가 치유 및 장애 내구성
• 자동 장애 감지, 복제, 복구
• 2개의 복제 및 1개 가용 영역 장애는 읽기 및 쓰기 가용성에 영향 없음
• 3개의 복제 장애에도 읽기 가용성에 영향 없음
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability

31. Aurora의 스토리지 백업 및 복구
• 자동 백업(Automated Backup)
• RDS는 백업을 자동으로 생성
• 신규 DB 인스턴스에 자동으로 활성화
• 백업 보관 기간(Backup Retention Period)
동안 데이터 보관 (1~35일)
• 연속 및 증분 백업
• 백업 중 성능 영향 없음
• 스냅샷 (DB Snapshots)
• 사용자가 생성한 백업
• 원하는 주기로 백업
• 백업 보관 기간 이상 보관
• 어느 시점으로도 복구 가능

32. Aurora의 스토리지 백업 및 복구
• 복구 (Restore)
• 백업 또는 스냅샷으로부터 신규 Aurora D
B 클러스터 생성
• 백업 보관 주기 내 어느 시점으로든 복구
• Latest Restorable Time : 보통 5분 이내
• Earliest Restorable Time : 백업 보관 주기
• Aurora Backup은 연속, 증분 백업으로 복
구 시간 향상을 위해 빈번한 스냅샷 생성
을 할 필요 없음

33. Aurora의 인스턴스 자동 Fail-over
• 읽기 복제 있는 경우
• 기존 복제를 새 기본 인스턴스로 승격
• failover 대상 인스턴스 우선 순위 지정 가능
• DB 클러스터 엔드포인트 유지하며, 신규 기
본 인스턴스로 DNS 레코드 변경
• 일반적으로 1분 이내에 완료
AZ 1
Primary
instance
Replica
instance
Replica
instance
Replica
instance
Shared Multi-AZ Storage
Automatic
Failover to
Replica
Instance
AZ 1
Primary
instance
Primary
instance
Shared Multi-AZ Storage
Create new
primary
Instance
Aurora Replica가 있는 경우 Aurora Replica가 없는 경우
읽기 복제 없는 경우
• 동일 가용 영역에 새 DB 인스턴스 생성 시도
• 생성 불가 시 다른 가용 영역에 신규 DB
인스턴스 생성 시도
• 일반적으로 15분 이내에 완료
AZ 3AZ 2AZ 3AZ 2
Primary
instance

34. 신속한 크래시 복구
• 최종 체크포인트 이후 로그 재생 필요
• MySQL은 싱글-쓰레드 동작 및 다량의
디스크 억세스 필요
• 스토리지 수준에서 redo 레코드를 on-
demand로 재생
• 병렬, 분산, 비동기
• 기존 데이터베이스 • Amazon Aurora
Checkpointed Data Redo Log
Crash at T0 requires
a re-application of the
SQL in the redo log since
last checkpoint
T0 T0
Crash at T0 will result in redo
logs being applied to each segment
on demand, in parallel, asynchronously

35. 독립적인 캐시 유지
• 데이터베이스 프로세스와 캐시
의 분리
• 데이터베이스 재기동 이벤트 시
에도 캐시 웜(warm) 상태 유지
• 전체 캐시 활성화가 신속
• 즉각적인 크래시 복구 + 캐시 유
지 = 빠르고 손쉬운 DB 장애 복
구
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Caching process is outside the DB process
and remains warm across a database restart.

36. 보다 신속하고 예측 가능한 Fail-over
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORA WITH MARIADB DRIVER
1 5 – 2 0 초
3 – 2 0 초

37. Networking
state
Application
state
Storage Service
App
state
Net
state
App
state
Net
state
BeforeZDP
New DB
Engine
Old DB
Engine
New DB
Engine
Old DB
Engine
WithZDP
User sessions terminate
during patching
User sessions remain
active through patching
Storage Service
제로 다운타임 패치

38. SQL로 장애 시뮬레이션 지원
• To cause the failure of a component at the database node:
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
• To simulate the failure of disks:
ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval
• To simulate the failure of networking:
ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval

39. 운영 모범 사례

40. MySQL로부터의 마이그레이션
MySQL
shards
AuroraDMSMySQL
shards
MySQL
shards
EC2
MySQL
Take snapshot;
Load to S3
Ingest snapshot
into Aurora
RDS
MySQL Aurora
Ingest snapshot
Catchup using
binlog
replication
Aurora
RDS MYSQL to Aurora EC2/on-premises
MYSQL to Aurora
Many-to-one
migration
RDS 스냅샷으로부터
마이그레이션 후 Binlog 복제
S3를 통한 스냅샷 전달
mysqldump / mysqlimport
DMS를 이용한 데이터 복제
Amazon S3

41. 데이터 복사: 원본 테이블의 데이터를 대상 테이블로 복사
변경 데이터 증분 복사 (CDC): 원본 데이터의 변경 사항은 테이블이
복사되는 동안 따로 버퍼링. 테이블 복사가 완료되면 버퍼링 되어 있던 변경
데이터를 대상에 적용. 추가 변경 사항은 작업이 종료될때까지 계속 적용됨AWS Database
Migration Service
AWS Schema
Conversion Tool
Oracle, SQL Server로 부터의 마이그레이션
SCT 평가 보고서: 원본 데이터베이스를 분석하고 권장되는 대상 엔진 및
자동/수동 변환 정보를 제공
코드 브라우저 및 권장 엔진: 수동 편집이 필요한 곳을 강조 표시하고
아키텍처 및 디자인 지침을 제공

42. SCT 코드 브라우저 및 평가 도구

43. DMS를 통한 데이터 마이그레이션
Replication
Instance
Oracle /
SQL Server Aurora
Change logs
Data pages
 스냅샷 전송, 라이브 복제, 부트스트랩
이후 라이브 복제 중에서 선택
 기존 테이블을 덮어 쓰거나 추가할
것인지 선택
 테이블 복제시 병렬 처리 정도 선택
(기본값은 8)
 원본과 대상 사이에서의 테이블간 맵핑
생성
 마이그레이션 시작후 진행 상황 관찰
• 복제 역할을 하는 인스턴스가 생성되어 데이터를 복제
• 인스턴스상의 각 프로세스는 하나의 전체 테이블을 로드
• 재시작시 중단된 곳부터 계속 됨

44. AWS 서비스 연동 기능 활용
Lambda
S3
IAM
CloudWatch
Aurora 스토어드 프로시저로 부터 Lambda 호출 가능
S3에 스냅샷 백업 및 복원 가능
DBMS 접근 제어에 IAM role 사용 가능
시스템 메트릭 및 감사 로그를 CloudWatch에 전송 가능

45. AWS Lambda와의 Integration
Stored Procedure
Amazon Lambda
Database Node.js, Java, Python, C#

46. import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
logger.info('I am from Aurora')
return 'Hello World!'

47. mysql> use auroraworkshop;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with –A
mysql> DROP PROCEDURE IF EXISTS InvokeLambda;
Query OK, 0 rows affected, 1 warning (0.02 sec)
mysql> DELIMITER ;;
mysql> CREATE PROCEDURE InvokeLambda() LANGUAGE SQL
-> BEGIN CALL mysql.lambda_async('arn:aws:lambda:us-east-1:549632206553:function:func-aurora-test','');
-> END ;;
Query OK, 0 rows affected (0.01 sec)
mysql> DELIMITER ;
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.10 sec)
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.07 sec)
mysql> call InvokeLambda();
Query OK, 0 rows affected (0.07 sec)

49. 고급 모니터링 활용
50+ 개 이상의 시스템/OS 메트릭 | 정렬된 process list 뷰 제공 | 1–60 초단위 측정값 제공
메트릭에 알람 설정 | CloudWatch Logs 연동 | 3rd-party 도구 연동 지원
ALARM

50. 읽기 복제본 활용
Master
Read
Replica
Read
Replica
Read
Replica
Shared distributed storage volume
Reader end-point
읽기 부하 분산을 통하여 애플리케이션 성능 향상 및
고가용성 제공
 복제본은 일반적으로 몇 분 내에 생성, 삭제, 확장
할 수 있음
 다수의 읽기 복제본에 대해 부하 분산되는 공용
엔드포인트 제공으로 애플리케이션 수정이
필요하지 않음
 스토리지 노드 공유로 복제 지연 시간이 아주 낮음
(10ms 이내)
 최대 15개까지의 (Failover로) 승격 가능한 읽기
복제본을 통한 고가용성 확보

51. 리전간 읽기 복제본 활용
• 리전 단위 재난시 타 리전의
복제본으로부터 빠른 복구
• 다른 지역의 고객에 데이터를
가까이 배치하여 최적화된 애
플리케이션 경험 제공
• 타 지역의 복제본을 마스터로
승격함으로써 마이그레이션
가능

52. 느린 쿼리 찾기: 로깅
파라미터 편집을 통해 느린 쿼리
로깅
• Slow_query_log : 로깅 활성화 여부
• Long_query_time : 느린 쿼리의
성능 기준
• Log_queries_not_using_indexes :
인덱스 미 사용 쿼리에 대한 로깅
여부

53. 인덱스를 활용 여부에 대한 판단
• EXPLAIN “쿼리”
• Select_type : DERIVED, UNCACHEABLE SUBQUERY, DEPENDENT SUBQUERY
• Type : ALL, index
• Key : 의도한 내용인지 확인
• Row : 결과에 비해 매우 큰 값이 아닌지 확인 Index 활용 여부 및 Key 값과 같이 확인
• Extra : Distinct, Using Index, Using index for group-by
주요 고려 사항

54. 쿼리 수행 최적화
• 인덱스 활용
• 조인 쿼리 힌트 제공
• ANALYZE TABLE ‘TABLE NAME’
• 대량의 데이터 변화 및 스키마 변경시 ANALYZE 자동 수행

55. 성능 모범 사례 정리
 기존의 SQL레벨의 RDBMS 성능 향상 방식은 여전히 동일
 가능한 동시접속 사용을 높임
 Aurora 출력량은 커넥션 갯수에 따라 증가
 읽기 확장을 적극 활용
 리드 복제의 지연이 극히 낮음, 여러 읽기 분산으로 전체 성능 향상
 파라미터 튜닝
 기존의 모든 MySQL파라미터를 Aurora에 적용할 필요 없음
 기본 Aurora 파라미터는 충분히 최적화
 퍼포먼스 비교
 개별 지표(CPU, IOPS, IO throughput)에 너무 의존하 말 것
 어플리케이션 측에서의 실제 성능 확인
 기타
 CloudWatch 메트릭 참고

56. 비용 절감 사례: Aurora의 비용 체계
단순한 비용 모델
라이선스 없음
최소 요금 없음
• 사용한 부분에 대해서만 비용 지불
예약 인스턴스 요금
• 1년 예약인스턴스 시 최대 44%
• 3년 예약인스턴스 시 최대 63%
인스턴스 vCPU 메모리 시간당 요금
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0.58
db.r3.2xlarge 8 61 $1.16
db.r3.4xlarge 16 122 $2.32
db.r3.8xlarge 32 244 $4.64
스토리지 요금 $0.100 월별 GB당
I/O 요금 $0.200 요청 100만 건당
* Virginia 지역 기준

57. 소유 비용: Aurora vs. MySQL
MySQL 구성 시간 당 비용
프라이머리
r3.8xl
스탠바이
r3.8xl
복제
r3.8xl
복제
r3.8xl
스토리지
6TB/10K PIOPS
스토리지
6TB/10K PIOPS
스토리지
6TB/5K PIOPS
스토리지
6TB/5K PIOPS
$3.78/hr
$3.78/hr
$3.78/hr $3.78/hr
$2,42/hr
$2,42/hr $2,42/hr
인스턴스 비용 : $15.12 / hr
스토리지 비용 : $8.30 / hr
총 비용 : $23.42 / hr
$2,42/hr

58. 소유 비용: Aurora vs. MySQL
Aurora 구성 시간 당 비용
프라이머리
r3.8xl
복제
r3.8xl
복제
r3.8xl
스토리지 / 6 TB
$4.64 / hr $4.64 / hr $4.64 / hr
$4.43 / hr
21.6%
Savings
 대기 중인 스탠바이 인스턴스 없음
 단일 공유 볼륨
 PIOPS 없음 – I/O 사용량 만큼 지불
 전반적인 IOPS 비용 감소
인스턴스 비용 : $13.92 / hr
스토리지 비용 : $4.43 / hr
총 비용 : $18.35 / hr

59. Aurora 구성을 통한 추가 비용 절감
프라이머리
r3.8xl
r3.4xl
복제
r3.8xl
r3.4xl
복제
r3.8xl
r3.4xl
스토리지 / 6 TB
$2.32 / hr $2.32 / hr $2.32 / hr
$4.43 / hr
51.3%
Savings
 더 작은 인스턴스 사용 가능
 Pay-as-you-go 스토리지
인스턴스 비용 : $6.96 / hr
스토리지 비용 : $4.43 / hr
총 비용 : $11.39 / hr

60. MariaDB server audit plugin Aurora native audit support
• We can sustain over 500K events/sec
Create event string
DDL
DML
Query
DCL
Connect
Write
to File
DDL
DML
Query
DCL
Connect
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free
queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance
Aurora 고급 감사 기능

61. Aurora for PostgreSQL

62.  Oracle과 가장 호환성이 높은 오픈 소스 데이터베이스
 20 년간 활발히 개발 중
 혁신 친화적인 오픈소스 라이센스
 회사가 아니라 재단에 의해 소유됨
 높은 성능
 객체 지향과 ANSI-SQL:2008 호환
 오픈 소스중에서 가장 뛰어난 공간정보 기능 보유
 12가지 언어로 스토어드 프로시저 지원
 Java, Perl, Python, Ruby, Tcl, C/C++, PL/pgSQL 등
 AWS Schema Conversion Tool을 사용해서 Oracle로 부터
PostgreSQL 전환에 있어서 가장 높은 자동 전환률
PostgreSQL 개요
Open Source Initiative

63. PostgreSQL vs. Oracle
Property PostgreSQL Oracle
Schema & Pre-defined Data Types Yes Yes
Secondary Indexes Yes Yes
SQL Yes Yes
API Framework C, ADO.NET, JDBC, ODBC ODP.NET, Oracle Call Interface (OCI),
JDBC, and ODBC
Triggers Yes Yes
Partitioning Can be achieved using extensions Yes
Replication Master-Slave Master-Slave and Master-Master
MapReduce APIs No No
Foreign Keys Yes Yes
Transactions ACID ACID
In-Memory No Yes
XML Support No Yes
Reporting Reporting Available Yes
Spatial PostGIS Yes

64. PostgreSQL vs. SQL Server
Property PostgreSQL SQL Server
Schema & Pre-defined Data Types Yes Yes
Secondary Indexes Yes Yes
SQL Yes Yes
API Framework C, ADO.NET, JDBC, ODBC OLE DB, Tabular Data Stream (TDS), ADO.
NET, JDBC, ODBC
Triggers Yes Yes
Partitioning Can be achieved using extensions Yes
Replication Master-Slave Master-Slave
MapReduce APIs No No
Foreign Keys Yes Yes
Transactions ACID ACID
In-Memory No Yes
XML Support No Yes
Reporting Reporting Available Yes
Spatial PostGIS Yes

65. • PostgreSQL
성능 측정을 위한 시스템 구성
• Amazon Aurora
AZ 1
EBS EBS EBS
45,000 total IOPS
AZ 1 AZ 2 AZ 3
Amazon S3
m4.16xlarge
database
instance
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
c4.8xlarge
client
driver
m4.16xlarge
database
instance
c4.8xlarge
client
driver
ext4 filesystem
m4.16xlarge (64 VCPU, 256GiB), c4.8xlarge (36 VCPU, 60GiB)

66. PGBENCH 결과
pgbench “tpcb-like” workload, scale 2000 (30GiB). All configurations run for 60 minutes

67. SYSBENCH 결과
SysBench oltp(write-only) workload with 30 GB database with 250 tables and 400,000 initial rows per table

68. 더 빠른 데이터 로드
Command: pgbench -i -s 2000 –F 90

69. 더 빠른 응답 시간
SysBench oltp(write-only) 23GiB workload with 250 tables and 300,000 initial rows per table. 10-minute warmup.

70. 더욱 일관성있는 출력(Throughput)
PgBench “tpcb-like” workload at scale 2000. Amazon Aurora was run with 1280 clients. PostgreSQL was run with
512 clients (the concurrency at which it delivered the best overall throughput)

71. 데이터 용량이 증가할수록 더 빠름
SysBench oltp(write-only) – 10GiB with 250 tables & 150,000 rows and 100GiB with 250 tables & 1,500,000 rows
75,666
27,491
112,390
82,714
0
20,000
40,000
60,000
80,000
100,000
120,000
10GB 100GB
writes/sec
SysBench Test Size
SysBench write-only
PostgreSQL Amazon Aurora

72. 더 빠른 크래시 리커버리
SysBench oltp(write-only) 10GiB workload with 250 tables & 150,000 rows
즉각 복원이 가능한 트랜잭션 기반의 스토리지 시스템!

73. Aurora 와 PostgreSQL 성능 비교 결과

74. 직접 사용해보기
• Amazon Aurora for PostgreSQL 업데이트
• https://aws.amazon.com/ko/blogs/korea/amazon-aurora-update-p
ostgresql-compatibility/
• 테스트를 위한 프리뷰 신청
• https://pages.awscloud.com/amazon-aurora-with-postgresql-comp
atibility-preview-form.html

75. Samsung Members
Aurora 사용 사례
서기언
삼성전자 무선사업부

76. Samsung Members
Aurora 사용 사례
Samsung Members 소개
Samsung Members
소개 동영상

77. Samsung Members
Schema Migration 사례
Community DB Schema Migration
배경
- Community 버전 Upgrade 에 따른 대규모 Schema 변경.
목표
- 별도 스크립트 작성 없이 SQL Query 만으로 Migration.
- Migration 작업이 서비스에 영향을 주지 않아야 함.
- 모든 사용자의 클라이언트가 업데이트 완료 될 때 까지 두 버전 모두 동작 해야 함.
결과
- 서비스 중단 및 지연 없이 대규모 Schema 변경이 포함된 Version Upgrade 작업 진행.

78. Samsung Members
Schema Migration 사례
Community DB Schema Migration
V 1.0
V 1.0(Replication) +
V 2.0 (Master)
V 1.0
V 2.0
V 1.0 API
V 2.0 API
V1.0 WA
S
V2.0 WA
S
Replication 증분 Migration
Batch
전체 Migration
1.0 -> 2.0

79. Samsung Members
Schema Migration 사례
적용 방법
1. Binlog 보관 기간 설정 (7일)
> CALL mysql.rds_set_configuration ('binlog retention hours', 168);
2. Master Cluster에 복제 사용자 생성.
> CREATE USER ‘repl_user’@’%’ IDENTIFIED BY ‘yourpassword’;
> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ‘repl_user’@’%’ IDENTIFIED BY
‘yourpassword’;
3. Master의 Binlog file 및 position 확인 (메모)
> SHOW MASTER STATUS;
TIP. 특히 Binlog File 명은 향우 Slave 에서 Replication 활성화 할 때 사용
4. Master의 Snapshot으로 부터 신규 Instance 생성

80. Samsung Members
Schema Migration 사례
적용 방법 (계속)
5. Slave Cluster에서 복제를 시작할 Binlog 파일 및 position 확인.
> SHOW MASTER STAUTS;
TIP. SHOW MASTER STAUTS 의 결과에 Master Instance에서 메모한 파일 명이 보이지 않으면
> SHOW BINARY LOGS;
6. Slave Cluster에서 복제 활성화
> CALL mysql.rds_set_external_master
('your master end-point', 3306, 'repl_user', '‘yourpassword’', 'mysql-bin-changelog.000036', 110382596, 0);
> CALL mysql.rds_start_replication;
7. 복제 모니터링
> SHOW SLAVE STATUS;
Second_Behind_Master = 0
8. New (2.0) Schema 생성
TIP. 증분 Migration 되는 데이터와, 2.0으로 바로 Insert 되는 데이터의 Key 중복을 피하기 위해
PK (Auto increment) 시작 값을 1.0 대비 충분히 크게 하면 좋음.
9. 1.0 -> 2.0 Migration 수행

81. Samsung Members
Region 이전 사례
Aurora Region 이전
배경
- Members 전체 인프라의 Region 이동.
목표.
- DB 이전 도중 예외 상황 발생 가능성 최소화.
- DB 이전에 걸리는 시간 최소화로 서비스 중단 시간 단축.
- 가능한 부분은 최대한 사전에 작업.
방법.
- Aurora Cross Region Replica 활용.
Region A Region B
Region C

82. Samsung Members
Region 이전 사례
Aurora Region 이전
방법
- Cross Region Replica 생성
(Region 이동 작업 이전에 미리 생성.)
- 트래픽 차단
- 차단 확인 후 Replica를 Master로 승격
- Route53에서 DNS 변경
결과
- DB Region 이전에 걸린 시간 10분 이내.
(Replica의 Master 승격 시간)
- 간단한 방법으로 모든 준비를 사전에.
- 실제 이전 작업시점엔 클릭 몇 번으로 작업 완료 From Region To Region

83. 감사합니다