본문 바로가기

Project

[GitHub Actions] GitHub Actions에서 gradle 캐싱하기

현재 진행하고 있는 쇼핑몰 프로젝트에서 GitHub Actions를 통해 CI를 구축했다.

젠킨스처럼 별도의 젠킨스 서버를 구축하지 않아도 되고, Travis CI처럼 유료 전환이 되는 것도 아닌 점이 큰 장점이다.

왜 gradle을 캐싱해서 사용할까?

gradle은 빌드할 때 의존성 패키지들을 모두 다운받는다.

(이때 gradle은 빌드 시간과 네트워크 통신을 줄이기 위해 의존성 패키지를 캐싱해서 재사용하는 방법을 사용한다.)

 

하지만 GitHub Actions의 workflow는 매 실행마다 새로운 환경을 구축하고, 매번 새롭게 의존성 패키지들을 가져와야 한다.이는 전체 빌드 시간의 증가로 이어진다.

 

또한 이런 반복되는 작업은 리소스가 낭비되며, 요금 청구가 늘어날 수 있다. GitHub Actions는 2000분~3000분의 시간만을 무료로 제공하기 때문에 리소스 사용을 아껴야 할 필요가 있다.

workflow의 작업들이 늘어나고 CI 과정 중 테스트 케이스가 많아질수록, CI 시간을 줄이기 위한 방법을 찾아야 한다.

 

그러므로, 빌드 시간의 단축을 위해서 우리는 GitHub Actions의 actions/cache를 사용하여

반복적으로 사용되는 gradle의 의존성에 대해서 캐싱할 수 있다.

gradle.yml 파일

 

  • path: 캐시의 저장과 복원에 사용되는 runner 내 파일 경로.
  • key: 캐시를 저장하고 복원하는 데에 사용되는 키. 여러 값들을 조합해서 512자 제한으로 생성할 수 있음.
  • restore-keys: 내가 설정한 key로 cache miss가 발생할 때, 사용할 수 있는 후보 키들.

gradle 캐싱 사용할 때의 성능 최적화

gradle 캐싱을 하지 않았을 때의 소요시간이다.

 

이번에는 gradle 캐싱을 적용했을 때의 소요시간이다.

 

2분 23초가 소요되던 CI 시간이 1분 11초로 감소된 것을 알 수 있다. 만약 더 많은 테스트 케이스를 추가하거나 실제 실무 환경에서는 CI 시간이 증가할수록 빌드 캐시를 통한 최적화는 더 크게 체감될 것이다.

만약 1번 실행할 때마다 10분을 줄일 수 있고, 하루 평균 100번씩 돌아간다고 하면 리눅스 서버 기준 하루에 8~256달러 정도의 비용을 아낄 수 있다.

 

즉, CI 속도 개선 필요성은 빌드 시간이 더 빨라진다는 편리함, 성능 최적화말고도

인프라 비용 절감, 제품 개발 생산성 향상(코드 변경사항 반영 시간이라거나 피드백 받을 시간이 단축되기 때문에 개발자들의 이슈 대응 속도가 향상) 등에 이유가 있다.

 

 

 

출처

https://devjem.tistory.com/76

'Project' 카테고리의 다른 글

TDD  (0) 2024.05.19
JPA Batch Size  (1) 2024.04.28