RSS Feed of hongkim.dev

이미지 최적화를 위한 여행기 (1) - 이미지 로딩 최적화

Thu, 24 Oct 2024 00:00:00 GMT

안녕하세요, 팀 Joytas 에서 백엔드 개발 파트를 맡고 있는 hong.kim 입니다.

SNS 서비스인 DAO 서비스 개발을 진행하며, 이미지 로딩 최적화를 이뤄내기 위해 어떤 과정들을 거쳤는지 이번글을 통해 소개해보려고 한다.

초기 이미지 로딩 아키텍처의 문제점

초기 DAO 프로젝트를 진행하면서 MVP 단계에서 빠른 구현에 초점을 맞추며, 아래 사진과 같이 이미지 시스템 아키텍처를 최대한 간단하게 가져갔다.

기존 이미지 시스템 아키텍처 (As-Is)

이미지 로드 요청

클라이언트가 S3 Object 엔드포인트로 직접 GET 요청

위 사진과 같이 구성한 이유는 이미지 업로드 자체가 우리 서비스의 메인 기능이 아닌 부수적인 기능이라 판단해 PUT 요청에 대한 최소한의 보안만 고려하여 구성하고 메인 기능에 집중하였다. 또한, 초기 최대 업로드 가능한 이미지 크기는 1MB로 제한함으로 써, 이미지 업로드 및 다운로드 속도를 제어하고 있었다. MVP의 메인 기능들이 완성되고, 휴대폰을 찍은 사진을 많이 올리는 SNS 서비스의 특성상 1MB 용량 제한을 25MB 으로 늘리도록 결정하였고, 이미지 용량 제한이 25배가 증가함에 따라 프론트엔드에서 이미지를 .webp 형식으로 변환하여 업로드하도록 로직을 수정함으로 써, 성능 이슈를 대비하였다.

아래의 .webp로 변환하여 이미지를 업로드 했을 때의 이미지 로드 속도를 봐보자:

1.8MB 의 이미지를 불러오는데 500ms 소요

1.8MB 크기의 이미지를 완전히 불러오기까지 500ms 가 넘게 걸리고 있었다. 불러올 이미지의 크기가 20MB가 넘는다면 이미지를 완전히 불러오는 시간은 1000ms 을 가볍게 넘는 것은 물론, 네트워크 대역폭도 증가하게 된다. 따라서, 이미지를 완전히 불러오기까지 걸리는 최대 시간을 200ms 이내로 들어오도록 목표를 잡았게되었다.

이러한 문제점을 개선할 수 있을까?

결론부터 말하자면, 이미지 시스템 아키텍처를 아래와 같이 개선하면서 다음과 같은 성과를 얻을 수 있었다:

개선된 이미지 시스템 아키텍처 (To-Be)

개선 후의 이미지 로드 시간

이미지 로드 요청
1. 로드 시간(Cache-Hit 기준) : 500ms -> 10ms (응답 시간 약, 50배 개선)
2. 이미지 크기 : 1.8MB -> 15.8KB (대역폭 약, 99.14% 절약)

DAO 서비스는 아래의 2가지 과정을 거쳐 전반적인 이미지 시스템 아키텍처 개선을 이뤘고, 하나씩 소개하려고 한다.

CDN 도입을 통한 RTT 및 S3 비용 개선
S3 Object Lambda를 통한 이미지 리사이징

CDN 도입을 통한 RTT 및 S3 비용 개선

초기 아키텍처에서 가장 개선이 필요한 부분은 클라이언트가 AWS S3로 직접 원본 이미지 요청을 보내 발생하는 문제였다.

S3 캐싱 기능의 부재 이슈
- S3 자체에서 캐싱 기능이 없어, 사용자들이 동일한 객체에 접근할 때 매번 S3에서 직접 데이터를 읽어 보내줘야한다.
S3 비용 증가 이슈
- AWS S3를 사용하면서 객체에 직접적으로 GET 요청으로 처리하면, S3에 대한 데이터 전송 요금이 부과된다.
- 즉, 1번 이슈와 동일하게 사용자들이 같은 객체에 계속 접근한다면? -> 비용은 계속 카운팅

클라이언트가 S3 로 직접 요청을 보내는 경우, 위 2가지 문제가 가장 큰 걸림돌이였다.

CDN(AWS CloudFront) 도입 고려

캐싱 기능의 부재와 S3에서 발생할 수 있는 비용 증가 이슈는, AWS 에서 제공하는 CDN 서비스인 CloudFront를 통해 개선을 진행할 수 있었다. 아래의 AWS CloudFront에 대한 설명을 봐보자.

CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다.

(출처: Amazon CloudFront란 무엇입니까?)

CloudFront는 정적 이미지를 사용자와 가장 가까운 Edge Location에서 캐싱함으로 써, RTT(Round Trip Time)을 줄일 수 있을 뿐더러, 클라이언트가 S3와 직접 통신하는 것이 아닌 CloudFront의 Edge Location과 통신하고, 결정적으로 CloudFront에서 S3로 요청하는 데이터 송신 비용은 무료이다.

출처: Amazon S3 요금 https://aws.amazon.com/ko/s3/pricing

정적 컨텐츠의 사이즈가 적을 때, S3만 운영하는 것과 CloudFront와 결합하여 운영하는 것의 비용 차이는 적지만, 정적 컨텐츠의 사이즈가 커질수록 운용 비용의 차이는 커진다. 또한, 클라이언트와 S3 사이에서 CloudFront가 Proxy 역할을 해줌으로 써, 보안적으로 이점을 챙길 수 있다.

(해당 내용의 비용 비교는 이 블로그에서 더 자세히 찾아볼 수 있다.)

S3와 CDN의 결합 전후 로드 시간 비교

CloudFront와 S3를 결합하여 운영할 때의 로드 시간을 봐보자.

CDN(AWS CloudFront) 적용 후의 응답 시간

Cache Hit 기준 1.8MB 컨텐츠가 500ms에서 250ms으로 응답 시간이 2배 개선된 것을 볼 수 있다. 하지만, 아직까지도 목표한 200ms이내로 이미지 로딩이 완료되지 않고있다.

S3 + CDN(AWS CloudFront)의 한계

정적 이미지를 서빙하기 위해 S3와 CloudFront를 결합한 아키텍처만으로도 좋은 아키텍처라고 생각한다. 하지만, CDN은 RTT만 줄여줄 뿐 근본적으로 이미지의 크기를 줄여주지 않음으로 매우 큰 개선은 어렵다.

