Hi,
I’m trying to understand the current best practice for running Grafana Mimir in a way that scales horizontally on both the read and write paths, ideally without needing frequent config changes or redeployments as usage grows.
Our current setup:
- Mimir deployed in distributed mode
- Helm chart version: 5.8.0
- Platform: AWS EKS
- Compute: AWS Fargate
- Storage: S3 for block storage
What I’ve observed so far:
On the read side, it seems like there are workable options for scaling stateless components. KEDA-based scaling looks promising, even though it still appears to be experimental. From what I can tell, that helps address most of the read-path scaling concerns.
On the write side, the distributor can be autoscaled, but the ingester seems to be the main challenge.
My understanding is that the ingester is hard to scale up and down aggressively because it is responsible for both:
- ingesting and buffering new writes, and
- serving queries for recent data.
Because of that dual role, it feels like the ingester should remain relatively stable and not churn frequently, even though in an ideal world I’d like the system to naturally scale out as tenant/customer usage increases.
What I’m trying to figure out:
- What is the current recommended architecture for a horizontally scalable Mimir deployment across both read and write paths?
- Is there a pattern for allowing Mimir to scale more naturally with growth, without requiring config redeployments whenever write load increases?
More broadly, I’m looking for guidance on the “ideal” setup for a Mimir deployment that can grow with customer usage over time, especially in Kubernetes/EKS environments.
Any guidance would be appreciated.