Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인

© 2020, Amazon Web Services, Inc. or its Affiliates.© 2020, Amazon Web Services, Inc. or its Affiliates.
AWS Databases Modernization Day
테크니컬 어카운트 매니저
Aurora MySQL
Backtrack을 이용한 빠른 복구
진교선

© 2020, Amazon Web Services, Inc. or its Affiliates.
강연 중 질문하는 방법
Go to Webinar “Chat/채팅” 창에 자신이 질문한
내역이 표시됩니다. 기본적으로 모든 질문은
공개로 답변 됩니다만 본인만 답변을 받고 싶으면
(비공개)라고 하고 질문해 주시면 됩니다.
본 컨텐츠는 고객의 편의를 위해 AWS 서비스 설명을 위해 온라인 세미나용으로 별도로 제작, 제공된 것입니다. 만약 AWS
사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우, AWS 사이트(aws.amazon.com)가 우선합니다. 또한 AWS 사이트
상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
AWS는 본 컨텐츠에 포함되거나 컨텐츠를 통하여 고객에게 제공된 일체의 정보, 콘텐츠, 자료, 제품(소프트웨어 포함) 또는 서비스를 이용함으로 인하여 발생하는 여하한 종류의 손해에
대하여 어떠한 책임도 지지 아니하며, 이는 직접 손해, 간접 손해, 부수적 손해, 징벌적 손해 및 결과적 손해를 포함하되 이에 한정되지 아니합니다.
고지 사항(Disclaimer)

Database on AWS

수 년간 발전해 온 어플리케이션의 구조…

현 시대 어플리케이션들의 요구사항!
더 나은 성능, 확장성, 그리고 가용성을 요구
Users 1M+
Data volume Terabytes—petabytes
Locality Global
Performance Microsecond latency
Request rate Millions per second
Access Mobile, IoT, devices
Scale Virtually unlimited
Economics Pay-as-you-go
Developer access Instance API access
Development Apps & storage are decoupled
Online
gaming
Social
media
Media
streaming
E-Commerce Shared economy

여러 요구 사항에 대응하는 다양한 관리형 데이터베이스
Relational
Referential
integrity, ACID
transactions,
schema-
on-write
Key-value
High
throughput,
Low latency
reads and writes,
endless scale
Document
Store documents
and quickly
access querying
on any attribute
In-memory
Query by key
with
microsecond
latency
Graph Time-series
Collect, store,
and process
data sequenced
by time
Ledger
Scalable, highly
available, and
managed Apache
Cassandra-
compatible service
Quickly and easily
create and
navigate
relationships
between data
Wide Column
Complete,
immutable, and
verifiable history
of all changes to
application data
Lift and shift,
ERP, CRM,
finance
Real-time
bidding,
shopping cart,
social, product
catalog,
customer
preferences
Content
management,
personalization,
mobile
Leaderboards,
real-time
analytics,
caching
Fraud detection,
social
networking,
recommendation
engine
IoT
applications,
event tracking
Systems
of record,
supply chain,
health care,
registrations,
financial
AWS
Service(s)
Common
Use Cases
Build low-latency
applications,
leverage open
source, migrate
Cassandra to the
cloud

Amazon Aurora: 오픈소스와 호환되는, 상용 수준
데이터베이스
MySQL과 PostgreSQL 에 호환되는 클라우드 기반의 RDBMS로, 상용 데이터 베이스 대비 1/10
비용으로 비용 절감과 성능에 최적화
Performance
& scalability
5x throughput of standard
MySQL and 3x of standard
PostgreSQL; scale-out up
to15 read replicas
Availability
& durability
Fault-tolerant, self-healing
storage; six copies of
data across three AZs;
continuous backup to S3
Highly
secure
Network isolation,
encryption at
rest/transit
Fully
managed
Managed by RDS: no
server provisioning,
software patching, setup,
configuration, or backups

확장 가능한 분산 스토리지
데이터 베이스의 목적별 저장을 위한
스토리지 구조
3개 AZ에 걸친 6개의 데이터 카피로 AZ
Failure에 대비
10GB 단위의 스토리지 노드 그룹이
사용자의 사용량에 따라 자동으로 확장
Storagenodes
Shared storage volume
SQL
Transactions
Caching
Availability Zone 1
SQL
Transactions
Caching
Availability Zone 2
SQL
Transactions
Caching
Availability Zone 3
Instancenodes

Aurora의 I/O 구조
BINLOG DATA DOUBLE-WRITELOG FRM FILES
MYSQL WITH REPLICA
Amazon EBS
mirror
Amazon EBS
mirror
AZ 1 AZ 2
Amazon EBSAmazon EBS
Primary
Instance
Replica
Instance
1
2
3
4
5
AZ 1 AZ 3
Primary
Instance
AZ 2
Replica
Instance
ASYNC
4/6 QUORUM
DISTRIBUTED
WRITES
Replica
Instance
AMAZON AURORA
78만 트랜잭션
평균 1 트랜잭션 당 7.4 I/O
MySQL I/O profile for 30 min Sysbench run
2,737만 트랜잭션 35X MORE
평균 1 트랜잭션 당 0.95 I/O 7.7X LESS
Aurora I/O profile for 30 min Sysbench run

