중요 업무용 웹 애플리케이션에 대한 글로벌 라우팅 중복성
중요
중요 업무용 아키텍처에 대한 글로벌 플랫폼 중단을 처리하는 중복 구현을 설계하는 것은 복잡하고 비용이 많이 들 수 있습니다. 이 디자인에서 발생할 수 있는 잠재적인 문제 때문에 장단 부분을 신중하게 고려해야 합니다.
대부분의 경우 이 문서에 설명된 아키텍처가 필요하지 않습니다.
중요 업무용 시스템은 솔루션에서 중복성 및 자가 복구 기능을 최대한 구축하여 단일 실패 지점을 최소화하기 위해 노력합니다. 시스템의 모든 통합 진입점은 실패 지점으로 간주될 수 있습니다. 이 구성 요소에 가동 중단이 발생하면 전체 시스템이 사용자에게 오프라인 상태가 됩니다. 라우팅 서비스를 선택할 때 서비스 자체의 안정성을 고려하는 것이 중요합니다.
중요 업무용 애플리케이션에 대한 기준 아키텍처에서 Azure Front Door는 높은 작동 시간 SLA(서비스 수준 계약) 및 풍부한 기능 집합으로 인해 선택되었습니다.
- 활성-활성 모델의 여러 지역으로 트래픽 라우팅
- TCP 애니캐스트를 사용한 투명한 장애 조치(failover)
- CDN(통합 콘텐츠 배달 네트워크)을 사용하여 에지 노드에서 정적 콘텐츠 제공
- 통합 웹 애플리케이션 방화벽을 사용하여 무단 액세스 차단
Front Door는 외부 고객뿐만 아니라 Microsoft의 여러 속성에도 최대한의 복원력과 가용성을 제공하도록 설계되었습니다. Front Door의 기능에 대한 자세한 내용은 Azure Front Door를 사용하여 웹 애플리케이션 가속화 및 보안을 참조하세요.
Front Door 기능은 대부분의 비즈니스 요구 사항을 충족하기에 충분하지만 분산 시스템에서는 오류가 발생할 수 있습니다. 비즈니스 요구 사항에 더 높은 복합 SLA 또는 가동 중지 시간이 필요한 경우 대체 트래픽 수신 경로에 의존해야 합니다. 그러나 더 높은 SLA를 추구하면 상당한 비용, 운영 오버헤드가 발생하며 전반적인 안정성을 낮출 수 있습니다. 대체 경로가 중요한 경로에 있는 다른 구성 요소에서 발생할 수 있는 장단 점 및 잠재적인 문제를 신중하게 고려합니다. 사용 불가의 영향이 중요한 경우에도 복잡성이 이점보다 클 수 있습니다.
한 가지 방법은 Azure Front Door를 사용할 수 없는 경우에만 활성화되는 대체 서비스를 사용하여 보조 경로를 정의하는 것입니다. Front Door의 기능 패리티는 하드 요구 사항으로 취급해서는 안 됩니다. 비즈니스 연속성을 위해 절대적으로 필요한 기능의 우선 순위를 지정합니다. 심지어 제한된 용량에서 실행될 수도 있습니다.
또 다른 방법은 글로벌 라우팅에 타사 기술을 사용하는 것입니다. 이 방법을 사용하려면 둘 이상의 클라우드 공급자에서 호스트되는 스탬프가 있는 다중 클라우드 활성-활성 배포가 필요합니다. Azure를 다른 클라우드 플랫폼과 효과적으로 통합할 수 있지만 여러 클라우드 플랫폼의 운영 복잡성 때문에 이 접근 방식은 권장되지 않습니다.
이 문서에서는 Azure Front Door를 사용할 수 없는 상황에서 Azure Traffic Manager를 대체 라우터로 사용하는 전역 라우팅에 대한 몇 가지 전략을 설명합니다.
접근 방식
이 아키텍처 다이어그램은 여러 중복 트래픽 경로가 있는 일반적인 방법을 보여 줍니다.
이 방법을 사용하면 몇 가지 구성 요소를 소개하고 웹 애플리케이션 배달과 관련된 중요한 변경을 수행할 수 있는 지침을 제공합니다.
Azure Traffic Manager 는 트래픽을 Azure Front Door 또는 선택한 대체 서비스로 전달합니다.
Azure Traffic Manager는 DNS 기반 글로벌 부하 분산 장치입니다. 도메인의 CNAME 레코드는 라우팅 방법을 구성하는 방법에 따라 대상을 결정하는 Traffic Manager를 가리킵니다. 우선 순위 라우팅을 사용하면 기본적으로 Azure Front Door를 통해 트래픽이 흐르게 됩니다. Azure Front Door를 사용할 수 없는 경우 Traffic Manager는 트래픽을 자동으로 대체 경로로 전환할 수 있습니다.
중요
이 솔루션은 Azure Front Door 중단과 관련된 위험을 완화하지만 글로벌 실패 지점으로 Azure Traffic Manager 중단에 취약합니다.
글로벌 부하 분산 장치와 같은 다른 글로벌 트래픽 라우팅 시스템을 사용하는 것도 고려할 수 있습니다. 그러나 Traffic Manager는 많은 상황에서 잘 작동합니다.
두 개의 수신 경로가 있습니다.
Azure Front Door는 기본 경로와 프로세스를 제공하고 모든 애플리케이션 트래픽을 라우팅합니다.
다른 라우터는 Azure Front Door에 대한 백업으로 사용됩니다. Front Door를 사용할 수 없는 경우에만 트래픽이 이 보조 경로를 통해 전달됩니다.
보조 라우터에 대해 선택하는 특정 서비스는 여러 요인에 따라 달라집니다. Azure 네이티브 서비스 또는 타사 서비스를 사용하도록 선택할 수 있습니다. 이 문서에서는 솔루션에 운영 복잡성을 더하지 않도록 Azure 네이티브 옵션을 제공합니다. 타사 서비스를 사용하는 경우 여러 제어 평면을 사용하여 솔루션을 관리해야 합니다.
원본 애플리케이션 서버는 두 서비스의 트래픽을 허용할 준비가 되어 있어야 합니다. 원본으로의 트래픽을 보호하는 방법과 Front Door 및 기타 업스트림 서비스가 제공하는 책임을 고려합니다. 애플리케이션이 트래픽이 흐르는 경로에서 트래픽을 처리할 수 있는지 확인합니다.
균형 유지
이 완화 전략은 플랫폼 가동 중단 중에 애플리케이션을 사용할 수 있도록 할 수 있지만 몇 가지 중요한 장단점이 있습니다. 알려진 비용에 대해 잠재적인 이점을 검토하고 혜택이 해당 비용의 가치가 있는지 여부에 대한 정보에 입각한 결정을 내려야 합니다.
재정적 비용: 애플리케이션에 여러 중복 경로를 배포하는 경우 리소스 배포 및 실행 비용을 고려해야 합니다. 서로 다른 사용 사례에 대해 각각 다른 비용 프로필이 있는 두 가지 예제 시나리오를 제공합니다.
운영 복잡성: 솔루션에 추가 구성 요소를 추가할 때마다 관리 오버헤드가 증가합니다. 한 구성 요소를 변경하면 다른 구성 요소에 영향을 미칠 수 있습니다.
Azure Front Door의 새로운 기능을 사용하기로 결정한다고 가정해 보겠습니다. 대체 트래픽 경로도 동등한 기능을 제공하는지 여부를 검사 해야 하며, 그렇지 않은 경우 두 트래픽 경로 간의 동작 차이를 처리하는 방법을 결정해야 합니다. 실제 애플리케이션에서 이러한 복잡성은 높은 비용을 초래할 수 있으며 시스템의 안정성에 큰 위험을 초래할 수 있습니다.
성능: 이 디자인에는 이름 확인 중에 추가 CNAME 조회가 필요합니다. 대부분의 애플리케이션에서는 중요한 문제가 아니지만 수신 경로에 추가 계층을 도입하여 애플리케이션 성능이 영향을 받는지 평가해야 합니다.
기회 비용: 중복 수신 경로를 설계하고 구현하려면 상당한 엔지니어링 투자가 필요하며, 궁극적으로 기능 개발 및 기타 플랫폼 개선을 위한 기회 비용이 발생합니다.
경고
복잡한 고가용성 솔루션을 설계하고 구현하는 방법에 주의를 기울이지 않으면 실제로 가용성을 더 악화시킬 수 있습니다. 아키텍처의 구성 요소 수를 늘리면 실패 지점 수가 증가합니다. 또한 운영 복잡성 수준이 더 높다는 것을 의미합니다. 추가 구성 요소를 추가할 때 모든 변경 내용을 신중하게 검토하여 전체 솔루션에 미치는 영향을 이해해야 합니다.
Azure Traffic Manager의 가용성
Azure Traffic Manager는 신뢰할 수 있는 서비스이지만 서비스 수준 계약이 100% 가용성을 보장하지는 않습니다. Traffic Manager를 사용할 수 없는 경우 Azure Front Door와 대체 서비스를 모두 사용할 수 있더라도 사용자가 애플리케이션에 액세스하지 못할 수 있습니다. 이러한 상황에서 솔루션이 계속 작동하는 방법을 계획하는 것이 중요합니다.
Traffic Manager는 캐시 가능한 DNS 응답을 반환합니다. DNS 레코드의 TTL(Time to Live)에서 캐싱을 허용하는 경우 Traffic Manager의 짧은 중단은 문제가 되지 않을 수 있습니다. 다운스트림 DNS 확인자가 이전 응답을 캐시했을 수 있기 때문입니다. 장기간 중단을 계획해야 합니다. Traffic Manager를 사용할 수 없는 경우 사용자를 Azure Front Door로 안내하도록 DNS 서버를 수동으로 다시 구성할 수 있습니다.
트래픽 라우팅 일관성
사용하고 사용하는 Azure Front Door 기능 및 기능을 이해하는 것이 중요합니다. 대체 서비스를 선택할 때 필요한 최소 기능을 결정하고 솔루션이 저하된 모드에 있을 때 다른 기능을 생략합니다.
대체 트래픽 경로를 계획할 때 고려해야 할 몇 가지 주요 질문은 다음과 같습니다.
- Azure Front Door의 캐싱 기능을 사용하나요? 캐싱을 사용할 수 없는 경우 원본 서버가 트래픽을 따라갈 수 있나요?
- Azure Front Door 규칙 엔진을 사용하여 사용자 지정 라우팅 논리를 수행하거나 요청을 다시 작성합니까?
- Azure Front Door WAF(웹 애플리케이션 방화벽)를 사용하여 애플리케이션을 보호합니까?
- IP 주소 또는 지역에 따라 트래픽을 제한하나요?
- TLS 인증서를 발급하고 관리하는 사람은 누구인가요?
- Azure Front Door를 통해 제공되도록 원본 애플리케이션 서버에 대한 액세스를 어떻게 제한합니까? Private Link 사용합니까, 아니면 서비스 태그 및 식별자 헤더가 있는 공용 IP 주소를 사용합니까?
- 애플리케이션 서버가 Azure Front Door 이외의 다른 곳에서 트래픽을 허용합니까? 이 경우 어떤 프로토콜을 수락합니까?
- 클라이언트가 Azure Front Door의 HTTP/2 지원을 사용합니까?
WAF(웹 애플리케이션 방화벽)
Azure Front Door의 WAF를 사용하여 애플리케이션을 보호하는 경우 트래픽이 Azure Front Door를 통과하지 않으면 어떻게 되는지 고려합니다.
대체 경로도 WAF를 제공하는 경우 다음 질문을 고려하세요.
- Azure Front Door WAF와 동일한 방식으로 구성할 수 있나요?
- 가양성 검색 가능성을 줄이기 위해 독립적으로 조정하고 테스트해야 합니까?
경고
대체 수신 경로에 WAF를 사용하지 않도록 선택할 수 있습니다. 이 방법은 애플리케이션의 안정성 목표를 지원하는 것으로 간주될 수 있습니다. 그러나 이것은 좋은 관행이 아니며 권장하지 않습니다.
검사없이 인터넷에서 트래픽을 수락하는 장단점 고려. 공격자가 애플리케이션에 대한 보호되지 않는 보조 트래픽 경로를 검색하는 경우 기본 경로에 WAF가 포함된 경우에도 보조 경로를 통해 악의적인 트래픽을 보낼 수 있습니다.
애플리케이션 서버에 대한 모든 경로를 보호하는 것이 가장 좋습니다.
도메인 이름 및 DNS
중요 업무용 애플리케이션은 사용자 지정 도메인 이름을 사용해야 합니다. 트래픽이 애플리케이션으로 흐르는 방식을 제어하고 단일 공급자에 대한 종속성을 줄입니다.
또한 Azure DNS와 같은 도메인 이름에 고품질의 복원력 있는 DNS 서비스를 사용하는 것이 좋습니다. 도메인 이름의 DNS 서버를 사용할 수 없는 경우 사용자는 서비스에 연결할 수 없습니다.
여러 DNS 확인자를 사용하여 전반적인 복원력을 더욱 높이는 것이 좋습니다.
CNAME 연결
Traffic Manager, Azure Front Door 및 기타 서비스를 결합하는 솔루션은 CNAME 체인이라고도 하는 다계층 DNS CNAME 확인 프로세스를 사용합니다. 예를 들어 사용자 지정 도메인을 resolve IP 주소가 반환되기 전에 5개 이상의 CNAME 레코드가 표시될 수 있습니다.
CNAME 체인에 추가 링크를 추가하면 DNS 이름 확인 성능에 영향을 줄 수 있습니다. 그러나 DNS 응답은 일반적으로 캐시되어 성능 영향을 줄입니다.
TLS 인증서
중요 업무용 애플리케이션의 경우 Azure Front Door에서 제공하는 관리되는 인증서 대신 고유한 TLS 인증서를 프로비전하고 사용하는 것이 좋습니다. 이 복잡한 아키텍처의 잠재적인 문제 수를 줄입니다.
다음과 같은 몇 가지 이점이 있습니다.
관리형 TLS 인증서를 발급하고 갱신하기 위해 Azure Front Door는 도메인의 소유권을 확인합니다. 도메인 확인 프로세스에서는 도메인의 CNAME 레코드가 Azure Front Door를 직접 가리킨다고 가정합니다. 그러나, 그 가정은 종종 정확하지 않습니다. Azure Front Door에서 관리형 TLS 인증서를 발급하고 갱신하는 것은 원활하게 작동하지 않을 수 있으며 TLS 인증서 문제로 인해 중단 위험이 높아질 수 있습니다.
다른 서비스에서 관리되는 TLS 인증서를 제공하더라도 도메인 소유권을 확인하지 못할 수 있습니다.
각 서비스가 자체 관리형 TLS 인증서를 독립적으로 가져오는 경우 문제가 있을 수 있습니다. 예를 들어 사용자는 다른 기관에서 발급한 다른 TLS 인증서 또는 만료 날짜 또는 지문이 다른 것을 기대하지 않을 수 있습니다.
그러나 인증서가 만료되기 전에 갱신 및 업데이트와 관련된 추가 작업이 있습니다.
원본 보안
Azure Front Door를 통해서만 트래픽을 허용하도록 원본을 구성하는 경우 계층 3 및 계층 4 DDoS 공격에 대한 보호를 받습니다. Azure Front Door는 유효한 HTTP 트래픽에만 응답하므로 많은 프로토콜 기반 위협에 대한 노출을 줄이는 데도 도움이 됩니다. 대체 수신 경로를 허용하도록 아키텍처를 변경하는 경우 실수로 원본이 위협에 노출되었는지 여부를 평가해야 합니다.
Private Link 사용하여 Azure Front Door에서 원본 서버로 연결하는 경우 트래픽이 대체 경로를 통해 어떻게 흐르나요? 개인 IP 주소를 사용하여 원본에 액세스할 수 있나요, 아니면 공용 IP 주소를 사용해야 합니까?
원본이 Azure Front Door 서비스 태그와 X-Azure-FDID 헤더를 사용하여 트래픽이 Azure Front Door를 통해 전달되었는지 확인하는 경우 원본을 다시 구성하여 트래픽이 유효한 경로 중 하나를 통해 전달되었는지 확인하는 방법을 고려합니다. 다른 고객의 Azure Front Door 프로필을 포함하여 다른 경로를 통해 트래픽에 대한 원본을 실수로 열지 않았는지 테스트해야 합니다.
원본 보안을 계획할 때 대체 트래픽 경로가 전용 공용 IP 주소 프로비저닝에 의존하는지 여부를 검사. 백업 경로를 온라인 상태로 만들기 위해 수동으로 트리거된 프로세스가 필요할 수 있습니다.
전용 공용 IP 주소가 있는 경우 원본에 대한 서비스 거부 공격의 위험을 줄이기 위해 Azure DDoS Protection 을 구현해야 하는지 여부를 고려합니다. 또한 다양한 네트워크 위협으로부터 보호할 수 있는 Azure Firewall 또는 다른 방화벽을 구현해야 하는지를 고려합니다. 더 많은 침입 검색 전략이 필요할 수도 있습니다. 이러한 컨트롤은 더 복잡한 다중 경로 아키텍처에서 중요한 요소가 될 수 있습니다.
상태 모델링
중요 업무용 설계 방법론에는 솔루션 및 해당 구성 요소의 전반적인 가시성을 제공하는 시스템 상태 모델이 필요합니다. 여러 트래픽 수신 경로를 사용하는 경우 각 경로의 상태를 모니터링해야 합니다. 트래픽이 보조 수신 경로로 다시 라우팅되는 경우 상태 모델은 시스템이 여전히 작동하지만 성능이 저하된 상태에서 실행되고 있다는 사실을 반영해야 합니다.
상태 모델 디자인에 다음 질문을 포함합니다.
- 솔루션의 다양한 구성 요소가 다운스트림 구성 요소의 상태를 모니터링하려면 어떻게 해야 하나요?
- 상태 모니터는 언제 다운스트림 구성 요소를 비정상으로 간주해야 하나요?
- 중단이 감지되는 데 얼마나 걸리나요?
- 중단이 감지되면 트래픽이 대체 경로를 통해 라우팅되는 데 얼마나 걸리나요?
Azure Front Door의 상태를 모니터링하고 가동 중단이 발생하는 경우 백업 플랫폼으로 자동 장애 조치(failover)를 트리거할 수 있는 여러 글로벌 부하 분산 솔루션이 있습니다. Azure Traffic Manager는 대부분의 경우에 적합합니다. Traffic Manager를 사용하면 검사 URL, 해당 URL을 검사 빈도 및 프로브 응답에 따라 다운스트림 서비스를 비정상으로 고려하는 시기를 지정하여 다운스트림 서비스를 모니터링하도록 엔드포인트 모니터링을 구성합니다. 일반적으로 검사 간격이 짧을수록 Traffic Manager가 원본 서버에 도달하기 위해 대체 경로를 통해 트래픽을 전송하는 데 걸리는 시간이 줄어듭니다.
Front Door를 사용할 수 없는 경우 다음을 포함하여 중단이 트래픽에 영향을 주는 시간에 여러 요인이 영향을 줍니다.
- DNS 레코드의 TTL(Time to Live)
- Traffic Manager가 상태 검사를 실행하는 빈도입니다.
- Traffic Manager가 트래픽을 다시 라우팅하기 전에 표시하도록 구성된 실패한 프로브 수입니다.
- 클라이언트 및 업스트림 DNS 서버가 Traffic Manager의 DNS 응답을 캐시하는 기간입니다.
또한 이러한 요소 중 컨트롤 내에 있는 요소와 제어할 수 없는 업스트림 서비스가 사용자 환경에 영향을 줄 수 있는지 여부를 결정해야 합니다. 예를 들어 DNS 레코드에서 낮은 TTL을 사용하는 경우에도 업스트림 DNS 캐시는 여전히 부실 응답을 예상보다 오랫동안 제공할 수 있습니다. 이 동작은 Traffic Manager가 이미 대체 트래픽 경로로 요청을 보내기로 전환한 경우에도 중단의 영향을 악화하거나 애플리케이션을 사용할 수 없는 것처럼 보일 수 있습니다.
팁
중요 업무용 솔루션에는 가능한 한 자동화된 장애 조치(failover) 접근 방식이 필요합니다. 수동 장애 조치(failover) 프로세스는 애플리케이션의 응답성을 유지하기 위해 느린 것으로 간주됩니다.
가동 중지 시간 없는 배포
중복 수신 경로를 사용하여 솔루션을 운영하는 방법을 계획하는 경우 성능이 저하될 때 서비스를 배포하거나 구성하는 방법도 계획해야 합니다. 대부분의 Azure 서비스의 경우 SLA는 관리 작업 또는 배포가 아닌 서비스 자체의 작동 시간에 적용됩니다. 서비스 중단에 대해 배포 및 구성 프로세스를 복원해야 하는지 여부를 고려합니다.
또한 솔루션을 관리하기 위해 상호 작용해야 하는 독립적인 제어 평면의 수를 고려해야 합니다. Azure 서비스를 사용하는 경우 Azure Resource Manager 통합되고 일관된 컨트롤 플레인을 제공합니다. 그러나 타사 서비스를 사용하여 트래픽을 라우팅하는 경우 별도의 컨트롤 플레인을 사용하여 서비스를 구성해야 할 수 있으며, 이로 인해 운영 복잡성이 더 커질 수 있습니다.
경고
여러 컨트롤 플레인을 사용하면 솔루션의 복잡성과 위험이 발생합니다. 차이점이 있을 때마다 누군가가 실수로 구성 설정을 놓치거나 중복 구성 요소에 다른 구성을 적용할 가능성이 높아집니다. 운영 절차에서 이 위험을 완화해야 합니다.
지속적인 유효성 검사
중요 업무용 솔루션의 경우 테스트 사례는 애플리케이션 트래픽이 흐르는 경로에 관계없이 솔루션이 요구 사항을 충족하는지 확인해야 합니다. 솔루션의 각 부분과 각 중단 유형에 대해 테스트하는 방법을 고려합니다.
테스트 프로세스에 다음 요소가 포함되어 있는지 확인합니다.
- 기본 경로를 사용할 수 없는 경우 트래픽이 대체 경로를 통해 올바르게 리디렉션되었는지 확인할 수 있나요?
- 두 경로 모두 수신할 프로덕션 트래픽 수준을 지원할 수 있나요?
- 성능이 저하된 상태일 때 취약성을 열거나 노출하지 않도록 두 경로가 모두 적절하게 보호되나요?
일반적인 시나리오
다음은 이 디자인을 사용할 수 있는 일반적인 시나리오입니다.
글로벌 콘텐츠 배달 은 일반적으로 정적 콘텐츠 배달, 미디어 및 대규모 전자 상거래 애플리케이션에 적용됩니다. 이 시나리오에서 캐싱은 솔루션 아키텍처의 중요한 부분이며 캐시에 실패하면 성능 또는 안정성이 크게 저하될 수 있습니다.
전역 HTTP 수신 은 일반적으로 중요 업무용 동적 애플리케이션 및 API에 적용됩니다. 이 시나리오에서 핵심 요구 사항은 트래픽을 안정적으로 효율적으로 원본 서버로 라우팅하는 것입니다. WAF는 종종 이러한 솔루션에 사용되는 중요한 보안 제어입니다.
경고
복잡한 다중 수신 솔루션을 설계하고 구현하는 방법에 주의를 기울이지 않으면 실제로 가용성을 더 악화시킬 수 있습니다. 아키텍처의 구성 요소 수를 늘리면 실패 지점 수가 증가합니다. 또한 운영 복잡성 수준이 더 높다는 것을 의미합니다. 추가 구성 요소를 추가할 때 모든 변경 내용을 신중하게 검토하여 전체 솔루션에 미치는 영향을 이해해야 합니다.
다음 단계
글로벌 HTTP 수신 및 글로벌 콘텐츠 배달 시나리오를 검토하여 솔루션에 적용되는지 여부를 이해합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기