다음을 통해 공유

Azure Traffic Manager의 Well-Architected 프레임워크 관점

  • 아티클

Azure Traffic Manager는 여러 Azure 지역, 지역 내 영역 또는 해당 영역 내의 데이터 센터에 트래픽을 분산할 수 있는 글로벌 부하 분산 장치입니다. DNS(도메인 이름 시스템) 프로토콜을 사용하여 클라이언트와 워크로드의 엔드포인트 간에 통신 경로를 설정합니다. 연결이 설정되면 클라이언트는 Traffic Manager의 도움 없이 엔드포인트에 직접 연결할 수 있습니다.

이 문서에서는 설계자로서 Azure 부하 분산 옵션을 검토하고 활성-활성 또는 활성-수동 모델의 여러 지역에 배포되는 워크로드에 대해 Azure Traffic Manager를 선택했다고 가정합니다. 이 문서의 지침은 Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.

중요하다

이 가이드를 사용하는 방법

각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록 있습니다.

또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 Traffic Manager 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.

기본 아키텍처 는 주요 권장 사항을 보여 주며, Traffic Manager, Azure Firewall 및 Application Gateway를 사용하여 다중 리전 부하 분산을 수행합니다.

기술 범위

이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.

  • 교통 관리자

Azure Traffic Manager를 사용한 장애 조치(failover) 시나리오를 보여 주는 다이어그램

메모

HTTP 애플리케이션을 호스트하는 워크로드의 경우 Azure Front Door는 콘텐츠 배달 네트워크, TLS(전송 계층 보안) 종료 및 통합 방화벽과 같은 기능 때문에 자연스럽게 선택됩니다.

Azure Front Door에 비해 Traffic Manager는 설정, 구성 및 유지 관리가 더 쉽습니다. Traffic Manager에는 직접 제어할 수 있는 엔드포인트가 없습니다. 클라이언트 요청을 처리하는 Front Door와 달리 Traffic Manager는 클라이언트를 워크로드의 엔드포인트에만 연결합니다.

그러나 이러한 단순성은 아키텍처의 복잡성을 도입할 수 있는 절충과 함께 제공됩니다. 예를 들어 OWASP(Open Worldwide Application Security Project) 공격 유형을 차단하기 위해 추가 보안 조치를 구현해야 할 수 있습니다. Azure Front Door 또는 Azure Application Gateway의 WAF(웹 애플리케이션 방화벽)는 이 기능을 제공합니다. 또는 캐시를 추가하여 콘텐츠 배달 속도를 높일 수 있지만 데이터 저장소를 관리해야 하므로 복잡성이 더해질 수 있습니다.

자세한 내용은 Azure Front Door의 Well-Architected Framework 관점을 참조하세요.

신뢰도

안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을 지속적인 기능을 제공하는 것입니다.

안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공할 있습니다.

디자인 검사 목록

