1. 왜 Grafana Cloud 비용이 갑자기 아프게 느껴질까
2. Grafana Cloud 가격 구조를 쉽게 풀어보면
3. 자체 호스팅 ROI, 저는 이렇게 계산합니다
4. 그래서 저는 Prometheus + Grafana 조합으로 다시 갔습니다
5. 실전 구현: Docker Compose로 10분 안에 올리기
5-1. 디렉터리 구조
5-2. docker-compose.yaml
5-3. prometheus.yml
5-4. Grafana 데이터소스 프로비저닝
5-5. 실행
6. 운영하면서 꼭 챙겨야 하는 비용 절감 포인트
7. ⚠️ 실제로 많이 겪는 트러블슈팅
8. 검증 결과: 무엇이 좋아졌고 무엇을 잃었나
9. 정리와 FAQ
자주 묻는 질문
참고한 공식 문서

[모니터링] Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유

Grafana Cloud 비용이 예전보다 훨씬 민감하게 느껴지기 시작하면, 그때부터는 단순히 '관리형이라 편하다'만으로 설명이 안 되더라고요. 저도 홈랩과 소규모 운영 환경에서 Grafana Cloud를 꽤 편하게 썼었는데, 메트릭(Metrics, 시계열 지표)과 로그(Logs, 시스템/애플리케이션 기록)가 늘어나면서 청구 구조를 다시 뜯어보게 됐습니다. 특히 Grafana Cloud 비용은 사용량이 조금만 늘어도 체감상 훅 올라갈 수 있어서, 모니터링 비용을 어디까지 SaaS로 맡길지 진지하게 다시 보게 되거든요.

이번 글은 '무조건 자체 호스팅이 낫다'는 이야기가 아닙니다. Grafana Cloud 공식 가격 구조를 기준으로 왜 비용이 커지는지, 그리고 어떤 조건에서 자체 호스팅 ROI(Return on Investment, 투자 대비 효과)가 맞아떨어지는지 제가 정리한 기준을 공유해보려는 글입니다. 중간에 실제로 바로 올려볼 수 있는 Prometheus(프로메테우스, 메트릭 수집기) + Grafana(그라파나, 시각화 도구) 구성 예시도 넣어둘게요.

Grafana Cloud와 자체 Prometheus 구성을 비용 관점에서 비교한 전체 아키텍처 예시입니다.

1. 왜 Grafana Cloud 비용이 갑자기 아프게 느껴질까

처음엔 진짜 편합니다. 가입하고, 에이전트 붙이고, 대시보드 몇 개 열면 끝이거든요. 저도 처음엔 이게 뭔가 싶을 정도로 진입 장벽이 낮아서 아주 만족했었습니다. 근데 여기서 중요한 포인트가 있습니다. 편한 구조일수록 과금 단위가 눈에 잘 안 들어온다는 점입니다.

Grafana 공식 가격 페이지를 보면, Pro 플랜은 월 플랫폼 요금(platform fee)에 더해 사용량 기반 과금이 붙습니다. 메트릭은 active series(액티브 시리즈, 실제로 수집 중인 시계열 개수) 기준이고, 로그와 트레이스는 process / write / retain처럼 단계별 과금 구조가 걸려 있더라고요. 쉽게 말해, 데이터를 많이 넣는 환경에서는 '조금 늘었네'라고 생각했는데 청구서는 전혀 조금이 아닐 수 있다는 뜻입니다.

메트릭: active series가 늘면 비용이 바로 반응합니다.
로그: 수집량뿐 아니라 처리와 저장이 분리돼 보여서 체감이 더 큽니다.
트레이스: 장애 분석엔 좋지만, 운영 습관 없이 켜두면 금방 비싸집니다.
보존 기간(retention, 데이터 보관 기간): 길어질수록 관리형 서비스의 장점은 커지지만 비용도 같이 올라갑니다.

