최종프로젝트 인프라 모니터링 설계

Lightsail, Docker, PostgreSQL, Redis, 외부 uptime check를 통해 서비스 생존성과 핵심 의존성 상태를 확인하기 위한 문서입니다.

🎯 목적

인프라 모니터링은 Polaris 운영 환경이 실제로 살아 있는지, 핵심 의존성인 PostgreSQL과 Redis가 정상인지, Lightsail 서버 자원이 부족하지 않은지를 빠르게 확인하기 위한 체계다.

MVP 단계에서는 관리형 대형 모니터링 스택을 바로 도입하지 않고, Lightsail 기본 metric, Docker healthcheck, cron checker, 외부 uptime check, Slack 알림을 조합한다.

이 문서는 인프라 담당자가 확인해야 할 서버/컨테이너/DB/Redis 생존성과 자원 상태를 다룬다. API latency, 5xx, AI fallback, 제품 funnel 지표는 각각 애플리케이션 메트릭 문서와 사용자/제품 로그 문서에서 다룬다.

💡 왜 단순하게 시작하는가

현재 운영 환경은 Lightsail과 Docker Compose 기반이다. MVP에서 가장 중요한 것은 “서버가 살아 있는지”, “DB와 Redis가 붙는지”, “외부에서 서비스에 접근 가능한지”, “장애를 팀이 바로 아는지”다.

처음부터 Kubernetes, APM, 분산 추적, 장기 로그 인덱싱을 붙이면 비용과 운영 부담이 커진다. 따라서 MVP에서는 우리가 실제로 쓰는 인프라 요소를 작고 확실하게 감시한다.

🧭 이 문서의 범위

구분 이 문서에서 다룸 다른 문서

☁️ Lightsail	CPU, network, instance status, disk usage	-
🐳 Docker	container 상태, restart 반복, healthcheck	-
🐘 PostgreSQL	접속 가능 여부, pg_isready, disk, connection	제품 로그/DB 쿼리 성능은 별도
⚡ Redis	PING, memory, evicted keys, restart	AI fallback 분석은 제품 로그/AI 로그
🌐 Uptime	public endpoint 외부 접근 가능 여부	-
💬 Slack 알림	인프라 알림 전송 형식	장애 등급/대응 절차는 Runbook
📈 API/JVM	다루지 않음	애플리케이션 메트릭
🤖 AI 품질	다루지 않음	사용자/제품 로그, AI Ops

🧱 현재 인프라 가정

• AWS Lightsail 사용
• Docker Compose 기반 배포
• PostgreSQL container 또는 별도 DB 서버
• Redis container 또는 별도 Redis 서버
• Spring Boot backend service container
• Nginx 또는 reverse proxy
• Slack을 팀 알림 채널로 사용 가능

운영 구조가 단일 서버인지 app/db 분리인지에 따라 healthcheck 대상과 알림 위치만 조정한다.

☁️ Lightsail 기본 모니터링

Lightsail에서 우선 확인할 항목은 다음과 같다.

항목 기준 초안 등급 설명

CPU	5분 평균 80% 이상	P2	앱 또는 DB 부하 의심
CPU	15분 평균 90% 이상	P1	서비스 지연/장애 가능성
Instance status	unhealthy	P0	서버 장애 가능성
Disk usage	80% 이상	P2	로그/DB 증가 확인
Disk usage	90% 이상	P1	쓰기 실패 가능성

CPU 50% 같은 낮은 기준은 알림이 아니라 대시보드 관측용으로 둔다. 초반에는 트래픽 패턴이 불안정하므로 낮은 임계치는 알림 피로를 만든다.

🐳 Docker 컨테이너 상태 감시

확인 명령:

docker compose ps
docker ps --format "table {{.Names}}\\\\t{{.Status}}\\\\t{{.Ports}}"

감시 대상:

• gateway/backend service container
• PostgreSQL container
• Redis container
• Nginx container
• monitoring agent container

알림 기준:

시나리오 기준 등급

container 종료	Exited 감지	P1
container unhealthy	healthcheck unhealthy	P1
restart 반복	5분 내 3회 이상 restart	P1
gateway/nginx 종료	외부 접근 불가 동반	P0

MVP에서는 1분 또는 5분 간격 cron checker로 상태를 확인하고, 이상 시 Slack webhook으로 전송한다.

🐘 PostgreSQL Healthcheck

PostgreSQL은 프로세스 생존보다 실제 접속 가능 여부가 중요하다.

