AWS CLOUD 2017 - Amazon Aurora를 통한 고성능 데이터베이스 운용하기 (박선용 솔루션즈 아키텍트)

862 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
862
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
120
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

AWS CLOUD 2017 - Amazon Aurora를 통한 고성능 데이터베이스 운용하기 (박선용 솔루션즈 아키텍트)

  1. 1. 1 Amazon Aurora를 통한 고성능 데이터베이스 운용하기
  2. 2. Agenda § Aurora 란? § 기존 Aurora의 성능을 위한 기능 § 새로운 성능 향상 § Aurora for PostgreSQL § 성능 Best Practices
  3. 3. Open source compatible relational database Performance and availability of commercial databases Simplicity and cost-effectiveness of open source databases Amazon Aurora 란?
  4. 4. 4 기존 Aurora의 성능을 위한 기능
  5. 5. WRITE PERFORMANCE READ PERFORMANCE 인스턴스 사이즈를 통한 성능 Aurora는 인스턴스 사이즈가 커짐에 따라 read 와 write 모두 성능 확장 Aurora MySQL 5.6 MySQL 5.7
  6. 6. 실제 데이터 – 게임 워크로드 Aurora vs. RDS MySQL – r3.4XL, MAZ Aurora 3X faster on r3.4xlarge
  7. 7. “Our first tests of Aurora were difficult to believe because the performance increase was substantial… Aurora made our migration from traditional colocation to AWS easier because the storage was fully managed and replication was extremely fast.” - Mark Smallcombe, CTO “…if you're using Aurora, you should think about using read replicas because the replica lag is really a game changer compared to regular MySQL.” - Advait Shinde, CTO and co-founder “Amazon Aurora was able to satisfy all of our scale requirements with no degradation in performance. With Alfresco on Amazon Aurora we scaled to 1 billion documents with a throughput of 3 million per hour, which is 10 times faster than our MySQL environment!" - John Newton, Founder and CTO of Alfresco” "After 8 months of production, Aurora has been nothing short of impressive… We love that so far Aurora has delivered the necessary performance without any of the operational overhead of running MySQL.” – Chris Broglie, Architect
  8. 8. Amazon Aurora – 낮은 가격에 더 높은 성능 • 더 적은 갯수의 인스턴스 • 더 작은 인스턴스로도 가능 • 프로비전 스토리지 필요 없음 • 읽기 복제를 위한 추가 스토리지 필요없음 Safe.com lowered their AWS database bill by 40% by switching from sharded MySQL to a single Amazon Aurora instance. Double Down Interactive (gaming) lowered their bill by 67% while also achieving better latencies (most queries ran faster) and lower CPU utilization.
  9. 9. 더 적은 I/Os 네트워크 패킷 최소화 캐시 우선 결과 데이터베이스 엔진 부담 경감 더 작아지도록 동작 비동기적인 프로세스 지연 패스 경감 락 프리 데이터 스트럭쳐 사용 배치 조작을 병행 보다 효율적으로 동작 Aurora의 성능향상 배경 데이터베이스는 대부분이 I/O 네크워크 부착 스토리즈는 대부분이 PACKETS/SECOND 고 성능 출력 프로세싱은 대부분이 CONTEXT SWITCHES
  10. 10. MySQL I/O 트래픽 BINLOG DATA DOUBLE-WRITELOG FRM FILES T Y P E O F W R I T E MYSQL WITH REPLICA EBS mirrorEBS mirror AZ 1 AZ 2 Amazon S3 EBS Amazon Elastic Block Store (EBS) Primary Instance Replica Instance 1 2 3 4 5 Issue write to EBS – EBS issues to mirror, ack when both done Stage write to standby instance through DRBD Issue write to EBS on standby instance I/O FLOW Steps 1, 3, 4 are sequential and synchronous This amplifies both latency and jitter Many types of writes for each user operation Have to write data blocks twice to avoid torn writes OBSERVATIONS 780K transactions 7,388K I/Os per million txns (excludes mirroring, standby) Average 7.4 I/Os per transaction PERFORMANCE 30 minute SysBench writeonly workload, 100GB dataset, RDS MultiAZ, 30K PIOPS
  11. 11. 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 I/O FLOW Only write redo log records; all steps asynchronous No data block writes (checkpoint, cache replacement) 6X more log writes, but 9X less network traffic Tolerant of network and storage outlier latency OBSERVATIONS 27,378K transactions 35X MORE 950K I/Os per 1M txns (6X amplification) 7.7X LESS PERFORMANCE Boxcar redo log records – fully ordered by LSN Shuffle to appropriate segments – partially ordered Boxcar to storage nodes and issue writesReplica Instance
  12. 12. 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 and 2 가 앞단의 지연 과정 Input queue is 46X less than MySQL (unamplified, per node) Favor latency-sensitive operations Use disk space to buffer against spikes in activity OBSERVATIONS I/O FLOW ① 레코드를 받아서 인 메모리 큐로 추가 ② 레코드를 유지하고 acknowledge ③ 레코드를 구성하고 로그와의 갭을 확인 ④ Gossip with peers to fill in holes ⑤ Coalesce log records into new data block versions ⑥ Periodically stage log and new block versions to S3 ⑦ 주기적으로 오래된 버전에 대한 가비지 컬랙트 ⑧ 주기적으로 블락에 대한 CRC 코드 validate
  13. 13. Aurora 복제에서 I/O 트래픽 페이지 캐시 업데이트 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 싱글 쓰레드 빈로그 적용 Data Volume Data Volume • Logical: SQL 명령을 Replica로 전송 • 쓰기 워크로드는 양쪽 모두 비슷함 • 독립적인 스토리지 • 마스터와 복제사이에서 데이터 표류가 발생 가능 Physical: 마스터로부터 복제로 Redo를 전달 복제는 스토리지를 공유. 별도의 쓰기 실행하지 않음 캐시 페이지에는 리두 적용 모든 쓰기 커밋이 진행 전 리드 뷰가 선행해서 보임 MYSQL 읽기 확장 AMAZON AURORA 읽기 확장
  14. 14. “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.” 실 데이터 – 읽기 복제 지연
  15. 15. 비동기 그룹 커밋 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 Maintain a buffer of log records to write out to disk Issue write when buffer full or time out waiting for writes First writer has latency penalty when write rate is low Request I/O with first write, fill buffer till write picked up Individual write durable when 4 of 6 storage nodes ACK Advance DB Durable point up to earliest pending ACK
  16. 16. • 재 진입 커넥션이 활성 쓰레드와 다중연동(multiplexed) • Kernel-space epoll() inserts into latch-free event queue • Dynamically size threads pool • Gracefully handles 5000+ concurrent client sessions on r3. 8xl 표준 MySQL – 연결당 하나의 쓰레드 Doesn’t scale with connection count MySQL EE – connections assigned to thread group Requires careful stall threshold tuning CLIENTCONNECTION CLIENTCONNECTION LATCH FREE TASK QUEUE epoll() MYSQL THREAD MODEL AURORA THREAD MODEL 적응성 쓰레드 풀
  17. 17. Scan Delete Aurora 락 관리 Scan Delete Insert Scan Scan Insert Delete Scan Insert Insert MySQL lock manager Aurora lock manager § Same locking semantics as MySQL § Concurrent access to lock chains § Multiple scanners allowed in an individual lock chains § Lock-free deadlock detection 많은 동시 세션들 지원을 위해 필요, 높은 업데이트 출력량
  18. 18. 18 새로운 성능 향상
  19. 19. Cached 읽기 성능 개선 • 카탈로그 동시성(Catalog concurrency): 데 이터 딕셔너리 동기화와 캐시 퇴거(eviction) 을 개선 • NUMA 인식 스케줄러: Aurora scheduler는 이제 NUMA를 고려함. 멀티 소켓 인스턴스의 확장성에 도움. • 리드 뷰(Read views): 리드 뷰 생성시 래치- 프리(latch-free) 동시성 읽기 뷰 알고리즘을 이용함 0 100 200 300 400 500 600 700 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 In thousands of read requests/sec * R3.8xlarge instance, <1GB dataset using Sysbench 25% 출력량 증가
  20. 20. • 스마트 스케줄러(Smart scheduler): Aurora 스케줄러가 쓰레드를 처리할 일이 I/O heavy 인가 CPU heavy 인가에 따라 동적 할당 • 스마트 선택자(Smart selector): Aurora는 카 피된 스토리지 노드중 가장 성능이 좋은 것 을 자동 선택함으로써 읽기 지연을 감소시킴 • 논리적 선행읽기(LRA; Logical read ahead): B트리 안에서 페이지를 순서대로 메모리에 선패치 함으로써 읽기 I/O를 줄임 비 캐시 읽기 성능 개선 0 20 40 60 80 100 120 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 In thousands of requests/sec * R3.8xlarge instance, 1TB dataset using Sysbench 10% 출력량 증가
  21. 21. Scan Delete 행 핫 경합(Hot row contention) Scan Delete Insert Scan Scan Insert Delete Scan Insert Insert MySQL lock manager Aurora lock manager • 높은 경쟁 워크로드는 메모리, CPU사용이 많음 § 1.9 (11월) – 락 압축 (핫 락을 위한 비트맵) § 1.9 – 스핀락을 블락킹 futex로 대체 – 최대 12x 의 CPU사용률 감소, 3x의 처리량 증가 § 12월– 락 릴리즈에 동적 프로그래밍 사용: from O(totalLocks * waitLocks) to O(totalLocks) Throughput on Percona TPC-C 100 improved 29x (from 1,452 txns/min to 42,181 txns/min)
  22. 22. 행 핫 경합(Hot row contention) MySQL 5.6 MySQL 5.7 Aurora Improvement 500 connections 6,093 25,289 73,955 2.92x 5000 connections 1,671 2,592 42,181 16.3x Percona TPC-C – 10GB * Numbers are in tpmC, measured using release 1.10 on an R3.8xlarge, MySQL numbers using RDS and EBS with 30K PIOPS MySQL 5.6 MySQL 5.7 Aurora Improvement 500 connections 3,231 11,868 70,663 5.95x 5000 connections 5,575 13,005 30,221 2.32x Percona TPC-C – 100GB
  23. 23. § 프라이머리 키 정렬로 배치 인서트 가속 – 인덱스 경유에서 커서 포지션을 캐싱함으 로써 동작 § 데이터 패턴에 따라 동적으로 스스로 기능 을 끄거나 켬 § 트리를 따라 내려가는 동안 래치를 획득하 기 위한 경합을 피함 § 양 방향적, 모든 인서트 구문에서 작동 – LOAD INFILE, INSERT INTO SELECT, INSERT INTO REPLACE and, Multi-value inserts. 배치 삽입 성능 향상 Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root MySQL: B-tree 루트로부터 시작 인서트 최종까지 경유 Aurora: 인덱스 경유를 피함
  24. 24. 더 빠른 인덱스 빌드 § MySQL 5.6은 Linux의 선행읽기(read ahead) 적용 – 이 방식은 결국 b트리에서 블락 주소를 요구. 탑다운 방식의 새로운 트리 삽입은 결국 분할과 과도한 로깅이 발생. § Aurora는 트리 안의 위치에 기반한 선 패치된 블락을 스캔하며, 이는 블락 주소를 만들지 않음 § Aurora builds the leaf blocks and then the branches of the tree. • No splits during the build. • Each page touched only once. • One log record per page. 2-4X better than MySQL 5.6 or MySQL 5.7 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
  25. 25. 공간 인덱스의 필요성 • Need to store and reason about spatial data • E.g., “Find all people within 1 mile of a hospital” • Spatial data is multi-dimensional • B-Tree indexes are one-dimensional • Aurora supports spatial data types (point/poly gon) • GEOMETRY data types inherited from MySQL 5.6 • This spatial data cannot be indexed • Two possible approaches: • Specialized access method for spatial data (e.g., R-Tree) • Map spatial objects to one-dimensional space & store in B-Tree - space-filling curve using a grid approximation A B A A A A A A A B B B B B A COVERS B COVEREDBY A A CONTAINS B INSIDE A A TOUCH B TOUCH A A OVERLAPBDYINTERSECT B OVERLAPBDYINTERSECT A A OVERLAPBDYDISJOINT B OVERLAPBDYDISJOINT A A EQUAL B EQUAL A A DISJOINT B DISJOINT A A COVERS B ON A
  26. 26. Aurora에서 공간 인덱스 Z-index used in Aurora R-Trees의 과제 잘 균형잡혔을 때 효율적 사각형이 중첩되거나 빈 공간을 덮으면 안됨 시간이 지남에 따라 악화 리 인덱싱 비용이 높음 R-Tree used in MySQL 5.7 Z-index (dimensionally ordered space filling curve) 저장, 인덱싱에서 기본적인 B-Tree 사용 Removes sensitivity to resolution parameter Adapts to granularity of actual data without user declaration Eg GeoWave (National Geospatial-Intelligence Agency)
  27. 27. 공간 인덱스 벤치 마크 Sysbench – points and polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . * r3.8xlarge using Sysbench on <1GB dataset * Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS 0 20000 40000 60000 80000 100000 120000 140000 Select-only (reads/sec) Write-only (writes/sec) Aurora MySQL 5.7
  28. 28. 28 Aurora for PostgreSQL
  29. 29. § 오픈 소스 데이터베이스 § 20 년간 활발히 개발 중 § 회사가 아니라 재단에 의해 소유됨 § 혁신 친화적인 오픈소스 라이센스 § 발군의 높은 성능 § 객체 지향과 ANSI-SQL:2008 호환 § 오픈 소스중에서 가장 뛰어난 공간정보 기능 보유 § 12언어로(Java, Perl, Python, Ruby, Tcl, C/C++, Oracle 유사의 PL/pgSQL, etc.) 스토어드 프로지서 지원 § 가장 Oracle 호환성이 높은 open-source database § AWS Schema Conversion Tool을 사용해서 Oracle 로 부터 PostgreSQL 전환에 있어서 가장 높은 자동 전환률 PostgreSQL 개괄 Open Source Initiative
  30. 30. Amazon Aurora로 고객 마이그레이션 시나리오 Amazon EC2 혹은 on-premises 로 부터 Amazon RDS for PostgreSQL 로 부터 Oracle and SQL Server 로 부터 새롭게 생성
  31. 31. PostgreSQL 벤치 마크 시스템 구성 Amazon Aurora AZ 1 EBS EBS EBS 45,000 total IOPS AZ 1 AZ 2 AZ 3 Amazon S3 m4.16xlarge database instance Storage Node Storage Node Storage Node Storage Node Storage Node Storage Node c4.8xlarge client driver m4.16xlarge database instance c4.8xlarge client driver ext4 filesystem m4.16xlarge (64 VCPU, 256GiB), c4.8xlarge (36 VCPU, 60GiB)
  32. 32. Amazon Aurora >=2x 더 빠름 (PgBench) pgbench “tpcb-like” workload, scale 2000 (30GiB). All configurations run for 60 minutes
  33. 33. Amazon Aurora 2x-3x 더 빠름 (SysBench) • Amazon Aurora delivers 2x the absolute peak of PostgreSQL and 3 x PostgreSQL performance at high client counts SysBench oltp(write-only) workload with 30 GB database with 250 tables and 400,000 initial rows per table
  34. 34. Amazon Aurora: Over 120,000 Writes/Sec • OLTP test statistics: • queries performed: • read: 0 • write: 432772903 • other:(begin + commit) 216366749 • total: 649139652 • transactions: 108163671 (30044.73 per sec.) read/wri te requests: 432772903 (120211.75 per sec.) other operations: 216366749 (60100.40 per sec.) ignored errors: 39407 (10. 95 per sec.) reconnects: 0 (0.00 per sec.) sysbench write-only 10GB workload with 250 tables and 25,000 initial rows per table. 10-minute warmup, 3,076 clients Ignored errors are key constraint errors, designed into sysbench Sustained sysbench throughput over 120K writes/sec
  35. 35. Amazon Aurora 3x 더 빨리 데이터 로드 • 데이터 베이스 초기화는 표준 PgBench 벤치마크 테스트에서 PostgreSQL보 다 3배 빠름 Command: pgbench -i -s 2000 –F 90
  36. 36. Amazon Aurora >2x 더 빠른 응답 시간 • 매우 높은 쓰기 로드에서 응답시간 >2x 더 빠름 • (그리고 >10x 더 일관적) SysBench oltp(write-only) 23GiB workload with 250 tables and 300,000 initial rows per table. 10-minute warmup.
  37. 37. Amazon Aurora 더욱 일관성있는 출력 • 부하 상황에서 성능은 3배 이상 • PostgreSQL 보다 더욱 일관성 PgBench “tpcb-like” workload at scale 2000. Amazon Aurora was run with 1280 clients. PostgreSQL was run with 512 clients (the concurrency at which it delivered the best overall throughput)
  38. 38. Amazon Aurora is 3x Faster at Large Scale • 데이터베이스가 10 GiB 에서 100 GiB로 증가했을 때 1.5x 에서 3x 로 빨라짐 SysBench oltp(write-only) – 10GiB with 250 tables & 150,000 rows and 100GiB with 250 tables & 1,500,000 rows 75,666 27,491 112,390 82,714 0 20,000 40,000 60,000 80,000 100,000 120,000 10GB 100GB writes/sec SysBench Test Size SysBench write-only PostgreSQL Amazon Aurora
  39. 39. Amazon Aurora 85x 더 빠른 리커버리 SysBench oltp(write-only) 10GiB workload with 250 tables & 150,000 rows Writes per Second 69,620 Writes per Second 32,765 Writes per Second 16,075 Writes per Second 92,415 Recovery Time (seconds) 102.0 Recovery Time (seconds) 52.0 Recovery Time (seconds) 13.0 Recovery Time (seconds) 1.2 0 20 40 60 80 100 120 140 0 20,000 40,000 60,000 80,000 PostgreSQL 12.5GB Checkpoint PostgreSQL 8.3GB Checkpoint PostgreSQL 2.1GB Checkpoint Amazon Aurora No Checkpoints Recovery Time in Seconds Writes Per Second Crash Recovery Time - SysBench 10GB Write Workload Transaction-aware storage system recovers almost instantly
  40. 40. Amazon Aurora 와 PostgreSQL 비교 성능 비교 결과 Measurement Result PgBench >= 2x faster SysBench 2x-3x faster Data Loading 3x faster Response Time >2x faster Throughput Jitter >3x more consistent Throughput at Scale 3x faster Recovery Speed Up to 85x faster
  41. 41. 41 성능을 위한 모범예
  42. 42. 성능 모범 예 § MySQL/RDBMS 성능 향상 방식은 여전히 동일 § 가능한 동시접속 사용을 높임 ü Aurora 출력량은 커넥션 갯수에 따라 증가 § 읽기 확장을 적극 활용 ü 리드 복제의 지연이 극히 낮음, 여러 읽기 분산으로 전체 퍼포먼스 향상 § 파라미터 튜닝 ü 기존 MySQL파라미터를 Aurora로 적용할 필요 없음 à 기본 Aurora 파라미터는 충분히 최적화 § 퍼포먼스 비교 ü 개별 지표(CPU, IOPS, IO throughput)를 너무 중시 말 것 ü 어플리케이션 성능 등에 촛점 § 기타 ü 쿼리 캐스를 ON으로 ü CloudWatch 메트릭 참고
  43. 43. Advanced monitoring 50+ system/OS metrics | sorted process list view | 1–60 sec. granularity alarms on specific metrics | egress to CloudWatch Logs | integration with third-party tools ALARM
  44. 44. 감사합니다 44

×