day-log

요즘 팀 슬랙에 EKS 노드 스케일 아웃 후 파드가 Running까지 도달하는 데 걸리는 시간 얘기가 자주 올라온다. GPU 노드에 20GB짜리 추론 이미지를 올려야 하는데, 이미지 pull에만 3분 넘게 걸린다. 트래픽 스파이크가 오고 나서야 노드가 뜨기 시작하면 사실상 늦다.이 문제 해결책으로 몇 년 전부터 계속 언급되는 게 lazy pulling이다. 이미지 전체를 미리 받지 않고, 컨테이너가 실제로 파일을 요청할 때만 해당 range를 원격 registry에서 가져다가 마운트해주는 방식. 개념은 단순한데 내부 동작이 꽤 재밌어서 이번에 SOCI(Seekable OCI) snapshotter 코드를 좀 뜯어봤다. 정리해둔다.OCI 이미지가 어떻게 생겨먹었길래 lazy pulling이 되는가우선 왜 ..

지난 주 화요일 아침에 백엔드 팀장이 슬랙 DM으로 물어봤다. "요즘 CI가 왜 이렇게 느려요? 예전에는 8분이면 됐는데 요새는 20분 넘게 걸리는 것 같은데." 확인해보니 정말 그랬다. Go 서비스 하나의 build job이 12분에서 19분으로 늘어나 있었다. 뭐 변경한 것도 없는데.내가 저 CI를 마지막으로 만진 게 6월 초였다. --mount=type=cache를 붙여서 Go module 다운로드를 캐싱하도록 바꿨다. 그때는 확실히 빨라졌다. 첫 빌드가 14분, 두 번째부터는 5분대. 팀 슬랙에 자랑까지 했다. 그런데 한 달 반이 지난 지금은 20분이 나오고 있었다.처음엔 러너 탓인 줄 알았다첫 번째 추측은 GitHub Actions runner가 지역별로 느려졌나 하는 것이었다. 요새 self-..

COPY --link 얘기는 한 2년 전부터 컨퍼런스마다 단골 메뉴였다. "그냥 다 붙여라, 캐시 효율이 미친다"는 식의 글도 많고. 우리 팀도 어느 순간부터 거의 자동 반사처럼 모든 COPY 앞에 --link를 박아 넣고 있었다. 근데 최근에 좀 다른 얘기가 돌더라.올해 2월에 Depot 블로그에서 "왜 COPY --link 쓰지 말아야 하는지"라는 글이 올라와서 한 번 더 시끌시끌했다. 한 줄로 요약하면 "BuildKit이 --link 레이어를 다루는 방식 때문에 오히려 빌드가 느려지는 케이스가 꽤 있다"는 거. 우리 팀에서도 비슷한 케이스를 한 번 만난 적이 있어서 정리해둔다.--link가 손해 보는 케이스가장 흔한 패턴이 이거다.FROM node:20-alpine AS buildWORKDIR /a..