[AWS] 10. CloudFront(CDN) 이해 및 사용해보기

안녕하세요. 갓대희 입니다. 이번 포스팅은 [ AWS - CloudFront란?(사용해보기)  ] 입니다. : )

0. 들어가기 앞서

 ▶  CloudFront란 AWS에서 제공하는 CDN(Content Delivery Network or Content Distribution Network, 콘텐츠 전송 네트워크) 서비스를 의미한다.

 

▶  CDN에 대해선 최소한의 내용만 체크하고, 실습 위주로 진행 해보려고 한다.

 

▶ CloudFront의 사용 사례는 다음 자습서를 통해서도 확인할 수 있다.

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

ex1) 정적 웹사이트 콘텐츠 전달 가속화 (Accelerate static website content delivery)

 - CloudFront는 정적 컨텐츠(예: 웹페이지, 이미지, 스타일 시트, JavaScript 등)를 전 세계 사용자에게 빠르게 제공할 수 있다.

 - 나와같은 경우도 해당 목적을 위해, 즉 정적 컨텐츠 라고 하는 이미지, JS, CSS 등을 CDN으로 Delivery 하기 위해 사용해 왔다.

ex2) 영상 및 라이브 스트리밍에 활용 될 수 있다.

ex3) 이이에도 Lambda@Edge를 활용 프라이빗 컨텐츠 제공 등등에도 활용될 수 있다.

 

▶ 이번엔 하기 자습서와 같이 S3를 활용하여 정적 컨텐츠를 CloudFront에 배포 해보려고 한다.

https://aws.amazon.com/ko/blogs/korea/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/

 

1. Cloud Front  및 CDN 특징

CDN 특징

 - 정적 컨텐츠(웹 페이지, 이미지, Javascript)등의 컨텐츠를 원본(Origin)서버에서 받아와 캐싱하여 둔다. 

 - 해당 컨텐츠에 대한 요청이 들어오면 CDN을 통해 캐싱해둔 컨텐츠를 제공 한다.

 - 서버의 할 일을 CDN이 대신해주기 때문에 서버의 부하를 낮추기도 한다.

 

Cloud Front 특징

 - AWS에서 제공하는 CDN 서비스의 이름이 Cloud Front라고 보면 된다. 

 - 파일(객체)의 사본이 전 세계 여러 엣지 로케이션에 캐싱되므로 안정성과 가용성이 향상 된다.

 - 간단한 동작 원리

1) 클라이언트가 CloudFront로 컨텐츠 요청을 하게 된다. (ex 웹사이트 접속) 

2) 가깝고 상태가 좋은 엣지 로케이션(임시 데이터 저장소)으로 Routing

3) 해당 캐싱 서버에 Client가 요청하는 컨텐츠가 캐싱되어 있는지 확인 한다.

     ┗ Case1) 캐싱된 컨텐츠가 존재 한다면 : 사용자 요청에 응답 한다.

     ┗ Case2) 캐싱된 컨텐츠가 미 존재시

          ┗  1) Origin Server로 해당 요청을 포워딩 한다.

          ┗  2) Origin Server에서 컨텐츠를 받은 후 캐싱 데이터를 저장한다.

          ┗  3) 사용자 요청에 응답 한다.

 

정말 간단하게 표현하였는데,  시간이 허락 된다면 웹 캐시에 대해서는 간단하게 라도 내용을 알고 있으면 좋을 것 같다.(하기 링크 참조)

2023.08.09 - [2. 웹개발/웹개발 기본] - 웹 Cache(웹 브라우저 캐시) & 헤더 다루기

 

ex) 요청한 사용자 컴퓨터(Client)의 위치가 대한민국이고, 원본 서버(OriginServer)가 미국에 위치 해있다고  가정해보자.

 

Case1) CDN을 사용하지 않을때

 - 지리적으로 먼 거리에 있는 리소스를 다운 받으려고 하면, 대한민국에 오리진 서버가 있는 것과 비교하여 상대적으로 느릴 수 밖에 없다.

https://aws.amazon.com/ko/blogs/korea/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/

 

Case2) 이런 경우 CDN을 사용하고 있다면 효과가 매우 클 수 있다.

 - Client 입장에서는 미국에 있는 원본서버와 직접 통신할 필요 없이 가까운 위치의 CDN과 통신하면 된다. 

 - 직접 미국에 있는 Origin Server와 통신할 때 보다 훨씬 빠르게 통신할 수 있다고 볼 수 있다.

https://aws.amazon.com/ko/blogs/korea/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/

 

2. CloudFront 구축 해보기

 - 최근 react, vue등이 급격히 발전함에 따라 정적 웹 사이트로 서비스를 운영하는 경우가 많아 졌다.

 - 이와 관련하여 CloudFront를 통해 정적 웹 사이트 호스팅하는 방법을 통해 CloudFront 구축 해보려고 한다.

1. S3 + CloudFront로 정적 웹 사이트 호스팅 하기

※ S3를 통해 정적 웹 사이트 호스팅 하는 방법은 하기 링크를 통해 선행 되어야 한다. (해당 포스팅에선 생략)