HA/DR with Aurora

Failure에 강력한 아키텍쳐
모든 Reader node는 Writer
node로 전환 될 수 있습니다.
Failover tier 로 우선 적으로
Failover될 node의 순위를 정할 수
있습니다.
Failure를 겪은 node는 복구 후
Reader로 자동적으로 추가 됩니다.
Writer Failover시에 모든
Reader가 재시작 됩니다..
AZ 1 AZ 2 AZ 3
SHARED CLUSTER STORAGE VOLUME
Writer
Transactions
Caching
SQL
Writer
Transactions
Caching
SQL
Reader
Transactions
Caching
SQL
Cluster
Endpoint
00 5
Reader
Endpoint

Near-instant crash recovery
Traditional database
• 마지막 Checkpoint 기준의 Redo log 보존
• 통상 적으로 5 minutes 간격의 Checkpoint
• MySQL의 Single Thread 복구 특성 상 많은 Disk
I/O를 필요로 함
Amazon Aurora
• 스토리지 레벨에서 redo record를 읽어 복구
진행
• 병렬, 분산, 비동기식 처리
• 인스턴스 재시작 시 replay 불필요
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
Note: Binlogs (master), undo logs와 같은 MySQL Engine 레벨의 구성 요소는 Engine 레벨의 리커버리가 필요합니다.
More: http://blog.symedia.pl/2016/03/crash-recovery-mysql-aurora.html

When the database fails – recovery is fast <30 seconds
0,00%
5,00%
10,00%
15,00%
20,00%
25,00%
30,00%
35,00%
1 2 3 4 5 6 7 8 9 1011121314151617181920212223242526272829303132333435
0 - 5s – 30% of fail-overs
0,00%
5,00%
10,00%
15,00%
20,00%
25,00%
30,00%
35,00%
40,00%
45,00%
50,00%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
0%
10%
20%
30%
40%
50%
60%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
20%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Continuous backup with point-in-time restore
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
• 스토리지 노드에서 실행되는 백업은 성능과 가용성에 영향을 받지 않고 수행됩니다.
• 주기적인 스냅샷은 여러 세그먼트에서 병렬적으로 수행되어 S3에 저장됩니다.
• 로그는 S3로 지속적으로 전송되어 복구에 활용됩니다.

Aurora backup and restore
Automated backups:
• 1일과 35일 사이의 유지 기간을 설정
• 최소 5분 전 시점의 데이터로 복구 가능
Snapshots:
• 유저로 부터 생성된 스냅샷
• 성능에 영항 없음
• 다른 지역이나 다른 계정으로 스냅샷 복사
공유 가능
Restore:
• 클러스터의 스토리지 사용량에 따라 복구
시간 영향
• 새로운 클러스터를 생성하여 데이터 복구
VOLUME
Writer
Transactions
Caching
SQL
Reader
Transactions
Caching
SQL
Amazon S3
RDS Service Managed
t
0
1 2 6
t
0
5 6
t
2
3
Automated backup
VOLUME
Writer
Transactions
Caching
SQL
Restore to t4
Source Cluster Restored Cluster
Data changes over time
t0 t1 t2 t3 t4 t5 t6

Aurora Backtrack
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible
Aurora Backtrack 은 Database의 시점복구 기능을 backup과 restore 를 거치지 않고 복구하는 기능입니다.
예상치 못한 DML과 DDL로 인한 데이터 유실이나 변조 시 복구에 사용
Backtrack을 여러 번 수행하여 적절한 시점을 찾는 사용 사례
QA에서 테스트 수행 후 테스트 전으로 데이터를 돌려 다시 테스트를 수행하는데 사용하는 사례

HA&DR: from one region to multiple regions…
논리적으로는 Binlog Replication
최대 5개의 Readable Replica 셋 생성
RDS 서비스에 의해 관리됨
물리적 redo log 복제
최대 16개의 Reader Instance
스토리지 계층의 복제로 성능 영향 없음
Cross-region read
replicas
Aurora Global
Database

Aurora Global Database
높은 스루풋:
낮은 복제 지연 :
빠른 복구 :
Oregon
M R R
Storage
R R
Storage
Ohio
R R
Storage
R R
Storage
Northern Virginia
Ireland
(secondary region)
(secondary region)
(secondary region)
(primary region)
Inboundreplication
InboundreplicationInboundreplication
Outbound replication
더 빠른 데이터 복구를 위한 솔루션

Performance: logical vs. physical replication
Logical replication
MySQL Binary logs (MTS)
Physical replication
Global Database
0
100
200
300
400
500
600
0
50 000
100 000
150 000
200 000
250 000
seconds
QPS
QPS
Lag
0,00
0,50
1,00
1,50
2,00
2,50
3,00
3,50
4,00
4,50
5,00
0
50 000
100 000
150 000
200 000
250 000
seconds
QPS
QPS
Lag
SysBench OLTP (write-only) stepped every 600 seconds on R4.16xlarge

