AWS 9월 웨비나 연사: 김필중, 솔루션즈 아키텍트

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
김필중, 솔루션즈 아키텍트
2017. 09. 27
Amazon Aurora Deep Dive

2. 강연 중 질문하는 법
자신이 질문한 내역이 표시되며, 전체 공개로 답변된 내용은 검은색,
질문자 본인에게만 공개로 답변된 내용은 붉은 색으로 돌아옵니다.

3. 본 세션의 주요 주제
• Amazon Aurora 개요
• Amazon Aurora 아키텍처 및 특징
• 성능
• 내구성과 가용성
• 운영 효율성
• 비용
• PostgreSQL 호환 Amazon Aurora

4. Amazon Relational Database Service (RDS)
• 관계형 데이터베이스
• 완전 관리형 서비스
• 빠르고 손쉬운 확장
• 빠르고 예측 가능한 성능
• 비용 절감, 사용량만큼 지불

5. Amazon Aurora란?
오픈 소스 호환 관계형 데이터베이스
MySQL 호환 관계형 데이터베이스
상업용 데이터베이스의 성능과 가용성
오픈소스 데이터베이스의 단순성과 비용 효율성

6. Aurora의 도입
AWS 역사상 가장
빠르게 성장하고
있는 서비스
비지니스 애플리케이션
웹/모바일
컨텐츠 관리
E-커머스, 리테일
IoT
검색, 광고
BI, 분석
게임, 미디어
탑 100 AWS 고객 중 2/3
탑 10 게이밍 고객 중 8

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

8. 데이터베이스의 역사
모놀리식 스택에 있는
여러 기능 계층들
SQL
Transactions
Caching
Logging
클라우드를 고려하지 않고 설계된 관계형 데이터베이스!

9. 지난 30년간 크게 바뀌지 않음
각 아키텍처는 모놀리식 사고 방식으로 제한됨
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Application
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Application
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Storage
Application

10. 관계형 데이터베이스의 재구성
오늘날 데이터베이스를 발명한다면?
- 스택을 레이어별로 분리하는건 필수!
- 고려할 것들
- 스케일-아웃이 가능하게
- Self-healing 이 가능하게
- 분산 서비스를 활용할 수 있게

11. 서비스 지향 아키텍처 적용 데이터베이스
로깅 및 스토리지를 멀티-테넌트,
스케일-아웃, DB 최적화 스토리지
서비스로 이동
EC2, VPC, DynamoDB, SWF, Route
53 등 다른 AWS 서비스들과
통합하여 제어 및 모니터링
운영 및 관리의 부담을 줄일 수
있는 Amazon RDS 를 통해 관리형
서비스로 제공
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route 53
Logging + Storage
SQL
Transactions
Caching
Amazon S3
1
2
3

12. Aurora 클러스터
Amazon S3
AZ 1 AZ 2 AZ 3
Aurora primary
instance
3개의 AZ에 걸친 클러스터 볼륨

13. 레플리카와 Aurora 클러스터
Amazon S3
AZ 1 AZ 2 AZ 3
Aurora primary
instance
3개의 AZ에 걸친 클러스터 볼륨
Aurora Replica Aurora Replica

14. 성능
빠릅니다. MySQL 보다 5배나 더.

15. 인스턴스 크기와 함께 확장
WRITE PERFORMANCE READ PERFORMANCE
오로라는 읽기와 쓰기 모두의 인스턴스 크기에 따라 확장
Aurora MySQL 5.6 MySQL 5.7

16. 응답속도 개선 사례 – 게임 워크로드
3배 빠른 Aurora (r3.4xlarge)
Aurora vs RDS MySQL – r3.4XL, MAZ

