CloudFront 캐싱 확인하기

반갑습니다!

💙베하💙 누구든 탑승할 수 있는 유임승차 팀의 BTC 룰루랄라 입니다!!💨😉

 

이번 포스팅에서는 AWS Cloudfront에 대해서 살펴보겠습니다.

 

그럼 시작해 보겠습니다!

룰루랄라~♬

 

 

 

CloudFront 캐싱 확인하기

배포까지 무사히 세팅했으니 이제 정말로 CloudFront 캐싱이 되는지 확인해보자.

	$ sudo -s
	$ cd /var/log/httpd
	$ tail -f access_log

로그를 띄우고 이제 EC2 DNS로 접속해보고, CloudFront DNS로 접속해보자.

이처럼 강력한 캐싱 기능으로 사용자에게 컨텐츠 서비스를 빠르게 제공할수 있다는 점을 확인하였다.

---

CloudFront 무효화 생성

자 그러면 위에서 생성한 index.html의 내용을 한번 바꿔보자.

$ vi /var/www/html/index.html

그리고 :wq를 쳐서 저장하고 또다시 EC2 DNS와 CloudFront DNS로 각각 접속해보자.

당연히 CloudFront가 기존의 내용을 이미 캐싱하고 있기때문에 바로 수정내용이 반영되지 않았기 때문이다.

물론 위에서 설정한 캐시 정책(TTL)에 따라 일정 시간이 지나면 캐싱 내용이 업데이트 되겠지만, 만일 급한 중요한 버그 수정과 같은 상황이라면 마냥 기다리기에는 서비스 이용에 치명적인 결과가 일어날수 있다.

따라서 무효화 기능(invalidation)을 통해 수정된 파일이 캐시로 바로 반영하도록 설정해야 된다.

Tip

파일 무효화(invalidate)
- TTL이 지나기 전에 강제로 캐시를 삭제 하는 것
- 주로 새로운 파일을 업데이트 한 후 TTL을 기다리지 못할 상황에 사용 (예를 들어, TTL이 2일인데 어떤 오류가 생겨서 버그수정한 파일을 업로드했지만, 유저에게 전달된 파일은 이미 캐싱된 구버젼 버그가 있는 파일을 CDN하기 때문에 이 기능을 사용한다고 보면 된다)
- 추가 비용 발생 (한달 1000건은 무료. 초과는 요청 하나당 5~6원 받음)
- CloudFront API, 콘솔, third-Party 툴 등을 사용해서 파일 무효화 기능을 사용할수 있음

이렇게 어떤 파일(경로)에 대한 무효화를 진행하게 되면, CloudFront는 등록한 파일이 캐시에 없다고 판단하고 다시 새롭게 파일을 가져오게 된다.

이제 다시 CloudFront DNS로 접속해보면 수정내용이 반영된 웹페이지가 뜨는 것을 확인 할 수 있다.

Tip

만약에 배포를 하는데, 프로젝트가 처음에 수정이 많을경우 TTL을 60초로 짧게 맞춘다던지 해서 개발을 진행하고, 나중에 안정화 되면 다시 TTL을 늘려 캐싱을 길게 하는 식으로 세팅하면 된다.

---

CloudFront 삭제

CloudFront는 전세계에서 배포되는 서비스이기 때문에 바로 삭제가 불가능하다.

우선 비활성화 한뒤 삭제를 진행해야된다. 이 역시 시간이 오래 걸린다.

---