19. 리다이렉션과 부하 균형

리다이렉션은 현대 웹에서는 피할 수 없습니다. HTTP 애플리케이션은 언제나 이 세가지를 원하기 때문입니다.

• 신뢰할 수 있는 HTTP 트랜잭션의 수행
• 지연 최소화
• 네트워크 대역폭 절약

이러한 이유때문에 웹 컨텐츠를 여러 장소에 배포해놓습니다. 그래서 이렇게 개선이 가능합니다!

• 한쪽에 이상이 생겨도 다른쪽이 커버를 할 수 있다. -> 신뢰성 개선
• 여러 장소 중 가장 가까운 리소스에 접근을 할 수 있다. -> 지연 최소화
• 목적지 서버가 분산 -> 대역폭 절약

 

하지만 컨텐츠를 마구잡이로 분산시킬 수는 없습니다. 사용률이 정말 적은곳에 많은 배포를 했다면, 나머지의 서버에 트래픽이 집중이 될 것이기 때문입니다. 이렇게 최적의 컨텐츠 분산을 찾는 부하균형과 그 컨텐츠를 찾는 최적의 방법들을 찾는 알고리즘을 리다이렉션은 굉장히 중요한 요소입니다.

 

 

리다이렉트 프로토콜

리다이렉션의 1차적인 목표는 HTTP 메시지를 최대한 빨리 보내는 것입니다. 그리고 다양한 장치들이 리다이렉션을 제공합니다.

 

 

1. 일반 리다이렉션

그림1. 일반 리다이렉션

(1) HTTP 리다이렉션

웹 서버들은 부하가 가장 적은 컨텐츠 서버를 찾아 사용자에게 그 서버로 재요청을 하라는 리다이렉트 메시지를 보낼 수 있습니다. (302 REDIRECT)

 

그림2. HTTP 리다이렉션

 

최초 요청 메시지를 받은 원 서버가 리다이렉트 메시지(302 Redirect)를 전송하면 그를 받은 클라이언트는 해당 리다이렉트 메시지의 정보를 활용해 다른 서버로 요청 메시지를 재전송합니다.

 

단점

• 어느 서버로 리다이렉트할지 결정하는 것도 상당히 많은 자원이 필요합니다. 과장해서 말하면, 그냥 컨텐츠를 제공하는 것 보다 많이 소모하는 정도.
• 메시지가 원서버 1번, 리다이렉트되는 서버 1번 총 두번을 왕복하기 때문에 대기시간이 늘어납니다.
• 리다이렉트 서버가 고장나면 사이트에도 오류가 생깁니다.

그래서 HTTP 리다이렉션은 다른 리다이렉션 기법들을 조합해서 사용합니다.

 

 

 

(2) DNS 리다이렉션

클라이언트가 웹 사이트에 접근을 시도할 때마다, 도메인명은 반드시 IP 주소로 분석되어야 합니다.(DNS)

그리고 이 DNS는 여러 알고리즘으로 도메인명에서 IP를 반환합니다.

 

a. DNS 라운드 로빈

가장 단순하고 흔한 기법입니다. DNS 호스트명 분석 기능을 사용해 웹 서버 팜 전체에 대한 균형을 유지합니다.

서버에 대한 클라이언트의 상대적인 위치나 서버의 현재 스트레스를 고려하지 않습니다.

 

 

b. 다중 주소와 라운드 로빈 주소 순환

DNS 클라이언트는 별 계산없이 주소 집합 중 첫 번째 주소를 사용하는데, 부하 균형을 위해 대부분의 DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킵니다. 이 순환을 DNS 라운드 로빈이라 부릅니다.

 

PLUS. 다른 DNS 기반 리다이렉션 알고리즘

 

 

종류	설명
부하 균형 알고리즘	웹 서버의 로드를 추적하고 가장 로드가 적은 웹 서버를 목록의 최상단에 위치시킨다
근접 라우팅 알고리즘	서버 팜이 지리적으로 분산된 경우 사용자에게 가장 가까운 웹 서버로 보낸다.
결함 마스킹 알고리즘	네트워크의 건강 상태를 모니터링해 요청을 정전이나 기타 장애를 피해 라우팅한다.

 

(3) 임의 캐스트 어드레싱

동남아시아권 국가에 여행을 가보면, 공항이나 사람들이 많이 다니는 거점에는 호객행위를 하는 택시가 정말 많습니다.

이들은 더 싼 가격에 원하는 목적지를 데려다줄 수 있다고 흥정을 하죠. 임의 캐스트 어드레싱에서 라우터도 이와 같은 역할을 합니다. 타 서버들에게 자신이 백본 라우터로 향하는 최적의 라우터라고 광고를 하는 셈입니다.

 

