HTTP: 리다이렉션과 부하 균형

도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.

이번에는 리다이렉션 기법들과 해당 기법들이 부하 균형을 맞추는 방법에 대해 알아봅니다.

---

1. 왜 리다이렉트인가?

리다이렉션은 다음의 장점을 가진다.

• 신뢰성 개선 -> 한 서버에서 실패한 경우 다른 서버를 이용할 수 있기 때문에 신뢰성이 개선된다.
• 지연 최소화 -> 클라이언트가 보다 가까운 리소스에 접근할 수 있게 되기 때문에 응답시간이 줄어든다.
• 네트워크 대역폭 절약 -> 목적지 서버 분산을 통해 네트워크 대역폭을 절약한다.

리다이렉션이란 최적의 분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합이다.

대부분의 리다이렉션 장치들은 부하 균형(들어오는 메시지의 부하를 서버 집합에 분산하는 것)을 포함한다. 반대로 모든 부하 균형도 리다이렉션을 포함한다.

---

2. 리다이렉트 할 곳

우선 클라이언트가 서버, 프락시, 캐시, 게이트웨이에게 HTTP 요청을 보내고 그들이 요청을 처리한다는 관점에서 본다면, 클라이언트 입장에서 서버, 프락시, 캐시, 게이트웨이는 모두 서버이다. 때문에 많은 리다이렉션 기법이 그들 모두에서 동작하고, 일부 리다이렉션 기법만이 일부 서버에서만 동작한다.

 

웹 서버에서 서버로의 리다이렉트란 휘발유를 찾는 모든 운전기사를 가장 가까운 주유소로 보내주는 것과 같다.

프락시로의 리다이렉트는 주 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다.

---

3. 리다이렉션 프로토콜의 개요

리다이렉션의 목표는 HTTP 메시지를 사용 가능한 웹 서버로 가급적 빨리 보내는 것이다.

브라우저 설정, DNS, TCP/IP 라우팅, HTTP는 모두 메시지를 리다이렉트하는 메커니즘을 제공한다. 다만 트래픽을 보내려는 곳이 어디냐에 따라 기법의 제한이 따른다.

---

4. 일반적인 리다이렉션 방법

서버와 프락시 모두에서 공통으로 쓰이는 리다이렉션 기법에 무엇이 있을까?

 

4.1. HTTP 리다이렉션

웹 서버들이 다른 곳에 요청을 보내보라고 말해주는 짧은 리다이렉트 메시지를 클라이언트에게 돌려주는 것

• 간단하게 부하를 분산할 수 있다.
• 서버는 사용 가능한 콘텐츠 서버 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트한다.
• 서버들이 광범위하게 분산되어 있다면 최선의 가용 서버를 찾는 것이 어렵다.
• 리다이렉트를 하는 서버가 클라이언트의 아이피 주소를 알고 있기 때문에, 이 정보에 근거해 최선의 가용 서버를 찾을 수 있다.
• 서버로 향하는 요청의 방향을 변경하는 것이다.

 

단점

• 어떤 서버로 리다이렉트할지 결정하려면 원 서버가 많은 처리를 해야 한다.
• 페이지에 접근할 때마다 2번의 왕복이 필요해서, 사용자가 기다리는 시간이 늘어난다.
• 만약 리다이렉트 서버가 고장나면, 사이트 자체도 고장난다.

 

4.2. DNS 리다이렉션

DNS는 하나의 도메인에 여러 IP 주소가 결부되는 것을 허용하며, DNS 분석자는 여러 IP 주소를 반환할 수 있다. DNS 분석자가 어떤 IP 주소를 반환할 것인가를 결정하는 방식은 다음과 같다.

 

DNS 라운드 로빈

• 가장 흔하고 단순한 기법
• 웹 서버 전체에 대한 부하 균형을 유지하기 위해 DNS 호스트 명을 분석한다.
• 순수한 부하 균형 전략으로, 서버에 대한 클라이언트의 상대적인 위치, 서버의 현재 스트레스 정도를 고려하지 않는다.

 

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

