[Web] 웹 브라우저 성능 개선 및 웹 서버 부하 완화

0. 웹 서버 부하 완화 및 웹 페이지 조회 성능 개선

웹의 본질은 웹 서버가 클라이언트(웹 서버 혹은 웹 브라우저)의 요청에 따라 그에 맞는 웹페이지를 반환한다.

• 웹 페이지 뿐 아니라 영상, 음성, 이미지 등 모두 반환 = 통칭 HTTP Resource
• 웹의 본질에 따라
  • 웹 브라우저는 매번 웹 서버에게 요청해서 결과를 받아와야 하고
  • 웹 서버는 매번 웹 브라우저의 요청에 대해 결과를 만들어 반환해야한다.
• 그래서 웹 브라우저와 웹 서버는 너무 힘들다.
  • 웹 브라우저 : 결과가 똑같다면 웹 브라우저는 매번 웹 서버에서 결과를 받아올 필요가 없다.
    • 이전에 받았던 결과를 저장 후, 매번 같은 요청이 오면 저장한 결과를 재사용하면 되지 않을까?
  • 웹서버 : 결과가 똑같다면, 웹 서버는 매번 웹 브라우저에게 만들어 줄 필요가 없다.
    • 이전에 만들었던 결과를 저장 후, 매번 같은 요청이 오면 저장한 결과를 재사용하면 되지 않을까?

0-1. 결과 반환 비용(시간, 네트워크 트래픽)을 줄이자 : 웹 브라우저 관점

• 반복 : 웹 브라우저는 매번 똑같은 100MB짜리 고양이 영상을 웹 서버로부터 받아온다.
  • 네트워크 트래픽 및 비용 발생
  • 100MB 다운로드 완료까지 긴 대기시간 후 시청가능
• 이전에 받았던 100MB짜리 고양이 영상을 재사용한다면?
  • 네트워크 트래픽 및 비용 감소
  • 100MB 다운로드 완료의 긴 대기시간 없이 바로 시청 가능 -> 유저 경험증진

 

0-2. 결과 생성 비용(노동, 자원)을 줄이자 : 웹 서버 관점

• 반복 : 웹 서버는 매번 똑같은 100MB짜리 고양이 팜플렛을 웹 브라우저에게 만들어준다.
  • 반복 연산 : 컴퓨터 자원(CPU, Memory) 소비
  • 트래픽 과중 : 모든 유저의 요청에 따라 반복 연산
• 이전에 만들었던 100MB짜리 고양이 팜플렛을 재사용한다면?
  • 반복 연산 감소 : 컴퓨터 자원(CPU, Memory) 여유
  • 트래픽 분산 : 반복되는 모든 유저의 요청 간단히 처리 가능 

1. HTTP Cache : 임시 중간 저장소

• 웹 브라우저와 웹 서버는 반복되는 요청에 대해 부담을 나누기 위한 기술을 도입 : HTTP Cache

• 웹 브라우저와 웹 서버 사이 임시 저장 중간소를 두고, 그곳에 재사용하려는 고양이 영상, 팜플렛 결과 저장
• 같은 말로 웹 브라우저와 웹 서버 사이 HTTP Cache를 놓고, 그곳에 재사용하려는 HTTP Resources 결과 저장

Cache 캐시 용어의 범용성

"클라이언트와 서버" 처럼 문맥에 따라 워낙 다용하게 사용되니 짚고가보자

• 캐시(명사) : 임시(단기적)로 재사용 할 내용을 저장
  • CPU 캐시 : CPU 연산을 위해 메모리에서 값을 가져와 사용 후 폐기
  • HTTP 캐시 : 웹 요청에 따른 결과를 임시 저장 후 사용
  • 서버 캐시 : LRU-Cache '로컬 캐시' 혹은 인메모리 DB인 Redis '글로벌 캐시'
• 캐시 동사 : "임시 저장하자"의 의미

 

1-2. HTTP Cache 종류

임시 저장 데이터를 누가 필요로 하는가? 1.특정된 한명인가, 2.불특정 다수인가?

• 임시 중간 저장소가 웹 브라우저 안에 있다면, 해당 웹 브라우저 유저 한명을 위한것
  • 아래 이미지에서 A.Private
• 임시 저장소가 웹 브라우저와 웹 서버 사이에 있다면, 모든 웹 브라우저 유저 다수를 위한것
  • 아래 이미지에서 B.Shared

 

