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

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

업데이트 날짜: 2014년 9월

Windows Azure 트래픽 관리자

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

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

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

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

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

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

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

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

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

장애 조치 부하 분산 방법을 구성할 때는 선택한 끝점의 순서가 중요합니다. 관리 포털을 사용하면 프로필의 구성 페이지에서 장애 조치(failover) 순서를 구성할 수 있습니다.

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

트래픽 관리자 장애 조치 부하 분산

그림 1

다음 각 단계의 번호는 그림 1에 나와 있는 숫자를 나타냅니다.

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

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

  3. 트래픽 관리자는 CS-B의 도메인 이름을 클라이언트의 DNS 서버에 반환합니다. 그러면 해당 서버가 도메인 이름을 IP 주소로 확인하여 클라이언트로 보냅니다.

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

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

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

트래픽 관리자 라운드 로빈 부하 분산

그림 2

다음 각 단계의 번호는 그림 2에 나와 있는 숫자를 나타냅니다.

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

  2. 프로필에는 끝점 목록이 포함되어 있습니다. 트래픽 관리자는 이 목록에서 무작위로 끝점을 선택합니다. 이때 트래픽 관리자 끝점 모니터링을 통해 확인된 오프라인(사용 불가) 끝점은 제외합니다. 이 예제에서 해당 끝점은 CS-B입니다.

  3. 트래픽 관리자는 CS-B의 도메인 이름을 클라이언트의 DNS 서버에 반환합니다. 클라이언트의 DNS 서버는 이 도메인 이름을 IP 주소로 확인하여 클라이언트로 보냅니다.

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

라운드 로빈 부하 분산 기능은 가중치가 적용된 네트워크 트래픽 분산도 지원합니다. Figure 3에는 끝점 집합에 대한 가중치가 적용된 라운드 로빈 부하 분산 방법의 예제가 나와 있습니다.

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

그림 3

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

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

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

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

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

REST API 사용에 대한 자세한 내용은 트래픽 관리자 작업(REST API 참조)을 참조하세요.

PowerShell cmdlet 사용에 대한 자세한 내용은 Azure 트래픽 관리자 cmdlet을 참조하세요. 예제 구성은 Azure 블로그의 Azure 트래픽 관리자 외부 끝점 및 가중치가 적용된 라운드 로빈 방식과 PowerShell 사용 방식 비교를 참조하세요.

단일 클라이언트의 프로필을 테스트하고 동일하거나 가중치가 적용된 라운드 로빈 동작을 관찰하려면 프로필에서 동일하거나 가중치가 적용된 값에 따라 DNS 이름이 끝점의 다른 IP 주소로 되었는지 확인합니다. 테스트 시에는 클라이언트 쪽 DNS 캐싱을 사용하지 않도록 설정하거나 각 시도 사이에서 DNS 캐시를 지워 새 DNS 이름 쿼리가 전송되도록 해야 합니다.

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

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

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

트래픽 관리자 성능 부하 분산

그림 4

다음 각 단계의 번호는 그림 4에 나와 있는 숫자를 나타냅니다.

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

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

  3. 트래픽 관리자가 인터넷 대기 시간 테이블에서 들어오는 요청의 IP 주소에 대한 행을 찾습니다. 사용자의 로컬 DNS 서버는 반복 DNS 쿼리를 수행하여 트래픽 관리자 프로필 이름에 대해 신뢰할 수 있는 DNS 서버를 찾으므로 클라이언트 로컬 DNS 서버의 IP 주소에서 DNS 쿼리가 전송됩니다.

  4. 트래픽 관리자가 프로필에 정의된 끝점을 호스트하는 데이터 센터 중 시간이 가장 짧은 데이터 센터를 찾습니다. 이 예제에서 해당 데이터 센터는 CS-B입니다.

  5. 트래픽 관리자는 CS-B의 도메인 이름을 클라이언트의로컬 DNS 서버에 반환하며, 그러면 해당 서버가 도메인 이름을 IP 주소로 확인하여 클라이언트로 보냅니다.

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

주의 사항:

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

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

  • 인터넷 대기 시간 테이블이 업데이트될 때 끝점의 트래픽 패턴 및 로드가 전과 달라질 수 있습니다. 이러한 변화가 많으면 좋지 않습니다.

  • 성능 부하 분산 방법을 외부 끝점과 함께 사용할 때는 해당 끝점의 위치를 지정해야 합니다. 배포와 가장 가까운 Azure 지역을 선택하세요. 자세한 내용은 끝점 추가 또는 삭제를 참조하십시오.

이 항목의 그림을 트래픽 관리자 관련 프레젠테이션용 PowerPoint 슬라이드로 저장하거나 용도에 맞게 수정하려면 MSDN 설명서의 트래픽 관리자 그림을 참조하세요.

참고 항목

표시:
© 2014 Microsoft