Github Actions의 의존성 캐싱을 통한 서버 배포속도 향상

핏펫이 느린 CI/CD 때문에 겪던 배포 대기 시간을 GitHub Actions 캐싱으로 줄인 기록이다. Terraform 으로 ECS Fargate 테스트 환경을 만들고 Gradle 의존성 캐시와 Docker Buildx 레이어 캐시를 붙였다. 테스트 환경에서 Gradle 빌드가 55초에서 15초로 줄었고, 실 서버에 적용했을 때는 약 2배 빨라졌다.

핵심 포인트

문제 정의가 구체적이다. 배포 1회에 5분, 하루 30회면 150분이라 배포에만 2시간 넘게 쓰는 셈이다.
GitHub Actions 는 워크플로가 매번 새로 셋업되므로 로컬처럼 캐시가 남지 않는다. actions/cache 로 고유 키를 만들어 명시적으로 살려야 한다.
Gradle 은 actions/setup-java 의 cache 옵션을 gradle 로 주는 것만으로 의존성 캐시가 붙는다.
Docker 는 setup-buildx-action 으로 Buildx 를 켜고 cache-from 과 cache-to 를 로컬 경로에 걸어 레이어를 재사용한다.
측정 결과는 Gradle 빌드 55초에서 15초, Docker 빌드와 푸시 30초에서 27초다. 테스트 환경 차이는 작지만 실 서버에서는 약 2배 개선됐다.

상세 정리

테스트 환경은 실제 운영과 비슷하게 AWS ECS Fargate 위에 Java 11 과 Gradle 앱을 올리고 Terraform 으로 구성했다. 전체 코드는 공개 저장소에 있다.
Terraform 구성은 기존 VPC, 퍼블릭/프라이빗 서브넷, 보안그룹을 data 로 참조하고 ALB 와 target group, listener, ECS 클러스터, ECR, task definition, service 를 만든다.
ECS 서비스는 capacity_provider_strategy 로 FARGATE_SPOT 을 쓰고 배포 시 minimum healthy 50 퍼센트, maximum 200 퍼센트로 잡았다.
Dockerfile 은 openjdk:11 기반이고 시스템 사용자 spring 을 만들어 실행하며 빌드 산출물 jar 를 복사해 8080 을 노출한다. 상용에서는 빌드 속도를 위해 Alpine 이미지를 쓴다고 덧붙인다.
워크플로는 Build 와 Deploy 두 job 으로 나뉜다. Build 에서 만든 jar 를 upload-artifact 로 올리고 Deploy 가 download-artifact 로 받아 이어간다.
Docker 레이어 캐시 키는 runner.os 와 github.sha 조합이고, restore-keys 로 이전 캐시를 폭넓게 되살린다.
캐시가 계속 쌓이는 것을 막기 위해 빌드 후 기존 캐시를 지우고 새 캐시를 그 자리로 옮기는 Move cache 스텝을 둔다.
이미지 태그는 short-sha 액션으로 만든 6자리 SHA 를 쓴다.
배포는 amazon-ecs-render-task-definition 으로 task-definition.json 의 이미지 태그를 새 SHA 로 갈아끼우고, amazon-ecs-deploy-task-definition 으로 서비스에 반영한다. wait-for-service-stability 는 false 라 태스크 생성 완료를 기다리지 않는다.