PostgreSQL에서 ClickHouse로: 대규모 캐싱 시스템의 데이터베이스 전환 사례
하루 200만 건 이상의 쿼리와 총 200억 건의 엔트리를 처리하는 캐싱 시스템을 운영한다면, 데이터베이스 엔진 선택이 곧 시스템의 생존 여부를 결정짓는다. Momentic은 기존 PostgreSQL 기반 아키텍처가 이 규모를 감당하지 못한다는 판단 하에 컬럼 지향 데이터베이스인 ClickHouse로 전환했고, 평균 응답 지연을 약 250ms 수준으로 안정화하는 데 성공했다.
왜 PostgreSQL이 한계에 부딪혔는가
PostgreSQL은 OLTP 워크로드에 최적화된 행 지향(Row-Oriented) 데이터베이스다. 트랜잭션 단위의 읽기/쓰기, 복잡한 관계형 데이터 모델에는 강점을 보이지만, 수십억 건의 레코드를 대상으로 집계·스캔 연산을 반복적으로 수행하는 캐싱 시스템 특성과는 근본적으로 맞지 않는다.
캐싱 시스템에서 빈번하게 발생하는 패턴은 특정 컬럼 값 기반의 대량 조회와 집계다. 행 지향 구조에서는 필요한 컬럼 데이터를 얻기 위해 디스크에서 불필요한 행 전체를 읽어야 하므로 I/O 비용이 선형적으로 증가한다. 데이터 규모가 200억 건에 달하면 이 비효율은 더 이상 튜닝으로 극복할 수 없는 수준이 된다.
ClickHouse가 이 문제를 해결하는 방식
ClickHouse는 컬럼 지향(Column-Oriented) 스토리지를 기반으로 설계된 OLAP 데이터베이스다. 동일한 컬럼의 데이터를 연속된 메모리 블록에 저장하기 때문에, 특정 컬럼만 읽는 쿼리에서 I/O를 극적으로 줄일 수 있다. 또한 컬럼 단위 압축 효율이 높아 스토리지 비용도 함께 절감된다.
캐싱 시스템의 조회 쿼리는 대부분 아래와 같은 구조를 가진다.
-- 특정 키 범위 내 최신 엔트리 집계
SELECT cache_key, max(updated_at), count(*)
FROM cache_entries
WHERE namespace = 'test_results'
AND updated_at >= now() - INTERVAL 1 DAY
GROUP BY cache_key
이런 패턴에서 ClickHouse는 namespace, updated_at, cache_key 컬럼만 읽으면 되므로, 행 전체를 스캔하는 PostgreSQL 대비 처리량과 응답 시간 모두에서 유리하다. 여기에 ClickHouse의 병렬 처리 엔진과 벡터화 실행 모델이 결합되면 대규모 데이터셋에서 그 차이는 더욱 두드러진다.
실무 적용 시 고려해야 할 트레이드오프
이 전환 사례는 단순히 "ClickHouse가 더 빠르다"는 결론으로 끝나지 않는다. 실무에서는 다음 트레이드오프를 반드시 검토해야 한다.
- 트랜잭션 지원 부재: ClickHouse는 ACID 트랜잭션을 지원하지 않는다. 쓰기 정합성이 중요한 도메인이라면 별도 처리 레이어가 필요하다.
- 업데이트/삭제 비용: 행 지향 DB와 달리, 컬럼 지향 구조에서 단건 업데이트는 비효율적이다. 대부분의 쓰기를 append-only로 설계하고, 논리적 삭제(soft delete)나 버전 관리를 활용하는 것이 권장된다.
- 운영 복잡도: ClickHouse는 PostgreSQL에 비해 운영 경험이 있는 팀이 적고, 클라우드 매니지드 옵션도 아직 성숙도가 낮다. 초기 도입 시 운영 비용을 과소평가하지 않아야 한다.
- 데이터 모델 재설계 필요: 기존 정규화된 스키마를 그대로 이전하면 성능 이점을 얻기 어렵다. 비정규화된 와이드 테이블 구조로의 재설계가 선행되어야 한다.
정리
- PostgreSQL은 OLTP에 최적화되어 있어, 수십억 건 규모의 집계·스캔 중심 캐싱 워크로드에서는 구조적 한계에 도달한다.
- ClickHouse의 컬럼 지향 스토리지와 벡터화 실행은 대규모 읽기 집약적 시스템에서 응답 지연과 I/O 비용을 크게 낮춰준다.
- 전환 효과를 극대화하려면 트랜잭션 요건 제거, append-only 쓰기 패턴, 비정규화 스키마 설계가 함께 이루어져야 한다.