[7장] 7.1~7.9

 

책을 읽고 공부한 내용을 기록한 글입니다.

웹 캐시는 문서 사본을 자동으로 보관하는 HTTP장치다. 요청 시 캐시된 사본이 있으면 원 서버로 가지않고 사본이 제공된다.

캐시쓰는 이유

# 불필요한 데이터 전송

한 리소스에 자주 접근한다면, 서버는 매번 같은 응답을 할텐데 이런 불필요한 원 서버 리소스 접근은 네트워크 대역폭을 잡아먹고, 전송을 느리게 만들며 웹서버에 부하를 준다. 캐시를 이용하면 첫 응답이 캐시에 보관돼서 다음에 같은 요청이 들어오면 캐시된 사본을 뿌려줘서 이런 대역폭 낭비를 줄일 수 있다.

# 대역폭 병목

대다수의 경우 로컬 네트워크 클라이언트의 대역폭이 원격 서버보다 넓고, 클라이언트가 원격 서버에 접근하는 속도는 그 경로에서의 가장 느린 네트워크 속도와 같다. 이 때 빠른 로컬 LAN에 있는 캐시로 부터 사본을 가져오면, 원격 서버에서 가져오는 속도보다 더 빨라질 것을 기대할 수 있다. 가져올 문서 크기가 작은 경우 대역폭이 비교적 체감되지않지만 문서 크기가 커질 수록 대역폭의 영향을 많이 받는다.

# 갑작스런 요청 쇄도 - Flash Crowds

캐시를 쓰는 가장 주요한 이유라고 할 수 있는 트래픽 급증이다. 갑작스런 트래픽 증가는 웹 서버에 과부하를 줘서 서버의 처리를 느리게 만든다.

# 거리로 인한 지연

물리적인 거리가 문제가 될 때도 있다. 아무리 빨라도 물리적인 거리가 멀어버리면 시간이 걸릴 수 밖에 없다. 이 경우 어차피 계속 리소스에 접근할건데 매번 몇 천 키로미터 밖의 서버에 접근해야될 이유가 없기때문에 각 나라의 가까운 곳에 캐시 서버를 둬서 이런 지연을 없앨 수 있다.

적중과 부적중

캐시를 사용해서 사본을 담고, 클라이언트가 리소스 요청을 했을 때 캐시에 사본이 존재한다면, 이걸 캐시 적중(cache hit)이라고 부른다. 적중하지 않으면(cache miss) 그냥 원 서버로 요청을 전달한다. 근데 캐시에 담긴 사본이 최신화가 되어있는 지는 다른 문제다. 리소스에 접근가능해도, 최신화되지 않았다면 잘못된 리소스를 반환하기 때문이다. 따라서 사본을 재검사(신선도 검사)하는 과정이 필요하다. 캐시는 언제든 사본을 재검사할 수 있는데 매번 재검사할 필요는 없기 때문에(재검사에도 네트워크 대역폭을 소모하기 때문에) 클라이언트가 사본 요청하고, 캐시된 사본이 충분히 오래된 경우에만 재검사를 수행한다. 

캐시가 원 서버에 재검사 요청을 보내면 서버는 콘텐츠가 신선하면 304 Not Modified를 보내고(재검사 적중), 낡았으면 새걸로 사본을 다시 제공한다(이때는 200 OK). 신선하면(304) 신선하다고 표시해서 신선도 기간을 늘린다. 이 방법은 원서버를 가볍게 써야되므로 순수 캐시 적중보다 당연히 느리고 캐시 부적중보다는 빠르다.(캐시에 있는 데이터가 신선할 때) 

재검사 적중 시 사용되는 헤더가 If-Modified-Since 헤더다. 객체가 삭제되었다면 404을 원서버가 내뿜고 캐시에서 사본을 삭제한다. 

적중률

0%(모든 요청이 캐시 miss) ~ 100%(모든 요청이 캐시 hit)가 기본 개념으로, 문서 사본이 있는지 검사하던 문서 적중률이 기본인데 바이트 단위의 적중률을 사용하기도 한다. 바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트 비율을 표현한다. 바이트 적중률이 높을 수록 트래픽의 절감 정도를 알 수 있다. 100이면 모든 바이트가 캐시에서 왔기 때문에 원격서버에서 받아온 리소스가 없다고 해석할 수 있다.

 

문제는 클라이언트에게 돌아가는 응답이 200 OK 라서 적중 부적중을 알 수 없다. 처리 방법에 따라 다른데 헤더에 응답 생성일 같은 정보를 붙여서 캐시된 응답임을 감지할 수 있다.

캐시 토폴로지 

캐시는 한 명만 사용하는 개인 전용 캐시와 공유된 캐시(공용 캐시)로 나눌 수 있고, 공용 캐시는 사용자 집단이 자주 찾는 페이지를 담는다.

개인 전용 캐시는 많은 리소스를 다루지 않기때문에 비교적 저렴하고 가볍게 구성할 수 있다. 웹 브라우저에도 개인 전용 캐시가 내장되어있다. 브라우저는 캐시를 사용자의 디스크에 저장(임시파일)해두고 꺼내 쓰곤 한다.

 

# 공용 프락시 캐시 = 공용 캐시

캐시 프락시 서버에서 공유된 프락시 서버가 공용 캐시다. 프락시 캐시는 사용자인척 서버에 접근한다. 이때 사용자 집단이 사용하게 되면서 다수의 사용자가 여러 리소스에 접근하고, 그러면 캐싱해둘수있는 리소스가 더 많아져서 불필요한 트래픽을 줄일 수 도 있다.

캐시 계층?

graph LR
    A[로컬 캐시] -- 부적중 --> B(공용 캐시)