이런 구조 때문에 클라우드 가격이 '갑자기 2배 오른 느낌'으로 다가오는 경우가 많습니다. 꼭 단가만 오른 게 아니라, 내가 보내는 데이터 패턴과 과금 기준이 맞물리면서 총액이 급격히 커지는 거죠. 실제로 써보니까, 비용 문제는 제품 성능보다 카디널리티(cardinality, 라벨 조합 폭발) 관리 실패에서 먼저 터지는 경우가 많더라고요.

2. Grafana Cloud 가격 구조를 쉽게 풀어보면

공식 가격 페이지 기준으로 현재 눈에 띄는 포인트는 이렇습니다. 글을 읽는 시점에 바뀔 수 있으니, 실제 계약 전에 공식 페이지는 꼭 다시 확인하셔야 합니다.

항목	공식 페이지 기준 포인트	운영자가 봐야 할 부분
Metrics	Free는 월 10k active series, 14일 보관	라벨 설계가 나쁘면 금방 초과합니다.
Metrics Pro	월 플랫폼 요금 + 사용량 기반 가격	노드 수보다 series 폭증이 더 위험합니다.
Logs Free	월 50GB, 14일 보관	테스트 환경은 괜찮지만 운영 로그는 빠듯할 수 있습니다.
Logs Pro	process, write, retain 기반 사용량 과금	수집, 저장, 보관을 따로 봐야 합니다.
Retention	Pro 기준 metrics 13개월, logs/traces 30일	장기 보관이 필요한 조직엔 장점이 큽니다.

쉽게 말해 이렇습니다. Grafana Cloud 비용은 서버 대수보다도 '얼마나 많은 시계열과 데이터를 계속 보내고 있는가'에 더 민감합니다. VM 몇 대 수준에서는 괜찮아 보여도, 쿠버네티스(Kubernetes, 컨테이너 오케스트레이션) 들어가고 라벨이 늘고, 로그를 구조화해서 많이 쌓기 시작하면 얘기가 달라집니다.

그래서 저는 비용 분석할 때 아래 세 가지부터 봅니다.

active series가 왜 늘고 있는지
scrape interval(스크랩 주기, 수집 간격)이 과한지
꼭 SaaS에 남겨야 하는 데이터와 로컬에 둬도 되는 데이터를 구분했는지

3. 자체 호스팅 ROI, 저는 이렇게 계산합니다

여기서 많이들 실수하는 게 있습니다. 자체 Prometheus로 돌린다고 해서 무조건 싸지 않거든요. 저도 처음엔 'VM 하나면 끝 아닌가?' 싶었는데, 막상 해보면 백업, 디스크, 알람, 업그레이드, 장애 대응까지 다 내 일이 됩니다. 삽질 좀 했습니다 ㅎㅎ

그래도 자체 호스팅 ROI가 좋아지는 구간은 분명히 있습니다.

메트릭은 많은데 장기 보관이 꼭 필요하지 않을 때
운영 인력이 있어 기본 유지보수를 감당할 수 있을 때
로그와 트레이스를 전부 관리형으로 둘 필요가 없을 때
홈랩, 사내 관제, 내부 서비스처럼 외부 SLA보다 비용 통제가 더 중요할 때

반대로 아래 조건이면 Grafana Cloud가 여전히 훨씬 편할 수 있습니다.

24x7 대응과 장기 보관이 중요할 때
멀티 리전, 팀 협업, 권한 관리가 이미 복잡할 때
장애 나면 관제 스택을 직접 고칠 사람이 없을 때

제가 실제로는 이렇게 따집니다. 월 청구서 증가분과 직접 운영할 때 들어가는 VM/디스크/백업 비용 + 관리 시간을 같이 봅니다. 숫자를 억지로 예쁘게 만들 필요는 없고요. 한 달에 두세 번만 대시보드 보고, 보관 기간도 15일~30일이면, 자체 Prometheus 쪽이 생각보다 금방 수지가 맞는 경우가 있습니다.

4. 그래서 저는 Prometheus + Grafana 조합으로 다시 갔습니다