안정성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. 애플리케이션의 특성과 구성 요소의 중요도를 염두에 두고 비즈니스 요구 사항과 관련성을 결정합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • 잠재적인 실패를 고려합니다. Traffic Manager는 복원력이 있도록 설계되었습니다. 그러나 워크로드에 대한 단일 실패 지점이 될 수 있습니다. 이 위험을 완화하려면 Traffic Manager를 사용할 수 없는 경우 활성화되는 대체 서비스에 대한 보조 경로를 정의합니다. 라우팅 문제를 방지하려면 Traffic Manager와 대체 서비스를 함께 사용하지 마세요.

  • SLA(서비스 수준 계약) 적용 범위를 잘 이해합니다. Traffic Manager SLA을 평가할 때, 게시된 백분위수와 관련된 적용 범위를 이해합니다. 예를 들어 DNS 조회가 여러 번 실패할 수 있습니다. 이러한 오류는 1분 동안 연속 DNS 조회 오류가 발생할 때까지 가동 중지 시간으로 간주되지 않습니다.

  • 워크로드 아키텍처에 중복성을 통합합니다. 서비스가 공용 IP 주소를 통해 노출되는 경우 Traffic Manager를 사용하여 Azure 지역, 온-프레미스 및 기타 클라우드에서 중복성을 구현합니다. 예를 들어 클라우드에 보조 인스턴스가 있는 온-프레미스 애플리케이션이 있을 수 있습니다. 온-프레미스 시스템이 실패하면 클라우드 인스턴스가 활성화되어 연속성을 보장할 수 있습니다.

  • 신뢰할 수 있는 배포 아키텍처를 사용하여 중복성을 지원합니다. 부하 분산 장치인 Traffic Manager는 라우팅 방법을 구성하는 방법에 따라 워크로드 엔드포인트 간에 트래픽을 분산합니다. Traffic Manager 프로필에서 이 구성을 정의합니다. 프로필은 배포 전략의 핵심 구성 요소입니다. 적절한 프로필 구성을 사용하여 활성-활성 모델 또는 대기 예비가 있는 활성-수동 모델을 구현할 수 있습니다.

    각 프로필은 단일 트래픽 라우팅 방법을 지정합니다. 일부 시나리오에서는 보다 정교한 트래픽 라우팅이 필요합니다. Traffic Manager 프로필을 결합하여 둘 이상의 트래픽 라우팅 방법을 활용할 수 있습니다.

    자세한 내용은 Traffic Manager 라우팅 방법을 참조하세요.

  • DNS 응답의 캐싱 기간을 평가합니다. Traffic Manager의 DNS 조회에 대한 TTL(Time-to-Live) 설정은 다운스트림 DNS 확인자가 DNS 응답을 캐시하는 기간을 결정합니다. 기본 TTL은 필요 이상으로 캐싱 시간이 길어질 수 있으며, 엔드포인트가 실패할 경우 가동 중지 시간이 발생할 수 있습니다. TTL을 줄여 캐시 업데이트 빈도를 늘립니다. 이 메서드는 가동 중지 시간을 완화하는 데 도움이 되지만 DNS 조회 빈도를 증가시킬 수 있습니다.

  • 비정상 또는 손상된 인스턴스로 트래픽을 보내지 않도록 합니다. Traffic Manager에서 기본 제공 상태 검색 기능을 검토합니다.

    HTTPS 및 HTTP 애플리케이션의 경우 상태 엔드포인트 모니터링 패턴을 구현하여 애플리케이션 내에서 사용자 지정 페이지를 제공합니다. 특정 검사에 따라 페이지는 적절한 HTTPS 상태 코드를 반환합니다. 엔드포인트의 가용성 외에도 상태 검사는 애플리케이션의 모든 종속성을 모니터링해야 합니다.

    다른 애플리케이션의 경우 Traffic Manager는 TCP(Transmission Control Protocol)를 사용하여 엔드포인트의 가용성을 확인합니다.

    자세한 내용은 건강 엔드포인트 모니터링 패턴 및 Traffic Manager 프로브이해하기를 참조하세요.

  • 가동 중단 허용 범위를 결정합니다. 백 엔드를 사용할 수 없게 되면 Traffic Manager가 오류를 인식하고 트래픽을 사용할 수 없는 엔드포인트로의 전송을 중지하기까지 시간이 경과할 수 있습니다. 클라이언트 요청을 처리할 수 없는 기간이 있습니다. 이 허용 오차를 사용하여 비즈니스 연속성 작업을 얼마나 빨리 시작할지 결정하는 프로브 설정을 구성합니다.

  • 복원력 테스트의 일부로 엔드포인트를 포함합니다. Traffic Manager에서 오류를 처리하는 방법을 확인하기 위해 사용할 수 없는 엔드포인트를 시뮬레이션합니다. 워크로드가 프라이빗 가상 네트워크에서 Application Gateway와 같은 부하 분산 장치를 사용한다고 가정합니다. Azure Chaos Studio에서 NSG(네트워크 보안 그룹) 규칙을 사용하여 엔드포인트의 오류를 시뮬레이션할 수 있습니다. Application Gateway가 있는 서브넷에 대한 액세스를 차단할 수 있습니다.

권장 사항

