AWS Aurora 100% 활용하기

v

아마존웹서비스 김상필, 솔루션즈 아키텍트

2015년 11월 28일

MySQL PowerGroup 2015년 3차 모임

Amazon Aurora 100% 활용하기

v

Amazon RDS 서비스란?

v v

AWS Database 서비스 옵션

DynamoDB

Amazon RDS Amazon Redshi3

Elas6Cache

v

•  관계형 데이터베이스 •  Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL

Server

•  완전 관리형 서비스 Amazon

RDS

Aurora

RDS 서비스 데이터베이스 엔진 옵션

v v 스키마 설계 쿼리 작성 쿼리 최적화

마이그레이션 백업 및 복구 패칭 구성 소프트웨어 업그레이드 스토리지 업그레이드 서버 업그레이드 하드웨어 관리

Amazon RDS 서비스 사용 목적

Focus your team here

Let AWS focus here

v v

RDS 데이터베이스 인스턴스 확장

• 데이터베이스 인스턴스 확장 •  CPU 메모리 구성에 따른 다양한 인스턴스 타입 • 필요에 따라 스케일 업 또는 스케일 다운

• 데이터베이스 스토리지 확장 • 범용 / Provisioned IOPS / 마그네틱 볼륨의 다양한 스토리지 타입 • 필요에 따라 용량 또는 성능의 확장

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

v v

Multi-AZ 배포를 통한 고가용성 Enterprise-grade fault tolerance solution for production databases

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

v v

지역간 읽기 복제를 통한 분산 및 마이그레이션 • Even faster recovery in the event of disaster • Bring data close to your customers • Promote to a master for easy migration

v

관계형 데이터베이스의 재구성 Amazon Aurora

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

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

v

Amazon Aurora의 손쉬운 사용

v v

손쉬운 데이터베이스 관리

• 수 분 내에 데이터베이스 생성

• 자동화된 패치

• 푸시-버튼 용량 확장

•  Amazon S3 연속 백업

• 자동 장애 감지 및 페일오버

Amazon RDS

v v

손쉬운 스토리지 관리

• 읽기 복제에 페일오버 – 데이터 유실 없음

• 사용자 스냅샷 즉각 생성 – 성능 영향 없음

•  Amazon S3에 연속, 증분 백업

• 최대 64TB까지 자동 스토리지 용량 확장 – 성능, 가용성 영향 없음

• 자동화된 재스트라이핑, 미러 복구, 핫스팟 관리, 암호화

v v

손쉬운 보안 향상

• 저장 시 암호화 •  AES-256 및 하드웨어 가속 •  디스크 및 S3 내 모든 블록들은 암호화 •  AWS KMS 를 통한 키 관리

• 전송 시 암호화 – SSL

•  Amazon VPC를 통한 네트워크 격리

• 노드에 직접 접근 없음

• 산업 표준의 보안 및 데이터 보호 인증서 지원

Storage

SQL

Transac1ons

Caching

Amazon S3

Applica1on

v

Amazon Aurora의 고가용성

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

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

v v

Amazon Aurora의 스토리지 백업 및 복구 자동 백업(Automated Backup)

•  RDS는 백업을 자동으로 생성

•  신규 DB 인스턴스에 자동으로 활성화

•  백업 보관 기간(Backup Retention Period) 동안 데이터 보관 (1~35일)

•  연속 및 증분 백업

•  백업 중 성능 영향 없음

스냅샷 (DB Snapshots)

•  사용자가 생성한 백업

•  원하는 주기로 백업

•  백업 보관 기간 이상 보관

•  어느 시점으로도 복구 가능

v v

Amazon Aurora의 스토리지 백업 및 복구

복구 (Restore)

•  백업 또는 스냅샷으로부터 신규 Aurora DB 클러스터 생성

•  백업 보관 주기 내 어느 시점으로든 복구

•  Latest Restorable Time : 보통 5분 이내

•  Earliest Restorable Time : 백업 보관 주기

•  Aurora Backup은 연속, 증분 백업으로 복구 시간 향상을 위해 빈번한 스냅샷 생성을 할 필요 없음

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 복제 지연

•  동일 스토리지를 공유하여 페일오버 시 데이터 유실 없음

v v

Amazon Aurora의 인스턴스 자동 페일-오버 읽기 복제 있는 경우

•  기존 복제를 새 기본 인스턴스로 승격

•  DB 클러스터 엔드포인트 유지하며, 신규 기본 인스턴스로 DNS 레코드 변경

•  일반적으로 1분 이내에 완료

AZ 1

Primary instance

Replica instance

Replica instance

Replica instance


Automa6c Failover to

Replica Instance

AZ 1

Primary instance

Primary instance


Create new primary Instance

Aurora Replica가 있는 경우 Aurora Replica가 없는 경우