17. MySQL의 I/O 트래픽
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R I T E
MYSQL WITH REPLICA
EBS에 쓰기 시작 – EBS는 미러링을 하고 완료 시 ack
DRBD를 통해 레플리카 인스턴스에 쓰기
레플리카 인스턴스의 EBS에 쓰기 수행
IO FLOW
스텝 1, 3, 4는 순차적이며 동기식
대기 시간과 지터 모두 증폭
각 작업에 대해 쓰기 유형이 많음
쓰기 조각을 방지하기 위해 데이터 블록을 두번 써야함
OBSERVATIONS
78만 트랜잭션
백만 트랜잭션 당 738만8천 I/O (미러링과 스탠바이 제외)
트랜잭션 당 평균 7.4 I/O
PERFORMANCE
30분 SysBench 쓰기 워크로드, 100 GB 데이터세트, RDS 단일 AZ, 3만 PIOPS
EBS mirrorEBS mirror
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
Primary
instance
Standby
instance
1
2
3
4
5

18. Aurora의 I/O 트래픽
AZ 1 AZ 3
Primary
instance
Amazon S3
AZ 2
Replica
instance
AMAZON AURORA
ASYNC
4/6 QUORUM
DISTRIBUTED
WRITES
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R I T E
30분 SysBench 쓰기 워크로드, 100 GB 데이터세트
IO FLOW
Redo 로그 레코드만 씀; 모든 단계는 비동기
데이터 블록 쓰기 없음 (체크포인트, 캐시 교체)
6배 더 로그를 쓰지만, 9배 더 적은 네트워크 트래픽
네트워크 및 스토리지 외부 지연 용인
OBSERVATIONS
2737만8천 트랜잭션 35X 더 많고
백만 트랜잭션 당 95만 I/O (6배 증폭) 7.7X 더 적음
PERFORMANCE
redo 로그 레코드 – LSN으로 정렬됨
적절한 세그먼트로 셔플 – 부분 정렬
스토리지 노드로 이동 후 쓰기 수행

19. Aurora의 I/O 트래픽 (스토리지 노드)
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 GOSSIPPeer
storage
nodes
모든 단계는 비동기
단계 1과 단계 2만 앞단의 지연에 영향을 줌
입력 큐는 MySQL 보다 46배 더 작음 (증폭없음, 노드 당)
지연에 민감한 작업에 강함
트래픽 급증 시 디스크 공간을 버퍼로 사용
OBSERVATIONS
IO FLOW
① 레코드를 받아서 인-메모리 큐에 추가
② 레코드를 유지하고 ACK
③ 레코드를 구성하고 로그와의 갭을 확인
④ 구멍을 메꾸기 위해 피어간 통신
⑤ 로그 레코드를 새로운 데이터 블록 버전으로 통합
⑥ 주기적으로 로그 및 새로운 블록 버전을 S3에 적제
⑦ 주기적으로 오래된 버전에 대한 가비지 콜렉트
⑧ 주기적으로 블록의 CRC 코드 유효성 검사

20. Aurora의 I/O 트래픽 (Replica)
페이지 캐시
업데이트
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
싱글 스레드
Binlog 적용
Data Volume Data Volume
Logical: SQL 문을 레플리카로 전송
쓰기 워크로드는 양쪽 모두 비슷함
독립 스토리지
마스터와 읽기 레플리카간 데이터 드리프트가
발생할 수 있음
Physical: 마스터에서 redo 를 레플리카로 전송
레플리카는 공유 스토리지 사용; 쓰기 수행 없음
캐시된 페이지에 redo 가 적용됨
모든 커밋이 보일 때 미리 읽음
MYSQL READ SCALING AMAZON AURORA READ SCALING

21. 실제 사례: 읽기 레플리카 지연
“In MySQL, we saw replica lag spike to almost 12 minutes which is
almost absurd from an application’s perspective. With Aurora, the
maximum read replica lag across 4 replicas never exceeded 20 ms.”

