캐싱

캐싱이란

• 웹사이트 성능을 최적화할 수 있는 방법 중 하나이다.
• 어떤 데이터를 한 번 받아온 후 그 데이터를 불러온 저장소보다 가까운 곳에 임시로 저장하여 필요시 빠르게 불러와 사용하는 프로세스이다.

단점

• 단위 메모리당 비용이 비싼 편이다.
• 따라서 엔지니어 입장에서는 재사용을 충분히 많이 할 수 있는 데이터만 선별적으로 잘 캐싱해서 성능과 비용을 모두 아끼는 것이 중요하다.

웹 캐시

• 웹 캐시는 주로 브라우저 측과 서버 측에서 발생한다. 브라우저 캐시는 사용자의 로컬 컴퓨터에 저장되며, 브라우저가 이전에 방문한 페이지의 자원(이미지, 스타일 시트, 스크립트 등)을 저장한다. 이렇게 함으로써 동일한 웹 페이지를 방문할 때마다 모든 자원을 다시 다운로드할 필요가 없어진다. 서버 측 캐시는 웹 서버나 프록시 서버에 위치하여, 동일한 페이지에 대한 요청을 받을 때 이전에 캐시된 데이터를 제공함으로써 서버 부하를 줄이고 응답 시간을 단축한다.

브라우저 캐시

• 이전에 한 번 불렀던 데이터이며 거의 바뀔 일이 없는 데이터라면 캐싱을 적용해 볼 수 있다.
  ex) 블로그 로고, 이미지, 제목, 사이드바 목차
  여기에 적용하는 캐시를 브라우저 캐시라고 한다.
  브라우저 캐시는 브라우저나 HTTP 요청을 하는 클라이언트 애플리케이션에 의해 내부 디스크에 이루어지는 캐시이다.
  단일 사용자를 대상으로 하는 사설 캐시이며 해당 사용자의 정보만 저장한다.

브라우저에서 캐싱을 처리하는 속성

• ETag: HTTP 헤더의 ETag는 특정 버전의 리소스를 식별한다.
  웹 서버가 내용을 확인하고 변하지 않았으면 이 ETag가 동일한 값을 그대로 가지고 있게 되어 웹 서버로 전체 요청을 보내지 않기 때문에 캐시를 효율적으로 관리 가능
  만약 해당 요청의 리소스가 변경되었다면 새로운 ETag가 생성됨

• Cache-Control: HTTP 헤더의 Cache-Control 요소를 통해 캐싱을 제어할 수 있다.
  Cache-Control의 no-cache라는 속성을 통해 캐시를 사용하기 이전에 서버에 해당 캐시를 사용해도 되는지에 관해 검증 요청을 보낼 수 있다.
  no-store 속성을 사용하면 반환된 응답에 대해 브라우저가 캐싱을 하지 않는다.(개인정보 등 priviate한 데이터가 있는 경우 이 속성을 사용할 수 있음)

프록시 캐시

• 공유 캐시로 한 명 이상의 사용자에 의해 재사용되는 응답을 저장한다.
  캐시를 적용하지 않았는데 적용이 된다면 캐시를 무효화할 수 있다.(must-revalidate)

• 예를 들어 우리가 구글에 들어간다고 가정해 보면 매번 구글에 접속할 때마다 미국에 있는 구글 서버에서 웹사이트 데이터를 불러온다면 상당한 시간이 걸릴 것이다. 이 데이터를 우리에게 더 가까이 둘 수 있다면 여러 이점이 있지 않을까? 이때 프록시 캐시를 사용하면 구글 웹사이트에 관한 리소스를 한국 서버에 둘 수 있을 것이다.

네트워크 캐시

• CDN: Content Delivery Networ의 약자로 분산 노드로 구성된 네트워크다.
  성능 향상을 위해 클라이언트의 요청이 같은 서버로 가는 것을 막는다.
  CDN은 각 지역의 엔드 유저에 따라 요청을 오리진 서버가 아닌 다른 서버로 가도록 분산시키는 역할을 한는데 이 과정에서 캐싱이 사용된다.

• 만약 엔드 유저의 요청이 CDN 노드에서 가져올 수 있다면 그 콘텐츠를 전달하지만, 그렇지 못한 경우라면 오리진 서버로 요청을 전송한다. 최초 한 번은 오리진 서버에 반드시 갔다 와야 하므로 느릴 수 있지만, 그 다음부터는 CDN을 통해 빠르게 해당 콘텐츠를 내려받을 수 있다는 장점이 있다.