따라서, 이미지 크기를 줄이기 위한 추가적인 아키텍처 구성이 필요하다.

S3 Object Lambda를 통한 이미지 리사이징

이미지 리사이징을 위한 추가적인 아키텍처를 구성하기 전, 현재 우리의 서비스를 살펴보자.

이미지 리사이징이 옳은 방법일까?

DAO 서비스의 이미지 랜더링 크기, 미리보기 150x150px와 상세보기 500x700px

현재, 우리 서비스는 미리보기 이미지에서 150x150 픽셀, 상세보기 탭에서 500x700 픽셀로 랜더링하고 있다. 즉, 이보다 더 큰 이미지일 경우 불필요한 이미지 크기로 인해 페이지의 성능을 저하를 유발한다. 따라서, 클라이언트가 이미지를 랜더링할 때 필요한 크기 즉, 동적으로 이미지를 리사이징함으로 써 응답 시간 및 대역폭을 개선할 수 있다고 기대했다.

동적 이미지 리사이징을 위해 고려한 방법들

나는 앞서 구축한 아키텍처와 동적 이미지 리사이징 서비스를 결합하기 위해 아래의 3가지 방안을 고려했다.

EC2 혹은 ECS 기반의 이미지 처리 서버 구성
Lambda@Edge
S3 Object Lambda

첫번째, 이미지 처리를 위해 별도의 서버를 운영하는 방법은 핵심 기능 외에 추가적인 관리 포인트가 늘어나고 유휴 시간 동안 발생하는 비용을 절감하기 위해 서버리스 환경 즉, AWS Lambda를 사용하는 방법으로 기울게 되었다. 또한, Edge Location에 리사이징된 이미지가 캐싱되어 있다면 Lambda가 동작하지 않아 추가적인 비용 절감 효과도 기대했다.

두번째, Lambda@Edge를 사용하여 이미지 리사이징을 구현할 때 전 세계 모든 Edge Location에 리사이징된 이미지를 캐싱하므로 글로벌 리전이 필요한 경우 매우 유용하게 작용할 수 있다.

Lambda@Edge 와 Lambda Function 가격 비교 (출처: AWS Lambda 비용)

하지만, Lambda@Edge는 Lambda Function에 비해 대략 3배의 비용이 발생하며, 우리 서비스는 글로벌 리전은 필요하지 않으므로 최종적으로 S3 Object Lambda를 사용하여 동적 이미지 리사이징 아키텍처를 구축하기로 결정했다.

S3 Object Lambda를 통한 이미지 리사이징 적용

본 글에서 사용한 Lambda Function의 코드는 깃허브 리포지토리에서 확인할 수 있다.

이제, DAO 서비스에서 어떻게 S3 Object Lambda를 설정했는지 예제를 통해 소개하겠다.

IAM 정책 생성

먼저, Lambda 함수가 S3 Object Lambda Access Point를 통해 S3 버킷에 저장된 객체에 안전하게 접근하고, 이를 동적으로 처리한 후 클라이언트(CloudFront)에 반환할 수 있도록 필요한 권한을 부여 하기 위해 아래와 같이 IAM 역할을 생성해줘야한다.

AWS IAM 설정

위 사진과 같이 AmazonS3ObjectLambdaExecutionRolePolicy 권한을 준 S3ObjectLambdaRole 역할을 만들었다.

이미지 리사이징 Lambda Function 생성

IAM 권한을 만들었다면, 이미지 리사이징 작업을 진행할 수 있도록 Lambda Function를 만들어주자. 생성할 Lambda Function에 앞서 만들어둔 역할을 부여해줘야한다.

앞서 만든 S3ObjectLambdaRole을 부여

Lambda Function의 실행 환경은 Node.js 20.x으로 설정해줘야한다. 이미지 리사이징에 대한 예제 코드는 CloudFront가 Client의 요청을 받을 때, 리사이징될 높이와 길이에 대한 정보를 쿼리 파라미터로 각각 h와 w로 받아 리사이징이 수행되도록 하는 로직으로 작성되어있다.

# 이미지를 200x200 으로 리사이징 하고 싶다면 아래와 같이 요청을 보내면 된다.
https://cdn.joytas.io/abcd-efgh?h=200&w=200

(예제 코드가 아닌, 직접 구현한 Lambda Function을 사용할 예정이라면 각자 환경에 맞는 버전으로 설정하면 된다.)

zip 파일로 압축된 Lambda Function 업로드

완성한 Lambda Function 코드와 실행 환경을 합께 압축하여 위 사진과 같이 .zip 파일로 올려 배포해주자. Lambda Function 코드 배포가 끝났다면, CloudFront가 생성한 Lambda Function을 호출할 수 있도록 리소스 기반 정책과 이미지 리사이징 작업 중 런타임 오류가 발생하지 않도록 할당된 메모리 및 임시스토리지를 늘려줘야한다.

먼저, 리소스 기반 정책 권한부터 설정해보자. 리소스 기반 정책 권한 설정은 "구성"의 "권한"탭에서 설정할 수 있다.

리소스 기반 정책 권한 추가 방법

보안 주체 및 작업은 사진과 동일하게 설정해주자

보안 주체와 작업을 위 사진과 동일하게 작성함으로 써, CloudFront 서비스에서 생성한 Lambda Function을 호출할 수 있다. 다음으로, Lambda Function의 기본 구성을 수정해보자. Lambda Function의 기본 구성의 메모리와 임시 스토리지는 각각 128MB 와 512MB 이며, 제한 시간은 3초로 되어있다.

Lambda Function 기본 설정 변경

나는 큰 이미지를 리사이징 할 때, 런타임 오류가 발생하지 않게 하기 위해 위 사진과 같이 메모리와 임시 스토리지를 모두 1024MB으로, 제한시간은 5초로 변경하여 설정해줬다.

S3 Access Point 설정

이미지 리사이징 작업을 진행하는 Lambda Function 설정을 완료했다면, 이제 CloudFront가 Lambda Function을 통해 S3 객체에 접근하여 이미지 리사이징 작업을 진행할 수 있도록 S3 Access Point를 지정해줘야한다. S3 Access Point를 지정해줄 때, 지정할 S3 버킷과 동일한 리전에서 진행해야 하는 것을 주의해야한다.

S3 Access Point 생성

S3 Bucket 지정

이제, 아래와 CloudFront에 대한 정책을 아래와 같이 같이 부여해주자.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccessPoint",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:*",
      "Resource": [
        "{{ Access Point ARN 기입 }}",
        "{{ Access Point ARN 기입 }}/object/*"
      ],
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:CalledVia": "s3-object-lambda.amazonaws.com"
        }
      }
    }
  ]
}

