[3장] 1. 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

3장 첫번째, 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

1. 처리 능력이 부족하면 복수 서버로 부하 분산된다.

클라이언트로 부터 서버에 액세스가 증가할 때,유입되는 대량의 패킷을 서버의 처리 능력이 따라잡지 못할 수 있다. 이럴 경우에는 복수의 서버를 사용하여 서버 한 대당 처리량을 줄여야 하는데, 이러한 방법을 분산 처리라고 한다.

그 중 가장 간단한 방법은 단순히 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법이 있다. 그러기 위해서는 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 구조가 필요하다.

DNS 서버에 적용되고 있는 분배하는 방법이 가장 간단하다.

서버에 액세스 할 때 DNS 서버에 조회하여 IP 주소를 조사하는데 이 때, DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해놓으면 DNS서버는 조회가 있을 때마다 등록된 IP주소를 차례대로 되돌려 준다.

예를 들어보자.

www.google.co.kr

이라는 도메인에 대해

192.0.2.60

192.0.2.70

192.0.2.80

3개의 IP 주소를 대응시킨다고 했을 때, 즉, DNS 서버에 여러 대의 웹 서버를 등록해두면,

최초의 조회에는 

192.0.2.60 / 192.0.2.70 / 192.0.2.80

이라고 회답을 하고 다음 조회에는

192.0.2.70 / 192.0.2.80 / 192.0.2.60

이라고 차례로 바꿔서 회답하고 

192.0.2.80 / 192.0.2.60 / 192.0.2.70

을 회답하는 방식이다.

1주기를 순환하고 원래대로 돌아가는데 이 방법을 라운드 로빈(Round Robin)이라고 한다. 이렇게 하여 복수의 서버에 균등하게 액세스를 분산시킬 수 있다.

웹 서버가 많으면 이 중에서 고장나는 것이 존재할 수 있다. 하지만 DNS 서버는 웹 서버의 장애 여부를 확인할 수 없기 때문에 장애가 발생하여 비활성화된 웹 서버의 IP Address를 회답할 수도 있다. 그렇기 때문에 위 방식인 라운드 로빈에서 차례대로 웹 서버를 분배하면 좋지 않은 상태가 생길 수 있다. 이러한 좋지 않은 상태를 피하기 위해 부하 분산 장치 또는 로드 밸선서 등으로 부르는 기기가 고안되었다.

2. 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다.

어떻게 부하 분산 장치를 사용할 수 있을까

먼저 부하 분산 장치에 웹 서버와 같은 이름인  www.google.co.kr을 붙이고 웹 서버의 IP 주소가 아닌, 부하 분산 장치의 IP 주소를 DNS 서버에 등록한다. 그러면 클라이언트는 부하 분산 장치가 웹 서버라고 생각하여 여기에 리퀘스트 메시지를 보내게 된다. 요청을 받은 부하 분산 장치는 특정 웹 서버에 부하가 집중되지 않도록 한다.

부하 분산 장치는 어떤 근거로 웹 서버에 리퀘스트를 전송하는가 

어느 웹 서버에 리퀘스트를 전송해야할 지 판단하는 근거는 여러 가지가 존재한다.

우선, 리퀘스트가 복수의 페이지에 걸쳐있는지를 기준으로 나뉜다. 복수 페이지에 걸쳐있지 않은 단순한 액세스라면 웹 서버의 부하 상태를 근거로 리퀘스트를 전송한다. 웹 서버의 부하 상태는 시험 패킷을 웹 서버에 보내 응답 시간으로 부하를 판단하는 방법이 일반적인 방법이다.

그러나 너무 자세한 상황을 조사하려면 부하를 조사하는 동작 자체로 웹 서버에 부하가 증가해버린다. 그래서 별도의 조사 과정을 거치지 않고 미리 설정된 웹 서버의 성능 비율에 따라서 리퀘스트를 분배하는 방법도 존재한다.

리퀘스트가 복수 페이지에 걸쳐있을 때는 웹 서버의 부하와 관계없이 이전의 리퀘스트와 같은 웹 서버에 전송해야 한다.

이 기준에 대한 근거를 파악, 즉 리퀘스트가 복수 페이지에 걸쳐있는지를 판단하는 것이 요점이 되었다.

