ClickStack으로 일 41TB, 200억 로그를 실시간 처리하기 - 호그와트 도서관 프로젝트

카카오페이증권 DevOps 팀은 하루 41TB, 200억 건 이상 쌓이는 로그를 기존 OpenSearch 기반 구조로는 감당할 수 없다고 판단했고, 수집부터 저장·조회까지 파이프라인 전체를 다시 설계했다. 결과적으로 ClickStack(ClickHouse + OpenTelemetry + HyperDX) 중심의 새 아키텍처를 구축해 로그 유입 지연을 수 분에서 20초 이내로 줄이고, 비용도 14.4% 수준까지 낮췄다.

핵심은 앞단을 가볍게 만들고, 중간 처리를 단순화하며, 저장소를 로그 분석에 맞는 구조로 바꾼 것이다. Filebeat → OpenTelemetry 전환으로 OTLP Proto 배치 전송을 적용해 Kafka 전송 효율을 끌어올렸고, 메시지 1건씩 보내던 방식 대비 150건 배치 전송에서 처리량이 16.5 MB/s → 300 MB/s로 뛰었다. Kafka CPU 사용량도 2배 이상 감소했다.

Kafka 구조는 서비스별로 흩어진 Topic을 300개 이상에서 18개로 통합하고, 로그를 std / nginx / transaction 같은 타입 기준으로 재편했다. 파티션은 최대 150개까지 두고, 컨슈머 수를 공약수로 맞춰 피크 시간대에 유연하게 대응하도록 설계했다. 증권업 특성상 09:00 장 시작과 23:30 해외장 시작(썸머타임 시 22:30)에 트래픽이 몰리기 때문에, 평시 자원 일부를 포기하더라도 장애 대응 여지를 확보하는 쪽을 택했다.

처리기 역시 Fluentd → OpenTelemetry Collector로 바꾸며 레벨별 풀 구조를 도입했다.

• Fast: 핵심 이벤트와 오류, 공식 2분 이내
• Common: 일반 운영 로그, 공식 15분 이내
• Debug: 디버깅용 상세 로그, 최선 노력

이렇게 분리해 피크 때는 Debug 자원을 줄이고 Fast를 확장하는 방식으로 운영했고, 서비스별로 따로 놀던 1,000개 이상의 Pod를 약 150개 수준으로 줄였다. 실제로는 로그가 발생한 뒤 20초 이내에 ClickHouse 적재가 이뤄지고, 1 Core당 처리량도 기존 Fluentd의 150건/초에서 OpenTelemetry Collector의 4,000건/초로 개선됐다.

저장소는 OpenSearch 대신 ClickHouse를 선택했다. 조회 패턴의 90% 이상이 전문 검색보다 시간 범위 + 필드 조건 검색이었고, ClickHouse는 컬럼형 저장과 ZSTD 압축, 벡터화 실행 덕분에 대용량 집계와 컬럼 조회에 강했다. 결과적으로 저장 효율은 약 90% 절감, 전체 비용은 78% 절감 효과를 얻었다.

장기 보관은 사내 아카이빙 도구인 ssak3가 IDC의 ClickHouse 데이터를 Amazon S3로 내보내고, AWS의 ClickHouse가 이를 조회하는 단방향 구조로 구성했다. 커스텀 로그는 OpenTelemetry의 Routing Connector와 logtype 추출을 활용해 43종 이상의 로그를 하나의 파이프라인에서 처리했고, 새 유형이 생겨도 Config만 수정하면 되도록 만들었다. 조회 UI는 HyperDX를 선택해 개발자들이 실시간으로 로그를 탐색할 수 있게 했다.