S3 + CloudFront 배포 (캐시 초기화)

 

나는 개발 단계중일때,
AWS EC2 에서 Nest.js + Vite React 를 프로덕션 전 개발을 계속 진행하는데 있어서 , 기능적으로 구현이 많이 되어진 상황이라 S3 + Cloud Front 로 배포를 옮겨야하는 상황이 생겼다 .

 

S3 에 Vite React 정적 빌드 결과물을 올려두고 CloudFront 로 세팅 후 Route 53 서비스를 새로 만들어서 , 가비아에 도메인 소유를 인증받고 네임 서버를 Route 53에서 나온 1,2,3,4차 를 입력해야한다. 

 

그 이후 Dns 세팅을 전반적으로 다 하고 , 이제 도메인에 들어갔을때 처음에는 S3 Storage 에 아무것도 없다가 첫 빌드 결과물이 올라가서 그런지 빠르게 웹 페이지가 바로 나오는걸 볼 수 있었습니다. 

 

하지만, 간단한 수정 후 재 배포시 바로 적용이 안되는 이슈가 나왔었습니다. 

 

구글이나 GPT 를 통해서 검색하다보니 , 캐시 데이터 때문에 초기화가 안되어서 이전 데이터 캐시가 남아서 이걸 초기화를 시켜주지 않으면 초기 캐시정책 설정된 기본 TTL: 86400초 ->  24시간 이후에 반영이 된다는걸 알 수 있었습니다. 

 

이걸 캐시 초기화 되는 시간을 줄여버린다면 사용자가 캐시된 파일이나 컨텐츠가 자주 만료가 되기에 또 다시 컨텐츠를 원본 서버(S3)에서 파일을 다시 가져와야하는 상황이 생깁니다. 

 

그래서, 정적파일을 새로 올린 후 이때 캐시 초기화를 요청을 해서 배포된 환경을 바로 직면 할 수 있도록 세팅을 간단하게 해봤습니다.

 

1. AWS CLI 설치 

brew install awscli

 

2. AWS 설정

aws configure

 

 

입력할 정보 순서대로 :

AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: ap-northeast-2
Default output format [None]: json

 

AWS Access Key , AWS Secret Access Key. 는 , AWS AIM 에서 인증된 유저 ID ,Key 를 가져와야합니다. 

 

파일 편집

vi invalidate.command




#!/bin/bash
echo "메인 웹사이트 무효화 실행 중..."
aws cloudfront create-invalidation --distribution-id S3 [CloudFront 프로젝트 ID] --paths "/*"

echo "모든 무효화 완료!"
read -p "아무 키나 누르세요..."

 

:wq 를 입력 후 , 저장을 합니다.

 

3. 실행

./invalidate-all.command

 

그러면 프로젝트 도메인에 다시 들어가보면 , 변경된 프로젝트를 바로 보실 수 있습니다. 

 

하면서 느꼈던점은, 

 

개발의 편의성만 본다면 EC2 직접 서빙이 훨씬 간단하고 , 바로 직관적으로 변경된 프로젝트를 볼 수 있었다. 

CloudFront 는 성능상 이점이 크지만,  그에 반면 개발 워크플로우의 복잡성을 감수해야하는 상황을 직면을 헀습니다. 

CloudFront는 그리고 캐시 의존도가 굉장히 높은 시스템이라는걸 보게 되었다. 

CDN 의 핵심 원리는 캐시된 데이터를 빠르게 제공하는 것과 원본 서버 접근을 최소화하는 것이 목표!!!

개발이 정말 릴리즈가 되어지는 상황에서 정적배포를 S3 + CloudFront 에 배포를 하는게 조금 더 편해보인다고 생각합니다.