HA: 다운타임 최소화
일관성이 유지되는 다중 쓰기 인스턴스
단일 Writer 실패 시 쓰기 워크로드 담당
RDS Proxy
Failover optimization and testing
Aurora Multi-Master
Efficient Connection
Management

Continuous availability with Aurora Multi-Master
스토리지를 공유하는 여러 쓰기 인스턴스
3개 AZ에 걸친 6개의 복제본
가용성 향상
고 내구성
indexes, constraints, triggers, procedures,
functions 등 MySQL 호환성
SQL 호환성
Storage Node 주도의 일관성 관리쓰기 분산

Introduction to Aurora Multi-Master
• 여러 Node가 쓰기 워크로드 수행
• 역시 분산 스토리지 볼륨을 공유
• 각 Node의 복구는 각자 진행 됨
• 추가비용 없음
Writer
#1
Writer
#2
Application1 Application 2
Shared distributed storage
volume

Using Aurora Multi-Master with your applications
• 최초 Application에 쓰기
인스턴스 할당
• 어플리케이션에서 쓰기
Node의 Health 상태 점검
• 인스턴스 실패 시 다른 쓰기
Node로 커넥션 재 생성

Multi-Master: example of transactions with no conflict
 트랜잭선 T1 과 T2 가 각기 다른
테이블을 Table 1 과 Table 2 를
업데이트
 논리적 물리적 충돌이 없기
때문에 문제 없이 수행
1 1 1 1 11 2 2 2 2 22
PAGE 1 PAGE 2
MASTER 1 MASTER 2
TABLE 1 TABLE 2

Multi-Master: example of physical conflict (storage
arbitration)
 트랜잭션 T1 과 T2 가 같은 테이블
Table 1 을 수정
 같은 Page의 데이터 끼리 충돌 발생
가능
 트랜잭선 T1 은 4/6 쿼럼을 충족
 트랜잭선 T2 는 쿼럼을 충족 하지
못하여 쓰기 실패하고 롤백 및
어플리케이션에 에러 전달
 스토리지 노드가 충돌 감시자 역할을
수행
1 1 1 2 21
PAGE 1 PAGE 2
MASTER 1 MASTER 2
TABLE 1 TABLE 2

Connection management to minimize disruptions
• 1개 Node당 16,000 개 커넥션 생성 가능(readers
or writers)
• 읽기 쓰기 분산 필요
• 커넥션 풀링을 사용하여 안정적인 커넥션 관리
• DNS TTL을 적절히 설정
• 장시간 수행 및 대기 쿼리를 제거
RDS Proxy is currently in Preview. More: https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-connection-management-handbook.pdf

Improving HA with RDS Proxy
Amazon RDS 를 위한 완전 관리형, 고가용성 Proxy 기능
Pool and share DB
connections for
improved app scaling
Consistent endpoint,
holds connections open
and queue up requests,
minimizes failover time
Delivered as a managed
service compatible with
RDS databases
Encryption in transit and
improved DB access controls
Connection
Pooling
Minimize Failover
Disruptions
Fully Managed
and Scalable
Improved Security

Connection Pooling with RDS Proxy
• 어플리케이션과 데이터베이스 레벨의 커넥션을 분리하여, 어플리케이션 스케일시에도
데이터베이스에 과도한 커넥션이 발생하지 않도록 방지
• 커넥션 당 트랜잭션을 다중화 하여, 커넥션 재사용으로 인한 성능 향상
• 커넥션들에 공통된 설정값들을 유지하여, 일관된 성능 유지
App
DB Cluster
RDSProxy
App
App

Minimize Failover Disruption with RDS Proxy
• 어플리케이션 레벨의 커넥션 풀은 유지하여, 더 빠르게 커넥션 복구
• Active Connection을 먼저 끊어 클라이언트 레벨에서 불완전 처리에 대한 에러 리턴
• 새로운 요청은 Proxy레벨에서 보관되어 추후 수행
Client
RDSProxy
Client
Client

Aurora Backtrack Demo

Summary
• 다양한 요구사항 다양한 데이터베이스!
• 강력한 HA/DR을 제공하는 오로라
• 스토리지 레벨의 빠른 병렬 복구
• Backtrack 기능을 활용한 데이터베이스 간편 복구
• 스토리지 레벨의 복제로 더욱 빠른 다지역 복제 기능 제공
• RDS Proxy를 활용한 더욱 편한 연결 관리

AWS Database Modernization Day에
참석해주셔서 대단히 감사합니다.
aws-korea-marketing@amazon.com
twitter.com/AWSKorea
facebook.com/amazonwebservices.ko
youtube.com/user/AWSKorea
slideshare.net/awskorea
twitch.tv/aws
저희가 준비한 내용, 어떻게 보셨나요?
더 나은 세미나를 위하여 설문을 꼭 작성해 주시기 바랍니다.

Thank you!

Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인

Related slideshows

More Related Content

Aurora MySQL Backtrack을 이용한 빠른 복구 방법 - 진교선 :: AWS Database Modernization Day 온라인