Docker 이미지 캐싱: Google Cloud Build에서 빌드 속도 높이기!

Docker 이미지 캐싱은 CI/CD 파이프라인, 특히 Google Cloud Build와 같은 클라우드 환경에서 빌드 시간을 획기적으로 줄여주는 핵심 기술입니다. Docker 이미지를 빌드할 때마다 모든 단계를 처음부터 다시 실행한다면, 시간과 비용이 많이 들겠죠? Docker 이미지 캐싱은 이 문제를 해결해 줍니다. 이 글에서는 Google Cloud Build 환경에서 Docker 이미지 캐싱이 어떻게 작동하는지, 왜 필요한지, 그리고 빌드 속도를 높이기 위한 구체적인 방법들을 개발자 주니어 및 개발 입문자의 눈높이에 맞춰 쉽고 자세하게 설명해 드릴게요!

목차

• Google Cloud Build 환경, 왜 캐싱이 필요할까요?
• Docker 레이어 캐싱의 기본 원리 이해하기
  • 로컬 캐시는 빌드 간에 유지되지 않아요!
  • 빌드 간 캐싱을 활성화하는 세 가지 필수 단계
• 레지스트리 정렬: 캐싱의 성공을 위한 필수 조건
• 캐시의 범위: 어디까지 재활용될까요?
• 고급 캐싱 기법: BuildKit으로 더 빠르게!
• 흔히 저지르는 실수와 해결책
• Google Cloud Build Docker 이미지 캐싱, 이것만 기억하세요!

---

Google Cloud Build 환경, 왜 캐싱이 필요할까요?

Google Cloud Build는 여러분의 코드를 빌드하고 테스트하며 배포하는 데 사용되는 강력한 서비스입니다. 각 빌드는 마치 깨끗한 새 컴퓨터에서 시작하는 것처럼, **새롭고 격리된 환경(임시 VM/컨테이너)**에서 실행됩니다. 각 빌드 단계도 자체 컨테이너에서 실행되지만, Docker 빌더를 사용하는 단계들은 동일한 Docker 데몬과 작업 디렉토리를 공유합니다.

이러한 '깨끗한 환경'은 빌드의 일관성과 격리성을 보장하지만, 한편으로는 이전 빌드에서 사용했던 Docker 이미지 레이어들을 재활용하기 어렵게 만듭니다. 매번 처음부터 모든 레이어를 빌드해야 한다면 빌드 시간이 길어지고 자원 소모도 커지겠죠. 그래서 Docker 이미지 캐싱이 매우 중요해집니다.

Docker 레이어 캐싱의 기본 원리 이해하기

로컬 캐시는 빌드 간에 유지되지 않아요!

Google Cloud Build에서는 로컬 Docker 캐시가 빌드 간에 유지되지 않습니다. 즉, 한 번 빌드가 끝나면 해당 빌드에서 생성된 임시 캐시 데이터는 사라진다는 의미입니다. 따라서 다음 빌드에서는 이전 빌드의 캐시를 자동으로 사용할 수 없습니다.

이 문제를 해결하고 빌드 간에 캐싱을 활성화하려면 특별한 전략이 필요합니다.

빌드 간 캐싱을 활성화하는 세 가지 필수 단계

빌드 간에 Docker 이미지 캐싱을 사용하려면 다음 세 가지 단계를 반드시 수행해야 합니다:

1. 빌드 시작 시 이전 이미지 가져오기(Pull): 빌드를 시작할 때, 이전에 빌드하여 레지스트리(예: Artifact Registry 또는 GCR)에 저장된 이미지를 먼저 가져와야 합니다.
2. --cache-from 사용: docker build 명령어에 --cache-from 옵션을 사용하고, 가져온 이전 이미지의 참조를 지정해야 합니다. 이 옵션은 Docker에게 이전에 가져온 이미지를 캐시 레이어로 사용하라고 알려줍니다.
3. 새 이미지 푸시(Push): 빌드가 완료된 후, 새로 빌드된 이미지를 다시 레지스트리에 푸시해야 합니다. 이렇게 해야 다음 빌드에서 이 이미지를 캐시로 사용할 수 있습니다.

