생산성

2GB 서버에서 Prometheus Grafana Docker Compose 메모리 최적화 실제 운영 설정 가이드

2GB 서버에서 Prometheus Grafana Docker Compose 메모리 최적화 실제 운영 설정 가이드

메모리 2GB 서버에 Prometheus랑 Grafana 올렸다가 OOM으로 컨테이너가 죽어버린 적 있으시죠? 기본 설정 그대로 올리면 1.5GB는 금방 사라져요. 나머지 500MB로 실제 앱까지 돌리는 건 거의 불가능하고요.

그런데 요즘 이 조합을 2GB 서버에 올리려는 팀이 늘고 있어요. AWS Lightsail, DigitalOcean, Hetzner 기준 월 5~10달러짜리 서버로 다시 내리는 “클라우드 다이어트” 트렌드 때문이에요. Hetzner 2025년 데이터에 따르면 2GB 인스턴스 신규 생성이 전년 대비 38% 늘었어요. 이 글은 그 환경에서 실제로 운영 가능한 설정을 데이터 기반으로 정리했어요.

핵심 요약

  • Prometheus 기본 설정 시 최대 800MB1GB RAM을 쓰지만, 보존 기간과 청크 설정 조정만으로 300400MB까지 낮출 수 있어요.
  • Grafana는 플러그인 없이 최소 실행 시 150~200MB면 충분해요.
  • Docker Compose의 mem_limit으로 컨테이너별 상한을 강제하면 OOM Killer가 서버 전체를 죽이는 상황을 막아줘요.
  • 2GB 서버 안정 운영 공식: Prometheus 500MB + Grafana 250MB + Node Exporter 30MB 이하.
  • 스크래핑 간격을 30초 → 60초로 늘리는 것만으로 Prometheus 메모리가 약 20~25% 줄어요.

Prometheus가 메모리를 많이 먹는 이유

Prometheus의 시계열 데이터베이스(TSDB)는 기본적으로 15일치 데이터를 메모리와 디스크에 혼합 저장해요. 수집 대상이 늘수록 메모리 사용량은 선형이 아닌 지수적으로 올라가요.

Node Exporter 하나만 붙여도 기본 메트릭 수가 700개를 넘어요. Spring Boot Actuator나 Redis Exporter까지 붙이면 수천 개로 순식간에 늘어나죠. CNCF 2025년 조사에서 응답 기업의 73%가 Prometheus를 프로덕션에서 쓴다고 했는데, 이 조합이 “메모리가 충분한 서버"를 전제로 설계됐다는 게 문제예요.


메모리를 절반으로 줄이는 핵심 설정 3가지

1. 데이터 보존 기간 줄이기

command:
  - '--storage.tsdb.retention.time=7d'
  - '--storage.tsdb.retention.size=1GB'

기본값 15일 → 7일로 줄이면 TSDB가 메모리에 올려두는 청크 수가 절반이 돼요. Last9 벤치마크에 따르면 이 변경만으로 메모리 사용량이 평균 35% 줄었어요.

2. 스크래핑 간격 늘리기

global:
  scrape_interval: 60s
  evaluation_interval: 60s

15초 → 60초로 바꾸면 수집 빈도가 4분의 1로 줄어요. 실시간성은 약해지지만, 서버 헬스 체크나 리소스 모니터링 용도라면 60초로도 충분해요. 이것만으로 메모리가 약 20~25% 줄어들어요.

3. 동시 쿼리 수 제한

command:
  - '--query.max-concurrency=4'
  - '--query.max-samples=5000000'

Grafana 대시보드에서 여러 패널이 동시에 쿼리를 날리면 메모리가 급격히 올라가요. 동시 쿼리 수를 제한하면 이 스파이크를 억제할 수 있어요.


Docker Compose 메모리 상한 설정

2GB 서버의 실제 가용 메모리는 OS가 약 300~400MB를 쓰기 때문에 실질적으로 약 1.6GB예요.

컨테이너mem_limit 권장값실제 평균 사용비고
Prometheus512MB300~400MB스크래핑 타깃 5개 이하 기준
Grafana256MB150~200MB플러그인 최소화
Node Exporter64MB20~30MB거의 고정
Loki (선택)256MB150~200MB로그 수집 필요 시만
services:
  prometheus:
    image: prom/prometheus:v2.51.0
    mem_limit: 512m
    memswap_limit: 512m
    restart: unless-stopped

