Azure Front Door는 HTTP 및 HTTPS 트래픽을 라우팅하는 글로벌 CDN(부하 분산 장치 및 콘텐츠 배달 네트워크)입니다. Azure Front Door는 애플리케이션 사용자에게 가장 가까운 트래픽을 제공하고 분산합니다.
이 문서에서는 설계자로서 부하 분산 옵션을 검토하고 워크로드에 대한 부하 분산 장치로 Azure Front Door를 선택했다고 가정합니다. 또한 애플리케이션이 활성-활성 또는 활성-수동 모델의 여러 지역에 배포되었다고 가정합니다. 이 문서의 지침에서는 Azure Well-Architected Framework 핵심 요소원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.
기술 범위
이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.
- Azure Front Door
Reliability
안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을지속적인 기능을 제공하는 것입니다.
신뢰성 설계 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 설계 전략을 제시하는입니다.
워크로드 디자인 검사 목록
안정성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. 계층 및 CDN 기능을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
당신의 배포 전략을 선택합니다. 기본 배포 방법은 활성-활성 및 활성-수동입니다. 활성-활성 배포는 워크로드를 실행하는 여러 환경 또는 스탬프가 트래픽을 처리한다는 것을 의미합니다. 활성-수동 배포는 주 지역만 모든 트래픽을 처리하다가 장애 발생 시 자동으로 보조 지역으로 전환된다는 것을 의미합니다. 다중 리소스 배포에서 스탬프 또는 애플리케이션 인스턴스는 트래픽을 분산하는 Azure Front Door와 같은 글로벌 부하 분산 장치를 사용하여 고가용성을 위해 다른 지역에서 실행됩니다. 따라서 적절한 배포 방법을 위해 부하 분산 장치를 구성하는 것이 중요합니다.
Azure Front Door는 활성-활성 또는 활성-수동 모델에서 트래픽을 분산하도록 구성할 수 있는 여러 라우팅 방법을 지원합니다.
앞의 모델에는 다양한 변형이 있습니다. 예를 들어 웜 스페어로 활성-수동 모델을 배포할 수 있습니다. 이 경우 보조 호스팅 서비스는 가능한 최소 컴퓨팅 및 데이터 크기 조정을 사용하여 배포하고 로드 없이 실행됩니다. 장애 조치 시 컴퓨팅 및 데이터 리소스는 주 지역의 부하를 처리하도록 크기를 조정합니다. 자세한 내용은 다중Region 디자인에 대한 아키텍처 전략을 참조하세요.
일부 애플리케이션은 사용자 세션 중에 동일한 원본 서버에 유지하려면 사용자 연결이 필요합니다. 안정성 측면에서는 동일한 원본 서버에 사용자 연결을 유지하지 않는 것이 좋습니다. 세션 연결을 최대한 피합니다.
각 계층동일한 호스트 이름을 사용합니다. 쿠키 또는 리디렉션 URL이 제대로 작동하도록 하려면 웹 애플리케이션 앞에서 Azure Front Door와 같은 역방향 프록시를 사용할 때 원래 HTTP 호스트 이름을 유지합니다.
상태 엔드포인트 모니터링 패턴구현합니다. 애플리케이션은 애플리케이션의 요청 처리에 필요한 중요한 서비스 및 종속성의 상태를 집계하는 상태 엔드포인트를 노출하도록 해야 합니다. Azure Front Door 상태 프로브는 엔드포인트를 사용하여 원본 서버의 상태를 검색합니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴참조하세요.
정적 콘텐츠를 캐시합니다. Azure Front Door의 콘텐츠 배달 기능에는 수백 개의 에지 위치가 있으며 트래픽 급증 및 DDoS(분산 서비스 거부) 공격을 견딜 수 있습니다. 이러한 기능은 안정성을 향상시키는 데 도움이 됩니다.
중복 트래픽 관리 옵션을 고려하다. Azure Front Door는 환경에서 싱글톤으로 실행되는 전역적으로 분산된 서비스입니다. Azure Front Door는 시스템에서 잠재적인 단일 실패 지점입니다. 서비스가 실패하면 클라이언트는 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다.
중복 구현은 복잡하고 비용이 많이 들 수 있습니다. 중단에 대한 허용 오차가 매우 낮은 중요 업무용 워크로드에 대해서만 고려합니다. 절충을 신중하게 고려하십시오.
- 중복 라우팅이 반드시 필요한 경우 전역 라우팅 중복성참조하세요.
- 캐시된 콘텐츠를 제공하기 위해서만 중복성이 필요한 경우 전역 콘텐츠 배달참조하세요.
구성 권장 사항
| Recommendation | Benefit |
|---|---|
| 배포 전략을 지원하는 라우팅 방법을 선택합니다. 구성된 가중치 계수에 따라 트래픽을 분산하는 가중치 메서드는 활성-활성 모델을 지원합니다. 백업으로 모든 트래픽을 수신하고 보조 지역으로 트래픽을 보내도록 주 지역을 구성하는 우선 순위 기반 값은 활성-수동 모델을 지원합니다. 가장 낮은 대기 시간을 가진 원본이 트래픽을 수신할 수 있도록 이전 메서드를 대기 시간 민감도 구성과 결합합니다. |
일련의 의사 결정 단계와 디자인을 사용하여 최상의 원본 리소스를 선택할 수 있습니다. 선택한 원본은 지정된 가중치 비율의 허용 대기 시간 범위 내에서 트래픽을 제공합니다. |
|
하나 이상의 원본 그룹에 여러 원본을중복성을 지원합니다. 항상 애플리케이션의 중복 인스턴스가 있고 각 인스턴스가 원본을 노출하는지 확인합니다. 이러한 원본을 하나 이상의 원본 그룹에 배치할 수 있습니다. |
여러 원본은 애플리케이션의 여러 인스턴스에 트래픽을 분산하여 중복성을 지원합니다. 한 인스턴스를 사용할 수 없는 경우 다른 원본은 여전히 트래픽을 수신할 수 있습니다. |
|
원본에 건강 프로브를 설정합니다. 상태 검사를 수행하여 원본 인스턴스를 사용할 수 있고 요청을 계속 받을 준비가 되었는지 확인하도록 Azure Front Door를 구성합니다. 자세한 내용은 상태 프로브에 대한모범 사례를 참조하세요. |
활성화된 상태 프로브는 상태 모니터링 패턴의 구현의 일부입니다. 상태 프로브는 Azure Front Door가 요청을 처리할 수 있을 만큼 정상인 인스턴스로만 트래픽을 라우팅하도록 합니다. |
| 요청을 원본으로 전달하는 데 시간 제한을 설정하고 장기 실행 요청을 방지합니다. 엔드포인트의 요구에 따라 시간 제한 설정을 조정합니다. 그렇지 않으면 원본이 응답을 보내기 전에 Azure Front Door가 연결을 닫을 수 있습니다. 모든 원본에 더 짧은 시간 제한이 있는 경우 Azure Front Door에 대한 기본 시간 제한을 낮출 수도 있습니다. 자세한 내용은 응답하지 않는 요청문제 해결을 참조하세요. |
장기 실행 요청은 시스템 리소스를 사용합니다. 시간 제한은 완료하는 데 예상보다 오래 걸리는 요청을 종료하여 성능 문제 및 가용성 문제를 방지하는 데 도움이 됩니다. |
| Azure Front Door 및 원본에서 동일한 호스트 이름을 사용합니다. Azure Front Door는 들어오는 요청의 호스트 헤더를 다시 작성할 수 있습니다. 이 헤더는 하나의 원본으로 라우팅되는 여러 사용자 지정 도메인 이름이 있는 경우에 유용합니다. 그러나 호스트 헤더를 다시 작성하면 요청 쿠키 및 URL 리디렉션에 문제가 발생할 수 있습니다. 자세한 내용은 [원래 HTTP 호스트 이름 유지](/azure/architecture/best-practices/host-name-preserve를 역방향 프록시와 해당 원본 웹 애플리케이션 간에 유지)를 참조하세요. |
세션 선호도, 인증 및 권한 부여로 오작동을 방지하려면 동일한 호스트 이름을 설정합니다. |
| 애플리케이션에 세션 선호도가 필요한지 여부를 결정합니다. 높은 안정성 요구 사항이 있는 경우 세션 선호도를 사용하지 않도록 설정하는 것이 좋습니다. | 세션 선호도를 사용하면 사용자 세션 중에 사용자 연결이 동일한 원본에 유지됩니다. 경우에 따라 다른 원본이 유휴 상태인 동안 단일 원본이 요청과 함께 오버로드될 수 있습니다. 해당 원본을 사용할 수 없게 되면 사용자 환경이 중단될 수 있습니다. |
| WAF(웹 애플리케이션 방화벽)에 포함된 속도 제한 규칙을 활용합니다. | 클라이언트가 애플리케이션에 너무 많은 트래픽을 보내지 못하도록 요청을 제한합니다. 속도 제한은 재시도 폭풍과 같은 문제를 방지하는 데 도움이 될 수 있습니다. |
Security
보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보증을 제공하는 것입니다.
워크로드 디자인 검사 목록
보안 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. 보안 상태를 개선하기 위해 취약성 및 컨트롤을 식별합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
원본 서버보호합니다. Azure Front Door는 프런트 엔드이며 애플리케이션에 대한 단일 진입점입니다.
Azure Front Door는 Azure Private Link를 사용하여 애플리케이션의 원본에 액세스합니다. Private Link는 원본이 공용 IP 주소 및 엔드포인트를 노출할 필요가 없도록 구분을 만듭니다. 자세한 내용은 Azure Front Door Premium에서 Private Link를 사용하여 원본을 안전하게 보호하기 참조하세요.
Azure Front Door에서 외부에서 사용하는 호스트 이름이 동일한 요청만 수락하도록 백 엔드 서비스를 구성합니다.
컨트롤 플레인대한 권한 있는 액세스만 허용합니다. Azure Front Door RBAC(역할 기반 액세스 제어) 사용하여 필요한 ID에만 액세스를 제한합니다.
네트워크 경계에서 일반적인 위협을 차단합니다. WAF는 Azure Front Door와 통합됩니다. 프런트 엔드에서 WAF 규칙을 사용하도록 설정하여 공격 원본에 가까운 네트워크 에지의 일반적인 악용 및 취약성으로부터 애플리케이션을 보호합니다. 국가 또는 지역에서 웹 애플리케이션에 대한 액세스를 제한하려면 지역 필터링을 고려하세요.
Azure Web Application Firewall 에 대한 자세한 내용은 Azure Front Door을 참조하세요.
예기치 않은 트래픽방지합니다. Azure Front Door의 아키텍처는 DDoS 공격으로부터 애플리케이션 엔드포인트를 보호하기 위한 기본 제공 DDoS 보호 제공합니다. 애플리케이션에서 다른 공용 IP 주소를 노출해야 하는 경우 고급 보호 및 검색 기능을 위해 해당 주소에 대한 Azure DDoS Protection 표준 계획을 추가하는 것이 좋습니다.
또한 잠재적으로 악의적일 수 있는 봇 트래픽 또는 예기치 않게 많은 양의 트래픽을 검색하는 WAF 규칙 집합이 있습니다. 가능한 경우 AI 기반 보안 기능을 사용하여 위협 분석을 수행하는 기능을 사용합니다. 예를 들어 Microsoft Security Copilot와 Azure Web Application Firewall 통합 은 컨텍스트 인사이트 및 위협 완화 제안을 요약하여 위협 식별을 신속하게 수행할 수 있습니다.
전송 중인 데이터 보호. 해당하는 경우 TLS(엔드투엔드 전송 계층 보안), HTTP-HTTPS 리디렉션 및 관리형 TLS 인증서를 사용하도록 설정합니다. 자세한 내용은 Azure Front Door 대한TLS 모범 사례를 참조하세요.
비정상적인 활동을 모니터링합니다. 정기적으로 로그를 검토하여 공격 및 오탐 여부를 확인합니다. Azure Front Door WAF 로그를 Microsoft Sentinel과 같은 조직의 중앙 집중식 SIEM(보안 정보 및 이벤트 관리)으로 보내 위협 패턴을 감지하고 워크로드 디자인에 예방 조치를 통합합니다.
구성 권장 사항
| Recommendation | Benefit |
|---|---|
| 잠재적으로 악의적인 트래픽을 감지하고 차단하는 WAF 규칙 집합을 사용하도록 설정합니다. 이 기능은 프리미엄 계층에서 사용할 수 있습니다. 다음 규칙 집합을 사용하는 것이 좋습니다. - 기본값 - 봇 보호 - IP 제한 - 지역 필터링 - 속도 제한 |
기본 규칙 집합은 Microsoft Threat Intelligence의 OWASP 상위 10개 공격 유형 및 정보를 기반으로 자주 업데이트됩니다. 특수 규칙 집합은 특정 사용 사례를 검색합니다. 예를 들어 봇 규칙은 클라이언트 IP 주소를 기반으로 봇을 양수, 불량 또는 알 수 없음으로 분류합니다. 또한 잘못된 봇 및 알려진 IP 주소를 차단하고 호출자의 지리적 위치에 따라 트래픽을 제한합니다. 규칙 집합의 조합을 사용하여 다양한 의도로 공격을 감지하고 차단할 수 있습니다. |
| 관리되는 규칙 집합에 대한 제외를 만듭니다. WAF 정책을 몇 주 동안 탐지 모드에서 테스트하고, 배포하기 전에 오탐을 조정하십시오. |
오탐지를 줄이고 애플리케이션에 대한 정상적인 요청을 허용합니다. |
| 호스트 헤더를 원본으로 보냅니다. | 백 엔드 서비스는 해당 호스트의 트래픽만 허용하는 규칙을 만들 수 있도록 호스트 이름을 알고 있어야 합니다. |
Azure Front Door부터 원본까지의 연결을 보호합니다.
지원되는 원본에 대한 Private Link 연결 사용하도록 설정합니다. 원본이 Private Link 연결을 지원하지 않는 경우 서비스 태그 및 X-Azure-FDID 헤더를 사용하여 요청 원본이 Azure Front Door 프로필인지 확인합니다. |
모든 트래픽이 Azure Front Door를 통해 흐르고 DDoS 보호 및 WAF 검사와 같은 보안 이점을 가져오는지 확인합니다. |
| 해당하는 경우 엔드투엔드 TLS, HTTP-HTTPS 리디렉션 및 관리형 TLS 인증서를 사용하도록 설정합니다. Azure Front Door 대한TLS 모범 사례를 검토합니다. 애플리케이션과 관련된 암호화가 있는 최소 허용 버전으로 TLS 버전 1.2를 사용합니다. Azure Front Door 관리형 인증서는 작업 용이성을 위해 기본 선택 항목이어야 합니다. 그러나 인증서의 수명 주기를 관리하려면 Azure Front Door 사용자 지정 도메인 엔드포인트에서 사용자 고유의 인증서를 사용하고 Key Vault에 저장합니다. |
TLS는 브라우저, Azure Front Door 및 원본 간의 데이터 교환이 변조를 방지하기 위해 암호화되도록 합니다. Key Vault는 관리되는 인증서 지원 및 간단한 인증서 갱신 및 회전을 제공합니다. |
비용 최적화
비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하면서 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.
비용 최적화 설계 원칙은 Azure Front Door 및 그 환경과 관련된 기술 설계에서 필요에 따라 이러한 목표를 달성하고 절충하기 위한 고급 설계 전략을 제공합니다.
워크로드 디자인 검사 목록
디자인 검토 검사 목록을 기반으로 투자를 위한 비용 최적화을 위한 디자인 전략을 시작합니다. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.
서비스 계층 및 가격 책정검토합니다. 가격 계산기를 사용하여 Azure Front Door의 각 계층에 대한 실제 비용을 예측합니다. 각 계층의 기능 및 당신의 시나리오에 맞는 적합성을 비교합니다. 예를 들어 프리미엄 계층만 Private Link를 통해 원본에 연결을 지원합니다.
표준 SKU는 더 비용 효율적이며 보통 트래픽 시나리오에 적합합니다. 프리미엄 SKU에서는 더 높은 단위 요금을 지불하지만 WAF 및 Private Link의 관리되는 규칙과 같은 보안 혜택 및 고급 기능에 액세스할 수 있습니다. 비즈니스 요구 사항에 따라 안정성 및 보안 에 대한 장단함을 고려합니다.
대역폭 비용을고려하십시오. Azure Front Door의 대역폭 비용은 선택한 계층 및 데이터 전송 유형에 따라 달라집니다. Azure Front Door 청구에 대해 자세히 알으려면 Azure Front Door 청구을 참조하세요.
Azure Front Door는 청구 가능한 메트릭에 대한 기본 제공 보고서를 제공합니다. 대역폭과 관련된 비용 및 최적화 노력에 집중할 수 있는 위치를 평가하려면 azure Front Door 보고서 참조하세요.
들어오는 요청최적화합니다. Azure Front Door는 요청의 청구를 처리합니다. 디자인 구성에서 제한을 설정할 수 있습니다.
디자인 패턴인 백 엔드 포 프론트엔드 및 게이트웨이 집계같은 방법을 사용하여 요청 수를 줄입니다. 이러한 패턴은 작업의 효율성을 향상시킬 수 있습니다.
WAF 규칙은 들어오는 트래픽을 제한하여 비용을 최적화할 수 있습니다. 예를 들어 속도 제한을 사용하여 비정상적으로 높은 수준의 트래픽을 방지하거나 지역 필터링을 사용하여 특정 지역 또는 국가의 액세스만 허용합니다.
리소스를 효율적으로. Azure Front Door는 리소스 최적화에 도움이 되는 라우팅 방법을 사용합니다. 워크로드가 대기 시간이 매우 중요한 경우가 아니면 배포된 리소스를 효과적으로 사용하기 위해 모든 환경에 트래픽을 균등하게 분산합니다.
Azure Front Door 엔드포인트는 많은 파일을 제공할 수 있습니다. 대역폭 비용을 줄이는 한 가지 방법은 압축을 사용하는 것입니다.
자주 변경되지 않는 콘텐츠의 경우 Azure Front Door에서 캐싱을 사용합니다. 콘텐츠는 캐시에서 제공되므로 요청이 원본으로 전달될 때 발생하는 대역폭 비용을 절감할 수 있습니다.
조직제공하는 공유 인스턴스를 사용하는 것이 좋습니다. 중앙 집중식 서비스에서 발생하는 비용은 워크로드 간에 공유됩니다. 그러나 안정성과의 절충을 고려합니다. 고가용성 요구 사항이 있는 중요 업무용 애플리케이션의 경우 자율 인스턴스를 사용하는 것이 좋습니다.
기록된 데이터의 양에 주의하세요. 특정 요청이 필요하지 않거나 로깅 데이터가 장기간 보존되는 경우 대역폭 및 스토리지와 관련된 비용이 발생할 수 있습니다.
구성 권장 사항
| Recommendation | Benefit |
|---|---|
| 이를 지원하는 엔드포인트에 캐싱을 사용합니다. | 캐싱은 Azure Front Door 인스턴스에서 원본으로의 호출 수를 줄이기 때문에 데이터 전송 비용을 최적화합니다. |
|
파일 압축사용하도록 설정하는 것이 좋습니다. 이 구성의 경우 애플리케이션은 압축을 지원해야 하며 캐싱을 사용하도록 설정해야 합니다. |
압축은 대역폭 소비를 줄이고 성능을 향상시킵니다. |
| 단일 원본이 있는 원본 그룹에서 상태 검사를 사용하지 않도록 설정합니다. Azure Front Door 원본 그룹에 하나의 원본만 구성된 경우 이러한 호출은 필요하지 않습니다. |
라우팅 결정을 내리는 데 필요하지 않은 상태 검사 요청을 사용하지 않도록 설정하여 대역폭 비용을 절감할 수 있습니다. |
운영 효율성
운영 우수성은 주로 개발 사례, 관찰 가능성 및 릴리스 관리대한 절차에 중점을 둡니다.
운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.
워크로드 디자인 검사 목록
Azure Front Door와 관련된 관찰성, 테스트 및 배포에 대한 프로세스를 정의하기 위한 운영 우수성 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.
IaC(Infrastructure as code) 기술을 사용합니다. Bicep 및 Azure Resource Manager 템플릿 같은 IaC 기술을 사용하여 Azure Front Door 인스턴스를 프로비전합니다. 이러한 선언적 접근 방식은 일관성과 간단한 유지 관리를 제공합니다. 예를 들어 IaC 기술을 사용하여 새 규칙 집합 버전을 쉽게 채택할 수 있습니다. 항상 최신 API 버전을 사용합니다.
구성을 간소화합니다. Azure Front Door를 사용하여 구성을 쉽게 관리할 수 있습니다. 예를 들어 아키텍처가 마이크로 서비스를 지원한다고 가정합니다. Azure Front Door는 리디렉션 기능을 지원하므로 경로 기반 리디렉션을 사용하여 개별 서비스를 대상으로 지정할 수 있습니다. 또 다른 사용 사례는 와일드카드 도메인의 구성입니다.
점진적 노출을 처리합니다. Azure Front Door는 여러 라우팅 방법을제공합니다. 가중 부하 분산 방법 경우 카나리아 배포를 사용하여 특정 비율의 트래픽을 원본으로 보낼 수 있습니다. 이 방법을 사용하면 배포하기 전에 제어된 환경에서 새 기능 및 릴리스를 테스트할 수 있습니다.
작업량 모니터링의 일부로 운영 데이터를 수집하고 분석합니다. Azure Monitor 로그를 사용하여 관련 Azure Front Door 로그 및 메트릭을 캡처합니다. 이 데이터는 문제를 해결하고, 사용자 동작을 이해하고, 작업을 최적화하는 데 도움이 됩니다.
Azure 로 인증서 관리를오프로드합니다. 인증 회전 및 갱신과 관련된 운영 부담을 덜어줍니다.
구성 권장 사항
| Recommendation | Benefit |
|---|---|
| HTTP에서 HTTPS로 리디렉션 사용하여 앞으로 호환성을 지원합니다. | 리디렉션을 사용하도록 설정하면 Azure Front Door는 이전 프로토콜을 사용하는 클라이언트를 자동으로 리디렉션하여 보안 환경을 위해 HTTPS를 사용합니다. |
|
로그 및 메트릭을 캡처합니다. 리소스 활동 로그, 액세스 로그, 상태 프로브 로그 및 WAF 로그를 포함합니다. 알림을설정하십시오. |
수신 흐름 모니터링은 애플리케이션 모니터링의 중요한 부분입니다. 요청을 추적하고 성능 및 보안을 개선하려고 합니다. Azure Front Door 구성을 디버그하려면 데이터가 필요합니다. 경고가 준비되면 중요한 운영 문제에 대한 즉각적인 알림을 받을 수 있습니다. |
| 기본 제공 분석 보고서을 검토하십시오. | Azure Front Door 프로필의 전체적인 보기를 통해 WAF 메트릭을 통한 트래픽 및 보안 보고서에 따라 향상된 기능을 제공합니다. |
| 가능한 경우 관리되는 TLS 인증서 사용합니다. | Azure Front Door는 인증서를 발급하고 관리할 수 있습니다. 이 기능은 인증서 갱신의 필요성을 없애고 유효하지 않거나 만료된 TLS 인증서로 인한 중단 위험을 최소화합니다. |
| 자동 프로비저닝 및 갱신을 위해 관리되는 인증서 지원과 함께 와일드카드 TLS 인증서를 사용합니다. 단일 인증서에서 여러 하위 도메인에 대해 자동 인증서 수명 주기 관리를 사용하도록 와일드카드 도메인에 대한 관리되는 인증서를 구성합니다. |
각 하위 도메인을 별도로 추가하거나 지정하기 위해 구성을 수정할 필요가 없습니다. 관리되는 와일드카드 인증서는 모든 하위 도메인에 대해 자동 프로비저닝 및 갱신을 제공하여 브랜드 상점 또는 서비스가 여러 개 있는 조직의 운영 오버헤드를 줄입니다. |
성능 효율성
성능 효율성은 용량을 관리하여 부하 증가하는 경우에도 사용자 환경을 유지 관리합니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.
성능 효율성 설계 원칙은 예상 사용량에 맞춰 용량 목표를 달성하기 위한 고차원 설계 전략을 제공합니다.
워크로드 디자인 검사 목록
성능 효율성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. Azure Front Door의 주요 성과 지표를 기반으로 하는 기준을 정의합니다.
예상 트래픽 패턴분석하여 용량을 계획합니다. 철저한 테스트를 수행하여 애플리케이션이 다른 부하에서 수행하는 방식을 이해합니다. 동시 트랜잭션, 요청 속도 및 데이터 전송과 같은 요소를 고려합니다.
해당 계획에 따라 SKU 선택 항목을 기반으로 합니다. 표준 SKU는 더 비용 효율적이며 보통 트래픽 시나리오에 적합합니다. 더 높은 부하가 예상되는 경우 프리미엄 SKU를 사용하는 것이 좋습니다.
성능 메트릭정기적으로 검토하여 성능 데이터를 분석합니다. Azure Front Door 보고서는 기술 수준에서 성능 지표 역할을 하는 다양한 메트릭에 대한 인사이트를 제공할 있습니다.
Azure Front Door 보고서를 사용하여 워크로드에 대한 실제 성능 목표를 설정합니다. 응답 시간, 처리량 및 오류 비율과 같은 요소를 고려합니다. 비즈니스 요구 사항 및 사용자 기대치에 맞게 대상을 조정합니다.
데이터 전송을 최적화합니다.
캐싱을 사용하여 이미지, 스타일시트, JavaScript 파일 또는 자주 변경되지 않는 콘텐츠와 같은 정적 콘텐츠를 제공하는 데 대기 시간을 줄입니다.
캐싱을 위해 애플리케이션을 최적화합니다. 클라이언트 및 프록시에서 콘텐츠를 캐시해야 하는 기간을 제어하는 애플리케이션에서 캐시 만료 헤더를 사용합니다. 캐시 유효성이 길면 원본 서버에 대한 요청 빈도가 낮아져 트래픽이 줄어들고 대기 시간이 줄어듭니다.
네트워크를 통해 전송되는 파일의 크기를 줄입니다. 파일이 작을수록 로드 시간이 빨라지고 사용자 환경이 향상됩니다.
애플리케이션의 백 엔드 요청 수를 최소화합니다.
예를 들어 웹 페이지에는 사용자 프로필, 최근 주문, 잔액 및 기타 관련 정보가 표시됩니다. 각 정보 집합에 대해 별도의 요청을 만드는 대신 디자인 패턴을 사용하여 여러 요청이 단일 요청으로 집계되도록 애플리케이션을 구성합니다.
여러 요청을 단일 TCP 연결로 결합할 수 있는 HTTP/2 프로토콜을 사용하도록 클라이언트를 업데이트합니다.
반복된 HTTP 요청 또는 폴링을 수행하는 대신 WebSocket 을 사용하여 실시간 전체 이중 통신을 지원합니다.
요청을 집계하여 프런트 엔드와 백 엔드 간에 더 적은 데이터를 보내고 클라이언트와 백 엔드 간의 연결 수를 줄여 오버헤드를 줄입니다. 또한 Azure Front Door는 더 적은 수의 요청을 처리하여 오버로드를 방지합니다.
헬스 프로브 사용을 최적화합니다.. 원본 출처 상태가 변경되는 경우에만 건강 프로브에서 건강 정보를 가져옵니다. 모니터링 정확도와 불필요한 트래픽 최소화 간의 균형을 조정합니다.
상태 프로브는 일반적으로 그룹 내에서 여러 원본의 상태를 평가하는 데 사용됩니다. Azure Front Door 원본 그룹에 하나의 원본만 구성된 경우 상태 프로브를 사용하지 않도록 설정하여 원본 서버에서 불필요한 트래픽을 줄입니다. 인스턴스가 하나뿐이므로 상태 프로브 상태는 라우팅에 영향을 주지 않습니다.
원본 라우팅 방법검토합니다. Azure Front Door는 대기 시간 기반, 우선 순위 기반, 가중치 및 세션 선호도 기반 라우팅을 포함하여 원본에 대한 다양한 라우팅 방법을 제공합니다. 이러한 메서드는 애플리케이션의 성능에 크게 영향을 줍니다. 시나리오에 가장 적합한 트래픽 라우팅 옵션에 대한 자세한 내용은 원본 트래픽 라우팅 방법을 참조하세요.
원본 서버위치를 검토합니다. 원본 서버의 위치는 애플리케이션의 응답성에 영향을 줍니다. 원본 서버는 사용자와 더 가까워야 합니다. Azure Front Door를 사용하면 특정 위치의 사용자가 가장 가까운 Azure Front Door 진입점에 액세스할 수 있습니다. 성능상의 이점은 더 빠른 사용자 환경, Azure Front Door의 대기 시간 기반 라우팅의 더 나은 사용, 사용자에게 더 가까운 콘텐츠를 저장하는 캐싱을 사용하여 데이터 전송 시간을 최소화하는 것입니다.
구성 권장 사항
| Recommendation | Benefit |
|---|---|
|
캐싱을 사용하도록 설정합니다. 캐싱하기 위해쿼리 문자열을 최적화할 수 있습니다. 순수 정적 콘텐츠의 경우 쿼리 문자열을 무시하여 캐시 사용을 최대화합니다. 애플리케이션에서 쿼리 문자열을 사용하는 경우 캐시 키에 포함하는 것이 좋습니다. 캐시 키에 쿼리 문자열을 포함하면 Azure Front Door가 구성에 따라 캐시된 응답 또는 기타 응답을 제공할 수 있습니다. |
Azure Front Door는 네트워크 가장자리에서 콘텐츠를 캐시하는 강력한 콘텐츠 배달 네트워크 솔루션을 제공합니다. 캐싱은 원본 서버의 부하를 줄이고 네트워크 간 데이터 이동을 줄여 대역폭 사용량을 오프로드하는 데 도움이 됩니다. |
| 다운로드 가능한 콘텐츠에 액세스할 때 파일 압축 사용합니다. | Azure Front Door의 압축은 최적의 형식으로 콘텐츠를 제공하고, 페이로드가 더 작으며, 사용자에게 콘텐츠를 더 빠르게 전달하는 데 도움이 됩니다. |
Azure Front Door에서 상태 프로브를 구성할 때 HEAD 요청 대신 GET 요청을 사용하는 것이 좋습니다. 상태 프로브는 콘텐츠가 아닌 상태 코드만 읽습니다. |
HEAD 요청을 사용하면 전체 콘텐츠를 가져오지 않고 상태 변경을 쿼리할 수 있습니다. |
| 동일한 사용자의 요청을 동일한 원본 서버로 전송해야 하는 경우 세션 선호도 를 사용하도록 설정해야 하는지 여부를 평가합니다. 안정성 관점에서 이 방법은 권장하지 않습니다. 이 옵션을 사용하는 경우 애플리케이션은 사용자 세션을 방해하지 않고 정상적으로 복구해야 합니다. 또한 여러 원본 간에 트래픽을 균등하게 분산하는 유연성을 제한하므로 부하 분산에서 타협이 발생합니다. |
특히 애플리케이션이 상태 정보를 로컬로 유지 관리하는 경우 사용자 세션에 대한 성능을 최적화하고 연속성을 유지 관리합니다. |
Azure 정책
Azure는 Azure Front Door 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 이전 권장 사항 중 일부는 Azure Policy를 통해 감사할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.
- Azure Front Door 프로필에서 관리되는 WAF 규칙 및 Private Link를 지원하려면 프리미엄 계층이 필요합니다.
- 버전 1.2인 최소 TLS 버전을 사용해야 합니다.
- Azure Front Door Premium과 Azure PaaS 서비스 간에 안전한 프라이빗 연결이 필요합니다.
- 리소스 로그를 사용하도록 설정해야 합니다. WAF는 요청 본문 검사를 사용하도록 설정해야 합니다.
- 정책을 사용하여 WAF 규칙 집합을 적용해야 합니다. 예를 들어 봇 보호를 사용하도록 설정하고 속도 제한 규칙을 설정해야 합니다.
포괄적인 거버넌스를 위해 Azure Content Delivery Network 대한 기본 제공 정의 및 azure Policy 기본 제공 정책 정의 나열된 기타 Azure Front Door 정책을 검토합니다.
Azure Advisor 권장 사항
Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다.
자세한 내용은 Azure Advisor를 참조하세요.
예제 아키텍처
주요 권장 사항을 보여 주는 기본 아키텍처: 다중 지역 클러스터를 위한 AKS 기본 사례입니다.
관련 콘텐츠
- Azure 프론트 도어
- Azure Front Door 대한 모범 사례