[26.10.26] ClickHouse 통합 전 분석과 복구 검토하기

ClickHouse를 기반으로 통계 데이터를 통합하는 작업을 주도하고 있습니다. 지난 낙서장에서는 대량 데이터 적재와 조회 부하 개선을 정리했습니다.

리뷰에서는 세 가지 질문을 받았습니다.

Splunk와 비교했을 때 ClickHouse의 단점은 무엇인가?
서로 다른 데이터를 조합해 분석할 수 있는가?
4TB가 넘는 원본을 어디에 보관하고 어떻게 복구할 것인가?

지금까지는 한 유형의 데이터를 적재하고 조회하는 데 집중했습니다. 이번에는 그 결과만으로 설명하지 못한 부분을 정리하고, 추가로 검증할 범위를 구체화하려고 합니다.

Splunk와 비교했을 때 ClickHouse의 단점은 무엇인가

ClickHouse의 조회를 개선한 경험은 있었지만, 그것만으로 Splunk를 어느 범위까지 대체할 수 있는지 설명하기는 부족했습니다. 먼저 두 제품이 데이터를 저장하고 읽는 방식부터 비교했습니다.

저장 구조에 따라 조회할 때 읽는 대상이 달라집니다

Splunk의 내부 구성	ClickHouse의 내부 구성

비교 항목	Splunk	ClickHouse
저장 방식	시간 범위별 Bucket에 압축 원문 `rawdata`와 Inverted Index인 `tsidx` 저장.	Sorting Key로 정렬한 데이터를 Column 단위로 압축해 Data Part에 저장.
읽는 범위	`tsidx`로 후보 이벤트를 찾고 해당 원문을 읽음	Sparse Primary Index로 여러 행을 묶은 Granule을 추린 뒤 필요한 Column만 읽음.
새 필드 추출	보관한 원문에 검색 시점의 필드 추출 규칙 적용	보관한 원문에서 SQL로 추출. 반복 조회는 Column과 Index 설계 검토
반복 집계	`stats`로 집계 `tstats`로 Index의 필드나 가속된 데이터 모델 집계	Vectorized Execution으로 필요한 Column을 읽어 집계 MV에 미리 계산한 결과 저장

ClickHouse로 통합할 때 보완할 부분

이 차이를 바탕으로 통합 과정에서 확인할 부분을 나눴습니다.

원문 검색: Sorting Key에 맞는 조건은 읽는 범위를 줄일 수 있지만, 임의의 검색어를 찾는 작업은 Sparse Primary Index만으로 최적화하기 어렵습니다. 필요한 검색 조건으로 Text Index 적용 여부를 검증하려고 합니다.
기존 조회 이전: Splunk의 SPL과 필드 추출 설정을 ClickHouse에서 그대로 실행할 수는 없습니다. 실제로 사용하는 조회와 추출 규칙을 SQL이나 수집 단계의 변환으로 옮겨야 합니다.
통계 기준 변경: 집계에 남기지 않은 정보는 집계 결과만으로 복원할 수 없습니다. Incremental MV도 원본 수정이나 JOIN 대상의 변경을 기존 집계에 자동 반영하지 않으므로, 원본을 보관하고 필요한 구간을 다시 집계할 경로가 필요합니다.

그래도 ClickHouse를 검토하는 이유

이번 통합에서는 앱, 버전, OS, 기간처럼 정해진 기준으로 대량 이벤트를 반복 집계합니다. 이 조회 패턴에는 다음 장점이 맞는다고 봤습니다.

필요한 데이터만 읽기: 조회에 필요한 Column만 읽어 처리할 데이터의 양을 줄일 수 있습니다.
반복 계산 줄이기: MV에 미리 집계한 결과를 저장해, 대시보드를 조회할 때 같은 계산을 반복하는 부담을 줄일 수 있습니다.
조회 패턴에 맞춘 최적화: 지난 조회 개선에서는 같은 13개월을 쿼리당 2스레드, 캐시 OFF 조건으로 비교했을 때 월 집계로 읽는 행 수가 319만에서 44.5만으로 줄었습니다. 읽는 양을 줄여본 경험을 이번 통합에도 적용하려고 합니다. 이전 조회 개선 기록

다만 이 결과는 ClickHouse 내부의 개선 전후 비교입니다. Splunk와의 성능과 운영 비용은 양쪽 모두 집계 최적화를 적용한 동일 조건에서 따로 비교할 필요가 있습니다.

서로 다른 데이터를 조합해 분석할 수 있는가

이 질문을 돌아보니 지금까지는 한 유형의 데이터만 테스트했고, 다른 데이터와의 조합은 검증하지 않았습니다. JOIN의 지원 여부를 설명하는 데서 그치지 않고, 추가 데이터를 적재해 실제 통계가 맞는지 확인하려고 합니다.

질문은 세 가지로 나눴습니다.

같은 ClickHouse의 서로 다른 테이블을 JOIN할 수 있는가?
서로 다른 ClickHouse 서버의 데이터를 JOIN할 수 있는가?
ClickHouse A와 B의 데이터를 Rill에서 조합해 하나의 지표를 만들 수 있는가?

아래 세 방식 모두 실제 조합 데이터로 검증하기 전입니다. 적재와 갱신 비용, 조회 성능을 함께 비교하려고 합니다.

같은 ClickHouse에서 JOIN	다른 ClickHouse를 읽어 JOIN	Rill에서 A·B 조합

첫 두 방식에서 Rill은 ClickHouse의 조회 결과를 받아 표시합니다. 세 번째 방식은 A·B의 필요한 데이터를 Rill 서버의 DuckDB에 따로 적재하고, DuckDB에서 JOIN합니다.