S3 Object Lambda Access Point 설정

다음으로, CloudFront에서 Lambda Function을 트리거 하여 이미지 리사이징 작업을 실행하도록 S3 Object Lambda Access Point를 설정해야한다. S3 콘솔에서 아래와 같이 Object Lambda Access Point를 생성해주자.

Object Lambda Access Point 생성

우리는 Lambda Function 이 S3 에 저장된 Origin Image를 요청해 이미지 리사이징을 진행한 후 Client 즉, CloudFront에게 전달해줘야 하므로 이미지 리사이징 Lambda Function과 연결해야 한다. 따라서, S3로 GET 요청 허용을 꼭 체크해주자.

S3 GET 요청 허용 및 Lambda Function 지정

생성한 Object Lambda Access Point에 대한 정책은 CloudFront를 만들고 난 후 다시 설정하도록 하겠다.

생성한 Object Lambda Access Point 별칭

다만 CloudFront를 생성할 때, 원본 도메인을 Object Lambda Access Point로 지정하여 Lambda Function을 트리거해야 하므로, Alias만 복사하고 넘어가도록 하겠다.

CloudFront 생성

이제 우리는 리사이징할 크기의 정보를 쿼리 파라미터에 포함하여 Edge Location에 캐싱 처리를 진행해야한다. 따라서, 아래와 같이 길이와 높이에 대한 정보를 w와 h으로 캐싱하도록 새로운 정책을 생성해주자.

쿼리 파라미터를 포함한 CloudFront 캐싱 정책 생성

쿼리 파라미터를 포함한 정책을 생성했다면, 이전 단계에서 생성한 Object Lambda Access Point의 별칭을 원본 도메인 이름으로 설정해준다.

Origin Domain 설정

원본 도메인의 형식은 아래와 같다.

# 아래와 같은 형식으로 지정하면 된다.
{{ 별칭 }}.s3.{{ 리전 }}.amazonaws.com

# Example
object-lambda-access-7t5engtgxwiiyabj4w6utkygapn2a--ol-s3.s3.ap-northeast-2.amazonaws.com

또한, Object Lambda Access Point는 public하게 설정할 수 없기 때문에, OAC를 통해 원본에 대한 요청을 인증할 수 있도록 해줘야한다. 따라서, 아래와 같이 OAC를 생성하고 Origin Access Control로 설정해주자.

OAC 생성 및 Origin Access Control과 연결

새로운 OAC 추가

마지막으로, 앞서 생성한 쿼리 파라미터 기반의 캐싱 정책을 기본 정책으로 선택하여 생성해주면 CloudFront 설정을 마무리할 수 있다.

CloudFront: 쿼리 파라미터 기반의 캐싱 정책 설정

CloudFront의 대체 도메인 설정은 생략하도록 하겠다.

S3 Object Lambda Access Point 및 S3 Bucket 정책 부여

이제, CloudFront가 Object Lambda Access Point을 원본 요청으로 사용할 수 있도록 Object Lambda Access Point 및 S3 Bucket 정책을 각각 업데이트 해주자. 각 정책들은 아래와 같이 설정한다.

# Object Lambda Access Point의 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3-object-lambda:Get*",
      "Resource": "{{ Object Lambda Access Point ARN 기입 }}",
      "Condition": {
        "StringEquals": {
          "aws:SourceArn": "{{ CloudFront ARN 기입 }}"
        }
      }
    }
  ]
}

아래의 S3 Bucket에 대한 정책에서 사용자 ARN은 현재 작업 중인 계정의 IAM 사용자 또는 역할 ARN을 넣어줘야한다.

# S3 Bucket 정책

{
  "Version": "2012-10-17",
  "Id": "Policy1234567890",
  "Statement": [
    {
      "Sid": "S3ObjectAccessPoint",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "*",
      "Resource": ["{{ S3 Bucket ARN 기입 }}", "{{ S3 Bucket ARN 기입 }}/*"],
      "Condition": {
        "StringEquals": {
          "s3:DataAccessPointAccount": "{{ 사용자 ARN 기입 }}"
        }
      }
    }
  ]
}

그림의 계정 ID를 S3 Bucket 정책에 추가

이로써, S3 Object Lambda 아키텍처를 성공적으로 구성할 수 있다.

달성한 성과

나는 클라이언트가 S3로 직접 요청했던 아키텍처에서 CDN과 S3 Object Lambda를 결합한 아키텍처를 도입하여 아래 사진과 같이 원본 이미지에 비해 약 99.69%, .webp 압축에 비해 약 99.14%의 압축률을 얻었다.

개선된 이미지 압축률

또한, 불필요한 대역폭이 줄어들어 AWS Data Transfer 비용을 감소시킬 수 있었고, 클라이언트에서는 .webp 압축만 진행했을 때에 비해 TBT(Total Blocking Time)가 약 98% 감소하여, 이전보다 더 빠르고 효율적으로 서비스를 이용 수 있게 전반적인 사용자 경험을 향상시켰다.

마무리 하며

나는 이미지 로딩 최적화 부분은 항상 프론트엔드에서의 영역이라고만 생각했고, 보안적으로 큰 문제가 생기는 것이 아니라면 큰 관심을 가지지 않았다. 그러나 SNS 서비스인 DAO를 운영하면서 이러한 관점이 얼마나 부정적인 영향를 미칠 수 있는지 깨닫게 되었다. 또한 백엔드 개발자로써, 서버리스에 대해 부정적인 인식을 가지고 비용을 고려하지 않는 채로 직접 애플리케이션을 구축하는 데만 집중해왔다. 이번 기회를 통해 서버리스를 무조건 배제하기보다는, 서비스 특성에 맞는 기술을 신중하게 채탱하는 것이 중요하다는 점을 다시금 깨닫은 기회였다.

Ref.

https://incheol-jung.gitbook.io/docs/q-and-a/infra/cloudfront-s3
https://aws.amazon.com/ko/blogs/korea/new-use-amazon-s3-object-lambda-with-amazon-cloudfront-to-tailor-content-for-end-users/
https://medium.com/musinsa-tech/s3-object-lambda를-이용한-on-demand-이미지-변환-서비스-소개-5e3650cc27a9

무중단 배포 일지 (Feat. Blue-Green)

Sun, 30 Jun 2024 00:00:00 GMT

