[Github Action] 데이터 좀 맡길게! 나중에 그대로 다시줄래? - action cache

 

지난 글에서는 Action Controller Runner (이하 ARC) 를 사용할 때 AWS EFS 를 마운트해서 특정 경로에 build 에 필요한 데이터를 캐싱했습니다.

 

근데 만약 AWS EFS 와 같은 데이터를 저장할 수 있는 스토리지가 없다면 어떨까요?

다행히 충분히 좋은 대책안이 있습니다. 바로 Github Action 에서 제공해주는 Action Cache 이라는 녀석입니다.

 

Github Action 을 사용한다면 아마 이미 다들 잘 아실 수도 있겠군요.

 

Action Cache 는 좋아요 3.7k 를 받을 만큼 많은 사랑?을 받고 있는 액션 중의 하나입니다.

Action Cache

 

 

도큐먼트를 보면 꽤 자세하게 설명이 되어있습니다.

 

예제 코드도 존재하며, 각 필요한 with 에 대해서도 친절하게 설명해주고 있습니다.

name: Caching Primes

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Cache Primes
      id: cache-primes
      uses: actions/cache@v3
      with:
        path: prime-numbers
        key: ${{ runner.os }}-primes

    - name: Generate Prime Numbers
      if: steps.cache-primes.outputs.cache-hit != 'true'
      run: /generate-primes.sh -d prime-numbers

    - name: Use Prime Numbers
      run: /primes.sh -d prime-numbers

 

근데 문제는 봐도 어떻게 동작하는 지 잘 이해가 안가더라고요.. (캐싱을 해주는 액션인 건 알겠어! 근데 뭐 어떻게...)

 

그래서 이번 글에서는 Action Cache 를 사용하는 방법과 캐싱을 했을 때 과연 얼마나 단축되는 지 알아보고자 합니다.

 

렛츠두더코드~

 

 

여담으로,
Github Action 의 caches 기능은 무료이며, Repo 당 최대 캐시 용량은 10GB 입니다. 캐시 유지 기간은 7일로 제한되며, 최대 용량을 초과하거나 유지 기간을 초과하면 자동으로 삭제됩니다. 7일 동안 사용되지 않은 캐시 또한 삭제됩니다. 관련 문서

 

 

Cache 전

---

아무 데이터도 캐싱 되어 있지 않은 환경에서 어떻게 동작하는 지 먼저 알아보죠!

 

진행되는 action.yaml 은 아래와 같아요.

steps:
    - name: Set up Java
      uses: actions/setup-java@v3
      with:
        distribution: zulu
        java-version: 17
        cache: gradle

    - uses: actions/cache@v3
      with:
        path: |
          ./gradle-cache

        key: ${{ github.repository }}-gradle-${{ hashFiles('**/*.gradle*') }}
        restore-keys: |
          ${{ github.repository }}-gradle-


    - name: Gradle Build
      shell: bash
      run: |
        ./gradlew build \
        --no-daemon \
        -Dorg.gradle.jvmargs=-Xmx1024m \
        --build-cache \
        --project-cache-dir=./gradle-cache/project \
        --gradle-user-home=./gradle-cache/global \
        --project-dir="./"

 

 

첫번째 step 에서는 zulu-17 의 자바를 설치하고 gradle 로 캐싱을 해줍니다. 매 job 마다 자바를 계속해서 새로 설치하면 많이 비효율적이잖아요? (근데 이 부분은 굳이 캐싱 안해도 속도 차이는 거의 없었던 거 같아요)

 

두번째 step 에서는 actions/cache@v3 를 통해 진행이 되는데, 그 전에 잠깐 Github Action 의 동작 방식 개념에 잠깐 짚고 넘어가 보고자 합니다.

 

기본적으로 Job 을 실행시키고 로그 내용을 찾아보면 아래 이미지처럼 Action 이 실행되고, 모든 Action 이 끝나면, 진행했던 Action 에 대해서 다시 한번 후처리를 해줍니다. 

 

 

저는 실질적인 작업을 진행하는 것은 In Action 이라고 지칭하고, 이후 후처리하는 Action 은 Post Action 이라고 지칭합니다. 이 개념을 설명하는 이유는 Action Cache 가 바로 이런 Post Action 으로 캐시를 저장하거나 캐시 히트를 해주기 때문이죠.

 

그럼 다시 본론으로 돌아와서 두번째 step 인 actions/cache@v3 에 다시 알아보죠.

• path : 캐싱할 경로 - In Action 이 모두 끝나고 Post Action 에서 이 경로에 있는 모든 데이터를 캐싱
• key : 캐시 데이터를 구분하기 위한 키 - In Action 에서 캐시 데이터를 restore 할 때 사용 (밑에서 다시 한번 설명함)
• restore-keys: restore 를 못했을 경우 다른 키를 사용하기 위한 대체키

 

세번째 step 에서는 스프링으로 만들어진 프로젝트를 gradle 로 빌드합니다. gradle 는 --project-cache-dir 과 --gradle-user-home 에 캐시를 저장합니다. 둘의 차이점이라면 전자는 각 프로젝트별로, 후자는 글로벌로 저장하게 됩니다. 

 

그럼 이제 이 액션을 실행시키면 무슨 일이 발생하는 지 알아보겠습니다!

 

 