추천 이익
Traffic Manager 프로필에 여러 엔드포인트 배포하고 사용하도록 설정합니다. 엔드포인트를 사용하도록 설정하지 않으면 상태 검사를 수행하지 않으며 트래픽 라우팅에 포함되지 않습니다. 이러한 엔드포인트를 다른 지역에 배치합니다. 중복 인스턴스는 하나의 엔드포인트가 실패할 경우 가용성을 보장하는 데 도움이 됩니다.
다양한 트래픽 라우팅 방법을평가합니다. 배포 전략에 맞게 방법 중 하나 또는 조합을 구성합니다. Traffic Manager는 선택한 메서드를 각 DNS 쿼리에 적용하고 이 메서드를 사용하여 DNS 응답에서 반환되는 엔드포인트를 결정합니다.

- 가중치 메서드 구성된 가중치 계수에 따라 트래픽을 분산합니다. 이 메서드는 활성-활성 모델을 지원합니다.
- 우선 순위 기반 메서드 트래픽을 수신하고 보조 지역에 백업으로 보내도록 주 지역을 구성합니다. 이 메서드는 활성-수동 모델을 지원합니다.
- 지리적 방법 DNS 쿼리의 지리적 원본을 기반으로 트래픽을 라우팅합니다. 모든 지역을 포함하려면 All(World) 속성을 사용하여 하나 이상의 엔드포인트를 구성합니다.		 최적화된 라우팅 방법을 사용하면 엔드포인트 간에 트래픽을 효율적으로 분산할 수 있습니다.

활성-활성 또는 활성-수동 배포 모델 목표를 지원할 수 있습니다. 효율적인 라우팅 방법을 사용하면 보조 지역에서 트래픽을 처리하거나 백업 역할을 할 수 있습니다.

지리적 라우팅은 위치를 기준으로 사용자를 가장 가까운 엔드포인트로 안내하는 데 도움이 됩니다. 트래픽이 효율적으로 관리되고 손실되지 않도록 하는 데 도움이 됩니다.
DNS TTL 간격 기간을 60초 미만의 낮은 값으로 설정합니다. 성능을 최적화하려면 상태 프로브 타이밍 및 DNS 레코드 TTL을 조정합니다. TTL 기간이 낮으면 다운스트림 DNS 확인자 캐시 업데이트가 더 빈번하고 더 빠른 장애 조치(failover)가 보장됩니다. 또한 가동 중지 시간을 최소화하고 애플리케이션의 전반적인 응답성을 향상시킵니다.
엔드포인트 을 모니터링하기 위한 상태 프로브을 설정합니다.

- 엔드포인트 모니터링을 사용하지 않도록 설정하고 상태와 관계없이 엔드포인트에 요청을 보내는 AlwaysServe사용하도록 설정하지 마세요.
- probing interval 값을 설정합니다. 오류를 감지할 수 있는 속도와 엔드포인트에 대한 요청 수 간의 절충을 고려합니다. Traffic Manager는 다양한 위치에서 동시에 ping하는 글로벌 서비스이므로 요청 수가 상당히 많을 수 있습니다.
- probe timeout 값을 설정합니다. 엔드포인트를 비정상 상태로 선언하기 전에 대기할 시간을 고려하세요. 실패 수에 오탐을 포함하세요.		 상태 프로브는 정상 인스턴스만 사용자 요청을 처리합니다. 또한 오류가 비전환적인지 여부와 장애 조치(failover) 작업이 얼마나 빨리 수행되어야 하는지를 결정하는 데 도움이 됩니다.

안전

보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보증을 제공하는 것입니다.

보안 디자인 원칙은 Traffic Manager의 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.

