피드로 돌아가기
Dev.toInfrastructure
원문 읽기
단일 체크 기반 Watchdog의 오판 방지를 위한 Retry 메커니즘 도입
Why "is it fully fixed?" has no honest answer — a small-server story
AI 요약
Context
1GB RAM 및 Single Core 환경의 VPS에서 API 서비스 운영 중 자원 고갈로 인한 가용성 문제 발생. 단순 Health Check 기반의 자동 재부팅 Watchdog 구조가 CPU Spike 상황을 서버 다운으로 오인하여 불필요한 Hard-reboot를 유발하는 설계적 한계 노출.
Technical Solution
- 단일 요청 실패 시 즉시 장애로 판정하던 로직을 3회 연속 실패 시에만 장애로 정의하는 Retry 전략으로 변경
- 10초 Timeout 설정 및 요청 간 10초의 Sleep Interval을 추가하여 일시적 Resource Starvation 상황에서의 회복 시간 확보
- 전체 30초 이상의 관찰 Window를 구축하여 Transient Spike와 실제 Deadlock 상태를 구분하는 판정 기준 수립
- 고부하 작업(ffmpeg 등)의 실행 환경을 분리하여 메인 서비스의 Resource Isolation 확보
- '완벽한 해결'이라는 정적 관점에서 '탐지 및 복구 가능성'이라는 동적 관점으로 모니터링 설계 패러다임 전환
실천 포인트
1. Health Check 실패 시 즉시 액션을 취하기 전, 최소 3회 이상의 Retry 및 적절한 Backoff Interval을 설정했는가?
2. 모니터링 도구 자체가 시스템의 가용성을 해치는 Single Point of Failure(SPOF)가 될 가능성을 검토했는가?
3. CPU/Memory 집약적 작업이 API 응답 성능에 영향을 주지 않도록 Resource Isolation이 구현되어 있는가?
4. 장애 복구 시 '완전한 해결'이 아닌 '빠른 탐지와 가역적 롤백' 관점에서 설계를 검증했는가?