입사한 지 3년이 넘었지만 통계 시스템은 여전히 여러 경로로 나뉘어 있습니다. 노후한 구성 요소를 교체할 때마다 기능별로 전환해 왔고, 전체 통합까지 이어지지는 않았습니다.
최근에는 전체 통계를 Splunk로 옮기기로 결정됐습니다. 저는 ClickHouse PoC로 더 적은 리소스에서의 운영 가능성을 확인했고, 현재 전체 통계 전환을 맡고 있습니다.
통계마다 다른 수집과 조회 경로 확인하기
- 제품 실행 통계: 수집 서버의 원본 로그 파일을 크론잡으로 S3에 전송하고 AWS 서비스로 집계합니다.
- 기능 실행 통계: Hadoop과 스크립트로 집계합니다.
- 모바일 통계: GA에서 Splunk로 전달합니다.
제품과 기능 통계는 같은 BI DB에 저장하지만, 수집 설정과 집계 작업, 조회 화면은 경로마다 따로 관리합니다. 이번에는 모바일과 기존 BI 조회까지 함께 옮겨 관리 지점을 줄이려고 합니다.
제품과 기능, 모바일 통계를 같은 ClickHouse에서 조회하기
수집부터 집계와 조회까지 공통화하려고 합니다.
- 제품과 기능 통계: Vector로 로그 파일을 읽어 ClickHouse에 적재하고 Rill에서 조회합니다.
- 모바일 통계: 우선 GA 데이터를 같은 ClickHouse로 가져와 조회하고, 이후 수집 방식도 공통화합니다.
다시 집계할 데이터를 남기기 위한 원문 보관 위치 비교하기
전체 통계로 확대하면서 PoC처럼 원문까지 보관할지 고민이 생겼습니다.
현재는 raw_logs에 원문을 적재하고, ClickHouse에서 events로 정제합니다. events에서 events_daily와 events_monthly로 각각 MV를 통해 집계를 쌓고 있습니다.
800GB 적재 기준으로 확인한 테이블별 상태입니다.
| 테이블 | 행 수 | 압축 크기 | 행당 압축 크기 |
|---|---|---|---|
raw_logs (원문) | 44.9억 | 114.6GiB | 27.4B |
events (정제 결과) | 44.9억 | 76.6GiB | 18.3B |
events_daily | 320만 | 4.6GiB | — |
events_monthly | 46만 | 1.1GiB | — |
정제 전후 행 수는 같고, events의 압축 크기는 원본 800GB의 10% 수준이었습니다.
연간 원본 로그 3.6TB(3,600GB)는 측정량 800GB의 4.5배입니다. 다음 조건으로 연간 압축 크기를 환산했습니다.
- 데이터 구성과 집계 비율은 측정 때와 같다고 가정합니다.
- 각 테이블에 1년분을 모두 보관합니다.
| 보관 방식 | 연간 예상 압축 크기 |
|---|---|
raw_logs와 events, 일별 집계, 월별 집계 보관 | 886.1GiB |
events와 일별 집계, 월별 집계만 보관 | 370.4GiB |
raw_logs를 보관하면 연간 515.7GiB가 추가됩니다. 이 저장 공간과 재처리할 원문을 확보하는 비용을 함께 비교해야 합니다.
저장 비용과 복구 방법 비교하기
왼쪽은 ClickHouse에서 정제하고, 오른쪽은 Vector에서 정제한 데이터를 events에 바로 적재하는 방식입니다. 집계는 두 방식 모두 ClickHouse의 MV에서 수행합니다.
| ClickHouse에서 정제 | Vector에서 정제 |
|---|---|
 |  |
ClickHouse의 원문 보관 기간에 따른 차이입니다.
| 보관 방식 | 이점 | 단점 |
|---|---|---|
| 1년 보관 | 1년 내 오류 조사와 복구에 DB 원문 바로 활용 | 원문 저장 공간 약 515.7GiB 추가 |
| 단기 보관 | 최근 오류 조사와 복구에 DB 원문 활용, 1년 보관보다 저장량 감소 | 기간이 지난 오류 조사와 복구에는 원문 재전송 필요 |
| 미보관 | ClickHouse의 원문 저장 공간 불필요 | 오류 조사와 복구마다 원문 재전송 필요 |
보관 기간은 오류 발견 시점과 원문 재전송 시간을 기준으로 정하려고 합니다.
재처리 부하를 확인하고 보관 정책 정하기
파싱 오류나 추출 필드 변경으로 과거 구간을 다시 정제할 때는, 기존 수집과 조회가 받는 영향도 확인해야 합니다.
| ClickHouse에서 재정제 | Vector에서 재정제 |
|---|---|
 |  |
| 정제 수행 위치 | 재처리 시 추가 작업 | 운영 영향 |
|---|---|---|
| ClickHouse | 보관된 원문 읽기와 재정제 | 신규 적재와 Rill 조회가 CPU, 메모리, 디스크를 경쟁 |
| 수집 서버의 Vector | 대상 기간의 원문 확보와 파일 읽기, 재정제와 재전송 | 수집 서버의 CPU, 디스크와 네트워크를 함께 사용해 실시간 수집이 지연될 수 있음 |
Vector로 정제 CPU 부담을 옮겨도 ClickHouse의 정렬과 압축, 결과 적재와 병합 작업은 남습니다.
같은 과거 구간을 실시간 수집과 Rill 조회가 실행 중인 상태에서 재처리해 다음을 비교하려고 합니다.
- 운영 영향: 서버별 CPU와 메모리, 정상 운영 대비 수집 반영 지연과 Rill 조회 p95의 증가
- 복구 시간: 원문 확보부터 재처리와 결과 검증까지 걸리는 시간, 재처리 후 병합 적체가 해소되는 시간
- 정확성: 오류 구간을 재실행했을 때 통계가 중복되거나 누락되는지 여부
수집과 조회의 지연 기준을 지키는 범위에서 재처리량과 복구 시간을 비교하겠습니다. 이 결과와 원문 확보 가능 범위를 기준으로 정제 위치, 원문을 보관할 위치와 기간, 통계별 전환 순서를 정하려고 합니다.