[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS 솔루션즈 아키텍트

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Aurora로 게임 데이터베이스 레벨 업!
김병수 | 솔루션즈 아키텍트

Agenda
• RDS – Aurora 개요 및 성능
• Aurora 고급기능
• Backtrack
• Clone
• Serverless
• Global database

RDS – Aurora 개요 및 성능

Amazon RDS
• 어플리케이션을 위한 최적의 데이터베이스 선택을 제공
오픈 소스 엔진 상용 엔진클라우드 네이티브 엔진

 하이엔드 데이터베이스 수준의 성능과 가용성
 오픈소스 데이터베이스의 단순함과 비용 효율성
 MySQL와 PostgreSQL 데이터베이스와의 호환성
 단순히 사용한 만큼만 지불하는 과금 방식
 관리형 데이터베이스 서비스로써 제공
Amazon Aurora
Amazon Aurora

Storage
SQL
Transactions
Caching
Logging
Compute
전통적인 데이터베이스 아키텍처
하나의 박스에 구성된 Monolithic Stack
➢모놀리틱 아키텍처
❖ SQL
❖ Transaction
❖ Caching
❖ Logging
❖ Storage
➢고분산 환경의 Cloud architectur에 최적화되지 않음
레이어 분리

Aurora : Re-architecting for Cloud
➢ 가용성, 내구성, 성능간의 트레이드 오프 최소화
➢ Log applicator를 스토리지로 내림
➢ 4/6 쓰기 쿼럼 & 로컬 트래킹
✓ 쓰기 성능
✓ 읽기 스케일 아웃
✓ 장애 대항력
✓ 즉각적인 데이터베이스 redo 복구
Master Replica Replica
Master Replica
Shared storage volume
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
AZ1 AZ2 AZ3
▪
▪
▪
▪

MySQL vs. Aurora I/O 성능 측정
BINLOG DATA DOUBLE-WRITELOG FRM FILES
TYPE OF WRITE
MYSQL WITH REPLICA
EBS mirrorEBS mirror
AZ 1 AZ 2
EBS
Amazon Elastic
Block Store (EBS)
Primary
Instance
Replica
Instance
1
2
3
4
5
AZ 1 AZ 3
Primary
Instance
AZ 2
Replica
Instance
ASYNC
4/6 QUORUM
DISTRIBUTED WRITES
Replica
Instance
AMAZON AURORA
0.78MM transactions
7.4 I/Os per transaction
30분간 Sysbench 수행시 MySQL I/O 측정
27MM transactions 35X 더 많음
0.95 I/Os per transaction 7.7X 더 적음
30분간 Sysbench 수행시 Aurora IO 측정

읽기와 쓰기 처리량 측정
Aurora MySQL이 MySQL보다 5배 높은 성능 제공
0
50,000
100,000
150,000
200,000
250,000
MySQL 5.6 MySQL 5.7 MySQL 8.0
Aurora 5.6 Aurora 5.7
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
MySQL 5.6 MySQL 5.7 MySQL 8.0
Aurora 5.6 Aurora 5.7
쓰기 처리량 읽기 처리량
< 250개 테이블과 200,000 row/table을 Sysbench로 R4.16XL에서 측정 >
20~35X 더 높은
쓰기 처리량
2.5X 더 높은
읽기 처리량

벌크 데이터 로딩 성능
Aurora MySQL이 MySQL보다 2.5배 높은 성능 제공
Data loading
Data loading
Index build
Index build
0 100 200 300 400 500 600 700 800
MySQL
Amazon
Aurora
Runtime (sec.)
< 10개 테이블과 10M row/table을 Sysbench로 R4.16XL에서 측정 >

읽기(Read) 스케일아웃
PAGE CACHE
UPDATE
Aurora Master
30% Read
70% Write
Aurora Replica
100% New Reads
Shared Multi-AZ Storage
MySQL Master
30% Read
70% Write
MySQL Replica
30% New Reads
70% Write
SINGLE-THREADED
BINLOG APPLY
Data Volume Data Volume
MYSQL READ SCALING AMAZON AURORA READ SCALING
변경 부분 전달 방식의 물리적 복제 및 페이지 캐시만 업데이트
복제에 쓰기 없음
공유 스토리지
완전 변경 사항 전달 방식의 논리적 BINLOG 복제
동일한 쓰기 워크로드
복제별 독립 스토리지

읽기 복제 방식 비교
“MySQL에서 거의 매 12분마다 치솟는 복제 lag이 있었으며, 어플리케이션
관점에서는 불합리한 것 이었습니다. Aurora에서는 4개의 replica들에서
발생하는 최대 read replica lag이 20ms을 넘지 않았습니다.”
Binlog Replica Lag (sec.) Aurora Physical Replica Lag (msec)Aurora Logical Replica Lag (seconds)

처리량 최적화 – 커넥션 처리 스레드 모델
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
.

처리량 최적화 – Lock Manager
Scan
Delete
Scan
Delete
Insert
Scan Scan
Insert
Delete
Scan
Insert
Insert
MYSQL LOCK MANAGER AURORA LOCK MANAGER

부하시 성능 변화 측정
< SysBench OLTP (write-only) 워크로드 / 250개 테이블과 200,000 row/table을 R4.16XL에서 측정 >
0
2
4
6
8
10
12
0 100 200 300 400 500 600
Time in seconds
Write Response Time (seconds)
Amazon Aurora
MySQL 5.6 on EBS

Online DDL: Aurora vs. MySQL
▪ 블록을 디코딩하기위해 스키마 버저닝 사용
▪ 최신의 스키마로 업그레이드 하기 위해 Modify-on-write 사용
▪ 테이블이 끝에 NULLable columns 추가 지원
▪ Columns을 어느 곳에나 추가
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
▪ 전체 테이블 복제; 모든 인덱스 리빌딩
▪ DML을 위한 임시 공간 필요
▪ DDL 연산이 DML 처리에 영향을 줌
▪ Table lock이 DML 변경을 적용하기 위해 필요

Online DLL 성능 측정 결과
On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec

성능 파라미터 튜닝
Aurora에서는 중요하지 않은 파라미터
innodb_log_file_size innodb_log_files_in_group
innodb_doublewrite
Innodb_write_io_threads
innodb_checksum_algorithm
innodb_use_native_aio
innodb_io_capacity
innodb_adaptive_flushing
innodb_flush_neighbors
innodb_max_dirty_pages_pct
innodb_log_buffer_size
하드웨어 구성에 따라 사전에 튜닝되어 있는 파라미터
table_open_cache table_open_cache_instances
innodb_buffer_pool_size and innodb_buffer_pool_instances
innodb_thread_concurrency
innodb_spin_wait_delay
innodb_read_io_threads
innodb_purge_threads
innodb_adaptive_hash_index
Aurora는 자동으로 사전 튜닝 및 자동 튜닝을 통해 각기 다른 하드웨어 구성에 각기
다른 파라미터를 적용하고 있습니다. 따라서, 고객이 아주 특별한 요구사항을
가지고 있지 않다면, 아무 튜닝 없이 최적의 성능을 가질 수 있습니다.

.
MySQL 성능 파라미터 튜닝 예시
SysBench OLTP (write-only) 10GiB 워크로드 / 250대 테이블과 200,000개 rows
No more trade-offs!
Recovery time (sec.): 376.0
Write/s: 90,606
Write/s: 26,129
Write/s: 4,382
Write/s: 207,398
0 50,000 100,000 150,000 200,000
0 50 100 150 200 250 300 350 400 450 500
MySQL (16GB Checkpoint)
MySQL (1GB Checkpoint)
MySQL (128MB Checkpoint)
Amazon Aurora
Writes per Second
Recovery Time (sec.)

실제 적용사례 - Grani
적용전 : R3.4xlarge RDS MySQL Multi-AZ
평균 total response time : 51.5ms
Database response time : 15 ~22 ms
51.5ms
20ms

적용후 : R3.4xlarge RDS Aurora Multi-AZ ( 1 master, 1 read replica )
평균 total response time : 36.5ms
Database response time : 5.5 ms
36.5ms

RDS MySQL
RDS Aurora

RDS – Aurora 고급기능

Backtrack
Backtrack 기능은 백업에서 복원하지 않고도 특정 시점으로 데이터베이스를 되돌릴 수 있습니다. (수 분 vs. 수 시간)
• 의도하지 않거나, 실수로 인한 DML 혹은 DDL 작업으로 부터 Backtrack 수행
• Backtrack은 데이터를 파괴하지 않으므로, 앞 뒤로 여러번 수행하면서 올바른 시점을 찾을 수 있음
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible

Backtrack
➢ 역추적 기능이 활성화된 상태에서 생성한 DB
클러스터에서만 역추적 가능
➢ 역추적 기간 제한은 72시간
➢ 역추적은 전체 DB 클러스터 대상
❖ 단일 테이블 또는 단일 데이터 선택적
역추적불가.
➢ Aurora MySQL 5.6만 지원
❖ 역추적이 활성화된 Aurora MySQL 5.6 DB
클러스터의 스냅샷을 Aurora MySQL 5.7로
복원 불가.
❖ 역추적이 활성화된 Aurora MySQL 5.6 DB
클러스터에서 특정 시점으로 복구 스냅샷을
Aurora MySQL 5.7로 복원 불가

PITR vs Backtrack
PITR BackTrack
복원가능기간 Up to 35 days Up to 72 hours
지원 DB engine RDS가 지원하는 전체 DB Engine 지원 RDS Aurora MySQL 5.6 only
복원가능시점 최근복원시점(5분이내)부터 복원가능
기간 내 지정시점
복원가능기간 내 지정시점
복원지점탐색 특점 지점별로 개별 복원하면서 탐색 연속적으로 앞뒤로 반복하며 탐색가능
복원시간 데이터 양에 따라 수분에서 수시간 수분이내
복원대상 별도 인스턴스/클러스터로 복원 같은 인스턴스/클러스터 내에서 앞뒤로 역
추적

Clone
➢빠른 DB 복제
✓스토리지 공유를 통한 빠른 DB Cloning (수분)
✓Copy-on-Write 복제
➢유즈케이스
✓테스트 용도로 프로덕션 데이터베이스 복제
✓데이터베이스 재구성
✓분석을 위해 프로덕션 영향 없이 특정 시점
스냅샷으로 활용
➢제한사항
✓15개의 클론 허용.
✓동일 리전내 복제 생성 가능Production database
Clone Clone
Clone
Dev/test
applications
Benchmarks
Production
applications
Production
applications

Clone – Copy-on-Write
Page 1 Page 2 Page 3 Page 4
① 복제 전Source
Database

Source
Database
Clone
Database
② 복제 후

Source
Database
Clone
Database
Page 1’
③ 원본 데이터베이스 변경 발생

Source
Database
Clone
Database
Page 1’ Page 4’
④ 복제 데이터베이스 변경 발생

Aurora Serverless
✓어플리케이션 부하에 자동으로 응답
✓10초 미만으로 스케일 업 & 다운
✓신규 인스턴스는 Warm buffer pool 보유
✓고가용성의 Multi-tenant Proxy 제공
45

Aurora Serverless 동작 방식
➢분산 Proxy Layer
❖SPOF가 없도록 분산 설계된
Proxy layer가 DB connection
관리
➢Aurora Instance Warm Pool
❖빠른 스케일 업&다운을 위한
다양한 사이즈의 Aurora
Instance로 구성
➢Auto scaling
❖모니터링 서비스를 통한 자동
확장/축소
46
Availability zone 1
Region
App
Shared distributed storage volume
Multi-tenant NLB / database proxy layer
Warm-pool of Aurora instances
Monitoring service
>70% CPU
utilization 혹은
>90% max
connections

Serverless Scaling 실제 동작 예시
1
2
4
8
16
32
64
128
0
500
1000
1500
2000
2500
3000
10
170
330
490
650
810
970
1130
1290
1450
1610
1770
1930
2090
2250
2410
2570
2730
2890
3050
3210
3370
3530
3690
3850
4010
4170
4330
4490
4650
4810
4970
5130
5290
5450
5610
5770
5930
6090
6250
6410
6570
6730
6890
7050
7210
tps ACU
Scales down more
gradually
Scales up quickly
as load increases

Aurora Serverless – Data API
연결관리 없이 Aurora MySQL Serverless Access
• 기존 애플리케이션 및 Lambda, AppSync와 같은 서버리스
애플리케이션에서 사용가능
• API내에서 SQL statement 사용 가능
• DB connection 및 pooling 불필요
• 보안
• AWS Secret Manager를 통하여 DB crendential 관리, API에 Credential 포함할 필요 없음
48
Web Service Data API
Aurora Serverless
ExecuteStatement BeginTransaction
BatchExecuteStatement CommitTransaction
RollbackTransaction

Aurora Global Database
• 재해복구 용도로 사용
• 데이터를 각 지역(국가)의 어플리케이션과 가까운 곳으로 가져와서 데이터 지역성을 강화, 저지연 확보
50

Global Database Physical Replication
① 프라이머리 인스턴스가 Log record들을 storage node, replica instance,
replication server에 동시에 전송합니다.
② Replication serve는 Log record들을 Secondary Region의 Replication
Agent로 스트리밍합니다.
③ Replication agent는 Log record들을 Storage node, replica instance들로
동시에 전송합니다.
④ 장애 발생시, 동기화를 위하여 Replication serve가 Storage node에서 Log
record들을 확인하여 재전송합니다.
높은 처리량: 체감 성능 영향 없이 150K writes/sec 처리
낮은 복제 지연: 높은 부하상황에서도 1초 이내의 교차 리전
복제 지연
빠른 복원: 리전 장애시에도 1분 이내 읽기/쓰기 복원가능
Primary region Secondary region
1
ASYNC 4/6 QUORUM
Continuous
backup
AZ 1
Primary
Instance
Amazon
S3
AZ 2
Replica
Instance
AZ 3
Replica
Instance
Replication
Server
Replication Fleet
Storage Fleet
11
4
AZ 1
Replica
Instance
AZ 2 AZ 3
ASYNC 4/6 QUORUM
Continuous
backup
Amazon
S3
Replica
Instance
Replica
Instance
Replication
Agent
Replication Fleet
Storage Fleet
3
3
2

Global Replication Performance
Logical replication Physical replication
0
100
200
300
400
500
600
0
50,000
100,000
150,000
200,000
250,000
seconds
QPS
QPS Lag
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
5.00
0
50,000
100,000
150,000
200,000
250,000
seconds
QPS
QPS Lag
Logical vs. physical replication

Simple Test
• 단순한 Schema와 간단한 Insert Loop, 그리고 Select Loop을
통하여 과연 어떻게 동작하는지를 살펴보겠습니다.

• 글로벌 데이터베이스 구성
• Primary Region: N.Virginia
• Secondary Region: Ireland
• Primary Insert , Secondary Select 동시 수행
Running the code

여러분의 피드백을 기다립니다!
Games on AWS 2019 QR코드를 통해
강연평가 및 설문조사에 참여해 주시면 최신
랩탑 배낭을 드립니다!
여러분의 소중한 의견 부탁 드립니다.
#GamesOnAWS 해시태그와 함께
소셜미디어에 여러분의 행사 소감을 올려주세요.

AWS Korea 공식 소셜 채널에서
발표자료 및 녹화 동영상을 확인하세요
발표자료 다운로드

감사합니다

[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS 솔루션즈 아키텍트

More Related Content

What's hot (20)

Similar to [Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS 솔루션즈 아키텍트 (20)

More from Amazon Web Services Korea (20)

[Games on AWS 2019] AWS 사용자를 위한 만랩 달성 트랙 | Aurora로 게임 데이터베이스 레벨 업! - 김병수 AWS 솔루션즈 아키텍트