22. 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
디스크에 기록할 로그 레코드 버퍼 유지
버퍼가 가득 차거나 쓰기를 기다리는 시간이 초과되면 쓰기
쓰기 속도가 느릴 때 첫번째 쓰기는 레이턴시 패널티 있음
첫 쓰기에서 I/O 요청, 쓰기가 완료될때까지 버퍼를 채움
6개의 스토리지 노드 중 4개가 ACK 일 때 개별 쓰기 내구성
가장 이른 대기중인 ACK 까지 DB 내구성을 가짐
비동기 그룹 커밋

23. 적응형 스레드 풀
• 활성 스레드에 멀티플렉싱 커넥션을 재사용
• 커널 영역의 epoll() 은 latch-free 큐에 삽입
• 동적 크기의 스레드 풀
• r3.8xl 에서 5000 개 이상의 동시 클라이언트 세션을
안정적으로(gracefully) 처리
표준 MySQL – 커넥션 당 하나의 스레드
커넥션 개수에 맞추어 확장되지 않음
MySQL EE – 커넥션은 스레드 그룹에 할당
조심스럽게 스톨 임계 값 튜닝 필요
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL

24. Aurora 락 관리
MySQL lock manager Aurora lock manager
• MySQL과 동일한 locking 시맨틱
• Lock 체인에 동시 접근
• 개별 Lock 채인에 여러개의 스캐너 허용
• Lock-free 데드락 감지
높은 업데이트 처리량과 많은 동시 세션을 지원하기 위해 필요

25. 캐시 읽기 성능
• 카탈로그 동시성: 향상된 데이터 사전
동기화 및 캐시 에빅션
• NUMA 인식 스케줄러: Aurora 스케줄러가
NUMA를 인식, 멀티 소켓 인스턴스 확장을
지원
• 읽기 뷰: Latch-free 동시 읽기-뷰 알고리즘
을 사용하여 읽기 뷰를 구성
0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
초당 수천건의 읽기 요청
* R3.8xlarge 인스턴스. <1GB 데이터세트, Sysbench 사용

26. 비캐시 읽기 성능
• 스마트 스케줄러: Aurora 스케줄러는 I/O
위주의 워크로드와 CPU 위주의
워크로드간에 스레드를 동적으로 할당
• 스마트 셀렉터: Aurora 최상의 성능으로
스토리지 노드에서 데이터 복사본을
선택하여 읽기 대기 시간을 줄임
• LRA (Logical read ahead): B-tree 내의
순서를 기반으로 페이지를 프리패치하여
읽기 I/O 대기를 회피
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
초당 수천건의 요청
* R3.8xlarge 인스턴스, 1TB 데이터세트, Sysbench 사용
10% 처리량 증가

27. 삽입 성능
• 커서 위치를 캐싱함으로써, 기본키로
정렬된 배치 삽입을 가속화
• 데이터 패턴에 따라 동적으로 활성
및 비활성
• 트리를 탐색하는 동안 불필요한
래치를 획득을 피함
• 양방향성, 모든 삽입문에서 동작
• LOAD INFILE, INSERT INTO SELECT,
INSERT INTO REPLACE, 다중 값 삽입
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL: 모든 삽입에 대해 루트부터 시작하여 B-tree를 순회
Aurora: 삽입은 인덱스 순회를 방지

28. 빠른 인덱스 구축
§ MySQL 5.6은 리눅스 read ahead를 활용하며
B-tree 에서 블록 주소를 요구. 탑다운 방식의
새로운 트리 삽입은 결국 분할과 과도한
로깅이 발생
§ Aurora의 스캔은 블록 주소가 아닌 트리의
위치를 기반으로 블록을 미리 가져옴
§ Aurora는 leaf 블록을 만들고 트리의 branch
를 만듬
• 구축 시 분할이 발생하지 않음
• 각 페이지는 한번씩만 접근
• 페이지 당 하나의 로그 레코드
MySQL 5.6 또는 MySQL 5.7 에 비해 2-4 배 우수
0
2
4
6
8
10
12
r3.large on 10GB
dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours
RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

