HTTP : 캐싱 , Web Cache

캐싱 ( Caching )
。데이터 복제본 또는 연산결과를 임시로 저장하여 요청의 응답을 효율적으로 하는 기술
▶ 웹서버에 일일이 요청할 필요 없이 자주 사용되는 복잡한 연산의 결과 또는 자주 찾는 데이터를 효율적으로 전달하는 것이 목적

。AWS의 CDN / ElastiCache에서 활용

• 장점
  。요청에 따라 캐시에 이전에 요청되어 저장된 내용이면 서버에 전달할 필요없이 클라이언트에게 빠르게 데이터를 전달 가능
  
  。복잡한 연산에 따른 자원 / 부하를 감소 가능
  
  
• 단점
  。일관성의 유지가 어려움
  
  。아키텍처의 복잡도가 증가

캐싱 정책
。캐시에 데이터를 저장하는 방식

• Lazy Loading :
  。처음에 데이터를 저장하지않고, 요청이 수행된 경우 서버에 요청을 수행 후 캐시에 응답된 데이터를 저장하는 정책
  ▶ 자원 낭비 감소
  ▶ 이후 요청 시 저장된 데이터를 가져온다.
  
  ex ) 웹사이트에서 모든 데이터를 한 번에 로딩하지 않고, 사용자가 스크롤하거나 버튼을 클릭하는 등 특정 행동을 했을 때만 필요한 데이터를 불러오는 방식
  
  。 최초 웹서버에 요청 및 응답 후 캐시에 응답 데이터 로딩이 필요
  
  
• EAGER Loading
  。사전에 캐시에 모든 데이터를 저장 후 요청을 기다리는 정책
  ▶ 캐시에 데이터가 항상 준비되있는 장점이 존재하나, 모든 데이터를 캐시에 저장하므로 불필요한 캐시 용량 낭비 및 매우 큰 자원을 소모
  
  
• Write Through
  。웹서버의 DB 데이터가 변경되거나 저장되는 시점에서 동시에 캐시에 동시 반영 및 저장
  ▶ 항상 데이터 일관성이 보장되지만 쓰기 과정이 DB뿐만 아닌 캐시에도모두 적용되므로 복잡해지고 느려지는 가능성이 존재
  
  
• Write Back
  。데이터를 캐시에 먼저 작성 후 웹서버 DB에 업데이트
  ▶ Write Through과 달리 쓰기가 빠르고 간단하지만 DB에 도달하기 전 캐시서버가 다운되어 유실될 위험 이 존재

캐시 만료 방식 ( Invalidation / Eviction )
。캐시에 저장된 임시 데이터를 삭제하는 방식

• TTL ( Time To Live ) :
  。모든 임시 데이터에 대해 일정 시간이 지나면 만료
  ▶ 모든 데이터에 대해 항상 갱신을 수행해야하는 단점이 존재.
  
  
• LRU ( Least Recently Used )
  。가장 사용시점이 가장 늦는 임시 데이터부터 만료
  ▶ 계속 사용되는 데이터들을 계속 지속적으로 보관
  
  
• LFU ( Least Frequently Used )
  。가장 사용빈도가 낮은 임시 데이터부터 만료
  ▶ 자주 사용되는 데이터들을 계속 지속적으로 보관
  
  
• FIFO ( First In First Out )
  。가장 먼저 들어온 데이터부터 만료

웹 캐시 ( Web Cache ) = 프록시 서버( Proxy Server )
。HTTP Server의 역할을 대신하는 중계서버
▶ 브라우저와 HTTP Server 중간에서 통신을 대리로 수행
▶ 기억장치의 Cache Memory와 유사한 Logic

。Origin Server에 접근할 필요없이 Local Server에 객체를 보관하여 접근하는 원리
▶ 자체 저장소를 가지고있어 최근 호출한 객체의 사본을 저장 및 보존
▶ 브라우저는 객체 요청 시 반드시 웹 캐시로 HTTP Request를 송신하도록 설정

。일반적으로 ISP가 웹캐시를 구입 및 설치하여 모든 캠퍼스의 브라우저가 해당 웹 캐시로 요청을 보내도록 설정

