당근에서 Loki 1년간 운영기 (SRE 밋업 4회)

주요 구간

• 02:00 Loki 쓰기·읽기 경로와 닥터 대시보드
• 13:00 목표와 rate limit 시행착오
• 16:00 10초 단위 로그 유실
• 21:00 CPU limit 제거
• 24:00 조회 속도 개선
• 30:00 장단점과 남은 과제

출발점과 목표

1년 전 당근은 인력이 부족해 안정성을 우선하며 Loki에 rate limit과 쿼리 병렬 제한을 걸었습니다. 그 결과 로그 일부가 버려지고 조회가 느렸습니다. 발표자는 쓰기·읽기 경로를 공부하고 Loki 전용 닥터 대시보드를 만든 뒤 개선 목표를 세웠습니다. 리소스 비용을 늘리지 않으면서 로그를 다 받고 조회를 빠르게 하는 것이 목표입니다.

적재 병목과 조회 대기 줄이기

대시보드에서 확인한 rate limit 지점은 수집기에서 Loki로, Loki에서 S3로 보내는 두 구간이었습니다. chunk 크기와 전송 간격을 늘리자 에러는 줄었지만, ingester 메모리가 불안정해지고 조회가 느려져 롤백했습니다.

남은 로그 유실은 로그가 많은 서비스에서 10초 간격으로 간헐적으로 발생했고 새벽에는 없었습니다. 슬라이드에 제시한 근거는 해당 서비스의 파일이 10초마다 로테이션되며, 누락 구간에는 수집기가 파일을 읽은 기록이 없다는 점입니다. 원인은 수집기(Alloy)의 파일 읽기 속도였으며, 배치 크기를 키우고 새 파일 감지 시간을 줄여 대응했습니다.

Loki의 응답 속도를 높이기 위해 CPU limit도 제거했습니다. 평균 CPU 사용률은 35%였지만 CFS 스로틀링은 심했습니다. 발표자는 Go가 CPU limit에 맞춰 동시 실행 스레드를 정하는 특성까지 겹친 결과라고 설명합니다.

조회 시간을 queue, index, store, exec로 나눠 보니 큐 대기와 필터링 실행이 대부분을 차지했습니다. 동시성·병렬성 옵션은 값을 높이면 querier 메모리가 넘치고 낮추면 큐 대기가 늘어났습니다. CPU limit 제거 뒤 이 값을 반복 조정하고, 특정 querier에 몰리던 샤드는 query-scheduler로 고르게 나눴습니다.

결과

• 로그 유실 문제 해결
• 느린 로그 조회 기준 평균 조회 속도 50% 개선(슬라이드)
• 매일 울리던 slow query 알림이 사흘에 한두 번으로 감소(자막 기준)

운영상 한계와 수치 근거

발표자는 압축 비용 효율과 최근 로그를 ingester 메모리에 두는 구조를 Loki의 장점으로 꼽았습니다. 라벨 인덱싱 때문에 조회가 느리고 LogQL의 진입 장벽이 있다는 점은 단점으로 들었습니다. Grafana Explore의 조회 한도로 대량 다운로드가 불편해, 비동기 다운로드와 전용 조회 화면을 고민 중이라고 합니다.

아래 표에서 슬라이드 본문에 글자로 나오지 않는 수치는 자막에 의존하며, “자막 기준"으로 표시했습니다.