![분산 원장을 통한 Conflict 해결
Aurora에는 일관성 처리를 위한
많은 요소들이 있음
데이터베이스 노드는 각자의
노드에서 발생한 트랜잭션의
순서를 인지
스토리지 노드는 각 노드에 적용된
트랜잭션의 순서를 인지
2개 이상의 데이터베이스가 2개
이상의 스토리지 노드의
데이터(Page)를 변경하려고
할때만 Conflict 발생
조정 작업이 훨씬 적게 필요함
2 3 4 5 61
BT1 [P1]
BT2 [P1]
BT3 [P1]
BT4 [P1]
BT1
BT2
BT3
BT4
Page1
Quorum
OT1
OT2
OT3
OT4
Page 1 Page 2
2 3 4 5 61
OT1[P2]
OT2[P2]
OT3[P2]
OT4[P2]
PAGE1 PAGE2
MASTER
MASTER
Page 2](https://image.slidesharecdn.com/gettingtoknownewfeaturesofamazonaurora-yoojeongchoi-180414090550/85/Amazon-Aurora-AWS-Summit-Seoul-2018-15-320.jpg)
![계층적 conflict 해결
양쪽 master들은 P1과 P2 페이지
모두를 작성하려고 함
BLUE master는 P1에 대한 쿼럼을
획득하고, ORANGE master는 P2에
대한 쿼럼을 획득함
양쪽 master는 conflict를 확인 후
2개 중 선택: (1) 트랜잭션 롤백 또는
(2) regional resolver에 이관
Regional 중재자가 순서를 결정
(Dead lock처리와 유사, Victim 결정)
2 3 4 5 61
BT1 [P1]
OT1 [P1]
2 3 4 5 61
OT1[P2]
BT1[P2]
PAGE1 PAGE2
MASTER
MASTER
BT1 OT1
Regional
resolver
Page 1 Page 2 Page 1 Page 2
Quorum
X X](https://image.slidesharecdn.com/gettingtoknownewfeaturesofamazonaurora-yoojeongchoi-180414090550/85/Amazon-Aurora-AWS-Summit-Seoul-2018-16-320.jpg)
Amazon Aurora 신규 서비스 알아보기::최유정::AWS Summit Seoul 2018
- 1. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. 최유정 데이터베이스 솔루션즈 아키텍트 / Amazon Web Services Amazon Aurora 신규 서비스 알아보기
- 2. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. AURORA SERVERLESS
- 3. 서버리스 컴퓨팅 + 관계형 데이터베이스 § 온디맨드로 시작하고, 사용하지 않을 시 종료할 수 있다면? § 관리할 인스턴스 없이 자동으로 확장할 수 있다면? § 데이터베이스 비용을 초단위로 사용한만큼만 지불할 수 있다면? § 기존 사용중인 어플리케이션과 호환성을 제공한다면? Amazon Aurora Serverless를 소개합니다. 다양한 워크로드를 서비스하는 어플리케이션에 온디맨드로 자동 스케일링되는 데이터베이스 이러한 데이터베이스 어떠신가요?
- 4. Aurora Serverless 사용 사례 § 자주 사용되지 않는 어플리케이션 (예. 적은 데이터를 가진 블로그 사이트) § 변동하는 부하량을 갖는 어플리케이션 – 예측하기 어려운 피크 처리 등 (예: 뉴스 사이트) § 야간이나 주말에는 사용하지 않는 개발 및 테스트 데이터베이스 § 멀티 테넌트 SaaS 어플리케이션들의 모음
- 6. 데이터베이스 엔드포인트 프로비저닝 데이터베이스 생성 시, Aurora Serverless는: § Aurora 스토리지 볼륨 생성 § 어플리케이션 연결을 위한 VPC 내 프록시 엔드포인트 생성 § 데이터베이스 트래픽 처리를 위한 request routers를 초기화 데이터베이스 인스턴스는 첫번째 요청이 발생할때 프로비저닝 어플리케이션 고객 VPC VPC 프록시 엔드포인트 VPC 엔드포인트 네트워크 로드 밸런서 스토리지 볼륨 REQUEST ROUTERS 데이터베이스 스토리지
- 7. 스케일링 업/다운 § 오로라는 어플리케이션의 부하량을 모니터링 (CPU, memory, connections) § 조정이 필요한 임계치에 도달하면 인스턴스는 자동으로 스케일 업/다운 (일반적으로 5초 이하) § 스케일링 작업은 어플리케이션에 투명하게 수행 – 연결 및 세션 정보를 신규 인스턴스로 전달 § 스케일링을 위한 최소 및 최대 용량 설정 § 데이터베이스 스토리지는 사용자가 명시적으로 삭제할때까지 유지 Aurora WARM POOL REQUEST ROUTER 데이터베이스 스토리지 현재 인스턴스 신규 인스턴스 PROXY 엔드포인트 어플리케이션
- 8. Aurora Serverless 생성 인스턴스 타입 설정 불필요
- 11. Aurora Serverless 모니터링 § 기존 Aurora 모니터링과 동일 § ACU : Aurora Capacity Unit § 1 ACU 가 최소 단위이며, 약 2GB 메모리와 이에 적정한 CPU 및 networking의 조합 § 인스턴스 타입이 아닌, ACU별 과금
- 12. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. AURORA MULTI-MASTER
- 13. 클러스터 내 다수의 Writer Application Master Node Read Replica 1 Read Replica 2 Shared distributed storage volume Availability Zone 1 Availability Zone 2 Availability Zone 3 읽기 성능 확장 Application Read/Write Master 1 Read/Write Master 2 Read/Write Master 3 Shared distributed storage volume Availability Zone 1 Availability Zone 2 Availability Zone 3 읽기 및 쓰기 성능 확장 여러 데이터 센터에 걸쳐, 읽기 및 쓰기 확장 가능한 첫번째 관계형 DB서비스
- 14. 기술적 이점과 사용 사례 § 연속적인 쓰기 가용성 § 쓰기 성능 확장 § 전역적 read-after-write 일관성 기술적 이점 § 지속적인 쓰기 가용성이 필요한 미션 크리티컬 업무 § 인스턴스 장애 시 영향 범위를 줄이기 위한 샤딩 애플리케이션 § R4.16xlarge의 200K writes/sec 이상의 성능이 필요한 쓰기 집약적 애플리케이션 § 초고속 성장이 예상되는 비지니스 애플리케이션 § ”논리적” 복제 지연시간이 없는 샤딩 애플리케이션 사용 사례
- 15. 분산 원장을 통한 Conflict 해결 Aurora에는 일관성 처리를 위한 많은 요소들이 있음 데이터베이스 노드는 각자의 노드에서 발생한 트랜잭션의 순서를 인지 스토리지 노드는 각 노드에 적용된 트랜잭션의 순서를 인지 2개 이상의 데이터베이스가 2개 이상의 스토리지 노드의 데이터(Page)를 변경하려고 할때만 Conflict 발생 조정 작업이 훨씬 적게 필요함 2 3 4 5 61 BT1 [P1] BT2 [P1] BT3 [P1] BT4 [P1] BT1 BT2 BT3 BT4 Page1 Quorum OT1 OT2 OT3 OT4 Page 1 Page 2 2 3 4 5 61 OT1[P2] OT2[P2] OT3[P2] OT4[P2] PAGE1 PAGE2 MASTER MASTER Page 2
- 16. 계층적 conflict 해결 양쪽 master들은 P1과 P2 페이지 모두를 작성하려고 함 BLUE master는 P1에 대한 쿼럼을 획득하고, ORANGE master는 P2에 대한 쿼럼을 획득함 양쪽 master는 conflict를 확인 후 2개 중 선택: (1) 트랜잭션 롤백 또는 (2) regional resolver에 이관 Regional 중재자가 순서를 결정 (Dead lock처리와 유사, Victim 결정) 2 3 4 5 61 BT1 [P1] OT1 [P1] 2 3 4 5 61 OT1[P2] BT1[P2] PAGE1 PAGE2 MASTER MASTER BT1 OT1 Regional resolver Page 1 Page 2 Page 1 Page 2 Quorum X X
- 17. 멀티-리전 멀티-마스터 (향후 출시 예정) 쓰기 작업은 로컬 리전에서 수행 낙관적 동시성 제어 – 분산 lock manager 및 lock management 프로토콜 없음 REGION 1 REGION 2 HEAD NODES HEAD NODES MULTI-AZ STORAGE VOLUME MULTI-AZ STORAGE VOLUME LOCAL PARTITION LOCAL PARTITIONREMOTE PARTITION REMOTE PARTITION 계층적 Conflicts 처리 – head 노드, 스토리지 노드, AZ 및 region 레벨 중재자 Conflicts가 없거나 낮은 경우, 거의 선형 성능 확장
- 18. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. AURORA PARALLEL QUERY
- 19. 수천개 스토리지 CPU를 활용한 쿼리 Aurora 스토리지에는 수천개의 CPU가 있음 § 스토리지를 활용하여 쿼리 프로세싱을 병렬화 § 스토리지에서 데이터를 처리함으로써 네트워크 트래픽 및 지연시간을 줄임 주요 기능 및 이점 § 해시 조인, 단일 테이블 표현식, CASE 문 및 100 여개의 SQL 함수를 처리 § 최대 25 배 빠른 분석 쿼리 § OLTP 처리량에 영향을 미치지 않음 § 병렬 처리 수준은 테이블 크기에 따라 조정 § 쿼리 옵티마이저에 의해 자동 관리 § 스토리지 및 네트워크 장애에 영향 받지 않고 처리 데이터베이스 노드 스토리지 노드 쿼리 술어 전달 결과 취합
- 20. Head 노드의 프로세싱 STORAGE NODES OPTIMIZER EXECUTOR INNODB NETWORK STORAGE DRIVER AGGREGATOR APPLICATION 부분 결과 스트림 결과 IN-FLIGHT DATA PQ CONTEXT PQ 실행계획 쿼리 옵티마이저는 Parallel Query (PQ) 실행계획을 작성하고 리프 페이지 정보를 기반으로 PQ context를 생성 PQ 요청은 PQ context와 함께 스토리지 노드로 전달 스토리지 노드는 § 기처리된(stable) row들에 대한 부분 결과 스트림을 생성 § 아직 처리되지 않은(unprocessed) row들의 Raw 스트림을 undo정보와 함께 생성 Head 노드는 이러한 데이터 스트림들을 취합하여 최종 결과를 생성
- 21. 스토리지 노드의 프로세싱 각 스토리지 노드는 parallel query와 연관된 최대 16개 PQ 프로세스를 실행 PQ 프로세스는 PQ context를 전달받음 § 스캔해야할 페이지 리스트 § 읽기 뷰와 조회 컬럼(projections) § 표현식 바이트 코드 PQ 프로세스는 페이지 리스트를 두번 조회 § 조회 1: InnoDB 형식의 raw 데이터에 대한 필터 처리 § 조회 2: MySQL 형식 데이터에 대한 표현식 처리 PQ 프로세스 PQ 프로세스 최대 16 TO/FROM HEAD 노드 스토리지 노드 프로세스 페이지 리스트
- 22. Parallel query 성능 지연시간 (초) 의사결정 벤치마크(Decision support benchmark), R3.8xlarge, buffer cache에 캐싱되지 않은 경우 Parallel Query 개선 효과 24.6x 18.3x 5.0x 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Aggregate + 2-table join Aggregate query Point query on non-indexed column With Parallel Query Without Parallel Query
- 23. Parallel query 사용 § Parallel query는 aurora_pq 파라미터를 통해 데이터베이스 레벨 및 세션 레벨로 설정 가능 è set session aurora_pq = {'ON'/'OFF’} ) § Parallel query는 옵티마이저가 테이블 크기와 데이터량을 기반으로 판단하여 자동 적용하나, aurora_pq_force 세션 파라미터로 강제 설정 가능(테스트 용도) +--------------------------------------------------------------------------------------------------------------------------------+ | Extra | +--------------------------------------------------------------------------------------------------------------------------------+ | Using where; Using temporary; Using filesort; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) | | Using where; Using join buffer (Hash Join Outer table orders); Using parallel query (4 columns, 1 filters, 0 exprs; 0 extra) | | Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel query (4 columns, 1 filters, 0 exprs; 0 extra) | +--------------------------------------------------------------------------------------------------------------------------------+ * Parallel query 사용 시 아래와 같이 2 단계로 수행됨 – Explain으로 확인 시
- 24. Parallel query 수행 SELECT l_orderkey, sum(l_extendedprice * (1 - l_discount)) AS revenue, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_mktsegment = 'AUTOMOBILE' AND c_custkey = o_custkey AND l_orderkey = o_orderkey AND o_orderdate < date '1995-03-13’ AND l_shipdate > date '1995-03-13' GROUP BY l_orderkey, o_orderdate, o_shippriority ORDER BY revenue DESC, o_orderdate LIMIT 10 TPCH 벤치마크 쿼리 --Without Parallel Query +------------+-------------+-------------+----------------+ | l_orderkey | revenue | o_orderdate | o_shippriority | +------------+-------------+-------------+----------------+ | 92511430 | 514726.4896 | 1995-03-06 | 0 | . . | 28840519 | 454748.2485 | 1995-03-08 | 0 | +------------+-------------+-------------+----------------+ 10 rows in set (24 min 49.99 sec) --With Parallel Query +------------+-------------+-------------+----------------+ | l_orderkey | revenue | o_orderdate | o_shippriority | +------------+-------------+-------------+----------------+ | 92511430 | 514726.4896 | 1995-03-06 | 0 | . . | 28840519 | 454748.2485 | 1995-03-08 | 0 | +------------+-------------+-------------+----------------+ 10 rows in set (1 min 49.91 sec) * db.r4.2xlarge 인스턴스에서 buffer cache에 캐싱되지 않은 경우
- 25. Parallel query 모니터링 § Parallel query 사용 관련 정보는 SHOW GLOBAL STATUS를 통해 확인 가능 Name Description Aurora_pq_attempted 요청한 PQ 세션 수 Aurora_pq_executed 실행된 PQ 세션의 수 Aurora_pq_failed 실패한 PQ 세션 수 Aurora_pq_in_progress 현재 진행중인 PQ 세션 수 Aurora_pq_not_chosen PQ가 선택되지 않은 수 Aurora_pq_not_chosen_below_min_rows 테이블 크기로 인해 PQ가 선택되지 않은 수 Aurora_pq_not_chosen_unsupported_long_trx 장시간 트랜잭션으로 인해 선택되지 않은 PQ 요청 수 Aurora_pq_not_chosen_unsupported_op 미 지원 오퍼레이션으로 인해 선택되지 않은 PQ 요청 수
- 26. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. AURORA PostgreSQL
- 27. RDS PostgreSQL 서비스 CLIENTS RDS PostgreSQL Aurora PostgreSQL EBS Aurora Storage Postgres 9.6—동일 extensions 백업/복구- PITR 고가용성 & 내구성 보안 읽기 복제본 크로스 리전 스냅샷 컴퓨트 노드 확장– 온라인 스토리지 확장 크로스 리전 복제 기능 아웃바운드 논리 복제
- 28. 동시성—로그 버퍼 제거 대기중인 작업 로그 버퍼 PostgreSQL Aurora PostgreSQL 스토리지 A 대기중인 작업 스토리지 B C D E 0 0 0 0 0 A B C D E 2 2 1 0 1 A B C D E 4 3 4 2 4 A B C D E 6 5 6 3 5 A B C D E 쿼럼 구성 추적
- 29. 3,729 4,871 17,158 - 5,000 10,000 15,000 20,000TPS(2UpdatesperTransaction) PostgreSQL 9.6 기준 BASE 16GB Max WAL Aurora PostgreSQL Aurora PostgreSQL 성능 - Update
- 30. Aurora PostgreSQL 최대 97% 빠른 복구 3 GiB 리두 로그 복구 19초 소요 10 GiB 리두 로그 복구 50초 소요 30 GiB 리두 로그 복구 123 초 소요 0 20 40 60 80 100 120 140 160 0 20,000 40,000 60,000 80,000 100,000 120,000 140,000 복구시간(초)(작을수록좋음) Writes / Second (클수록 좋음) 워크로드 별 장애 후 복구 시간 동그라미 크기는 반드시 복구해야하는 리두 로그의 크기를 나타냄 PostgreSQL 처리량이 늘어날수록 로그 크기와 복구 시간이 늘어남 Amazon Aurora 는 리두 로그가 없음. 처리량이 훨씬 큰 상황에서 복구 3초 소요
- 31. 읽기 전용 복제본 - PostgreSQL PostgreSQL RW EBS Snapshot PostgreSQL RO EBS update 비동기 복제 변경 분 반영
- 32. 읽기 전용 복제본 - Aurora PostgreSQL Aurora RW PostgreSQL RO update 비동기 복제 Aurora Storage 메모리 갱신
- 33. pgbench 벤치마크 테스트 비동기 복제 및 반영 PostgreSQL Aurora PostgreSQL RW RO accounts tellers branches history accounts tellers branches history 비동기 복제 및 메모리 갱신 RW RO accounts tellers branches history accounts
- 34. Aurora Storage RO Application AZ-1 AZ-2 AZ-3 빠른 데이터베이스 복제 RW Application RW Developers Reporting Async Invalidation & Update Clone update Primary Storage Clone Storage
- 35. 캐쉬 적용 - Double Buffering 없음 488GB RAM PG + OS processes shared_buffers Linux pagecache 데이터 조회 시 shared_buffers 내 블록 체크 shared_buffers에 없으면 pagecache 또는 disk로부터 로딩 EBS 1/4 duplicate buffers PG + OS processes shared_buffers PostgreSQL Aurora PostgreSQL Aurora Storage 데이터 조회 시 shared_buffers 내 블록 체크 또는 Aurora 스토리지로부터 로딩 3/4 Survivable Cache
- 36. 캐쉬 적용 - Double Buffering 없음 689,068 417,496 334,691 682,931 - 100,000 200,000 300,000 400,000 500,000 600,000 700,000 800,000 TransactionsPerSecond(tps) pgbench read only - scale 22,000 - r4.16xlarge Aurora 75% Cache PostgreSQL 25% Cache PostgreSQL 10% Cache PostgreSQL 75% Cache 1.6x 2.0x 18K read iops no reads heavy double buffering no double buffering no survivable cache 약 350GB 데이터 세트
- 37. 왜 Vacuuming이 중요한가? tuple1 tuple2 tuple3 tuple4 tuple5 tuple6 tuple1tuple1 tuple2 tuple2 tuple7 tuple8 tuple9 tuple10 Vacuum 수행 시tuple3 tuple4 tuple3 tuple4 tuple1 tuple2 tuple3 tuple4 tuple5 tuple6 tuple1tuple1 tuple2 tuple2 tuple7 tuple8 tuple9 tuple10 Vacuum 미 수행 시tuple3 tuple4 tuple3 tuple4 더 많은 블록= 더 많은 캐쉬 미스, 더 많은 FPW
- 38. 효율적인 Vacuum Prefetch PostgreSQL Aurora PostgreSQL 배치 I/O 처리
- 39. 체크포인트 Amazon Aurora Available Durable AWS DMS Amazon RDS AWS IAM, KMS & VPC Amazon S3 Convenient Compatible Automatic Failover Read Replicas X 6 Copies High Performance & Scale Secure Encryption at rest and in transit Enterprise Performance 64TB Storage PostgreSQL MySQL
- 40. 본 강연이 끝난 후 Aurora 신규서비스 평가판 가입하기 • Aurora Serverless https://pages.awscloud.com/amazon-aurora-serverless-preview.html • Aurora Multi-master https://pages.awscloud.com/amazon-aurora-multimaster-preview.html • Aurora Parallel Query https://pages.awscloud.com/amazon-parallel-query-preview.html
- 41. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. AWS Summit 모바일 앱과 QR코드를 통해 강연 평가 및 설문 조사에 참여해 주시기 바랍니다. 내년 Summit을 만들 여러분의 소중한 의견 부탁 드립니다. #AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 공유될 예정입니다. 여러분의 피드백을 기다립니다!
- 42. 감사합니다