기본 콘텐츠로 건너뛰기

라벨이 cache TTL 거버넌스인 게시물 표시

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)' 방식입니다. 동시 ...