[DB] WAL과 fsync

https://m.blog.naver.com/sssang97/223233122052

Write Ahead Log(이하 WAL)은 DB에 있어서 가장 중요한 근간이면서도, 가장 큰 성능 병목 지점이기도 하다.
이건 어떤 DB든 마찬가지다. 그리고 그 병목의 세부사항 중 하나가 디스크 쓰기 보장(fsync)이다.

WAL이 제때 작성되어야 혹시나 장애가 발생하더라도 복구할 수가 있는건데, 그렇다고 무작정 write마다 fsync를 날려서 WAL을 확실하게 추가하면 성능 부하가 크게 걸린다. 이게 생각보다 엄청 큰 딜레마다.

fsync를 너무 날려대면 디스크 저장은 확실하게 보장되니 안전하기야 하지만, 그만큼 디스크/리소스 부하가 커진다. 그렇다고 fsync를 게으르게 하면, 진짜 디스크 쓰기가 완료되기 전에 서버가 뻗을 경우 손실이 발생한다.

PostgreSQL의 경우

PostgreSQL은 안정성을 성능보다 중요시하는 경우라서, fsync를 write마다 날리는 축에 속한다. 하지만 조정 가능한 옵션이 제공된다.

WAL fsync와 직접적으로 관련된 파라미터로는 commit_delay가 있다. 단위는 마이크로초고 기본값은 0이라서 항상 즉시 쓰기를 수행한다.

commit_delay에 500ms를 지정한다면, write가 발생했을 때 최대 500ms까지 다른 write를 기다렸다가 fsync를 날리는 식으로 동작한다. 모아서 쏘는 것이다.
당연히 이 값을 늘릴 수록 쓰기 성능은 향상되겠지만, 그만큼 장애시 데이터 내구성이 손실될 것이다.

CassandraDB의 경우

CassandraDB는 이 부분에서 내구성을 포기하고 성능을 가져가는 방법을 선택했다.
write마다 fsync 동기화를 하지는 않고, 백그라운드 루프를 통해서 정기적으로 fsync를 날리는 방식으로 디스크 저장을 느슨하게 보장한다.

이에 대한 파라미터가 commitlog_sync_period_in_ms다. 기본값은 10000(10초)다.

이 말인즉슨 10초마다 동기화를 한다는 것이고, 하드웨어 장애 등이 발생한다면 10초 내에 저장된 값은 진짜 증발할 수 있다는 것이다.

참조
https://cassandra.apache.org/doc/3.11/cassandra/architecture/storage_engine.html
https://stackoverflow.com/questions/67353944/will-the-write-ahead-log-become-the-bottleneck-of-cassandra
https://postgresql.kr/docs/9.5/runtime-config-wal.html
https://wiki.postgresql.org/wiki/Group_commit