클라우드 서버 모니터링·로그 수집 비용 비교: Datadog vs Prometheus·Grafana Loki 구축 및 과금 최적화
서비스 트래픽이 늘어나면서 인프라 운영자가 가장 먼저 마주하는 예상 밖의 청구서 중 하나가 바로 APM(Application Performance Monitoring) 및 로그 수집(Observability) 비용입니다. 초기에는 노드 몇 대에 에이전트만 설치하면 끝나는 것처럼 보이지만, 컨테이너가 오토스케일링되고 커스텀 메트릭과 JSON 로그가 쌓이기 시작하면 실제 AWS EC2·RDS 서버 비용의 20~40%에 육박하는 금액이 모니터링 SaaS로 빠져나가는 일이 흔합니다.
특히 엔터프라이즈 표준으로 꼽히는 Datadog은 호스트 단가 외에도 로그 인덱싱(Indexing)·커스텀 메트릭(Custom Metrics)·APM 트레이스(Traces)가 별도로 과금되는 구조라, 설정을 방치하면 월 청구서가 순식간에 수천 달러로 불어납니다. 이번 글에서는 1) Datadog vs Grafana Cloud vs 자체 구축 Prometheus·Grafana Loki의 과금 구조 및 월간 비용 시뮬레이션, 2) 로그 수집량을 70% 줄이는 Promtail·Loki 파이프라인 실전 설정, 3) 카디널리티(Cardinality) 폭증으로 인한 OOM 장애와 추가 과금을 막는 튜닝 전략을 정리합니다.
1. Datadog vs Grafana Cloud vs 자체 구축 Prometheus·Loki 요금 비교
모니터링 스택을 고를 때는 단순히 '에이전트 1개당 가격'이 아니라 호스트·컨테이너 수, 월간 로그 수집량(GB), 메트릭 시계열(Active Series) 수를 함께 따져야 합니다. 대표적인 세 가지 선택지의 과금 체계를 표로 비교했습니다.
| 구분 / 항목 | Datadog (Pro 연간 약정 기준) | Grafana Cloud (Pro) | 자체 구축 (Prometheus + Loki) |
|---|---|---|---|
| 인프라 기본료 | 호스트당 월 $15 (APM 추가 시 호스트당 +$31) |
기본 월 $19 (무료 티어 초과분 종량제) |
단일 모니터링 노드 기준 월 $50~$80 (예: t3.large) |
| 로그 수집·보관 | 수집 $0.10 / GB + 인덱싱 $1.70 / 100만 건 (15일) |
무료 50GB 포함 후 초과 $0.50 / GB (30일 보관) |
AWS S3 스토리지 실비만 부과 ($0.023 / GB, 압축 후 더 절감) |
| 메트릭 과금 | 호스트당 100~200개 포함, 초과 커스텀 메트릭 $0.05 / 개 |
10,000 Active Series 포함, 초과 1,000개당 $6.50 |
서버 메모리(RAM) 한도 내 추가 과금 없음 |
| 네트워크 전송비 | 외부 SaaS 전송에 따른 NAT·인터넷 Egress 비용 발생 |
외부 SaaS 전송에 따른 NAT·인터넷 Egress 비용 발생 |
동일 VPC 내부 통신 및 S3 Gateway Endpoint로 $0 |
| 추천 규모 | 전담 SRE 없이 빠른 APM· 트레이싱이 필요한 조직 |
소규모~중규모 팀, PromQL·LogQL 생태계 선호 |
로그·메트릭 규모가 커져 월 SaaS 비용이 $500 넘는 팀 |
2. 월간 비용 시뮬레이션: 노드 20대 + 월 로그 500GB 환경
실제 운영 환경에 가까운 컨테이너 호스트 20대, 월간 로그 500GB(약 5억 건), 커스텀 메트릭 2,000개 추가 조건으로 월간 예상 비용을 계산하면 격차가 극명하게 드러납니다.
① Datadog 이용 시 (약 $1,900 ~ $2,400 / 월)
인프라(20대 × $15 = $300)와 APM(20대 × $31 = $620)만 합쳐도 기본 $920입니다. 여기에 로그 수집(500GB × $0.10 = $50)과 15일 보관 인덱싱(500M 건 × $1.70 = $850), 커스텀 메트릭 초과분($100 내외)을 더하면 월 $1,920(약 260만 원 이상)이 청구됩니다. 온디맨드(월간 결제)나 고해상도 컨테이너(호스트당 허용 컨테이너 초과)가 섞이면 $2,400을 훌쩍 넘깁니다.
② 자체 구축 Prometheus + Grafana Loki 이용 시 (약 $80 ~ $130 / 월)
모니터링 전용 EC2 1대(예: t3.large 또는 c6i.large + EBS 100GB) 약 $65~85에 500GB 로그를 gzip/snappy 압축(약 100~150GB)해 S3에 저장하면 스토리지 비용은 월 $3~5 수준에 불과합니다. 또한 같은 AWS VPC 내부에서 통신하고 S3 Gateway Endpoint를 연결하면 외부 인터넷 Egress나 AWS NAT Gateway 데이터 처리 요금 폭탄도 원천 차단할 수 있습니다. 동일 워크로드 기준 월 비용이 90% 이상 절감되는 셈입니다.
3. Datadog·SaaS 비용이 폭증하는 3가지 숨은 원인
자체 구축이 어렵다면 기존 Datadog이나 Grafana Cloud를 쓰면서도 과금 구조를 정확히 이해해 지출을 절반 이하로 줄일 수 있습니다.
1) 로그 수집(Ingestion)보다 비싼 인덱싱(Indexing)
Datadog은 로그를 받아들이는 비용($0.10/GB)보다 검색 가능하게 저장하는 인덱싱 비용($1.70/100만 건)이 10배 이상 비쌉니다. 로드밸런서 헬스체크(GET /healthz 200), 정적 파일 요청, 디버그(DEBUG) 로그까지 전부 인덱싱하면 돈만 내고 정작 장애 분석 시 노이즈만 늘어납니다. Exclusion Filter로 정상 200 응답이나 헬스체크 로그는 수집 직후 인덱싱에서 제외하고, S3 아카이브로만 흘려보내야 합니다.
2) 고카디널리티(High Cardinality) 커스텀 메트릭 태그
메트릭 태그(Label)에 user_id, request_id, pod_ip처럼 값이 무한히 늘어나는 식별자를 넣으면, 고유한 태그 조합 수만큼 별도의 커스텀 메트릭으로 과금됩니다. 이 현상은 Prometheus나 Grafana Loki에서도 동일하게 발생해 시계열 인덱스가 폭발하고 결국 모니터링 서버의 메모리가 고갈되는 원인이 됩니다.
3) 스팟·오토스케일링 환경의 컨테이너 과금
Kubernetes나 ECS에서 파드(Pod)가 하루에 수십 번씩 뜨고 지는 환경에서는 월평균이 아니라 고점(High-Water Mark) 기준으로 호스트·컨테이너 추가 요금이 산정될 수 있습니다. 스파이크 시간대의 불필요한 파드 증설을 제어하고 컨테이너 메모리 제한을 적정선으로 맞추는 것이 모니터링 비용 절감으로도 이어집니다. 컨테이너 메모리 초과로 인한 재시작 루프가 의심된다면 Docker 컨테이너 Exit Code 137 (OOM Killed) 원인 분석 및 메모리 제한 가이드를 함께 점검해 두는 편이 좋습니다.
4. 실전 설정: Promtail + Grafana Loki 로그 필터링으로 수집량 70% 줄이기
자체 구축 환경이나 Grafana Cloud로 전환할 때 가장 효과가 큰 작업은 에이전트(Promtail 또는 Grafana Alloy) 단에서 불필요한 로그를 버리고, Loki 라벨에는 오직 고정된 소수 집합(service, env, level)만 남기는 것입니다. 아래는 실무에서 바로 적용할 수 있는 promtail-config.yaml 파이프라인 예시입니다.
scrape_configs:
- job_name: app-containers
static_configs:
- targets: [localhost]
labels:
job: api-server
env: production
__path__: /var/log/app/*.log
pipeline_stages:
# 1) JSON 로그 파싱 (단, user_id나 trace_id는 라벨로 승격하지 않음)
- json:
expressions:
level: level
path: path
status: status
# 2) 헬스체크 및 메트릭 스크랩 요청은 저장 전 폐기 (수집량 50~70% 절감)
- match:
selector: '{job="api-server"}'
stages:
- drop:
source: path
expression: "^/(healthz|readyz|metrics)$"
# 3) 저카디널리티 필드만 Loki 라벨로 지정
- labels:
level:핵심은 user_id, ip, trace_id 같은 값을 labels 블록에 넣지 않는 것입니다. Loki는 본문(Log line) 자체를 인덱싱하지 않고 라벨 조합 단위로 청크(Chunk)를 쪼개어 S3에 저장하므로, 위처럼 라벨을 3~4개 이내로 제한한 뒤 필요할 때만 LogQL의 | json | user_id="1234" 파이프라인 필터로 조회하는 방식이 메모리 안정성과 쿼리 속도 모두에서 압도적으로 유리합니다.
5. Loki S3 백엔드 및 보존 기간(Retention) 튜닝 예시
자체 구축 Loki의 경우 로컬 디스크(EBS)에 로그를 계속 쌓으면 디스크 풀(Disk Full) 장애가 나기 쉽습니다. 아래처럼 S3 Object Storage + Compactor 30일 자동 삭제를 설정하면 스토리지 관리 부담 없이 저비용 장기 보관이 가능합니다.
schema_config:
configs:
- from: 2024-04-01
store: tsdb
object_store: s3
schema: v13
index:
prefix: loki_index_
period: 24h
storage_config:
aws:
s3: s3://ap-northeast-2/my-company-loki-logs
tsdb_shipper:
active_index_directory: /loki/tsdb-index
cache_location: /loki/tsdb-cache
limits_config:
retention_period: 720h # 30일 후 자동 만료
ingestion_rate_mb: 16
ingestion_burst_size_mb: 32
compactor:
working_directory: /loki/compactor
compaction_interval: 10m
retention_enabled: true
delete_request_store: s36. 요약: 팀 규모별 최적의 모니터링·로그 아키텍처
모든 팀이 당장 Datadog을 버릴 필요는 없습니다. 호스트 5대 미만이고 개발 속도가 최우선인 초기 단계라면 Grafana Cloud 무료 티어(로그 50GB·메트릭 10k 포함)나 Datadog 기본 플랜에 로그 Exclusion Filter만 걸어도 충분합니다. 반면 월간 모니터링 청구서가 $500(약 70만 원)을 넘어가기 시작하는 시점이라면, 메트릭과 로그는 자체 구축한 Prometheus + Grafana Loki(S3 백엔드)로 분리해 비용을 80~90% 절감하고, 꼭 필요한 핵심 결제·인증 API에만 분산 트레이싱(Tempo 또는 샘플링된 APM)을 적용하는 하이브리드 전략이 가장 합리적입니다.
클라우드 인프라 전반의 고정비를 추가로 낮추고 싶다면, GitHub Actions 유료 러너 비용 비교 및 빌드 시간 단축 가이드와 AWS NAT Gateway 데이터 요금 절감 전략도 함께 점검해 보시기 바랍니다.
