Grafana Mimir에 Kafka를 도입하기 전 미리 알았다면

문제 상황

• Grafana Mimir classic 구조에서 distributor와 ingester 사이에 durable buffer가 없어, ingester 장애와 처리 지연이 곧바로 backpressure, 429, metrics 유실로 이어질 수 있는 상황
• Loki와 유사하게 downstream 지연을 충분히 흡수하지 못하는 운영 한계

원인 분석

• RF=3 fan-out 구조로 ingester 부담과 write quorum 실패 가능성이 큼
• Kafka를 일반 consumer group처럼 쓰지 않고, ingester ordinal과 partition number를 1:1로 묶는 특이한 운영 모델
• 새 pod 이름으로 consumer group이 바뀌면 committed offset이 없어 backfill storm이 발생할 수 있음

해결 방법

• Mimir 3.0의 ingest-storage architecture로 전환해 Kafka를 write path의 durable buffer로 사용
• partition 수, zone-aware replica 수, StatefulSet ordinal을 맞춰 partition ownership을 명시적으로 운영
• scale-in 시 /ingester/prepare-partition-downscale, lag, drain 상태를 확인하며 순차적으로 축소

성능/운영 포인트

• 같은 트래픽에서 ingester CPU와 memory 사용량이 크게 감소
• Kafka broker BytesIn/Out, fetch throttling, consumer lag, read consistency 지표가 핵심 운영 대상
• retention, replication factor, message size, startup position, rollout-operator 동작을 사전에 점검 필요