Amazon Aurora Deep Dive (김기완) - AWS DB Day

고객 사례와 함께하는
Aurora Technical Deep Dive
김기완
Solutions Architecture, Amazon Web Services
Time : 13:30 – 14:50

Schedule
AGENDA
Afternoon Sessions
1:00 pm — 1:30 pm
AWS 데이터베이스 – 나에게 맞는 데이터베이스는 뭘까?
김상필 아마존 웹서비스 솔루션즈 아키텍트
Jun Okubo 아마존 웹서비스 사업개발 매니저
1:30 pm — 2:50 pm Amazon Aurora 자세히 살펴보기 김기완 아마존 웹서비스 솔루션즈 아키텍트
2:50 am — 3:10 am Coffee Break
3:10 pm — 4:30 pm 개발자가 알아야 할 Amazon DynamoDB 활용법 김일호 아마존 웹서비스 솔루션즈 아키텍트
4:30 pm — 5:50 pm Amazon Redshift 자세히 살펴보기 김용우 아마존 웹서비스 솔루션즈 아키텍트
5:50 pm — 6:00 pm 폐회 및 경품추첨

• Amazon Aurora 개요
• 고객 사례 – REMEMBER on Aurora
• Amazon Aurora의 빠른 성능
• Amazon Aurora의 고가용성
• 고객 사례 – SendBird
• Amazon Aurora 시작하기 및 마이그레이션
Introduction
목차

Amazon Aurora는?
• MySQL 호환 관계형 데이터베이스 엔진
• 상용 데이터베이스의 성능 및 가용성 제공
• 오픈소스 데이터베이스의 효율성 및 비용
Introduction
Amazon Aurora는?

서비스 중심 아키텍처 적용 데이터베이스
로깅 및 스토리지 레이어를 멀티-테넌시 스케일-아
웃 기반 데이터베이스 최적화 스토리지 서비스로
전환
서비스 내부 운영을 위하여 Amazon EC2, Amazon
VPC, Amazon DynamoDB, Amazon SWF, and Am
azon Route 53 등 다른 AWS 서비스들과 통합
연속적인 백업을 위한 Amazon S3 와 통합으로 99.
999999999% 내구성 제공
Control PlaneData Plane
Amazon Dyna
moDB
Amazon SWF
Amazon Route 53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3
서비스 중심 아키텍쳐 적용
Introduction

Amazon Aurora 주요 특징
높은 성능
Introduction
Amazon Aurora 주요 특징
뛰어난 보안 MySQL과 호환
뛰어난 확장성 높은 가용성 완전 관리형

손쉬운 데이터베이스 관리
• 수 분 내에 데이터베이스 생성
• 자동화된 패치
• 푸시-버튼 용량 확장
• Amazon S3 연속 백업
• 자동 장애 감지 및 페일오버
Amazon RDS
Introduction
손쉬운 데이터베이스 관리

손쉬운 스토리지 관리
• 읽기 복제에 페일오버 – 데이터 유실 없음
• 사용자 스냅샷 즉각 생성 – 성능 영향 없음
• Amazon S3에 연속, 증분 백업
• 최대 64TB까지 자동 스토리지 용량 확장
• 자동화된 재스트라이핑, 미러 복구, 핫스팟 관리, 암호화
Introduction
손쉬운 스토리지 관리

손쉬운 보안 향상
• 저장 시 암호화
• AES-256 및 하드웨어 가속
• 디스크 및 S3 내 모든 블록들은 암호화
• AWS KMS 를 통한 키 관리
• 전송 시 암호화 – SSL
• Amazon VPC를 통한 네트워크 격리
• 노드에 직접 접근 없음
Storage
SQL
Transactions
Caching
Amazon S3
Application보안 최적화
Introduction

AWS 역사 상
가장 빠르게 성장 중인 서비스
비지니스 어플리케이션
웹 및 모바일
컨텐츠 관리
전자 상거래
사물 인터넷
검색 및 광고
비지니스 인텔리전스, 분석
게임, 미디어
다양한 적용 분야Aurora Technical Deep Dive
Introduction
다양한 적용 분야

