Sentry 에서 Clickhouse 를 택한 이유

Sentry 에서 Snuba 라는 검색 인프라를 도입한 이유를 설명한 아티클인데 이벤트 데이터베이스를 Postgres 에서 Clickhouse 로 넘어간 이유를 중점적으로 다루고 있어 Clickhouse 또는 OLAP 에 관심 있는 개발자라면 참고할 만하다.

 

Sentry 는 모바일이나 서버에서 보내는 에러를 실시간으로 수집하고 사용자에게 알럿을 보내주는 오픈소스 모니터링 툴이다. 하루에도 수백만개의 에러가 들어오곤하니 대용량 데이터의 실시간 처리가 무엇보다 중요한 서비스다.

 

Sentry 에선 원래 이벤트 데이터를 Postgres 에 넣어두고 비정규화 방식을 적용하면서 관리했다. 예를 들어 Time Seen 처럼 누적 통계 데이터 값을 읽어오는 경우 매번 count 쿼리를 치는게 아니라 Time Seen 같은 칼럼을 둬서 관리하는 방법이다. 게시물 좋아요 개수처럼 데이터가 많이 쌓이는 경우 별도의 칼럼을 둬서 count 쿼리 부하를 막을 수 있다.

 

그런데 이런 방식은 유연하지 않다. 예를 들어 Environment 라는 칼럼이 추가되는 경우 기존에 있던 기존 Times Seen 칼럼에 있던 데이터는 모두 무효한 데이터가 되고 다시 개별적으로 업데이트 해야한다. 비정규화 방식으로성능은 잡았지만 유연성까지는 잡지 못한다.

 

이런 케이스가 많아지자 Sentry 에서는 OLAP(Online Analytic Processing) 를 도입해서 비정규화 없이 빠르게 질의할 수 있는 환경을 만들고자했다. 그리고 여러가지 데이터베이스 중에서 Clickhouse 가 가장 최적의 방안인 것으로 검토했다.

그냥 Postgres 를 샤딩 해서 해결하는 방법도 있었을텐데?

 

처음 시도는 Postgres 를 스케일 하는 방안이었다고 한다. 그러나 하드웨어를 추가한다고 해결할 수 있는 수준이 아니었다. 아예 다른 차원의 인프라를 구축해야 해결 가능했던 부분이었음.

 

사실 이부분에 대해선 자세한 설명은 없다. 우리팀에 Postgres 전문가들이 많았지만 그럼에도 옮겨갈 수 밖에 없었다는 코멘트가 전부...

클릭하우스를 선택한 이유?

Impala, Druid, Pinot, BigQuery 같은 OLAP 데이터베이스를 검토했고 최종적으로 Clickhouse 를 선택했다. 자세한 이유는

1. Clickhouse 는 오픈소스다. Sentry 도 오픈소스이기 때문에 독점 솔루션을 선택하는건 적절하지 않다.
2. 주키퍼를 이용해서 관리하는 분산시스템이었기 때문에 스케일 업/다운 이 쉬웠다.
3. Row는 PK를 이용해서 정렬되고 칼럼은 개별적인 물리 파일에 저장된다. 이런 구조 덕분에 테라 바이트에서 기가 바이트로 공간 절약을 할 수 있었다
4. 작성되자마자 데이터를 리얼 타임으로 읽어올 수 있었다.
5. 쿼리 플래너에 매직은 없었다. 쿼리 패턴을 최적화 하기 위해서 clickhouse 에서 제공하는건 적지만 유효했다. 특히나 prewhere 같은 구문은 강한 필터링 조건 덕분에 대량의 데이터를 생략할 때 유용했다.

1, 3 같은 경우에는 Sentry 의 특성과 관련이 있는 부분이고 2, 4, 5 의 경우에는 범용적으로 적용되는 이유이기도 하니 주목해봐도 좋을 것 같다.