지리적으로 분산된 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지합니다. 그리고 이 최단거리는 아까 언급한 라우터들의 광고를 통해서 알아낼 수 있습니다.

 

백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을 때, 아이피 주소를 받아들일 수 있는 가장 가까운 라우터를 찾습니다. 

그림3. 임의 캐스트 어드레싱

임의 캐스트 어드레싱을 구현하기 위해서는 서버는 반드시 라우터의 언어로 말해야 하고, 라우터는 주소 충돌을 커버할 능력이 있어야 합니다. (라우팅 누수 발생)

 

(4) 아이피 맥 포워딩

네트워크 세그먼트의 데이터 링크 계층에서 통신을 위한 네트워크 인터페이스에 할당된 고유 식별자인 미디어 접근 컨트롤(MAC) 주소를 이용하는 방법입니다. (하드웨어의 시리얼 넘버라 생각하시면 편합니다.)

단 하나밖에 없는 유니크한 값이란 특징을 가지기 때문에, 어떤 IP 주소던 상관없이 MAC 주소만 알고있으면 원하는 목적지까지 전송(포워딩)이 가능합니다.

 

추가적으로 MAC은 유니크한 값이기 때문에 서버나 프록시는 스위치와 1:1로 배정되어 있어야 합니다.

 

 

(5) IP 주소 포워딩

아이피 맥 포워딩과 다르게 스위치가 가변하는 아이피 주소에 라우팅하는 방법입니다.

덕분에 아이피 맥 포워딩과는 다르게 1:1로 배치할 필요가 없어집니다. 그저 업스트림의 위치만 판별할 수 있으면 인터넷 라우팅이 패킷을 올바른 위치로 전송합니다. 이러한 종류의 전달을 잘 알려진 네트워크 주소 변환(NAT)이라고 합니다!

 

하지만 라우팅 대칭성을 주의해야 합니다. 요청과 응답의 이동 경로가 같아야 한다는 뜻입니다. (반드시 요청이든 응답이든 스위치를 거쳐야 한다.)

그림4. IP 주소 포워딩의 주의점

 

 

CASE1 출발 주소가 클라이언트 주소에서 스위치 주소로 변경

패킷의 출발 주소를 클라이언트에서 스위치 주소로 변경하는 방법입니다.

이렇게 되면, 응답 패킷이 스위치로 전송되게 할 수 있습니다. 또 이 스위치에서는 다시 목적지 주소를 변경해서 원 클라이언트에게 전송을 하는 것이죠.

이렇게 양방향으로 목적지를 변경할 수 있는 기능을 완전 NAT라고 합니다.

그림5. 완전 NAT

 

CASE2. 스위치로 향하는 경로 말고는 다른 경로를 모두 끊기

만약 이 스위치가 발송자를 변경할 수 있는 기능이 구현되어 있지 않다면, 스위치를 거치지 않고 클라이언트에게 향하는 경로를 모두 제거해야 합니다. 이 기능을 반 NAT(half NAT)라고 합니다.

그림6. 경로 끊기

이 기능의 단점으로 꼽자면, 네트워크 전체에 대한 통제가 있어야 한다는 점입니다.

 

 

 

2. 프록시 리다이렉션

 

그림7. 캐시와 프록시 리다이렉션

 

 

 

(1) 명시적 브라우저 설정

브라우저에서 프록시의 이름, IP주소, 포트번호를 설정할 수 있는 메뉴가 존재합니다.

 

이에 대한 단점들을 살펴봅시다.

1. 프록시가 응답을 하지 않아도 원 서버로 우회하지 않는다. 이로 인해 접속 문제를 겪을 수 있다.

 

2. 네트워크 아키텍처를 변경했을 때 모든 사용자들에게 전파가 어렵다. 사용자들이 직접 설정을 변경해야 한다.

    - 설정 자체를 사용자들이 했기 때문에 이에 대한 변화 역시 사용자들에게 책임이 있습니다.

 

 

(2) 프록시 자동 설정 (PAC: Proxy Auto-configuration)

사용자가 설정하는 것이 아닌, 각 URL별로 접촉해야 할 프록시를 지정한 PAC 파일을 찾아 그에 맞게 자동으로 설정을 하는 방법입니다. 이를 통해 동적인 변화에도 유연하게 대처를 할 수 있습니다. (단점 해결)

// PAC 파일
function FindProxyForURL(url, host)
return_value = FindProxyForURL(url_of_request, host_in_url);

브라우저는 요청하는 매 URL마다 이 함수를 호출해 반환한 값이 알려주는 곳으로 접속합니다.

 

 

(3) 웹 프록시 자동발견 프로토콜