Amazon Aurora의 빠른 성능
Performance

한국 Aurora 고객 사례 – REMEMBER on AWS
한국 Aurora 고객 사례 – REMEMBER on AWS
YOUNGRAE LEE
DRAMA & COMPANY

스마트한비즈니스 습관,리멤버
찍으면 입력해주는 No.1 명함관리 앱
리멤버 소개

스마트한비즈니스 습관,리멤버
찍으면 입력해주는 No.1 명함관리 앱
비서의수기입력 명함정보 업데이트 주소록저장지원
100% 정확한 입력
수정이 필요없는 편리함
리멤버 회원 간 명함 정보 변경 시
실시간으로 자동 업데이트
휴대폰 및 구글 주소록에 저장,
Excel 다운로드 및 아웃룩 연계
리멤버 소개

2015.12.11
Amazon AuroraRDS MySQL 5.6
리멤버 소개

14/01
서비스는 순항중!
14/07 15/01 15/07 16/01 16/04
76만
2500만
1억
2억5천만
4억5천만
6억
그러나, 데이터 증가량에 대한 예측 실패.
데이터 증가 건 수가 예상치보다 많았다.
: 명함 데이터 테이블 (Actual)
: 명함 데이터 테이블 (Expected)
왜 DB이전을 고려하게 되었나요? (1)

하나, 둘 발생하는 문제들
Optional subtitle
데이터가 급격히 많아짐에 따라 하나 둘 씩 흔히 나타나는문제들이발생하기시작합니다.
• 점점 주기가 짧아지는 인덱스 통계정보갱신으로Query Execution Plan이 바뀌는 경우가 가끔발생.
• 구조적 핸디캡으로, 트랜잭션으로인한 LOCK문제 발생하기 시작함.
• 쉽게 해소되지 않는 CPU 오버헤드. 서비스를중단시키고 해소시켜야하는 상황이 발생.
• 늘어나는 데이터에 대한 디스크 관리.
• 늘어난 워크로드.

스키마 구조 개선 vs 물리적 성능 개선
이 일을 어쩌지?
(사실 몇 달 전 빠른 기능확장성 위주의 대대적 스키마 구조 개편이 있었음)

그리고,
좀 더 안정적인 운영이 가능했으면 하는 바램.

MariaDB 10 vs Aurora vs MySQL 5.7
벤치마크 테스트

SYSBENCH TEST Aurora MariaDB MySQL
Version 5.6.10a 10.0.17 5.7.10
Instance Class db.r3.4xlarge db.r3.4xlarge db.r3.4xlarge
Storage / IOPS - 3,000GB / 30,000 IOPS 3,000GB / 30,000 IOPS
Sysbench Server c4.8xlarge c4.8xlarge c4.8xlarge
벤치마크 테스트 (1)

테스트 조건
Optional subtitle
다음과 같이 SYSBENCH 테스트를 진행했습니다.
• 서버 파라미터 튜닝을 하지 않은 상태로 진행.
• RDBMS별 50개의 테이블에각 1천만건 씩 총 5억건 데이터를 생성.
• RDBMS별 500개의 Thread로 OLTP Fully Read, FullyWrite, Read/Write 테스트진행.
• DB Warmup을 고려해수 차례 OLTP 테스트진행 후 마지막 3건의결과 중 가장 좋은 수치의 결과를캡쳐.

테스트 결과 : Fully Read
0
20000
40000
60000
80000
100000
120000
140000
Aurora MariaDB MySQL
(RequestPerSecond)

테스트 결과 : Fully Write
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
(RequestPerSecond)
~2.0X
~2.4X

테스트 결과 : Read / Write
0
10000
20000
30000
40000
50000
60000
70000
80000
(RequestPerSecond)
~4.5X ~5.4X