이번 선택의 핵심은 단순했습니다. 메트릭은 자체 호스팅, 필요하면 나중에 일부만 외부로 보낸다. Prometheus는 구조가 명확하고, Grafana는 익숙하고, 둘 다 문서가 탄탄합니다. 무엇보다 제가 어디서 비용이 나는지 눈으로 볼 수 있더라고요.

Prometheus 공식 문서를 보면 로컬 저장소(local storage)는 기본적으로 15일 retention입니다. 그리고 저장소 크기를 제어하려면 --storage.tsdb.retention.time 또는 --storage.tsdb.retention.size를 잡을 수 있습니다. 또 중요한 경고가 하나 있는데, NFS 같은 비POSIX 환경은 권장되지 않습니다. 이거 모르고 네트워크 스토리지에 올렸다가 애매한 문제 겪는 경우 진짜 많습니다.

Grafana Cloud 비용 절감을 위해 구성한 자체 Prometheus 홈랩 다이어그램

Docker Compose 기반으로 Prometheus와 Grafana를 엮은 홈랩 구성 예시입니다.

5. 실전 구현: Docker Compose로 10분 안에 올리기

복잡하게 시작할 필요 없습니다. 가장 단순하고 관리하기 쉬운 형태로 먼저 띄우는 게 좋습니다. 아래 예시는 Prometheus와 Grafana를 같은 Docker Compose 네트워크에 올리는 방식입니다.

5-1. 디렉터리 구조

monitoring/
├── docker-compose.yaml
├── prometheus/
│   └── prometheus.yml
└── grafana/
    └── provisioning/
        └── datasources/
            └── prometheus.yaml

5-2. docker-compose.yaml

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=15d
      - --storage.tsdb.retention.size=20GB
      - --web.enable-lifecycle
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    depends_on:
      - prometheus

volumes:
  prometheus-data:
  grafana-data:

여기서 중요한 포인트는 두 가지입니다. 첫째, retention.time과 retention.size를 둘 다 넣어 디스크 폭주를 막는 것. 둘째, 영속 볼륨(persistent volume)을 꼭 쓰는 것입니다. 안 그러면 컨테이너 다시 뜰 때 데이터가 날아가거든요.

5-3. prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - prometheus:9090

Prometheus 공식 시작 가이드의 가장 기본적인 예시는 자기 자신을 스크랩하는 구성입니다. 저는 처음에 딱 여기서 시작하시는 걸 추천합니다. 이것만으로도 Prometheus가 정상 수집 중인지 바로 검증할 수 있거든요.

5-4. Grafana 데이터소스 프로비저닝

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    jsonData:
      httpMethod: POST

Grafana 공식 문서에도 나오지만, 같은 Compose 네트워크라면 http://prometheus:9090처럼 서비스 이름으로 붙이는 방식이 제일 깔끔합니다. 많은 분들이 여기서 localhost:9090 넣고 왜 안 되지? 하는데, 컨테이너 안에서 localhost는 자기 자신이거든요. 저도 처음엔 여기서 한 번 헷갈렸습니다.

5-5. 실행

cd monitoring
docker compose up -d

docker compose ps
curl http://localhost:9090/-/ready
curl http://localhost:3000/api/health

Prometheus는 http://localhost:9090, Grafana는 http://localhost:3000으로 들어가면 됩니다. Grafana 데이터소스가 자동으로 붙어 있으면 거의 다 된 겁니다. 드디어 됐다! 하는 순간이 여기서 오더라고요.

Grafana Cloud 비용 대안으로 자체 Prometheus를 연결한 Grafana 설정 이미지

Grafana에서 Prometheus 데이터소스가 정상 연결된 상태를 보여주는 설정 화면 예시입니다.

6. 운영하면서 꼭 챙겨야 하는 비용 절감 포인트

자체 호스팅으로 돌아왔다고 모니터링 비용 문제가 자동 해결되진 않습니다. 그냥 청구서 대신 디스크와 리소스가 문제를 말해줄 뿐이죠. 그래서 아래 기준은 꼭 잡고 가는 편이 좋습니다.