🙇🏻 잘못된 내용 혹은 개선할 내용이 있다면 아낌 없이 피드백 주시면 정말 감사합니다! 🙇🏻

현재 카카오 클라우드 스쿨에서 진행한 커뮤니티 서비스를 실제로 사용자들이 이용할 수 있게 배포를 진행해보기로 했다.

먼저 특별한 전략없이 일반적으로 배포하는 흐름을 알아보자.

새롭게 배포할 애플리케이션 V2를 빌드한다. (ex. Dockerfile 빌드)
EC2 서버에 SSH 접속을 한다.
V2 빌드 파일을 EC2 서버로 가져온다.
기존의 운영중인 V1 애플리케이션을 종료한다.
V2 빌드 파일을 실행한다.

특별한 배포 전략이 없다면 보통 위와 같은 흐름을 가지게 된다.
~~(사실 위 과정은 Recreate 배포 전략이다.)~~

위 흐름에서의 문제점은, 4 - 5 번 과정에서 애플리케이션이 종료되어 사용자가 내 서비스를 이용하지 못하게 되는 시간이 존재하게 된다.

나는 이러한 문제점을 개선하기 위해, 자동화된 무중단 배포 전략을 사용하여 DOWNTIME 을 줄여 사용자가 현재 새로운 서비스로 Release 되고 있는지 인지하지 못하게 함으로 써 사용자 경험을 개선해보고자 한다.

DOWNTIME 이란?

배포 과정에서 새로운 기능 혹은 수정된 기능을 제공하기 위해 이전 버전을 종료하고 새로운 버전이 시작되기까지 서비스를 사용할 수 없는 시간을 의미한다.

→ 즉, 사용자에게 새로운 서비스를 제공하기 위해 서비스를 이용할 수 없는 시간을 말한다.

배포 전략 선택

먼저, 현재 내 프로젝트에 적용하기 위해 고려한 무중단 배포 전략은 총 3가지이다.

Rolling Update
Blue-Green
Canary Release

Rolling Update

Rolling Update 배포 전략은 점진적으로 트래픽을 새로운 버전 V2 로 이전 시켜가는 무중단 배포 전략이다.

하지만, Rolling Update 배포 전략은 이전 버전인 V1 과 최신 버전인 V2 가 동시에 실행될 수 있어, 서로 다른 버전 간 충돌이 일어날 수 있어 배포시 주의가 필요하다.

따라서, Rolling Update 배포 전략을 사용하기 위해서는 서로 다른 버전간의 호환성 테스트를 꼼꼼히 테스트해야하고

신규 버전으로 배포 실패시 롤백 과정을 구현하기 어려울 것 같다는 생각에 Rolling Update 배포 전략은 선택하지 않았다.

Blue-Green

Blue Green 전략은 Rolling Update 전략과 달리 한번에 트래픽을 V1 에서 V2 로 옮기는 무중단 배포 전략이다.

Blue Green 전략은 버전 업데이트 실패 시 LB가 다시 V1 으로 라우팅 하면 되서 업데이트 실패에 대한 롤백 과정 구현이 상대적으로 매우 쉽다.

또한, 모든 트래픽을 V1 에서 V2 로 옮기기 때문에 버전간의 호환성 문제가 발생할 일도 사라지게 된다.

하지만, 최대 단점인 V1 과 V2 서비스가 동시에 띄우는 방법이라 시스템 리소스를 많이 먹는 문제가 있다.

Canary Release

마지막으로 고려해본 전략은 카나리 배포 전략이다.

카나리 배포 전략은 Rolling Update 전략과 비슷하게 트래픽을 점진적으로 새로운 버전으로 이전 시켜가며 배포하는 전략이다.

하지만, 중요한 차이점은 Rolling Update 전략과 달리 새로운 버전을 특정 사용자 그룹에만 배포하여 문제가 없을 경우에 점진적으로 트래픽을 이전 시켜가는 비율을 증가 시킨다는 것이다.

즉, 처음 25% 의 사용자 그룹에게만 V2 버전을 배포하여 문제가 없다면 그다음 50%... 100%.. 로 점차 비율을 늘려가며 마지막엔 서비스 전체가 V2 버전으로 업데이트 되도록 하는 배포 전략이다.

TMI) 카나리 배포 전략을 이해하기 위한 카나리아의 유래

옛날 광부들이 지나가려는 통로에 가스 누출이 되었는지 확인하기 위해,
유독 가스에 민감한 카나리아 새를 통해 위험을 미리 탐지 했던 방법에서 유래된 방법이다.

즉, 미리 소수의 사용자들에게만 배포를 진행해보고 문제가 없을 경우
점점 비율을 늘려가며 최종적으로 전체 서비스가 업데이트 되어가는 무중단 배포 전략을 의미한다.

최종적으로 선택한 배포 전략

Rolling Update 전략은 배포 실패에 대한 롤백 과정을 구현하기 까다로울 것 같다는 생각에 고려하지 않았다.

또, 카나리 배포 전략은 현재 내 서비스를 이용하는 사용자가 없기도 하고, 네트워크 관리에 대한 비용과 러닝커브가 클 것 같다는 생각으로 고려하지 않았다.

최종적으로 Blue-Green 배포 전략을 선택했고,
Blue 서비스와 Green 서비스가 동시에 실행하여 서버 리소스를 많이 사용하는 문제를 개선하기 위해,
업데이트가 정상적으로 마무리 될 경우 이전 버전은 종료하도록 구현했다.

~~(사실 현재 하나의 EC2 서버밖에 보유하지 않아 어떤 배포 전략을 선택해도 비슷하게 구현될 것 같다..)~~

전체 아키텍처 구성과 흐름

앞서 설명한 무중단 배포를 위해 선택한 전략인 Blue-Green 배포의 전체적인 흐름이다.

프론트엔드는 프리티어를 최대한 이용하고자 AWS 에서 제공하는 CDN 인 CloudFront 를 선택하였다.
CloudFront 를 사용하면 캐시 무효화 작업만으로 프론트엔드에서 간단하게 무중단 배포를 구현할 수 있다.

백엔드 무중단 배포 전략의 흐름 (Blue-Green 배포)

Github 메인 브랜치로 PUSH 이벤트가 발생한다.
Github Action 을 통해 스프링 애플리케이션 빌드 이미지를 Docker Hub 로 push 한다.
Self Hosted Runner 를 통해 EC2 서버에서 이미지를 pull 한다.
Blue 혹은 Green 컨테이너를 띄운다.
Health Check 에 통과하면 NGINX 설정을 교체한다. (Blue → Green 혹은 Green → Blue)
기존에 운영 중인 Blue 혹은 Green 컨테이너는 종료한다. (서버 리소스 절약)