레지스트리 정렬: 캐싱의 성공을 위한 필수 조건

Docker 이미지 캐싱이 제대로 작동하려면, 이미지를 가져오는(pull) 레지스트리와 --cache-from 옵션에서 사용하는 이미지 참조가 동일한 레지스트리 및 경로여야 합니다. 예를 들어, Artifact Registry를 사용한다면 asia-northeast3-docker.pkg.dev와 같은 동일한 경로를 사용해야 합니다.

만약 다른 레지스트리에서 가져오거나 참조가 일치하지 않으면, 캐시가 전혀 사용되지 않아 빌드 속도 향상 효과를 볼 수 없습니다. 이는 Docker 이미지 캐싱에서 흔히 발생하는 실수 중 하나입니다.

YAML

# Artifact Registry 예시
- name: 'gcr.io/cloud-builders/docker'
  args: ['pull', 'asia-northeast3-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/${_IMAGE_NAME}:latest']
- name: 'gcr.io/cloud-builders/docker'
  args: [
    'build', '-t', 'asia-northeast3-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/${_IMAGE_NAME}:latest',
    '--cache-from', 'asia-northeast3-docker.pkg.dev/${PROJECT_ID}/${_ARTIFACT_REGISTRY_REPO}/${_IMAGE_NAME}:latest',
    '.'
  ]

 

캐시의 범위: 어디까지 재활용될까요?

한 번 가져온 Docker 이미지와 그 레이어들은 동일한 빌드 내의 모든 Docker 단계에서 사용 가능합니다. 즉, 한 빌드 안에서는 여러 Docker 빌드 스텝이 있더라도 캐시를 공유할 수 있다는 뜻입니다.

하지만 캐시는 다른 빌드 간에는 자동으로 사용되지 않습니다. 캐시를 재활용하려면 위에서 설명한 것처럼 레지스트리에서 이미지를 명시적으로 가져와야 합니다.

고급 캐싱 기법: BuildKit으로 더 빠르게!

더욱 향상된 Docker 이미지 캐싱 성능을 원한다면, Docker BuildKit을 활성화하고 --build-arg BUILDKIT_INLINE_CACHE=1 옵션을 사용하는 것을 고려해 볼 수 있습니다. BuildKit은 Docker 빌드를 더 빠르고 효율적으로 만들어주는 차세대 빌더입니다.

BuildKit을 사용하려면 빌드 단계에서 환경 변수 DOCKER_BUILDKIT=1을 설정해야 합니다.

흔히 저지르는 실수와 해결책

Docker 이미지 캐싱을 설정할 때 흔히 저지르는 실수들이 있습니다.

• 다른 레지스트리에서 가져오기: --cache-from에서 사용하는 레지스트리와 이미지를 가져오는 레지스트리가 다르면 캐시가 사용되지 않습니다. 항상 동일한 레지스트리 참조를 사용해야 합니다.
• 빌드 후 이미지 푸시 누락: 빌드 후에 새로 빌드된 이미지를 레지스트리에 푸시하지 않으면, 다음 빌드에서 사용할 캐시가 업데이트되지 않습니다. 캐시를 지속적으로 활용하려면 반드시 푸시해야 합니다.

Google Cloud Build Docker 이미지 캐싱, 이것만 기억하세요!

Docker 이미지 캐싱은 Google Cloud Build에서 빌드 시간을 단축하고 CI/CD 파이프라인의 효율성을 높이는 데 필수적인 전략입니다. 개발자 주니어나 개발 입문자로서 클라우드 환경에서 Docker 이미지를 다룰 일이 많을 텐데, 이때 이 캐싱 개념을 잘 활용하면 훨씬 스마트하게 작업할 수 있습니다.

핵심은 이전 이미지를 가져와 캐시로 사용하고, 새로운 이미지를 다시 푸시하여 다음 빌드를 위해 캐시를 업데이트하는 것입니다. 이 원리를 잘 이해하고 적용하여 여러분의 개발 워크플로우를 더욱 빠르고 효율적으로 만들어 보세요!