scrape interval을 무작정 5초로 두지 않습니다. 15초나 30초면 충분한 경우가 많습니다.
high cardinality 라벨을 줄입니다. 요청 ID, 세션 ID 같은 값은 거의 독입니다.
장기 보관이 필요하면 Prometheus 단독보다 Thanos, Mimir 같은 별도 구조를 검토합니다.
메트릭과 로그를 분리해서 생각합니다. 둘을 한 번에 SaaS에서 빼면 운영 복잡도가 급격히 올라갈 수 있습니다.

특히 모니터링 비용은 수집량보다도 라벨 설계에서 무너지는 경우가 많습니다. 예를 들어 pod 이름, request path, 사용자별 식별자가 섞이면 active series가 순식간에 불어납니다. 클라우드 가격이 비싸다고 느껴질 때는 서비스 갈아타기 전에 먼저 series 폭증 원인을 보는 게 맞습니다. 이게 정말 중요한 포인트입니다!

7. ⚠️ 실제로 많이 겪는 트러블슈팅

Grafana에서 데이터가 안 보임
원인: 데이터소스 URL을 localhost:9090으로 넣은 경우가 많습니다. 컨테이너 분리 환경이면 서비스명이나 내부 네트워크 주소를 써야 합니다.
디스크가 생각보다 빨리 참
원인: retention은 시간만 잡고 size 제한을 안 둔 경우가 많습니다. --storage.tsdb.retention.size를 같이 설정하세요.
Prometheus 재시작 후 데이터가 날아감
원인: 볼륨 마운트가 빠졌을 가능성이 큽니다. 특히 테스트하다가 귀찮아서 빼면 꼭 나중에 후회합니다.
NFS에 올렸더니 이상하게 불안정함
원인: Prometheus 공식 문서에서도 로컬 파일시스템 사용을 강하게 권장합니다. 네트워크 파일시스템은 피하는 편이 안전합니다.

저는 한때 백업 편하겠다고 네트워크 스토리지를 먼저 떠올렸었는데, 이건 운영 편의보다 안정성이 우선이더라고요. 결국은 로컬 디스크 + 스냅샷/백업 전략으로 다시 정리했습니다.

8. 검증 결과: 무엇이 좋아졌고 무엇을 잃었나

직접 운영으로 바꾸고 나면 제일 먼저 느끼는 건 비용 예측 가능성입니다. Grafana Cloud 비용처럼 사용량 급등에 따라 청구서가 튀는 대신, 이제는 VM 크기와 디스크 크기, retention 정책으로 상한선을 제가 결정할 수 있습니다. 이거 진짜 편하더라고요. 적어도 월말에 놀랄 일은 줄어듭니다.

반대로 잃는 것도 분명합니다.

관리형 서비스의 즉시성
긴 retention과 팀 기능의 편의성
장애 시 벤더에 기대는 심리적 안정감

그래서 결론은 단순합니다. 메트릭 위주의 소규모~중간 규모 환경이라면 자체 Prometheus는 충분히 매력적입니다. 반면 로그, 트레이스, 장기 보관, 멀티팀 협업이 핵심이면 Grafana Cloud가 여전히 좋은 선택일 수 있습니다. 결국 핵심은 도구 종교가 아니라 ROI와 운영 책임 범위입니다.

Grafana Cloud 비용 분석 후 자체 Prometheus 전환 결과 대시보드 이미지

자체 Prometheus 전환 후 Grafana 대시보드와 리소스 사용량을 함께 확인하는 결과 예시입니다.

9. 정리와 FAQ

자주 묻는 질문

Q. Grafana Cloud를 완전히 버려야 하나요?
아닙니다. 메트릭만 자체 호스팅하고, 로그나 외부 공유 대시보드는 관리형을 유지하는 혼합형도 충분히 좋습니다.
Q. 자체 호스팅 ROI는 언제 좋아지나요?
청구서 증가 속도보다 VM/스토리지/운영 시간 증가 속도가 느릴 때입니다. 특히 retention이 짧고 운영 범위가 작을수록 유리합니다.
Q. 다음 단계는 뭘 보면 좋을까요?
다음 글에서는 Node Exporter, Alertmanager, 그리고 카디널리티 줄이는 실전 팁을 정리해볼 예정입니다. 이전 글에서 다뤘던 홈랩 스토리지 설계와도 연결해서 보시면 더 이해가 쉬우실 겁니다.

