Cloudfront 가 이전 버전을 띄워줄 때 (Devlog 10일차)
"이럴 바에야 자동화가 무슨 소용인가.."
Invalidations
S3 의 버킷 웹 사이트 엔드 포인트로는 배포한 클라이언트가 잘 바뀐 채로 적용이 되었는데, CloudFront 에서는 적용이 안 되는 경우라면 이 글이 도움이 될 수 있을 것 같습니다.
본론부터 바로 달려보겠습니다.
이미지 1
이미지 2
- CloudFront 의 Distributions 에서 활성화되어있는 distribution 의 id 를 클릭합니다.
- 오른쪽에서 2 번째에 위치한 Invalidations 메뉴를 클릭하고 Create Invalidation 버튼을 클릭합니다. (이미지 1 참고)
- 전부 다 바꾸려면
/*을 넣고 Create invalidation 버튼을 클릭합니다. (이미지 2 참고)
기본적으로 CloudFront 는 24시간 동안 Amazon S3 에서 응답을 캐시한다고 합니다. 즉 CloudFront 를 통해 엣지 로케이션으로 S3 객체가 전달되면 최소 24시간 동안은 캐시된 응답을 돌려주게 된다는 것이죠.
위의 방법은 바로 이 캐시된 S3 객체를 무효화해서 엣지 로케이션이 아닌 Amazon S3 에서 직접 객체를 검색하도록 하는 방법입니다.
참고로 위의 방법에 대해, 매달 1,000건의 무료 무효화 경로가 허용된다는 안내가 있습니다. 이 부분은 유의하실 필요가 있겠습니다.
위의 내용이 안내되어 있는 AWS 공식 Q&A 답변을 링크합니다.
캐시 설정 수정
사실 24시간을 기다리면 해결될 문제이긴 합니다만, 개발 단계에서 버그 수정 등이 잘 적용되었는지를 빠르게(한국인답게) 확인하고 싶을 때가 있잖아요.
CloudFront 의 캐시 설정은 다음과 같이 변경이 가능합니다.
- 해당하는 Distribution ID 를 클릭하고, 왼쪽에서 3 번째에 있는 Behaviors 메뉴를 클릭합니다.
- (아마도 Path Pattern 에 Default 라고 되어있을) 적용되어 있는 Behavior 를 선택하고 Edit 을 클릭합니다.
- Cache key and origin requests 부분에서 Cache policy 아래의 Create policy 를 클릭합니다. (이미지 3 참고)
- TTL settings 에서 Default TTL 을 원하는 시간으로 설정하여 policy 를 만들어주고, 만든 policy 를 선택해 설정합니다. (이미지 4 참고)
이미지 3
이미지 4
Outro
저녁 시간을 삽질하며 보낸 덕분에 오래된 콘텐츠를 빠르게 수정해서 반영하는 방법을 알게 되었습니다만, 클라이언트를 해결하고 나니 이번에는 서버가 문제입니다. EC2 가 아까부터 굉장히 느리게 접속되더니, 인스턴스를 껐다 킨 지금은 아예 접속이 안되네요. ㅠㅠ
산 넘어 산이긴 합니다만..이렇게 한 걸음씩 더 전진해나가는 거겠죠. 이제 EC2 를 해결하러 또 다시 구글의 바다로 떠나보겠습니다.