pg_isready -h <DB_HOST> -p 5432 -U <DB_USER> -d <DB_NAME>

필요하면 다음 쿼리로 응답 지연을 확인한다.

select 1;

알림 기준:

시나리오 기준 등급

DB 접속 불가	pg_isready 실패 2회 연속	P0
DB 응답 지연	select 1 2초 이상 3회 연속	P1
disk 85% 이상	1회 감지	P1
migration 실패	배포 중 감지	P1

운영에서 추가로 볼 항목:

• connection 수
• slow query 여부
• disk 사용량
• backup/snapshot 여부
• migration 실패 여부

⚡ Redis Healthcheck

Redis는 인증/토큰, AI rate limit 같은 보조 흐름에 영향을 준다. Redis 장애는 전체 서버 down이 아니더라도 로그인, 인증, AI 품질 저하로 이어질 수 있다.

redis-cli -h <REDIS_HOST> -p 6379 ping

정상 응답:

PONG

알림 기준:

시나리오 기준 등급

Redis 접속 불가	PING 실패 2회 연속	P1
Redis 접속 불가 + 로그인/API 장애 동반	같은 5분 구간	P0
Redis memory 80% 이상	10분 지속	P2
evicted keys 증가	10분 지속	P2
rejected connections 발생	5분 내 반복	P1

AI fallback 증가 여부는 이 문서에서 직접 판단하지 않고, 사용자/제품 로그 또는 AI 품질 대시보드에서 함께 확인한다.

🌐 외부 Uptime Check

외부에서 실제 서비스 접근 가능 여부를 확인한다.

추천 체크:

• GET https://<domain>/actuator/health
• GET https://<domain>/
• GET https://<domain>/share/<shareId> 또는 public share page

MVP에서는 무료/저비용 외부 uptime check 1개만 붙인다.

후보:

• UptimeRobot
• Sentry Uptime
• Grafana Cloud Synthetic Monitoring
• GitHub Actions scheduled curl

💬 Slack 알림 형식

자동 알림 채널은 #polaris-alerts를 기본 후보로 둔다.

메시지 최소 필드:

필드 예시

Severity	P1
Target	redis
Scenario	Redis healthcheck failed
Time	2026-05-22 15:20 KST
Evidence	redis-cli ping failed 2 times
First Check	docker compose ps redis, redis-cli ping, check redis logs

장애 등급별 담당자, 확인 순서, 복구 절차는 Runbook에서 관리한다.

💸 비용 최소화 전략

MVP에서 바로 하지 않아도 되는 것:

• 모든 로그를 외부 SaaS로 전송
• 전체 distributed tracing
• 긴 retention의 log indexing
• 고가의 APM 도구
• 자동 복구 시스템

우선 할 것:

• Lightsail 기본 metric alarm
• 외부 uptime check
• Docker/Redis/PostgreSQL cron healthcheck
• Slack webhook
• gateway Actuator health 연동
• 백업/snapshot 주기 확인

✅ MVP 구현 체크리스트

• [ ] Lightsail CPU/status 알림 설정
• [ ] disk usage checker 작성
• [ ] docker compose ps 기반 container checker 작성
• [ ] PostgreSQL pg_isready checker 작성
• [ ] Redis PING checker 작성
• [ ] 외부 uptime check 설정
• [ ] Slack webhook secret 등록
• [ ] 인프라 알림을 Runbook 시나리오와 연결
• [ ] 백업/snapshot 주기 결정

🔗 연결 문서

• 🚨 장애 등급, 담당자, 대응 절차는 Runbook에서 관리한다.
• 📈 HTTP latency, 5xx, JVM metric은 애플리케이션 메트릭 문서에서 관리한다.
• 📊 AI fallback, 제품 funnel, 보상 정합성은 사용자/제품 로그 문서에서 관리한다.
• 🧪 Synthetic traffic과 부하 실험은 Synthetic Data 문서에서 관리한다.

🗣️ 팀 논의 필요 항목

1. Lightsail 서버 구성이 app/db 분리인지 단일 서버인지
2. Docker Compose healthcheck를 어느 서비스까지 추가할지
3. Slack webhook을 누가 만들고 secret을 어디에 둘지
4. 외부 uptime check 도구를 무엇으로 할지
5. Redis 장애를 단독 P1로 볼지, 인증 장애 동반 시 P0로 볼지
6. disk usage 알림을 어떤 방식으로 구현할지
7. 백업/snapshot 주기를 어떻게 둘지