데이터베이스 벤치마크를 보다 보면 '초당 수십만 건 쓰기 처리'라는 화려한 숫자를 자주 만나게 되는데요. 최근 한 데이터베이스 엔지니어가 이 숫자들의 이면을 꿰뚫는 글을 올렸어요. 핵심 주장은 한 문장이에요. 빠른 쓰기는 일을 없앤 게 아니라, 일을 다른 곳이나 다른 시간으로 옮겼을 뿐이라는 것. 당연한 말 같지만, 이 관점 하나로 데이터베이스의 온갖 설계와 운영 사고를 꿰어서 설명할 수 있거든요.
쓰기가 빨라지는 원리부터 볼게요
데이터베이스가 쓰기를 빠르게 처리하는 방법은 결국 하나예요. 지금 당장 해야 할 일을 최소한으로 줄이고, 나머지는 미루는 거죠. 대표적인 게 WAL(Write-Ahead Log, 미리 쓰기 로그)이에요. 데이터를 디스크의 제자리에 찾아가서 고치는 대신, 로그 파일 끝에 '이런 변경이 있었다'고 순서대로 적기만 하는 거예요. 디스크는 여기저기 흩어진 위치에 쓰는 것보다 한 곳에 이어 쓰는 게 훨씬 빠르니까, 쓰기 응답이 순식간에 끝나요. 그런데 로그에만 적어둔 변경은 언젠가 실제 데이터 파일에 반영돼야 하잖아요? 그 일이 체크포인트라는 이름으로 뒤로 미뤄진 거예요. 그래서 평소엔 쌩쌩하던 DB가 체크포인트 순간에 디스크 쓰기가 몰리면서 응답 시간이 튀는 현상이 생기는 거죠.
PostgreSQL의 MVCC도 같은 구조예요. MVCC가 뭐냐면, 행을 수정할 때 기존 데이터를 덮어쓰지 않고 새 버전을 하나 더 만들어두는 방식이에요. 덕분에 읽는 쪽과 쓰는 쪽이 서로를 기다리지 않아도 되니 처리량이 올라가요. 대신 옛 버전, 이른바 '죽은 튜플'이 계속 쌓이고, 이걸 청소하는 VACUUM이라는 작업이 뒤로 미뤄져요. 오토바큠이 제때 못 따라가면 테이블이 비대해지고 디스크가 차오르는 사고로 이어지는데, Postgres를 운영하다 한 번쯤 겪는 단골 장애거든요.
RocksDB나 Cassandra가 쓰는 LSM 트리는 이 철학을 극단까지 밀어붙인 구조예요. 쓰기를 일단 메모리에 모았다가 정렬된 파일로 순차적으로 내려쓰니까 쓰기 속도가 정말 빨라요. 하지만 그렇게 쌓인 파일들을 백그라운드에서 계속 합치고 다시 쓰는 컴팩션이 필수인데, 이 과정에서 같은 데이터가 여러 번 다시 쓰여요. 이걸 쓰기 증폭이라고 불러요. 게다가 읽을 때는 여러 파일을 뒤져야 하니 읽기 비용도 커지죠. 쓰기에서 아낀 비용이 컴팩션과 읽기 쪽으로 고스란히 이사 간 거예요. 비동기 복제도 마찬가지고요. 리플리카에 전달되는 걸 기다리지 않으니 쓰기는 빠르지만, 그 대가는 복제 지연이라는 형태로 읽는 쪽이 치러요.
그래서 뭘 배워야 하냐면
이 관점이 실무에서 중요한 이유는, 미뤄진 일은 반드시 청구서로 돌아오기 때문이에요. 벤치마크는 보통 짧은 시간 동안 쓰기만 몰아치니까, 미뤄진 작업이 아직 시작되기 전의 숫자만 보여주거든요. 그런데 실제 서비스는 몇 달을 연속으로 돌잖아요. 컴팩션과 바큠과 체크포인트가 평상시 부하와 겹치는 정상 상태(steady state)에서의 성능이 진짜 성능이에요. 그래서 부하 테스트를 할 때는 짧게 최대치를 찍는 게 아니라, 백그라운드 작업이 돌 만큼 충분히 오래 돌리면서 응답 시간의 상위 백분위(p99)를 봐야 해요. 새 데이터베이스를 검토할 때도 '쓰기가 빠르다'는 말을 들으면 반사적으로 이렇게 물어보세요. 그 미뤄진 일은 어디로 갔고, 언제, 누가 그 비용을 치르나요?
정리하면, 데이터베이스 설계는 일을 없애는 기술이 아니라 일을 언제 어디서 치를지 배치하는 기술이라는 이야기예요. 여러분도 새벽에 터진 컴팩션 폭풍이나 멈춘 오토바큠 때문에 고생해본 적 있으세요? 미뤄진 청구서에 당했던 경험을 나눠주세요.
🔗 출처: Hacker News