관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016

2. 목 차 • Amazon Aurora 개요 • 고객 사례 – 리멤버 • Amazon Aurora의 빠른 성능 • Amazon Aurora의 고가용성 • Amazon Aurora 시작하기 및 마이그레이션

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

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 역사 상 가장 빠르게 성장 중인 서비스 비지니스 어플리케이션 웹 및 모바일 컨텐츠 관리 전자 상거래 사물 인터넷 검색 및 광고 비지니스 인텔리전스, 분석 게임, 미디어 다양한 적용 분야

10. REMEMBER ON AURORA 이영래(DBA) DRAMA & COMPANY

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

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

13. 2015.12.11 Amazon AuroraRDS MySQL 5.6 리멤버 소개

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)

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

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 드라마앤컴퍼니 개발그룹 블로그를 소개합니다!

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

36. Amazon Aurora의 빠른 성능

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

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

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

52. Amazon Aurora의 고가용성

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

58. Amazon Aurora의 인스턴스 자동 페일-오버 페일-오버 1분 미만

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

63. Amazon Aurora를 통한 비용절감

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

68. Amazon Aurora 시작하기 및 마이그레이션

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

73. 여러분의 피드백을 기다립니다! https://www.awssummit.co.kr 모바일 페이지에 접속하셔서, 지금 세션 평가에 참여하시면, 행사 후 기념품을 드립니다. #AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 곧 공유될 예정입니다.

74. 감사합니다

76. 목 차 • Amazon Aurora 개요 • 고객 사례 – 센드버드 • Amazon Aurora의 빠른 성능 • Amazon Aurora의 고가용성 • Amazon Aurora 시작하기 및 마이그레이션

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

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

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

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)

99. Amazon Aurora의 빠른 성능

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

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

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

115. Amazon Aurora의 고가용성

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

121. Amazon Aurora의 인스턴스 자동 페일-오버 페일-오버 1분 미만

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

126. Amazon Aurora를 통한 비용절감

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

131. Amazon Aurora 시작하기 및 마이그레이션

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

136. 여러분의 피드백을 기다립니다! https://www.awssummit.co.kr 모바일 페이지에 접속하셔서, 지금 세션 평가에 참여하시면, 행사 후 기념품을 드립니다. #AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 곧 공유될 예정입니다.

137. 감사합니다

관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016

Similar to 관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016