중요 업무용 글로벌 HTTP 수신

중요 업무용 애플리케이션은 네트워크 구성 요소를 사용할 수 없거나 성능이 저하된 경우에도 높은 수준의 가동 시간을 유지해야 합니다. 웹 트래픽 수신, 라우팅 및 보안을 설계할 때 여러 Azure 서비스를 결합하여 더 높은 수준의 가용성을 달성하고 단일 실패 지점을 방지하는 것이 좋습니다.

이 방법을 채택하려는 경우 애플리케이션 서버에 대한 별도의 네트워크 경로를 구현해야 하며 각 경로를 별도로 구성하고 테스트해야 합니다. 이 접근 방식의 전체 의미를 신중하게 고려해야 합니다.

이 문서에서는 Azure Front Door 및 Azure Application Gateway 통해 글로벌 HTTP 트래픽 수신을 지원하는 방법을 설명합니다. 이 방법은 솔루션에 다음이 필요한 경우 요구 사항에 적합할 수 있습니다.

• 글로벌 트래픽 라우팅을 위한 Azure Front Door. 이는 별도의 Azure 지역에 애플리케이션 인스턴스가 여러 개 있거나 단일 지역의 모든 글로벌 사용자에게 서비스를 제공한다는 것을 의미할 수 있습니다.
• 트래픽이 원본 서버에 도달하는 경로에 관계없이 애플리케이션을 보호하기 위한 WAF(웹 애플리케이션 방화벽)입니다.

네트워크 에지에서 캐싱은 애플리케이션 배달의 중요한 부분이 아닙니다. 캐싱이 중요한 경우 대체 방법은 중요 업무용 글로벌 콘텐츠 배달 을 참조하세요.

참고

이 사용 사례는 Azure Front Door를 사용할 수 없는 경우 대체 방법을 다루는 전반적인 디자인 전략의 일부입니다. 컨텍스트 및 고려 사항에 대한 자세한 내용은 중요 업무용 글로벌 웹 애플리케이션을 참조하세요.

접근 방식

이 DNS 기반 부하 분산 솔루션은 여러 Azure Traffic Manager 프로필을 사용하여 Azure Front Door를 모니터링합니다. 가용성 문제가 발생할 가능성이 거의 없는 경우 Traffic Manager는 Application Gateway 통해 트래픽을 리디렉션합니다.

이 솔루션은 다음 구성 요소를 포함합니다.

• 우선 순위 라우팅 모드를 사용하는 Traffic Manager 에는 두 개의 엔드포인트가 있습니다. 기본적으로 Traffic Manager는 Azure Front Door를 통해 요청을 보냅니다. Azure Front Door를 사용할 수 없는 경우 두 번째 Traffic Manager 프로필은 요청을 지시할 위치를 결정합니다. 두 번째 프로필은 아래에 설명되어 있습니다.

• Azure Front Door 는 대부분의 애플리케이션 트래픽을 처리하고 라우팅합니다. Azure Front Door는 트래픽을 적절한 원본 애플리케이션 서버로 라우팅하고 애플리케이션의 기본 경로를 제공합니다. Azure Front Door의 WAF는 일반적인 보안 위협으로부터 애플리케이션을 보호합니다. Azure Front Door를 사용할 수 없는 경우 트래픽은 보조 경로를 통해 자동으로 리디렉션됩니다.

• 성능 라우팅 모드를 사용하는 Traffic Manager에는 각 Application Gateway instance 대한 엔드포인트가 있습니다. 이 Traffic Manager는 클라이언트 위치에서 최상의 성능으로 Application Gateway instance 요청을 보냅니다.

• Application Gateway 각 지역에 배포되고 해당 지역 내의 원본 서버로 트래픽을 보냅니다. Application Gateway WAF는 보조 경로를 통해 흐르는 모든 트래픽을 보호합니다.

• 원본 애플리케이션 서버는 언제든지 Azure Front Door 및 Azure Application Gateway 트래픽을 수락할 준비가 되어 있어야 합니다.

고려 사항

