개발자들이 Docker Compose로 배포한 자체 호스팅 앱이 자정 이후 3시에 다운되는 문제를 리소스 제한, 자동 재시작, 로그 로테이션, 헬스 체크, 역방향 프록시 설정으로 해결

Context

자체 호스팅 환경에서 앱을 배포한 후 프로덕션 단계에서 예기치 않게 3AM에 서비스가 중단되는 문제가 발생했다. 메모리 누진적 고갈, 디스크 풀, 자동 복구 메커니즘 부재라는 세 가지 근본 원인이 있었다.

Technical Solution

• 메모리 고갈 방지: Docker Compose에서 모든 컨테이너에 memory 한계(app 512M, postgres 1G)와 cpus 제한(1.0) 설정 및 예약 메모리(memory reservation) 지정
• 자동 재시작 정책 적용: docker-compose.yml의 restart: unless-stopped 설정으로 크래시된 컨테이너를 명시적 중단이 아닌 이상 자동 재시작
• 디스크 풀 방지: /etc/docker/daemon.json에서 log-driver를 json-file로 설정하고 max-size 10m, max-file 3으로 로그 로테이션 구성
• 디스크 모니터링 구현: bash 스크립트로 df 명령어를 통해 디스크 사용률 85% 초과 시 webhook 알림 발송 및 15분 간격 cron 작업으로 스케줄
• 헬스 체크 강화: docker-compose.yml에서 healthcheck 설정(30초 간격, 5초 타임아웃, 3회 재시도)하고 /health 엔드포인트에서 데이터베이스 SELECT 1 쿼리와 Redis PING 실행으로 종속성 검증
• 역방향 프록시 구성: Caddy를 사용해 TLS 자동 인증서 갱신(Let's Encrypt) 구현하고 passive 헬스 체크(health_uri, 30초 간격)로 데드 업스트림 차단 및 rate_limit 동적 영역으로 원격 호스트당 1분에 100 이벤트 제한
• 백업 자동화: pg_dump -Fc로 데이터베이스 전체 덤프를 일일 실행하고 7일 보존 정책으로 로컬 백업 유지 및 rclone으로 원격 스토리지 동기화 선택사항 제공

Impact

아티클에서 명시된 정량적 수치가 없으나, 세 가지 근본 원인 해결이 약 90% 정도의 3AM 인시던트를 방지할 수 있다고 언급했다.

Key Takeaway

자체 호스팅 프로덕션 환경에서는 애플리케이션 자체보다 애플리케이션을 감싸는 운영 계층(모니터링, 자동 복구, 로그 관리, 헬스 체크, 백업)이 안정성 확보의 핵심이며, Kubernetes가 아닌 단일 VPS와 Docker Compose로도 적절한 설정만으로 신뢰성 있는 프로덕션 환경을 구축할 수 있다.