AWS CloudFront.feat caching

캐싱이라는 기능을 아는가? 일반적으로 서비스의 품질을 높이기위해 사용하는 기능. 속도가 느린 경우, 캐싱을 활용해 서비스 속도를 높여줄 수 있는 기술이다. 동일한 요청이 지속적으로 들어올 경우, 인프라 용량이 지속적으로 과부화(서버 부담, 효율적이지않음, 부하가 발생)가되곤한다. 이떄 캐싱을 사용하게 되면, 운영비용을 줄일 수 도 있으며, 서비스의 속도가 빨라진다.
주로 개발자가 제공해주는 서비스를 이용하는 고객들이 있을건데, 이런 고객들에게 좀 더 빠른 속도로 제공해주는 저장공간, 시설을 이용할때 사용한다.

 

그렇다면 어떤 데이터를 캐싱하는게 좋을까?
3가지의 경우가 있다.

1. 수집하기에 느리고 비싼 쿼리가 필요한 데이터 => 동일한 쿼리가 들어오는데, 그때 그때마다 복잡한 쿼리문이 실행되며, 동일한 결과를 산출할때
2. 비교적 정적이고, 일정기간동안 변화가 없는 데이터 => 웹사이트 프로필과 같은 경우
3. 일정기간 동안 변화가 없을 수 있는 정보

이런 케싱의 이점은 어떤게 있을까?

응답지연이 감소하게된다. ==> 그렇다면 당연히 에플리케이션 속도가 향상된다 ==> 이때 DB와 연관되어있다면 당연히 DB의 쿼리에 대한 부담이 완화된다 ==> DB가 여유로워지니 인스턴스를 줄일 수 있게 된다. ==> 즉 비용의 감소가 이루어진다.

캐싱의 종류는 크게 2가지로 클라이언트 측 캐싱과 서버 측 캐싱이 있다.

클라이언트 측 캐싱은 대표적으로 웹 브라우저가있다.

헤더에 담겨진 정보 중 캐싱과 관련된 정보가있다. 이때 웹 브라우저가 이것을 보고, 저장을 해도 되며, 저장을 할 수 있는 시간이 정해진 내용을 보며, 이 응답받은 값을 임시 저장공간에 저장한다. 이 후 똑같은 요청을 받을때, 웹서버로 그 내용을 보내는것이 아니라 저장된 내용을 그대로 산출한다.
==> 이렇게되면 웹 서버에 대한 부담을 줄일 수 있게 된다.

서버 측은 웹 서버와 역방향 프록시 캐시가 있다. 
역방향 프록시 케시는 웹 브라우저와 웹 서버 사이에 있는데, 이때 캐싱을 사용하게 되면, 웹 브라우저에서 웹 서버로 데이터가 흐르는것이 아니라, 역방향 프록시 캐시로 먼저 가게 된다. 그때 캐시 서버는 저장된 내용이라면 그 내용을 산출하며, 저장되어있지 않은 내용의 경우 웹 서버에 요청해 다시 응답을 보내게 된다.

이런 캐싱이 AWS에서는 엣지로케이션에있는 CDN 서비스(CloudFront)를 통해 활용할 수 있다. 
일반적으로 글로벌 환경에서 자주 쓰이게 되는데 예로서 한국에서 Web서비스를 진행한다고 가정해보자.
동아시아의 사람들은 위치가 가깝기때문에 별 문제없이 서비스를 접근하고 사용할 수 있다. 하지만 남미, 유럽과 같이 멀리 있는 국가의 경우 웹 서버가 무겁다면(동영상이 있다거나, 사진이 많은것 등의 경우) 사용하기에 굉장히 불편할 것이다. 이때 각각의 리전에 CDN을 활용하여 로딩하는데 오래 걸리는 데이터들을 캐싱해두면, 다른 지역에서도 응답속도를 충분히 빠르게 사용할 수 있다. 정적인 데이터를 캐싱한다.

CloudFront의 특징
다중 계층 캐시와 광범위한 유연성 등의 다양한 환경에 대해 최적화가 되어있다. 또한 waf(웹 방화벽), shiled(DDoS)와 같은 서비스를 엣지로케이션에서 활용할 수 있기 때문에 추가적인 보안 계층을 제공하게 된다. 또한 WebSocket프로토콜(정적인 컨텐츠이지만 동적으로 움직일 수 있게 해 주는 서비스)을 지원해준다.

정적, 동적 자료를 둘다 cloudfront를 거쳐서 사용자에게 제공할 수 있게 한다면 3가지의 장점이 생긴다
1. 설정의 용이함.
정적 자료는 cloudfront로, 동적자료는 인터넷으로 가도록 설정하면 설정을 할 때 굉장히 번거로워진다.
2.Transfer Acceleration을 활용해 좀 더 빠르게 접근할 수 있게 해 준다.
가까운 엣지 로케이션까지는 인터넷, 엣지 로케이션에서부터 S3까지는 AWS 백본망을 이용해서 접근한다. 그렇게 된다면 좀 더 빠르게 접근할 수 있게 된다.
3. 보안계층이 생성된다.
4. 동적 컨탠츠에 짧은 캐싱을 사용해 동적 컨탠츠를 제공하는 인프라의 부담을 굉장히 많이 줄일 수 있다.(포털사이트 기사, 댓글, 인터넷 실시간 투표 등이 대표적인 예시)