29. 성능 향상의 이유
더 적은 I/Os 수행
네트워크 패킷 최소화
이전 결과 캐시
데이터베이스 엔진 오프로드
더 적은 작업
비동기 처리
지연 줄임
Lock 없는 데이터 구조 사용
배치 작업
더 효율적으로
데이터베이스의 대부분은 I/O
네트워크로 연결되는 스토리지의 대부분은 PACKETS/SECOND
높은 처리량을 위해 허용하지 않는 CONTEXT SWITCHES

30. 벤치마크 수행법
https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf
AMAZON
AURORA
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
R3.8XLARGE
• Amazon VPC 생성 (또는 기존 VPC 사용)
• SysBench를 실행하기 위해 4개의 EC2 R3.8XL 인스턴스를
생성 (4개의 인스턴스는 동일한 가용영역에 있어야 합니다)
• 클라이언트에서 향상된 네트워킹 (Enhanced networking)
활성화
• Linux 설정 튜닝 (자세한건 백서 참조)
• SysBench (v0.5) 설치
• 동일한 VPC 및 가용영역에서 R3.8XL Amazon Aurora DB
인스턴스 시작
• 벤치마크 시작!
1
2
3
4
5
6
7

31. 성능을 위한 모범사례 (Best Practices)
• MySQL과 RDBMS에서의 전략은 여전히 유효
• 작업에 적합한 도구를 선택 (OLAP vs OLTP)
• 적절한 인덱스 생성
• SQL 코드 튜닝, Explain plan 사용, 성능 스키마 사용
• 높은 동시성 활용
• 커넥션 갯수에 따라 Aurora 처리량 증가
• 높은 동시성을 활용하도록 애플리케이션 설계
• 읽기 확장성
• 사실상 레플리케이션 랙 없이 읽기 레플리카를 제공
• 여러개의 읽기 레플리카로 읽기를 분산

32. 성능을 위한 모범사례 (Best Practices)
• 파라미터 튜닝
• 성능 관련 MySQL 파라미터를 마이그레이션 할 필요 없음
• 대부분의 경우에 맞춰 파라미터 그룹은 미리 튜닝되어 있음
• 성능 비교
• 개별 지표(CPU, IOPS, I/O 처리량)에 얽매이지 않는게 좋음
• 중요한 것, 즉 애플리케이션 성능에 집중!
• 기타
• 쿼리 캐시 활성화
• Amazon CloudWatch 지표를 활용

33. 가용성
“데이터베이스가 가동중이여야지만 성능이 의미가 있습니다”

34. 스토리지 내구성
• 스토리지 볼륨은 자동으로 최대 64TB
까지 증가
• 읽기/쓰기를 위한 쿼럼 시스템; 지연
내구성
• 갭을 채우기 위한 peer-to-peer-gossip
레플리케이션
• S3에 지속적으로 백업 (11개의 9 내구성)
• 노드와 디스크의 복구를 위해
지속적으로 모니터링
• 복구 또는 핫스팟 리밸런스를 위한 10GB
세그먼트 단위
• 쿼럼 멤버십 변경으로 쓰기 작업이
멈추지 않음
AZ 1 AZ 2 AZ 3
Amazon
S3

35. Aurora 레플리카
• Aurora 클러스터는 기본노드와
최대 15개의 레플리카를 가질 수
있음
• 실패한 데이터베이스 노드는
자동으로 감지되어 대체됨
• 실패한 데이터베이스 프로세스는
자동으로 감지되고 재활용 됨
• 여러 레플리카에 걸쳐 읽기
트래픽 처리를 확장할 수 있음
• 레플리카는 중단이 지속될 경우
자동으로 승격됨
AZ 1 AZ 3AZ 2
Primary
Node
Primary
Node
Primary
Node
Primary
Node
Primary
Node
Secondary
Node
Primary
Node
Primary
Node
Secondary
Node