• (번외) 서버 캐시 종류 : HTTP Cache가 아닌 웹 서버에서 사용하는 캐시에도 로컬/글로벌로 나뉜다
• 데이터 베이스는 영구적 저장이라면, 캐시는 일시적 저장 - 목적에 맞게 활용
  • 로컬 캐시 : LPU-Cache, Memcache, Chcache
  • 글로벌 캐시 : Redis(캐시 서버, 데이터베이스에 가까운 사용)

• Private : 해당 웹 브라우저만을 위해 - 특정된 한명만 사용 가능(웹 브라우저에 위치)
  
  • 브라우저 캐시 : 웹 서버 HTTP Cache 헤더(Cache-Control)를 통한 제어

 

• Shared : 모든 웹 브라우저들을 위해 - 불특정 다수가 사용 가능(웹 브라우저와 웹 서버 사이에 위치)
  • 프록시 캐시 : 웹 서버 HTTP Cache 헤더(Cache-Control)를 통한 제어
  • 관리형 캐시 : 서비스 개발자가 직접 정책 제어, 배포, 캐싱할 데이터 직접 업로드 등(Reverse proxy, CDN)
  • 프록시 캐시, 관리형 캐시는 Cache-Control 헤더를 통해 제어하느냐 직접 제어하느냐 여부로 나뉜다.
    • 프록시 캐시는 웹 서버가 주는 Cache-Control 헤더대로 동작 = 수동적
      • 물론 개발자가 어느정도 의도를 가지고 개발하지만 결과적으로 웹 서버가 반환하는 응답에 대해서만 Cache-Control 헤더에 의해 저장
    • 관리형 캐시는 개발자가 직접 어떤 데이터들을 캐싱할지 업로드하고, 삭제하고, 배포 및 제어

 

1-4. HTTP Cache 동작

• 캐시 활용 여부 : 실시간성이 중요한 데이터의 경우 성능에 문제가 되더라도 캐시를 사용하면 안된다.
• 재검증 : 데이터의 원래 주인인 웹 서버에 캐시되어 있는 데이터의 유효성(신선도) 체크
  1. 재검증 주기 : 캐시되어 있는 데이터를 얼마의 주기를 가지고 재검증할 것인가
     • 데이터가 얼마의 주기로 갱신되는지, 각 데이터의 특성에 따라 개발자가 설정하면 된다.
  2. 재검증 기준 : 캐시되어 있는 데이터의 유효성(신선도) 여부 판단 근거
     • 시간 : 수정일(Last-modified)
     • 고유값 : 해시 또는 ID (ETag)

1-5. HTTP Cache 제어 : Cache-Control 헤더를 통한 세부 설정 방법

• 서버의 제어 : HTTP Cache 사용 여부 및 기간, 저장 장소 등 정책 전달을 위해 Cache-Control 헤더를 사용한다.
  1. 캐시의 저장 여부 : 데이터를 캐싱해야하는가?
     • no-store : 캐시 x
     • no-cache : 캐시 o , 하지만 매번 재검증을 거친 후 사용한다.(기존 데이터를 받는것보다 패킷 경량화)
  2. 캐시 저장 장소
     • public : Private + Shared 모두 저장
     • private : Private에만 저장
  3. 캐시 재검증 주기 : 데이터를 캐시 한 후 얼마의 시간 후 재검증 할 것인가?
     • max-age : Expires(유효시간)으로 변환되기 때문에, 기존 Expries가 있어도 덮어쓴다.
       • 매번 재검증을 해야 하는 데이터 : max-age=0 OR no-cache
     • s-maxage : 프록시 캐시에만 적용되는 유효기간
       • CDN 캐시 적용 : s-maxage = 31536000, max-age = 0 
         이러한 s-maxage의 경우 잘 변하지 않지만 버전업 등 혹시나 변할지 모르는 상황에서 개발자가 Invalid를 통해 캐시되어 있는 데이터를 변경해야 할 때 사용할 수 있다.
  4. 재검증 강제
     • must-revalidate : max-age에 도달했을 때 꼭 재검증이 완료된 뒤 사용하도록 강제하는 것
       • 기존에는 max-age에 도달했을 때, 서버와의 접속 문제로 재검증이 실패 시 캐싱되어 있는 데이터 반환
       • 하지만 must-revalidate가 활성화되어 있다면 504에러가 발생한다.
       • 통장 잔고 같은 것은 어떤 상황에서도 서버의 검증 없이 쓰이면 안되기 때문이다.
