장기 AI를 웹으로 제공하는 운영 소스에는 웹 앱과 전용 터널을 감시하는 watchdog이 있다. 공개 글에서는 실제 호스트 별칭, 포트, 개인 경로를 모두 제거하고 재사용 가능한 운영 원칙만 설명한다.
무엇을 따로 감시하는가
웹 프로세스가 존재하는지, 로컬 포트가 LISTEN인지, HTTP 경로가 기대한 상태를 반환하는지는 서로 다른 신호다. 터널도 프로세스 문자열만 보지 말고 반대편에서 실제 요청이 도달하는지 별도의 probe가 필요하다.
프로세스 복구
감시자는 먼저 현재 listener가 대상 앱의 프로세스인지 확인한다. 다른 서비스가 포트를 쓰고 있다면 무조건 종료하지 않고 운영자에게 알린다. 대상 앱이 죽었을 때만 독립 process group으로 재시작하고 로그 파일을 분리한다.
터널 복구
암호화 터널은 키 인증과 최소 권한 계정을 사용한다. 실제 운영의 원격 주소와 포트 mapping을 코드·게시글·로그에 노출하지 않는다. 실패하면 즉시 무한 반복하지 말고 지수 backoff, 최대 재시도와 냉각 시간을 둔다.
heartbeat
마지막 정상 확인, 최근 재시작, 연속 실패 수와 현재 모드를 작은 상태 파일이나 metric으로 기록한다. heartbeat 파일이 갱신되지 않는 경우는 watchdog 자체의 장애이므로 외부 감시가 필요하다.
안전한 종료
SIGTERM을 먼저 보내고 유예 시간 뒤에도 남은 자신의 child만 종료한다. `pgrep` 문자열 하나로 광범위한 프로세스를 죽이면 다른 서비스가 중단될 수 있다. PID, 작업 디렉터리와 실행 명령을 함께 검증한다.
관련 소스에서 얻은 교훈
- 앱 readiness와 단순 포트 확인을 구분한다.
- 개발 서버와 production 서버를 자동으로 혼용하지 않는다.
- 재시작 요청과 자동 복구를 감사 가능한 이벤트로 남긴다.
- 터널 장애가 AI 이외의 게시판 기능까지 멈추지 않게 한다.
댓글
0개아직 댓글이 없습니다.