같은 ClickHouse에 모으는 방식과 DuckDB에 모으는 방식은 모두 데이터 적재와 갱신이 필요합니다. 차이는 이를 공유 통계 데이터로 운영할지, Rill에서 사용할 분석 데이터로 따로 운영할지에 있습니다. DuckDB 방식에서도 A·B에서 데이터를 읽는 부하는 적재와 갱신 시 발생합니다.

비교 항목	같은 ClickHouse에서 JOIN	다른 ClickHouse를 읽어 JOIN	Rill에서 A·B 조합
JOIN 실행	적재한 ClickHouse에서 두 테이블 조합	B의 조회 결과를 받아 A에서 조합	A·B에서 가져온 데이터를 Rill 서버의 DuckDB에서 조합
장점	모은 데이터를 여러 지표와 조회에서 재사용 Rill은 DuckDB에 다시 적재하지 않고 ClickHouse 결과 조회	한 서버로 옮겨 적재하기 전에 조합 가능	A·B에 JOIN용 구성을 추가하지 않고 Rill 쪽 복제본에서 분석 분석 범위별 변환과 갱신을 Rill 프로젝트에서 관리
한계	JOIN 대상 데이터의 집중 적재와 동기화, 저장 공간 필요 조회 시 ClickHouse의 JOIN 연산과 메모리 사용량 발생	B의 응답과 결과 전송량이 조회에 영향 A에서 JOIN 연산과 메모리 사용량 발생	데이터 복제와 갱신 경로를 별도로 운영 적재와 JOIN이 Rill 서버의 CPU, 메모리, 저장 공간을 사용
선택 기준	여러 통계를 지속적으로 통합하고 같은 데이터를 재사용하려는 경우	A·B의 저장 위치를 유지하면서 필요한 데이터를 조합하려는 경우	Column과 기간을 좁힌 데이터를 Rill 분석용으로 독립 관리하려는 경우
보완점	필요한 Column과 기간으로 적재 범위 제한 공통 키 중복 확인과 반복 집계의 사전 계산 검토	필요한 Column과 기간으로 전송량 제한 반복 조회는 기준 데이터의 로컬 적재 검토	A·B 데이터 수집과 갱신 경로 검증 데이터 규모와 대시보드 부하를 함께 고려해 Rill 서버 자원 확인

Rill의 Metrics SQL은 서로 다른 Metrics View 간 JOIN을 지원하지 않습니다. 따라서 A와 B를 각각 조회할 수 있다는 것과, 두 데이터를 조합한 지표를 만들 수 있다는 것은 구분해서 확인하려고 합니다.

이번 통합은 여러 통계를 함께 조회하는 것이 목적이므로, 같은 ClickHouse에 모았을 때의 데이터 재사용과 적재 비용을 먼저 확인하려고 합니다. 공통 키가 1:1 또는 1:N일 때 집계가 중복되는지도 검증할 예정입니다. 이후 원격 JOIN의 조회 시간과 전송량을 비교하고, DuckDB 방식은 분석 범위를 좁힌 데이터로 Rill 서버의 자원과 갱신 부담까지 확인하려고 합니다.

원본을 어디에 보관하고 어떻게 복구할 것인가

원본 데이터는 4TB가 넘습니다. 리뷰를 보완하면서, 정제 오류나 통계 기준 변경에 대응하려면 원본을 남기는 것뿐 아니라 다시 읽어 처리할 방법까지 정해야 한다고 봤습니다.

처음에는 디스크를 연도별로 순환하는 방식을 제안했습니다. 이후 디스크 배치와 교체에 드는 관리를 줄일 수 있는 대안으로 S3 보관도 검토하게 됐습니다.

원본 적재부터 백업 전환과 디스크 재사용까지	원본을 S3로 보관하는 안

비교 항목	디스크 로테이션	S3 원본 보관
보관 기준	당해 연도와 전년도는 바로 읽을 수 있도록 유지 이전 원본은 보관 기한까지 백업	원본을 로컬 디스크에 남기지 않고 S3에 보관 2026년: S3 Standard-IA에서 복원 대기 없이 읽기 2025년: S3 Glacier Deep Archive에서 복원 후 읽기
장점	기존 파일 수집 경로 활용 연결된 디스크의 원본은 복원 대기 없이 재처리	물리 디스크의 배치와 교체 작업을 줄임 Lifecycle로 Storage Class 전환과 보관 기한 삭제 관리
한계	보관량에 맞는 디스크 용량 확보 필요 백업 디스크의 보관과 교체를 직접 관리	파일 수집을 원본 직접 전송으로 바꾸는 작업 필요 Deep Archive는 복원 대기 발생. 통상 Standard Retrieval 12시간 이내, Bulk Retrieval 48시간 이내이며 전송과 재처리는 별도
보완점	연도별 보관 위치와 교체 이력 관리 백업 원본을 Vector에 재투입해 복구 검증	원본 직접 전송과 S3 보관 경로 검증 복원 요청부터 Vector 재투입까지 실제 소요 시간 확인
선택 기준	당해 연도와 전년도 원본을 바로 다시 읽어야 하고 디스크 관리 작업을 수행할 수 있는 경우	물리 디스크 관리를 줄이면서 오래된 원본의 복원 대기를 허용할 수 있는 경우

두 방식 중 어느 쪽을 택할지는 같은 보관 기간과 허용 복구 시간에서의 총비용을 비교해 결정하려고 합니다.

디스크: 원본용과 백업용 디스크의 구매와 교체, 관리에 드는 시간과 비용
S3: 저장량과 Storage Class에 따른 보관 요금, 요청과 복원, 전송 요금