• 재검증 : 캐시 소유자가 서버에게 자신이 가진 캐시 데이터 전달 및 유효성(신선도)을 검증 받는 행위
  • 조건부 요청 : 재검증 기준이 되는 값을 서버에게 보낸다.

시간 기반(Last-Modified) 대응일 때 그림

서버가 해당 헤더(Last-Modified) 를 줄때 : 전송 Resource의 마지막 수정일

기본적으로 캐시가 유효한지 여부를 시간을 기반으로 판단한다.

• 캐시 소유자 : If-Modified-Since (저장된 데이터를 받은 시간 이후로 데이터가 바뀌었나?)
  • 만약 바뀌었다면 -> 200 + Resource Cache
• 캐시 소유자 : If-Unmodified-Since (저장된 데이터를 받은 시간 이후 데이터가 안 바뀌었나?)
  • 만약 안 바뀌었다면 -> 304 Not Changed

고유값(ETag)기반 대응일 때 그림

서버가 해당 헤더(Etag) 를 줄때 : 전송 Resource의 고유값(해시, ID)

기본적으로 캐시가 유효한지 여부를 고유값(해시, ID)을 기반으로 판단한다.

• 캐시 소유자 : If-None-Match (저장된 데이터를 받은 고유값 데이터가 바뀌었나?)
  • 만약 바뀌었다면 -> 200 + Resource Cache
• 캐시 소유자 : If-Match (저장된 데이터를 받은 시간 이후 데이터가 안 바뀌었나?)
  • 만약 안 바뀌었다면 -> 304 Not Changed

 

• 추가적으로 HTTP Cache 제어 중 SWR (stale-while-revalidate) 확장 디렉티브 전략
  • 현재에(당장) 캐싱된 컨텐츠를 즉시 로드하는 즉시성(Stale한 데이터라도)
  • 미래에 업데이트 된 캐싱 컨텐츠가 사용될 수 있도록 보장하는 최신성

Cache-Control : max-age=1, stale-while-revalidate=60일 때 나타나는 그림

• 0~1초(max-age 지나기 전) : 캐싱된 응답을 "재검증"없이 바로 반환

• 1~60초(오래되었지만 반환 후, 재검증) : 캐싱된 응답을 바로 반환 + "재검증"요청(백그라운드 내)

• 60~초(재검증) : 캐싱된 응답을 사용하지 않고 + 서버에 요청보내 응답 캐싱 및 반환

1-6. HTTP Cache 이점

• 웹 서버 입장 : 가장 큰 장점은 웹 서버의 부하가 완화된다.
  • 반복 연산 감소 : 웹 서버가 동적 웹페이지를 생성하는 연산을 하지 않아도 된다.(캐시가 반환하기 때문)
  • 트래픽 분산 : 웹 서버가 모든 요청 트래픽을 받아내지 않아도 된다.(캐시가 일부 트래픽을 분담하기 때문)
• 웹 브라우저 입장 : 가장 큰 장점은 빠르고 높은 효율로 웹을 이용할 수 있다.
  • 네트워크 트래픽 감소(레이턴시 및 네트워크 대역폭 사용 감소)
  • 유저 경험 증진

2. 스클비트 로드 전략 : HTML 파싱 (DOM 생성 중) JS 파일 로드 시점 조율

웹 브라우저 내 HTML(DOM) 웹 페이지 로드 속도 향상 : 스크립트 로드 시점 조율

• 웹 브라우저는 페이지 표기를 위해 HTML 파일을 위에서 아래로 순서대로 읽으며 DOM Tree 생성
  • 중간에 JS가 포함된 <script>를 만난다면 이 또한 DOM 요소이기에 완벽하게 로드 및 실행
  • 하지만, 이렇게 HTML(DOM)웹 페이지 로드 중 중간에 <script>의 JS파일을 다 실행한다면?
    1. 다운받은 JS 파일을 모두 로드 및 실행하는데 오랜 시간을 기다려야함 (DOM 로드 지연)
    2. 다운받은 JS파일 실행 시 <script> 아래 위치한(아직 로드되지 않은) DOM 접근 불가
    3. <script>를 맨 아래로 내린다고 하더라도 HTML이 크다면 스크립트 시랭 히기는 늦음
