Traffic Manager "DNS 쿼리"란 무엇입니까?

사용자가 응용 프로그램에 액세스할 때마다 서비스 이름을 해당 IP 주소에 매핑하는 데 DNS 쿼리가 사용됩니다. 호스트된 여러 Azure 서비스가 동일한 데이터 센터에서 실행되는지 또는 전 세계 여러 데이터 센터에서 실행되는지에 관계없이 Traffic Manager는 여러 DNS 쿼리에 서로 다른 응답을 제공하는 방법으로 수신 트래픽을 호스트된 여러 Azure 서비스에 라우트할 수 있습니다. Traffic Manager에서는 성능, 장애 조치(Failover), 라운드 로빈이라는 3가지 트래픽 라우팅 방법을 제공합니다. 이러한 방법으로 트래픽을 효과적으로 관리함으로써 응용 프로그램의 고성능, 가용성 및 복구 기능을 보장합니다.

Traffic Manager

관련 질문과 대답

  • Traffic Manager를 사용하면 호스팅되는 Azure 서비스 엔드포인트을 모니터링하고 서비스 중단 시 자동 장애 조치(failover) 기능을 제공하여 중요 응용 프로그램의 가용성을 향상할 수 있습니다. Traffic Manager는 이를 위해 지속적으로 각 서비스 엔드포인트의 상태를 모니터링합니다. 이러한 “상태 검사”를 통해 서비스 중단이 감지되면 Traffic Manager가 트래픽 경로를 다른 서비스로 조정합니다.

  • 예, 사용되는 트래픽 라우팅 방법에 관계없이 DNS 쿼리 및 상태 검사에 대한 가격은 동일합니다.

  • 사용자의 PC에서 DNS 쿼리를 만들 때 Traffic Manager 이름 서버를 직접 연결하지 않습니다. 대신 기업 및 ISP에서 실행하는 재귀적 DNS 서버를 통해 쿼리를 전송합니다. 이러한 서버는 DNS 응답을 캐싱하므로 다른 사용자의 쿼리를 더욱 신속하게 처리할 수 있습니다. 이와 같이 캐싱된 응답은 Traffic Manager 이름 서버에 도달하지 않으므로 비용이 발생하지 않습니다. 캐싱 기간은 원래 DNS 응답의 "TTL" 매개 변수에 의해 결정됩니다. 이 매개 변수는 Traffic Manager에서 구성할 수 있으며, 기본값은 300초이고 최소값은 30초입니다. TTL 값을 크게 지정할수록 재귀적 DNS 서버의 캐싱 기간이 증가하므로 DNS 쿼리 비용을 절감할 수 있습니다. 그러나 캐싱 기간을 늘리면 사용자가 엔드포인트 상태의 변화를 신속히 파악할 수 없습니다. 예를 들어, 엔드포인트 장애 시 사용자의 장애 조치(failover) 시간이 길어집니다. 따라서 TTL 값을 너무 크게 설정하지 않는 것이 좋습니다. 마찬가지로 TTL 값을 작게 지정하면 장애 조치 시간이 단축되지만 캐싱 기간도 감소하여 트래픽 관리자 이름 서버에 대한 쿼리 수가 증가합니다. 사용자가 Traffic Manager에서 TTL 값을 구성할 수 있으므로 사용자 응용 프로그램의 비즈니스 요구에 따라 가장 적합한 TTL 시간을 선택할 수 있습니다.