GitLab CI/CD 캐싱
GitLab CI/CD 캐싱 (Caching)
잡을 실행할 때마다 인터넷에서 패키지를 다시 받는 건 낭비예요. 그래서 GitLab은 자주 쓰는 데이터를 재사용하도록 캐시를 지원합니다. 캐시를 잘 쓰면 의존성 설치 시간을 크게 줄일 수 있어요.
캐시와 아티팩트, 어떻게 다를까
캐시와 아티팩트는 둘 다 파일을 저장해 재사용하지만, 용도가 달라요. 캐시는 인터넷에서 내려받는 패키지 같은 의존성을 위한 것이고, 아티팩트는 스테이지 사이에 넘길 중간 빌드 결과물을 위한 것이죠.
- 캐시: GitLab Runner가 설치된 곳에 저장되고, 분산 캐시가 켜져 있으면 S3에 업로드돼요.
- 아티팩트: 잡이 만들어 GitLab에 저장되고, 필요할 때 내려받을 수 있어요.
둘 다 경로를 프로젝트 디렉터리 기준으로 정의한다는 공통점이 있고, 그 밖의 파일을 가리키는 건 안 돼요.
캐시의 특징
cache키워드로 잡마다 정의해요. 지정하지 않으면 비활성화됩니다.- 뒤따르는 파이프라인들이 캐시를 쓸 수 있어요.
- 의존성이 동일하다면 같은 파이프라인의 뒤따르는 잡도 캐시를 쓸 수 있어요.
- 서로 다른 프로젝트끼리는 캐시를 공유하지 못해요.
- 기본적으로 보호된 브랜치와 보호되지 않은 브랜치는 캐시를 공유하지 않습니다.
아티팩트의 특징
- 잡마다 정의해요.
- 같은 파이프라인의 뒤쪽 스테이지에 있는 잡들이 사용할 수 있어요.
- 기본적으로 30일이 지나면 만료되는데, 만료 시간을 직접 정할 수도 있어요.
- '최신 아티팩트 보관'을 켜면 최근 아티팩트는 만료되지 않아요.
dependencies로 어떤 잡의 아티팩트를 가져올지 제어할 수 있어요.
좋은 캐싱 관행
캐시를 효과적으로 쓰려면 두 가지 방향을 고려해요.
- 모든 잡에 단일 러너를 사용하기. 그러면 캐시가 한 곳에 모여 있어서 재사용률이 높아져요.
- 분산 캐시를 지원하는 여러 러너를 쓰기. 캐시를 S3 버킷에 저장하는 방식이죠. GitLab.com의 인스턴스 러너가 이렇게 동작합니다. 이런 러너들은 autoscale 모드일 수도 있고 아닐 수도 있어요.
캐시가 어디에 저장될까
한 잡에 정의된 모든 캐시는 하나의 cache.zip 파일로 묶여요. 파일이 저장되는 위치는 러너 설정이 정하는데, 기본값은 GitLab Runner가 설치된 머신의 로컬이고 실행기 종류에 따라 달라지죠. 예를 들어 Docker 실행기라면 /var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip처럼 Docker 볼륨 아래에 저장됩니다.
압축·추출이 일어나는 순서
파이프라인이 시작되면 job A가 실행되고, 캐시가 있으면 먼저 추출돼요. 그다음 before_script, script, after_script가 순서대로 실행되고, 마지막에 cache가 vendor/ 디렉터리를 cache.zip으로 압축해 러너 설정과 cache: key에 따라 저장합니다. 뒤의 job B가 실행될 때 그 캐시를 다시 추출해서 쓰는 구조예요.
캐시 지우기
러너가 캐시를 재사용하다 보면 때로는 동작이 어긋날 수 있어요. 새 캐시로 시작하고 싶다면 cache:key를 바꾸거나 직접 지우면 됩니다.
cache:key를 바꾸면 다음 파이프라인이 실행될 때 캐시가 다른 위치에 저장돼요.- GitLab UI에서는 Build > Pipelines 화면 오른쪽 위의 Clear runner caches를 선택하면 돼요. 다음 커밋부터 CI/CD 잡이 새 캐시를 사용합니다.