• 이러한 문제를 해결하기 전 비동기에 대해 알아보자
  • 서버간 통신할 때 어떤 방식으로 나뉠까?
    1. 동기(Synchronous, 실시간성) : 요청 - 응답을 대기
    2. 비동기(Asynchronous, 비실시간성) : 요청 - 응답을 대기하지 않음(하지만 요청에 대한 응답이 누락되는 것은 아님)

• Defer : (실행) 지연 스크립트
  • 병렬 : HTML 파싱 - 스크립트 호출(로딩)  -> HTML 파싱 끝난 후 실행
  • 심화 : DOMContentLoaded = HTML 파싱 및 Defer 지연 스클비트 호출 및 실행이 다 끝났을 때
• Async : (실행) 비동기 스크립트
  • 병렬 : HTML 파싱 - 스크립트 호출(로딩) + 바로 실행
    • 만약 스크립트 호출이 끝난다면 HTML 파싱을 잠시 멈추고, 스크립트 실행

 

3. Proxy와 CDN : 클라이언트 및 웹 서버의 캐시(성능 향상 및 부하 완화), 보안으로의 역할

Proxy는 캐싱 + 요청에 대한 세부적 추가 작업을 위해 사용한다.

• 캐싱 : 요청에 따른 응답을 중간 저장해놓은 뒤, 동일 요청 시 저장값 반환
• 요청에 대한 세부적 추가 작업 : 요청 변환, 필터 등의 추가 작업 수행

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

• 캐싱 : 요청에 따른 응답을 중간 저장해놓은 뒤 동일 요청 시 저장값 반환
• 지역성 해결 : HTTP Resource 제공 서버와 클라이언트가 멀리 떨어진 경우 클라이언트와 가까운 곳에 저장

3-1. Proxy : 클라이언트 측 Forward Proxy와 서버 측 Reverse Proxy, 두 종류로 나뉜다.

 

Forward Proxy : 클라이언트 성능 및 보안

• 요청 보내는 측 : 클라이언트(웹 브라우저)
  • 요청에 대한 세부적 추가 작업
    1. 클라이언트 은닉 : IP 변환을 통해 원 요청자 은닉
    2. 클라이언트 접근 제어 : 특정 IP혹은 웹 페이지에 대한 접근 금지
    3. 캐싱 : 클라이언트가 받을 요청을 중간에 임시 저장(개인이 소비하는 입장에서)

Reverse Proxy : 웹 서버 성능 향상, 부하 완화 및 보안

• 요청을 받는 측 : 웹 서버
  • 요청에 대한 세부적 추가 작업
    1. 요청 변환 : Header 세팅
    2. 요청 전달 : URL Mapping (Routing), 로드 밸런싱(요청 분산)
       • 로드 밸런싱(요청 분산) = 웹 서버의 부하 완화
    3. 서버 은닉 : 서버 고유의 IP가 외부로 노출되지 않음
    4. 서버 접근 제어(요청 필터) : DDos 방지 - Trafiic 제어, Response Max Size, Timeout 세팅
       • Rate Limiting
       • WAF( Web Application Firewall)
         • Honeypot에 저장된 악성 IP 리스트 활용한 블럭
         • Custom IP 추가 기능
    5. 보안 : HTTPS
       • 보통 모든 서버가 Private Key를 가지고 암호화를 진행해야 하는 단점

       • 

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

       • 

    6. 캐싱 : 클라이언트가 자주 요청하는 응답을 중간에 임시 저장 (다수에게 제공하는 관점에서)

3-2. CDN (Content Delivery Network) : Reverse Proxy = 웹 서버 성능 향상, 부하 완화

 

미국 웹 서버가 제공하는 HTTP Resource를 한국 클라이언트에서 조회 시 물리적인 거리에 의한 긴 응답시간이 발생

전 세계적으로 캐시 서버를 곳곳에 두어 중간에 저장해놓는다면, 각국에서 필요한 정보들을 빠르게 취할 수 있음

캐시 서버로 동작하는만큼 원 서버에 문제가 생기면 CDN이 고가용성을 보장해주는 버퍼의 역할을 하기도 함

 

 

최종적으로 웹 브라우저와 웹 서버 사이에 존재하는 다양한 캐시들과 관계도(?)를 그리면 아래와 같을 수 있다.