<Web> 웹 브라우저 성능 개선 및 웹 서버 부하 완화, HTTP Cache, Proxy

2024.05.08 - [Web] - 웹 저장소 Cookie, Session, Storage

<Web> 웹 저장소 Cookie, Session, Storage

들어가기 앞서 이전글을 읽으시면 이해하시는데 도움이 됩니다.

 

이번 글에서는

• 웹 브라우저와 웹 서버의 부하
• 웹 서버 부하 완화 및 웹 페이지 로드 성능 개선
• HTTP Cache
• Proxy

까지 다뤄보도록 하겠습니다.

시작!

---

1. 웹 브라우저와 웹 서버의 부하

 

웹의 본질은 요청을 보내고 결과를 받는 것입니다.

웹의 성능은 요청을 보냈을 때 결과를 가능한 빠르게 받는 것을 의미합니다.

 

여기서 결과란, HTTP Resource(웹 페이지, 영상, 음성, 이미지 등)입니다.

 

1.1 웹 브라우저

• 웹 페이지 로드 결과가 이전과 같다면, 매번 웹 서버에게 결과를 받아올 필요가 없습니다.
• 이전에 받았던 결과를 저장 후, 요청 시 저장한 결과를 재사용 반환하면 됩니다.

 

1.2 웹 서버

• 웹 페이지 로드 결과가 이전과 같다면, 매번 웹 브라우저를 만들어 반환할 필요가 없습니다.
• 이전에 반환한 결과를 저장 후, 요청을 받을 시 저장한 결과를 재사용 반환하면 됩니다.

---

2. 웹 서버 부하 완화 및 웹 페이지 로드 성능 개선

 

2.1 웹 브라우저 : 결과 "반환" 비용을 줄이자

웹 브라우저 캐시 흐름 : 캐시 후 0초 후 응답 = 네트워크 사용 X (0초) + 서버자원 사용 X (0초)

 

예시)

웹 브라우저는 매번 같은 100MB 크기의 고양이 영상을 웹 서버로부터 받아온다.

• 네트워크 트래픽  및 비용 증가 
• 고양이 영상(100MB) 다운로드 완료까지 대기시간 발생

이전 결과를 재사용한다면? 

• 네트워크 트래픽 및 비용 감소
• 대기시간 없이 영상 시청 가능 = 유저 경험 증진

 

2.2 웹 서버 : 결과 "생성" 비용을 줄이자

웹 서버 캐시 흐름 : 캐시 후 3초 후 응답 = 네트워크 사용 O (3초) + 서버자원 사용 X (0초)

 

예시)

웹 서버는 매번 같은 100MB 크기의 고양이 영상을 웹 브라우저에게 만들어 준다.

• 반복적인 서버자원(CPU, Memory) 소비 : 모든 유저의 요청에 대한 반복 연산

이전 결과를 재사용한다면? 

• 반복적인 서버자원(CPU, Memory) 소비 감소 : 반복되는 모든 유저의 요청을 간단히 처리
• 불특정 다수의 웹 브라우저에게도 캐시 된 자원 제공 가능
  • HTTP Cache vs Web Brower Cache
  • 웹 브라우저 캐시는 웹 브라우저 유저만 캐시 된 자원을 활용할 수 있었다.

---

3. HTTP Cache

HTTP 캐시는 Web Resource (HTML 문서, 이미지, JavaScript 파일 등)의 복사본을 저장하는 기술입니다.

사용자가 웹사이트를 방문할 때 리소스가 캐시에 이미 저장되어 있다면, 서버에서 다시 다운로드할 필요 없이 캐시에서 바로 리소스를 불러올 수 있습니다. 이로 인해 페이지 로딩 시간이 단축되고, 서버 부하가 감소하며, 전반적인 웹 성능이 향상됩니다.

 

---

3.1 HTTP Cache 종류

HTTP 캐시는 크게 두 가지 유형으로 나눌 수 있습니다: private 캐시와 shared 캐시입니다.

 

임시 저장 데이터를 누가 필요로 하는가? 에 따라 종류가 나뉩니다.

• Private Cache : 특정된 한 명인가
• Shared Cache : 불특정 다수인가

1. 브라우저 캐시 (Private Cache) 
   1. 브라우저 캐시 (Private Cache)는 특정 사용자만 접근 가능한 캐시로서, 대표적으로 웹 브라우저의 캐시가 여기에 해당합니다.
   2. 사용자가 한 번 방문했던 웹페이지의 리소스들이 브라우저에 저장되어, 같은 리소스를 다시 요청할 때 서버에 직접 요청하지 않고 브라우저의 캐시에서 불러오는 방식으로 작동합니다.  
   3. 웹페이지의 로딩 시간을 줄이고, 서버의 부하를 감소시킬 수 있습니다.
