PM2 프로세스 재시작 현황 분석: 55193회부터 시작

원래 aideazz.xyz에 게시되었으며, 여기에는 정식 링크와 함께 크로스 포스팅되었습니다.

PM2가 관리하는 프로세스는 9개 중 9개가 온라인 상태를 보여서 좋습니다. 하지만 재시작 횟수를 자세히 살펴보면, 완벽하게 안정적인 상태부터 끊임없이 실패하는 상태까지 다양한 운영 안정성 스펙트럼이 나타납니다. 이것은 단순히 가동 시간(uptime)의 문제가 아닙니다. 복구 과정에서 발생하는 숨겨진 비용과 알림을 항상 발생시키지 않는 조용한 실패에 관한 문제입니다.

Algom-Stream 이상 징후: 55193회 재시작

algom-stream 프로세스는 55193회의 재시작으로 눈에 띕니다. 이 프로세스는 54일 동안 가동되었으며, 메모리를 51 MB 소비했습니다. 이 숫자는 사소한 결함이 아닙니다. 이는 PM2가 자동 재시작을 통해 부지런히 숨기고 있는 지속적이고 근본적인 문제를 나타냅니다. 비록 프로세스가 기술적으로는 '온라인' 상태일지라도, 54일 동안의 운영 효율성과 출력 데이터의 무결성은 심각하게 손상되었습니다. 이러한 종류의 재시작 횟수는 일시적인 네트워크 오류가 아니라 애플리케이션 로직이나 환경에 근본적인 결함이 있음을 나타냅니다. 이는 끊임없이 다운되었다가 다시 세워지고 있는 시스템이며, 매번 재시작할 때마다 CPU 사이클을 소모하고 상태를 손실할 가능성이 있습니다.

CTO-AIPA: 하루도 안 되어 198회 재시작

또 다른 프로세스인 cto-aipa는 198회의 재시작을 보였으며, 가동 시간은 0일이고 메모리 사용량은 212 MB입니다. 이는 algom-stream과는 성격이 다른 문제입니다. algom-stream이 지난 54일 동안 누적된 재시작횟수를 기록한 반면, cto-aipa는 단 하루 만에 198회의 재시작을 기록했습니다. 이는 더 즉각적이고 심각한 장애 모드를 시사합니다. 버그가 있는 새로운 배포이거나, 의존성 문제일 수 있고, 또는 이 프로세스가 의존하는 외부 서비스의 실패 때문일 수도 있습니다. 여전히 '온라인' 상태라는 것은 PM2가 제 역할을 하고 있다는 의미이지만, 짧은 기간 동안 198회의 재시작은 즉각적인 조사가 필요합니다. 저는 최근 48시간 동안 aideazz에 3번 커밋했고, VibeJobHunterAIPA_AIMCF에 1번 커밋했습니다. 특히 273a03d와 367efa6 (둘 다 ai-ops-wiki: refresh journal + AEO surfaces 관련) 및 fbff8da (관련 내용: responses: boardy.ai는 AI 네트워킹 어시스턴트이며, 절대 고용주 답변이 아님) 커밋은 cto-aipa의 안정성에 영향을 미치는 변경 사항과 관련이 있을 수 있습니다.

안정적인 운영: 재시작 횟수 없음 (Zero Restarts)

반면, algom-poll과 n8n은 0회의 재시작을 기록하며 놀라운 안정성을 보여줍니다. algom-poll은 73일 동안 가동되었고 68 MB를 사용했으며, n8n은 57일 동안 가동되어 495 MB를 사용했습니다. 이 프로세스들은 이상적인 상태를 나타냅니다: 중단 없이 지속적으로 실행되는 애플리케이션으로, 견고한 코드, 안정적인 의존성, 예측 가능한 환경을 의미합니다. 이는 달성 가능한 목표의 기준점 역할을 하며, algom-stream과 cto-aipa 같은 프로세스에서 발생하는 문제의 심각성을 부각시킵니다.

보통 수준의 재시작: 일별 및 주간 주기