디자인 검사 목록

  • 보안 기준을 검토합니다. 보안 태세를 향상하려면 Traffic Manager 대한보안 기준을 검토합니다.

  • 트래픽 라우팅의 무단 수정을 방지합니다. Traffic Manager 프로필은 트래픽 라우팅에 대한 구성 설정을 포함하므로 중요한 워크로드 리소스로 처리합니다. 권한 있는 ID만 이러한 프로필에 액세스할 수 있어야 합니다. 컨트롤 플레인에서 RBAC(역할 기반 액세스 제어) 구현하여 리소스 만들기, 삭제 또는 수정과 같은 작업을 제한합니다. 권한 있는 ID만 엔드포인트를 사용하거나 사용하지 않도록 설정할 권한이 있어야 합니다. 무단 액세스로 인해 구성이 변경되고 잠재적으로 트래픽을 악의적인 구현으로 다시 라우팅할 수 있습니다.

  • 네트워크 에지의 위협으로부터 애플리케이션을 보호합니다. Traffic Manager는 WAF와 같은 기본 제공 보안 기능을 제공하지 않습니다. HTTP 애플리케이션을 보호하려면 엔드포인트 수준에서 트래픽 검사를 구현해야 합니다.

    일반적인 아키텍처에는 Traffic Manager 및 여러 엔드포인트가 포함될 수 있습니다. 각 엔드포인트에 대해 TLS 종료 및 기타 보안 기능을 처리하는 애플리케이션 게이트웨이가 보호를 제공합니다. 해당 패턴을 보여 주는 참조 아키텍처는 Traffic Manager, Azure Firewall 및 Application Gateway Multiregion 부하 분산을 참조하세요.

  • DNS 기록을 강화하십시오. Traffic Manager는 DNS 데이터를 조작하는 공격에 취약할 수 있으며, 트래픽을 악성 사이트로 리디렉션하고 보안 문제를 일으킬 수 있습니다. 일반적인 위협은 DNS 레코드가 프로비전 해제된 Azure 리소스를 가리키는 하위 도메인 인수입니다. 하위 도메인 인수를 방지하려면 Azure DNS 별칭 레코드를 사용하고 DNS 레코드의 수명 주기를 Azure 리소스와 결합합니다.

    자세한 내용은 DNS 항목 현수 방지를 참조하십시오.

권장 사항

추천 이익
워크로드 엔드포인트애플리케이션 게이트웨이를 추가합니다.

HTTP 애플리케이션에 대한 방화벽을 사용하여 보안 검사를 구현하려면 워크로드 엔드포인트에 애플리케이션 게이트웨이를 추가합니다.		 인바운드 HTTP 트래픽을 검사하여 일반적인 공격으로부터 애플리케이션을 보호할 수 있습니다.
Traffic Manager 프로필을 참조하기 위해 워크로드의 apex 도메인 이름에 대한 별칭 레코드 Azure DNS에 만듭니다. 별칭 레코드는 DNS 레코드의 수명 주기를 Azure 리소스와 긴밀하게 결합합니다. 이 구성은 워크로드가 사용 중지되는 경우 비활성 참조를 방지하는 데 도움이 됩니다. Traffic Manager 프로필이 삭제되면 DNS 별칭 레코드가 빈 레코드 집합이 됩니다. 더 이상 삭제된 리소스를 참조하지 않습니다.

비용 최적화

비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하면서 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.

비용 최적화 디자인 원칙은 Traffic Manager 및 해당 환경과 관련된 기술 설계에서 필요할 경우 목표를 달성하고 절충안을 마련하기 위한 고수준의 디자인 전략을 제공합니다.

디자인 검사 목록

디자인 검토 검사 목록을 기반으로 한 비용 최적화을 위한 투자 디자인 전략을 시작하십시오. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.

  • 기능 비용을 평가합니다. 트래픽 보기 대시보드 기능은 클라이언트가 연결하는 위치와 연결된 대기 시간을 보여 줍니다. 이 정보는 성능을 최적화하고 설계를 구체화하여 운영 우수성과 시스템 효율성에 기여합니다. 그러나 추가 비용이 발생합니다. 자세한 내용은 트래픽 보기 청구참조하세요.

    건강 프로브와 관련된 비용도 고려합니다. Traffic Manager는 다양한 위치에서 정의된 엔드포인트를 ping하여 가용성을 확인합니다. 느린 ping 및 빠른 ping을 선택할 수 있습니다. 빠른 ping은 오류를 더 빠르게 감지하지만 비용이 더 많이 듭니다. 또한 상태 검사가 더 빈번하기 때문에 워크로드에 더 많은 부하를 추가합니다.

  • 라우팅 전략의 비용을 평가합니다. 예를 들어 대부분의 클라이언트가 대기 시간이 긴 지역에서 엔드포인트에 액세스하는 경우 해당 사용자에게 더 가까운 다른 엔드포인트를 만들고 Traffic Manager에서 라우팅 방법을 조정할 수 있습니다. 이 방법은 대기 시간을 줄여 더 적은 용량으로 더 많은 요청을 처리할 수 있으므로 비용을 절감할 수 있습니다.

