누군가 복잡한 이론을 건너뛰고 이런 시스템을 만들 때마다 aphyr가 그걸 무너뜨리는 걸 봄
이제는 AI가 프로젝트 문서를 읽고 데이터 손실 가능성을 마케팅 문구만으로 예측할 수 있을지도 궁금해짐
긴 수염을 쓰다듬으며 고개를 끄덕이는 기분임
사람들은 늘 “이론은 과대평가됐다”거나 “학교 교육보다 해킹이 낫다”고 말하지만, 결국 문서화된 문제 공간에서 스스로 발목을 잡는 꼴이 됨
나도 LLM에게 비슷한 일을 시켜봤는데, 결과가 꽤 유용했음
NATS가 CAP 이론을 무시하는 듯한 느낌임
과소평가된 발언 같음
나는 NATS를 in-memory pub/sub 용도로 써왔는데, 그 부분에서는 훌륭했음
미묘한 스케일링 디테일도 잘 처리했음
하지만 persistence는 써본 적 없고, 이렇게까지 취약할 줄은 몰랐음
단일 비트 파일 손상에도 취약하다니 당황스러움
관련된 자료로, Jepsen과 Antithesis가 최근에 분산 시스템 용어집을 공개했음
참고하기에 아주 좋은 자료임 → Jepsen Glossary
aphyr.com/tags/jepsen과 jepsen.io/analyses의 콘텐츠 차이가 궁금했음
최근 aphyr.com을 발견했는데, 통찰이 많을 것 같아 기대 중임
Jepsen은 원래 개인 블로그 시리즈로 시작했음
이후 jepsen.io는 전문 프로젝트로 발전했고, 약 10년 전부터 본격적으로 운영하기 시작했음
“Lazy fsync by Default” 설정이 왜 존재하는지 의문임
벤치마크 성능을 높이려는 이유인가? 작은 클러스터에서는 이런 설정이 문제의 원인이 되곤 함
단순히 지연 시간뿐 아니라 처리량(throughput) 향상도 있음
많은 애플리케이션은 완전한 내구성을 요구하지 않기 때문에 lazy fsync가 유용할 수 있음
다만 기본값으로 두는 건 논란의 여지가 있음
fsync를 왜 반드시 지연시켜야 하는지 늘 궁금했음
TCP corking처럼 묶음 처리(batch) 로 해결할 수 있을 것 같음
분산 시스템이라 가능한 일 중 하나임
lazy fsync로 인한 실패는 대부분의 노드에서 동시에 일어나지 않기 때문임
성능 향상을 위한 선택이 맞음
복제와 분산을 통한 내구성과, lazy fsync로 확보한 처리량을 함께 노림
JetStream의 서버리스 대안으로 s2.dev를 추천함
장점: 객체 스토리지 수준의 내구성을 가진 무제한 스트림 지원
단점: 아직 consumer group 기능이 없음
Jepsen 테스트를 돌려본 적 있는지 궁금함
NATS가 기본적으로 2분마다만 fsync를 수행하고, 즉시 ack를 반환한다는 점이 문제임
여러 노드가 동시에 장애를 겪으면 커밋된 데이터 손실이 발생할 수 있음
MongoDB 초창기 시절의 “웹 스케일” 마케팅이 떠오름
기본값은 항상 가장 안전한 옵션이어야 한다고 생각함
NATS는 클러스터 가용성만 보장한다고 명확히 밝힘
그 점이 오히려 좋았고, 그 위에 시스템을 설계할 수 있었음
2018년에 사용했을 때는 성능도 좋고 관리도 쉬웠음
대부분의 현대 DB도 기본값이 완전 안전하지 않음
예를 들어 PostgreSQL의 기본 트랜잭션 격리 수준은 read committed임
Redis도 기본적으로 1초마다 fsync함
Redis 클러스터는 다수 노드에 복제된 후에만 ack를 반환함
standalone Redis에서도 fsync 후 ack 설정이 가능하지만, OS 버퍼링 때문에 완전 보장은 어려움
결국 ack의 의미를 정확히 이해하는 게 중요함
대부분의 시스템은 속도와 내구성의 절충을 택함
안전한 기본값만 고집하면 성능이 크게 떨어지고, 사용자가 직접 튜닝해야 하는 부담이 커짐
예를 들어 Postgres의 기본 격리 수준도 약해서 race condition이 발생할 수 있음
참고: Hermitage 테스트 글
fsync는 극단적인 선택지밖에 없는 게 문제임
SSD 시대에는 group-commit 같은 중간 단계가 사라졌고, 이제는 syscall 전환 비용이 병목임
2분은 너무 긴 주기임 (fdatasync vs fsync 차이도 고려해야 함)
솔직히 예상은 했지만, 이렇게까지 심각할 줄은 몰랐음
그냥 Redpanda를 쓰는 게 나을 듯함
NATS의 fsync 성능 경고를 개선할 수 있을지 궁금했음
일정 주기로 배치 플러시(batch flush) 를 하면 지연은 늘겠지만 처리량은 유지할 수 있지 않을까 생각함
고정된 주기가 아니라, fsync가 진행 중일 때 쓰기 요청을 큐잉하고 다음 배치에 함께 처리하면 됨
이는 Paxos 라운드를 묶는 방식과 유사함
한 라운드가 끝나면 바로 다음 배치를 시작하는 식으로 처리해야 함
Hacker News 의견
이제는 AI가 프로젝트 문서를 읽고 데이터 손실 가능성을 마케팅 문구만으로 예측할 수 있을지도 궁금해짐
사람들은 늘 “이론은 과대평가됐다”거나 “학교 교육보다 해킹이 낫다”고 말하지만, 결국 문서화된 문제 공간에서 스스로 발목을 잡는 꼴이 됨
미묘한 스케일링 디테일도 잘 처리했음
하지만 persistence는 써본 적 없고, 이렇게까지 취약할 줄은 몰랐음
단일 비트 파일 손상에도 취약하다니 당황스러움
참고하기에 아주 좋은 자료임 → Jepsen Glossary
최근 aphyr.com을 발견했는데, 통찰이 많을 것 같아 기대 중임
이후 jepsen.io는 전문 프로젝트로 발전했고, 약 10년 전부터 본격적으로 운영하기 시작했음
벤치마크 성능을 높이려는 이유인가? 작은 클러스터에서는 이런 설정이 문제의 원인이 되곤 함
많은 애플리케이션은 완전한 내구성을 요구하지 않기 때문에 lazy fsync가 유용할 수 있음
다만 기본값으로 두는 건 논란의 여지가 있음
TCP corking처럼 묶음 처리(batch) 로 해결할 수 있을 것 같음
lazy fsync로 인한 실패는 대부분의 노드에서 동시에 일어나지 않기 때문임
장점: 객체 스토리지 수준의 내구성을 가진 무제한 스트림 지원
단점: 아직 consumer group 기능이 없음
여러 노드가 동시에 장애를 겪으면 커밋된 데이터 손실이 발생할 수 있음
MongoDB 초창기 시절의 “웹 스케일” 마케팅이 떠오름
기본값은 항상 가장 안전한 옵션이어야 한다고 생각함
그 점이 오히려 좋았고, 그 위에 시스템을 설계할 수 있었음
2018년에 사용했을 때는 성능도 좋고 관리도 쉬웠음
예를 들어 PostgreSQL의 기본 트랜잭션 격리 수준은 read committed임
Redis도 기본적으로 1초마다 fsync함
standalone Redis에서도 fsync 후 ack 설정이 가능하지만, OS 버퍼링 때문에 완전 보장은 어려움
결국 ack의 의미를 정확히 이해하는 게 중요함
안전한 기본값만 고집하면 성능이 크게 떨어지고, 사용자가 직접 튜닝해야 하는 부담이 커짐
예를 들어 Postgres의 기본 격리 수준도 약해서 race condition이 발생할 수 있음
참고: Hermitage 테스트 글
SSD 시대에는 group-commit 같은 중간 단계가 사라졌고, 이제는 syscall 전환 비용이 병목임
2분은 너무 긴 주기임 (fdatasync vs fsync 차이도 고려해야 함)
그냥 Redpanda를 쓰는 게 나을 듯함
일정 주기로 배치 플러시(batch flush) 를 하면 지연은 늘겠지만 처리량은 유지할 수 있지 않을까 생각함
이는 Paxos 라운드를 묶는 방식과 유사함
한 라운드가 끝나면 바로 다음 배치를 시작하는 식으로 처리해야 함