2023.09.25 - [6. DevOps/AWS 기초편] - [AWS] 6-3. AWS - S3를 통해 정적 웹 사이트 호스팅 하기(3)(S3로 index.html 호스팅 하기)

 

 - 위의 작업이 완료 되었다면 CloudFront를 검색하여 관리 콘솔로 이동 하자.

 - "CloudFront 배포 생성" 클릭.

 - 원본 도메인(Origin Domain) 선택 : 위에서 설정해준 S3 버킷을 선택 하여 주자.

 - S3를 웹 사이트로 사용 하려고 하니 "웹 사이트 엔드포인트 사용" 클릭.

 - 나는 http로 요청오는 것도 https로 전환하고자 하여, 뷰어 프로토콜 정책을 "Redirect HTTP to HTTPS"로 체크 하였다. 

 - 캐시 키 및 원본 요청은 기본 설정 그대로 둔다. 

※ 참고

1) 캐시 정책 (정책 보기 클릭 하여 확인)

1) TTL(Time to Live)

 - 캐싱된 컨텐츠(객체)가 살아 있는 시간을 말한다. 즉 캐싱된 객체는 TTL 이후 캐싱에서 삭제 된다.

 

2) 캐시 키(Cache Key)

 - 헤더, 쿠키, 쿼리 스트링(문자열)을 사용하여 컨텐츠를 캐싱할 수 있다.

ex) 같은 URL로 접속 하더라도 위의 방법을 사용하여 다르게 설정 가능 하다.

 

3) 컨텐츠 압축도 현재 2가지 방법으로 지원 해 주고 있다.

 - 람다는 다른 실습에서 다루며, 해당 포스팅에선 설정하지 않고 넘어 간다.

 - 방화벽 설정을 할 수 있다. 거절된 요청은 403(Forbidden) Status 응답을 받게 된다.

 - 나머지 설정도 기본설정을 유지 하고 넘어가도 무방하다.

1) 가격 분류

 - 지역 범위 까지의 Edge Node를 사용할지 선택 한다.

   (실습시에는 3번째인 "북미, 유럽, 아시아, 중동 및아프리카에서 사용"이 무난할 것 같다.)

2) 대체 도메인 이름(CNAME) : 직접 도메인 이름을 지정할 때 사용한다.

3) SSL 인증서 : https를 이용하여 객체에 접근 시 사용할 인증서.

 - Default CloudFront Certificte : CloudFront에서 제공하는 인증서 사용한다.

 - Custom SSL Certificate : 개인 소유의 SSL 인증서나 ACM을 통해 발급받은  SSL 인증서를 사용한다.

4) 지원되는 Http 버전을 추가할 수 있다.

5) 기본값 루트 객체 : 이번 실습의 경우 index.html을 생성하였기 떄문에 입력 하여 준다.

6) 표준 로깅은 끄고, IPv6는 켜기 를 체크 한다.

 

 

 - 최종 점검 후 배포 생성 클릭.

 

- 하기 표시된 URL로 접속하면 S3에서 설정 하였던 정적 웹 사이트가 동일하게 노출되는 것을 볼 수 있다.

 

 

※ 추가 실습 (Cache-Control, 캐시 무효화)

 - 원래 대로라면 한번 접속 후 두번, 세번 새로 고침을 하게되면 Status Code가 301 ㅇㅇㅇㅇ 로 떨어져야 한다.

 - 다만 내가 실습했던 S3 설정을 그대로 따라왔다면 S3 메타정보 설정에 의해

   다음과 같이 Response Header 정보를 확인할 수 있으며 Status 200(OK), 즉 캐싱된 데이터가 아닌 매번 새로운 데이터를 받고 있는것을 볼 수 있다. 

 

1. index.html을 캐싱될 수 있도록 원본 객체의 Meta정보를 변경 해보자.

 - S3 콘솔로 이동 > 해당 버킷 이동 > "index.html" 클릭

 - 하단에 내가 설정해 두었던 정보를 확인 할 수 있다. "편집" 클릭.

 - Cache-Control 영역 "제거" 클릭 후 "변경 사항 저장" 클릭.

 

2. 캐시 무효화 하기

 - Cloud Front 콘솔 접속 > 무효화 탭 클릭 > "무효화 생성"을 클릭 하여 준다.

 

 - 현재는 index.html 파일 1개 밖에 없기 때문에 /index.html을 입력해도 되고, /*을 입력 해도 된다. 입력 후 "무효화 생성" 클릭.

 

 - 다시 CDN에 접속해 보자.

1) 최초 접속시 Status Code는 200 OK 이다.

2) 아까 있었던 Response Headers의 Cache-Control 영역이 없어진 것을 확인할 수 있다.

 

- 한번 더 새로 고침 해보자. Status 304(Not Modified)가 떨어지는것을 볼 수 있다.

 

※ 참고

 - CloudFront 대시보드에서는 다음과 같은 통계 정보를 제공해 준다.

ex) Toss 광고 트래픽을 감당 하기위해 CloudFront를 활용해 보았다. (30만 Traffic을 보장한다고 한다.)

 

ex1) 2번 이상 접속한 Traffic이 304 Not modified, 약 2만 3천회 정도 있지 않았을까 예측 되어 진다.

 

ex2) 늘 느끼지만 내 주변엔 다 아이폰인데, 실제 사용자는 안드로이드가 압도 적이다. 브라우저 정보도 확인 가능 하다.

 

ex3) 방문이 가장 많았던 객체와 같은 insight를 주기도 한다.

 

ex4) redirect to https로 설정 하였기 떄문에 각각의 요청수도 확인 가능하다.

 

ex5) 위치 정보를 확인할 수 있다.

 

 

 - 웹서버 없이 간단하게 S3를 Origin Server로 두고 Cloud-Front(CDN) 구축 해보는 것을 실습해 보았다.

 - 좀더 여유로울 때 웹서버를 통해 연동하는 방법 등등 예시를 좀더 추가 할 예정이다.