기본 콘텐츠로 건너뛰기

라벨이 restore-keys 전략인 게시물 표시

GitHub Actions 캐시 무효화로 CI 시간이 폭증한 사례와 대응 가이드

GitHub Actions 캐시 무효화로 CI 시간이 폭증한 사례와 대응 가이드 AI 생성 이미지: GitHub Actions에서 캐시 무효화로 CI 시간이 폭증한 사례 사건 개요 — GitHub Actions에서 캐시 무효화로 CI 시간이 폭증한 사례 한 조직에서 갑작스럽게 GitHub Actions 파이프라인 실행 시간이 몇 분에서 수십 배로 늘었습니다. 원인은 의도치 않은 캐시 무효화였습니다. 반복해서 생성되던 의존성과 빌드 아티팩트가 매 실행마다 다시 내려받아지고 재생성되면서 전체 워크플로가 지연되었습니다. 증상: 캐시 히트율이 급격히 떨어졌고, 개별 잡 실행 시간이 10분에서 1시간 이상으로 늘었습니다. 동시에 실행 대기열(백로그)이 누적되었습니다. 영향 범위: PR 병합 지연과 배포 파이프라인 정체가 발생했습니다. 빌드 자원·네트워크 비용이 증가했고, 개발 생산성이 저하되었습니다. 발생 시점·배경: 특정 커밋에서 캐시 키 포맷이 변경되거나 외부 의존성의 버전 정책이 바뀐 직후에 문제가 시작되었습니다. 캐시 보존 정책과 용량 한계가 결합하며 문제는 빠르게 확산되었고, 실무 체크리스트로는 — 캐시 키 변경 시 영향 범위 검토(네이밍 표준화 포함), 보존 정책·사이즈 제한 문서화, CI 실행 전 캐시 히트율 모니터링을 권장합니다. GitHub Actions 캐시의 동작 원리와 제한사항 actions/cache는 워크스페이스 파일을 키(key)로 구분해 GitHub 백엔드에 업로드하고, 필요할 때 해당 키로 다운로드합니다. 정확히 일치하는 키가 있으면 그 캐시를 우선 복원합니다. 일치하는 키가 없다면 restore-keys 목록을 위에서부터 순서대로 탐색해 접두사가 일치하는 첫 항목을 사용합니다. restore-keys는 완전 일치 실패에 대비한 그레이스케일 복원 전략이며, 여러 캐시를 병합해 복원하는 기능은 아닙니다. 업로드는 '마지막 쓰기 우선(Last write wins)' 방식입니다. 동시 ...