|
| 1 | +## CloudFront란? |
| 2 | + |
| 3 | +<aside> |
| 4 | +💡 html, css, js 등의 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 서비스 |
| 5 | +→ 즉 `CDN` 역할을 하는 서비스다. |
| 6 | + |
| 7 | +</aside> |
| 8 | + |
| 9 | +- “엣지 로케이션”이라고 하는 aws 데이터 센터를 이용하여 전세계 네트워크를 통해 콘텐츠를 제공 |
| 10 | + - 일반적인 웹 서버에서 이미지의 경우 url을 통해 제공되어짐 |
| 11 | + ex) https://example.com/sunsetphoto.png |
| 12 | + - 해당 이미지로 접속하게 되면 여러 네트워크의 복잡한 방식을 통해 라우팅 된다. |
| 13 | + → 클라우드 프론트의 경우 이런 라우팅 방식을 효과적으로 제어해 콘텐츠 배포 속도를 올린다. |
| 14 | + (최종 사용자에게 가장 가까운 네트워크를 사용해서 빠르게 데이터를 제공한다) |
| 15 | + ![[스크린샷 2024-06-05 13.15.19.png]] |
| 16 | + |
| 17 | +전세계에 퍼져있는 aws 백본 네트워크와, 엣지 서버를 활용해 사용자에게 제일 가까이 존재하는 cloudfront를 사용하여 속도를 올릴 수 있다. |
| 18 | + |
| 19 | +### CDN (Content Delivery Network) 이란? |
| 20 | + |
| 21 | +- cdn은 content delivery network의 약자로 네트워크 설계로 인해 발생하는 통신 지연을 줄이기 위한 것. |
| 22 | + - 물리적으로 거리가 멀면 멀수록 지연시간이 생길 수 밖에 없다. |
| 23 | + - 이럴 때 클라이언트와 서버 중간에 캐시 서버를 두어 속도를 높이는 것 |
| 24 | + |
| 25 | +![[스크린샷 2024-07-25 오후 4.46.23.png]] |
| 26 | + |
| 27 | +![[스크린샷 2024-07-25 오후 4.46.28.png]] |
| 28 | + |
| 29 | +## Cloud Front 콘텐츠 제공 방법 |
| 30 | + |
| 31 | +1. 웹사이트 혹은 앱에서 객체(데이터)에 대한 요청을 보낸다. |
| 32 | +2. DNS는 최적으로 요청을 처리할 수 있는 CloudFront POP(엣지 로케이션)로 라우팅 (일반적으로는 지연시간이 가장 짧은 곳) |
| 33 | +3. CloudFront는 해당 캐시에 요청된 객체가 있는지 확인, 있으면 사용자에게 반환 |
| 34 | + 1. 없으면 해당 객체(데이터)의 오리진에서 데이터를 가져옴 |
| 35 | + 2. 오리진에서 첫 번째 바이트가 도착하는 순간부터 CloudFront가 객체를 사용자에게 전달하기 시작. |
| 36 | + 3. CloudFront는 다음에 다른 사용자가 객체를 요청할 때 캐시에 해당 객체를 추가 |
| 37 | + |
| 38 | +- 또한 CloudFront는 캐시를 두단계로 나눠서 관리. |
| 39 | + |
| 40 | +1. 전역 엣지 로케이션인 POP는 사용자에게 가장 가까운 위치. |
| 41 | +2. 리전 엣지 캐시는 리전내에 위치하며 POP을 도와준다. (POP보다는 덜 사용되는 데이터들의 정보를 가지고 있다.) |
| 42 | + |
| 43 | +![[스크린샷 2024-06-05 13.42.27.png]] |
| 44 | + |
| 45 | +## 사용 사례 |
| 46 | + |
| 47 | +- s3 + cloudFront로 정적 웹 콘텐츠 (html, css, js)의 전송속도를 높일 수 있다. |
| 48 | + ![[스크린샷 2024-06-10 13.352331.png]] |
| 49 | +- 미디어를 스트리밍하기 위한 몇 가지 옵션을 제공한다 |
| 50 | + - 온디맨드 비디오 : hls, mpeg dash 등과 같은 일반적인 포맷으로 디바이스에 상관없이 스트리밍 가능 |
| 51 | + - 라이브 스트리밍 : 엣지에 미디어 조각을 캐싱하여 해당 소작을 올바른 순서로 전송하는 manifast 파일에 대한 여러 요청을 결합함으로써 오리진 서버의 부하를 줄일 수 있음. |
| 52 | +- https로도 구성 가능 (보안) |
| 53 | +- 엣지에서 서버리스 코드를 실행하면 지연 시간을 최소화하면서 다양한 방식으로 최종 사용자에 대한 콘텐츠와 환경을 사용자 지정할 수 있다. |
| 54 | + - 예를 들어 오리진 서버가 유지보수를 위해 다운된 경우 최종 사용자에게 일반 HTTP 오류 메시지를 표시하는 대신 사용자 지정 오류 메시지를 표시할 수 있다. |
| 55 | + |
| 56 | +## 특징 |
| 57 | + |
| 58 | +- 기본적으로 Amazon s3 버킷의 파일은 비공개로 설정. 버킷을 만든 AWS 계정만 파일을 읽거나 쓸 수 있는 권한이 있음. (공개 읽기 권한 부여하면 누구나 읽을 수 있음) |
| 59 | +- 사용자 지정 도메인 이름을 사용하도록 할 수 있음 |
| 60 | + |
| 61 | +## 정책 |
| 62 | + |
| 63 | +- 3가지의 정책 설정 가능 |
| 64 | + |
| 65 | +1. 캐시 정책 (Cache Control) |
| 66 | + - TTL 및 Cache Key 정책 |
| 67 | + - 클라우드프론트가 어떻게 캐싱을 할지 결정 |
| 68 | +2. 원본 요청 정책 (Origin Request) |
| 69 | + - 오리진에 쿠키, 헤더, 쿼리스트링 중 어떤 것을 보낼 것인가. |
| 70 | +3. 응답 헤더 정책 |
| 71 | + - 클라우드 프론트가 응답과 함께 실어 보낼 HTTP Header |
| 72 | + |
| 73 | +### 장점 |
| 74 | + |
| 75 | +- 지연 시간을 줄일 수 있음 (사용자가 빠르게 정보를 받을 수 있다.) |
| 76 | +- 보안 관리의 용이 |
| 77 | + - DDos가 줄어듬 |
| 78 | + - DDoS 공격은 호스팅 서버에 과부하를 주어 작동하기 때문에 CDN은 지리적으로 분산되어 있고 사용자와 더 가까운 여러 서버에서 부하를 균등하게 공유함으로써 도움이 된다. |
| 79 | + - 이렇게 하면 한 서버가 다운되더라도 계속 작동하는 서버가 존재한다 |
| 80 | + ⇒ cdn 자체가 여러개의 캐시 서버를 두는 것이므로 오리진에 대한 부하를 효과적으로 줄일 수 있다. |
| 81 | + - 인증서 관리와 자동 인증서 생성 및 갱신을 제공하여 보안을 지킨다. |
| 82 | + |
| 83 | +## 요금 |
| 84 | + |
| 85 | +- 요금의 경우 데이터를 "전송"할 때만 청구된다. |
| 86 | + |
| 87 | +## 기타 |
| 88 | + |
| 89 | +- 캐시 기능으로 인해 원본이 업데이트가 안될 수 있다. |
| 90 | + - 이럴때에는 “무효화 기능(invalidation)”을 통해 수정된 파일이 캐시로 바로 반영하도록 설정할 수 있다. |
| 91 | + → TTL이 지나기 전에 강제로 캐시 삭제하는 것, 추가적인 비용이 발생한다 (1000건 무료, 그 뒤는 요청 하나당 5~6원) |
| 92 | + |
| 93 | +### Reference |
| 94 | + |
| 95 | +[[AWS] S3와 CloudFront 연동하기](https://velog.io/@rungoat/AWS-S3와-CloudFront-연동하기) |
0 commit comments