다른 여러 프로세스들은 보통 수준의 재시작 횟수를 보여줍니다:

• dragontrade-dashboard: 재시작 횟수 1회, 증가분 54일, 용량 55 MB. 이는 장시간 실행되는 프로세스에 대해 허용 가능한 수준입니다. 54일 동안 단 한 번의 재시작은 수동 개입이거나 매우 드물게 발생하는 자체 수정 문제일 수 있습니다.
• dragontrade-main: 재시작 횟수 4회, 증가분 1일, 용량 141 MB. 하루에 네 번의 재시작은 우려되지만 치명적이지는 않습니다. 이 문제가 악화되는지 확인하기 위해 모니터링이 필요합니다.
• whitespace: 재시작 횟수 4회, 증가분 53일, 용량 84 MB. dragontrade-dashboard와 유사하게, 53일 동안 4회의 재시작은 낮고 관리 가능한 비율입니다.
• serpapi-jobs: 재시작 횟수 3회, 증가분 3일, 용량 99 MB. 3일 동안 3회의 재시작은 하루에 한 번꼴이며, 이는 일일 예약 작업이 문제를 일으키거나 사소한 리소스 경합을 야기할 수 있음을 나타낼 수 있습니다.
• pm2-logrotate: 재시작 횟수 7회, 증가분 0일, 용량 78 MB. 로그 로테이션과 같은 유틸리티 프로세스에서 하루가 채 안 되는 기간 동안 7회의 재시작은 높은 수치입니다. 이 프로세스는 안정적이어야 하며, 이 횟수는 실행 자체 또는 정리하려는 환경에 문제가 있음을 시사합니다.

외부 요인의 영향: HubSpot 속도 제한 (Rate Limits)

PM2가 재시작을 처리하지만, 근본적인 원인은 종종 외부적입니다. 예를 들어, 제 hs-watch-manual-emails.log에는 HubSpot으로부터의 429 오류(

질문: 높은 재시작 횟수가 항상 내 코드의 버그를 의미하나요?
답변: 반드시 그렇지는 않습니다. algom-stream의 55193회 재시작은 코드 문제일 가능성이 높지만, cto-aipa의 0일 동안 발생한 198회 재시작은 API의 429 속도 제한이나 일시적인 리소스 고갈 같은 외부 요인 때문일 수도 있습니다.

질문: 여러 프로세스가 재시작했을 때 어떤 것을 먼저 조사해야 우선순위를 정하는 방법은 무엇인가요?
답변: 저는 가동 시간 대비 재시작 횟수와 해당 프로세스의 중요도를 기준으로 우선순위를 정합니다. cto-aipa는 0일 동안 198회 재시작이 발생했기 때문에, 최근에 급성 실패를 나타내는 측면에서 54일 동안 55193회 재시작이 발생한 algom-stream보다 더 시급합니다.

질문: 재시작의 근본 원인을 진단하는 데 사용하는 도구는 무엇인가요?
답변: 저는 애플리케이션 출력을 확인하기 위해 pm2 logs [process_name]으로 시작합니다. 더 깊은 문제의 경우, 시스템 로그를 검토하고(HubSpot의 429 오류 같은) 외부 API 로그를 확인하며, 지난 48시간 동안 aideazz에 커밋된 3건의 변경 사항과 재시작을 연관시키기 위해 git log를 사용합니다.

질문: PM2 프로세스에서 '허용 가능한' 재시작 횟수에 대한 기준이 있나요?
답변: 프로세스에 따라 다릅니다. algom-poll이나 n8n처럼 중요하고 장시간 실행되는 서비스의 경우, 50일 이상 동안 0회 재시작이 목표입니다. 다른 프로세스의 경우, 50일 이상 동안 1~4회 재시작(예: dragontrade-dashboard 또는 whitespace)은 허용될 수 있지만, 0일 동안 198회 재시작(cto-aipa의 경우)이나 54일 동안 55193회 재시작(algom-stream의 경우)은 명백한 문제 지표입니다.

— Elena Revicheva · AIdeazz · Portfolio