Aurora로 이전하기로 결정
Optional subtitle
성능, 안정성, 기능제공 면에서 MySQL, MariaDB보다좋았다.
• 벤치마킹 결과와 같이Aurora가 가장 좋은 성능을보여주었다.
• Failover기능에 상당히만족했다. 서버의 장애상황을 감지해자동으로Failover하거나, 수동 Failover가가능.
• 쉽게 데이터 이전이 가능.
• AWS RDS의 주력 제품으로, 꾸준한 개선 및 관리가 잘 될 것 같다는 기대감.
Aurora로 결정!

DB이전 다운타임 최소화 하기
Optional subtitle
DB이전을 할 때 다운타임을 최소화 하기 위한 방법은 놀라울 정도로 간단합니다!
• RDS MySQL의 최신 스냅샷을 Migrate기능을 이용해 AuroraDB로이전
• Migrate하는동안의 데이터변경분 처리(AuroraDB를Replica Server로활용)
• 각 Applications에서 DB Endpoint를AuroraDB Cluster Endpoint로 변경
Aurora로 마이그레이션 (1)

1. Binary log 보관 주기를 늘려주기
Optional subtitle
MySQL에서AuroraDB로Migrate하는 동안의 binlog는기록되어보관될 수 있도록 보관 주기를늘려줍니다.
• CALL mysql.rds_set_configuration(‘binlog retention hours’, 48);

2. AuroraDB 인스턴스 생성
Optional subtitle
기존에 사용하던 MySQL Master DB의 최신 Snapshot을이용해AuroraDB로 Migrate를합니다.
• Migrate를 하기 전 해당 시점 binary log의 File과 Position을잘 기록해 둡니다.
• Binlog의 File과 Position은 “SHOW MASTERSTATUS” 명령어를 통해 확인합니다.
• 마이그레이션이 완료 되고 인스턴스가생성될 때 까지 기다립니다.

