본문 바로가기
IT 개인 공부/Web

캐시(Cache) : 검증 헤더와 조건부 요청

by Libi 2021. 8. 28.
반응형

클라이언트가 특정 데이터를 자주 요청한다고 하자. 해당 데이터를 매번 요청마다 서버를 통해 DB에게 접근하여 반환하는 방법은 상당히 비효율적이다.

왜냐하면 이전에 사용했던 데이터와 새롭게 요청하는 데이터는 차이가 없음에도 불구하고 비싼 네트워크 통신을 통해 해당 데이터를 서버로부터 다운로드하여야 하기 때문이다.

 

이를 해결하기 위해 우리는 캐시(Cache)라는 것을 사용한다.

캐시(Cache)란 한번 조회된 데이터를 미리 특정 공간에 저장해놓고, 똑같은 요청이 발생하게 되면 서버에게 다시 요청하지 말고 저장해놓은 데이터를 제공해서 빠르게 서비스를 제공해주는 것을 의미한다.

 

즉, 캐시를 통해 자주 사용하는 데이터를 저장하여 서버의 부담을 줄일 수 있게 된다.

하지만 캐시는 보통 디스크나 메모리에 저장하기 때문에 물리적 저장 공간의 한계가 존재한다. 따라서 캐시 데이터를 계속해서 저장한다면 결국 OOM(Out Of Memory)가 발생할 것이다.

 

이를 위해 Cache-Control라는 캐시 제어 헤더를 제공하고 max-age라는 옵션을 통해 캐시의 유효 시간을 제한할 수 있다.

캐시 데이터는 max-age 옵션으로 인해 유효 시간이 지나면 자동으로 제거되면서 OOM를 해결할 수 있다.

 

하지만 캐시를 관리하는 공간이 아직 여유가 있으며, 캐시 데이터가 자주 사용됨에도 불구하고 유효시간이 지나서 데이터가 제거된다면 비효율적이지 않을까?

제거되지 않았다면 해당 데이터의 요청이 왔을 때 캐시 데이터를 반환해주면 되지만, 제거되었을 경우 해당 데이터의 요청이 오게 되면 결국 또다시 서버를 통해 데이터를 조회하고 캐시를 갱신해야 하는 번거로움이 발생하게 된다.

이는 검증 헤더조건부 요청 헤더를 사용해서 해결할 수 있다.

 

캐시 유효시간이 끝나서 서버에 다시 데이터를 요청하는 경우 두 가지 상황이 존재할 것이다.

  • 서버에서 기존 데이터를 변경함
  • 서버에서 기존 데이터를 변경하지 않음

 

그런데 기존 데이터가 변경되지 않거나 변경되었더라도 기존의 데이터와 거의 비슷해서 사용하는데 지장이 없는 수준이라면 서버로부터 갱신할 필요가 있을까?

이러한 상황에서는 캐시가 만료되었다 하여도 서버로부터 갱신할 필요 없이 기존의 캐시 데이터를 재사용할 수 있다면 효율적으로 처리할 수 있을 것이다.

 

이를 위해선 클라이언트의 데이터와 서버의 데이터가 동일해서 갱신할 필요가 없다는 사실을 확인할 수 있는 방법이 필요하다.

이는 Last-Modified라는 검증 헤더를 통해 해결할 수 있다.

Last-Modified는 데이터가 마지막에 수정된 시간을 의미하며 캐시 유효시간이 끝나더라도 클라이언트의 데이터와 서버의 데이터의 Last-Modified가 동일하다면 서버로부터 요청하지 말고 기존의 캐시 데이터 유효 시간을 갱신해준다.

물론 동일한지 확인하기 위해 서버에게 요청 및 응답 과정이 수행되지만 기존의 방식에서 가벼운 검증 헤더 하나만 추가하며, 이로 인해 불필요한 갱신을 제거할 수 있기 때문에 매우 실용적인 방법이다.

 

하지만 이 방법은 데이터의 마지막 수정 시간이 조금이라도 다르다면 무조건 서버에게 요청해야 하는 단점이 존재한다.

만약 A.jpg라는 데이터가 B.jpg라는 데이터로 갱신되면서 수정시간이 변경되었지만, 데이터 결과가 동일하거나 데이터가 변경되었더라도 거의 차이가 없어서 사용하는데 지장이 없는 상황이라고 하자.

 

하지만 단순히 Last-Modified를 통해서 검증한다면 위의 두 가지 시나리오 모두 서버에게 B.jpg를 요청해야 한다.

이는 ETag(Entity Tag)라는 검증 헤더를 사용해서 해결한다. ETag는 캐시용 데이터의 임의의 고유한 버전 이름으로 데이터의 버전을 표현하는 방법이라고 생각하면 된다.

데이터가 변경되어도 ETag가 동일하다면 유지하고, 다르다면 서버로부터 받는 방식이다.

 

비효율적인 상황을 해결하는 방법으로 Last-Modified와 ETag 검증 헤더를 배웠다. 하지만 두 검증 헤더를 사용하는 조건이 다르기 때문에 이를 분류해서 사용할 수 있어야 한다.

이는 조건부 요청 헤더를 추가하여 상황에 따라 분류해서 사용할 수 있다.

  • ETag : If-Match, If-None-Match 조건부 요청 헤더 추가
  • Last-Modified : If-Modified-Since, If-Unmodified-Since 조건부 요청 헤더 추가

 

 

 

[ Reference ]

· https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

반응형

댓글