프론트엔드 무중단 배포 전략의 흐름

Github 메인 브랜치로 PUSH 이벤트가 발생한다.
Github Acton 을 통해 리액트 애플리케이션을 빌드 후 S3 에 저장한다.
CloudFront 의 캐시를 무효화 하여 사용자가 새로운 버전의 리액트를 사용할 수 있도록 한다.

이번 게시글에서는 백엔드에서 어떻게 Blue-Green 배포를 구현할 수 있는지 단계별로 알아보자.

백엔드 무중단 배포 구현

Blue-Green 무중단 배포를 구현하기 위해 사용할 환경들

GitHub Action
- 스프링 애플리케이션 빌드 및 이미지를 push
Self Hosted Runner
- EC2 서버에서 이미지는 pull 받고 배포 스크립트를 실행시킴
AWS EC2 - (Amazon Linux)
- 필자는 Amazon Linux 환경의 EC2 서버를 사용
Docker Hub
- 빌드된 스프링 이미지들을 가지고 있는 도커 리포지토리

Dockerfile 작성

먼저, 우리가 구현한 스프링 애플리케이션을 실행하는 이미지를 만들기 위해 DockerFile 을 작성해주자.

# ./Dockerfile

FROM amazoncorretto:17-alpine-jdk

WORKDIR /app
# 각자의 프로젝트 파일에 맞게 변경하십셔
COPY ./build/libs/community-0.0.1-SNAPSHOT.jar /app/hong-community.jar
ENV TZ=Asia/Seoul

CMD ["java", "-jar", "hong-community.jar"]

Docker Hub 리포지토리 생성

나는 이미지를 빌드하고 docker hub 리포지토리로 Push 후 EC2 서버에서 이미지를 가져와 사용할 예정이다.

그럼 docker hub 리포지토리 탭에서 리포지토리를 생성해보자.

이미지 빌드시 secret key 와 같이 민감한 정보와 함께 빌드될 수 있어 private 리포지토리로 만드는 것을 추천한다.
private 리포지토리는 docker hub 무료 플랜(Personal) 기준으로 한개만 생성 가능하다.

정상적으로 생성이 완료되면 위 사진과 같이 private 리포지토리로 생성된 것을 확인할 수 있다.

Github Action Workflow 작성 - 이미지 빌드 및 Push

이제, .jar 로 빌드된 스프링 애플리케이션을 실행하는 이미지를 생성하고 docker hub 로 push 하는 docker-build-and-push 작업을 작성해보자.

먼저, Github Action 을 동작시킬 trigger 이벤트를 설정해준다.

나는 배포 작업은 main 브랜치로 push 이벤트가 일어날 때 Github Action 이 동작하도록 구현했다.

# ./.github/workflows/backend-prod-cd.yml

on:
  workflow_dispatch:
  push:
    branches:
      - main

그 다음으로, 스프링 애플리케이션을 .jar 로 빌드하는 작업을 추가해주자.

# ./.github/workflows/backend-prod-cd.yml

# ...

jobs:
  docker-build-and-push:
    # Github Action 은 우분투 환경으로 진행
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      # JDK 설치
      - name: JDK 17 버전 설치
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      # 스프링 애플리케이션을 .jar 파일로 빌드
      - name: Gradle 을 통해 빌드
        uses: gradle/gradle-build-action@v2.6.0
        with:
          arguments: bootJar

    # ...

마지막으로, .jar 파일로 빌드한 스프링 애플리케이션을 실행할 수 있도록 Docker image 를 만들고,
EC2 서버에서 해당 이미지를 가져올 수 있도록 docker hub 로 push 하는 작업을 추가해주자.

# ./.github/workflows/backend-prod-cd.yml

# ...
jobs:
  docker-build-and-push:
    runs-on: ubuntu-latest

    steps:
      # ...

      - name: Docker 빌드 도구 설정
        uses: docker/setup-buildx-action@v2.9.1

      - name: Docker Hub 로그인
        uses: docker/login-action@v2.2.0
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Docker 이미지 빌드 및 푸시
        uses: docker/build-push-action@v4
        with:
          context: .
          file: ./Dockerfile
          push: true
          platforms: linux/amd64
          tags: ${{ secrets.DOCKER_HUB_REPOSITORY }}:${{ secrets.IMAGE_TAG }}

나는 Docker Hub 에 로그인 하기 위해 username 및 발급받은 access token (password) 과
생성한 이미지를 push 할 docker hub 리포지토리와 tag 명을 Github Action 의 secrets 변수로 설정 해줬다.

→ access token 은 docker hub 의 security 설정에서 발급 받을 수 있다.

DOCKER_HUB_REPOSITORY 는 username/repository-name 으로,
IMAGE_TAG 는 프로젝트에 맞게 지정하면 된다.

나는 DOCKER_HUB_REPOSITORY 을 kimjihong/hong-community-layout 으로 설정하고
IMAGE_TAG 는 latest 로 지정했다.

Self Hosted Runner 설정

사실 AWS CodeDeploy 를 통해 EC2 서버에서 배포해도 되고,
Github Action SSH 를 사용하여 EC2로 접속해서 배포해도 되고 여러가지 방법 있다.

하지만, 내가 Self Hosted Runner 를 사용한 이유는 아래와 같다.

배포의 전체 과정을 한곳에서 몰아서 보고싶다.
Github Action 에서 SSH 를 사용하면 무료 시간에서 차감된다.

따라서, 배포 과정을 Github Action 으로 통일하고, Github 에서 관리하는 인스턴스가 아닌 나의 EC2 서버에서 진행할 수 있는 Self Hosted Runner 를 사용하였다.

또, Self Hosted Runner 설정은 매우매우 간단스하다. ~~(사실 이게 가장 큰 이유)~~

먼저, Github Repository 설정에서 Runners 에 들어간다.

Runners 탭에서 New self-hosted runner 버튼을 누르면 아래와 같이 설정 스크립트를 친절하게 알려준다.

우리는 단순히 복붙만으로 빠르게 self hosted runner 설정을 끝낼 수 있다..!

내 EC2 서버의 OS 는 Amazon Linux 이므로 Linux 버전으로 선택했다.

이제, 스크립트를 EC2 서버에서 실행하여 입맛에 맞게 설정해주자.

