[GitHub Action] actions/cache 기능을 통한 데이터 캐싱
GitHub Action의 GitHub Actions의 workflow는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.
GitHub Actions에는 CI/CD 작업을 위해 다양한 기능이 있으며 이번에 테스트할 기능은 actions/cache 기능입니다. actions/cache 기능은 workflow 간에 파일을 캐싱하고 공유할 수 있습니다.
개요
GitHub Actions의 actions/cache는 workflow 간에 파일을 캐싱하여 실행 시간을 줄입니다. 사용자는 key와 path를 설정하여 캐시를 구성하며, 동일한 key가 있을 경우 기존 캐시를 재사용합니다. actions/cache 기능을 통해 의존성 다운로드, 빌드 결과 캐싱 등에 사용할 경우 유용합니다.
- name: Cache node modules
uses: actions/cache@v2
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-Cache Hit & Miss
GitHub Actions에서 actions/cache를 사용할 때, "Cache Hit"과 "Cache Miss"는 중요한 개념입니다.
- 캐시 히트(Cache Hit)
- 요청한 key로 캐시가 이미 존재하면, 해당 캐시가 사용됩니다. 이 경우 새 캐시를 생성하지 않고, 기존 캐시를 사용하여 작업을 빠르게 진행할 수 있습니다.
- 캐시 미스(Cache Miss)
- 요청한 key로 캐시가 존재하지 않으면, 새로운 캐시가 생성됩니다. 작업이 완료된 후, 지정된 path에 있는 파일들이 새 key와 함께 캐시됩니다.
actions/cache를 사용할 때, 적절한 key 전략을 수립하는 것이 중요합니다. 이미 존재하는 key 값으로 새로운 데이터를 캐싱할 경우 Cache Hit가 발생하며 새 캐시를 생성하지 않습니다.
따라서 새로운 데이터는 캐싱되지 않고 기존에 캐시한 데이터를 불러오도록 동작합니다. 그러므로 key는 고유한 값을 가지도록 파일의 해시값, 사용된 의존성 목록, 환경변수 등을 포함하여 구성됩니다. 이는 key의 고유성을 보장하고, 적절한 시점에 Cache Hit 또는 Miss를 발생시키는 데 사용될 수 있습니다.
Cache Hit은 성능을 최적화하는 반면, Cache Miss는 캐시를 최신 상태로 유지하고, 변경사항을 반영할 수 있는 기회를 제공합니다.
사용 범위 및 제한 사항
사용 범위
- 의존성 캐싱
- node_modules, vendor/bundle, .pip 등과 같은 의존성 디렉터리를 캐시하여, 매번 의존성을 설치하는 시간을 절약할 수 있습니다.
- 빌드 캐싱
- 빌드 과정에서 생성되는 아티팩트(예: 컴파일된 소스코드)를 캐시하여, 변경되지 않은 부분은 다시 빌드하지 않도록 할 수 있습니다.
- 테스트 캐싱
- 테스트 데이터나 테스트 결과를 캐시하여, 변경되지 않은 테스트는 다시 실행하지 않을 수 있습니다.
제한 사항
- 캐시 크기 제한
- GitHub Actions는 캐시의 최대 크기를 10GB로 제한하며, 이는 저장소 단위로 적용됩니다.
- 대용량 파일을 캐시하려는 경우 이 제한에 주의해야 하며, 최대 캐시 스토리지에 도달하면 가장 오래된 캐시를 삭제하여 공간을 생성합니다.
- 캐시 유지 기간
- 캐시된 데이터는 최대 7일간 유지됩니다. 7일이 지나면 캐시가 만료되고, 자동으로 삭제됩니다.
- 장기간에 걸쳐 캐시를 유지하려는 경우에는 이를 고려하여 CI/CD 코드를 작성해야 됩니다.
- 캐시 공유 제한
- 캐시는 동일한 GitHub Actions workflow 내에서만 공유됩니다.
- 다른 저장소나 workflow 간에 캐시를 직접 공유할 수는 없습니다.
artifact vs cache 간단 비교
아티팩트와 캐싱은 GitHub에 파일을 저장하는 기능을 제공한다는 점에서 유사하지만 각 기능은 서로 다른 사용 사례를 제공하며 서로 바꿔서 사용할 수 없습니다.
패키지 관리 시스템의 빌드 종속성과 같이 작업이나 워크플로 실행 간에 자주 변경되지 않는 파일을 재사용하려는 경우 캐싱을 사용합니다.
워크플로 실행이 종료된 후 보기 위해 작업에서 생성된 파일(예: 빌드된 바이너리 또는 빌드 로그)을 저장하려는 경우 아티팩트를 사용합니다.
예시 코드
예시 코드의 workflow는 push 이벤트가 발생할 때마다 실행되도록 설정하였습니다. 또한 두 개의 작업(Job)을 구성하여 첫 번째 작업에서 파일을 캐싱하고, 두 번째 작업에서 캐싱된 파일을 복원하도록 구성하였습니다.
> ./.github/workflows/action_caching_demo.yml
name: Workflows Names - action_caching_demo
run-name: Runs Names - action_caching_demo 🚀
on:
push
jobs:
Jobs-Names-action_caching_demo-01:
runs-on: ubuntu-latest
steps:
- name: check all file
run: ls -al
- name: create test file
run: touch test_file
- name: check create file
run: ls -al
- name: caching file
uses: actions/cache@v3
with:
path: test_file
key: ${{ runner.os }}-test-${{ hashFiles('test_file') }}
restore-keys: |
${{ runner.os }}-test-${{ hashFiles('test_file') }}
${{ runner.os }}-test-
Jobs-Names-action_caching_demo-02:
needs: Jobs-Names-action_caching_demo-01
runs-on: ubuntu-latest
steps:
- name: check all file
run: ls -al
- name: caching file
uses: actions/cache@v3
with:
path: test_file
key: ${{ runner.os }}-test-${{ hashFiles('test_file') }}
restore-keys: |
${{ runner.os }}-test-${{ hashFiles('test_file') }}
${{ runner.os }}-test-
- name: check caching file
run: ls -al
01번 작업에서 touch test_file 명령어를 사용하여 test_file이라는 새로운 파일을 생성 후 캐싱하고자 설정하였습니다.
02번 작업에서 캐싱된 파일을 복구하여 확인하도록 설정하였습니다.
캐싱 키는 실행 환경(OS)와 test_file의 해시 값을 기반으로 생성됩니다. 이는 key의 중복 없이 고유성을 보장하고자 설정하였습니다.
실행
자 이제 예시 코드를 실행하여 actions/cache 기능을 통한 데이터 캐싱을 확인해보겠습니다.
설정한 workflow를 실행하였습니다.
01번 작업에서 touch test_file 명령어를 사용하여 test_file이라는 새로운 파일을 생성하였습니다.
01번 작업에서 actions/cache 기능을 통해 test_file이라는 파일을 캐싱하였습니다. 요청한 key로 캐시가 존재하지 않아 Cache Miss가 발생하여 새 key와 함께 새로운 캐시를 생성하였습니다.
자 이번에는 02번 작업에서 actions/cache 기능을 통해test_file이라는 파일을 복구해보도록 하겠습니다. ls -al 명령어를 통해 파일이 없음을 확인하였으며, actions/cache 기능을 사용하였습니다. 요청한 key로 캐시를 확인하여 파일을 복구하였으며, 다시 ls -al 명령어를 통해 test_file 파일을 확인하였습니다.
GitHub Actions의 actions/cache 기능은 워크플로우의 실행 시간을 단축하고 성능을 최적화하기 위한 효율적인 도구입니다. 예시를 통해 test_file 생성 및 캐싱 과정을 통해, 동일한 key를 사용하여 캐시를 재사용하는 과정과 캐시 미스 시 새로운 캐시를 생성하는 방식을 확인하였습니다.
이는 의존성 설치, 빌드 과정의 최적화 및 테스트 데이터의 재사용 등 다양한 상황에서 유용하게 활용될 수 있습니다. 다만, 캐시 크기 제한 및 유지 기간과 같은 제한 사항을 고려하여 워크플로우를 설계해야 합니다.
GitHub Actions의 actions/cache 기능에 대한 이해에 도움이 되었다면 좋겠습니다.
또한 다양한 cache 설정을 통해 CI/CD 자동화 시 효율성을 높여보시기 바랍니다.
지금까지 actions/cache 기능을 통해 workflow 간에 파일을 캐싱하고 공유해보는 시간을 가졌습니다....! 끝...!
[Reference]
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
'CI-CD > GitHub Actions' 카테고리의 다른 글
| [GitHub Actions] workflows 이름 설정하기 (0) | 2024.03.21 |
|---|---|
| [GitHub Actions] actions artifact 기능을 통한 데이터 공유 및 저장 (0) | 2024.03.19 |
| [GitHub Action] workflow_call를 통한 다른 workflow 실행하기 (2) | 2024.03.13 |
| [GitHub Actions] workflows 설정 및 기본 실행 (0) | 2024.02.08 |
| [GitHub Actions] 한번 알아보자 (0) | 2024.02.06 |