36. 지속적 백업
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
• 주기적으로 각 세그먼트의 스냅샷을 병렬로 생성; redo 로그를 Amazon S3 로 스트리밍
• 성능이나 가용성에 영향을 미치지 않고 지속적으로 백업
• 복원 시 해당 세그먼트 스냅샷과 로그 스트림을 스토리지 노드로 가져옴
• 세그먼트 스냅샷에 로그 스트림을 병렬 및 비동기로 적용

37. 신속한 크래시 복구
전통적인 데이터베이스
• 마지막 체크포인트 이후의 로그를
리플레이해야 함
• 일반적으로 체크포인트 간격은
5분
• MySQL 에서는 싱글-쓰레드이며
많은 수의 디스크 접근이 필요
Amazon Aurora
• 기반 스토리지는 디스크 읽기의
일부로 필요할 때 redo 레코드를
리플레이
• 병렬, 분산, 비동기
• 시작시 리플레이 없음
Checkpointed data Redo log
T0 에서 충돌이 발생하면
마지막 체크포인트 이후 redo
로그내의 SQL 복제가 필요함
T0 T0
T0 에서 충돌 발생시 필요에 따라 각
세그먼트에 redo 로그가 병렬적으로,
비동기적으로 적용됨

38. 살아남는 캐시
• 데이터베이스 프로세스와 캐시의 분리
• 데이터베이스 재가동시에도 캐시는 웜(warm) 상태 유지
• 완전히 로드된 작업을 훨씬 빠르게 재게 가능
• 신속한 크래시 복구 + 캐시 유지 à 빠르고 손쉬운 DB
장애 복구
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
캐싱 프로세스가 DB 프로세스 외부에 있고
데이터베이스 재시작에도 웜(warm) 상태 유지

39. 빠른 장애 조치
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
MySQL
App
Running
Failure Detection DNS Propagation
Recovery
DB
Failure
Aurora (w/ MariaDB Driver)
1 5 - 2 0 s e c
3 - 2 0 s e c

40. 데이터베이스 장애 복구 시간
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0 - 5s – 30% of fail-overs
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
5 - 10s – 40% of fail-overs
0%
10%
20%
30%
40%
50%
60%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
10 - 20s – 25% of fail-overs
0%
5%
10%
15%
20%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
20 - 30s – 5% of fail-overs

41. 실제 사례: Failover 시간
“In RDS MySQL, it took minutes or sometimes tens of minutes to failover.
It’s pretty awesome that you can failover/restart within less than a minute.”

42. SQL을 사용하여 장애 시뮬레이션
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval
ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval
• 데이터베이스 노드에서의 구성요소의 장애:
• 디스크 장애:
• 네트워킹 장애:

43. 효율성 (운영)
자동화된 스토리지 관리, 보안 및 컴플라이언스,
향상된 모니터링, 데이터베이스 마이그레이션

44. 스토리지 관리 단순화
§ Amazon S3에 지속적으로 증분 백업
§ 성능 영향 없이 즉시 사용자 스냅샷 생성
§ 성능 영향 없이 최대 64TB 까지 자동으로 스토리지 확장
§ 자동 restriping, 미러 복구, 핫스팟 관리, 암호화
최대 64TB – 10GB 단위로 자동 확장
최대 64 TB

45. 보안과 컴플라이언스
R 고객 관리 키를 사용하여 데이터를
안전하게 저장하는 암호화
• AES-256; 하드웨어 가속
• Amazon S3와 디스크의 모든 블록이 암호화
• AWS KMS를 통한 키 관리
R 암호화된 리전간 복제, 스냅샷 복사
(데이터 전송 간 보호를 위한 SSL)
R 성능 영향 없이 향상된 감사 및 로깅
R 업계 표준 보안 및 데이터 보호 - SOC,
ISO, PCI/DSS, HIPPA/BAA
Data Key 1 Data Key 2 Data Key 3 Data Key 4
Customer Master
Key(s)
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Database
Engine

46. 향상된 모니터링
50개 이상의 시스템/OS 지표 | 정렬된 프로세스 목록 | 1–60 초단위
특정 지표에 알람 설정 | CloudWatch Logs에 적재 | 3rd 파티 도구들과 통합