。웹 캐시는 자체저장소에 저장된 객체 사본이 Origin Server 내 객체보다 Outdated 될 수 있는 문제점을 Conditional GET을 통해 검증하여 해결

• Cache Hit
  。클라이언트 요청에 따라 서버에 전달할 필요없이 캐시에 저장된 데이터로 응답할 수 있는 상황
  
  
• Cache Miss
  。요청에 따른 데이터를 캐시에서 찾을수 없는 상황
  ▶ 해당 경우 서버에 데이터를 요청해서 응답.
  
  
• Cache Hit Rate :
  。브라우저에서 요청한 객체가 웹 캐시에 존재하여 Web Cache가 만족시킨 HTTP Request의 비율
  
  。일반적으로 Cache Hit Rate = 0.2 ~ 0.7
  
  ex ) Cache Hit Rate = 0.4 인 경우
  브라우저가 웹 캐시로 요청하는 HTTP Request의 40%는 웹 캐시에 의해 응답되고 나머지 60%는 웹 캐시가 Origin Server로 HTTP Request하여 획득

웹캐시 사용목적

• Client의 HTTP Request에 대한 Response Time 감소
  。Origin Server까지 요청할 필요없이 중간의 중계서버인 웹캐시를 통해 객체를 요청하므로
  
  
• 다수의 End System으로 구성된 특정 기관으로부터의 인터넷으로 접속하는 Access Link의 Traffic을 상당수 감소
  。기관 네트워크에서 인터넷으로 진입하는 비율이 감소하면서 비용 감소
  
  。인터넷 전체의 트래픽을 감소시키면서 네트워크 어플리케이션의 성능 증진
  
  
• P2P 또는 Content Provider 입장에서 유리
  。Network상에 분포된 Web Cache에 사전에 Content에 대한 사본을 저장하여 Share가 유리해짐
  ▶ 브라우저가 Content를 요청 시 Content Provider의 Server가 아닌 Web Cache로부터 Content를 응답받도록 설정

웹캐시 원리
。웹 캐시는 HTTP Server이면서 동시에 HTTP Client 역할을 수행
▶ Client 프로세스와 Server 프로세스를 동시 실행

。브라우저가 객체를 요청하는 HTTP Request Message를 웹캐시에 전송하는 경우
▶ 웹캐시가 해당 객체를 포함하는 경우 즉시 응답하여 반환
▶ 웹캐시가 해당 객체를 포함하지 않는 경우 웹캐시에서 HTTP Server로 해당 객체를 요청 후 브라우저로 반환

• 브라우저는 웹캐시와 TCP Connection을 구축 후 객체에 대한 HTTP Request 송신
  
  
• 웹캐시는 객체의 사본이 자체저장소에 저장되어있는지 확인
  。객체의 사본이 자체저장소에 저장되어있는 경우 브라우저로 HTTP Response Message에 객체를 캡슐화한 후 응답
  
  
• 웹캐시가 객체의 사본이 없는 경우 Origin Server( = HTTP Server )에 TCP Connection을 설정 후 객체에 대한 HTTP Request 송신
  。HTTP Server는 HTTP Response Message에 객체를 캡슐화한 후 웹캐시로 응답
  
  
• Origin Server로부터 HTTP Response 수신 후 객체를 자체저장소에 사본으로서 저장 및 브라우저에 HTTP Response Message에 객체를 캡슐화한 후 응답
  。객체 사본 저장 시 Last-Modified Header Line도 함께 저장
  ▶ 향후 Conditional GET을 통한 객체가 Outdated 되었는지 확인

웹 캐싱 예시

