10P by xguru 2021-11-15 | favorite | 댓글 1개

- Heap은 분석용 멀티 페타바이트 Postgres를 운영중
- 빠르게 성장하면서 노드 사용률이 80%를 넘어 수집 파이프라인에서 성능문제가 발생
- 문제의 원인은 SSD는 사용률이 100%에 가까워 지면 성능이 저하되는 경향이 있다는 것
- CoW(Copy-on-Write)인 ZFS를 사용하는 것 때문에 문제가 악화됨
ㅤ→ 블록이 업데이트 될때마다 새로운 복사본을 작성
- 물론, CoW는 여러가지 장점이 있음
ㅤ→ 파일시스템 단위의 압축이 다른 파일시스템 대비 편해서 4-5x 압축하여 공간을 절약
ㅤ→ 더 높은 내구성을 가져서 Postgrest의 full_page_writes를 비활성화 가능하고, 이로써 성능도 향상되고 전체 IO가 감소
ㅤ→ 일관성을 보장해 주는 Point-in-time 스냅샷 - 페이지가 실제 변경 불가능하므로 스냅샷 중에도 예전 페이지를 유지
- 하지만 ZFS 같은 CoW 파일시스템은 용량이 차면서 성능이 떨어짐
ㅤ→ 페이지 업데이트 할 때마다 블록 얼로케이터가 빈 블락을 찾아야 하므로 사용률이 높아지면 성능 저하가 심각해짐
ㅤ→ 이전에 언링크된 블록을 삭제하고 기존 블록들과 섞어야함
ㅤ→ 더 높은 압축률을 얻기 위해 블록 크기를 64kb로 크게 설정해서 더 악화 되었음
ㅤ→ 이런 이유로 인해서 ZFS의 사용률은 80%를 넘지 않는 것이 좋음

- ZFS 2.x로 업그레이드 해서 lz4 압축에서 Zstandard 압축으로 변경하는 것을 시도
ㅤ→ lz4는 엄청 빠르고 ~4.4x 정도의 압축률을 보임
ㅤ→ Zstandard는 ~5.5x 까지의 압축률을 보여줘서 20%를 개선
ㅤ→ 하지만 많은 벤치마크에서 Zstandard가 lz4보다 속도가 느리다고 나옴
ㅤ→ 그래서 실제 상황에서 엄격한 테스트를 해보기로 함
ㅤ→ 테스트 결과 쿼리 성능은 변하지 않고 스토리지 사용도가 ~20% 감소하고, 쓰기 쿼리 시간이 절반으로 감소

- Heap의 DB클러스터는 5개의 노드로 나뉘어져서 각각의 ASG에 속함
ㅤ→ 노드 변경은 간단히 ASG에서 분리하기만 하면, ASG 새로운 노드를 만들고 최종 백업본에서 리스토어하고 웜 스탠바이 모드에 들어감
ㅤ→ 새로운 설정의 AMI를 만들고 각 노드를 하나씩 진행
ㅤ→ 전체 사용량은 ~21% 줄었고, 쓰기시간이 50% 감소했고, 쿼리 성능은 별반 차이 없었음

- Arch Linux 가 패키지 압축 도구를 xz에서 Zstandard로 교체 https://news.hada.io/topic?id=1227
- 압축 알고리즘 르네상스 https://news.hada.io/topic?id=1228

글에서는 CPU사용률 얘기가 없는데 HN에서 원저자의 댓글을 보니 ~40% 에서 ~50%로 증가했다고는 합니다.(Zstd가 CPU는 더 쓴다는 얘기)
- https://news.ycombinator.com/item?id=29164727