모니터링 서버 디스크 풀로 인한 9월 비용 급증 원인 및 해결 방안 논의

[Hexeong]

문제 배경

무슨 일이 있었나

9월 AWS 비용이 8월 대비 갑자기 $50 이상으로 튀는 것을 확인했습니다. Cost Explorer로 분석한 결과, 실제 원인은 solid-connection-monitoring 인스턴스(t4g.micro)의 CPU 크레딧 초과 요금이었습니다 (APN2-CPUCredits:t4g 항목만 8월 $0 → 9월 $19.85).

근본 원인

SSH로 직접 접속해서 확인한 결과, 아래와 같은 연쇄 장애였습니다.

1. 루트 EBS 볼륨이 6.8GB로 매우 작은데, 5개월간 아무 정리 정책 없이 운영되면서 디스크가 100% 풀됨
2. 디스크가 꽉 차자 dockerd가 grafana/loki/prometheus 컨테이너 로그를 쓰지 못해 초당 여러 번씩 에러를 반복 재시도
3. 이 에러들이 rsyslogd/systemd-journald로 계속 쏟아지면서 두 프로세스가 9월 2일부터 CPU를 지속적으로 폭주시킴 (rsyslogd 평균 66.5%, journald 평균 30.4%)
4. t4g.micro의 버스트 CPU 크레딧이 계속 소진되며 초과 요금 발생 → 이번 비용 급증의 직접 원인
5. 디스크 풀로 인해 logrotate.service도 실패 상태가 되고, Grafana 웹 UI도 정적 자산 로딩 실패로 접속 불가 상태였음 (TLS 인증서는 2026-10-06까지 유효 — 인증서 문제 아님, 확인 완료)

디스크를 차지하고 있던 항목 (정리 전 기준):

위치	용량
/usr (기본 OS)	2.7G
/var/lib/containerd (이미지 레이어)	1.6G
/home	764M
/var/log/journal	436M
/var/lib/snapd (오래된 리비전)	412M
/var/cache/apt	301M
/var/lib/docker	257M
Prometheus TSDB + Loki 청크 (실측)	약 480M (304M + 179M)

→ 메트릭/로그 데이터 자체는 전체 디스크의 7% 수준이었고, 대부분은 OS/이미지/캐시성 자산이 무기한 쌓인 것이 원인이었습니다.

응급 조치 (이미 완료)

apt-get clean, docker system prune -f(운영 컨테이너/이미지는 보존), journalctl --vacuum-size=100M, 오래된 snap 리비전 삭제를 진행해서 디스크 사용률을 **100% → 87%(919M 여유)**로 낮췄고, 실시간 CPU도 확인 결과 rsyslogd/journald 모두 **0%**로 정상화됐으며 Grafana도 다시 정상 접속됩니다. 단, 근본 원인(작은 볼륨 + 정리 정책 부재)은 그대로라 재발 가능성이 높습니다.

추가로 설정 점검 중 발견한 별개 버그: solid-connection-monitoring-node-exporter 스크레이프 job이 monitoring 자신이 아니라 stage 서버 IP를 중복으로 긁고 있어서, monitoring 자체 지표는 수집되고 있지 않았습니다.

---

해결 방식 후보

옵션 A. 최소 조치 — 로그만 통제

• Docker 데몬에 로그 로테이션(max-size, max-file) 적용, logrotate.service 실패 원인 수정, CloudWatch 디스크 사용률 알람 추가
• 장점: 작업량 작음, 비용 없음, 빠르게 적용 가능
• 단점: Loki/Prometheus 데이터나 OS/이미지 누적은 그대로라 근본 해결은 아님

옵션 B. 인프라 사이징 정상화 — 볼륨 확장 + Retention 정책 (추천)

• 루트 EBS 볼륨을 6.8G → 20~30G로 확장(Terraform, 온라인 리사이즈 가능) + Loki/Prometheus에 명시적 retention 설정 + 옵션 A 포함
• 장점: 이번 사고를 정확히 겨냥한 근본 조치, 비용 미미(월 몇 백~천 원대), 무중단 적용 가능
• 단점: retention 정책 적용 시 기존 데이터 정리 과정에서 컨테이너 재시작 필요

옵션 C. 구조적 개선 — 관측 스택 아키텍처 재검토

• 데이터 볼륨을 루트와 분리, fleet 전체 디스크/메모리 알람 표준화, 장기적으로 managed Prometheus/Grafana 이전 검토
• 장점: 단일 인스턴스 장애가 전체 관측 스택을 마비시키는 구조적 취약점 해소, 다른 EC2에서도 조기 감지 가능
• 단점: 설계 논의와 마이그레이션 계획이 필요한 큰 작업, 지금 당장 급한 결정은 아님

옵션 D. 불필요한 메트릭/로그 수집 축소

• Loki에 retention 정책 추가(현재 설정 자체가 없어서 로그가 무기한 쌓이는 구조 — 이건 옵션과 무관하게 고쳐야 함)
• 대시보드에서 실제로 안 쓰는 세부 히스토그램(redis_commands_latencies_usec_bucket 등, 전체 시리즈의 15%+ 차지) 확인 후 drop, scrape_interval 10s → 30s 완화
• 장점: 설정 변경만으로 가능해 비용/리스크 최저, 장기적인 디스크 증가 속도와 Prometheus/Loki의 CPU·쓰기 부하 감소
• 단점: 현재 메트릭+로그 데이터가 전체 디스크의 7%에 불과해서, 단독으로는 이번 같은 디스크 풀 재발을 막기엔 부족함

종합 의견

B + D를 함께 진행하는 것을 제안합니다. B가 이번 사고의 직접 원인(용량 부족)을 해소하고, D는 다음에 또 볼륨을 늘려야 하는 주기를 늦춰줍니다. A는 B에 포함되는 내용이라 별도로 안 해도 되고, C는 지금 결정하기보다 로드맵 아이템으로 남겨두는 정도면 충분할 것 같습니다.

의견 남겨주세요 🙏

[whqtker]

1. EBS 볼륨 늘리는 것은 좋은 거 같습니다. 그라파나, 프로메테우스, 로키에 도커, OS까지 생각하면 6GB는 너무 적은 거 같네요.
2. 말씀하신 대로 디스크 사용량은 CloudWatch로 모니터링하는 게 좋은 거 같네요. 이번 모니터링 인스턴스 외에도 적용하면 좋을 거 같습니다.
3. EBS 공간 늘리고 실제로 OS가 이를 사용하도록 하려면 별도로 파일시스템 및 파티션을 확장해야 한다고 하네요. [참고] 완전 온라인 리사이즈는 아닌 거 같습니다.
4. 로키 리텐션 정책은 찬성합니다. 다만 가능하다면 프로메테우스 매트릭 인터벌과 통일성있으면 좋을 거 같네요.
5. 스크랩 인터벌을 늘리는 건 근본 해결 방식이 아닌 거 같습니다. 리텐션만 적용하도 될 거 같습니다. 뭐 30초로 해도 크게 영향 있을 거 같진 않지만, 그러니까 오히려 건들지 않아도 될 거 같습니다.