AWS CloudFront의 역할

이번에 서비스 이미지 로딩속도 개선을 위해 AWS lambda@edge를 공부하던 중

두루뭉술 알고 있던 CloudFront를 다시 한번 공부하며 기록을 남깁니다.

 

CloudFront는 html, css, js, image 등 정적, 동적 콘텐츠를 전 세계 사용자에게 더 빠르게 제공하도록 지원하는 웹서비스이다.

어떻게 더 빠르게 지원하느냐!

결론부터 말하자면 S3나 EC2같은 오리진 서버 말고. 전 세계 곳곳에 사용자 가까이에 '엣지로케이션'이라고 하는 데이터 센터를 두고

사용자가 CloudFront를 통해 들어오면 지연시간이 가장 낮은 엣지로케이션으로 요청을 라우팅 한다.

그리고 이 엣지로케이션에 콘텐츠가 캐싱되어 있다면 오리진에 요청을 보내지 않고

사용자가 가까운 엣지로케이션이 바로 콘텐츠를 응답한다.

보통 'https://exam.com/sunsetphoto.png' 같은 데이터 저장소(예를 들면 s3) url을 통해 오리진서버와 통신해서

이미지를 로딩하는데, 이는 엄청나게 복잡한 네트워크 라우팅 과정이라고 한다.  

CloudFront는 AWS 네트워크를 통해 가장 효과적으로 네트워크 할 수 있는 엣지로케이션으로 각 사용자를 라우팅 해서

빠르게 콘텐츠를 제공한다. 이를 통해 반드시 통과해야 하는 네트워크 과정이 줄어들어 데이터 전송속도가 빨라진다.

또한 한번 받아온 정보는 각 엣지로케이션에 캐싱되어 데이터로 존재하게 된다.

그래서 만약 서울의 엣지로케이션에 첫번째 유저가 접속해서 오리진을 통해 콘텐츠를 받아왔다면

서울의 엣지로케이션에 캐시가 남아 두 번째 유저부터는 오리진을 통하지 않고 엣지로케이션에서 바로 응답을 받는다.

만약 캐싱되어있지 않다면 오리진서버에서 콘텐츠를 검색하고 캐시를 남겨둔다.

클라우트 프론트를 구성하는 방법:

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

  

 

엣지로케이션에 캐시가 있는 경우와 없는 경우 네트워크가 어떻게 이루어지는지 나타낸 이미지이다.

캐시가 있을 때는 1,2,3 순서로 유저에게 서빙되고 캐시가 없는 경우에는 1,2,3a,3b, 3c의 과정을 거친다.(첫 번째 유저만)

전 세계에 분포되어있는 엣지로케이션 위치이다. 

추상적 개념이 아니라 진짜 물리적으로 존재하는 데이터센터이다.

이것은 우리 서비스의 정적 콘텐츠 최적화 과정을 파악한 것이다.

다음에는 검은색으로 표시된 lambda edge에 대해 공부하고 글을 남긴다.

 

실제 로딩시간 비교

위 캡처는 클라우드프론트로 정적파일을 요청했지만 캐시가 없어서 Miss from cloudfront가 뜬 요청이다.(로컬에서 테스트)

즉 첫 번째 유저의 네트워크인데, 26.7kb의 파일을 받는데 465ms가 걸렸다.

위 캡처는 두 번째 유저의 요청이다. 강력 새로고침으로 브라우저 캐시를 전부 날리고 다시 로딩했지만 

엣지로케이션에 캐시가 남아있기 때문에 Hit from cloudfront로 뜬것을 볼 수 있다.

그리고 네트워크가 오리진까지 갈 필요가 없기 때문에 이번에는 52ms 만에 응답을 받은 것을 볼 수 있다.

둘 다 status는 200번이지만 엣지로케이션의 응답은 항상 더 빠르다

 

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

Amazon CloudFront란 무엇입니까? - Amazon CloudFront