EIF 1: First Project (1) - AWS 배포 및 Cloudfront Cache 삭제

이건 TIL이라기보다는 2WIL(2 Weeks I Learned)가 될 것 같습니다.

 

에러를 만나고 해결할 때마다 기록하고 싶은 것들은 노션에 적어놨었습니다. 이제 블로그에도 틈날 때마다 정리해서 올려보려고 합니다.

먼저 AWS 배포 관련해서 만났던 에러들을 어떻게 핸들링했는지 정리해보았습니다!

 

AWS 배포

Route53에 Server도 A나 CNAME으로 레코드 추가해주기

 

여기서 A나 CNAME 은 DNS의 일종입니다.

 

DNS는 Domain Name System의 약자로 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 만들어진 시스템입니다. 예를 들어 www.example.com 과 같은 주 컴퓨터의 도메인 이름을 192.168.1.0과 같은 IP 주소로 변환하고 라우팅 정보를 제공할 때 쓰이는 시스템입니다.  

 

A Record는 DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소를 직접 매핑시키는 방법입니다. 위와 같은 www.example.com이 A Record에 해당됩니다. 

 

CNAME Record는 Canonical Name Record의 약자로 하나의 도메인 네임을 또 다른 도메인 이름으로 매핑시키는 도메인 네임 시스템의 일종입니다. 하나의 IP주소로부터 한 개가 아닌 여러 개의 서비스를 실행할 때 좋습니다. 또는 IP 주소가 자주 바뀌는 환경에서 유연하게 적용할 수 있다는 장점이 있습니다. 

한편, 실제 IP 주소를 얻을 때까지 여러 번 DNS 정보를 요청해야한다는 점이 단점이 될 수 있습니다. 이 점은 성능저하를 유발할 수 있기 때문입니다.

 

 

 

 

 

 

Cloudfront Cache 삭제

이전에 만들었던 버전으로 클라이언트 배포 자동화를 하고 난 후, 클라이언트 부분이 업데이트 되어 새로 머지했었던 적이 있었습니다. 이후 제대로 반영이 되었는지 도메인에 접속했는데 하나도 반영이 되어있지 않았습니다. 파이프라인을 확인했을 때 제대로 배포 단계까지 잘되었다고 나와있어서 에러가 어디서 났는지 찾기 어려웠습니다. 구글링을 해보니 CDN 캐시를 삭제해야 한다는 말이 있어 삭제해보았더니, 클라이언트 변경 부분이 잘 반영되었습니다.

그 이유는 아래 그림을 참고하면서 설명해보겠습니다.

 

CDN과 Edge의 작동 예시

Cache가 없는 Empty Edge는 Origin에 있는 파일을 가져옵니다.

반면, Cache가 있는 Cached Edge는 캐시된 파일을 전달합니다. 요청 처리 속도 부분에서는 캐시된 파일을 바로 전달해주니 Empty Edge를 통해 전달하는 것보다 훨씬 유리할 것입니다. 하지만 오리진 파일이 변경되는 경우에는 기존의 캐시된 파일을 보내줄 것이 아니라, 새로 오리진에서 파일을 가져와 캐시를 해야하기 때문에 캐시를 삭제해야 반영할 수 있었던 것입니다.

 

 

실제로 Response를 확인해보니 아래와 같이 x-cache: Hit rom cloudfront라고 되어있었습니다. 

Hit from cloudfront

 

 

 

캐시를 아래와 같은 방법을 이용해서 캐시를 삭제했습니다.

CDN cache 삭제

 

 

삭제하고 나니 x-cache가 Miss from cloudfront로 바꼈습니다.

Miss from cloudfront