2. 공유 캐시 (Shared Cache)
   1. 공유 캐시 (Shared Cache)는 여러 사용자가 공유하여 사용하는 캐시로서, 대표적으로 프록시 서버나 CDN(Content Delivery Network)가 여기에 해당합니다.
   2. 프록시 서버는 여러 사용자의 요청을 대신하여 서버와 통신하고, 이때 응답받은 데이터를 캐시에 저장하여 후속 요청에 빠르게 응답할 수 있습니다. (프록시 서버에 대해서는 밑에서 더욱 자세히 다루겠습니다.)

---

3.2 HTTP Cache 동작

캐시는 최신 데이터를 반영하지 않을 수 있어 문제가 될 수 있습니다.

예를 들어, 웹 사이트의 CSS 파일이 변경되었을 때, 사용자의 브라우저가캐시 된 오래된 파일을 사용하면 최신스타일이 반영되지 않을 것입니다.

이러한 문제를 해결하기 위해 HTTP 캐시는 '재검증(Revalidation)'이라는 과정을 거칩니다.

• 준실시간 : 캐시 해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증
• 재검증 : 캐시 한 데이터의 주인인 웹 서버가 설정한 특정 주기에 따라 캐시 한 데이터가 오래됐는지 검증

 

3.2.1 캐시 재검증: 준실시간성 보장

캐시 재검증은 클라이언트가 서버에게 캐시 된 리소스가 여전히 유효한지 확인하는 과정입니다.

캐시 재검증은 HTTP 헤더의 ETag나 Last-Modified 값 등을 통해 이루어집니다.

• ETag: 각 리소스에 대해 서버가 생성하는 고유한 식별자입니다. 리소스가 변경될 때마다 ETag 값도 변경되므로, 클라이언트는 ETag 값을 통해 리소스의 변경 여부를 확인할 수 있습니다.
• Last-Modified: 리소스가 마지막으로 변경된 시간을 나타냅니다. 클라이언트는 이 값을 통해 마지막으로 받았던 리소스 이후에 변경이 이루어졌는지를 확인할 수 있습니다.

 

3.2.2 재검증 과정

1. 클라이언트가 캐시 된 리소스를 사용하기 전에 서버에 재검증 요청 (ETag나 Last-Modified 값을 함께 보냄)
2. 서버가 ETag나 Last-Modified 값을 비교하고 리소스의 유효성을 판단
3. 서버는 리소스가 변경되었는지를 확인
   1. 변경 O : 새로운 리소스 + 200 OK 응답 반환
   2. 변경 X :  304 Not Modified 응답 반환

 

3.2.3 HTTP Cache 재검증 기준

Last-Modified (수정일)	ETag (고유값)
낮은 정확도 - 파일이 수정되지 않았는데 수정일이 변경되는 경우 - 텍스트 파일 수정 후, 다시 원상복구한 경우 수정일만 변경	높은 정확도 - Last-Modified 보다 ETag 사용을 권장 - 다만, HTTP 1.0 혹은 1.1 호환성을 위해 둘 다 사용하는 것을 권장
검사 방법 - If-Modified-Since : 바뀌었어? - If-Unmodified-Since : 안바뀌었어?	검사 방법 - If-None-Match : 바뀌었어? - If-Match : 안바뀌었어?

 

---

3.3 Cache-control 헤더를 통한 세부 설정

캐시 저장 여부 

• no-store : 캐시 안 함
• no-cache : 캐시 함. 단, 매번 재검증 후 사용 (패킷 경량화) ← 캐시 안 하는 게 아님!

캐시 저장 장소

• public : Private(웹 브라우저) + Shared(프록시) 모두에 저장 ← 브라우저에도 저장!
• private : Private(웹 브라우저) 에만 저장

 캐시 재검증 주기 

• max-age : Expires(유효시간)으로 변환 (기존 Expires 가 있다면 덮어쓴다)
• s-maxage : 프록시 캐시에만 적용되는 유효기간

예시) 

s-maxage=31536000(1년), max-age=0는 무엇을 의미하나?

• 웹 브라우저는 계속 CDN에게 재검증을 수행, CDN 은 1년을 주기로 본 웹 서버에게 재검증
• 웹 브라우저는 CDN 이 자체적으로 Invalidation(무효화) 하지 않는 한 1년 동안 같은 데이터만 반환

---

4. Proxy

프록시는 클라이언트와 서버 사이에 위치하여 클라이언트의 요청을 서버에 전달하고, 서버의 응답을 클라이언트에게 전달하는 중간 역할을 하는 서버입니다.

프록시 서버는 네트워크 트래픽을 필터링하고, 사용자의 IP 주소를 숨기는 등의 보안 기능 제공, 캐시를 활용한 내용 전달 성능 향상 등 다양한 목적으로 사용됩니다.

---

4.1 포워드 프록시(Forward Proxy)

포워드 프록시는 클라이언트와 인터넷 사이에 위치하며, 클라이언트의 요청을 대신하여 인터넷의 서버로 전송합니다.