memswap_limitmem_limit과 같게 설정하면 swap 사용을 막을 수 있어요. 2GB 서버에서 swap이 활성화되면 I/O가 폭발하면서 오히려 더 느려지는 경우가 많거든요.


Grafana 플러그인이 진짜 문제예요

Grafana 자체는 생각보다 메모리를 많이 안 써요. 문제는 플러그인이에요.

environment:
  - GF_ANALYTICS_REPORTING_ENABLED=false
  - GF_ANALYTICS_CHECK_FOR_UPDATES=false
  - GF_LOG_LEVEL=warn

이미지 렌더링 플러그인(grafana-image-renderer)은 단독으로 150~300MB를 써요. PDF 리포트가 필요 없다면 아예 설치하지 마세요. 로그 레벨을 warn으로 낮추는 것만으로도 CPU와 메모리 모두 절약돼요.


스택 구성 방식 비교

항목Prometheus + Grafana 풀 스택Prometheus만VictoriaMetrics + Grafana
메모리 사용500~700MB300~400MB350~450MB
설정 난이도중간낮음높음
시각화Grafana 대시보드없음 (쿼리만)Grafana 대시보드
2GB 환경 적합성설정 최적화 필수적합적합

VictoriaMetrics는 Prometheus API와 호환되면서 메모리 효율이 더 좋아요. VictoriaMetrics 자체 문서에 따르면 동일 메트릭 수에서 메모리 사용량이 Prometheus 대비 30~50% 낮다고 해요. 다만 커뮤니티가 작고 트러블슈팅 자료가 적다는 점은 감수해야 해요.


상황별로 접근이 달라요

사이드 프로젝트 혼자 운영: 보존 기간 3일, 스크래핑 60초, Grafana 없이 Prometheus 내장 UI만 써도 충분해요. 메모리 총합 350MB 이하로 유지할 수 있어요.

소규모 팀 (3~5명) 프로덕션: Prometheus 512MB, Grafana 256MB, Node Exporter만 붙이는 구성이 현실적이에요. 알림이 필요하면 Alertmanager 대신 Grafana 내장 알림을 쓰면 컨테이너 하나를 줄일 수 있어요.

앱 서버와 분리가 필요한 경우: 2GB 서버가 두 개라면 모니터링 전용 서버를 따로 두는 게 나아요. 설정 제약이 대폭 줄고, Loki로 로그까지 같이 수집할 수 있어요.


지금 당장 확인할 것 3가지

  1. docker stats로 컨테이너별 실시간 메모리 확인
  2. Prometheus targets 페이지에서 스크래핑 타깃 수와 메트릭 수 확인
  3. prometheus_tsdb_head_chunks 메트릭으로 현재 메모리에 올라간 청크 수 파악

2GB 서버에서 Prometheus + Grafana 운영은 불가능한 게 아니에요. 기본값 그대로 쓰면 반드시 실패하는 것뿐이에요.

보존 기간 7일, 스크래핑 60초, mem_limit 명시, 이미지 렌더러 제거. 이 네 가지만 적용해도 메모리 사용량이 30~40% 줄어요. Prometheus 3.x 로드맵에 TSDB 압축 방식 개선이 포함돼 있어서 앞으로 더 나아질 수 있지만, 지금 당장 2GB 서버에서 돌려야 한다면 기다리는 것보다 설정을 바꾸는 게 맞아요.

docker stats를 열어서 Prometheus가 얼마나 먹고 있는지 확인해보세요. 400MB를 넘는다면, 오늘 바로 설정을 바꿔볼 시점이에요.

참고자료

  1. 서버 모니터링 시스템 Docker 로 구성하기(Grafana, Prometheus, Loki, Promtail, Springboot) — Railly`s IT 정리노트
  2. Prometheus with Docker Compose: The Complete Setup Guide | Last9
  3. Grafana 및 prometheus 활용 #2 - 나만의 코딩기록 - 티스토리

Photo by Conny Schneider on Unsplash