[Pgday.Seoul 2019] AppOS 고성능 I/O 확장 모듈로 성능 10배 향상시키기 - 김상욱

1. AppOS 고성능 I/O 확장 모듈로
성능 10배 향상시키기
김 상 욱

2. 데이터베이스 서버의 낮은 클라우드 스토리지 활용률
Database on Cloud
2
새로 개발되고 있는 데이터베이
스는 유연성, 확장성에만 초점
기존 데이터베이스는 클라우드
환경을 고려하지 않고 설계됨
* Mainstream DB: MySQL, MariaDB, PostgreSQL, MongoDB * New DB: Cockroach, YugaByte, TiDB, Vitess

3. Characteristics of Cloud Storage
3
클라우드 스토리지 특성
특정 크기 기준
IOPS 제어
로컬 SSD특수 기능

4. IOPS Control
4
클라우드 스토리지 IOPS 제어 시 I/O 크기 최대치만 존재
PostgreSQL/
Oracle
MySQL/MariaDB
AppOS 적용 시
Linux
AWS, Azure: 256KB
GCP, IBM: 16KB

5. IOPS Control
5
클라우드 스토리지 IOPS 제어 시 IO 크기 최대치만 존재
e.g., 256KB
3 IOPS 소모
클라우드
스토리지
리눅스
페이지 캐시
DB 버퍼
…

6. Atomic Write Support
6
클라우드 스토리지 atomic write 지원

7. Atomic Write Support
7
PostgreSQL는 buffered I/O만을 지원하기 때문에 활용 불가능
8KB
최소 4KB 단위로
스토리지에 반영
리눅스
페이지 캐시
DB 버퍼
8KB

8. Local SSD
8
로컬 SSD 높은 성능 제공하지만 저장공간으로 적합하지 않음
로컬
SSD
+ 높은 성능
- 데이터 손실 가능
네트워크
스토리지DB
서버 네트워크
+ 데이터 안전
- 낮은 성능

9. AppOS Extension
9
클라우드 네이티브로 변환해주는 확장 모듈
처리량 10x
응답시간 11x
다운로드
데이터베이스
재시작

10. 10
Background: Linux I/O Stack
Storage Device
Caching Layer
PostgreSQL
File System Layer
Block Layer
Abstraction
Buffer Cache
read() write()
FG FGBG
BG FG BGBG
reorder
리눅스 내부 다양한 계층 통해서 파일 I/O 처리
BG
reorder
Page Cache
I/O Scheduler
Firmware Scheduler

11. AppOS Architecture
11

12. AppOS Architecture
12

13. 13
AppOS Internals
_PG_init
Postgres
Linux kernel
syscall
Postgres
Linux kernel
syscall
prehook
syscall
posthook
Postgres
Linux kernel
syscall
prehook
syscall
posthook
appos
core
File
I/O
On-disk
access

14. 14
AppOS Internals
Virtual File
System
Page Cache
Block I/O
Context-aware
I/O Scheduler
Appos core API
I/O API
Postgres Context Classifier
POSIX file API
checkpointer
autovacuum
backend
…Cached Direct
Linux

15. 15
AppOS Internals
File Level Read/Write Lock
D D CDD C D
write
D DD D DD CC
I/O Level Range Lock
Linux page cache AppOS page cache
PostgreSQL shared buffer
readwrite
BLOCK!!!
AppOS uses range lock instead of big file lock
PostgreSQL shared buffer
readwrite

16. 16
AppOS Internals
AppOS
Page Cache
D C
Appos
I/O Scheduler Context-Aware I/O Sheduler
checkpointer: 200 shares
autovacuum: 200 shares
backend: 500 shares
writeback: 100 shares
Example:
D D
Linux kernel
backend
read
writeback
write
control
inflight I/Os
AppOS schedules I/Os based on context and congestion

17. Cloud Storage Driver
17
클라우드 스토리지 IO 크기 고려한 요청 크기 제어
e.g., 8KB * 32 pages
1 IOPS 소모
클라우드
스토리지
AppOS 캐시
DB 버퍼
…

18. Cloud Storage Driver
18
AWS 클라우드에서 처리량 4x 향상
* AWS Seoul: r5.4xlarge (16 vCPUs, 128GB memory, 500GB 2k iops EBS) * SysBench 1.0.15 (client): c5.xlarge (4 vCPUs), 10GB initial dataset * PostgreSQL 11.5: shared_buffers 25% memory, max_wal_size 8GB