이 과정에서 포워드 프록시는 클라이언트의 실제 IP 주소를 숨기고 자신의 IP 주소를 사용하여 요청을 전송합니다.

이를 통해 사용자의 익명성을 보장하고, 접근 제어나 콘텐츠 필터링 등의 추가 보안 기능을 제공할 수 있습니다. 또한, 자주 요청되는 데이터를 캐싱함으로써 네트워크 성능을 개선하는 역할도 합니다.

---

4.2 리버스 프록시(Reverse Proxy)

반면, 리버스 프록시는 인터넷과 서버 사이에 위치하여 서버의 응답을 클라이언트에게 전달하는 역할을 합니다.

서버의 실제 IP 주소를 숨기고 대신 리버스 프록시의 IP 주소를 사용하여 클라이언트의 요청을 받습니다.

이를 통해 서버의 보안을 강화하고, 로드 밸런싱을 통해 서버의 부하를 분산시키는 등의 기능을 제공합니다. 또한, SSL 암호화 처리나 압축, 캐싱 등의 기능을 통해 서비스의 전송 속도와 보안을 향상시킬 수 있습니다.

---

4.2.1 L2 Reverse Proxy : Load Balancer

로드 밸런서는 여러 서버 사이에 들어오는 트래픽을 분산시켜, 단일 서버에 과부하가 걸리는 것을 방지하고 서비스의 가용성과 성능을 유지합니다.

로드 밸런서는 서버가 다운되거나 과부하 상태에 이르는 것을 방지하며, 사용자에게 더 안정적인 서비스를 제공할 수 있게 해 줍니다.

 

기능과 장점

• 트래픽 분산: 다수의 서버에 트래픽을 고르게 분산시켜 처리 능력을 최적화합니다.
• 고가용성: 하나의 서버가 실패하더라도 다른 서버가 해당 트래픽을 처리하여 서비스 중단을 최소화합니다.
• 확장성: 서비스의 요구 사항에 맞춰 서버를 추가하거나 줄이는 것이 용이합니다.
• 한 서버(Reverse Proxy)가 Private Key를 가지고 있으면 관리 및 인증이 간편합니다.

 

 

요청을 받는 측 : 웹 서버

• 요청에 대한 세부적 추가 작업
  • 요청 변환 : Header 세팅 (예, X-FORWARDED-BY로 근원 클라이언트 IP를 서버에게 전달)
  • 요청 전달 : URL/I Mapping (URI 기반 Routing), 로드 밸런싱 (요청 분산)
    • 로드 밸런싱 (요청 분산) = 웹 서버 부하 완화
      • 웹 서버 수 동적으로 늘리기 → SRE의 업무 (고가용성)
  • 서버 은닉 : 서버 고유의 IP 가 외부로 노출되지 않음
  • 서버 접근 제어 (요청 필터)
    • DDoS 방지 : Traffic 제어
      • Rate Limiting : 짧은 시간(예, 1초) 내 너무 많은 요청이 오는 것을 막기 위한 정책

 

• 한 서버(Reverse Proxy)가 Private Key를 가지고 있으면 관리 및 인증이 간편합니다.

---

4.2.2 L1 Reverse Proxy : CDN (Contents Delivery Network)

CDN은 전 세계에 분산된 서버 네트워크를 사용하여 사용자에게 웹 콘텐츠를 더 빠르게 제공하는 시스템입니다. 사용자가 요청하는 콘텐츠를 사용자에게 가장 가까운 서버에서 제공함으로써, 데이터 전송 시간을 단축하고 사용자 경험을 개선합니다.

 

 

기능과 장점

• 향상된 속도: 사용자에게 더 가까운 서버에서 콘텐츠를 제공함으로써 로딩 시간을 단축합니다.
• 스케일링: 트래픽이 몰릴 때 자동으로 처리 능력을 조정하여 서비스의 안정성을 유지합니다.
• 보안 강화: DDoS 공격과 같은 여러 종류의 네트워크 공격으로부터 웹 애플리케이션을 보호할 수 있습니다.

 

CDN 은 캐싱 + 지역성 해결을 을 위해 사용합니다.

 

• 캐싱 : 요청에 따른 응답을 중간 저장해 놓은 뒤 동일 요청 시 저장값 반환
  • 원본 데이터를 가진 웹 서버에 문제가 생기면 CDN이 대신 응답을 반환하여 고가용성 보장
    • CDN : 고가용성을 보장해 주는 버퍼의 역할
  • 원본 데이터를 가진 웹 서버에 DDoS 공격을 방지하는 역할
• 지역성 해결 : HTTP Resource 제공 서버와 클라이언트가 멀리 떨어진 경우 클라이언트에게 가까운 곳에 저장
  • 한국 웹 브라우저에서 미국 웹 서버로부터 응답을 받으려면 긴 응답시간을 기다려야 함
  • 전 세계적으로 캐시 서버를 곳곳에 두어 캐시 서버 내 응답 데이터를 캐싱(저장)하여 속도 개선

---