정리하면 이렇습니다. Grafana Cloud 비용이 부담스럽다고 느껴지는 순간이 오면, 무조건 해지부터 할 필요는 없습니다. 먼저 내 사용량 구조를 보고, 어떤 데이터가 비용을 끌어올리는지 파악한 뒤, 메트릭부터 단계적으로 분리해보세요. 저처럼 한 번 직접 돌려보면, 어떤 환경에서 자체 호스팅이 맞는지 감이 꽤 선명해집니다. 처음엔 헷갈려도, 막상 해보면 생각보다 어렵지 않습니다.

Grafana Cloud와 자체 호스팅 ROI를 한눈에 정리한 비교 인포그래픽 예시입니다.

참고한 공식 문서

'IT > Cloud' 카테고리의 다른 글

[클라우드] Azure Functions 최신 업데이트와 실전 대응 전략 (0)	2026.07.11
[Cloud] Cloud Run 마이그레이션: 온프레미스 앱 전환 전략 (0)	2026.07.11
[Cloud] AWS Lambda 보안 강화 체크리스트: 10가지 필수 설정 (0)	2026.07.11
[클라우드] AWS Bedrock 데이터 공유 정책 변경, 한국 기업 영향 분석 (0)	2026.07.10
[Cloud] Ollama 클라우드 배포 성공 사례: AWS EC2에서 LLM 운영하기 (0)	2026.07.06
[AWS] AWS Reserved Instance 구매 실패 사례: 비용 절감의 함정 (0)	2026.07.06

13년차의 서버실

[모니터링] Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유

목차

[모니터링] Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유

1. 왜 Grafana Cloud 비용이 갑자기 아프게 느껴질까

2. Grafana Cloud 가격 구조를 쉽게 풀어보면

3. 자체 호스팅 ROI, 저는 이렇게 계산합니다

4. 그래서 저는 Prometheus + Grafana 조합으로 다시 갔습니다

5. 실전 구현: Docker Compose로 10분 안에 올리기

5-1. 디렉터리 구조

5-2. docker-compose.yaml

5-3. prometheus.yml

5-4. Grafana 데이터소스 프로비저닝

5-5. 실행

6. 운영하면서 꼭 챙겨야 하는 비용 절감 포인트

7. ⚠️ 실제로 많이 겪는 트러블슈팅

8. 검증 결과: 무엇이 좋아졌고 무엇을 잃었나

9. 정리와 FAQ

자주 묻는 질문

참고한 공식 문서

'IT > Cloud' 카테고리의 다른 글

티스토리툴바

[모니터링] Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유

목차

[모니터링] Grafana Cloud 비용 분석, 자체 Prometheus로 돌아간 이유

1. 왜 Grafana Cloud 비용이 갑자기 아프게 느껴질까

2. Grafana Cloud 가격 구조를 쉽게 풀어보면

3. 자체 호스팅 ROI, 저는 이렇게 계산합니다

4. 그래서 저는 Prometheus + Grafana 조합으로 다시 갔습니다

5. 실전 구현: Docker Compose로 10분 안에 올리기

5-1. 디렉터리 구조

5-2. docker-compose.yaml

5-3. prometheus.yml

5-4. Grafana 데이터소스 프로비저닝

5-5. 실행

6. 운영하면서 꼭 챙겨야 하는 비용 절감 포인트

7. ⚠️ 실제로 많이 겪는 트러블슈팅

8. 검증 결과: 무엇이 좋아졌고 무엇을 잃었나

9. 정리와 FAQ

자주 묻는 질문

참고한 공식 문서

📚 함께 읽으면 좋은 글

'IT > Cloud' 카테고리의 다른 글

관련글

티스토리툴바