읽기 복제 없는 경우

•  동일 가용 영역에 새 DB 인스턴스 생성 시도

•  생성 불가 시 다른 가용 영역에 신규 DB 인스턴스 생성 시도

•  일반적으로 15분 이내에 완료

AZ 3 AZ 2 AZ 3 AZ 2

Primary instance

v v

Amazon Aurora의 인스턴스 자동 페일-오버

페일-‐오버

1분 미만

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

신속한 크래시 복구

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

v v

보다 신속하고 예측 가능한 페일오버

Failure Detec6on DNS Propaga6on

Recovery Recovery

App running

DB Failure

Failure Detec6on

Recovery

App running

DB Failure

?

DNS Propaga6on

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

v

Amazon Aurora의 빠른 성능

v v

• MySQL Sysbench

•  R3.8XL - 32 vCPU 및 244 GB RAM

•  4 클라이언트 - 각 1,000 쓰레드

쓰기 성능 (console screenshot)

v v

• MySQL Sysbench

•  R3.8XL - 32 vCPU 및 244 GB RAM

•  1 클라이언트 - 각 1,000 쓰레드

읽기 성능 (console screenshot)

v v

• 초당 13,800 회 업데이트 발생 시 Aurora Replica는 7.27 밀리 초 지연 • 동일 사양의 MySQL 5.6 은 초당 2,000 회 업데이트 발생 시 ~2초 지연

Read Replica 지연 (console screenshot)

v v

-‐

10

20

30

40

50

60

70

10 100 1,000 10,000

Thou

sand

s of w

rites per se

cond

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의 테이블 수에 따른 쓰기 확장성

v v

-‐

20

40

60

80

100

120

50 500 5,000

Thou

sand

s of w

rites per se

cond

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의 동시접속 관리 향상

v v

캐시를 통한 성능 향상

-‐

50

100

150

200

250

300

350

400

100/0 50/50 0/100

Thou

sand

s of o

pera1o

ns per se

cond

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

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 m

illisecon

ds

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배 낮은 지연

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=uniformrun

v v

BINLOG DATA DOUBLE-‐WRITE LOG FRM FILES

T Y P E O F WR 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 트래픽

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 WR 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 트래픽

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 트래픽

v

Amazon Aurora 시작하기 및 이전

v v

RDS Aurora 생성 및 마이그레이션

RDS�� 런치�� 시�� Amazon�� Aurora�� 엔진�� 선택하여�� 신규�� RDS�� 인스턴스�� 런치��

• 신규

• 이전 (MySQL)

• 이전 (RDS MySQL)

• 이전 (non-MySQL)

v

v

v

v

v

v

v v


• 신규




DB on instance

RDS Aurora instance

PostgreSQLPostgreSQLAurora mysqldump / mysqlimport

•  MySQL�� 에서�� Aurora�� 이전을�� 위하여�� 데이터�� 익스포트에�� 표준적인�� mysqldump�� utility�� 사용�� 및�� 데이터�� 임포트에�� mysqlimport�� utility�� 사용�� 또는�� 반대도�� 가능��

v v


• 신규




RDS MySQL instance

RDS Aurora instance

PostgreSQLPostgreSQLAurora Snapshot migra6on

•  MySQL�� v5.6�� :�� RDS�� DB�� Snapshot�� 마이그레이션�� •  MySQL�� v5.6�� 이전�� :�� DB�� 업그레이드�� 후�� DB�� 스냅샷�� 마이그레이션��

MySQL

v

v

v

v

v v


• 신규




•  RDS�� Migration�� Tool은�� 최소한의�� 다운타임으로�� On-premise�� 및�� EC2�� DB�� 를�� RDS로�� 이전하기�� 위한�� 강력한�� 툴��

•  Full�� load�� 및�� CDC(Change�� Data�� Capture)�� •  이기종�� DB�� 이전�� 지원�� (예:MS�� SQL�� to�� Aurora)�� •  요청�� 시�� AMI�� 공유��

RDS instance

RDS Aurora instance

PostgreSQLPostgreSQLAurora

RDS migra6on tool

OracleMS SQLPostgreSQLPostgreSQL

v

v

v

v

v

v

v

v

AWS Database Migration Service 소개

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

v v

10 minutes or less to migration

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

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

v v

MySQL PowerGroup 회원을 위한 Aurora Credit

v v

MySQL PowerGroup 회원을 위한 AWS Credit

http://bit.ly/awskr-feedback

AWS Activate 패키지 100달러 무료 크레딧 + 80 달러 Qwiklab Credit

600달러 온라인 강좌 수강권+ 100달러 1개월 비지니스 서포트

등록하시면 패키지를 받으실 수 있는 URL을 이메일로 보내드립니다!

v

감사합니다.