[AWS] CloudFront 에 대하여

https://bosungtea9416.tistory.com/entry/AWS-CloudFront

[AWS] CloudFront 에 대하여

https://real-dongsoo7.tistory.com/86

[AWS 파헤치기] #2 CloudFront(CDN)가 뭐야?

 

위의 글을 참고하여, 학습을 위해 본 글을 작성하였습니다.

---

최근 들어, 건국대학교 러닝앤쉐어링 프로젝트를 계획하기 앞서 인프라에 대해 더 공부하고자 AWS CloudFront를 정리하고자 한다.

왜 CloudFront를 사용해야 할까에 대해 고민해봤다. 우리 팀이 구상하는 앱은 건국대학교 재학생 전체를 대상으로 하는, 학교 도우미(공지사항 제공, 지도 정보 제공, 시설 대여) 애플리케이션이다. 

 

만약 재학생 전부가 API를 요청하였을 때, 스프링 + JDBC 특성상 블록킹으로 처리되어 API 응답속도가 느릴 수 있다. 이는 서버의 안정성에 위배된다.

따라서 CloudFront라는 캐싱 서버를 따로 제공하여, 본 서버에 매번 API 요청을 하는 것이 아니라, 미리 저장된 데이터를 제공하고자 한다. CloudFront의 정적, 동적 컨텐츠 처리로 매번 요청이 필요한 API를 제외하고, CloudFront 단에서 API를 처리하고자 한다.

 

AWS CloudFront 란?

AWS CloudFront는 AWS의 CDN (Content Delivery Network) 서비스이다.

CDN 서비스란 Client의 콘텐츠 요청으로 서버에서 받아온 콘텐츠를 캐싱하고 이후 같은 요청이 왔을 때, 그 캐싱해 둔 것을 제공하는 서비스다. 이렇게 함으로써 물리적으로 거리가 먼 곳에도 빠르게 요청을 처리할 수 있고 결과적으로 서버의 부하를 낮출 수 있다고 한다.

 

Edge Location(Pop) / Regional Edge Caceh(REC)

Edge Location은 CloudFront 서비스가 콘텐츠를 캐싱하고, Client에게 제공하는 지점 혹은 캐시 서버를 의미한다.

 

장소나 환경에 구애를 최대한 받지 않도록 빠른 서비스를 제공하기 위해 전 세계 주요 도시에 Edge Location이 분포되어 있다. 사용자가 요청한 콘텐츠의 캐시가 Edge Location에 있다면 가까운 Edge Location에 저장된 캐시를 불러올 수 있다.

 

리전 엣지 캐시(Regional Edge Cache)는 사용자가 접근할 수 있는 글로벌 하게 배포되어 있는 CloudFront 위치이다. 오리진과 Edge Location 사이에 위치해 있는데, 콘텐츠가 캐시가 유지될 정도로 인기 있지 않아도 캐시는 더 오랫동안 남으며, Edge Location보다 캐시 스토리지 용량이 더 크다. 따라서 REC로 인해 CloudFront가 오리진에 요청하는 것을 줄여준다.

 

CloudFront 동작 순서

 

1. 사용자가 어플리케이션에 요청을 한다.

2. DNS는 사용자에게 적합한 Edge Location으로 라우팅 한다.

3. Edge Location에서 캐시를 확인하고 있으면 이것을 사용자에게 반환한다.

4. 없으면 가장 가까운 REC로 캐시가 있는지 요청한다. 

5. 없으면 CloudFront는 오리진으로 요청을 전달한다.

6. 오리진은 '오리진 > REC > Edge Location > CloudFront가 사용자에게 전달' 수순을 밟는다. (캐시도 추가된다)

7. REC에 캐시가 있다면 REC는 콘텐츠를 요청한 Edge Location으로 반환한다.

8. REC로부터 콘텐츠의 첫 번째 바이트가 도착하는 즉시 Edge Location은 이를 사용자에게 반환한다.

7. Edge Location은 나중을 위해 이 콘텐츠 캐시를 저장한다.

 

CloudFront의 Static(정적)  / Dynamic(동적) 콘텐츠 처리

 

CloudFront는 다른 CDN과 다르게 '정적' 콘텐츠와 '동적' 콘텐츠를 모두 처리한다. 

 

정적 콘텐츠에는 서버(EC2)가 필요하지 않은 이미지 같은 것이 포함된다. 미리 캐싱해둔 뒤, 모든 사용자에게 동일하게 전달해줘도 무방한 데이터에 사용할 수 있다.

 

동적 콘텐츠는 서버가 필요한 콘텐츠를 의미한다. 즉, 서버가 무언가 해줘야 하는 데이터다. 예를 들면 뒷단의 데이터베이스에서 끌어오는 로그인 자료라던지 혹은 실시간으로 새롭게 추가되는 게시판이 될 수 있다. 이런 자료를 정적 캐싱한다면 TTL 시간 동안 사용자는 새롭게 추가/수정된 데이터를 볼 수 없게 된다.

 

이것을 간략하게 AWS 구성해보자면 다음과 같다. 서버(EC2)의 연산이 필요한 동적 콘텐츠의 요청을 EC2로 향하게 Distribution 처리하고 서버가 필요하지 않은 정적 콘텐츠는 S3 버킷 등으로  Distribution 처리하는 구성을 고려해볼 수 있다.

 

CloudFront의 여섯가지 기능도 있다고 한다.

 

1. HTTPS 지원 기능

 

2. 특정 지역 콘텐츠 접근 제한 기능

 

3. Signed URL 기능

cloudFront는 허용된 사용자에게만 접근할 수 있는 signed url 제공한다. 

1. 콘텐츠에 접근할 수 있는 사용자를 정한다

2. signed url을 생성해 특정 컨텐트만 접근하도록 구성한다

3. 사용자가 해당 콘텐츠를 요청한다

4. 사용자를 검증한다

5. 검증에 성공하면 signed url을 제공한다

6. 사용자는 signed url을 통해 콘텐츠에 접근한다

 

4. Signed Cookie 기능

CloudFront는 Signed Cookie 기능도 제공한다. Signed Cookie는 하나가 아닌 다수의 콘텐츠에 사용될 수 있다.