권장 사항

추천 이익
가격 계산기 사용하여 Traffic Manager 기능의 비용을 예측합니다. 필요한 경우 보다 정확한 비용 모델을 사용하고 리소스에 대한 거버넌스를 설정할 수 있습니다.
최적화 작업 중에 트래픽 보기 대시보드 사용하도록 설정합니다. 이 기능을 사용하면 사용 패턴을 더 잘 이해할 수 있습니다. 성능 튜닝을 위해 이 데이터를 사용하여 워크로드 목표에 도달하세요.

적시에 기능을 사용하도록 설정하고 적절한 계층을 적용하여 리소스가 부족하지 않도록 합니다.
복구 메트릭에 따라 상태 프로브에 대해 빠르고 느린 ping 중에서 선택합니다.

빠른 ping은 오류를 더 빨리 감지하지만 비용이 더 많이 듭니다. ping이 느린 경우, 속도는 느리지만 비용이 적게 듭니다.

ping을 사용하지 않도록 설정하지 마세요.		 비용을 최적화하고 워크로드 엔드포인트의 부하를 줄이기 위해 Ping 빈도를 줄입니다.

운영 우수성

운영 우수성은 주로 개발 사례, 관찰 가능성 및 릴리스 관리를 절차에 중점을 둡니다.

운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항을 충족하기 위한 목표 달성을 위해 높은 수준의 디자인 전략을 제공합니다.

디자인 검사 목록

  • 워크로드 모니터링의 일부로 운영 데이터를 수집하고 분석합니다. 관련 Traffic Manager 로그 및 메트릭을 캡처합니다. 이 데이터를 사용하여 트래픽 동작 문제를 해결하고, 이해하고, 라우팅 논리를 미세 조정합니다.

  • 프로필의 트래픽 데이터를 봅니다. 이 데이터는 대기 시간이 긴 지역에서 Azure 현재 상태를 확장하는 등 개선 영역을 정확히 파악하는 데 도움이 됩니다. 또한 투자를 늘리거나 줄일 위치를 결정하는 데 도움이 되는 다양한 지역의 트래픽 패턴을 강조 표시합니다.

  • 재해 복구 작업구현합니다. 재해 복구 구현은 주 사이트에서 백업 사이트로 네트워크/웹 트래픽의 경로를 다시 지정하도록 설계할 수 있습니다. 이 재해 복구 방법은 Azure DNS 및 AZURE TRAFFIC Manager(DNS)를 사용하여 구현할 수 있습니다. 재해가 발생할 경우 기본 엔드포인트의 성능이 저하되면 Traffic Manager는 트래픽을 정상 보조 엔드포인트로 리디렉션합니다. 기본적으로 Traffic Manager는 기본 엔드포인트에 우선 순위를 부여하지만 트래픽 부하를 분산하기 위해 추가 장애 조치(failover) 엔드포인트 또는 부하 분산 장치로 설정할 수도 있습니다. 자세한 내용은 재해 복구 및 중단 탐지설정을 참조하세요.

  • 자동 장애 복구(failback) 작업을 피합니다. 장애 복구(failback)를 수행할 때는 자동 장애 복구(failback)를 사용하지 마세요. 이 장애 복구는 사용 가능한 경우 주 엔드포인트의 원래 엔드포인트로 즉시 다시 전환됩니다. 대신 원래 엔드포인트를 사용하지 않도록 설정하고 전환할 때까지 보조 엔드포인트를 사용합니다. 이 방법은 안정화를 위한 시간을 제공합니다. 즉시 장애 복구(failback)를 수행하면 추가 로드 및 지연이 발생할 수 있습니다.

    자세한 내용은 멀티리전 부하 분산 아키텍처을 참조하세요.

  • 구성 설정을 테스트합니다. 잘못된 구성은 워크로드의 모든 측면, 특히 안정성에 영향을 줄 수 있습니다. 다양한 위치에서 여러 클라이언트를 사용하여 구성을 테스트합니다. 더 많은 정보는 Traffic Manager 설정을 확인하세요를 참조하십시오.

