인메모리 해시테이블에 락 하나: 스페이스타임DB 2.0의 진짜 정체

데이터베이스 시장은 신규 진입자에게 특히 가혹하다. 기존 강자들과 차별화하는 것도 어렵고, 장기적인 지지를 얻는 일은 더 어렵다. 이런 상황에서 스페이스타임DB(SpacetimeDB)는 2.0 버전을 내놓으면서 다소 이색적인 방식을 택했다. 경쟁 제품을 조롱하는 밈 영상('경쟁사의 눈물'을 마시는 연출)과, 너무 좋아서 오히려 의심스러운 벤치마크를 함께 공개한 것이다. 마케팅의 자극성은 잠시 접어두더라도, 이 제품에는 짚어볼 만한 기술적 아이디어가 분명히 들어 있다.

벤치마크가 감춘 것

신규 진입자들이 흔히 하는 착각은 '최고 성능'만 있으면 시장에서 이길 수 있다는 믿음이다. 실제로는 그렇게 성공한 사례가 거의 없다. 지속 가능한 데이터베이스 사업을 만든 소수의 회사들은 그 자체로 설득력 있는 정직한 기술 작업으로 승부했다. 벤치마크가 도움이 되긴 하지만, 그 벤치마크 역시 정직하고 견고해야 한다는 조건이 붙는다.

스페이스타임DB가 공개한 수치의 근본적인 문제는 '정직하지 않다'는 점이다. 이 제품은 애초에 경쟁사들과 다른 세그먼트에 있다. 데이터베이스와 애플리케이션 서버가 한 몸으로 묶여, 사용자의 애플리케이션 코드가 데이터베이스 '안에서' 실행되는 구조다. 저장 프로시저를 개발자 경험 측면에서 크게 개선한 형태라고 볼 수 있고, 이것만으로도 충분히 매력적인 제품이 된다. 문제는 이 구조를, 쿼리마다 네트워크 요청을 주고받아야 하는 멀티리전 분산 데이터베이스와 나란히 놓고 QPS를 비교했다는 데 있다. 메모리에서 데이터를 읽는 쪽이 네트워크 너머로 읽는 쪽보다 빠른 것은 당연하다. 그것을 증명하는 벤치마크 장치를 만들었다고 해서 잠재 고객이 감동할 이유는 없다.

글쓴이는 플래닛스케일(PlanetScale) 시절 자신이 겪은 경험을 예로 든다. 디스크에 벡터 데이터를 저장하는 완전 트랜잭션형 벡터 검색을, 그래프를 메모리에 올려야 하는 pgvector와 같은 머신·같은 데이터셋에서 비교하면 '1만 배 빠르다'는 수치를 뽑아낼 수 있었다. 하지만 그것은 같은 조건처럼 보일 뿐 같은 일이 아니었다. 그래서 그들은 그 벤치마크 대신 트레이드오프와 한계를 설명하는 기술 문서를 냈고, 오히려 좋은 반응을 얻었다. 터보퍼퍼(Turbopuffer)의 문서가 '할 수 있는 것'보다 '할 수 없는 것'을 더 길게 나열하면서도 조용히 경쟁사 고객을 데려가는 것과 같은 맥락이다.

스토리지 엔진의 실체

그렇다면 이 데이터베이스는 실제로 어떻게 만들어졌는가. 스페이스타임DB의 커밋된 상태 전체는 단 하나의 읽기-쓰기 뮤텍스(Read-Write Mutex)로 감싸여 있다. 인메모리 저장소에 대한 쓰기가 선형성(linearizability)을 만족한다는 점은 좋은 소식이지만, 그 증명이 자명한 이유는 이 구조가 사실상 '락 하나를 앞에 세운 해시테이블'이기 때문이다. 모든 쓰기는 순차적으로 일어나므로 서로 충돌하지 않는다. 그러나 읽기와 쓰기도 동시에 일어날 수 없다. 사용된 뮤텍스는 parking_lot 크레이트의 RWMutex로, 최종적 공정성(eventual fairness)을 통해 읽기 요청이 결국은 락을 얻지만 최대 0.5ms까지 무작위로 지연될 수 있다.

쓰기 로직인 '리듀서(reducer)'는 웹어셈블리로 컴파일된 임의의 사용자 코드이며, 전역 락을 쥔 채 Wasmtime 런타임에서 실행된다. 이 동안에는 다른 어떤 코드도 데이터베이스를 읽거나 쓸 수 없다. 공식 문서가 리듀서에서 HTTP 요청을 할 수 없다고 못 박은 것은 당연한 귀결이다. 이번 릴리스에서 베타로 추가된 '프로시저(Procedure)'는 HTTP 등 비싼 작업을 허용하지만, 그 안에서 트랜잭션을 열면 다시 전역 뮤텍스를 잡기 때문에 빨리 커밋하지 않으면 시스템 전체가 멈춘다. 읽기 전용인 '뷰(View)'는 리더 락을 잡아 서로 동시에 실행될 수 있지만, 뷰가 도는 동안 쓰기는 불가능하다.

지속성과 남는 숙제

단일 뮤텍스 설계의 필연적 결과는 트랜잭션 임계 구간에서 최소한의 일만 해야 한다는 것이다. HTTP 요청은 물론이고, 트랜잭션을 디스크에 동기적으로 남기는 일조차 임계 구간 안에서 할 수 없다. 이 데이터베이스는 WAL(Write Ahead Log)로 뒷받침되지만, WAL은 쓰기 트랜잭션의 일부로 디스크에 커밋되지 않고 기본 50ms 주기로 비동기 플러시된다. 완전한 일관성이 필요하면 withConfirmedReads 플래그로 디스크에 반영된 데이터만 읽게 할 수 있는데, 이는 최대 50ms까지 서버에서 대기하는 방식이라 요청당 지연으로는 결코 짧지 않다. 결국 이 제품은 '대체로 휘발성인 데이터'를 전제로, 평균적인 쿼리는 그런 강한 보장을 필요로 하지 않는다는 가정 위에 서 있다.

이 모든 그림은 2011년 무렵의 몽고DB를 떠올리게 한다. 인상적인 벤치마크와 부실한 스토리지 엔진으로 출발해 인터넷에서 조롱받았지만, 이후 와이어드타이거를 인수해 제대로 된 엔진을 갖추고 15년 뒤 진지한 데이터베이스 회사로 자리 잡았다. 다만 초창기의 나쁜 평판은 여전히 일부 개발자들 사이에 남아 있다. 한국의 실무자 입장에서 얻을 교훈은 분명하다. 락 하나를 앞세운 해시테이블로 출발하는 것 자체는 몽고DB가 증명했듯 사업적으로 가능한 선택이다. 그러나 제품이 관심을 끌기 시작하면 기술 부채와 평판 부채를 서둘러 갚아야 하며, 레이저 광선과 '눈물 병' 같은 요란한 마케팅은 그 회수 과정을 훨씬 더 어렵게 만든다.