CPU의 L2 L3 캐시랑 비슷하게, 작은 캐시(로컬)에서 부적중이 일어나면 더 큰 캐시(공용)에서 찾아서 반환하는 방식이다. 이 계층이 깊어지면 당연히 연쇄가 길어짐에 따라 성능저하도 발생하게 될 것이다. 그래서 최대 세개 정도의 프락시만 사용하도록 연쇄를 제한한다고 한다.

캐시 계층 대신 캐시망, 콘텐츠 라우팅, peering을 이용하는 동적 네트워크 아키텍쳐도 존재한다.

캐시끼리 대화하는 방식인데,

• URL에 근거해서 부모/원 서버 중 효율적인 것을 택한다.
• URL에 근거해서 특정 부모 캐시를 동적으로 선택한다.
• 부모 캐시로 가기전에 로컬에서 사본을 찾는다.
• 다른 캐시를 통한 트래픽유출은 금지한채로 부분적인 열람을 허용한다.

peering은 캐시를 연결해서 한 캐시처럼 쓰는건데 HTTP는 이걸 지원하지 않아서 ICP나 HTCP를 통해 유사하게 사용한다.

#캐시 처리 7단계

이 과정에서 주체는 캐시다.

1. 캐시가 네트워크 요청을 받는다
2. 메시지를 파싱해서 해석한다.
3. 캐싱된 사본이 있다면?
4. 신선한지 확인하고
5. 응답메시지를 만들어
6. 발송하고
7. 트랜잭션에 대한 로그를 남긴다.

\

3번,4번, 5번이 핵심이다.

사본이 없으면 할 행동이 실패를 반환하거나, 부모나 원서버에 들러 반환하거나 두 종류다. 또 응답메시지를 만들 때는 캐시서버가 원서버인척 하고 싶기 때문에 캐시된 서버 응답(원 서버 꺼)을 토대로 응답을 만든다.

이제 사본이 있지만, 신선하지 않을 때는 그 전에 캐시된 사본이 원본과 일치하도록 유지할 수 있는 작업이 필요한데, 문서 만료 - 서버 재검사를 통해 이를 수행한다. 이 작업이 캐시 제어라고 부르는 작업이다. 우선 순위 순서대로 작성했다. 

Cache-Control: no-store/no-cache/must-revalidate/max-age 와 Expires 헤더를 통해 유효기간을 검사한다.

유효기간이 만료된다면 -> 서버랑 비교해 달라진 점이 있는 지 검사하여 새로 사본을 갱신하고, 유효기간도 갱신해야된다. 이게 서버 재검사다.

효율적인 재검사를 위해 조건부 헤더를 사용하는데 그 중 가장 유용한 게 위에 적중 이야기할 때 나왔던 If-Modified-Since, 그리고 If-None-Match다.

(+) if-unmodified-since, if-range, if-match)

이 조건부 헤더가 false여야 효율적인 갱신이 이루어진다.(304코드와 함께 본문보내지 않고 유효기간 갱신)

IMS는 Last modified랑 같이 쓰이면서 변경일자랑 최근 일자를 비교한다. 문제는 이렇게 조건검사를 할 때, 내

용이 바뀌지않고(아니면 매우 사소해서 본문에 영향을 끼치지않는) 갱신되는 파일에 대한 검증이 되지않는다. 이때 사용되는게 버전을 기록할 엔터티 태그와 If-None-Match다. 엔터티 태그의 W/ 같은 추가정보를 통해 약한 검사, 강한 검사로 또 나눌 수 있는데 사소한 게 달라졌더라도 엔터티 태그를 갱신하는게 강한 검사다.

엔터티 태그 vs Last modified

일단 둘 다 알 수 있다면, 둘 다 검사해야된다... 이 말은 두가지 헤더를 모두 가질 경우, 두 조건 모두 만족할 때만 304반환을 해야된다는 뜻이 된다. Last modified만 있다면 IMS만 하면 되는데, 따라서 중요도는 엔터티 태그가 더 높은 것으로 보인다.

#캐시 제어 

위에서 간단하게 나왔는데, 순서대로 살펴보겠다

no-store / no-cache

no-store는 캐시가 응답 사본 만드는 걸 금지시킨다.

no-cache는 서버와 재검사를 하지않고는 클라이언트에게 캐시를 제공할 수 없게 한다.

즉 이 두개는 검증되지않은 캐시된 객체로 응답하는 것을 금지하는 헤더라고 할 수 있다.

must-revalidate

성능 개선을 위해 만료된 객체를 제공할 수도 있다. 데이터의 변화가 없는데 만료가 다 된 경우, 유효기간 갱신을 안한다면 이 조건을 만들 수 있는데, 이 헤더를 사용하면 만료된 객체에 대한 서버 재검사를 강제할 수 있다.

max-age, expires

max-age, expires는 위에서 문서만료 때 나왔다.

 

헤더를 사용하지 않고, 캐시가 경험한 알고리즘에 따라 최대나이를 계산하는데 이걸 휴리스틱 만료라고 부른다.

https://ko.wikipedia.org/wiki/%ED%9C%B4%EB%A6%AC%EC%8A%A4%ED%8B%B1_%EC%9D%B4%EB%A1%A0

휴리스틱 이론 - 위키백과, 우리 모두의 백과사전

경험 했을 수도 있는데, 브라우저가 신선하지 않은 콘텐츠를 강제로 새로고침 하는 경우가 있다. 이런 판단 근거는 브라우저, 클라이언트 마다 달라진다.

캐시 제어는 생각할 거리가 많다. 유효기간을 길게 잡고, IMS로 약한 제한조건으로 검사한다면 잘못된 데이터에 접근할 가능성이 높아진다. 그렇다고 유효기간을 아예 안쓰면 매번 검사해서 사본을 받아와야하니까 성능저하가 발생한다

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^