권장 사항

추천 이익
Traffic Manager 프로필에 대한 진단 로그 사용하도록 설정합니다.

도구 사용하여 로그를 재생하고 상태 검사 데이터를 분석합니다.		 진단 로그는 Traffic Manager 프로필의 동작에 대한 인사이트를 제공합니다. 예를 들어 엔드포인트에 대한 개별 프로브 시간 제한의 이유를 식별할 수 있습니다.
트래픽 보기 대시보드사용하도록 설정합니다. 클라이언트가 연결하는 위치와 연결된 대기 시간에 대한 인사이트를 가져옵니다. 이 정보는 디자인을 구체화할 수 있으므로 성능 및 비용을 최적화하는 데 도움이 됩니다.
클라이언트 위치 및 대기 시간에 대한 데이터를 제공하는 열 지도 REST API활용합니다. 이 방법은 특정 기간 설정과 같은 유연성을 제공합니다. 사용자 지정 도구 또는 대시보드에 데이터를 추가할 수 있습니다. 이 API를 사용하여 외부 도구와 통합할 수도 있습니다.
운영 작업엔드포인트를 사용하지 않도록 설정합니다. 예를 들어 장애 조치(failover) 후 장애 복구(failback)를 사용하지 않도록 설정하여 유지 관리 또는 테스트를 수행할 수 있습니다. 부하 분산 장치에서 엔드포인트를 사용하지 않도록 설정하면 실시간 트래픽을 중지할 수 없으므로 운영 작업에 유용합니다. 유지 관리 중에 엔드포인트를 사용하지 않도록 설정하면 인스턴스가 트래픽을 수신하지 않습니다. 이 접근법은 자동 복구를 방지합니다.

성능 효율성

성능 효율성은 용량을 관리하여 부하 증가하는 경우에도 사용자 환경을 유지 관리합니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.

성능 효율성 디자인 원칙은 예상 사용량에 대해 이러한 용량 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.

디자인 검사 목록

성능 효율성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. Traffic Manager의 주요 성능 지표를 기반으로 하는 기준을 정의합니다.

  • 구성의 성능 영향을 측정합니다. Traffic Manager는 클라이언트와 엔드포인트 간의 직접 연결을 방해하지 않습니다. 주요 성능 영향은 초기 DNS 조회입니다. TTL 설정은 이 조회가 발생하는 빈도에 영향을 줍니다. TTL이 낮을수록 DNS 확인이 더 자주 실행되므로 성능에 약간 영향을 줄 수 있습니다. TTL을 0으로 설정하면 모든 요청에는 DNS 조회가 필요하므로 엔드포인트에 액세스하기 전에 약간의 지연이 추가됩니다.

    Traffic Manager는 DNS 수준에서 작동하므로 세션 선호도를 지원하지 않습니다. Traffic Manager는 각 호출에 대해 사용자를 다른 엔드포인트로 보낼 수 있습니다. 세션 선호도가 필요한 경우 상태를 별도의 데이터 저장소에 유지해야 합니다.

    자세한 내용은 Traffic Manager 대한성능 고려 사항을 참조하세요.

  • 트래픽 라우팅 동작을 조정하여 성능을 최적화합니다. 단일 프로필에는 여러 엔드포인트가 있을 수 있지만 한 번에 하나의 라우팅 방법만 적용할 수 있습니다.

    더 복잡한 시나리오의 경우 다양한 라우팅 방법을 결합하는 프로필 계층 구조를 만드는 것이 좋습니다. 예를 들어 지역 우선 순위를 지정한 다음 지역 내에서 성능 기반 라우팅을 사용할 수 있습니다.

권장 사항