19. Atomic Write Support
19
AppOS의 direct I/O를 통해 atomic write 활용 가능
8KB
최소 8KB 단위로
스토리지에 반영
AppOS 캐시
DB 버퍼
8KB

20. Atomic Write Support
20
GCP 클라우드에서 처리량 4x ~ 12x 향상
* GCP Tokyo: n1-standard-32 (32 vCPUs, 120GB memory, 500GB 16KB SSD PD) * SysBench 1.0.15 (client): n1-highcpu-8 (8 vCPUs), 50GB initial dataset * PostgreSQL 9.6.12: shared_buffers 25% memory, max_wal_size 2GB
(full_page_writes = off)

21. Local SSD Caching
21
로컬 SSD 메모리 확장으로 활용
write
네트워크
스토리지
로컬 SSD
Write through
write ack
ack write
Write back
async
write
+ 데이터 안전
- 느린 쓰기
네트워크
스토리지
로컬 SSD
ack
+ 빠른 쓰기
- 데이터 손실
write
Flush on sync
async
write
네트워크
스토리지
로컬 SSD
ack
+ 데이터 안전
+ 빠른 쓰기
sync
flush

22. Local SSD Caching
22
로컬 SSD 메모리 확장으로 활용
NVMe
SSD
1000GB
(3000 iops)
300GB
(AWS 기준 월 $60)
기존 EBS 단일 구성 Apposha 로컬 SSD 솔루션
VS.EBS16 코어
64GB 메모리
1000GB
(3000 iops)
EBS16 코어
64GB 메모리
AppOS
네트워크 네트워크

23. Local SSD Caching
23
월 $60 추가로 AWS에서 5~13배 처리량 향상 가능
처리량 13배
62,0005,000 20,0003,800
처리량 5배

24. 24
Extensibility
PostgreSQL 기반 다양한 DB에 적용가능

25. 25
TimescaleDB Performance

26. 26
TimescaleDB Performance
TimescaleDB 데이터 삽입
초당 3만6천건

27. 27
TimescaleDB Performance
TimescaleDB 데이터 삽입 7x 향상
초당 26만건

28. 28
TimescaleDB Performance
AppOS 적용 시 HDD가 SSD보다 높은 성능
SSD로 교체해도 초당 23만건

29. 29
TimescaleDB Performance
TimescaleDB 쿼리 시간 1/5 감소
Aggregate on across
both time and host,
giving the average of all
(10) CPU metrics per host
per hour for 24 hours

30. Operational Benefits
30
리소스 세부
모니터링 운영 안정성 향상
스토리지 관련
튜닝 불필요

31. Operational Benefits
31
시스템 리소스 세부 지표 모니터링 가능

32. Operational Benefits
32
실시간 SLA 보장

33. 33
WAL 튜닝
스토리지
특성 분석
백그라운드
태스크 튜닝
스토리지 관련 튜닝 어려움 해소
Operational Benefits

34. Operational Benefits
34
WAL 최대 크기 정해주더라도 동적으로 생성/삭제

35. Operational Benefits
35
AppOS 적용시 트래픽에 따라 WAL 선할당량 조절

36. Operational Benefits
36
운영 안정성 향상: 데이터 파편화 및 공간 낭비 완화
PostgreSQL Vacuum PostgreSQL Analyze

37. Operational Benefits
37
데이터 파편화 및 공간 낭비 완화
Server: r5d.4xlarge, 300GB NVMe SSD, Ubuntu 16.04, PostgreSQL v11.3 (shared_buffers=32GB, max_wal_size=8GB) Client: c5.xlarge
Aggressive Autovacuum:
autovacuum_vacuum_cost_delay=1s
autovacuum_vacuum_cost_limit=10000

38. 38
IOPS vs. 처리량?HDD or SSD? 동적 성능 변화?
스토리지 특성 세부 분석 어려움 해소
Operational Benefits
파일시스템? I/O 스케줄러? 시스템 튜닝?

39. Future of AppOS
39
스토리지
데이터베이스
Apposha Platform
표준
인터페이스
다양한 데이터베이스 및 스토리지 지원
HDD SSD 블록
스토리지
오브젝트
스토리지
비휘발성
메모리

40. https://apposha.io
sangwook@apposha.io