대부분의 DNS 클라이언트는 그냥 다중 주소 집합의 첫 번째 주소를 사용한다. 이 기법의 경우, 룩업이 끝날 때마다 주소를 순환시킨다.

 

DNS 캐싱의 효과

DNS 주소 순환은 부하를 순환시키지만, 호스트 하나에 대해 한 번의 DNS 룩업을 수행한 뒤에는, 그 주소를 몇 번이고 다시 사용한다. 이러한 이유로 DNS 라운드 로빈은 일반적으로 하나의 클라이언트로 인한 부하는 제대로 분산하지 못한다. 그러나 여러 클라이언트의 부하 총량은 적절히 분산될 수 있다. 때문에, 비슷한 요청을 하는 클라이언트의 수가 어느 정도 이상 된다면, 부하는 모든 서버에 걸쳐 잘 분산될 수 있다.

 

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

• 부하 균형 알고리즘: 몇몇 DNS 서버는 웹 서버의 로드를 추적하고 가장 로드가 적은 웹 서버를 목록의 가장 위에 놓는다.
• 근접 라우팅 알고리즘: 웹 서버들이 지리적으로 분산되어 있는 경우, DNS 서버는 사용자를 근처의 웹 서버로 보내는 시도를 할 수 있다.
• 결함 마스킹 알고리즘: DNS 서버는 네트워크의 건강 상태를 모니터링하고 요청을 정전과 같은 장애를 피해서 라우팅할 수 있다.

 

권위 있는 서버 모델의 경우, 클라이언트가 로컬 DNS 서버에 요청을 보내고, 로컬 DNS 서버가 루트 DNS 서버로 요청을 보내 인접한 서버를 찾는 방식이다. 이 모델에는 루트 DNS가 클라이언트 IP가 아닌 로컬 DNS 서버의 IP를 통해 인접한 서버를 찾는다는 단점이 있다.

 

4.3. 임의 캐스트 어드레싱

여러 지리적으로 흩어진 웹 서버들이 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지한다.

 

4.4. 아이피 맥 포워딩

• 레이어-2 장비는 들어오는 특정 맥 주소의 패킷을 받아서 나가는 특정 맥 주소로 포워딩한다.
• 레이어-4 장비는 요청을 여러 프락시 캐시로 보낼 수 있고, 그들 사이의 부하 균형을 유지할 수 있다.
• MAC 주소 포워딩은 점 대 점으로만 가능하기 때문에, 서버나 프락시는 장비(스위치)와 한 홉 거리에 위치해야 한다.

 

4.5. 아이피 주소 포워딩

• 레이어-4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 MAC 주소가 아니라 목적지 IP 주소의 변경에 따라 라우팅한다.
• MAC 주소 포워딩과 달리, 목적지 서버와 한 홉 거리에 있을 필요가 없다.

 

4.6. 네트워크 주성요소 제어 프로토콜(NECP)

• IP 패킷을 전달하는 라우터나 스위치 같은 네트워크 구성요소들이 웹 서버나 프락시 캐시와 같이 애플리케이션 계층 요청을 처리하는 서버 구성요소들과 대화할 수 있게 해 준다.
• 명시적으로 부하 균형을 지원하지는 않는다.
• 서버 구성요소들이 네트워크 구성요소들에게 부하 균형 정보를 제공할 수 있는 방법을 제공하여, 서버 구성요소들이 적합하다고 판단한 대로 네트워크 구성요소들이 부하 균형을 유지할 수 있도록 한다.
• MAC 포워딩, GRE 캡슐화, NAT와 같은, 패킷을 전달하는 여러 가지 방법을 제공한다.

 

---

5. 프락시 리다이렉션 방법

웹브라우저와 같은 클라이언트들은 어떻게 프락시로 갈까?

 

5.1. 명시적 브라우저 설정

• 대부분의 브라우저에서는 프락시 서버에 접촉하기 위해 프락시 이름, IP 주소, 포트번호를 설정할 수 있다.
• 몇몇 서비스 제공자들은 미리 프락시 설정이 다 돼있는 브라우저를 다운로드 받도록 하기도 한다.
• 즉, 브라우저들은 접촉할 프락시의 주소를 안다.

 

