요약

  • RFC 1794는 DNS 프로토콜을 변경하지 않고 주소 순서가 서버 부하 변화에 반응하도록 만들려던 1995년의 시도를 기록하고 있습니다.
  • 권한 있는 서버가 선호 순서를 보낼 수 있었지만, 캐싱, 2차 영역 갱신, 클라이언트 측 정렬 때문에 그 순서가 특정 기기에 요청을 배정하지는 않았습니다.

순서 있는 응답은 배치가 아니었다

동등한 세 대의 서버로 해석되는 이름을 상상해 보십시오. 관리자는 가장 한가한 서버를 목록 앞에 두고 싶어할 수 있습니다. 그러나 DNS는 레코드를 제공할 뿐, 애플리케이션 연결 자체를 열지는 않습니다. RFC 1794는 이 구분을 논의의 중심에 두었습니다. 응답은 유용하고 예측 가능한 순서를 담을 수 있었지만, 프로토콜이 클라이언트가 그 순서를 유지할 것을 보장하지는 않았습니다.

이 문서는 1995년 4월에 정보성(Informational) 문서로 발표되었습니다. 인터넷 표준을 지정하지 않는다고 명시적으로 밝히고 있습니다. 역사적 자료로서의 가치는 특별히 직접적인데, 저자가 DNS 워킹 그룹 논의와 검토된 접근 방식을 기록하면서 그 역사의 일부가 누락되었을 수 있음을 경고했기 때문입니다. 따라서 이 기록은 배치된 부하 분산 시스템의 실태 조사가 아니라 설계 논쟁에 대한 증거입니다.

순환 배치에서 부하 인식 정렬로

RFC 1794는 문제의 뿌리를 1986년경, BIND에 주소 레코드 순서를 순환시키는 수정이 시작된 시점으로 봅니다. 저자는 Bryan Beecher의 “Shuffle Address” 변경과 Marshall Rose의 “Round Robin” 코드를 널리 배포된 사례로 꼽을 가능성이 있다고 언급합니다. 저자의 표현은 신중하며, 이 날짜들은 소급적으로 추정한 것으로 읽어야 합니다.

순환 배치는 시간이 지나면 첫 번째 위치가 여러 서버에 고르게 분산되지만, 서버의 실제 부하는 측정하지 않았습니다. 문서는 이를 TGV의 Matt Madison에게 귀속되는 변경과 대비하는데, 후자는 VMS 고유의 기능을 사용해 시스템 부하를 검사하고 부하가 가장 낮은 순서에서 높은 순서로 주소를 반환했습니다. 이는 호스트의 상태에 더 민감하게 반응했지만 하나의 운영체제에 의존했고 DNS 레코드 처리 방식의 변경을 요구했습니다. 두 접근은 서로 다른 한계를 드러냈습니다. 실시간 부하 정보가 없는 이식 가능한 순서이거나, 특정 플랫폼에 묶인 부하 인식 정렬이었습니다.

호환성이 움직이는 부분을 옮겼다

RFC 1794에 기록된 워킹 그룹의 기준은 까다로웠습니다. 기존 DNS와의 호환성 유지, 빈번한 변경 허용, 다중 주소 반환, 다른 레코드 유형에 대한 예측 가능한 처리, 다양한 종류의 부하 표현, 빠른 계산이 그것입니다. 5분이 일반적인 갱신 주기로 언급되었고, 60초는 가능한 속도로 상상되었을 뿐 측정된 서비스 수준으로 보고되지 않았습니다. 다중 주소는 1순위 호스트가 레코드의 TTL이 만료되기 전에 장애가 날 경우를 대비한 대안을 남기기 위한 것이었습니다.

DNS는 이미 광범위하게 설치되어 있었기 때문에 와이어 프로토콜을 변경하거나 새 레코드 유형을 추가하는 것은 매력적이지 않았습니다. 문서는 Rob Austein의 다른 제안을 전합니다. 영역 전송 프로그램을 더 똑똑하게 만들자는 것이었습니다. 프로그램이 부하 정보를 얻어 영역 데이터를 재정렬하고, DNS 메시지의 모습을 바꾸지 않은 채 이름 서버에 제공할 수 있습니다. 이 모델에서 실시간 질의 경로는 그대로 유지되면서 영역 데이터를 준비하는 과정만 동적으로 변했습니다.

그러나 이는 복잡성을 제거한 것이 아니라 옮긴 것입니다. 영역 전송은 2차 이름 서버를 갱신하며, 1차 서버는 자기 자신으로부터의 전송을 사용해 질의에 답하지 않습니다. 따라서 빠르게 변하는 하위 영역은 갱신 설정에 의존했고, 변경된 순위가 빠르게 전파되려면 리졸버에 전달되는 레코드는 짧은 TTL이 필요했습니다. 계산 역시 그 결과가 유효한 정보의 수명 안에서 끝나야 했습니다. 원천에서의 빠른 순위 계산도 캐시된 응답이 사용되는 시점에는 이미 오래되었을 수 있습니다.

최종 선택은 클라이언트에 남았다

RFC 1794는 DNS가 순서를 보장하지 않는다고 말합니다. 저자는 순서를 예측적인 것으로 묘사합니다. 클라이언트는 같은 순서를 반복해서 볼 수 있지만, 정렬 목록(sort list)을 포함해 주소를 로컬에서 재정렬할 수도 있습니다. 영역 전송 에이전트는 그런 원격 측의 선택을 예측할 수 없습니다. 여러 주소를 반환한다고 해서 클라이언트가 모두 시도할 것, 대안이 정상일 것, 애플리케이션 요청이 성공할 것을 증명하지도 않습니다.

이 에피소드는 DNS가 부하 분산기가 된 이야기라기보다, 경계가 명시적으로 드러난 이야기입니다. 운영자는 순위를 계산하고 게시하는 방식을 선택할 수 있었습니다. 2차 서버와 캐시는 그것이 얼마나 빨리 전파되는지를 좌우했습니다. 최종 선택은 클라이언트에 남았습니다. RFC 1794는 그 경계 안에서 작업하는 한 가지 방법을 기록할 뿐, 그 방법이 얼마나 널리 채택되었고 얼마나 잘 작동했는지는 확립하지 않습니다.

출처