• 특정 기관 네트워크의 브라우저에서 인터넷의 Origin Server간 HTTP Transaction 수행 시
  
  。기관 네트워크와 인터넷은 각각 Access Link를 통해 기관의 라우터와 ISP의 POP를 통해 연결됨

  • 가정
    。Access Link : 초당 전송률 15.4 Mbps의 통신링크
    。LAN : 초당 전송률 100 Mbps의 통신링크
    
    。평균 데이터객체 크기 : 1 Mbits
    
    。Origin Server와 ISP의 POP 간 RTT : 2 sec
    ▶ Internet Delay
    
    。기관 브라우저에서 Origin Server에 대한 초당 평균 요청비율 : 15 / sec번
    
    
  • 소요시간( delay ) 계산 : Traffic Intensity
    。 초당 Traffic의 총량 : 초당 요청수 * 객체 크기 = 15 Mbits/sec = 15 Mbps
    
    。 LAN Traffic Intensity = $\displaystyle \frac{15 Mbps}{100 Mbps}=0.15$
    ▶ LAN Utilization은 약 15%에 육박
    ▶ Traffic Intensity = 0.15는 최대 msec Delay를 야기하므로 해당 지연을 무시가능.
    
    。Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{15.4 Mbps}=0.97$
    ▶ Access Link Utilization은 약 97%에 육박
    ▶ Traffic Intensity가 0.78을 초과하는지점에서 큐잉지연이 급격하게 증가하여 few minute Delay가 발생
    
    Total Delay = Internet delay + Access delay + LAN delay
    ▶ 2 sec + minute + msec = minute
    
    。 최종적으로 전송률이 낮은 Access Link 때문에 대략 몇분 수준의 Delay가 발생.

• 
  
  
• 해결책 1 : fatter Access Link
  
  。Access Link를 Bandwidth가 더 큰 fatter Access Link로 교체하여 Bandwidth가 154 Mbps이 될 경우
  
  。 Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{154 Mbps}=0.09$
  ▶ Access Link Utilization은 약 9.9%에 육박하여 최대 msec delay가 발생.
  ▶ 2 sec + msec + msec = 2 sec
  
  。그러나 해당 방식은 fatter Access Link로 인한 비용증가 문제와 Web Cache 방식보다 Delay가 다소 큰 문제가 존재.
• 
  
  
• 해결책2.: 기관 네트워크에 로컬 웹 캐시를 추가하여 인터넷의 Origin Server간 HTTP Transaction 수행 시
  
  。기관 네트워크의 모든 브라우저가 Origin Server가 아닌 Local Web Cache에 HTTP Request를 전송하여 중계하도록함.
  ▶ Web Cache에 저장된 객체를 요청하는 HTTP Request까지는 Access Link를 통해서 Origin Server에 접근할 필요없이 LAN 내부 Local Web Cache가 대신 처리
  
  。LAN 내부의 Local Web Cache에서 일정부분의 HTTP Request를 Origin Server 대신 처리하므로 Access Link의 Utilization이 감소.

  • 가정
    。기관네트워크의 브라우저에서 웹캐시로 요청한 HTTP Request의 Cache Hit Rate = 0.4
    
    
  • 소요시간 ( delay ) 계산
    
    。HTTP Request의 40%는 웹 캐시에 의해LAN 내부에서 즉시 응답
    ▶ 약 10 ms delay 발생
    
    。HTTP Request의 60%는 웹 캐시에서 Origin Server로 HTTP Request 전송
    ▶ HTTP Request 중 약 60%만 Access Link를 통과
    
    Access Link Traffic Intensity = $\displaystyle \frac{15 Mbps}{15.4 Mbps}*0.6=0.6$
    
    。기존 0.97 대비 0.6으로 Access Link Utilization이 감소하면서 Congestion이 감소
    ▶ 일반적으로 0.78 미만의 traffic intensity는 큐잉 지연이 낮으므로 msec delay를 발생
    
    Total Delay = Internet delay + Access delay + LAN delay
    ▶ ( 2 sec * 0.6 ) + ( 0.6 * msec ) + ( 0.4 * msec ) = 1.2 sec
    
    。웹캐시를 사용하지 않고 Fatter Access Link를 사용한 Total Delay ( 2 sec )보다 훨씬 감소한 것을 확인가능
    ▶ 또한 웹캐시 비용도 Fatter Access Link에 비해 저렴

Conditional GET [RFC 7232]
。HTTP Request Message 전송 시 GET Method와 If-Modified-Since Header Line을 포함하는 방식

。 웹 캐시는 자체저장소에 저장된 객체 사본이 Origin Server 내 객체보다 Outdated 될 수 있는 문제점이 존재
▶ Conditional GET을 통해 브라우저로 전달되는 객체가 Up to date인지 확인하면서 캐싱을 수행

