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 엔드포인트
어플리케이션
11. Aurora Serverless 모니터링
§ 기존 Aurora 모니터링과 동일
§ ACU : Aurora Capacity Unit
§ 1 ACU 가 최소 단위이며, 약
2GB 메모리와 이에 적정한
CPU 및 networking의 조합
§ 인스턴스 타입이 아닌,
ACU별 과금
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가 없거나 낮은 경우, 거의 선형 성능 확장
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 요청 수
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
쿼럼 구성
추적
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
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