사용자가 수동으로 프록시 설정을 할 필요도, 인터셉트에 의존할 필요도 없이 웹 브라우저가 근처의 프록시를 찾아내 사용할 수 있게 해주는 방법을 제공합니다.

 

PAC 파일 자동발견

(2)번에서 설명한 방식을 사용해서 목적지 프록시를 찾아내는 방법입니다.

WPAD 알고리즘을 이용해서 PAC 파일의 CURL을 찾습니다.

 

WPAD 알고리즘

PAC 파일 CURL을 찾기위해서 여러 가지 리소스 발견 로직들을 이용합니다. 순서는 다음과 같습니다.

1st. DHCP(Dynamic Host Configuration Protocol)

  - WPAD는 DHCP 질의를 DHCP 서버에 보내 CURL을 얻습니다.

 

2nd. SLP(Service Location Protocol)

 

3rd. DNS에게 잘 알려진 호스트명 (QNAME= 호스트명) 

  - 프록시 서버의 IP주소들이 DNS에 반드시 저장되있어야 합니다.

  - 룩업을 성공하면 URL IP 주소를 반환합니다.

 

4th. DNS의 SRV 레코드

 

5th. TXT 레코드의 DNS 서비스 URL

 

각 순서에서 성공적으로 발견이 된다면 WPAD 알고리즘은 끝이 나고 CURL을 반환합니다. 그 외에는 다음 순서로 로직이 넘어가게 됩니다. WPAD 클라이언트에게는 오직 'DHCP'와 'DNS에게 잘 알려진 호스트명' 기법만이 요구됩니다.

 

 

 

(4) 웹 캐시 조직 프로토콜

 

 

 

(5) 인터넷 캐시 프로토콜(ICP)

요청받은 컨텐츠가 자신에게 없다면, 형제 캐시에 해당 컨텐츠가 있는지 캐시 적중을 찾아볼 수 있도록 해줍니다. 

만약 형제 캐시에 해당 컨텐츠가 있다는 응답을 받으면(HIT), 원 서버에 요청하는 것 보다 비용이 더 들지 않는다 판단하고 그 캐시에서 컨텐츠를 가져옵니다. 없다면(MISS) 부모캐시에 요청합니다.

 

ICP는 이처럼 HIT, MISS 같은 짧은 응답 메시지를 받고, 커넥션을 열기 때문에 단순하고 가볍습니다.

하지만 이 메시지들은 신뢰할 수 없는 UDP를 통해 전송되기 때문에 데이터의 손실을 감지할 타임아웃이 설정되어야 합니다.

 

그림8 ICP

 

(6) 캐시 배열 라우팅 프로토콜(CARP)

프록시는 원서버에 대한 과도한 트래픽을 줄이는 기능을 하고 있지만, 사용자가 급증하는 경우 프록시에 과도한 트래픽이 집중될 수 있습니다. 이를 방지하는 방법은 전체 컨텐츠의 구역을 나누어 캐시들에게 갖게 하는 것 입니다. 이 방법이 바로 캐시 배열 라우팅 프로토콜(CARP)로 프록시의 배열이 클라이언트 시점에서 마치 하나의 캐시처럼 보이도록 관리해주는 MS와 넷스케이프 커뮤니케이션이 제안한 표준입니다.

 

그림9 CARP

다음 그림과 같이 전체 컨텐츠를 A/B/C 세 부분으로 나누고 캐시들이 나누어 가집니다.

평소에는 캐싱 프록시가 여러 형제 캐시들에게 주기적으로 폴링을 함으로써 캐시가 살아있는지 체크합니다.

만약 클라이언트가 A부분에 속하는 컨텐츠를 요청하면 A부분을 가지는 형제 캐시에만 요청을 하면 됩니다!

캐시적중 결과가 MISS가 나온다면, 부모캐시에게 최종 요청을 하면 그만입니다.

 

이렇게 여러 캐시가 유기적으로 움직어 하나의 캐시처럼 움직이는 방법은 단점도 명확합니다.

만약 컨텐츠를 수정해야 할 일이 생기면, 다른 캐시들 모두 고쳐야 한다는 점이죠.

 

(7) 하이퍼텍스트 캐싱 프로토콜(HTCP)

형제 캐시들이 모두 URL과 요청 및 응답 헤더를 사용해서 서로에게 캐시 적중 여부를 알 수 있게 함으로써 문서 정확도는 높이고, 중복되는 컨텐츠를 삭제, 필요한 컨텐츠를 추가하도록 모니터링 할 수 있게 만든 기능입니다.

이때 형제 캐시간에 주고받는 메시지 구조는 HTCP 구조로 일반적인 HTTP나 다른 구조보다 더욱 자세하게 기재되어 있습니다.