현재 진행하고 있는 쇼핑몰 프로젝트에서 GitHub Actions를 통해 CI를 구축했다.
젠킨스처럼 별도의 젠킨스 서버를 구축하지 않아도 되고, Travis CI처럼 유료 전환이 되는 것도 아닌 점이 큰 장점이다.
왜 gradle을 캐싱해서 사용할까?
gradle은 빌드할 때 의존성 패키지들을 모두 다운받는다.
(이때 gradle은 빌드 시간과 네트워크 통신을 줄이기 위해 의존성 패키지를 캐싱해서 재사용하는 방법을 사용한다.)
하지만 GitHub Actions의 workflow는 매 실행마다 새로운 환경을 구축하고, 매번 새롭게 의존성 패키지들을 가져와야 한다.이는 전체 빌드 시간의 증가로 이어진다.
또한 이런 반복되는 작업은 리소스가 낭비되며, 요금 청구가 늘어날 수 있다. GitHub Actions는 2000분~3000분의 시간만을 무료로 제공하기 때문에 리소스 사용을 아껴야 할 필요가 있다.
workflow의 작업들이 늘어나고 CI 과정 중 테스트 케이스가 많아질수록, CI 시간을 줄이기 위한 방법을 찾아야 한다.
그러므로, 빌드 시간의 단축을 위해서 우리는 GitHub Actions의 actions/cache를 사용하여
반복적으로 사용되는 gradle의 의존성에 대해서 캐싱할 수 있다.

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

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

2분 23초가 소요되던 CI 시간이 1분 11초로 감소된 것을 알 수 있다. 만약 더 많은 테스트 케이스를 추가하거나 실제 실무 환경에서는 CI 시간이 증가할수록 빌드 캐시를 통한 최적화는 더 크게 체감될 것이다.
만약 1번 실행할 때마다 10분을 줄일 수 있고, 하루 평균 100번씩 돌아간다고 하면 리눅스 서버 기준 하루에 8~256달러 정도의 비용을 아낄 수 있다.
즉, CI 속도 개선 필요성은 빌드 시간이 더 빨라진다는 편리함, 성능 최적화말고도
인프라 비용 절감, 제품 개발 생산성 향상(코드 변경사항 반영 시간이라거나 피드백 받을 시간이 단축되기 때문에 개발자들의 이슈 대응 속도가 향상) 등에 이유가 있다.
출처
'Project' 카테고리의 다른 글
TDD (0) | 2024.05.19 |
---|---|
JPA Batch Size (1) | 2024.04.28 |