내보내기(0) 인쇄
모두 확장

트래픽 관리자 부하 분산 방법 정보

업데이트 날짜: 2014년 5월

트래픽 관리자에는 세 가지 부하 분산 방법이 제공됩니다. 각 트래픽 관리자 프로필은 한 번에 하나의 부하 분산 방법만 사용할 수 있지만 언제든지 해당 프로필에 대해 다른 부하 분산 방법을 선택할 수 있습니다.

모든 부하 분산 방법이 모니터링에 의존하는 것을 명심해야 합니다. 트래픽 관리자 프로필을 구성하여 요구 사항에 가장 적합한 부하 분산 방법을 지정한 후 모니터링 설정을 구성합니다. 모니터링이 올바르게 구성되었으면 트래픽 관리자는 클라우드 서비스 및 웹 사이트로 구성된 끝점의 상태를 모니터링하고 사용할 수 없는 것으로 확인된 끝점에 트래픽을 보내지 않습니다. 트래픽 관리자 모니터링에 대한 자세한 내용은 트래픽 관리자 모니터링 정보를 참조하십시오. 모니터링 설정을 구성하는 방법은 트래픽 관리자 모니터링 구성을 참조하십시오.

트래픽 관리자의 3가지 부하 분산 방법은 다음과 같습니다.

  • 장애 조치: 장애 조치(Failover)는 끝점이 동일한 Azure 데이터 센터 또는 다른 데이터 센터(관리 포털에서는 지역이라고도 함)에 배치되어 있고, 기본 끝점에서 모든 트래픽을 처리하지만 기본 또는 백업 끝점을 사용할 수 없을 때를 대비해서 백업을 제공하려는 경우에 선택합니다. 자세한 내용은 장애 조치 부하 분산 방법를 참조하십시오.

  • 라운드 로빈: 라운드 로빈은 동일한 데이터 센터 또는 다른 데이터 센터에 포함되어 있는 일련의 끝점 간에 부하를 분산하려는 경우에 선택합니다. 자세한 내용은 라운드 로빈 부하 분산 방법를 참조하십시오.

  • 성능: 서로 다른 지리적 위치에 끝점이 있고 요청하는 클라이언트가 대기 시간이 가장 짧은, 가장 "가까운" 끝점을 사용하도록 하려면 성능을 선택합니다. 자세한 내용은 성능 부하 분산 방법를 참조하십시오.

Azure 웹 사이트에서는 웹 사이트 모드와 상관없이 한 데이터 센터의 웹 사이트에 대한 장애 조치 및 라운드 로빈 부하 분산 기능을 이미 제공하고 있습니다. 트래픽 관리자를 사용하면 다른 데이터 센터의 웹 사이트에 대한 장애 조치 및 라운드 로빈 부하 분산을 지정할 수 있습니다.

많은 조직들이 자사 서비스의 신뢰성을 높이기 위해 노력하고 있습니다. 그 방법은 기본 서비스가 중단될 경우에 대비하여 백업 서비스를 제공하는 것입니다. 일반적인 서비스 장애 조치 패턴으로는 동일한 끝점 집합을 제공하고 기본 서비스에 트래픽을 전송하면서 하나 이상의 백업을 준비하는 방법이 사용됩니다. 기본 서비스를 사용할 수 없는 경우 요청하는 클라이언트는 다음 순서의 서비스를 참조합니다. 목록에서 첫 번째와 두 번째 서비스를 모두 사용할 수 없는 경우 트래픽은 세 번째 서비스로 전송됩니다.

장애 조치 부하 분산 방법을 구성할 때는 선택한 끝점의 순서가 중요합니다. 기본 끝점은 목록에서 첫 번째로 표시됩니다. 관리 포털에서 빠른 생성을 사용해서 이 설정을 구성할 때는 프로필의 구성 페이지에서 장애 조치 순서를 별도로 구성해야 합니다. 빠른 생성 중에는 끝점 장애 조치 순서를 설정할 수 없습니다.

Figure 1에는 끝점 집합에 대한 장애 조치 부하 분산 방법의 예가 나와 있습니다.

장애 조치 부하 분산 흐름

그림 1

장애 조치 부하 분산의 예
다음 각 단계의 번호는 그림 1에 나와 있는 숫자를 나타냅니다.

  1. 트래픽 관리자는 DNS 서버(표시되어 있지 않음)를 통해 클라이언트로부터 들어오는 요청을 받고 프로필을 찾습니다.

  2. 프로필에는 순서별로 정렬된 끝점 목록이 포함되어 있습니다. 트래픽 관리자는 목록에서 첫 번째 끝점을 확인합니다. 지속적인 끝점 모니터링을 수행하면서 해당 끝점이 온라인이면 해당 끝점의 DNS 이름을 클라이언트에 대한 DNS 응답에 지정합니다. 해당 끝점이 사용할 수 없는 끝점인 경우 트래픽 관리자는 목록의 다음 번 온라인 끝점을 지정합니다. 이 예에서 HS-A는 사용할 수 없지만 HS-B는 사용할 수 있습니다.

  3. 트래픽 관리자는 HS-B의 도메인 이름을 클라이언트에 대한 DNS 응답에 반환합니다. 그런 다음 클라이언트는 HS-B의 도메인 이름을 해당 IP 주소로 확인합니다.

  4. 클라이언트가 HS-B에 대한 트래픽을 시작합니다.

