배경:
- frontend build 의 가장 큰 시간 소비 = runner stage 의 COPY node_modules (12분 16초)
- 전체 21분 34초 중 57%
- next.config.mjs 의 output: "standalone" 가 prod 빌드에서 이미 활성 상태였으나, Dockerfile 의 runner stage 가 .next 통째 + node_modules 통째를 COPY 하느라 standalone 결과물 미활용
조치:
- runner stage 재작성:
- .next 전체 → .next/standalone (server.js + 실제 사용 node_modules)
- .next/static 별도 COPY (standalone 가 자동 포함 안 함)
- public 별도 COPY (standalone 가 자동 포함 안 함)
- node_modules 통째 COPY 제거 (standalone 가 알아서 포함)
- package.json COPY 제거 (server.js 직접 실행)
- CMD: npm start → node server.js
검증:
- frontend 에 dynamic require/import 0건 (정적 import 만) → standalone 의존성 추적 정확
- prisma 가 package.json 에 있으나 코드 import 0건 → 자연 제외, 추가 설정 불필요
예상 효과:
- 빌드 시간 21m 34s → 약 9분 (12분 단축, 57% 감소)
- 이미지 크기 약 1GB → 약 300MB (70% 감소)
- pull 시간 단축
- runtime memory footprint 감소
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
main 의 최근 8연속 build 실패 (run 113~120) 원인이 docker build 단계의 OOM Killed.
진단:
- wace 호스트 32GB / available 24GB 충분, 시스템 OOM 기록 없음
- act_runner systemd MemoryMax=infinity, config container.options=null (제한 없음)
- 그러나 Next.js build V8 heap spike (5-8GB+) 가 다른 30개 동시 가동 서비스 (k3s/mailu/nextcloud/mattermost 등) 와 충돌
- Committed_AS 21.6 GB / Limit 24.8 GB 한계 — page touch 시 oom-killer 가 build process kill
- 결과: 28분 빌드 후 Killed → 8연속 main 배포 실패
조치:
- builder stage 에 NODE_OPTIONS=--max-old-space-size=4096 명시 → V8 heap 4GB 로 cap
- build process 가 알아서 절제 → OOM killer 트리거 안 됨
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
빌드 컨텍스트 변경에도 운영 frontend chunk 에 신규 라우트가 들어가지
않는 증상 발견. Kaniko/Docker layer cache 가 npm run build 단계를
잘못된 시점에 hit 하는 것으로 의심. GIT_SHA build-arg 를 npm run build
직전에 주입해 매 commit 마다 그 layer 부터 강제 invalidate.
또 진단 step 에 deploy 이미지 tag 표시 추가 — 새 image 로 갱신
됐는지 즉시 확인 가능.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
johngreen
chpark
gbpark