3. MySQL에 Replication전용 계정 추가
Optional subtitle
AuroraDB가 MySQL에 Replication을 위해 접근할계정을 생성하고 권한을부여합니다.
• CREATE USER `reql_user`@`%` IDENTIFIED BY ’yourpassword’;
• GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO `repl_user`@%` IDENTIFIED BY ‘yourpassword’;

4. Replication 설정 및 시작
Optional subtitle
RDS에서 제공하는 procedure를 사용해replication설정을 마무리합니다.
• MySQL의 Endpoint와 앞서메모해 두었던binlog의 ‘File’과 ’Position’을이용해 프로시저를실행합니다.
• CALL mysql.rds_set_external_master([mysqlendpoint],3306,’repl_user’,’pw’,[File],[Position],0);
• External master 설정을마쳤으면, 복제를 시작합니다.
• CALL mysql.rds_start_replication;

5. 서버 이전 마무리
Optional subtitle
AuroraDB가 MasterDB와 동기화가 되었다면 각 어플리케이션의 DB endpoint를AuroraDB로 변경하고 마무리합니다.
• 각 Application별로 DB endpoint를AuroraDB의 Cluster Endpoint로변경시켜준비합니다.
• AuroraDB를 Master로 승격합니다.
• AuroraDB의 복제를종료합니다.
• CALL mysql.rds_stop_replication;
• 각 Application별로 Endpoint변경사항을 반영합니다.

서버 이전 후기
Optional subtitle
• 데이터는 약 1.5TB가량. 총 이전 시간 약 5시간.
• 이전 중 별다른 예외사항 없었음.
• 서비스 재시작을 위한 다운타임은약 20분 가량.
• 요즘은AWS DMS(Data Migration Service)를 통해 몇번의 클릭으로손쉽게 데이터 이전이 가능함.
Aurora 이전 후기

Aurora 사용 후기
Optional subtitle
• 심리적 안정감.
• 디스크 관리에서 해방!
• 강력한 Fail over기능.
• 상세한 서버 모니터링 툴.
• 유지 가능한 캐시 워밍. 손 워밍에서 해방!
• 충분한 네트웍 대역폭과 성능이 보장되면 정말로MySQL 5.6대비5배의 처리량을 보여줌.
Aurora 사용 후기

Aurora 사용 시 주의할점
Optional subtitle
• 너무 많은 Replication서버 구성은Master 서버를바쁘게 한다.
• 가능하면 Replication 서버 댓수는줄이고, Instance Class를 높이면좋다.
• ”/tmpdir”폴더는인스턴스클래스의로컬 스토리지에 생성되는 구조적한계.
• 때문에 데이터가 엄청 많은 테이블을 Full Scan하는 쿼리는삼가야 한다.
• MySQL 5.6대비성능이 5배 라는 말은 쿼리 수행 속도가 5배 빠르다는게 아니라 5배 많은 처리를할 수 있다는 말.
Aurora 이건 신경써주세요

Aurora 사용 팁
Optional subtitle
• 자주 업데이트 되고 있다. 한 두달에 한 번은 업데이트 기록을찾아보자. 좋은 기능이 생겨있을 가능성이 높다.
• RDS에 대해 현재까지 보고된 문제들은 RDS DOC의“문제 해결”에 자세히나와있다. 반드시 참조해야 한다.
• MariaDB에서 만든 MariaDB-Connector-j에Aurora를 위한failover제어 기능이들어있다.
Aurora TIP

우리의 경험들이 차곡차곡!
드라마 개발그룹 블로그!
http://developer.dramancompany.com
드라마앤컴퍼니 개발그룹 블로그를 소개합니다!

WANTED!
드라마 주연배우 캐스팅 중
http://dramancompany.com/joinus
드라마에서 주연배우로 활약할 개발자를 캐스팅합니다!

DBDAY 0427
리멤버명함교환방
“코드로 교환방 찾기”

READ PERFORMANCE
• 4 클라이언트 머신 및 각 1,000 connections
WRITE PERFORMANCE
단일 클라이언트 머신 및 각 1,600 connections
Amazon Aurora R3.8XL (32 vCPU, 244 GB RAM) 사용 MySQL sysBench 성능 테스트
Performance
SQL 성능 테스트 결과

h t t p s : // d 0 . a wss t a t ic. c o m / pr o d uc t- m a rk e t in g / A ur o r a /R D S _ A u r or a _ P e r f or m a nc e _ A ss ess m e n t _ B e n ch m a rk in g _v 1 - 2 . p d f
AMAZON
AURORA
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
• Amazon VPC 생성 (또는 기존 VPC 사용)
• SysBench 클라이언트 실행을 위한 4 EC2 R3.8XL 클라이언
트 생성. 모든 인스턴스는 동일 가용 영역 설치
• 클라이언트 들이 향상된 네트워킹 적용
• Linux 설정 조정 (백서 참조)
• Sysbench version 0.5 버전 설치
• 클라이언트 실행 중인 VPC 및 가용 영역에 r3.8xlarge Amaz
on Aurora DB 인스턴스 실행
• 벤치마크 시작
1
2
3
4
5
6
7
Performance
성능 테스트 수행

• SysBench OLTP 워크로드
• 250 테이블
Connections Amazon Aurora
Amazon RDS MySQL
30 K IOPS (single AZ)
50 40,000 10,000
500 71,000 21,000
5,000 110,000 13,000
8x
UP TO
FASTER
Performance
사용자 수 증가에 따른 성능

• SysBench 쓰기-전용 워크로드
• 1,000 접속, 기본 설정
Tables
Amazon Aur
ora
MySQL
I2.8XL
local SSD
MySQL
I2.8XL
RAM disk
RDS MySQL
30 K 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
11x
UP TO
FASTER
Number of write operations per second
Performance
테이블 수 증가에 따른 성능

• SYSBENCH WRITE-ONLY
DB Size Amazon Aurora
RDS MySQL
1GB 107,000 8,400
10GB 107,000 2,400
100GB 101,000 1,500
1TB 26,000 1,200
67x
UP TO
FASTER
DB Size Amazon Aurora
RDS MySQL
30K IOPS (single AZ)
80GB 12,582 585
800GB 9,406 69
CLOUDHARMONY TPC-C
136x
UP TO
FASTER
Performance
데이터 양 증가에 따른 성능

• SysBench OLTP 워크로드
• 250 테이블
Updates per
second Amazon Aurora
RDS MySQL
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
500x
UP TO
LOWER LAG
Performance
읽기 복제에 대한 성능 지연

I/O의 감소
네트워크 패킷 최소화
기존 결과를 캐시
데이터베이스 엔진 오프로드
DO LESS WORK
비동기식 처리
응답속도 경로 감소
락-없는 데이터 구조 사용
배치 수행 동시 처리
BE MORE EFFICIENT
DATABASES ARE ALL ABOUT I/O
NETWORK-ATTACHED STORAGE IS ALL ABOUT PACKETS/SECOND
HIGH-THROUGHPUT PROCESSING DOES NOT ALLOW CONTEXT SWITCHES
Performance
성능을 위한 Aurora 아키텍쳐

Aurora 클러스터
Amazon S3
AZ 1 AZ 2 AZ 3
Aurora 프라이머리
인스턴스
3 가용영역에 걸친 클러스터 볼륨
Performance
Aurora 클러스터

Amazon S3
AZ 1 AZ 2 AZ 3
Aurora 프라이머리
인스턴스
3 가용영역에 걸친 클러스터 볼륨
Aurora 복제 Aurora 복제
Performance
Aurora 클러스터 및 읽기 복제

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

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

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
③ 레코드를 구성 및 로그의 간극 파악
④ 동료 스토리지 노드와 간극 통신하여 간극 메움
⑤ 로그 레코드를 신규 데이터 블록 버전으로 통합
⑥ 주기적으로 로그 및 신규 블록 버전을 S3로 전송
⑦ 주기적으로 기존 버전에 가비지 콜렉션 수행
⑧ 주기적으로 블록에 대한 CRC 검증
Aurora I/O 트래픽 - 스토리지Aurora Technical Deep Dive
Performance
Aurora I/O 트래픽 - 스토리지

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

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 athead 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 시 내구성
비동기식 트랜잭션 처리로 성능 및 효율성 제공
Performance
Asynchronous group commits

액티브 스레드에 접속을 멀티플렉싱
커널 영역의 epoll() 통한 latch-free 이벤트 큐 입력
스레드 풀 크기 동적 조정
5000+ 동시 클라이언트 세션을 r3.8xl에서 처리
표준 MySQL— 접속 당 스레드
접속 수 증가에 확장되지 않음
MySQL EE — 접속은 스레드 그룹에 할당.
Threshold 조정 등에 있어 주의 필요
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
Performance
Adaptive Thread Pool

Amazon Aurora의 고가용성
High Availability

Amazon Aurora의 스토리지
• 기본 고가용성
• 3 가용영역에 6 copy 복제
• 4 / 6 쓰기, 3 / 6 읽기 쿼럼
• S3 저장소에 연속 백업
• SSD, 스케일-아웃, 멀티-테넌트 스토리지
• 연속적 스토리지 확장
• 최대 64TB 크기
• 사용한만큼만 지불
• 로그-구조 기반 스토리지
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3
High Availability
Amazon Aurora의 스토리지

스토리지 자가 치유 및 장애 내구성
• 자동 장애 감지, 복제, 복구
• 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
High Availability
스토리지 자가치유 및 장애 내구성

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

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

Amazon Aurora의 인스턴스 자동 페일-오버
읽기 복제 있는 경우
ü 기존 복제본을 새 기본 인스턴스로 승격
ü 페일오버 대상 인스턴스 우선 순위 지정 가능
ü 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
High Availability

페일-오버
1분 미만
High Availability

신속한 크래시 복구
ü 최종 체크포인트 이후 로그 재생 필요
ü MySQL은 싱글-쓰레드 동작 및 다량의 디스
크 억세스 필요
ü 스토리지에서 읽는 시점에 온-디맨드 형태
로 Redo 레코드 재생
ü 병렬, 분산, 비동기
기존 데이터베이스 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
High Availability
신속한 크래시 복구

• 데이터베이스 프로세스와 캐시의 분리
• 데이터베이스 재기동 이벤트 시에도 캐
시 웜(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.
High Availability
캐시 유지

App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORAWITH MARIADB DRIVER
15–20초
3–20초
신속하고 예측 가능한 페일-오버
High Availability

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
High Availability
SQL 사용 장애 시뮬레이션 지원

Amazon Aurora 시작하기 및 마이그레이션
Startup & Migration

한국 Aurora 고객 사례 – SendBird on AWS
한국 Aurora 고객 사례 – SendBird on AWS
김여신 (Harry Kim)
CTO, SendBird

센드버드 소개 및 오로라 DB로의 이전을 결정한 배경
Aurora DB로의 이전을 결정한 배경
SendBird 는 모바일 앱/웹사이트를 위한 실시간 메시징 솔루션 입니다.
§ 크로스 플랫폼 지원: iOS, Android, 유니티 3D엔진, 웹(JavaScript),
자마린 SDK 및 서버 API 제공
§ 월 ~2백만 최종 고객 (End-user)이 센드버드를 통해 채팅 서비스 이용
(일 1백만 건 이상의 신규 메시지, 일 50억 건 이상의 전송량)
전세계적으로 5,600개 개발사가 센드버드 서비스에 가입하여, 이 중
900개 앱에 탑재되어 이용중입니다. 센드버드는 월 60%의 속도로 빠르게
성장하고 있습니다.
SendBird 소개
채팅 서비스의 특성 상 많은 메시징
데이터가 쌓였고, 이를 처리하던 기존
MariaDB (Persistent Storage)에서 성능
외적인 문제를 직면
백업 레플리카
Failover 하드웨어
예측
70

오로라 DB 소개
Aurora는 아마존에서 제공 하는 MySQL 호환성을 가지고 더 높은 성능과 향상된 기능을
제공하는 AWS RDS(Relational Database Service) 서비스 중 하나입니다
§ MySQL과 호환되며 오로라 엔진을 채용하여 퍼포먼스와 신뢰도를 향상시킴으로 기존
MySQL 클라이언트를 그대로 적용할 수 있다는 장점이 존재
§ 기존 RDS에 비해 자동 스토리지 용량 증설, 로우 레이턴시 복제기능, 향상된 Failover
등 향상된 성능을 제공
71

Problem We Faced : Self-Hosted RDBMS
72
Self-Hosted
RDBMS
서비스 중 하드웨어
업그레이드 어려움
수동적인 장애 조치
백업 용량 및 시간 증가1
레플리카
생성 어려움
2
3
4

1Problem We Faced : 백업
과거 센드버드는 유저 데이터를 Daily로백업하여S3에 올리는 방식을사용해 작업 시간의낭비를 경험
§ 백업데이터의 증가로 몇 백기가에달하는 데이터를 압축하고 전송하는데시간 소요
§ 데이터 유실이 발생하는 경우 이를 처리하기위한 데이터복구에 수동적인 방법 적용
73

2Problem We Faced : 레플리카
레플리카 추가시에도 막대한 시간 낭비, 리소스 비효율이 초래됨
새로운
인스턴스
생성
기존
마스터에서
데이터 덤프
레플리카에
리스토어
74

3Problem We Faced : 장애조치
사람의 지속적인 개입을 필요로 했던 Failover
“…마스터의 장애 발견…레플리카의 복제 차단…
기존 서버의 설정 모두 레플리카 서버로 수정 후
재시작…모든 서버에 접근해 서비스의 DB설정 변경…”
75

4Problem We Faced : 하드웨어 예측
AWS를 사용하는 이유 중
하나인 온디맨드(On-Demand)
하드웨어 증설이 어려워지고
비효율적인 하드웨어 예측 발생
추후 다운타임(Downtime)을 최소화
하기 위해 필연적으로 필요이상의
스토리지 용량과 하드웨어 티어를
선택할 수 밖에 없음
76

Aurora 이전 후 개선사항
77
Self-Hosted
RDBMS
최소한의
다운타임으로
서비스 중
하드웨어
업그레이드
자동 장애조치
데일리 스냅샷 백업1
원-클릭
레플리카 생성
2
3
4

Aurora 이전 후 개선사항: 백업1
백업 시간을 지정하면 해당 시간대에 스냅샷 형태로 저장이 되며
백업된 스냅샷으로 새로운 RDS 인스턴스를 생성 가능
78

Aurora 이전 후 개선사항: 레플리카2
필요에 따라 언제든지 레플리카를 추가하여
고(高) 가용성과 읽기 확장성을 확보함
§ 원 클릭으로 생성이 가능
§ 10분 이내 생성 후 적용 가능
79

Aurora 이전 후 개선사항: 장애조치3
일반적으로 레플리카로의 Failover가 30초 내
가능해지며, 마스터 하드웨어 업그레이드가
매우 손쉽게 진행 가능
§ 자동으로 레플리카 서버를 마스터로 승격
§ 도메인 변경 불필요
§ 장애 후 30초 이내 복구 가능
80

Aurora 이전 후 개선사항: 하드웨어 업그레이드4
81
l 현 상황에 맞는 Tier를 선택 가능: 스토리지 용량이
증가함에 따라 64 TB까지 자동으로 증설 가능
l 원할 경우 최소한의 다운타임으로 Tier 변경 가능:
1분 내의 다운타임만으로 다음 티어의 하드웨어로
업그레이드 가능

실제 사례 (Case study):최소한의 다운타임으로 Aurora DB 업그레이드 하기
레플리카를 마스터로 승격
마스터 Tier 업그레이드
마스터 복구
총 장애 시간
1분 이내

결론 (Conclusion)
§ 백업을 이용해 즉시 디비 인스턴스를 생성; 배포 전 테스트를 위한 임시 디비
생성에 걸리는 시간 비약적 단축
§ 원 클릭 Failover 기능으로 인해 고가용성을 확보
§ CloudWatch API를 이용하여 오로라 디비의 모든 메트릭을 상세히 사내
대시보드에 통합할 수 있었음
§ 하드웨어의 변경에 따른 부담이 감소하여 최적화된 코스트의 장비를 선택 가능
§ 특히, 인프라팀을 운영할 수 없는 경우 비용 절감 효과 및 서비스 신뢰성 향상 가능

RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
RDS 런치 시 Amazon Aurora 엔진 선택하여
신규 RDS 인스턴스 런치
Aurora 생성 및 마이그레이션
Startup & Migration

DB on
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAuroramysqldump / mysqlimport
• MySQL 에서 Aurora 이전을 위하여 데이터 익스포트에
표준적인 mysqldump utility 사용 및 데이터 임포트에
mysqlimport 유틸리티사용 또는 반대도 가능
Startup & Migration
신규

RDS MySQL
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAurora
Snapshot migration
• MySQL v5.6 : RDS DB Snapshot 마이그레이션
• MySQL v5.6 이전 : DB 업그레이드 후 DB 스냅샷 마이
그레이션
MySQL
Startup & Migration
신규

• Database Migration Service(DMS)는 최소한의 다운타임
으로 On-premise 및 EC2 DB 를 RDS로 이전하기 위한
강력한 툴
• Full load 및 CDC(Change Data Capture)
• 이기종 DB 마이그레이션 지원 (예:MS SQL to Aurora)
RDS
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAurora
Database
Migration Service
OracleMS SQLPostgreSQLPostgreSQL
Startup & Migration
신규

Amazon Aurora Deep Dive (김기완) - AWS DB Day

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Amazon Aurora Deep Dive (김기완) - AWS DB Day

Similar to Amazon Aurora Deep Dive (김기완) - AWS DB Day (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

Amazon Aurora Deep Dive (김기완) - AWS DB Day