[DB] WAL Write 성능 실험

WAL 구조를 직접 구현해보면서 성능 트레이드오프가 어느 정도인지 대충 벤치마크 돌려본걸 정리한 글이다.
언어는 Rust다.

디스크 sync 시점: fsync vs fdatasync

https://blog.naver.com/sssang97/224039042217

fsync. 그러니까 디스크 완전 동기화는 성능에 얼마나 큰 영향을 끼칠까?

일단은 write마다 fsync를 날려봤다. 데이터셋은 10000만개.

확실히 느리긴 했다. 초당 300개 언저리밖에 넣지 못했다.

그러면 datasync는 어떨까? fsync가 모든 데이터와 파일 메타데이터 모두를 디스크에 flush하는 api라면, datasync는 파일 데이터만 flush하는 API다.
그래서 PostgreSQL의 경우에도 WAL write시에 datasync만을 하는 것이 기본 옵션이다.

근데 사실, 별 차이는 없더라. 차이가 있더라도 눈에 띄지 않는 수준인 것 같다.

다른 방법은, 아예 그냥 fsync를 하지 않는 것이다.
이러면 OS가 하고 싶을때만 disk에 flush되고, 데이터 내구성은 손실될 테지만 성능은 크게 향상될 수 있다.

그럼 확실히 빨라지긴 한다. 초당 13000건이나 처리가 가능해졌다.

CassanrdaDB의 경우에는 write마다 fsync를 하지 않고, 10초마다 fsync를 몰아서 처리하는 방식을 취한다.

10초마다 하나, 아예 안하나 별 차이는 없더라. 이 방법이 최적화하기 가장 편한 방법인 것 같긴 하다.
그래서 난 이 background fsync로 선택했다.

압축 알고리즘 선택

대부분의 주요 DB들은 직접 커스텀한 바이너리 압축 알고리즘을 사용한다.
난 굳이 그렇게까지 하고 싶진 않아서, 기존 구현체만 가져다가 뭐가 낫나 비교해봤다.

데이터는 10만개 정도, 키는 uuid, 값은 적당한 크기의 문자열

JSON의 경우에는

사실 payload 크기가 엄청 큰건 아니라서, 10만개씩 넣어도 크기가 별로 크진 않다. 느리지도 않고

protobuf도 써봤다. 구현체는 rust-protobuf 3.7다.
공식 구현체는 아니라서 신뢰성이 높지 않긴 한데

적당히 이렇게 나왔다. 사실 실행 성능에는 별 차이가 없었다.
어차피 파일 I/O가 대부분의 병목이라서인 것 같다.

FlatBuffer도 써봤다. 구현체는 공식 구현체인 flatbuffer-rs다.

이것도 별 차이는 없었다. 압축률이 아주 좋은건 아니다.

마지막으로 테스트해본건 bincode다. 표준 알고리즘같은건 아니고,
Rust에만 구현체가 있다. 가장 잘 구현된 편이라고 해서 써봤다.

저장공간 효율성은 protobuf와 대등하고, max latency가 좀 더 나았다. 의미있는 수준은 아니지만.
그래도 개중에는 성능/사용성 측면에서는 제일 나은거같아서 bincode로 갔다.

file write 시스템콜 줄이기

사실 현실적인 병목은 write 자체가 많다는 것이 가장 크다.
아무리 다른걸 최적화해도 OS에 write를 날리는 것 자체가 헤비한 작업이라 의미가 없다.

일단 write 자체를 줄여보자.

기존에는 좀 무식하게 write를 처리했었다. 크기 헤더가 있고, 본문이 있는데, 저걸 따로 날렸다.

저걸 그냥 코드에서 합쳐서 보내기만 해도 write 호출이 한번 줄어든다.
그렇게 돌려보면

유의미한 성능 향상이 보인다.

뭔가 더 줄일 수는 없을까?
지금 상태에서는 append당 2번의 write 호출이 있다.

save_state는, 현재 세그먼트 파일의 정보와 최신 record_id의 정보를 담는 상태 파일이다.
상태 관리용 파일이 따로 있는게 대충 짜기 편해서 뒀는데, 생각해보면 이런 것도 최신 파일을 끝까지 읽으면 다 가져올 수 있는 정보다.
실행 중에는 메모리에서만 수정하고, 재시작할때는 세그먼트 파일을 읽어서 recover하는 식으로 해보자.

그러면

눈에 띌 정도로 최적화가 된 것을 볼 수 있다.

세그먼트 파일 크기

그러면 세그먼트의 파일 크기는 성능에 어떤 영향을 미칠까?
일단 내 경우에는 PostgreSQL의 경우를 따라서 16MB로 맞춰놓은 상태였다.

이건 완벽한 정답이라고는 할 수 없는데, OS 페이지 캐시 단위와 밀접한 연관이 있다.
그래서 이건 DB마다 조금씩 다르다.

CassandraDB의 경우에는 세그먼트 크기가 32MB길래, 동일하게 맞춰봤다.

그랬더니 근소한 향상이 있었다.

그렇다고 더 늘리면 오히려 느려졌다.

내 장비의 경우에는 32MB 정도가 딱 적당한가보다.

그래서 그냥 32MB로 정했다.

버퍼링

Vector 할당을 좀 줄여볼까 했다. 기존에는 매 append 호출마다 버퍼를 초기화했는데

그냥 글로벌 버퍼 하나 두고서

계속 돌려쓰면서 넣게 했다.

뭔가 빨라진 느낌이 들긴 하는데, 오차가 좀 있어서 크게 빨라졌다는 확신은 들지 않았다.

Allocator?

나름 내부 할당이 꽤 있을만한 코드니까, allocator를 커스텀하면 좀 빨라지지 않을까 기대를 했다.
그래서 jemalloc을 붙여봤는데

이것도 사실 별 차이는 없었다.

컴파일러 최적화 옵션

Rust는 추가적인 최적화 옵션을 몇가지 제공하는 편이다.
https://blog.naver.com/sssang97/223216318146

이 중에서 lto, strip, native 컴파일 옵션을 줘봤다.

codegen unit 조정은 컴파일이 너무 느려지는데 반해 효과도 잘 안보여서 뺐다.

그러니까 꽤 빨라지긴 하더라. TPS가 53000-54000 정도까지 올랐다.

PGO도 돌려봤다.

이것도 마찬가지로 유의미한 향상은 없었다.

Memory Map (mmap)

왜이리 느릴까 해서 CassadraDB 코드를 뜯어보다보니까, 기본 설정이 mmap을 쓰는 거라는 것을 깨닫게 됐다.
그래서 file write를 쓰지 않고 mmap 기반으로 쓰기를 처리하도록 바꿨다.

그랬더니

상당히, 매우 빨라졌다.
더 최적화할 여지가 있긴 할 것 같긴 한데, 이 정도만 해도 충분히 빠르다고 볼 수 있을 것 같다.

Zero Copy

그래도 여전히 최적화의 여지는 남아있었다.
위 버전에서는 mmap을 통해 개선이 되긴 했는데, 인코딩된 값을 buffer에 둔 다음에 그걸 다시 mmap에 넣는 방식을 취했다. 이것도 사실 불필요한 복사나 다름없다.

그래서 mmap에 인코딩된 값을 바로 write하도록 수정했다.

그러니 드디어 70000 tps의 벽을 넘었다.

여기서 만족하고 실험은 마무리했다. 이 이상은 하드웨어 한계에 가까운 것 같다.

서버 코드
https://github.com/myyrakle/barus

벤치마크 코드
https://github.com/myyrakle/benchmarks/tree/master/database_write_performance