주의 사항:

  • 트래픽 관리자 끝점 모니터링이 올바르게 구성되어야 합니다. 그렇지 않으면 항상 모든 트래픽이 기본 끝점으로 전송됩니다.

  • 프로필을 만든 다음에는 프로필에 대한 구성 페이지에서 끝점 장애 조치 순서를 지정해야 합니다.

  • DNS TTL(Time To Live)은 DNS 서버상의 DNS 클라이언트 및 확인 프로그램이 확인된 이름을 캐시할 수 있는 기간입니다. 해당 이름의 로컬 DNS 캐시 항목이 만료될 때까지는 클라이언트에서 도메인 이름을 확인할 때 지정된 끝점이 계속 사용됩니다.

일반적인 부하 분산 패턴은 동일한 끝점의 집합을 제공하고 라운드 로빈 방식으로 각 서비스에 트래픽을 보내는 것입니다. 라운드 로빈 방법은 여러 끝점에 대해 트래픽을 균등 분산합니다. 이 방법에서는 정상 상태의 끝점을 무작위로 선택하고 작동 중지된 것으로 확인된 서비스에는 트래픽을 전송하지 않습니다. 자세한 내용은 트래픽 관리자 모니터링 정보를 참조하십시오.

라운드 로빈 부하 분산 기능은 가중치가 적용된 네트워크 트래픽 분산도 지원합니다. 그렇지만 현재 가중치를 구성하려면 REST(정의 만들기 참조) 또는 Windows PowerShell(New-AzureTrafficManagerProfile 참조) 중 하나를 사용해야만 합니다.

Figure 2에는 끝점 집합에 대한 라운드 로빈 부하 분산 방법의 예가 나와 있습니다.

라운드 로빈 부하 분산 흐름

그림 2

라운드 로빈 부하 분산의 예
다음 각 단계의 번호는 그림 2에 나와 있는 숫자를 나타냅니다.

  1. 트래픽 관리자는 클라이언트로부터 들어오는 요청을 받고 프로필을 찾습니다.

  2. 프로필에는 끝점 목록이 포함되어 있습니다. 트래픽 관리자는 마지막 요청에서 참조된 끝점을 알고 있습니다. 이 예제에서는 끝점 HS-B입니다.

  3. 트래픽 관리자는 목록 내 끝점의 도메인 이름을 클라이언트에 대한 DNS 응답에 반환합니다. 이 예제에서는 끝점 HS-C입니다.

  4. 트래픽 관리자는 다시 끝점 HS-C에 마지막 트래픽이 전송되었음을 기억합니다.

  5. 클라이언트가 끝점 HS-C의 도메인 이름을 해당 IP 주소로 확인하고 트래픽을 시작합니다.

주의 사항:

  • DNS TTL(Time To Live)은 DNS 서버상의 DNS 클라이언트 및 확인 프로그램이 확인된 이름을 캐시할 수 있는 기간입니다. 해당 이름의 로컬 DNS 캐시 항목이 만료될 때까지는 클라이언트에서 도메인 이름을 확인할 때 지정된 끝점이 계속 사용됩니다. 단일 클라이언트의 프로필을 테스트하고 라운드 로빈 동작을 관찰하려면 DNS 클라이언트 항목이 제거되거나 만료된 이후의 각 요청에 대해 DNS 이름이 서로 다른 IP 주소로 확인되는지를 확인합니다.

Figure 3에는 끝점 집합에 대해 가중치가 적용된 라운드 로빈 부하 분산의 예가 나와 있습니다.

그림 3

가중치가 적용된 라운드 로빈 부하 분산의 예

가중치가 적용된 라운드 로빈 부하 분산은 각 끝점에 할당된 '가중치' 값을 토대로 다양한 끝점에 부하를 배분할 수 있게 합니다. 가중치가 커질수록 끝점이 반환되는 경우가 더 잦습니다. 이 방법이 유용할 수 있는 시나리오에는 다음 경우가 포함됩니다.

  • 응용 프로그램의 단계적 업그레이드: 새 끝점으로 라우팅하는 데 트래픽의 일부를 할당하고 트래픽을 시간 경과에 따라 단계적으로 100%로 증가시킵니다.

  • Azure로 응용 프로그램 마이그레이션: Azure 및 외부 끝점으로 프로필을 만들고 각 끝점으로 라우팅될 트래픽 가중치를 지정합니다.

  • 추가 용량을 위한 클라우드 전환: 트래픽 관리자 프로필 뒤에 둠으로써 온-프레미스 배포를 빠르게 클라우드로 확장합니다. 클라우드에 추가 용량이 필요한 경우에는 더 많은 끝점을 추가하거나 활성화하고 각 끝점으로 어느 정도의 트래픽이 향하게 할지 지정할 수 있습니다.