47. 중요한 시스템 및 OS 지표
User
System
Wait
IRQ
Idle
Nice
Steal
CPU utilization
Rx per declared ethn
Tx per declared ethn
Network
Sleeping
Running
Total
Stopped
Blocked
Zombie
Processes
Process ID
Process name
VSS
Res
Mem %
consumed
CPU % used
CPU time
Parent ID
Process list
Free
Cached
Buffered
Total
Writeback
Inactive
Dirty
Mapped
Slab
Page tables
Huge pages free
Huge pages rsvd
Huge pages surp
Huge pages size
Huge pages total
Swap
Swap free
Swap committed
Memory
Read latency
Write latency
Read throughput
Write throughput
Read I/O/sec
Write I/O/sec
Queue depth
Read queue depth
Write queue depth
Free local storage
Device I/O
Used
Total
Used Inodes/%
Max Inodes/%
File system
1 min
5 min
15 min
Load average

48. 중요한 데이터베이스 지표
§ Aurora 및 CloudWatch
콘솔의 데이터베이스 수준
지표 보기
§ 소급 워크로드 분석 수행
Select throughput
Select latency
DML throughput
DML latency
Commit throughput
Commit latency
DDL throughput
DDL latency
DB connections
Active connections
Login failures
Buffer cache hit ratio
Resultset cache hit
ratio
Deadlocks
Blocked transactions
Failed SQL statements
Replica lag
Replica lag maximum
Replica lag minimum
Free local storage

49. MySQL 및 AWS 에코시스템 활용
Query and
Monitoring
Business
Intelligence
Source: Amazon
Data Integration
“We ran our compatibility test suites against Amazon Aurora and
everything just worked." - Dan Jewett, Vice President of Product Management
at Tableau
Lambda IAM
CloudWatch
S3
Route53
KMS
AWS 에코시스템
VPC SWF

50. 비용
비용을 줄여 줍니다.
상용 데이터베이스의 1/10 비용. MySQL 보다도 저렴합니다.

51. 소유 비용: Aurora vs MySQL
Primary
r3.4XL
Standby
r3.4XL
Replica
r3.4XL
Replica
R3.4XL
Storage
1 TB / 10 K PIOP
Storage
1 TB / 10 K PIOP
Storage
1 TB / 4 K PIOP
Storage
1 TB / 4 K PIOP
$2.27/hr
$2.27/hr
$2.27/hr $2.27/hr
$1.2/hr
$0.60/hr $0.60/hr
인스턴스 비용: $9.08 / 시간
스토리지 비용: $3.60 / 시간
총 비용: $12.68 / 시간
$1.2/hr
2017.09.06 Seoul 리전 기준

52. 소유 비용: Aurora vs MySQL
인스턴스 비용: $8.40 / hr
스토리지 비용: $0.50 / hr
총 비용: $8.90 / hr
Primary
r3.4XL
Replica
r3.4XL
Replica
R3.4XL
Storage / 1 TB
$2.80 / hr $2.80 / hr $2.80 / hr
$0.5 / hr
* 전체적으로 Aurora는 RDS MySQL에 비해
스토리지 비용을 50% 이상 절약
29.8%
Savings
§ 유휴 대기 인스턴스 없음
§ 단일 공유 스토리지 볼륨
§ PIOPS 없음 – I/O 사용량 만큼 지불
§ 전반적인 I/O 감소
2017.09.06 Seoul 리전 기준

53. 소유 비용: Aurora vs MySQL (추가 전략)
인스턴스 비용: $4.20 / hr
스토리지 비용: $0.50 / hr
총 비용: $4.70 / hr
62.9%
Savings
Primary
r3.4XL
Replica
r3.4XL
Replica
r3.4XL
Storage / 1TB
$1.40 / hr $1.40 / hr $1.40 / hr
$0.5 / hr
r3.2XL r3.2XL r3.2XL
§ 더 작은 인스턴스 크기 사용
§ 사용한만큼 지불하는 스토리지

