20장 리다이렉션과 부하 균형
리다이렉션 기법들과 그것들이 어떻게 동작하며 어떤 부하 균형 능력을 갖고 있는지 알아본다
1. 왜 리다이렉트인가?
HTTP 애플리케이션이 원하는것
- 신뢰할 수 있는 HTTP 트랜잭션의 수행
- 지연 최소화
- 네트워크 대역폭 절약
리다이렉션
- 최적의분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합
2. 리다이렉트 할 곳
- 서버, 프락시, 캐시, 게이트웨이는 클라이언트에게 있어서 HTTP 요청을 보내고 그것을 처리하므로 서버라고 할 수 있다.
- 서버로의 리다이렉트는 휘발유를 찾는 운전 기사를 가장 가까운 주유소로 보내는 것이다.
- 프락시로의 리다이렉트는 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다.
3. 리다이렉션 프로토콜의 개요
- HTTP 메시지를 웹 서버로 가급적 빨리 보내는 것이 리다이렉션의 목표다.
- HTTP 메시지는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다.
- 메시지를 서버로 리다이렉트하기 위한 여러 방법들이 존재한다.
4. 일반적인 리다이렉션 방법
4.1 HTTP 리다이렉션
- 요청을 처리하는 서버는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트 한다.
- 리다이렉트를 하느 서버가 클라이언트의 아이피 주소를 아는 것은 좀 더 정보에 근거해 선택하므로 장점이다.
단점
- 어떤 서버로 리다이렉트할지 경정하려면 원 서버는 상당히 많은 처리를 해야 한다.
- 페이지에 접근할 때마다 두 번의 왕복이 필요하므로 사용자가 더 오래 기다리게 된다.
- 리다이렉트 서버가 고장나면, 사이트도 고장난다.
4.2 DNS 리다이렉션
- 클라이언트가 웹사이트에 접근하려고 시도할 때마다, 도메인 이름은 반드시 아이피 주소로 분석되어야 한다.
- DNS는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용한다.
- DNS 분석자는 여러 아이피 주소를 반환하도록 결정하는 방법은 다양하다.
- DNS 결정 알고리즘은 라운드 로빈이 가장 쉽다.
DNS 라운드 로빈
- 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트명 분석 기능을 사용한다.
- DNS 클라이언트는 다중 주소 집합의 첫 번째 주소를 사용한다.
- DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킨다.
DNS 캐싱의 효과
- DNS 룩업은 애플리케이션, 운영체제 등 DNS 서버에 의해 재사용 되어 비용을 줄이게 된다.
- 클라이언트의 수가 어느정도 이상만 된다면, 부하는 모든 서버에 잘 분산된다.
4.3 임의 캐스팅 어드레싱
- 여러개의 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의
최단거리라우팅 능력에 의지한다. - 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을때, 그 아이피 주소를 받아들일 수 잇는 가장 가까운 라우터를 찾는다.
- 서버는 반드시 라우터의 언어로 말해야하고 라우터는 일어날 수 있 는 주소 충돌을 반드시 다룰수 있어야 한다.
4.4 아이피 맥 포워딩
- HTTP 메시지는 주소가 붙은 데이터 패킷의 형태로 보내진다.
- 각 패킷은 출발지와 목적지의 아이피 주소와 TCP 포트 번호로 이루어진 레이어4 주소를 갖는다.
- 레이어2의 역할은 들어오는 특정 맥(MAC) 주소의 패킷을 받아서 나가는 특정 맥 주소로 포워딩한다.
4.5 아이피 주소 포워딩
- 스위치나 레이어4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅한다.
- 목적지 서버가 한 홉 거리에 있을 필요가 없다.
- 스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려줘야 한다.
5. 프락시 리다이렉션 방법
5.1 명시적 브라우저 설정
- 대부분의 브라우저에는 프락시 서버에 접촉하기 위한 프락시 이름, 아이피 주소, 포트번호를 설정하는 메뉴가 존재한다.
- 사용자의 설정에 따라 모든 요청에 대해 프락시와 접촉한다.
단점
- 만약 프락시가 다운되었거나 브라우저가 잘못 설정되었다면, 사용자는 접속 문제에 마주하게 된다.
- 네트워크 아키텍처를 변경했을 때 그 변경사항을 모든 최종사용자에게 전파하는것이 어렵다.
5.2 프락시 자동 설정(Proxy Auto-configuration, PAC)
브라우저가 동적으로 자신을 설정할 수 있게 하는 것이다.
PAC는 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC 파일이라 불리는 특별한 파일을 찾도록 하는것이다.
브라우저는 반드시 PAC파일을 얻기 위해 지정된 서버에 접촉하도록 설정되어 있다.
브라우저는 재시작 할 때마다 PAC 파일을 가져온다.
PAC 파일은 다음의 함수를 반드시 정의해야하는
자바스크립트파일이다.function FindProxyForURL(url, host)
5.3 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol)
- 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법을 제공해 준다.
6. 캐시 리다이렉션 방법
- 신뢰성이 높고, 고성능, 콘텐츠 지각 디스패칭이 가능하게 하여 복잡한 방법이다.
6.1 WCCP 리다이렉션
- 캐시 조직 프로토콜(WCCP)는 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고, 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다.
- WCCP 서비스 그룹을 구성하고, 어떤 트래픽이 어디로 어떻게 보내지는지, 서비스 그룹에서 부하가 캐시들 사이에서 어떻게 분산되어야 하는지 명시한다.
- HTTP 요청이 서비스 그룹의 라우터에 도착한다면, 라우터는 그 요청을 처리하기 위해 서비스 그룹의 캐시 중 하나를 선택한다.
7. 캐시 배열 라우팅 프로토콜
- 부하를 분산하기 위해 사용하는 프락시 서버를 여러대로 늘리는 것이다.
- CARP는 프락시 서버의 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해주는 표준이다.
- 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고 있는 하나의 큰 서버처럼 동작한다.
- 하나의 웹 객체는 하나의 프락시 서버에만 속하기 때문에, 프락시 서버 각각을 폴링하지 않고도 한 번의 검색으로 그 객체의 위치를 결정할 수 있다.
8. 하이퍼텍스트 캐싱 프로토콜
- HTCP는 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 질의를 할수 있도록 해줌으로써 적중이 아님에도 적중으로 잘못 처리될 확률을 줄인다.
- 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있게 해준다.
- 근처 캐시가 문서를 갖고 있다면, 요청 캐시는 그 캐시에 HTTP 커넥션은 열고 그 문서를 가져 온다.