다음 섹션에서는 이러한 유형의 아키텍처에 대한 몇 가지 중요한 고려 사항을 설명합니다. 또한 중요 업무용 솔루션에서 Azure Front Door를 사용할 때 중요 업무용 글로벌 웹 애플리케이션 을 검토하여 다른 중요한 고려 사항 및 절충을 고려해야 합니다.

Traffic Manager 구성

이 방법은 중첩된 Traffic Manager 프로필을 사용하여 애플리케이션의 대체 트래픽 경로에 대한 우선 순위 기반 및 성능 기반 라우팅을 함께 달성합니다. 단일 지역에 원본이 있는 간단한 시나리오에서는 우선 순위 기반 라우팅을 사용하도록 구성된 단일 Traffic Manager 프로필만 필요할 수 있습니다.

지역 배포

Azure Front Door는 글로벌 서비스이며 Application Gateway 지역 서비스입니다.

Azure Front Door의 현재 상태는 전역적으로 배포되고 TCP 및 TLS 연결은 클라이언트에 가장 가까운 현재 상태에서 종료됩니다. 이 동작은 애플리케이션의 성능을 향상시킵니다. 반면 클라이언트가 Application Gateway 연결하면 트래픽이 발생한 위치에 관계없이 요청을 수신하는 Application Gateway TCP 및 TLS 연결이 종료됩니다.

클라이언트에서 연결

글로벌 다중 테넌트 서비스인 Azure Front Door는 다양한 위협에 대한 내재된 보호를 제공합니다. Azure Front Door는 유효한 HTTP 및 HTTPS 트래픽만 허용하며 다른 프로토콜의 트래픽을 허용하지 않습니다. Microsoft는 Azure Front Door가 인바운드 연결에 사용하는 공용 IP 주소를 관리합니다. 이러한 특성으로 인해 Azure Front Door는 다양한 공격 유형으로부터 원본을 보호하는 데 도움이 될 수 있으며 Private Link 연결을 사용하도록 원본을 구성할 수 있습니다.

반면, Application Gateway 전용 공용 IP 주소를 사용하는 인터넷 연결 서비스입니다. 다양한 공격 유형으로부터 네트워크 및 원본 서버를 보호해야 합니다. 자세한 내용은 원본 보안을 참조하세요.

원본 서버에 대한 연결 Private Link

Azure Front Door Premium은 원본에 대한 Private Link 연결을 제공하여 솔루션의 공용 인터넷 연결 노출 영역을 줄입니다.

Private Link 사용하여 원본에 연결하는 경우 가상 네트워크에 프라이빗 엔드포인트를 배포하고 프라이빗 엔드포인트를 애플리케이션의 백 엔드로 사용하도록 Application Gateway 구성하는 것이 좋습니다.

확장

Application Gateway 배포할 때 솔루션에 대한 전용 컴퓨팅 리소스를 배포합니다. 많은 양의 트래픽이 예기치 않게 Application Gateway 도착하면 성능 또는 안정성 문제가 발생할 수 있습니다.

이러한 위험을 완화하려면 Application Gateway instance 크기를 조정하는 방법을 고려합니다. 자동 크기 조정을 사용하거나 장애 조치(failover) 후 수신할 수 있는 트래픽 양을 처리하기 위해 수동으로 크기를 조정했는지 확인합니다.

캐싱

Azure Front Door의 캐싱 기능을 사용하는 경우 트래픽이 대체 경로로 전환되고 Application Gateway 사용하면 콘텐츠가 더 이상 Azure Front Door 캐시에서 제공되지 않는다는 점에 유의해야 합니다.

솔루션에 대한 캐싱에 의존하는 경우 파트너 CDN을 Azure Front Door 대체로 사용하는 대체 방법은 중요 업무용 글로벌 콘텐츠 배달 을 참조하세요.

또는 캐싱을 사용하지만 애플리케이션 배달 전략의 필수적인 부분이 아닌 경우 장애 조치(failover) 중에 캐시 누락 수가 증가하여 발생한 부하 증가에 대처하기 위해 원본을 스케일 아웃하거나 스케일 업할 수 있는지 여부를 고려합니다.

균형 유지

