캐싱 개념정리

2023. 12. 19. 08:23Network

| 캐싱이란

어떠한 데이터를 한 번 받아온 이후 가져온 곳보다 더 가까운 곳에 임시로 저장하여,

필요시 더 빠르게 불러와서 사용하는 프로세스를 의미한다.

개발자는 재사용을 충분히 많이 있는 데이터만 캐싱해서, 성능과 비용을 모두 아끼는 것이 중요하다.

캐싱을 사용하지 않는다면 서버에 매번 요청을 보내기에 과부하를 일으킬 수 있으며

클라이언트에서는 서버에서의 응답을 매번 기다려야하기에 성능이 저하된다.

 

이를 해결 할 수 있는 방법은

처음에 불러온 데이터의 복사본을 두고 stale(최신이 아닌 데이터를 가지고 있는)이 되었다고 판단하여 서버에 다시 요청을 보내는것으로

요청을 줄이고 성능을 향상 시킬 수 있다.

 

| 브라우저 캐시

이미 방문한 웹 페이지에서는 페이지의 리소스를 캐싱해서 다음번에도 동일한 페이지에 방문했을 때 다시 다운로드 하지않고 저장된 항목을

보여줄 수 있다. 브라우저의 캐싱을 처리하는 속성에는 ETag와 Cache-Control이 있다.

 

- ETag

웹 서버가 내용을 확인하고 변하지 않았다면 full 요청을 보내지 않는다.

그래서 캐쉬가 더 효율적이게 되며 대역폭 또한 아낄 수 있다.

만약 내용이 변경 되었다면 “mid-air collisions”이라는 리소스 간의 동시 다발적 수정 덮어쓰기 현상을 막는데 유용하게 사용이 된다.

또한 POST 요청을 보낼 때 If-Match 헤더에 ETag 값을 넣어서 충돌을 피할 수 있다.

해시가 일치하지 않다면 문서가 변경 되었다고 판단하여 412(Precondition Failed) 에러를 던져준다.

 

- Cache-Control

HTTP 헤더의 Cache-Control 요소를 이용해서 캐싱을 제어할 있다.

 

| no-cache - 서버로 현재 데이터가 최신인지 확인을 하고 최신이라면 다시 받아오고 그렇지 않으면 캐싱  데이터를 사용하도록 하는 옵션이다. 

| no-store - 캐싱을 하지 않겠다는 의미이다.

| public - 클라이언트에서 서버로 요청을 보내는 사이 중간 매개체가 있을 중간 매개체에도 캐싱을 허용할 이면 public 옵션을 주면 된다.

| private - 외부 캐시 서버에서는 캐싱을 사용하도록 하지 않고 브라우저에서만 사용하도록 하는것이다.

| max-age - 캐싱을 사용할 이라면 데이터를 얼마나 유지할 인지 세팅을 해주는것이다. 설정을 하지 않으면 null 설정된다.

 

| 프록시 캐시

프록시 캐시는 한명 이상의 사용자에 의해 재사용 되는 응답을 저장한다.

프록시 캐시에도 Cache-Control이 존재한다. 하지만 한가지를 더 신경써야 할 부분이 있다.

클라이언트에서는 캐시를 적용하지 않고 매번 요청을 보내 따끈한 데이터를 받아오고 싶지만 웹 브라우저가 임의로 캐싱을 하여 업데이트가 되지 않는 문제가 발생 할 수 있다.

그래서 캐시를 무효화 시켜주어야 한다.

위에서 살펴본 no-cache, no-store가 있고 must-revalidate 속성이 있다.

must-revalidate = 캐시가 만료된 이후 최초 조회 서버에 검증을 반드시 거쳐야한다. 접근이 안된다면 504 Gateway Timeout 발생한다. max-age 시간을 부여할 있으며 stale 데이터를 쓰고싶지 않을 속성을 사용하면 된다.

 

| CDN

CDN은 Content Delivery Network 의 약자로 분산 노드로 구성된 네트워크이다.

성능 향상을 위해 클라이언트의 요청이 같은 서버로 가는것을 방지한다.

각 지역의 엔드 유저에 따라 오리진 서버가 아닌 다른 서버로 가도록 분산시키는 역할을 한다.

이 과정에서 캐싱이 사용된다.

최초 요청시에는 무조건 오리진 서버에 갔다와야해서 처음의 속도는 느릴 있지만 다음부터는 CDN 통해 빠르게 콘텐츠를 내려받을 있다.