지금은 가중치가 적용된 부하 분산을 구성하는 데 관리 포털을 사용할 수 없습니다. Azure는 관련된 서비스 관리 REST API 및 Azure PowerShell Cmdlet을 사용하여 이 방식에 대한 프로그래밍 방식 액세스를 제공하고 있습니다. REST 작업 사용에 관한 정보는 트래픽 관리자 작업(REST API 참조)을 참조하세요. PowerShell cmdlet 사용에 관한 정보는 Azure 트래픽 관리자 Cmdlet을 참조하세요.

전 세계 각지의 다른 데이터 센터에 있는 끝점의 부하를 분산하기 위해 들어오는 트래픽을 가장 가까운 끝점(요청하는 클라이언트와 끝점 간의 대기 시간이 가장 짧음)으로 보낼 수 있습니다. 대개 “가장 가까운” 끝점은 지리적으로 거리가 가장 짧은 끝점입니다. 성능 부하 분산 방법을 사용하면 위치 및 대기 시간에 따라 트래픽을 분산할 수 있지만 네트워크 구성 또는 부하의 실시간 변경 사항은 반영되지 않습니다.

성능 부하 분산 방법은 요청하는 클라이언트의 원본을 찾고 가장 가까운 끝점에 참조합니다. 각 IP 주소별 Azure 데이터 센터 간의 왕복 시간을 보여주는 네트워크 성능 테이블에 의해 "거리"가 결정됩니다. 이 테이블은 정기적으로 업데이트되며 실시간으로 인터넷 성능을 반영하지 않습니다. 이 방법에는 특정 서비스에 대한 부하가 고려되지 않지만, 사용자가 선택한 방법에 따라 트래픽 관리자가 끝점을 모니터링하고 사용할 수 없는 끝점은 DNS 쿼리 응답에 포함하지 않습니다. 즉, 성능 부하 분산에는 장애 조치 부하 분산 방법도 포함됩니다.

Figure 4에는 끝점 집합에 대한 성능 부하 분산 방법의 예가 나와 있습니다.

성능 부하 분산 흐름

그림 4

성능 부하 분산의 예
다음 각 단계의 번호는 그림 4에 나와 있는 숫자를 나타냅니다.

  1. 트래픽 관리자는 성능 시간 테이블을 정기적으로 빌드합니다. 트래픽 관리자 인프라에서 전 세계 서로 다른 지점과 끝점을 호스팅하는 Azure 데이터 센터 사이의 왕복 시간을 확인하는 테스트를 실행합니다. 이 테스트의 실행은 Azure 시스템에서 정한 기준에 따릅니다.

  2. 트래픽 관리자가 DNS 서버를 통해 클라이언트로부터 들어오는 요청을 수신하고 프로필을 찾습니다.

  3. 트래픽 관리자가 성능 시간 테이블에서 들어오는 요청의 IP 주소에 대한 행을 찾습니다.

  4. 트래픽 관리자가 프로필에 정의된 끝점을 호스팅하는 데이터 센터에 대한 시간이 가장 짧은 데이터 센터(열)를 찾습니다. 이 예에서는 HS-D입니다.

  5. 트래픽 관리자가 HS-D의 도메인 이름을 클라이언트에 대한 DNS 응답에 반환합니다. 그런 다음 클라이언트는 HS-D의 도메인 이름을 해당 IP 주소로 확인합니다.

  6. 클라이언트가 HS-D에 대한 트래픽을 시작합니다.

주의 사항:

  • 프로필에 동일한 데이터 센터의 끝점이 여러 개 포함된 경우 해당 데이터 센터로 보내진 트래픽이 끝점 모니터링에 따라 사용 가능하고 정상 상태인 끝점에 균등하게 분산됩니다.

  • 끝점 모니터링에 따라 지정된 데이터 센터의 일부 끝점을 사용할 수 없는 경우 해당 끝점에 대한 트래픽이 가장 가까운 다음 끝점으로 전송되지 않고 프로필에 지정된 사용 가능한 다른 모든 끝점에 분산됩니다. 이는 가장 가까운 다음 끝점이 과부하 상태인 경우 발생할 수도 있는 연속 오류를 방지하는 데 도움이 됩니다.

  • 성능 테이블이 업데이트될 때 끝점의 트래픽 패턴 및 로드 정보가 전과 달라질 수 있습니다. 이러한 변화가 많으면 좋지 않습니다.

  • DNS TTL은 DNS 서버상의 DNS 클라이언트 및 확인 프로그램이 확인된 이름을 캐시할 수 있는 기간입니다. 해당 이름의 로컬 DNS 캐시 항목이 만료될 때까지는 클라이언트에서 도메인 이름을 확인할 때 지정된 끝점이 계속 사용됩니다.

  • 성능 부하 분산 방법을 외부 끝점과 함께 사용할 때는 해당 끝점의 위치를 지정해야 합니다. 배포와 가장 가까운 Azure 지역을 선택하세요.

참고 항목

표시:
© 2014 Microsoft