• Conditional GET 원리
  

  • 브라우저의 HTTP Request를 수신하여 웹캐시에서 Origin Server로 HTTP Request를 요청( GET )

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com

  • Origin Server는 웹 캐시에 객체를 캡슐화한 HTTP Response Message를 응답

  HTTP/1.1 200 OK
  Date: Sat, 3 Oct 2015 15:39:29
  Server: Apache/1.3.0 (Unix)
  Last-Modified: Wed, 9 Sep 2015 09:23:24
  Content-Type: image/gif
        // 
        HTTP Response Body
        //

  。웹캐시는 해당 객체 사본과 Last-Modified의 Date를 함께 자체저장소에 저장 및 브라우저로 전달
  
  

  • 일정기간이 소요된 후 브라우저가 웹 캐시에 동일 객체를 HTTP Request하여 요청( GET )
    。브라우저가 웹 캐시에 동일 객체를 요청

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com

  • 웹 캐시에서 Origin Server로 Conditional GET 수행
    。웹 캐시가 저장한 객체 사본의 Last-Modified의 Date를 HTTP Request Message의 If-modified-since : Header Line에 포함하여 Origin Server로 HTTP Request를 요청

  GET /fruit/kiwi.gif HTTP/1.1
  Host: www.example.com
  If-modified-since: Wed, 9 Sep 2015 09:23:24

  ▶ 객체 사본이 Up to date한지 검증을 위해 Origin Server로 전송
  
  

  • Origin Server에서 HTTP Request Message에 포함된 If-modified-since : Header Line을 검증 후 응답
    。Origin Server의 객체의 Last-Modified와 웹 캐시에서 전송한 If-modified-since의 시점을 비교 후 응답에 객체 포함 결정

    • If-modified-since : 시점의 명시된 시점 이후에 객체가 수정되지 않은 경우
      。객체가 Up to date한 상태이므로, 빈 객체를 웹 캐시로 반환
      ▶ 비어있는 Message Body를 응답하므로 Response Time이 적음

    HTTP/1.1 304 Not Modified
    Date: 전송시각
    Server: Apache/1.3.0 (Unix)
          // 
          객체 없음
          //

    。 Status Code : 304를 Client에 응답하여 웹캐시에 저장된 객체 사본을 사용하도록 지시
    
    

    • If-modified-since : 시점의 명시된 시점 이후에 객체가 수정된 경우
      。웹 캐시에 객체 사본이 저장된 이후 Origin Server에서 해당 객체를 수정하여 객체 사본이 Outdated된 경우 ( ex : Wed, 9 Sep 2015 09:23:24 이후에 수정된 경우 )

    HTTP/1.1 200 OK
    Date: 전송시각
    Server: Apache/1.3.0 (Unix)
    Last-Modified: 객체가 마지막으로 수정된 Date
    Content-Type: image/gif
          // 
          HTTP Response Body
          //

    。수정된 객체와 Last-Modified를 웹 캐시에 응답
    ▶ 웹 캐시는 자체저장소에 해당 객체 사본으로 교체하여 Last-Modified와 함께 저장 후 클라이언트로 반환

프록시 종류

• Forward Proxy :
  。Client-side에서 Client 대신 Proxy Server가 목적서버(Web server)에 대리로 통신해주는 역할을 수행하는 프록시 서버
  ▶ Proxy Server가 외부 웹서버와 통신을 수행하면서 Client는 Proxy Server만을 이용하여 정보를 획득하고 웹서버는 Proxy Server를 통한 Access log가 남는다.
  
  。Client가 어떤 Proxy Server를 경유할지 설정 가능.
  
  
• Reverse Proxy :
  。Server-side에서 Client의 Http Request를 처리하는데 적합한 웹서버를 선택허여 배분하는 역할을 수행하는 프록시 서버
  ▶ Client의 각 url에 따른 Http Request를 Proxy Server에 집중한 후 url에 따라서 각 HttpRequest를 수신할 웹서버를 설정.
  
  。Client 입장에서는 Proxy Server가 웹서버와 동일한 동작을 수행하므로, 서버 측에서 웹서버가 여러개 존재하는것을 은폐 가능.
  
  。주로 nginx가 존재