추천 이익
서로 다른 지리적 위치에 엔드포인트가 있는 경우 성능 라우팅 방법을 사용합니다. 이 메서드는 대기 시간이 가장 짧은 엔드포인트로 트래픽을 보내는 우선 순위를 지정합니다. 이 방법은 사용자를 위한 빠른 서비스를 보장하는 데 도움이 됩니다.
특수 도구를 사용하여 성능을 최적화합니다. DNS 조회의 성능을 측정합니다 . 트래픽 성능을 분석하려면 트래픽 보기 대시보드 또는 열 지도 REST API사용합니다. DNS 대기 시간 측정 도구는 전체 DNS 조회를 수행하고 성능 데이터를 제공합니다. 이 데이터를 사용하여 TTL 기간을 설정하고 성능을 최적화할 수 있습니다.
최적의 성능을 위해 워크로드 요구 사항에 따라 트래픽 방법을 계층 구조로 된 프로필과 결합합니다. 최적화된 라우팅 방법을 사용하면 트래픽이 가장 응답성이 뛰어나고 가장 가까운 엔드포인트로 전송되도록 할 수 있습니다. 이 방법은 애플리케이션 성능 및 사용자 환경을 개선하는 데 도움이 됩니다.
실제 사용자 측정 기능 사용하여 Azure 지역에 대한 네트워크 대기 시간 측정값을 봅니다. 이 기능은 추가 비용 없이 사용할 수 있습니다. 데이터 기반 라우팅을 결정하여 가장 낮은 대기 시간을 제공하는 Azure 지역으로 쿼리를 보낼 수 있습니다.
DNS TTL 간격 더 높은 값으로 설정합니다. 클라이언트는 더 긴 시간 동안 결과를 캐시할 수 있으므로 매번 DNS를 확인할 필요가 줄어듭니다.

Azure 정책

Azure는 Traffic Manager 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 이전 권장 사항 중 일부는 Azure Policy를 통해 감사할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.

  • 리소스 로그를 사용하여 활동을 추적할 수 있습니다.
  • Traffic Manager 프로필에 대한 로그는 Azure Event Hubs로 전송됩니다.

포괄적인 거버넌스를 위해 Azure 네트워킹 서비스 대한Azure Policy 기본 제공 정의를 검토합니다.

Azure Advisor 권장 사항

Azure Advisor 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 맞춤형 클라우드 컨설턴트입니다. 다음은 웹 애플리케이션 인스턴스의 안정성, 보안, 비용 효율성, 성능 및 운영 우수성을 개선하는 데 도움이 되는 몇 가지 권장 사항입니다.

장단점

기둥 검사 목록의 접근 방식을 사용하는 경우 디자인 측면에서 타협이 필요할 수 있습니다. 다음은 장점과 단점의 몇 가지 예입니다.

안정성 및 성능 효율성

  • DNS 조회에 대한 TTL 설정입니다. 기본 TTL 설정으로 인해 캐싱 시간이 길어질 수 있습니다. 애플리케이션이 TTL 기간 동안 실패한 엔드포인트에 대한 연결을 계속 시도하기 때문에 엔드포인트가 실패하는 경우 캐싱 시간이 길어지면 가동 중지 시간이 발생할 수 있습니다.

    이 문제를 완화할 수 있도록 TTL을 줄입니다. TTL이 낮을수록 업데이트가 더 빈번하고 장애 조치(failover)가 더 빨라지지만 DNS 조회 빈도가 증가합니다. 이 방법은 성능에 영향을 미치고 DNS 서버의 부하를 증가시킬 수 있습니다.

안정성 및 비용 최적화

  • 헬스 프로브. Traffic Manager는 상태 프로브를 사용하여 다양한 위치에서 엔드포인트를 ping하여 가용성을 확인합니다. 느린 ping 또는 빠른 ping을 선택할 수 있습니다. 빠른 ping은 오류를 더 빠르게 감지하지만 비용을 추가합니다. 느린 ping은 오류를 감지하는 데 더 오래 걸리지만 비용이 적게 듭니다. 오류 감지 및 복구 속도와 관련 비용의 균형을 조정합니다.

다음 단계

이 문서의 권장 사항을 보여 주는 다음 리소스를 고려합니다.

  • 이 문서의 지침을 워크로드에 적용하는 방법의 예로 다음 참조 아키텍처를 사용합니다.

  • 구현 전문 지식을 향상하려면 다음 제품 설명서를 사용합니다.