OOM-killed 방지하는 Puppeteer 메모리 프로파일링 전략

Context

Puppeteer 사용 시 시간이 지남에 따라 RSS 메모리가 지속적으로 증가하는 현상 발생. 단순한 추측이 아닌 Heap Snapshot 분석을 통한 실제 누수 지점 식별 필요. Node.js 프로세스가 아닌 Chrome 자식 프로세스 중심의 메모리 관리 한계 존재.

Technical Solution

• process.memoryUsage()를 통해 rss, heapUsed, heapTotal, external 등 네 가지 핵심 지표를 실시간 추적하는 모니터링 구조 설계
• JSONL 파일 기반의 시계열 데이터 기록 방식으로 메모리 증가 추이와 요청 수 간의 상관관계 분석
• 브라우저 실행 전, 후, Warm-up 단계별 Baseline 수치를 설정하여 비정상적인 메모리 점유 시점 식별
• 특정 요청 주기마다 Heap Snapshot을 캡처하고 Chrome DevTools에서 스냅샷 간 차이를 비교하는 객체 추적 전략
• 코드상 누수가 없는 경우 Chrome 자체의 메모리 파편화 해결을 위해 일정 요청 수마다 브라우저를 재시작하는 Recycling 전략 도입

Impact

• Baseline RSS: 실행 전 50-80MB $\rightarrow$ 실행 후 150-250MB $\rightarrow$ Warm-up 후 160-270MB
• Baseline Heap Used: 실행 전 15-25MB $\rightarrow$ 실행 후 25-40MB $\rightarrow$ Warm-up 후 30-45MB

Key Takeaway

추측이 아닌 정량적 측정과 스냅샷 비교를 통한 데이터 기반의 디버깅 원칙 준수. 애플리케이션 레벨의 최적화 한계 시 인프라 수준의 리사이클링이나 외부 관리형 서비스 도입을 고려하는 실용적 설계 접근.