단점

• 프락시를 설정하도록 설정된 브라우저들은 프락시가 응답하지 않더라도 원 서버와 접촉하지 않는다. 만약 프락시가 다운되었거나 브라우저가 잘못 설정되었다면, 사용자는 접속 문제를 경험한다.
• 네트워크 아키텍처를 변경했을 때 그 변경사항을 모든 최종사용자에게 전파하는 것이 어렵다. 만약 서비스 제공자가 더 많은 프락시를 추가하길 원하거나 몇 개를 서비스에서 제거하길 원한다면, 브라우저 사용자들은 그들의 프락시 설정을 변경해야 한다.

 

5.2. 프락시 자동 설정

• 올바른 프락시 서버에 접촉하기 위해 브라우저가 동적으로 자신을 설정할 수 있게 하는 방법
• PAC(Proxy Auto-configuration)이라고 한다.
• 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC 파일을 찾는다. 브라우저는 반드시 PAC 파일을 얻기 위해 지정된 서버에 접촉하도록 설정된다. 브라우저는 재시작할 때마다 PAC 파일을 가져온다.
• 프락시의 위치가 변경된 경우 이를 반영하기 위해 PAC 파일이 서버에서 업데이트된다. 때문에 PAC은 브라우저가 자동으로 네트워크 아키텍처 안에서의 변경에 맞는 올바른 프락시에 접촉할 수 있도록 해줄 수 있다.

 

5.3. 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol)

• 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법을 제공한다.
• 선택할 수 있는 발견된 프로토콜이 여러 가지 존재한다는 것과 프락시 사용에 대한 설정이 브라우저들마다 차이가 있기 때문에 문제가 복잡해진다.

---

6. 캐시 리다이렉션 방법

6.1. WCCP 리다이렉션

라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다.

 

---

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

• 캐시들이 형제 캐시에서 일어난 캐시 적중을 찾아볼 수 있도록 해준다.
• 만약 캐시가 HTTP 메시지에서 요청한 콘텐츠를 갖고 있지 않다면, 캐시는 근처의 형제 캐시 중 그 콘텐츠를 가지고 있는 것이 있는지 찾아보고 만약 있다면 원 서버에 질의하는 것보다 비용이 더 들지 않을 것을 기대하며 그 캐시에서 콘텐츠를 가져온다.
• 한 차례 이상의 ICP 질의를 통해 HTTP 요청 메시지의 최종 목적지를 결정할 수 있다는 점에서, ICP는 리다이렉션 프로토콜이다.
• 캐시는 ICP를 사용해 근처의 캐시 모두에게 특정 URL을 갖고 있는지 한번에 물어본다. 때문에 ICP는 객체 발견 프로토콜이다.
• ICP 메시지는 파싱하기 쉽도록 네트워크 바이트 순서에 따라 32비트 크기로 맞춰진 구조체이다. 때문에 단순하고 가볍다.

---

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

• 프락시 서버의 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해준다.
• CARP를 통해 프락시 서버에 가해지는 부하를 프락시 서버를 여러 대로 늘려 분산할 수 있다.
• CARP 프로토콜은 협력은 하지만 분산된 캐시가 되는 ICP와 달리, 프락시 서버 그룹을 하나의 캐시 집단으로 보이게 해준다. 이로 인해 자주 생성되는 프락시 간 트래픽이 제거되고, 중복된 웹 캐시에 대한 사본의 중복을 피할 수 있다. 이는 결과적으로 캐시 시스템이 웹 객체를 더 많이 보관할 수 있다는 장점과, 하나의 프락시가 실패하면 상당량의 캐시 콘텐츠를 재배치해야 한다는 단점을 가진다.

---

9. 하이퍼텍스트 캐싱 프로토콜

• 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 질의를 할 수 있도록 한다.
• 적중이 아님에도 적중으로 잘못 처리될 확률을 줄인다.
• 형제 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있다.
• 형제 캐시들이 서로의 캐시된 문서에 대한 캐싱 정책을 변경할 수 있게 해준다.

 

---