나는 runner 를 백그라운드에서 실행시키기 위해 nohup ./run.sh > output.log 2>&1 & 로 실행시켰다.

정상적으로 실행이 완료되고, 다시 Runner 탭으로 들어가보면 runner 가 Idle 상태로 되어 있는 것을 확인되었다면 정상적으로 runner 가 등록된 것이다.

나는 여기서 추가로 러너가 장시간 켜져있을 경우 종료될 수도 있다고 판단하여
매일 새벽 3시마다 runner 를 재실행하도록 크론 잡을 설정해줬다.

# 크론 편집기 열기
$ crontab -e


# crontab 에 아래 스크립트 저장
# 매일 새벽 3시마다 runner 재실행
0 3 * * * cd /home/ec2-user/actions-runner && sudo ./svc.sh restart

svc.sh 는 self-hosted runner 에서 제공하는 스크립트로,
self-hosted runner 설치, 시작, 중지, 재시작 등의 작업을 할 수 있다.

Blue & Green docker-compose 설정

Runner 설정이 완료 되었다면, 이제 blue 로 띄울 스프링 컨테이너와 green 으로 띄울 스프링 컨테이너를 정의 해줘야 한다.

나는 docker-compose.blue.yml 과 docker-compose.green.yml 두개의 파일로 나눠서 설정해줬다.

주의 할 점은, Runner 가 EC2로 접속하는 경로는 홈 경로가 아니라 기본적으로
/home/ec2-user/actions-runner/_work/<repo_name>/<repo_name>/ 로 접속한다.

따라서, docker-compose 파일은 해당 디렉토리 내에 위치하도록 해야한다.

# docker-compose.blue.yml
version: '3'

services:
  spring-backend:
    container_name: spring-backend-blue
    image: kimjihong/hong-community-layout:latest
    ports:
      - "8081:8080"
    env_file:
      - .env

---

# docker-compose.green.yml
version: '3'

services:
  spring-backend:
    container_name: spring-backend-green
    image: kimjihong/hong-community-layout:latest
    ports:
      - "8082:8080"
    env_file:
      - .env

blue 컨테이너의 호스트 포트는 8081로, green 컨테이너의 호스트 포트는 8082로 설정하고 컨테이너 포트는 8080 포트로 동일하게 설정해줬다.

따라서, 현재 실행중인 서비스가 blue 일 경우 NGINX 는 8081 포트를, 현재 실행중인 서비스가 green 일 경우 NGINX 는 8082 포트를 참조하도록 설정해야한다.

NGINX 설정

NGINX 에서 배포가 성공적으로 이뤄질 때, 참조하는 스프링 컨테이너의 포트를 동적으로 변경하기 위해 service-url.inc 파일을 생성했다.

service-url.inc 파일에서 service_url 변수를 정의하여 서비스를 제공할 스프링 애플리케이션의 주소를 설정하고, nginx.conf 파일에서 이 변수 값을 proxy_pass 지시어의 주소로 사용되도록 구현했다.

# /etc/nginx/conf.d/service-url.inc

set $service_url http://127.0.0.1:8081;

# /etc/nginx/nginx.conf

server {
	# ...
	include /etc/nginx/conf.d/service-url.inc;

	location / {
			proxy_pass $service_url;

			proxy_set_header X-Real-IP $remote_addr;
			proxy_set_header HOST $http_host;
			proxy_set_header X-NginX-Proxy true;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Request-ID $request_id;
			proxy_redirect off;
	}

	# ...
}

나는 현재 EC2 인스턴스에서 하나의 NGINX 만 사용하기도 하고, 네트워크 설정에 대한 복잡성 때문에 NGINX 는 docker 로 띄우지 않고, EC2 내부에 직접 설치하여 사용하였다.

deploy.sh 작성 (blue-green 배포 스크립트)

이제, Blue-Green 배포의 핵심인 배포 스크립트를 작성해보자.

내가 작성한 배포 스크립트의 흐름은 다음과 같다.

먼저 현재 실행중인 서비스가 무엇인지 확인한다.
현재 실행중인 서비스가 blue 일 경우 green 컨테이너를 새로 띄운다. (green 일 경우 blue)
컨테이너가 실행되기까지 지정된 시간 만큼 대기한다.
스프링 애플리케이션에서 미리 작성한 health check 엔드포인트로 요청을 보낸다.
200 OK 응답이 올 때까지 지정한 횟수 만큼 반복적으로 요청을 보낸다.
NGINX 가 참조하고 있는 service-url.inc 파일을 green 컨테이너에 맞게 수정한다.
nginx -s reload 로 NGINX 중단 없이 .conf 파일만 다시 갱신한다.
기존에 실행중이였던 서비스 blue 컨테이너를 종료한다.

위와 같은 흐름을 가지며 스크립트 실행 도중 새로운 버전 즉, green 컨테이너를 띄우는 과정에서 오류가 발생한다면 신속 blue 컨테이너로 다시 롤백하는 흐름을 가진다.

아래는 위 흐름을 스크립트로 작성한 파일이다.

#!/bin/bash

# hong: 리팩토링 해놔서 아래 변수만 설정에 맞게  변경하셔서 쓰심 됨다

# 설정 변수
CONTAINER_NAME="spring-backend"  # 컨테이너 prefix
CONTAINER_SETUP_DELAY_SECOND=10  # 컨테이너 실행 지연 시간
MAX_RETRY_COUNT=15  # 서버 상태 확인 최대 시도 횟수
RETRY_DELAY_SECOND=2  # 서버 상태 확인 지연 시간(초)
BLUE_SERVER_URL="http://127.0.0.1:8081"  # blue 서버 URL
GREEN_SERVER_URL="http://127.0.0.1:8082"  # green 서버 URL
HEALTH_END_POINT="/api/health"  # 서버 health check 를 위한 엔드포인트 (200 응답만 오면 됩니당)
BLUE_DOCKER_COMPOSE_FILE_NAME="docker-compose.blue"  # blue 의 docker-compose 파일명 (ex. `docker-compose.blue.yml`)
GREEN_DOCKER_COMPOSE_FILE_NAME="docker-compose.green"  # green 의 docker-compose 파일명 (ex. `docker-compose.green.yml`)
NGINX_SERVICE_URL_FILE="/etc/nginx/conf.d/service-url.inc"  # NGINX 설정 파일 경로