이 유형의 아키텍처는 대체 트래픽 경로가 요청 처리 규칙, WAF 및 TLS 오프로드와 같은 기능을 사용하려는 경우에 가장 유용합니다. Azure Front Door와 Application Gateway 모두 유사한 기능을 제공합니다.

그러나 다음과 같은 절충이 있습니다.

• 운영 복잡성. 이러한 기능을 사용하는 경우 Azure Front Door 및 Application Gateway 모두 구성해야 합니다. 예를 들어 Azure Front Door WAF에 대한 구성을 변경하는 경우 Application Gateway WAF에도 동일한 구성 변경 내용을 적용해야 합니다. 두 개의 별도 시스템을 다시 구성하고 테스트해야 하는 경우 운영 복잡성이 훨씬 더 높아집니다.

• 기능 패리티. Azure Front Door와 Application Gateway 제공하는 기능 간에는 유사점이 있지만 많은 기능에는 정확한 패리티가 없습니다. 이러한 차이는 애플리케이션이 따르는 트래픽 경로에 따라 전달되는 방식에 영향을 줄 수 있으므로 주의해야 합니다.

  Application Gateway 캐싱을 제공하지 않습니다. 이러한 차이점에 대한 자세한 내용은 캐싱을 참조하세요.

  Azure Front Door 및 Application Gateway 고유한 제품이며 사용 사례가 다릅니다. 특히 두 제품은 Azure 지역에 배포되는 방식과 다릅니다. 각 제품의 세부 정보와 사용 방법을 이해해야 합니다.

• 비용. 일반적으로 원본이 있는 각 지역에 Application Gateway instance 배포해야 합니다. 각 Application Gateway instance 별도로 청구되므로 원본이 여러 지역에 배포되면 비용이 높아질 수 있습니다.

  비용이 솔루션의 중요한 요소인 경우 Azure Front Door에 대한 대체로 CDN(파트너 콘텐츠 배달 네트워크)을 사용하는 대체 방법은 중요 업무용 글로벌 콘텐츠 배달을 참조하세요. 일부 CDN은 소비량에 따라 트래픽을 청구하므로 이 방법이 더 비용 효율적일 수 있습니다. 그러나 솔루션에 Application Gateway 사용하면 다른 이점이 손실될 수 있습니다.

  또는 Traffic Manager가 트래픽을 PaaS(Platform as a Service) 애플리케이션 서비스로 직접 라우팅할 수 있는 대체 아키텍처를 배포하여 Application Gateway 필요를 방지하고 비용을 절감할 수 있습니다. 솔루션에 Azure App Service 또는 Azure Container Apps와 같은 서비스를 사용하는 경우 이 방법을 고려할 수 있습니다. 그러나 이 방법을 따르는 경우 고려해야 할 몇 가지 중요한 장단 사항이 있습니다.

  • Waf: Azure Front Door와 Application Gateway 모두 WAF 기능을 제공합니다. 애플리케이션 서비스를 인터넷에 직접 노출하는 경우 WAF를 사용하여 애플리케이션을 보호하지 못할 수 있습니다.
  • TLS 오프로드: Azure Front Door 및 Application Gateway 모두 TLS 연결을 종료합니다. TLS 연결을 종료하도록 애플리케이션 서비스를 구성해야 합니다.
  • 라우팅: Azure Front Door와 Application Gateway 모두 경로 기반 라우팅을 포함하여 여러 원본 또는 백 엔드에서 라우팅을 수행하고 복잡한 라우팅 규칙을 지원합니다. 애플리케이션 서비스가 인터넷에 직접 노출되는 경우 트래픽 라우팅을 수행할 수 없습니다.

경고

애플리케이션을 인터넷에 직접 노출하는 것을 고려하는 경우 철저한 위협 모델을 만들고 아키텍처가 보안, 성능 및 복원력 요구 사항을 충족하는지 확인합니다.

가상 머신을 사용하여 솔루션을 호스트하는 경우 가상 머신을 인터넷에 노출해서는 안 됩니다.

다음 단계

글로벌 콘텐츠 배달 시나리오를 검토하여 솔루션에 적용되는지 여부를 이해합니다.