[AWS] 캐싱

캐싱

• 먼 거리에 있는 서비스를 가까운 거리에 있는 장소에 옮겨서 속도를 향상시키는 기능
• 자주 엑세스하지만 데이터 변화가 적은 서비스를 캐싱하는 것이 좋다
• 서버와 DB는 부화가 적어지고 사용자는 응답 지연 시간이 감소하여 좋다

 

1. 엣지 캐싱, CloudFront

CDN(컨텐츠 전송 네트워크)을 제공하는 CloudFront

• 가장 가까운 엣지 서비스에 자주 접근하는 서비스 캐싱한다
• 아키텍처에 추가적인 보안 계층 제공

CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 짧은 엣지 로케이션으로 라우팅된다

콘텐츠가 이미 엣지에 있는 경우, CloudFront가 콘텐츠를 즉시 제공하지만, 없는 경우 원본이 있는 리전으로 이동한다

리전에서 콘텐츠를 엣지에 캐싱하고 엣지에서 사용자에게 콘텐츠를 전송함

즉, 처음 한번은 CloudFrot를 사용해도 속도가 똑같지만 그 다음부터는 캐싱된 콘텐츠를 사용하기 때문에 속도가 매우 빨라진다

 

콘텐츠가 캐싱되지 않은 경우 -> 1,2,3,4

콘텐츠가 캐싱된 경우 -> 1,4

 

S3의 이미지를 캐싱할 경우

첫 번째 GET요청은 CloudFront가 있을때와 없을때 속도가 비슷하다

하지만 이후부터는 각 GET요청의 속도가 현저히 빨리진다.

S3 버킷에서 전송되는 파일이 첫 번째 GET 요청 이후 캐싱되어 이미 테스트를 실시하는 곳과 가장 가까운 엣지 로케이션에 저장되기 때문이다.

 

이와같이 S3와 CloudFront를 같이 사용하면 이점이 많다

1. 콘텐츠를 더욱 빠르게 사용자에게 전송하여 애플리케이션 성능을 높일 수 있다
2. CloudFront의 보안 기능으로 애플리케이션의 보안 강화할 수 있다
3. CloudFront에서 인터넷으로 데이터를 전송하는 요금이 간혹 S3에서 인터넷으로 전송하는 요금보다 저렴하여 비용 절감이 가능하다

 

콘텐츠 만료 방법, Time To Live(TTL)

• 엣지에 콘텐츠가 영원히 캐싱되어 있으면 안되므로 TTL값을 사용한다(업데이트가 필요하기 때문)
• 고객이 설정
• CloudFront에서 오리진으로의 GET 요청에 If-Modified-Since header를 사용
• TTL값이 만료가 안됐음에도 즉각적으로 콘텐츠를 바꿔야 할때는 객체의 이름을 바꾼다(h1.jpg->h2.jpg)

 

 

2. 웹 티어 캐싱

세션관리, ELB

• 사용자 세션을 관리하는 특정 서버로 요청을 라우팅 할 수 있음
• 클라이언트 측 쿠키
• 비용 효율성
• 세션 검색 속도 증가

상태정보(쿠키)를 인스턴스에 저장하는 게 아니라 DynamoDB(외부DB)에 저장하면 더 빠른 세션 검색 가능!

 

 

3. 데이터베이스 캐싱

반복되는 쿼리가 계속 들어와서 부화가 걸리고 부하가 커서 디비가 넘칠때

디비 증량하면 비용이 비싸지니 비용을 줄이고 싶으면 디비 캐싱을 한다

 

DynamoDB Accelerator

- 탁월한 성능, 완전관리형, DynamoDB와 API호환

- DynamoDB도 성능이 좋지만 향상 시키고 싶다면 Accelerator 사용

 

ElastiCache

- 클라우드에 있는 인 메모리 데이터 스토어를 웹 애플리케이션에 제공하기 때문에 디스크 기반 데이터베이스보다 빠름

- 여러개의 노드로 구성되어 있고 각 노드에는 고유한 DNS 및 포트가 있음

- 완전관리형

- Memcached와 Redis 중 하나를 선택

• Memcached
  • 다중스레드
  • 연속 쓰기

• Redis
  • 싱글 스레드
  • 레이지 로딩

 

TTL추가

레이지 로딩은 기한 경과 데이터에 대해 허용되는 반면, 연속 쓰기는 데이터를 항상 최신 상태로 유지하며 불필요한 데이터로 캐시를 채울 수 있다

TTL값을 각각의 쓰기에 추가하면 각 전략을 활용할 수 있으며 캐시를 데이터로 채우는 것을 방지 할 수 있다

애플리케이션이 TTL이 끝날때 읽으려고 시도하면 캐시에서 데이터를 찾을 수 없어 데이터베이스에 쿼리되며 캐시는 업데이트 된다

이렇게 하면 데이터를 기한 내에 업데이트 할 수 있다