Grafana, Prometheus 적용
서론
현재 프로젝트에 Spring actuator와 Prometheus, Grafana의 적용을 완료했다.
(넣어준 쿼리가 그래프 형식으로 보이는 모습)
도커에서 이미지로 제공하기 때문인지 설정 파일만 몇 개 작성하고 의존성만 넣어주면 돼서 생각보다 쉽게 끝났다.
기초적인 설정이니 별달리 이에 대해 코드를 올리거나 설명하진 않으려 한다. 대신 이러한 기술들을 배우고 사용하면서 AI와 질의응답 한 내용이 항상 새겨야 할 내용이고 중요한 것 같아 이를 포스팅하려 한다.
나도 질의응답 내용과 같이 PromQL과 메트릭의 활용과 같은 기술의 기본기를 꼭 다지고 사용해야겠다는 생각이 들었다. 이는 내가 계획 중인 테스트에서 가독성이 좋고 훌륭한 결과를 도출하고 시각화 하는 데에도 꼭 필요한 과정이라 생각한다.
질의응답
-> 도커가 쓸 수록 너무 편리한 것 같아. 여러 프로그램들을 이미지로 간단하게 사용할 수 있어서 npm의 확장된 버전 같이. 부작용 같은건 없을까?
-> 정말 좋은 관찰입니다! Docker는 정말 편리하지만 “편리함의 함정”이 있어요. npm과 비교한 관점도 정확합니다.
Docker의 편리함과 함정
편리한 점들
# 복잡한 설치 과정 없이
docker run redis
docker run postgres
docker run elasticsearch
# 버전 관리도 쉽게
docker run redis:6.2
docker run redis:7.0
하지만 숨겨진 복잡성들…
주요 부작용들
1. 블랙박스 문제
# 겉보기에는 간단하지만...
prometheus:
image: prom/prometheus # 내부에서 뭔 일이 일어나는지 모름
문제 상황:
- Prometheus가 갑자기 죽음 → “왜지?”
- 로그 확인 → “어디서 봐야 하지?”
- 설정 변경 → “어떤 파일을 수정해야 하지?”
2. 리소스 오버헤드 누적
# 각각은 작아 보이지만...
Redis: 50MB
PostgreSQL: 200MB
Elasticsearch: 1GB
Prometheus: 200MB
Grafana: 150MB
Nginx: 50MB
─────────────────
총합: 1.65GB # 실제 로직과 무관한 오버헤드
3. 의존성 지옥의 다른 형태
# npm의 node_modules 대신 이미지 의존성
services:
app:
depends_on: [db, redis, rabbitmq, elasticsearch]
# 각각이 또 다른 이미지들을 pull
실제 부작용 사례
1. 개발자 스킬 공동화
# 예전: PostgreSQL 설치하면서 자연스럽게 학습
sudo apt install postgresql
sudo -u postgres createdb myapp
# → DB 설정, 권한, 네트워크 등을 이해하게 됨
# 지금:
docker run postgres
# → 내부 동작 원리를 모르고 사용
2. 디버깅 능력 저하
# 문제 발생시
개발자: "Docker가 안 되는데요?"
시니어: "어떤 에러가?"
개발자: "그냥... 안 되요"
# 실제로는
docker logs container-name
docker exec -it container-name bash
# 이런 기본기가 부족
3. 프로덕션 환경에서의 복잡성
# 개발: docker-compose up (끝)
# 운영:
- 컨테이너 오케스트레이션 (Kubernetes)
- 네트워크 설정
- 볼륨 관리
- 보안 설정
- 모니터링
- 로그 수집
npm과의 공통점과 차이점
공통점 (편의성의 함정)
# npm
npm install express # 내부 동작 모름
# Docker
docker run nginx # 내부 설정 모름
차이점 (영향 범위)
# npm: 코드 레벨 의존성
package.json의 라이브러리들
# Docker: 인프라 레벨 의존성
전체 운영 환경, 네트워크, 보안
건전한 Docker 사용법
1. 기본기 이해하고 사용
# 단순히 실행하지 말고
docker run postgres
# 내부 구조 이해하며 사용
docker run -d \
--name postgres \
-e POSTGRES_PASSWORD=mypass \
-p 5432:5432 \
-v postgres-data:/var/lib/postgresql/data \
postgres:13
2. 로컬에서는 직접 설치도 병행
# Docker로 빠른 프로토타이핑
docker run redis
# 동시에 로컬에 직접 설치해서 학습
brew install redis
redis-server
3. 프로덕션 준비성 고려
# 개발용: 간단하게
services:
db:
image: postgres
# 운영용: 상세하게
services:
db:
image: postgres:13-alpine
restart: always
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
volumes:
- db-data:/var/lib/postgresql/data
secrets:
- postgres_password
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
백엔드 개발자로서 균형잡힌 접근
권장 사항
- Docker로 빠른 환경 구성 → 생산성 ✅
- 핵심 기술은 직접 설치/학습 → 깊이 있는 이해 ✅
- 문제 발생시 디버깅 능력 → 문제 해결 능력 ✅
결론: Docker는 훌륭한 도구지만 “마법”이 아닙니다. 편의성을 누리되, 내부 동작 원리를 이해하려는 노력을 게을리하지 않는 것이 중요해요. 특히 백엔드 개발자라면 인프라에 대한 기본 이해는 필수입니다!