54. 높은 성능과 낮은 비용
§ 더 적은 인스턴스로 충분
§ 작은 인스턴스를 활용 가능
Safe.com 은 샤딩된 MySQL에서 단일 Aurora 인스턴스로
전환한 뒤 기존 비용의 40%를 절감하였습니다.
Double Down Interactive (게이밍) 비용의 67%를 절감하였을
뿐만 아니라 지연은 더 나아졌으며 (대부분의 쿼리가 더 빠르게
동작) CPU 사용률 또한 낮추었습니다.
§ 스토리지를 사전에 준비할 필요 없음
§ 읽기 레플리카를 위한 추가 스토리지 필요
없음

55. 개발 및 테스트 용도
• t2.small/t2.medium 을 활용하세요!
t2 RI 할인
1년 RI 시 최대 27%
3년 RI 시 최대 53%
vCPU Mem Hourly Price
db.t2.small
db.t2.medium
1
2
1
4
$0.063
$0.125
db.r3.large 2 15.25 $0.35
db.r3.xlarge 4 30.5 $0.70
db.r3.2xlarge 8 61 $1.40
db.r3.4xlarge 16 122 $2.80
db.r3.8xlarge 32 244 $5.60
2017.09.06 Seoul 리전 기준

56. Amazon Aurora with PostgreSQL

57. 2014년, MySQL 호환성을 갖춘 Amazon Aurora를 출시했습니다.
이제 우리는 PostgreSQL 호환성을 추가합니다.
상용 데이터베이스의 성능과 가용성, 그리고 오픈 소스
데이터베이스의 단순성과 비용 효율성과 함께 Amazon의 클라우드
최적화 관계형데이터베이스를 사용 방법을 선택할 수 있습니다
Amazon Aurora의 발전

58. PostgreSQL
• 20년 동안 활발히 개발중인 오픈소스 데이터베이스
• 단일 회사가 아닌 재단이 소유
• 관대한 혁신 친화적 오픈 소스 라이센스
• 높은 성능
• 객체지향 및 ANSI-SQL 2008 호환
• 12개의 언어로 작성할 수 있는 저장 프로시저 지원
(Java, Perl, Python, Ruby, TCL, C/C++, PL/pgSQL, 등)
• 오라클과 가장 높은 호환성을 가진 오픈소스
데이터베이스
Open Source Initiative

59. PostgreSQL 호환성의 의미
PostgreSQL 9.6 + Amazon Aurora 클라우드 최적화 스토리지
• 성능: 단일 PostgreSQL 보다 2~3배 높은 처리량
• 가용성: 30초 미만의 장애조치 시간
• 내구성: 3개의 가용영역에 걸쳐 6개의 사본
• 읽기 레플리카: 최대 15개의 레플리카에서 한 자리 밀리초 지연시간
Amazon Aurora 스토리지

60. PostgreSQL 호환성의 의미
• 클라우드 고유의 보안 및 암호화
• 손 쉬운 관리 및 운영
• 쉬운 마이그레이션
• 가까운 장래에 PostgreSQL과 완벽하게 호환
AWS DMS
Amazon RDS
PostgreSQL

61. 숫자로 보는 성능
측정 결과
PgBench 2배 이상 빠른
SysBench 2~3배 빠른
데이터 로딩 3배 빠른
응답시간 2배 이상 빠른
처리량 지터 3배 이상 더 일관적
확장시 처리량 3배 빠른
복구 속도 최대 85배 빠른

62. Amazon Relational Database Service (RDS)

63. https://aws.amazon.com/blogs/database/category/aurora/

64. 질문에 대한 답변 드립니다.
발표자료/녹화영상 제공합니다.
http://bit.ly/awskr-webinar
더 나은 세미나를 위해
여러분의 의견을 남겨 주세요!