4. 서비스 중심 아키텍처 적용 데이터베이스
로깅 및 스토리지를 멀티-테넌시
스케일-아웃 기반 DB 최적화
스토리지 서비스로 전환
서비스 내부에 Amazon EC2, VPC,
DynamoDB, SWF 및 Route 53 등
다른 AWS 서비스들 사용
연속적인 백업을 위한 Amazon S3
와 통합으로 99.999999999%
내구성 제공
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route 53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3
5. Amazon Aurora 주요 특징
고성능 뛰어난 보안 MySQL과 호환
뛰어난 확장성 높은 가용성 및
내구성
완전 관리형
6. 손쉬운 데이터베이스 관리
• 수 분 내에 데이터베이스 생성
• 자동화된 패치
• 푸시-버튼 용량 확장
• Amazon S3 연속 백업
• 자동 장애 감지 및 페일오버
Amazon RDS
7. 손쉬운 스토리지 관리
• 읽기 복제에 페일오버 – 데이터 유실 없음
• 사용자 스냅샷 즉각 생성 – 성능 영향 없음
• Amazon S3에 연속, 증분 백업
• 최대 64TB까지 자동 스토리지 용량 확장 – 성능, 가용성 영향 없음
• 자동화된 재스트라이핑, 미러 복구, 핫스팟 관리, 암호화
8. 손쉬운 보안 향상
• 저장 시 암호화
• AES-256 및 하드웨어 가속
• 디스크 및 S3 내 모든 블록들은 암호화
• AWS KMS 를 통한 키 관리
• 전송 시 암호화 – SSL
• Amazon VPC를 통한 네트워크 격리
• 노드에 직접 접근 없음
• 산업 표준의 보안 및 데이터 보호 인증서 지원
Storage
SQL
Transactions
Caching
Amazon S3
Application
9. AWS 역사 상
가장 빠르게 성장 중인 서비스
비지니스 어플리케이션
웹 및 모바일
컨텐츠 관리
전자 상거래
사물 인터넷
검색 및 광고
비지니스 인텔리전스, 분석
게임, 미디어
다양한 적용 분야
12. 스마트한비즈니스습관,리멤버
찍으면 입력해주는 No.1 명함관리 앱
비서의수기입력 명함정보업데이트 주소록저장지원
100% 정확한 입력
수정이 필요없는 편리함
리멤버 회원 간 명함 정보 변경 시
실시간으로 자동 업데이트
휴대폰 및 구글 주소록에 저장,
Excel 다운로드 및 아웃룩 연계
리멤버 소개
14. 14/01
서비스는 순항중!
14/07 15/01 15/07 16/01 16/04
76만
2500만
1억
2억5천만
4억5천만
6억
그러나, 데이터 증가량에 대한 예측 실패.
데이터 증가 건 수가 예상치보다 많았다.
: 명함 데이터 테이블 (Actual)
: 명함 데이터 테이블 (Expected)
왜 DB이전을 고려하게 되었나요? (1)
15. 하나, 둘 발생하는 문제들
Optional subtitle
데이터가 급격히 많아짐에 따라 하나 둘 씩 흔히 나타나는 문제들이 발생하기 시작합니다.
• 점점 주기가 짧아지는 인덱스 통계정보 갱신으로 Query Execution Plan이 바뀌는 경우
가 가끔 발생.
• 구조적 핸디캡으로, 트랜잭션으로 인한 LOCK문제 발생하기 시작함.
• 쉽게 해소되지 않는 CPU 오버헤드. 서비스를 중단시키고 해소시켜야 하는 상황이 발생.
• 늘어나는 데이터에 대한 디스크 관리.
• 늘어난 워크로드.
왜 DB이전을 고려하게 되었나요? (2)
16. 스키마 구조 개선 vs 물리적 성능 개선
이 일을 어쩌지?
(사실 몇 달 전 빠른 기능확장성 위주의 대대적 스키마 구조 개편이 있었음)
왜 DB이전을 고려하게 되었나요? (3)
17. 그리고,
좀 더 안정적인 운영이 가능했으면 하는 바램.
왜 DB이전을 고려하게 되었나요? (4)
19. 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)
20. 테스트 조건
Optional subtitle
다음과 같이 SYSBENCH 테스트를 진행했습니다.
• 서버 파라미터 튜닝을 하지 않은 상태로 진행.
• RDBMS별 50개의 테이블에 각 1천만건 씩 총 5억건 데이터를 생성.
• RDBMS별 500개의 Thread로 OLTP Fully Read, Fully Write, Read/Write 테스트 진행.
• DB Warmup을 고려해 수 차례 OLTP 테스트 진행 후 마지막 3건의 결과 중 가장 좋은 수
치의 결과를 캡쳐.
벤치마크 테스트 (2)
21. 테스트 결과 : Fully Read
0
50000
100000
150000
Aurora MariaDB MySQL
Aurora MariaDB MySQL
(Request Per Second)
벤치마크 테스트 (4)
22. 테스트 결과 : Fully Write
0
5000
10000
15000
20000
Aurora MariaDB MySQL
Aurora MariaDB MySQL
(Request Per Second)
~2.0X
~2.4X
벤치마크 테스트 (5)
23. 테스트 결과 : Read / Write
0
20000
40000
60000
80000
Aurora MariaDB MySQL
Aurora MariaDB MySQL
(Request Per Second)
~4.5X ~5.4X
벤치마크 테스트 (6)
24. Aurora로 이전하기로 결정
Optional subtitle
성능, 안정성, 기능제공 면에서 MySQL, MariaDB보다 좋았다.
• 벤치마킹 결과와 같이 Aurora가 가장 좋은 성능을 보여주었다.
• Failover기능에 상당히 만족했다. 서버의 장애 상황을 감지해 자동으로 Failover하거나,
수동 Failover가 가능.
• 쉽게 데이터 이전이 가능.
• AWS RDS의 주력 제품으로, 꾸준한 개선 및 관리가 잘 될 것 같다는 기대감.
Aurora로 결정!
25. DB이전 다운타임 최소화 하기
Optional subtitle
DB이전을 할 때 다운타임을 최소화 하기 위한 방법은 놀라울 정도로 간단합니다!
• RDS MySQL의 최신 스냅샷을 Migrate기능을 이용해 AuroraDB로 이전
• Migrate하는 동안의 데이터 변경분 처리(AuroraDB를 Replica Server로 활용)
• 각 Applications에서 DB Endpoint를AuroraDB Cluster Endpoint로 변경
Aurora로 마이그레이션 (1)
26. 1. Binary log 보관 주기를 늘려주기
Optional subtitle
MySQL에서 AuroraDB로 Migrate하는 동안의 binlog는 기록되어 보관될 수 있도록 보관 주기
를 늘려줍니다.
• CALL mysql.rds_set_configuration(‘binlog retention hours’, 48);
Aurora로 마이그레이션 (2)
27. 2. AuroraDB 인스턴스 생성
Optional subtitle
기존에 사용하던 MySQL Master DB의 최신 Snapshot을 이용해
AuroraDB로 Migrate를 합니다.
• Migrate를 하기 전 해당 시점 binary log의 File과 Position을 잘 기록
해 둡니다.
• Binlog의 File과 Position은 “SHOW MASTER STATUS” 명령어를 통
해 확인합니다.
• 마이그레이션이 완료 되고 인스턴스가 생성될 때 까지 기다립니다.
Aurora로 마이그레이션 (3)
28. 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’;;
Aurora로 마이그레이션 (4)
29. 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;;
Aurora로 마이그레이션 (5)
30. 5. 서버 이전 마무리
Optional subtitle
AuroraDB가 MasterDB와 동기화가 되었다면 각 어플리케이션의 DB endpoint를 AuroraDB로
변경하고 마무리 합니다.
• 각 Application별로 DB endpoint를 AuroraDB의 Cluster Endpoint로 변경시켜 준비합니다.
• AuroraDB를 Master로 승격합니다.
• AuroraDB의 복제를 종료합니다.
• CALL mysql.rds_stop_replication;;
• 각 Application별로 Endpoint변경사항을 반영합니다.
Aurora로 마이그레이션 (6)
31. 서버 이전 후기
Optional subtitle
• 데이터는 약 1.5TB가량. 총 이전 시간 약 5시간.
• 이전 중 별다른 예외사항 없었음.
• 서비스 재시작을 위한 다운타임은 약 20분 가량.
• 요즘은 AWS DMS(Data Migration Service)를 통해 몇번의 클릭으로 손쉽게 데이터 이전이
가능함.
Aurora 이전 후기
32. Aurora 사용 후기
Optional subtitle
• 심리적 안정감.
• 디스크 관리에서 해방!
• 강력한 Fail over기능.
• 상세한 서버 모니터링 툴.
• 유지 가능한 캐시 워밍. 손 워밍에서 해방!
• 충분한 네트웍 대역폭과 성능이 보장되면 정말로 MySQL 5.6대비 5배의 처리량을 보여줌.
Aurora 사용 후기
33. Aurora 사용 팁
Optional subtitle
• 자주 업데이트 되고 있다. 한 두달에 한 번은 업데이트 기록을 찾아보자. 좋은 기능이 생겨있
을 가능성이 높다.
• RDS에 대해 현재까지 보고된 문제들은 RDS DOC의 “문제 해결”에 자세히 나와있다. 반드
시 참조해야 한다.
• MariaDB에서 만든 MariaDB-Connector-j에 Aurora를 위한 failover제어 기능이 들어있다.
Aurora TIP
34. 우리의 경험들이 차곡차곡!
드라마 개발그룹블로그!
http://developer.dramancompany.com
드라마앤컴퍼니 개발그룹 블로그를 소개합니다!
37. SQL 성능 테스트 결과
4 클라이언트 머신 및 각 1,000 connections
WRITE PERFORMANCE READ PERFORMANCE
단일 클라이언트 머신 및 각 1,600 connections
Amazon Aurora r3.8xl (32 vCPU, 244 GB RAM) 사용 MySQL SysBench 성능 테스트
38. 성능 테스트 수행
https:/ /d0.aw ss tati c. com /produ ct - ma rket ing/Au ro ra/ RDS_Au ro ra_Pe rfo r mance_A sse ss ment_Bench ma r king_ v1-2 .pdf
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
Amazon Aurora DB 인스턴스 실행
• 벤치마크 시작
1
2
3
4
5
6
7
39. 사용자 수 증가에 따른 성능 확장
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
40. 테이블 수 증가에 따른 성능 확장
SysBench 쓰기-전용 워크로드
1,000 접속, 기본 설정
Tables
Amazon
Aurora
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
41. 데이터 크기 증가에 따른 성능 확장
SYSBENCH WRITE-ONLY
DB Size Amazon Aurora
RDS MySQL
30 K IOPS (single AZ)
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
42. 읽기 복제에 따른 지연 감소
SysBench OLTP 워크로드
250 테이블
Updates per
second Amazon Aurora
RDS MySQL
30 K 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
500x
UP TO
LO W ER LAG
43. I/O의 감소
네트워크 패킷 최소화
기존 결과를 캐시
데이터베이스 엔진 오프로드
DO LESS WORK
비동기식 처리
응답속도 경로 감소
락-없는 데이터 구조 사용
배치 수행 동시 처리
BE MORE EFFICIENT
성능을 위한 Aurora 아키텍처
DATABASES ARE ALL ABOUT I/O
NETWORK-ATTACHED STORAGE IS ALL ABOUT PACKETS/SECOND
HIGH-THROUGHPUT PROCESSING DOES NOT ALLOW CONTEXT SWITCHES
45. Aurora 클러스터 및 읽기 복제
Amazon S3
AZ 1 AZ 2 AZ 3
Aurora 프라이머리
인스턴스
3 가용영역에 걸친 클러스터 볼륨
Aurora 복제 Aurora 복제
46. BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W RI T E
MYSQL WITH STANDBY
EBS 볼륨에 쓰기 수행 - EBS 는 미러에 쓰기 수행, 둘 다 종료
시 ACK
스탠바이 인스턴스에 쓰기 복제
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
EBS 미러EBS 미러
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
프라이머리
인스턴스
스탠바이
인스턴스
1
2
3
4
5
RDS MySQL I/O 트래픽
47. AZ 1 AZ 3
프라이머리
인스턴스
Amazon S3
AZ 2
복제
인스턴스
AMAZON AURORA
비동기
4/6 쿼럼
분산 쓰기
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W RI 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 트래픽
48. 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 트래픽 - 스토리지
49. Aurora I/O 트래픽 – 읽기 복제
페이지 캐시
업데이트
Aurora 마스터
30% 읽기
70% 쓰기
Aurora 복제
100% 신규 읽기
공유 Multi-AZ 스토리지
MySQL 마스터
30% 읽기
70% 쓰기
MySQL 복제
30% 신규 읽기
70% 쓰기
싱글-스레드
BINLOG 전송
데이터 볼륨 데이터 볼륨
Logical: SQL 문을 복제에 적용
쓰기 부하는 양쪽 노드에서 유사
별도 스토리지
마스터 및 복제 사이에 데이터 차이 존재
Physical: 마스터에서 복제로 redo를 전송
복제는 스토리지를 공유.
쓰기 수행 없음
캐시된 페이지는 Redo 적용
MYSQL READ SCALING AMAZON AURORA READ SCALING
50. Asynchronous group commits
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
TRADITIONAL APPROACH AMAZON AURORA
디스크에 쓰기 위한 로그 레코드의 버퍼 관리
쓰기 작업을 위한 버퍼 풀(Full) 또는 타임아웃 발생 시 쓰기 작업
수행
쓰기 비율이 낮을 때 첫번째 쓰기에 응답속도 페널티
첫번째 쓰기에 I/O 요청.
개별 쓰기는 6개 스토리지 노드 중 4개 쓰기 ACK 시 내구성
비동기식 트랜잭션 처리로 성능 및 효율성 제공
51. 액티브 스레드에 접속을 멀티플렉싱
커널 영역의 epoll() 통한 latch-free 이벤트 큐 입력
스레드 풀 크기 동적 조정
5000+ 동시 클라이언트 세션을 r3.8xl에서 처리
표준 MySQL— 접속 당 스레드
접속 수 증가에 확장되지 않음
MySQL EE — 접속은 스레드 그룹에 할당.
쓰레쉬홀드 조정 등에 있어 주의 필요
CLIENT CONNECTION
CLIENT CONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
Adaptive thread pool
53. Amazon Aurora의 스토리지
기본 고가용성
• 3 가용영역에 6-way 복제
• 4 / 6 쓰기, 3 / 6 읽기 쿼럼
• S3 저장소에 연속 백업
SSD, 스케일-아웃, 멀티-테넌트
스토리지
• 연속적 스토리지 확장
• 최대 64TB 크기
• 사용한만큼만 지불
로그-구조 기반 스토리지
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3
54. 스토리지 자가 치유 및 장애 내구성
자동 장애 감지, 복제, 복구
2개의 복제 및 1개 가용 영역 장애는 읽기 및 쓰기 가용성에 영향 없음
3개의 복제 장애에도 읽기 가용성에 영향 없음
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availability Read availability
55. Amazon Aurora의 스토리지 백업 및 복구
자동 백업(Automated Backup)
• RDS는 백업을 자동으로 생성
• 신규 DB 인스턴스에 자동으로
활성화
• 백업 보관 기간(Backup Retention
Period) 동안 데이터 보관 (1~35일)
• 연속 및 증분 백업
• 백업 중 성능 영향 없음
스냅샷 (DB Snapshots)
• 사용자가 생성한 백업
• 원하는 주기로 백업
• 백업 보관 기간 이상 보관
• 어느 시점으로도 복구 가능
56. Amazon Aurora의 스토리지 백업 및 복구
복구 (Restore)
• 백업 또는 스냅샷으로부터 신규 Aurora
DB 클러스터 생성
• 백업 보관 주기 내 어느 시점으로든
복구
• Latest Restorable Time : 보통 5분 이내
• Earliest Restorable Time : 백업 보관 주기
• Aurora Backup은 연속, 증분 백업으로
복구 시간 향상을 위해 빈번한 스냅샷
생성을 할 필요 없음
57. 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
59. 신속한 크래시 복구
최종 체크포인트 이후 로그 재생 필요
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
60. 캐시 유지
데이터베이스 프로세스와 캐시의
분리
데이터베이스 재기동 이벤트
시에도 캐시 웜(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.
61. 보다 신속하고 예측 가능한 페일오버
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORA WITH MARIADB DRIVER
15– 20초
3– 20초
62. 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
64. Amazon 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 지역 기준
65. 소유 비용: 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
66. 소유 비용 : 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
67. 소유 비용 : Aurora vs. MySQL
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
69. RDS Aurora 생성 및 마이그레이션
RDS 런치 시 Amazon Aurora 엔진 선택하여
신규 RDS 인스턴스 런치
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
70. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
DB on
instance
RDS Aurora
instance
PostgreSQLPostgreSQL
Auror
amysqldump / mysqlimport
• MySQL 에서 Aurora 이전을 위하여 데이터
익스포트에 표준적인 mysqldump utility 사용 및
데이터 임포트에 mysqlimport 유틸리티사용 또는
반대도 가능
71. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션(non-MySQL)
RDS MySQL
instance
RDS Aurora
instance
PostgreSQLPostgreSQLAurora
Snapshot migration
• MySQL v5.6 : RDS DB Snapshot 마이그레이션
• MySQL v5.6 이전 : DB 업그레이드 후 DB 스냅샷
마이그레이션
MySQL
72. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
• 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
78. 서비스 중심 아키텍처 적용 데이터베이스
로깅 및 스토리지를 멀티-테넌시
스케일-아웃 기반 DB 최적화
스토리지 서비스로 전환
서비스 내부에 Amazon EC2, VPC,
DynamoDB, SWF 및 Route 53 등
다른 AWS 서비스들 사용
연속적인 백업을 위한 Amazon S3
와 통합으로 99.999999999%
내구성 제공
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route 53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3
79. Amazon Aurora 주요 특징
고성능 뛰어난 보안 MySQL과 호환
뛰어난 확장성 높은 가용성 및
내구성
완전 관리형
80. 손쉬운 데이터베이스 관리
• 수 분 내에 데이터베이스 생성
• 자동화된 패치
• 푸시-버튼 용량 확장
• Amazon S3 연속 백업
• 자동 장애 감지 및 페일오버
Amazon RDS
81. 손쉬운 스토리지 관리
• 읽기 복제에 페일오버 – 데이터 유실 없음
• 사용자 스냅샷 즉각 생성 – 성능 영향 없음
• Amazon S3에 연속, 증분 백업
• 최대 64TB까지 자동 스토리지 용량 확장 – 성능, 가용성 영향 없음
• 자동화된 재스트라이핑, 미러 복구, 핫스팟 관리, 암호화
82. 손쉬운 보안 향상
• 저장 시 암호화
• AES-256 및 하드웨어 가속
• 디스크 및 S3 내 모든 블록들은 암호화
• AWS KMS 를 통한 키 관리
• 전송 시 암호화 – SSL
• Amazon VPC를 통한 네트워크 격리
• 노드에 직접 접근 없음
• 산업 표준의 보안 및 데이터 보호 인증서 지원
Storage
SQL
Transactions
Caching
Amazon S3
Application
83. AWS 역사 상
가장 빠르게 성장 중인 서비스
비지니스 어플리케이션
웹 및 모바일
컨텐츠 관리
전자 상거래
사물 인터넷
검색 및 광고
비지니스 인텔리전스, 분석
게임, 미디어
다양한 적용 분야
84. 센드버드 오로라 사용 사례
(Migrating to Amazon RDS Aurora)
김여신 (Harry Kim)
CTO, SendBird
85. Aurora DB로의 이전을 결정한 배경
SendBird 는 모바일 앱/웹사이트를 위한 실시간 메시징 솔루션 입니다.
§ 크로스 플랫폼 지원: iOS, Android, 유니티 3D엔진, 웹(JavaScript),
자마린 SDK 및 서버 API 제공
§ 월 ~2백만 최종 고객 (End-user)이 센드버드를 통해 채팅 서비스
이용 (일 1백만 건 이상의 신규 메시지, 일 50억 건 이상의 전송량)
전세계적으로 5,600개 개발사가 센드버드 서비스에 가입하여, 이 중
900개 앱에 탑재되어 이용중입니다. 센드버드는 월 60%의 속도로
빠르게 성장하고 있습니다.
SendBird 소개
채팅 서비스의 특성 상 많은 메시징
데이터가 쌓였고, 이를 처리하던 기존
MariaDB (Persistent Storage)에서
성능 외적인 문제를 직면
백업 레플리카
Failover 하드웨어
예측
센드버드 소개 및 Aurora이전 결정 배경
86. Aurora는 아마존에서 제공 하는 MySQL 호환성을 가지고 더 높은 성능과 향상된
기능을 제공하는 AWS RDS(Relational Database Service) 서비스 중 하나입니다
§ MySQL과 호환되며 오로라 엔진을 채용하여 퍼포먼스와 신뢰도를 향상시킴으로
기존 MySQL 클라이언트를 그대로 적용할 수 있다는 장점이 존재
§ 기존 RDS에 비해 자동 스토리지 용량 증설, 로우 레이턴시 복제기능, 향상된
Failover 등 향상된 성능을 제공
오로라 DB 소개
87. Self-Hosted
RDBMS
서비스 중 하드웨어
업그레이드 어려움
수동적인 장애 조치
백업 용량 및 시간 증가1
레플리카
생성 어려움
2
3
4
Problem We Faced : Self-Hosted RDBMS
88. 1
과거 센드버드는 유저 데이터를 Daily로 백업하여 S3에 올리는 방식을 사용해 작업 시간의 낭비를 경험
§ 백업데이터의 증가로 몇 백기가에 달하는 데이터를 압축하고 전송하는데 시간 소요
§ 데이터 유실이 발생하는 경우 이를 처리하기 위한 데이터 복구에 수동적인 방법 적용
Problem We Faced : 백업
89. Problem We Faced : 레플리카
레플리카 추가시에도 막대한 시간 낭비, 리소스 비효율이 초래됨
새로운
인스턴스
생성
기존
마스터에서
데이터 덤프
레플리카에
리스토어
2
90. 사람의 지속적인 개입을 필요로 했던 Failover
“…마스터의 장애 발견…레플리카의 복제 차단…
기존 서버의 설정 모두 레플리카 서버로 수정 후
재시작…모든 서버에 접근해 서비스의 DB설정 변경…”
Problem We Faced : 장애조치3
91. AWS를 사용하는 이유 중
하나인 온디맨드(On-Demand)
하드웨어 증설이 어려워지고
비효율적인 하드웨어 예측 발생
추후 다운타임(Downtime)을 최소화
하기 위해 필연적으로 필요이상의
스토리지 용량과 하드웨어 티어를
선택할 수 밖에 없음
Problem We Faced : 하드웨어 예측4
93. 백업 시간을 지정하면 해당 시간대에 스냅샷 형태로 저장이 되며
백업된 스냅샷으로 새로운 RDS 인스턴스를 생성 가능
Aurora 이전 후 개선사항 : 백업1
94. 필요에 따라 언제든지 레플리카를 추가하여
고(高) 가용성과 읽기 확장성을 확보함
§ 원 클릭으로 생성이 가능
§ 10분 이내 생성 후 적용 가능
Aurora 이전 후 개선사항 : 레플리카2
95. 일반적으로 레플리카로의 Failover가 30초
내 가능해지며, 마스터 하드웨어
업그레이드가 매우 손쉽게 진행 가능
§ 자동으로 레플리카 서버를 마스터로 승격
§ 도메인 변경 불필요
§ 장애 후 30초 이내 복구 가능
Aurora 이전 후 개선사항 : 장애조치3
96. l 현 상황에 맞는 Tier를 선택 가능: 스토리지
용량이 증가함에 따라 64 TB까지 자동으로 증설
가능
l 원할 경우 최소한의 다운타임으로 Tier 변경 가능:
1분 내의 다운타임만으로 다음 티어의
하드웨어로 업그레이드 가능
Aurora 이전 후 개선사항 : 하드웨어 업그레이드4
97. 레플리카를 마스터로 승격
마스터 Tier 업그레이드
마스터 복구
총 장애 시간
1분 이내
실제 사례 (Case study): 최소한의 다운타임으로
Aurora DB 업그레이드 하기
98. § 백업을 이용해 즉시 디비 인스턴스를 생성;; 배포 전 테스트를 위한 임시 디비
생성에 걸리는 시간 비약적 단축
§ 원 클릭 Failover 기능으로 인해 고가용성을 확보
§ CloudWatch API를 이용하여 오로라 디비의 모든 메트릭을 상세히 사내
대시보드에 통합할 수 있었음
§ 하드웨어의 변경에 따른 부담이 감소하여 최적화된 코스트의 장비를 선택 가능
§ 특히, 인프라팀을 운영할 수 없는 경우 비용 절감 효과 및 서비스 신뢰성 향상 가능
결론 (Conclusion)
100. SQL 성능 테스트 결과
4 클라이언트 머신 및 각 1,000 connections
WRITE PERFORMANCE READ PERFORMANCE
단일 클라이언트 머신 및 각 1,600 connections
Amazon Aurora r3.8xl (32 vCPU, 244 GB RAM) 사용 MySQL SysBench 성능 테스트
101. 성능 테스트 수행
https:/ /d0.aw ss tati c. com /produ ct - ma rket ing/Au ro ra/ RDS_Au ro ra_Pe rfo r mance_A sse ss ment_Bench ma r king_ v1-2 .pdf
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
Amazon Aurora DB 인스턴스 실행
• 벤치마크 시작
1
2
3
4
5
6
7
102. 사용자 수 증가에 따른 성능 확장
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
103. 테이블 수 증가에 따른 성능 확장
SysBench 쓰기-전용 워크로드
1,000 접속, 기본 설정
Tables
Amazon
Aurora
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
104. 데이터 크기 증가에 따른 성능 확장
SYSBENCH WRITE-ONLY
DB Size Amazon Aurora
RDS MySQL
30 K IOPS (single AZ)
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
105. 읽기 복제에 따른 지연 감소
SysBench OLTP 워크로드
250 테이블
Updates per
second Amazon Aurora
RDS MySQL
30 K 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
500x
UP TO
LO W ER LAG
106. I/O의 감소
네트워크 패킷 최소화
기존 결과를 캐시
데이터베이스 엔진 오프로드
DO LESS WORK
비동기식 처리
응답속도 경로 감소
락-없는 데이터 구조 사용
배치 수행 동시 처리
BE MORE EFFICIENT
성능을 위한 Aurora 아키텍처
DATABASES ARE ALL ABOUT I/O
NETWORK-ATTACHED STORAGE IS ALL ABOUT PACKETS/SECOND
HIGH-THROUGHPUT PROCESSING DOES NOT ALLOW CONTEXT SWITCHES
108. Aurora 클러스터 및 읽기 복제
Amazon S3
AZ 1 AZ 2 AZ 3
Aurora 프라이머리
인스턴스
3 가용영역에 걸친 클러스터 볼륨
Aurora 복제 Aurora 복제
109. BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W RI T E
MYSQL WITH STANDBY
EBS 볼륨에 쓰기 수행 - EBS 는 미러에 쓰기 수행, 둘 다 종료
시 ACK
스탠바이 인스턴스에 쓰기 복제
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
EBS 미러EBS 미러
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
프라이머리
인스턴스
스탠바이
인스턴스
1
2
3
4
5
RDS MySQL I/O 트래픽
110. AZ 1 AZ 3
프라이머리
인스턴스
Amazon S3
AZ 2
복제
인스턴스
AMAZON AURORA
비동기
4/6 쿼럼
분산 쓰기
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W RI 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 트래픽
111. 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 트래픽 - 스토리지
112. Aurora I/O 트래픽 – 읽기 복제
페이지 캐시
업데이트
Aurora 마스터
30% 읽기
70% 쓰기
Aurora 복제
100% 신규 읽기
공유 Multi-AZ 스토리지
MySQL 마스터
30% 읽기
70% 쓰기
MySQL 복제
30% 신규 읽기
70% 쓰기
싱글-스레드
BINLOG 전송
데이터 볼륨 데이터 볼륨
Logical: SQL 문을 복제에 적용
쓰기 부하는 양쪽 노드에서 유사
별도 스토리지
마스터 및 복제 사이에 데이터 차이 존재
Physical: 마스터에서 복제로 redo를 전송
복제는 스토리지를 공유.
쓰기 수행 없음
캐시된 페이지는 Redo 적용
MYSQL READ SCALING AMAZON AURORA READ SCALING
113. Asynchronous group commits
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
TRADITIONAL APPROACH AMAZON AURORA
디스크에 쓰기 위한 로그 레코드의 버퍼 관리
쓰기 작업을 위한 버퍼 풀(Full) 또는 타임아웃 발생 시 쓰기 작업
수행
쓰기 비율이 낮을 때 첫번째 쓰기에 응답속도 페널티
첫번째 쓰기에 I/O 요청.
개별 쓰기는 6개 스토리지 노드 중 4개 쓰기 ACK 시 내구성
비동기식 트랜잭션 처리로 성능 및 효율성 제공
114. 액티브 스레드에 접속을 멀티플렉싱
커널 영역의 epoll() 통한 latch-free 이벤트 큐 입력
스레드 풀 크기 동적 조정
5000+ 동시 클라이언트 세션을 r3.8xl에서 처리
표준 MySQL— 접속 당 스레드
접속 수 증가에 확장되지 않음
MySQL EE — 접속은 스레드 그룹에 할당.
쓰레쉬홀드 조정 등에 있어 주의 필요
CLIENT CONNECTION
CLIENT CONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
Adaptive thread pool
116. Amazon Aurora의 스토리지
기본 고가용성
• 3 가용영역에 6-way 복제
• 4 / 6 쓰기, 3 / 6 읽기 쿼럼
• S3 저장소에 연속 백업
SSD, 스케일-아웃, 멀티-테넌트
스토리지
• 연속적 스토리지 확장
• 최대 64TB 크기
• 사용한만큼만 지불
로그-구조 기반 스토리지
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3
117. 스토리지 자가 치유 및 장애 내구성
자동 장애 감지, 복제, 복구
2개의 복제 및 1개 가용 영역 장애는 읽기 및 쓰기 가용성에 영향 없음
3개의 복제 장애에도 읽기 가용성에 영향 없음
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availability Read availability
118. Amazon Aurora의 스토리지 백업 및 복구
자동 백업(Automated Backup)
• RDS는 백업을 자동으로 생성
• 신규 DB 인스턴스에 자동으로
활성화
• 백업 보관 기간(Backup Retention
Period) 동안 데이터 보관 (1~35일)
• 연속 및 증분 백업
• 백업 중 성능 영향 없음
스냅샷 (DB Snapshots)
• 사용자가 생성한 백업
• 원하는 주기로 백업
• 백업 보관 기간 이상 보관
• 어느 시점으로도 복구 가능
119. Amazon Aurora의 스토리지 백업 및 복구
복구 (Restore)
• 백업 또는 스냅샷으로부터 신규 Aurora
DB 클러스터 생성
• 백업 보관 주기 내 어느 시점으로든
복구
• Latest Restorable Time : 보통 5분 이내
• Earliest Restorable Time : 백업 보관 주기
• Aurora Backup은 연속, 증분 백업으로
복구 시간 향상을 위해 빈번한 스냅샷
생성을 할 필요 없음
120. 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
122. 신속한 크래시 복구
최종 체크포인트 이후 로그 재생 필요
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
123. 캐시 유지
데이터베이스 프로세스와 캐시의
분리
데이터베이스 재기동 이벤트
시에도 캐시 웜(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.
124. 보다 신속하고 예측 가능한 페일오버
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MYSQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
AURORA WITH MARIADB DRIVER
15– 20초
3– 20초
125. 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
127. Amazon 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 지역 기준
128. 소유 비용: 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
129. 소유 비용 : 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
130. 소유 비용 : Aurora vs. MySQL
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
132. RDS Aurora 생성 및 마이그레이션
RDS 런치 시 Amazon Aurora 엔진 선택하여
신규 RDS 인스턴스 런치
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
133. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
DB on
instance
RDS Aurora
instance
PostgreSQLPostgreSQL
Auror
amysqldump / mysqlimport
• MySQL 에서 Aurora 이전을 위하여 데이터
익스포트에 표준적인 mysqldump utility 사용 및
데이터 임포트에 mysqlimport 유틸리티사용 또는
반대도 가능
134. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션(non-MySQL)
RDS MySQL
instance
RDS Aurora
instance
PostgreSQLPostgreSQL
Auror
aSnapshot migration
• MySQL v5.6 : RDS DB Snapshot 마이그레이션
• MySQL v5.6 이전 : DB 업그레이드 후 DB 스냅샷
마이그레이션
MySQL
135. RDS Aurora 생성 및 마이그레이션
신규
마이그레이션 (MySQL)
마이그레이션 (RDS MySQL)
마이그레이션 (non-MySQL)
• 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
PostgreSQLPostgreSQLAuror
a
Database
Migration Service
OracleMS SQLPostgreSQLPostgreSQL