LLM WikiAccess-protected knowledge portal

WIKI

Grafana Loki Kafka 수집 레이어: 페타바이트 로그를 10배 빠르게 분석하는 새 아키텍처

왜 지금 봐야 하나 2026년 4월 21일 바르셀로나 GrafanaCON에서 Grafana Labs는 Grafana 13 을 발표했다. 핵심은 Loki 수집 레이어의 전면 재설계다. 로그가 오브젝트 스토리지에 저장되기 전 거치는 경로 전체가 바뀌었다. 변화는 하나의 진단에서 출발한다. 기존 Loki 분산 배포에서 로그 한 줄이 실제로 저장되는 횟수는 평균 2.3회 였다. 설계 의도는 3 way 복제였지만 수집기 ingester

경로human/study/content/database-frontier/63-grafana-loki-kafka-ingestion-petabyte-architecture.md
카테고리Study
태그#architecture #ingestion #kafka #loki #monitoring #mysql #petabyte #study

왜 지금 봐야 하나

2026년 4월 21일 바르셀로나 GrafanaCON에서 Grafana Labs는 Grafana 13을 발표했다. 핵심은 Loki 수집 레이어의 전면 재설계다. 로그가 오브젝트 스토리지에 저장되기 전 거치는 경로 전체가 바뀌었다.

변화는 하나의 진단에서 출발한다. 기존 Loki 분산 배포에서 로그 한 줄이 실제로 저장되는 횟수는 평균 2.3회였다. 설계 의도는 3-way 복제였지만 수집기(ingester) 간 타임스탬프 동기화 오차로 파일명 기반 중복 제거가 쿼리 시점까지 미뤄졌고, 그 결과 스토리지가 부풀었다.

Loki 3.x에서 도입된 Kafka 백엔드는 이 문제를 수집 경로에서 직접 해결한다. 로그가 Kafka에 한 번 기록되고 수집기가 파티션에서 소비하는 구조로 바뀌면서 유효 복제 계수(replication factor)가 1로 내려온다.

기존 아키텍처의 문제

수집 경로의 오버헤드

클라이언트
Promtail
Alloy
Fluentbit
→
Distributor
해시 기반 라우팅
3개 수집기로
동일 데이터 복제
→
Ingester × 3 (복제)
Ingester-A
Ingester-B
Ingester-C
타임스탬프 드리프트 → 중복 제거 실패 → 평균 2.3배 저장
→
스토리지
Object Store
(S3/GCS/Azure)
기존 Loki 분산 수집 경로

기존 설계에서 Distributor는 해시 기반으로 동일 로그를 3개 Ingester에 동시에 보냈다. 각 Ingester는 독립적으로 청크를 플러시하기 때문에 타임스탬프나 파일명이 미세하게 달라졌고, 쿼리 엔진이 중복을 걸러내야 했다. 중복 제거가 쿼리 시점으로 미뤄지면:

  1. 스토리지에 불필요한 데이터가 쌓인다.
  2. 쿼리가 더 많은 데이터를 읽어야 한다.
  3. Querier가 중복 제거에 CPU와 시간을 소비한다.

새 아키텍처: Kafka 수집 레이어

클라이언트
Promtail
Alloy
Fluentbit
→
Distributor
볼륨 기반
파티션 라우팅
→
Kafka (내구성 레이어)
Partition 0
Partition 1
Partition N
RF-1 (한 번만 기록)
→
Partition Ingester
파티션 소비
중복 없이
청크 생성
→
스토리지
Object Store
실 복제 계수 ≈ 1
Loki 3.x Kafka 수집 경로

변화의 핵심

내구성 책임이 Kafka로 이전된다. 기존 Ingester 3중 복제는 메모리 내 데이터가 유실되지 않도록 보장하는 역할이었다. Kafka가 그 역할을 담당하면 Ingester는 파티션 하나를 독점 소비하면서 중복 없이 청크를 만들면 된다.

볼륨 기반 파티션 배정. 기존 해시 ID 기반 Ingester 배정이 볼륨 기반 파티션 배정으로 바뀐다. 로그 볼륨이 많은 테넌트가 특정 Ingester에 집중되는 핫스팟 문제가 줄어든다.

쓰기-읽기 경로 완전 분리. Kafka가 중간 버퍼 역할을 하면서 수집 속도와 쿼리 속도가 서로 영향을 주지 않는다. 수집이 폭증해도 Querier는 이미 플러시된 청크만 읽는다.

쿼리 엔진 재설계

수집 경로만 바뀐 게 아니다. 새 쿼리 엔진도 함께 출시됐다.

요소기존신규
쿼리 플래너중앙 집중식파티션 기반 분산 플래너
쿼리 실행직렬 집계파티션 병렬 실행
데이터 로컬리티미고려파티션 → Querier 친화적 배치
집계 쿼리 성능기준최대 10배 향상
스캔 데이터량기준최대 20배 감소

쿼리 플래너가 파티션을 기준으로 작업을 나누고, 각 Querier가 담당 파티션의 데이터를 병렬로 읽는다. sum(rate({job="api"}[5m])) 같은 집계 쿼리에서 효과가 가장 크다.

배포 모드별 영향

Kafka 의존성은 분산 모드에만 해당한다.

단일 바이너리 (Single Binary)
Kafka 불필요
개발·소규모 운영
모든 컴포넌트 단일 프로세스
기존 수집 경로 유지
분산 모드 (Distributed)
Kafka 필수
페타바이트 규모 운영
컴포넌트 독립 확장
새 수집 경로 적용
Loki 배포 모드별 Kafka 요구사항

단일 바이너리 모드로 Loki를 운영 중이라면 이번 변화는 직접 관련이 없다. 분산 모드로 전환을 고려하거나 이미 운영 중인 조직이 대상이다.

트레이드오프: 단순성 vs. 성능

Loki의 초기 설계 철학은 "오브젝트 스토리지만 있으면 된다"는 최소 의존성이었다. Elasticsearch 같은 복잡한 색인 시스템 없이 레이블만으로 로그를 찾을 수 있다는 점이 Loki의 차별점이었다.

Kafka 도입은 그 약속을 깬다.

항목기존신규 (분산)
외부 의존성Object Store 만Object Store + Kafka
운영 복잡도낮음중간~높음
스토리지 효율~2.3x 오버헤드~1x (RF-1)
집계 쿼리 성능기준10x
스캔 데이터량기준20x 감소
비용 (동일 규모)기준~30% 절감

소규모 팀이 단순한 Loki를 운영한다면 이 복잡도 증가가 이득보다 클 수 있다. 초당 수백만 로그 라인을 처리하거나, 집계 쿼리로 장애를 분석하는 환경이라면 전환 검토가 합리적이다.

GCX CLI: AI 코딩 에이전트와 관측성 연동

GrafanaCON에서 Loki 아키텍처와 함께 발표된 GCX(Grafana Coding eXperience) CLI도 주목할 만하다. GitHub Copilot·Cursor 같은 AI 코딩 에이전트가 Grafana 대시보드나 알림 데이터에 직접 접근할 수 있게 해주는 CLI 도구다.

운영자 관점에서의 의미는 하나다. "코드 변경이 실제 메트릭에 어떤 영향을 미쳤는가"를 코딩 에이전트가 직접 확인할 수 있게 된다. 아직 초기 릴리스 단계이며 지원 에이전트 범위는 제한적이다.

운영 전환 체크리스트

분산 모드 Loki를 운영 중이거나 전환을 고려 중인 경우.

References