3. v
v
AWS Database 서비스 옵션
DynamoDB
Amazon
RDS
Amazon
Redshi3
Elas6Cache
4. v
• 관계형 데이터베이스
• Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL
Server
• 완전 관리형 서비스
Amazon
RDS
Aurora
RDS 서비스 데이터베이스 엔진 옵션
5. v
v
스키마 설계
쿼리 작성
쿼리 최적화
마이그레이션
백업 및 복구
패칭
구성
소프트웨어 업그레이드
스토리지 업그레이드
서버 업그레이드
하드웨어 관리
Amazon RDS 서비스 사용 목적
Focus
your
team
here
Let
AWS
focus
here
6. v
v
RDS 데이터베이스 인스턴스 확장
• 데이터베이스 인스턴스 확장
• CPU 메모리 구성에 따른 다양한 인스턴스 타입
• 필요에 따라 스케일 업 또는 스케일 다운
• 데이터베이스 스토리지 확장
• 범용 / Provisioned IOPS / 마그네틱 볼륨의 다양한 스토리지 타입
• 필요에 따라 용량 또는 성능의 확장
7. v
v
RDS 백업
• Automated backups
• Restore your database to a point in time
• Enabled by default
• Choose a retention period, up to 35 days
• Manual snapshots
• Initiated by you
• Persist until you delete them
• Stored in Amazon Simple Storage Service (Amazon S3)
• Build a new database instance from a snapshot when needed
8. v
v
Multi-AZ 배포를 통한 고가용성
Enterprise-grade fault tolerance solution for production databases
9. v
지역 간 스냅샷 복사를 통한 내구성 향상
• Copy a database snapshot to a different AWS Region
• Warm standby for disaster recovery
• Or use it as a base for migration to a different region
10. v
v
지역간 읽기 복제를 통한 분산 및 마이그레이션
• Even faster recovery in the event of disaster
• Bring data close to your customers
• Promote to a master for easy migration
12. v
v
Amazon RDS for Aurora
• Amazon Aurora는 MySQL 호환 관계형 데이터베이스 엔진
• Aurora는 상용 데이터베이스의 10분의 1 가격으로 MySQL보다 최
고 5배 뛰어난 성능을 제공
• 3 가용영역에 거쳐 6개의 복제를 저장하여 고가용성 제공
• Amazon S3에 지속적으로 데이터를 백업
• 지역 내 15개 Amazon Aurora Replicas
• 10GB에서 64TB까지 스토리지 자동 증가
• 리전 : Virginia, Oregon, Ireland 및 Tokyo
13. v
v
Amazon Aurora 개요
• 서비스 중심 아키텍처의 적용
• 로깅 및 스토리지 레이어에, 멀
티-티넌트, 스케일-아웃, 데이터
베이스 최적화된 스토리지 서비
스 적용
• 내부 운영을 위하여 EC2, VPC,
DynamoDB, SWF, Route 53 등
AWS 기존 서비스 활용
• 연속 백업을 위하여 Amazon S3
통합
Logging
+
Storage
SQL
Transac1ons
Caching
Control
Plane
Data
Plane
Amazon S3
DynamoDB
Amazon SWF
Amazon Route 53
15. v
v
손쉬운 데이터베이스 관리
• 수 분 내에 데이터베이스 생성
• 자동화된 패치
• 푸시-버튼 용량 확장
• Amazon S3 연속 백업
• 자동 장애 감지 및 페일오버
Amazon
RDS
16. v
v
손쉬운 스토리지 관리
• 읽기 복제에 페일오버 – 데이터 유실 없음
• 사용자 스냅샷 즉각 생성 – 성능 영향 없음
• Amazon S3에 연속, 증분 백업
• 최대 64TB까지 자동 스토리지 용량 확장 – 성능, 가용성 영향 없음
• 자동화된 재스트라이핑, 미러 복구, 핫스팟 관리, 암호화
17. v
v
손쉬운 보안 향상
• 저장 시 암호화
• AES-256 및 하드웨어 가속
• 디스크 및 S3 내 모든 블록들은 암호화
• AWS KMS 를 통한 키 관리
• 전송 시 암호화 – SSL
• Amazon VPC를 통한 네트워크 격리
• 노드에 직접 접근 없음
• 산업 표준의 보안 및 데이터 보호 인증서 지원
Storage
SQL
Transac1ons
Caching
Amazon S3
Applica1on
19. v
v
Amazon Aurora의 스토리지
• 기본 고가용성
• 3가용영역에 6-way 복제
• 4 / 6 쓰기, 3 / 6 읽기 쿼럼
• S3 저장소에 연속 백업
• SSD, 스케일-아웃, 멀티-테넌
트 스토리지
• 연속적 스토리지 확장
• 최대 64TB 크기
• 사용한만큼만 지불
• 로그-구조 기반 스토리지
SQL
Transac1ons
AZ
1
AZ
2
AZ
3
Caching
Amazon S3
20. v
v
스토리지 자가 치유 및 장애 내구성
• 자동 장애 감지, 복제, 복구
• 2개의 복제 및 1개 가용 영역 장애는 읽기 및 쓰기 가용성에 영향 없음
• 3개의 복제 장애에도 읽기 가용성에 영향 없음
SQL
Transac6on
AZ
1
AZ
2
AZ
3
Caching
SQL
Transac6on
AZ
1
AZ
2
AZ
3
Caching
Read
and
write
availability
Read
availability
21. v
v
Amazon Aurora의 스토리지 백업 및 복구
자동 백업(Automated Backup)
• RDS는 백업을 자동으로 생성
• 신규 DB 인스턴스에 자동으로 활성화
• 백업 보관 기간(Backup Retention
Period) 동안 데이터 보관 (1~35일)
• 연속 및 증분 백업
• 백업 중 성능 영향 없음
스냅샷 (DB Snapshots)
• 사용자가 생성한 백업
• 원하는 주기로 백업
• 백업 보관 기간 이상 보관
• 어느 시점으로도 복구 가능
22. v
v
Amazon Aurora의 스토리지 백업 및 복구
복구 (Restore)
• 백업 또는 스냅샷으로부터 신규
Aurora DB 클러스터 생성
• 백업 보관 주기 내 어느 시점으로든 복
구
• Latest Restorable Time : 보통 5분 이내
• Earliest Restorable Time : 백업 보관 주기
• Aurora Backup은 연속, 증분 백업으로
복구 시간 향상을 위해 빈번한 스냅샷
생성을 할 필요 없음
23. v
v
Amazon Aurora Replica의 읽기 복제
MySQL 읽기 확장
• 복제는 반드시 로그를 재생
• 복제는 마스터에 추가적인 부하
• 복제 지연의 증가
• 페일오버 시 데이터 유실 발생 가능
Page
cache
invalida6on
Aurora Master
30%
Read
70%
Write
Aurora
Replica
100%
New
Reads
Shared
Mul1-‐AZ
Storage
MySQL Master
30%
Read
70%
Write
MySQL
Replica
30%
New
Reads
70%
Write
Single
threaded
binlog
apply
Data
Volume
Data
Volume
Amazon Aurora 읽기 확장
• 로그 재생 없음
• 마스터 부하 최소, 최대 15개 복제
• ~100 ms 복제 지연
• 동일 스토리지를 공유하여 페일오버
시 데이터 유실 없음
24. v
v
Amazon Aurora의 인스턴스 자동 페일-오버
읽기 복제 있는 경우
• 기존 복제를 새 기본 인스턴스로 승격
• DB 클러스터 엔드포인트 유지하며, 신규 기본
인스턴스로 DNS 레코드 변경
• 일반적으로 1분 이내에 완료
AZ
1
Primary
instance
Replica
instance
Replica
instance
Replica
instance
Shared
Mul1-‐AZ
Storage
Automa6c
Failover
to
Replica
Instance
AZ
1
Primary
instance
Primary
instance
Shared
Mul1-‐AZ
Storage
Create
new
primary
Instance
Aurora Replica가 있는 경우 Aurora Replica가 없는 경우
읽기 복제 없는 경우
• 동일 가용 영역에 새 DB 인스턴스 생성 시도
• 생성 불가 시 다른 가용 영역에 신규 DB 인스턴
스 생성 시도
• 일반적으로 15분 이내에 완료
AZ
3
AZ
2
AZ
3
AZ
2
Primary
instance
25. v
v
Amazon Aurora의 인스턴스 자동 페일-오버
페일-‐오버
1분 미만
26. v
기존 데이터베이스
• Have to replay logs since the last
checkpoint
• Single-threaded in MySQL; requires a
large number of disk accesses
Amazon Aurora
• Underlying storage replays redo
records on demand as part of a disk
read
• Parallel, distributed, asynchronous
Checkpointed
Data
Redo
Log
Crash
at
T0
requires
a
re-‐applica6on
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
신속한 크래시 복구
27. v
v
캐시 유지
• We moved the cache out of the
database process
• Cache remains warm in the
event of a database restart
• Lets you resume fully loaded
operations much faster
• Instant crash recovery +
survivable cache = quick and
easy recovery from DB failures
SQL
Transac1ons
Caching
SQL
Transac1ons
Caching
SQL
Transac1ons
Caching
Caching
process
is
outside
the
DB
process
and
remains
warm
across
a
database
restart
28. v
v
보다 신속하고 예측 가능한 페일오버
Failure
Detec6on
DNS
Propaga6on
Recovery
Recovery
App
running
DB
Failure
Failure
Detec6on
Recovery
App
running
DB
Failure
?
DNS
Propaga6on
29. v
v
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
31. v
v
• MySQL Sysbench
• R3.8XL - 32 vCPU 및
244 GB RAM
• 4 클라이언트 - 각 1,000
쓰레드
쓰기 성능 (console screenshot)
32. v
v
• MySQL Sysbench
• R3.8XL - 32 vCPU 및
244 GB RAM
• 1 클라이언트 - 각 1,000
쓰레드
읽기 성능 (console screenshot)
33. v
v
• 초당 13,800 회 업데이트 발생 시 Aurora Replica는 7.27 밀리 초 지연
• 동일 사양의 MySQL 5.6 은 초당 2,000 회 업데이트 발생 시 ~2초 지연
Read Replica 지연 (console screenshot)
34. v
v
-‐
10
20
30
40
50
60
70
10
100
1,000
10,000
Thousands
of
writes
per
second
Number
of
tables
Write
performance
and
table
count
Aurora
MySQL
on
I2.8XL
MySQL
on
I2.8XL
with
RAM
Disk
RDS
MySQL
with
30,000
IOPS
(Single
AZ)
Tables
Amazon
Aurora
MySQL
I2.8XL
local
SSD
MySQL
I2.8XL
RAM
disk
RDS
MySQL
30K
IOPS
(single
AZ)
10
60,000
18,000
22,000
25,000
100
66,000
19,000
24,000
23,000
1,000
64,000
7,000
18,000
8,000
10,000
54,000
4,000
8,000
5,000
Write-only workload
1,000 connections
Query cache (default on for Amazon Aurora, off for MySQL)
Amazon Aurora의 테이블 수에 따른 쓰기 확장성
35. v
v
-‐
20
40
60
80
100
120
50
500
5,000
Thousands
of
writes
per
second
Concurrent
connec1ons
Write
performance
and
concurrency
Aurora
RDS
MySQL
with
30,000
IOPS
(Single
AZ)
Connec1ons
Amazon
Aurora
RDS
MySQL
30K
IOPS
(single
AZ)
50
40,000
10,000
500
71,000
21,000
5,000
110,000
13,000
OLTP Workload
Variable connection count
250 tables
Query cache (default on for Amazon Aurora, off for MySQL)
Amazon Aurora의 동시접속 관리 향상
36. v
v
캐시를 통한 성능 향상
-‐
50
100
150
200
250
300
350
400
100/0
50/50
0/100
Thousands
of
opera1ons
per
second
Read/write
ra1o
Performance
with
query
cache
on
and
off
Aurora
without
Caching
Aurora
with
Caching
RDS
MySQL;30,000
IOPS
(Single
AZ)
-‐
without
caching
RDS
MySQL;30,000
IOPS
(Single
AZ)
-‐
with
caching
R/W
ra1o
Amazon
Aurora
without
caching
Amazon
Aurora
with
caching
RDS
MySQL
30K
IOPS
without
caching
RDS
MySQL
30K
IOPS
with
caching
100/0
160,000
375,000
35,000
19,000
50/50
130,000
93,000
24,000
20,000
0/100
64,000
64,000
16,000
16,000
OLTP workload
1,000 connections
250 tables
Query cache on/off tested
37. v
v
2.6
3.4
3.9
5.4
1,000
2,000
5,000
10,000
0
50,000
100,000
150,000
200,000
250,000
300,000
350,000
Updates
per
second
Read
replica
lag
in
milliseconds
Read
replica
lag
Aurora
RDS
MySQL;30,000
IOPS
(Single
AZ)
Updates
per
second
Amazon
Aurora
RDS
MySQL
30K
IOPS
(single
AZ)
1,000
2.62
ms
0
s
2,000
3.42
ms
1
s
5,000
3.94
ms
60
s
10,000
5.38
ms
300
s
Write workload
250 tables
Query cache on for Amazon Aurora, off for MySQL (best
settings)
복제는 최대 400배 낮은 지연
38. v
v
Amazon Aurora 성능 벤치마크 가이드 제공
• https://d0.awsstatic.com/product-marketing/Aurora/
RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf
./sysbench --test=tests/db/oltp.lua
--mysql-host=<rds-aurora-
instancehost-name>
--oltp-tables-count=250 --mysql-
user=<db-username> --
mysqlpassword=<db-password>
--mysql-port=3306 --db-driver=mysql
--oltp-tablesize=25000
--mysql-db=<db-name> --max-requests=0
--max-time=600 --
oltp_simple_ranges=0 --oltp-distinct-
ranges=0 --oltp-sum-ranges=0 --
oltporder-ranges=0
--oltp-point-selects=0 --num-
threads=1000 --randtype=uniform
run
39. v
v
BINLOG
DATA
DOUBLE-‐WRITE
LOG
FRM
FILES
T Y P E
O F
W R I T E
MYSQL WITH STANDBY
Issue
write
to
EBS
–
EBS
issues
to
mirror,
ack
when
both
done
Stage
write
to
standby
instance
using
DRBD
Issue
write
to
EBS
on
standby
instance
IO FLOW
Steps
1,
3,
5
are
sequen6al
and
synchronous
This
amplifies
both
latency
and
jifer
Many
types
of
writes
for
each
user
opera6on
Have
to
write
data
blocks
twice
to
avoid
torn
writes
OBSERVATIONS
780K
transac6ons
7,388K
I/Os
per
million
txns
(excludes
mirroring,
standby)
Average
7.4
I/Os
per
transac6on
PERFORMANCE
30
minute
SysBench
write-‐only
workload,
100
GB
data
set,
RDS
SingleAZ,
30K
PIOPS
EBS
mirror
EBS
mirror
AZ
1
AZ
2
Amazon S3
EBS
Amazon
Elas6c
Block
Store
(EBS)
Primary
instance
Standby
instance
1
2
3
4
5
일관성 및 낮은 응답속도 – RDS MySQL I/O 트래픽
40. v
v
AZ
1
AZ
3
Primary
instance
Amazon S3
AZ
2
Replica
instance
AMAZON AURORA
ASYNC
4/6
QUORUM
DISTRIBUTED
WRITES
BINLOG
DATA
DOUBLE-‐WRITE
LOG
FRM
FILES
T Y P E
O F
W R I T E
30
minute
SysBench
write-‐only
workload,
100
GB
data
set
IO FLOW
Only
write
redo
log
records;
all
steps
asynchronous
No
data
block
writes
(checkpoint,
cache
replacement)
6X
more
log
writes,
but
9X
less
network
traffic
Tolerant
of
network
and
storage
outlier
latency
OBSERVATIONS
27,378K
transac6ons
35X
MORE
950K
I/Os
per
1M
txns
(6X
amplifica6on)
7.7X
LESS
PERFORMANCE
Boxcar
redo
log
records
–
fully
ordered
by
LSN
Shuffle
to
appropriate
segments
–
par6ally
ordered
Boxcar
to
storage
nodes
and
issue
writes
일관성 및 낮은 응답속도 – RDS Aurora I/O 트래픽
41. v
v
LOG
RECORDS
Primary
instance
INCOMING
QUEUE
STORAGE
NODE
S3
BACKUP
1
2
3
4
5
6
7
8
UPDATE
QUEUE
ACK
HOT
LOG
DATA
BLOCKS
POINT
IN
TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER-‐TO-‐PEER
GOSSIP
Peer
storage
nodes
All
steps
are
asynchronous
Only
steps
1
and
2
are
in
foreground
latency
path
Input
queue
is
46X
less
than
MySQL
(unamplified,
per
node)
Favor
latency-‐sensi6ve
opera6ons
Use
disk
space
to
buffer
against
spikes
in
ac6vity
OBSERVATIONS
IO FLOW
① Receive
record
and
add
to
in-‐memory
queue
② Persist
record
and
ACK
③ Organize
records
and
iden6fy
gaps
in
log
④ Gossip
with
peers
to
fill
in
holes
⑤ Coalesce
log
records
into
new
data
block
versions
⑥ Periodically
stage
log
and
new
block
versions
to
S3
⑦ Periodically
garbage
collect
old
versions
⑧ Periodically
validate
CRC
codes
on
blocks
일관성 및 낮은 응답속도 – RDS Aurora I/O 트래픽
62. v
v
RDS Aurora 생성 및 마이그레이션
• 신규
• 이전 (MySQL)
• 이전 (RDS MySQL)
• 이전 (non-MySQL)
DB on
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAurora
mysqldump
/
mysqlimport
• MySQL
83. v
v
RDS Aurora 생성 및 마이그레이션
• 신규
• 이전 (MySQL)
• 이전 (RDS MySQL)
• 이전 (non-MySQL)
RDS MySQL
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAurora
Snapshot
migra6on
• MySQL
147. v
Start your first migra.on in 10 minutes or less
Keep your apps running during the migra.on
Replicate within, to or from Amazon EC2 or RDS
Move data to the same or different database engine
Sign up for preview at aws.amazon.com/dms
AWS
Database Migration
Service
149. v
v
Customer
Premises
Application Users
AWS
Internet
VPN
• Start a replication instance
• Connect to source and target
databases
• Select tables, schemas, or databases
Let AWS Database Migration
Service create tables, load data, and
keep them in sync
Switch applications over to the
target at your convenience
Keep your apps running during the migration
AWS
Database Migration
Service
150. v
v
After migration, use for replication and data
integration
• Replicate data in on-premises databases to AWS
• Replicate OLTP data to Amazon Redshift
• Integrate tables from third-party software into your reporting or
core OLTP systems
• Hybrid cloud is a stepping stone in migration to AWS
152. v
v
MySQL PowerGroup 회원을 위한 AWS Credit
http://bit.ly/awskr-feedback
AWS Activate 패키지
100달러 무료 크레딧 + 80 달러 Qwiklab Credit
600달러 온라인 강좌 수강권+ 100달러 1개월 비지니스 서포트
등록하시면 패키지를 받으실 수 있는 URL을 이메일로 보내드립니다!