# NGINX 재로드 함수
reload_nginx() {
    echo "NGINX 설정 변경 작업 시작"

    if nginx -t; then
        nginx -s reload
        echo "NGINX 설정 재로드 완료"
    else
        echo "NGINX 설정 오류 -> 롤백 수행"
        echo "set \$service_url $CURRENT_SERVICE_URL;" > $NGINX_SERVICE_URL_FILE
        nginx -s reload
        exit 1
    fi
}

# 헬스 체크 함수
health_check() {
    local REQUEST_URL=$1
    local RETRY_COUNT=0

    while [ $RETRY_COUNT -lt $MAX_RETRY_COUNT ]; do
        echo "상태 검사 ( $REQUEST_URL )  ...  $(( RETRY_COUNT + 1 ))"
        sleep $RETRY_DELAY_SECOND

        REQUEST=$(curl -o /dev/null -s -w "%{http_code}\n" $REQUEST_URL)
        if [ "$REQUEST" -eq 200 ]; then
            echo "상태 검사 성공"
            return 0
        fi

        RETRY_COUNT=$(( RETRY_COUNT + 1 ))
    done

    return 1
}

# 컨테이너 시작 함수
start_container() {
    local COLOR=$1
    local DOCKER_COMPOSE_FILE_NAME=$2
    local SERVER_URL=$3

    echo "$COLOR 컨테이너를 띄우는 중"
    docker-compose -p ${CONTAINER_NAME}-$COLOR -f ${DOCKER_COMPOSE_FILE_NAME}.yml up -d
    echo "${CONTAINER_SETUP_DELAY_SECOND}초 대기"
    sleep $CONTAINER_SETUP_DELAY_SECOND

    echo "$COLOR 서버 상태 확인 시작"
    if ! health_check "$SERVER_URL$HEALTH_END_POINT"; then
        echo "$COLOR 배포 실패"
        echo "$COLOR 컨테이너 정리"
        docker-compose -p ${CONTAINER_NAME}-$COLOR -f ${DOCKER_COMPOSE_FILE_NAME}.yml down
        exit 1
    else
        echo "$COLOR 배포 성공"
        echo "set \$service_url $SERVER_URL;" > $NGINX_SERVICE_URL_FILE
        reload_nginx
        echo "기존 ${OTHER_COLOR} 컨테이너 정리"
        docker-compose -p ${CONTAINER_NAME}-${OTHER_COLOR} -f ${OTHER_DOCKER_COMPOSE_FILE_NAME}.yml down
    fi
}

# 메인 스크립트 로직
if [ "$(docker ps -q -f name=${CONTAINER_NAME}-blue)" ]; then
    echo "blue >> green"
    OTHER_COLOR="blue"
    OTHER_DOCKER_COMPOSE_FILE_NAME=$BLUE_DOCKER_COMPOSE_FILE_NAME
    start_container "green" $GREEN_DOCKER_COMPOSE_FILE_NAME $GREEN_SERVER_URL
else
    echo "green >> blue"
    OTHER_COLOR="green"
    OTHER_DOCKER_COMPOSE_FILE_NAME=$GREEN_DOCKER_COMPOSE_FILE_NAME
    start_container "blue" $BLUE_DOCKER_COMPOSE_FILE_NAME $BLUE_SERVER_URL
fi

~~(저와 동일하게 진행하고 있으시다면, 아래의 스크립트의 상단에 환경 변수만 프로젝트에 맞게 수정해서 사용하시면 됩니다!)~~

Github Action Workflow 작성 - 이미지 Pull 및 실행

EC2 내부에서 Blue-Green 배포를 위한 설정들을 마쳤다면,
마지막으로 Runner 가 EC2에서 진행할 작업을 정의해줘야한다.

# ...

jobs:
  docker-build-and-push:
  # ...

  docker-pull-and-run:
    # 우리가 설정한 runner 의 실행 환경
    runs-on: [ self-hosted, Linux, X64 ]
    needs: [ docker-build-and-push ]
    # 도커 이미지 빌드 및 리포지토리로 push 가 성공할 경우에만 진행
    if: ${{ needs.docker-build-and-push.result == 'success' }}

    steps:
      # 프로젝트에서 환경 변수를 .env 로 관리한다면 동일하게 진행하심 됩니다.
      # 사용하지 않는다면 지워주시면 됩니다.
      - name: 환경변수 파일 생성
        env:
          PROPERTIES_PROD: ${{ secrets.PROPERTIES_PROD }}
        run: |
          touch .env
          echo "${PROPERTIES_PROD}" > .env

      # docker hub 의 private 리포지토리에 있는 이미지를 pull
      - name: Docker Hub 리포지토리에서 최신 이미지 가져오기
        run: |
          sudo docker login --username ${{ secrets.DOCKER_HUB_USERNAME }} --password ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}
          sudo docker pull ${{ secrets.DOCKER_HUB_REPOSITORY }}:${{ secrets.IMAGE_TAG }}

      # deploy.sh 의 실행 권한 주기 및 실행
      - name: blue green 배포
        run: |
          sudo chmod +x deploy.sh
          sudo ./deploy.sh

runs-on 은 우리가 이전에 설정했던 self hosted runner 의 설정에 맞게 추가해주면 된다.
필자는 self-hosted, Linux, X64 라벨을 추가해줬다.

또, 나는 스프링 애플리케이션 실행시 필요한 환경 변수들이 있어, .env 파일을 EC2 서버 내부에 생성하도록 구현을 해놨다.
~~(.gitmodule 을 사용하여 application.yml 파일을 관리하고 이미지 빌드시 포함하는 것을 추천한다.)~~

Blue-Green 배포 테스트

현재 서비스중인 컨테이너가 blue 일 경우 green 으로, green 일 경우 blue 로 전환이 잘 되는 것을 확인할 수 있다.

Ref.

https://hudi.blog/zero-downtime-deployment/
https://velog.io/@mminjg/Github-Actions-CodeDeploy를-이용한-EC2-배포-자동화
https://velog.io/@hooni_/Blue-Green-무중단-배포

GitHub Actions 캐싱처리 꼭 해야할까?

Wed, 03 Jan 2024 00:00:00 GMT

Django 기준으로 구현한 코드는 GitHub에서 확인 가능합니다.

Cache를 사용해야하는 이유

GitHub Cache Action은 매 Workflow에서 build에 필요한 의존성 패키지 설치 작업을 Cache 처리해 build 속도를 향상시키기 위해 사용한다.

예를 들어, DRF를 통해 REST API를 구현하고 GitHub Action을 통해 CI를 구현했다고 했을 때 설정한 Event trigger 즉, push 혹은 pull request 이벤트가 발생할 때마다 Runner는 계속해서 requirements.txt에 작성된 의존성 패키지를 다운받아 build 완료까지 오랜 시간이 소모되고, 이로 인해 실제 test를 진행및 완료되기까지 오랜 시간이 걸리게 된다.

