[CI] Github Actions CI 적용하기 #5 - Github Cache 활용하여 의존성 설치시간 줄여보기

이전 포스트까지 해서 Github Actions 테스트 실행 스크립트를 작성해 보았다.

https://hoplin-dev.tistory.com/7

[CI] Github Actions CI 적용하기 #4 - 설계내용 적용하기 & PR Merge 이전 테스트 강제하기

이전 포스트 사진에 캡쳐 사진을 보면 Workflow duration이 4m 27s로 되어있다. 하지만 이는 기존에 약 4m 55s 정도 걸리던 CI의 실행시간을 줄인것이다.

 

Github Actions의 속도를 올리기 위해 Document를 찾다보니, Caching dependencies to speed up workflows라는 문서를 발견하게 되었다.

일반적으로 사용되는 패키지 매니저를 나열해보면, Java의 Maven, Gradle, Node.js의 npm, yarn 등이 있다. 그리고 이 패키지 매니저들은 다운로드한 의존성 패키지들에 대해 local cache를 저장하게 된다. 필자가 주로 사용하는 yarn을 기준으로 로컬 캐시를 확인해본다.

(yarn cache)(npm cache). 

 

간단하게 yarn의 cache가 저장되는 곳과, 실제 cache가 저장되는것을 출력해본다.

// Yarn의 캐시 디렉토리
yarn cache dir

// Yarn 캐시 출력. --pattern을 추가하면, pattern의 이름을 가진 패키지들에 대한 캐시를 불러온다.
yarn cache list --pattern nest

 

간단히 yarn/npm 캐시에 대해 짚고 넘어가자면, 여러개의 패키지 의존성을 설치할때 캐시 내에 있는 패키지는 다운로드 하지 않고, 캐시에 존재하는 패키지를 가져온다. 이를 통해 의존성 다운로드시, 실질적으로 다운로드해야하는 패키지 수를 줄일 수 있는것이다. 아래 사진을 보면 패키지들이 버전별로 설치되어 디렉토리 형태로 존재하는것을 볼 수 있다.

 

Github Action Workflow가 실행될때마다, 새로운 Runner환경이 실행된다. 그렇기 때문에 위와같은 패키지 매니저의 캐시는 매번 삭제되게 된다. 일일히 실행될때마다. 패키지 매니저 캐시가 존재하지 않기때문에 모든 의존성들은 매번 다시 다운로드 되게 된다. Github Action 중에 Cache Actions라는것이 있다. 이 Action을 통해서 고유 ID 식별된 캐시를 생성하고, 복원한다.

 

Cache Actions를 직접 사용해도 좋지만, 만약 기존 프로그래밍 언어 런타임 Setup Action을 사용한다면 각 Action에서 내부적으로 Cache Actions를 활용해 캐싱을 지원한다. 아래 사진은 지원되는 Setup Action 리스트들이다.

 

필자의 프로젝트에서 활용하는 Setup Node의 Caching global package data를 참고하자. 이 문서를 보면 actions/setup-node@v4에 cache필드(optional)에 사용할 패키지 매니저를 지정해주면된다.(npm, yarn, pnpm만 지원) 이를 활용하면 종속성 파일(pacakge-lock.json, yarn.lock)을 검색한 후 종속성 파일의 해시를 캐시 키의 일부로 사용한다.

만약 package.json이 프로젝트 루트 디렉토리에 없거나 여러개를 활용하는 경우에는 cache-dependency-path필드를 통해 경로를 지정해준다.(Docs)

이제 프로젝트의 Github Action에 적용해본다. 현재 프로젝트는 yarn을 패키지 매니저로 사용하기 때문에, Build & Setup Step의 actions/setup-node@v4에 캐시를 적용해준다. 

      # Setup environment for Node.js 18
      - name: Node.js version 18 Environment setting
        uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn

다른 Job에서는 적용하지 않은 이유는 의존성 설치에서는 Build & Setup Job에서만 이루어지고 이 Artifact를 통해 다른 Job들에게 공유하는 방식으로 설계하였기 때문이다. 적용 후에 비교를 해보면 의존성 설치 step에서 실제로 약 30초정도의 시간 감소 효과가 있는것을 볼 수 있었다.

이를 적용한 후, Artifact를 공유하는 시간이 만약 Cache를 활용하여 의존성을 설치하는 시간보다 더 높으면 Cache를 활용해 모든 Job에서 의존성 설치하는것이 더 효율적이지 않을까? 라는 생각을 해보았다.

여기서 추가로 생각해야하는 조건은 모든 Job에서 의존성을 설치하게 된다는것은 애플리케이션 빌드 또한 모든 Job에서 다시 실행해야하는 것이다. 우선 Build & Setup을 보면 의존성 설치와 빌드 step 합쳐서 16초정도 되는것을 볼 수 있었다.

그리고 Artifact를 Runner에 다운로드 하는 속도는 약 9~10초정도 걸린다.

이를 통해 일일히 의존성 설치하는것보다, 빌드된 Artifact를 공유하는것이 더 빠르다는 결론을 낼 수 있다.

 

그럼에도 불구하고 만약 빌드된 애플리케이션 자체의 용량이 높아진다면, 반대의 결과가 나올 수 도 있지않을까? 라는 생각이 든다. 그렇기에 프로젝트 성격에 따라 유동적인 방법 채택이 중요하다는 생각이 들었다.

 

지금까지 총 5개의 글로 나눠 Github Actions를 파악하고, 실제 프로젝트에 활용할 Github Action Workflow에 대해 고민, 설계하고 Workflow 정의 이후 속도 최적화도 진행해 보았다. 다음에는 Circle CI를 활용해 CI를 구축해본 경험을 공유해볼 예정이다.

 

아래 링크는 이 시리즈에서 작성한 Github Actions이 적용된 프로젝트이다.

https://github.com/J-Hoplin/Online-Judge-System