[Network] DNS round robin

HTTP 통신에서는 폭주하는 부하를 분산하기 위해 DNS 라운드 로빈같은 로드 밸런싱 기법을 사용한다. 서버가 두 대 이상으로 로드 밸런싱이 되면 클라이언트가 이전에 접속했던 서버에 다시 접속한다고 반드시 보장할 수 없기 때문에 클라이언트가 앞서 요청을 보낸 웹 서버에 지속적으로 요청을 보낼 수 있도록 만드려면 HTTP의 쿠키(cookie)나 킵얼라이브(keep alive)라는 기술을 사용해야 한다.

 

DNS

도메인과 IP 주소 사이의 변환 기능을 해주는 것이 DNS(Domain Name System)이다.

• 정방향 조회 : 도메인으로 IP 주소를 알아내는 것
• 역방향 조회 : IP 주소를 사용해서 도메인을 알아내는 것

클라우드 환경에서는 주로 정방향 조회가 많이 사용된다.

 

DNS round robin

IP 주소를 순서대로 돌려 쓰는 것을 DNS 라운드 로빈이라고 한다.

FQDN(Fully Qualified Domain Name)과 IP 주소가 1:N 인 관계인 대규모 시스템에서 하나의 IP 주소(서버나 로드 밸런서)만으로는 제대로 대응하지 못할 수 있다. 이런 경우에는 DNS에서 FQDN에 대응하는 IP 주소를 여러 개 등록하는 방법을 쓴다. 이렇게 하면 DNS가 순차적으로 IP 주소를 돌려쓰기 때문에 하나의 서버가 모든 요청을 받는 때보다 부하를 줄일 수 있다. 이것을 DNS 라운드 로빈이라고 한다.

부하 분산을 위해 여러 서버를 사용하더라도 사용자 관점에서는 IP 주소를 변경하지 않도록 IP 주소의 변경 사실을 은폐하는 역할을 하기도 한다.

• FQDN(Fully Qualified Domain Name, 정규화된 도메인명) : 호스트명과 도메인이 하나로 연결된 전체 이름을 말한다. FQDN으로 네트워크상의 수많은 호스트들 중 원하는 하나를 지정할 수 있게 된다.

 

도메인과 IP 주소의 변환 방법

1. API를 호출하는 클라이언트에서는 스텁 리졸버(stub resolver)라는 이름 변환 요청을 대행하는 프로그램을 통해서 캐시 DNS 서버에 도메인에 해당하는 IP 주소 정보를 물어본다.
   • 있으면 바로 IP주소를 얻고 클라이언트로 반환.
2. 없다면 루트 도메인부터 시작해서 최하위 도메인까지 각 도메인 네임스페이스를 관리하는 DNS에 되물어 본다.
3. DNS 서버는 질의한 측에 하위 도메인 DNS 서버의 주소를 알려주고 하위 도메인 DNS에서 물어보게 한다.
   • 결과적으로 상위 도메인 DNS 서버는 도메인 변환 처리를 하위 도메인 DNS로 위임하고,
     질의한 측(DNS 캐시 서버)은 다시 위임 받은 하위 도메인 DNS 서버로 IP 주소 정보를 물어본다.
4. 이런 과정을 반복하여 언젠가는 요청한 도메인의 IP 주소를 알 수 있게 된다. 이 과정을 DNS 질의 혹은 DNS 쿼리(query)라고 한다.

최상위 도메인을 관리하는 루트 DNS 서버로 질의가 집중되므로 상당한 부하가 걸릴 수 있기 때문에 DNS 캐시 서버가 필요하게 되며, 실제로 부하를 상당수 경감해 주는 역할을 한다.

클라이언트에서 DNS 캐시 서버로 질의하는 것을 재귀적 질의(recursive query), DNS 캐시 서버가 루트 DNS 서버나 다른 DNS 서버로 질의하는 것을 비재귀적 질의(non-recursive query)라고 한다.

가능한 비재귀적 질의를 많이 사용하도록 만드는 것이 중요하다.

 

• DNS에서 이름 변환 기능을 제공하는 것을 리졸버(resolver)라고 하는데, 클라이언트 애플리케이션 측의 이름 변환 라이브러리를 스텁 리졸버(stub resolver), 서버 측의 이름 변환 서비스를 풀 리졸버(full resolver)라고 한다.
• 캐시 DNS 서버 : PC의 네트워크 설정에서 지정된 DNS. 로컬 네임 서버(local name server) 혹은 리커시브 네임 서버(recursive name server)라고 하기도 한다.

 

단점

1. 서버의 수 만큼 공인 IP 주소가 필요하다.
   • 부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP 가 필요합니다.
2. 균등하게 분산되지 않는다.
   • 모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이라고 하는 프록시 서버를 경유한다.
   • 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속됩니다.
   • 또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않습니다.
   • DNS 레코드의 TTL 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL 에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.
3. 서버가 다운되도 확인이 불가능하다.
   • DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없다.
   • 웹 서버의 부하가 높아서 응답이 느려지거나 접속수가 꽉 차서 접속을 처리할 수 없는 상황인 지를 전혀 감지할 수가 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공된다.
   • 이 때문에 유저들은 간혹 다운된 서버로 연결이 된다.
   • DNS 라운드 로빈은 어디까지나 부하분산을 위한 방법이지 다중화 방법은 아니므로 다른 S/W 와 조합해서 관리할 필요가 있다.

해결법

1. 다중화 구성 방식 (Synchronous Time-Division Multiplexing)
   • AP 서버에 VIP(Virtual IP)를 부여해서 다중화를 구성한다. 각 AP 서버를 Health Check후 이상이 감지되면 VIP를 정상 AP 서버로 인계하는 방식을 사용한다.
   • 즉 DNS Server Table 에 실시간으로 AP 서버의 상태를 확인할 수 있는 칼럼 및 함수를 추가하여 요청될 경우 서버 상태를 확인하여 우회 루트를 제공하거나 에러를 전송하는 방식을 말합니다.
2. 가중치 편성 방식 (Weighted round robin)
   • 각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.
3. 최소 연결 방식 (Least connection)
   • 접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

 

참고

• 그림으로 배우는 클라우드 인프라와 API 구조 3장
• http://dailusia.blog.fc2.com/blog-entry-362.html