이를 개선하려면, 의존성 패키지 설치 작업을 캐싱처리하여 CI 테스트시 캐싱된 작업이 있는지 검사하고 있다면 해당 작업을 가져오고, 없을 때는 의존성 패키지 설치 작업을 진행 후 다시 캐싱 처리하는 방식을 사용하면 빠르게 build하고 테스트까지 진행이 가능하다.

한번 캐싱처리 전과 후의 시간 차이를 확인해보자.

Cache 하기전의 build및 test 완료까지 걸린 시간은 1분10초, 캐싱 처리 후의 소모 시간은 46초로 약 25초가량 CI 테스트 시간이 줄어들었다. (둘다 오래걸리진 않았지만 대략 52% 의 성능 속도 향상..!)

지금은 테스트를 위해서 간단하게 구현한 것이라 캐싱처리 전에도 1분대로 엄청 느리지는 않지만, 만약 프로젝트가 커지게 된다면 그에 따라 의존성 패키지도 많아지게 되어 build 시간이 더 커지게 될 것이다.

그럼 캐싱처리는 어떻게 구현 해야할까?

Cache 구현

먼저 Actions 탭에서 Django workflow를 선택했을 때 제공해주는 django.yml 파일에서 steps 부분을 살펴보자.

# .github/workflow/django.yml

jobs:
  # ...
  steps:
    - name: Check out repository code
      uses: actions/checkout@v3

    - name: Set up Python ${{ matrix.python-version }}
      id: setup_python
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install dependencies
      shell: bash
      run: |
        pip install --upgrade pip
        python -m pip install -r requirements.txt

    - name: Run Tests
      run: |
        python manage.py test

위 처럼 매 CI test가 진행될 때마다 requirements.txt 파일에 작성된 의존성 패키지들을 설치하고 test를 진행한다.

이제 우리가 고려해야할 부분은 "어디를 캐싱처리 할 것인가?" 이다.

나는 의존성 패키지를 가상환경에 설치하고 해당 가상환경 자체를 Cache에 저장해 Cache가 유효할 때까지 pip install 작업 즉, 의존성 패키지 설치 작업을 생략하도록 구현했다.

로직은 다음과 같다.

IF 캐싱된 가상환경이 있고, requirements.txt 파일이 변경되지 않았는가?
True:
- 해당 가상환경을 가져오고 의존성 패키지 설치 작업 Skip.
False:
- 가상환경 생성 및 의존성 패키지 설치 작업 Start.

위 로직을 구현하기 위해 첫번째로 캐싱된 가상환경이 있는지 확인하는 steps을 구현했다.

- name: cache virtualenv
  uses: actions/cache@v3
  id: cache-venv # Step 식별을 위한 고유 식별자
  with:
    path: ./.venv/
    key: |
      ${{ runner.os }}-${{ steps.setup_python.outputs.python-version }}-venv-${{ hashFiles('requirements.txt') }
    restore-keys: |
      ${{ runner.os }}-${{ steps.setup_python.outputs.python-version }}-venv-

Runner가 실행되는 환경에서 의존성 패키지들의 정보가 작성된 requirements.txt 이 변경되지 않을 경우에만 캐싱된 가상환경을 가져오기 위해 Cache Key 명을 "{실행환경}-{python-version}-venv-{해시값}" 으로 지정하였다.

따라서 requirements.txt 파일이 변경되지 않았고, Cache가 유지되는 기간동안에는 Cache에서 가상환경을 가져올 수 있다.

두번째로, 만약 Cache에 일치하는 Key가 없는 경우 의존성 패키지를 설치하고 일치하는 Key가 있는 경우 의존성 패키지 설치 작업을 건너뛰는 steps을 구현했다.

- name: Install dependencies
  shell: bash
  run: |
    python -m venv ./.venv
    source ./.venv/bin/activate
    pip install --upgrade pip
    python -m pip install -r requirements.txt
  if: steps.cache-venv.outputs.cache-hit != 'true'

첫번째 구현 로직의 고유 식별자(id)인 cache-venv 를 통해 if문으로 캐시를 가져오지 못했을 경우에만 가상환경내 의존성 패키지 설치 작업을 진행하도록 구현했다.

이로써, 불필요하게 계속해서 의존성 패키지를 설치하는 과정을 Skip 할 수 있다.

마지막으로, Cache에 저장된 가상환경이 없는 경우 가상환경에 진입 후 패키지를 설치하기 때문에 문제가 없지만, 만약 Cache에 저장된 가상환경이 있을 경우 가상환경 진입과정을 건너뛰게 되므로 test 시작 전에는 꼭 가상환경에 진입하도록 구현해야한다.

- name: Run Tests
  shell: bash
  run: |
    source ./.venv/bin/activate  # 가상환경 진입 필수!
    python manage.py test
  env:
  # ...

Logic Test

Cache 기능을 적용하고 다시 Action을 실행했을 때

위 사진과 같이 cache virtualenv 작업에서 캐시를 찾지 못했다는 문구가 뜨는데 이는, 지금 새로 Cache 기능을 적용한 뒤 처음 Action을 실행하는 것이라 찾지 못한 것이다.

따라서, 의존성 패키지 설치 작업을 마친 후, CI 테스트를 진행한다. 가상환경을 Cache내에 저장하는 것은 steps의 모든 작업을 완료한 뒤에 이뤄진다. (actions/cache@v3 의 작업)

한번, Actions의 Cache 탭을 확인해보자.

2개의 테스트 실행환경에서 가상환경을 캐싱하여 저장된 것을 볼 수 있다.

이제, 다시 push 이벤트를 발생시켜 저장된 Cache를 정상적으로 가져오는지 확인 해보자!

cache virtualenv 작업에서 캐시를 찾아서 Install dependencies 작업을 건너뛰고, CI 테스트를 진행하는 것을 볼 수 있다.

이로써, Cache 적용 후 처음 Actions 실행시 진행했던 의존성 패키지 설치 단계를 건너뛰어 약 20초의 시간을 단축할 수 있게 되었다.

참고할 점은 Cache의 유효기간과 최대 용량은 GitHub 무료티어 기준으로 유효기간 7일, 최대 용량 2GB이다.

Ref.

https://mckornfield.medium.com/caching-python-installs-in-github-actions-8309e12a15e6