[ DevOps ] - AWS 기반 소규모 & 중규모 아키텍트 설계 - AWS CloudFront 생성 및 캐싱 설정

실습

우선 AWS CloudFront를 배포하기 전에, origin을 ELB로 하겠습니다. 

우선 원본 도메인인 origin을 이전에 만들었던 ELB로 설정해 주었습니다. 그리고 모든 엣지 로케이션에서 사용하도록 했습니다. 이는 가격과 연동되어 있어서, 나중에 바로 실습하고 지워버릴 겁니다.

다음으로는 이제 Route53에 들어가셔서 호스팅영역 수정을 진행해 주어야 합니다. 그 이유는 저기 A 레코드를 보시면 기존에 ELB와 연결되어 있음을 보실 수 있습니다. 이제는 ELB가 아닌 Cloud Front와 연결 시켜주어야 합니다.

 

그리고 위에서 설정 못한 cloud front의 대체 도메인 이름인 CNAME을 추가해 주어야 하는 과정을 수반해야 합니다.

그리고 SSL인증서는 이전에 발급한 인증서가 먹히지 않았습니다. 왠지는 모르겠지만 us-east-1에서 발급한 인증서만 된다길래 새로운 인증서를 부착하고 저장했습니다.

 

그리고 다음과 같이 A레코드들을 다 별칭으로서 배포된 cloud front를 부착해 주었습니다.

 

그럼 정상 작동하는지 확인해 보겠습니다.

https상에서도 잘 돌아갑니다.

 

그후에는 cloud front의 동작 편집을 눌러서 추가 기능에 대해서 알아보겠습니다.

Cloud front가 업데이트 되면서 Legacy cache settings가 default가 아니게 되었다고 합니다. 여기서 최소 TTL, 최대 TTL, 기본 TTL을 설정해 줄 수 있습니다. 이가 왜 필요한지 알아 보겠습니다. 앞서서 말했지만, distribution의 값은 그저 캐시된 값일 뿐 origin의 값이 바뀌어도 바로 바뀌어 지지 않아서 client에게 잘못된 값을 줄 수도 있습니다.

 

이를 위해서 TTL이 존재하는 것입니다. 기본적으로 (초)단위를 지원합니다. 제가 만약에 아래와 같이 postman으로 shop을 추가해 본다고 해 봅시다.

다음과 같이 shop목록에 추가하면 아래와 같이 추가한 shop데이터들이 반영되지 않았을 것입니다.

이는 당연한 결과입니다. 그냥 캐시된 값을 보여주고 있는거죠 하지만 저희가 기본 TTL을 10으로 설정했으니까 10초후에는 이가 아래와 같이 origin에서의 값으로 갱신을 합니다.

그리고 php같은데서는 원래 TTL을 설정할 수 있는데, 이를 위해 최대, 최소 TTL을 설정 할 수 있게 한 것입니다. 이런데서 TTL을 설정한 것을 boundary할 수 있는 기능이라고 보시면 됩니다.