웹 브라우저 성능 개선 및 웹 서버 부하 완화(4) - 서버 부하 완화 및 보안(요청/응답 변조)을 위한 Proxy

프록시를 사용하는 이유

1. 보안: IP 숨기기 혹은 프록시 서버를 방화벽으로 사용하기도 한다(프록시 방화벽)
2. 속도(캐시): 동일 요청이 들어오면 서버에 다로 접속할 필요가 없이 저장된 Cache 자원을 반환
   • 전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지 = 이는 서비스의 속도를 높여준다
3. ACL: 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)
4. Log/ Audit: 리포트, 모니터링(회사 내 직원의 인터넷/인트라넷 사용을 레포팅)
5. 지역 네트워크 제한 우회: 한국에서는 접속이 제한이 되는 사이트 (IP 검사로 한국에서의 접속임을 감지)
   • 이런 경우 프록시 서버를 사용하면 접속을 다른 나라로 우회

proxy는 클라이언트측 Forward Proxy 와 서버측 Reverse Proxy, 두 종류로 나뉜다.

---

1. Forward Proxy: 웹 클라이언트 보안 및 접근 제어(예, ISP)

요청 보내는 측: 클라이언트(웹브라우저)

Forward Proxy 역할

1. 클라이언트 은닉: IP 변환을 통해 원 요청자 은닉
   • 우회(Bypass): 특정 클라이언트 IP가 블락되어있다면, 그걸 피해서 접속하기 위해 IP감춤
2. 클라이언트 접근 제어: 특정 IP 혹은 웹 페이지에 대한 접근 금지
3. 캐싱: 클라리언트가 받을 응답을 중간에 임시 저장(개인이 소비하는 입장에서)

---

2. Reverse Proxy: 웹 서버 부하 완화 및 보안(예, 로드 밸런서)

요청 받는 측: 웹 서버 (Nginx와 같은 WS를 쓰기도 한다.., AWS ELB)

Reverse Proxy 역할

1. 요청 전달: URL/I Mapping (URI기반 Routing), 로드 밸런싱(요청 분산)
   • 로드 밸런싱(요청 분산) = 웹 서버 부하 완화
   • 웹 서버 수 동적으로 늘리기 -> SRE 의 업무 (고가용성)
2. 요청 반환: Header세팅 ( 예, X-FORWARDED-BY로 근원 클라이언트 IP를 서버에게 전달)
   • X-FORWARDED-BY: 123, 456, 789 -> 가장 마지막에 있는게 최초 호출자
3. 서버 은닉: 서버 고유의 IP가 외부로 노출되지 않음
4. 서버 접근 제어(요청 필터)
   • DDoS 방지: Traffic 제어
     • Rate Limiting: 짧은 시간(예, 1초) 내 너무 많은 요청이 오는걸 막기 위한 정책 (WS, WAS 같은 원 서버에서도 적용 가능)
     • WAF(Web Application Firewall)
       • Honypot에 저장된 악성 IP리스트 활용한 블럭
       • Custom IP추가 가능, (예, 악성 크롤링 봇 블럭)
   • Response Max Size 세팅: 너무 큰 파일을 반환하는 경우 블락(Nginx 설정)
   • Timeout 세팅: Nginx 설정으로 세팅 가능
5. 보안: HTTPS: 모든 서버가 Private Key를 가지고 있어야하는 단점을 한 서버(Reverse Proxy)가 Private Key를 가지고 있으면 관리 및 인증이 간편해진다. (아래 그림 참고)
6. 캐싱: 클라이언트가 자주하는 요청에 대한 응답을 중간에 임시 저장(다수에 제공하는 관점에서)

프록시 서버에만 private key를 가지고 있으면 된다.

 

---

L2 Reverse Proxy: Load Balancer

💡Load Balancer: 대량 트래픽에 의한 서버 부담을 어떻게 분산할까
트래픽 분산 뿐만 아니라, 트래픽이 급증하거나 급감하는 경우 서버의 수를 동적으로 제어하여 고가용성 제공

단 한개의 웹 서버를 통해 웹 어플리케이션 서비스를 제공하는 경우 아래 두 문제가 발생

1. 대량의 트래픽이 한개의 웹 서버에 집중되는 경우
   • 한개의 웹 서버가 트래픽을 감당하지 못해 터져버린다. -> 수직적 확장 혹은 수평적 확장이 필요
2. 새 버전의 웹 어플리케이션을 배포 시
   • 새로운 웹 서버에 배포하는 경우 IP가 변경
   • 기존의 웹 서버에 배포를 하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저는 사용하지 못함

[로드밸런서를 이용한 트래픽 분산 + 고가용성 제공]

로드밸런서를 웹 서버 앞단에 두고 IP를 부여한 뒤 웹 클라이언트가 해당 로드밸런서를 호출하게 하면 아래와 같은 문제 해결가능

-> 로드밸런서는 앞단의 모든 웹 클라이언트의 요청을 받아, 뒷단의 모든 웹 서버에게 요청을 분산

1. 배포 이슈 해결: 클라이언트는 고정된 IP의 로드밸런서만 호출하기에 웹 서버가 몇개든 죽든말든 상관없음
2. 트래픽 이슈 해결: 아무리 많은 요청이 들어와도 로드밸러서 뒷단에 서버 수만 늘리면 된다(수평적 확장)

---

L1 Reverse Proxy: CDN(Contents Delivery Network)

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

캐싱: 요청에 따른 응답을 중간 저장해놓은 뒤 동일 요청 시 저장값 반환

• 원본 데이터를 가진 웹 서버에 문제가 생기면 CDN가 대신 응답을 반환하여 고가용성 보장 -> CDN: 고가용성을 보장해주는 버퍼의 역할
• 원본 데이터를 가진 웹 서버에 DDoS 공격이 가해지는 것을 CDN이 대신 방어

지역성 해결: HTTP Resource 제공 서버와 클라이언트가 멀리 떨어진 경우 클라이언트에 가가운 곳에 저장

• 한국 웹 브라우저에서 미국 웹 서버로부터 응담을 받으려면 긴 응답 시간
• 전세계적으로 캐시 서버를 곳곳에 두어 캐시 서버 내 응답 데이터를 캐싱(저장)한다면 속도 개선
• 캐시 서버로 동작하는 만큼 원 서버에 문제가 생기면 CDN 이 False Tolerance 장애 허용을 해주기도 함.