구성방법 및 작동 방식
1. 원본을 만든다.(S3나 인스턴스 등)
2. 클라우드 프론트 배포(웹 배포) ==> 오리진 위치, 인증서, 유지시간, 암호화 통신 등을 설정한다
3. 생성된 내용에 대해 DNS 가 할당 ==> 엣지로케이션은 모든 지역을 선택할 수 도 있다. 그렇게 된다면 사용자는 혼동이 올 수 있으며, 이것을 방지하기위해 DNS레코드는 1개만 설정된다. 사용자는 이 단 1개의 DNS을 보고 접근을 하면, AWS에서 가장 가까운 지역으로 분산시켜준다. 
4. 내가 선택한 환경으로 구성 정보가 배포가 된다. ==> 바로 캐싱을 하는것이 아닌, 구성정보만 지정이되며 데이터는 따로 없이 준비만 된 상태이다.

 

==> 여기서부터 작동방식

5. 4에서 만들어진 환경에서는 특별한 필터링 없이(데이터가 없기에) 오리진으로 신호를 보낸다.
6. 오리진에서 캐싱을 위해 엣지 로케이션으로 전송된다
7. 전송된 데이터는 사용자에게 보여준다.
8. 4~7의 환경이 반복되면서 캐싱이 되어있지 않은 데이터는 조금 오리진에서, 캐싱이 된 데이터는 cloudfront에서 바로바로 응답해준다.

캐싱 자료 관리
이렇게 캐싱된 자료는 TTL, 객체 이름 변경, 객체 무효화 라는 콘텐츠 만료 방법을 통해 관리할 수 있다. TTL time to live
개발자가 지정할 수 있으며, 지정된 만큼만 저장하며 만료가 된다면 if-modified-since 헤더를 사용해 원본(오리진에 있는 파일)과 저장된 캐시의 차이점을 확인한 후, 차이점이 없다면 삭제하지 않고 유지(TTL을 늘림), 삭제가 있다면 삭제 후 원본에서 다시 데이터를 가져온다. 지금 당장 보여줄 필요가 없는 자료(예약)들이 주로 사용된다.

객체 이름 변경
개발자가 조금 귀찮지만, 매인 페이지에 구성된 코드(링크)를 수정하면 즉각적으로 변경되어 적용된다.

객체 무효화
cloudfront에 저장된 데이터를 삭제하는 서비스이다. 굉장히 비효율적이며 비용이 많이 든다.

ELB를 한번 생각해 보자. ELB를 사용하게 된다면 외부에서 들어오는 트레픽이 인스턴스에 분산이된다. 
사용자가 로그인을 하게 된다면, 최초로 접근한 서버(분할된 인스턴스)에는 로그인을 했다는 기록이 남아 있지만, 새로고침과 같은 활동으로 인해 ELB(ALB)가 작동해 다른 서버로 분산이 된다면 그 서버에는 로그인 기록이 남아있지 않게 되며, 다시 로그인을 해야하는 불편함이 있다. 이것을 극복하는 방법으로 웹 계층의 캐싱(세션 관리)을 사용하면 되는데, 고정세션과 DynamoDB를 활용하면 된다.

고정세션(Sticky  세션)
ELB에 고정세션을 on으로 하게 되면 최초에 연결된 인스턴스에 고정이 되어서 항상 동일한 인스턴스가 응답을 하게 된다. 
하지만 탄력성을 가지는 인프라를 구축했다고 해 보자. 사용자의 수가 기하급수적으로 늘어나게 된다면 모든 PC의 리소스를 증가시켜야 하는 번거로움이 생긴다. 또한 사용자의 수가 줄어들어서 오토스케일링을 하게 되었을때, 기존 사용자와 연결된 인스턴스가 사라지게 된다면, 세션이 끊겨서 사용자는 불편함이 생기게 될 수 있다.

이런 불편함을 극복하기 위해 고정세션 대신 DynamoDB를 만들어서 각각의 서버들이 세션정보를 DB에 업로드하여, 이곳을 기준으로 세션을 확인하는 방법을 사용할 수 있다. 굉장히 빠른 동작속도를 가지고 있기에 세션을 저장하는 용도로 충분히 사용할 수 있다. 하지만 DynamoDB를 사용하더라도 "세션이 느리다" 라고 느낄 때가 있다. 그럴때는 Database 계층에서 캐싱을 활용하면 된다.

관계형 데이터베이스의 경우 DB의 인스턴스 타입을 높여주거나, 더 좋은 성능의 스토리지로 바꾸면된다. 혹은 쿼리를 수정한다거나 하는 등의 작업을 하면 된다. 하지만 DynamoDB는 그렇게 할 수 없기에 DynamoDB Accelerator라는 마이크로초 단위의 응답시간을 가지는 서비스를 활용해야한다.

DynamoDB Accelerator라는 기능은 DB의 응답이 느려서 걱정이 될 때나, 부하가 큰 용량을 요청하여 DB의 성능이 부족할때, DB의 비용을 줄이고 싶을때 사용할 수 있다. 굉장히 빠른 속도의 캐싱환경이 자동으로 만들어지며, 높은 확장성, 성능, 완전관리형, 대부분의 API와 호환(코드 수정이 거의 필요없다), 높은 보안성을 자랑한다.