첫 액션이므로 어떠한 캐시 데이터도 존재하지 않습니다. 때문에 아래 로그처럼 캐시 키를 찾을 수 없다고 합니다.

no cache key

 

"gradle cache is not found" 는 actions/setup-java@v3 에서 cache: gradle 을 주었기 때문에 보여지는 로그입니다.

gradle 를 캐싱한다고 했는데 이와 관련된 캐시 키를 찾지 못한거죠.

 

그리고 "Cache not found for input keys" 가 actions/cache@v3 가 제공하는 로그입니다. 역시 마찬가지로 첫 액션이므로 캐싱된 데이터가 없고, 관련 캐시 키를 찾지 못해서 발생한 로그입니다.

 

참고로 캐시 키는 아래와 같은 탭에서 찾을 수 있습니다. 

 

 

만약 아래와 같은 화면이 보여지면 간단한 Action 하나 만들어서 실행시키면 이 다음부턴 위 화면 처럼 보여질 거에요.

아무 액션도 없어서 아래처럼 보여지는 겁니다.

 

 

 

그리고 action cache 가 끝나고 이어서 gradle build 가 실행됩니다.

 

아래는 gradle build 가 실행될 때 출력되는 로그입니다. 보면 523 라인에 NO-SOURCE 라는 문구를 확인할 수가 있는데 이는 gradle build 를 진행할 때 캐시 데이터를 사용하지 않았을 때 출력되는 문구입니다.

gradle build

 

만약 캐시 데이터를 사용했다면 NO-SOURCE 가 아니라 FROM-CACHE 라는 문구를 확인할 수 있습니다.

 

이후 gradle build 가 끝나면 In Action 에 필요한 작업들은 모두 끝났습니다. 이후 Post Action 을 보게 되면, 아래와 같은 문구를 확인할 수 있어요.

 

Cache Saved

 

actions/setup-java@v3 과 actions/cache@v3 에서 cache 를 사용했기 때문에 두번의 캐시가 저장되었습니다.

"Cache saved successfully" 로 성공적으로 캐시가 저장되었고, "Cache saved with the key" 로 성공적으로 해당 캐시 데이터를 찾을 수 있고 캐시 키도 발급되었죠.

 

그리고 이 캐시는 여기서 확인할 수 있습니다. 위에서 생성된 2개의 캐시 키입니다. setup-java-linux-gradle-xxx 라는 캐시 키 이름은 actions/setup-java@v3 에서 생성해주는 것이며, <repo name>-gradle-xxxx 는 actions/cache@v3 에서 .with.key 에 명시한 이름입니다.

캐시 키

 

이제 앞으로 이 캐시 키를 가지고 액션은 캐시 데이터를 복원하게 됩니다.

이 캐시 키를 실수로 삭제해도 걱정은 안하셔도 됩니다. 또 액션을 돌리면 생성되거든요. 다만, build 할 때 또 많은 시간이 걸리겠죠?

 

캐시 데이터를 쓰지 않고 순수 gradle build 를 진행한 결과 7분 정도 걸렸습니다.

(CPU 1500Mi 기준이며, 스프링 프로젝트는 아주 기본적인 dependency 만 가지고 있음)

7분 15초 소요

 

그럼 이제 캐시를 사용했을 때 어떠한 변화가 있는 지 살펴보죠.

 

 

Cache 후

---

이제 캐시 데이터가 저장이 되었고, 캐시 키를 통해서 언제든지 캐시 데이터를 복원할 수 있습니다. 그럼 바로 Action 을 실행해보죠.

 

actions/setup-java@v3 과 actions/cache@v3 모두 캐시 키를 이용해서 잘 복원한 걸 확인할 수 있습니다.

 

그리고 gradle build 과정에서 출력되는 로그 또한 FROM-CACHE 라는 문구를 보여주는 것을 보니 캐싱 데이터를 이용해서 빌드 하는 것을 알 수 있습니다. 

 

그럼 이제 Post Action 를 확인해보죠. Post Action 같은 경우 In Action 의 역순으로 진행되기 때문에 actions/cache@v3 먼저 실행된 걸 볼 수 있습니다. 그리고 성공적으로 캐시 주키에 캐시 히트를 했다고 나옵니다. 

 

 

이미지에서는 짤렸는데 "Cache hit ~" 맨 뒤에 "not saving cache" 라는 문구 있는데 업데이트 된 캐시 데이트가 없고, 이미 캐시 데이터가 있기 때문에 굳이 캐시를 저장하지 않았다는 의미입니다.

 

그리고 액션 결과입니다. 캐싱 전에는 7분 15초가 걸렸는데 캐싱 후에는 2분 35초가 소요되었습니다. 상당히 많이 단축된 걸 확인 할 수 있습니다. 글에서 사용된 스프링 프로젝트가 아주 가벼워서 그렇지 만약 실무에서 사용되는 프로젝트라면 아마 더 많은 시간 단축을 기대할 수 있을 거 같아요.

2분 35초 소요

 

 

오늘은 Github Action 의 핵심인 Cache 에 대해 알아보았습니다. 위에서 보여드린 기능말고도 더 다양한 기능들을 제공해주니 공식 문서를 확인해보시길 바랍니다.

 

그럼 오늘은 여기까지!