HTTP의 기본 동작은 리퀘스트 메시지를 보내기 전에 TCP 접속 동작을 하고 응답 메시지를 반송하면 연결을 끊는다. 그렇기 때문에 리퀘스트가 복수 페이지에 걸쳐있는지를 판단하기 위해서는 웹 서버측에서 정보를 유지해야 한다. 즉, 웹 서버의 부담이 높아지는 것이다.

이 부담을 줄이기 위해 액세스 동작을 중개하는 프록시를 사용하게 되면 리퀘스트의 송신처 IP 주소가 프록시의 IP 주소로 되어있어서 실제 리퀘스트를 보낸 클라이언트의 IP 주소를 알 수 없게 된다.

따라서 이 전후 관계를 판단하기 위해서 HTTP 사양을 확장하여 HTTP 헤더 필드에 부가하는 방법을 사용한다. 부하 분산 장치는 이러한 정보를 조사하여 연속된 리퀘스트라면 이전과 같은 웹 서버에 리퀘스트를 전송하고 그렇지 않으면 부하가 적은 웹 서버에 전송하도록 동작한다.

3. 캐시 서버의 이용

같은 기능을 가진 여러 대의 서버를 설치하는 것이 아니라 다른 방법으로 부하 분산을 할 수 있다. 데이터베이스 서버와 웹 서버를 나누는 것 처럼 서버의 역할에 따라 나누는 방법으로 캐시 서버를 사용할 수 있다.

캐시 서버란 프록시 구조를 사용하여 데이터를 디스크에 저장하는 서버이다. 캐시 서버는 액세스 동작을 중개할 때 웹 서버에서 받은 데이터를 디스크에 저장해두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 갖고 있다.

캐시 서버는 웹 서버로부터 받아 저장해둔 데이터를 읽기만 해서 클라이언트에 송신하므로 웹 서버에서 송신하는 것보다 빠르게 데이터를 송신할 수 있다. 단, 웹 서버에서 데이터가 변경된다면 캐시에 저장된 데이터는 쓸모없는 데이터가 된다. 그렇기 때문에 언제든지 캐시의 데이터를 이용할 수 있는 것은 아니다.

부하 분산 장치를 사용할 때와 마찬가지로, 웹 서버 대신 DNS에 캐시 서버를 등록하여 사용한다. 그리고 갱신일을 기준으로 데이터를 관리한다. 캐시 서버는 클라이언트로부터 리퀘스트 메시지를 받으면 메시지 내용을 조사하고 데이터가 자신의 캐시에 저장되어있는지 조사한다.

저장되어 있지 않은 경우에는  via라는 헤더 필드를 추가하여 웹 서버에 리퀘스트를 전송한다. via는 캐시서버를 통과했다는 것을 나타내기 위해 추가해준다. 이 때, 여러 대의 웹 서버의 데이터를 캐시 서버에서 저장하고 있을 경우에는 리퀘스트 메시지의 내용에 따라 전송 대상의 웹 서버를 판단하는 방법이 필요하다.

대표적인 방법은 리퀘스트 메시지의 URI에 쓰여있는 디렉토리를 보고 판단하는 것이다. 해당되는 웹 서버에 리퀘스트 메시지를 전송하고 그에 해당하는 응답 메시지가 되돌아 올 것이다. 이 때도 마찬가지로 via라는 헤더 필드가 부가되며 캐시 서버는 응답 메시지를 캐시에 저장하고 저장한 일시를 기록한다.

캐시에 저장된 경우에는 어떻게 하는가

이전에 액세스한 데이터가 캐시에 저장되어 있는 경우, 그 데이터를 바로 보내주면 되지만 혹시 모를 변경사항을 웹 서버에게 물어봐야 한다. 캐시 서버는 웹 서버측에 데이터가 변경되었는지 조사하기 위해 ‘If-Modified-Since’라는 헤더 필드를 추가하여 웹 서버에 전송한다.

웹 서버는  ‘If-Modified-Since’ 헤더 필드의 값과 데이터의 최종 갱신 일시를 비교하여 그에 해당하는 응답 메시지를 반송한다. 이 갱신 일시만 조사하면 되므로 데이터 송수신에서 부담이 적어진다. 변경 사항이 없다는 응답 메시지를 받은 캐시서버는 저장한 데이터를 추출하여 사용자에게 보낸다.(응답) 변경 사항이 존재하는 경우는 캐시 서버에 데이터가 저장되어있지 않은 경우와 동일하다.

3장 첫번째 The end