refactor: CD 시간 단축 및 OCI 배포시 부하 개선

[Hexeong]

어떤 부분을 리팩터링하려 하나요?

리팩터링하려는 부분에 대해 간결하게 설명해주세요

CD(Code Deploy) 시간 단축 및 OCI 배포시 부하 개선

AS-IS

현재 dev환경과 prod환경에서의 CD 워크플로우는 다음과 같이 동작하고 있습니다.

1. GitHub Actions 러너(Runner)에서 Gradle을 사용해 프로젝트를 빌드합니다.
2. 빌드된 JAR 파일, Dockerfile, docker-compose.prod.yml 등과 배포에 필요한 파일 전체를 scp를 통해 원격 프로덕션 서버로 복사합니다.
3. 원격 서버에 ssh로 접속하여 docker compose -f docker-compose.prod.yml up -d --build 명령어를 실행합니다.이미지 빌드와 컨테이너 실행이 모두 프로덕션 서버에서 직접 이루어집니다.

문제점

• 프로덕션 서버 부하: 이미지 빌드 과정이 CPU와 메모리를 많이 사용하므로, 실제 서비스 중인 프로덕션 서버에 직접적인 부하를 줍니다. 이는 빌드 중 서비스 성능에 영향을 미칠 수 있습니다.
• 느린 배포 시간: 소스 파일 전체를 전송하고 서버에서 이미지를 빌드하는 데 시간이 소요되어 전체 배포 리드타임이 길어집니다.
• 불필요한 파일 전송: 프로덕션 서버에는 실행에 필요한 Docker 이미지만 있으면 됨에도 불구하고, 전체 소스코드와 빌드 관련 파일들이 전송됩니다.

TO-BE

GitHub Actions에서 Docker 이미지 빌드를 완료한 후, 압축된 이미지 파일을 서버로 전송하여 실행하는 방식으로 개선합니다. 이 방식은 서버의 부하를 없애고 배포 과정을 효율화하는 데 초점을 맞춥니다.

워크플로우는 빌드, 패키징, 전송, 배포의 4단계로 명확하게 분리됩니다.

1. 빌드 (in GitHub Actions)
   • 기존과 동일하게 GitHub Actions 러너에서 Gradle을 사용해 JAR 파일을 빌드합니다.
   • 이어서, 동일한 러너 환경에서 Dockerfile을 사용하여 서비스의 Docker 이미지를 빌드합니다.
2. 패키징 (in GitHub Actions)
   • docker save 명령어를 통해 방금 빌드한 Docker 이미지를 단일 .tar 아카이브 파일로 저장합니다.
   • gzip으로 .tar 파일을 압축하여 (.tar.gz), 네트워크를 통해 전송될 파일의 크기를 최소화합니다.
3. 전송 (from GitHub Actions to Server)
   • scp를 통해 압축된 이미지 파일(.tar.gz)과 실행에 필요한 docker-compose.prod.yml 파일만 원격 서버로 전송합니다.
4. 배포 (on Server)
   • 서버에서 gunzip과 docker load 명령어를 사용하여 전송받은 압축 파일을 Docker 이미지로 복원합니다.
   • docker compose up -d 명령어를 실행하여 새로운 버전의 컨테이너를 실행합니다.

작업 상세 내용

• dev-cd.yml과 prod-cd.yml 수정

참고사항

• 처음에는 GHCR(Github Container Registry)를 사용해서 문제를 해결해보려고 했지만, Free Plan의 제한이 500MB인데 반해 저희 서비스의 도커 이미지가 575MB여서 무료 사용이 불가능할 것 같아 해결 방안에서 제외했습니다.. ㅎㅎ
  • pricing 관련 정책 Docs : https://docs.github.com/ko/billing/concepts/product-billing/github-packages

참고할만한 자료(선택)

• 원격 호스트에 많은 복사 과정에서 많은 시간이 소요됨을 확인

• 복사를 진행한 후, 원격 호스트에서 이미지 빌드를 실행

• 현재 solid-connection 도커 이미지 크기