Azure Application Gateway v2는 애플리케이션 계층에서 작동하는 웹 트래픽 부하 분산 장치입니다. Application Gateway는 HTTP 요청의 특성에 따라 웹 애플리케이션에 대한 트래픽을 관리합니다. 고급 라우팅 기능이 있고 향상된 보안 및 확장성이 필요한 시나리오에 Application Gateway를 사용합니다.
이 문서에서는 설계자로서 네트워킹 옵션을 검토하고 워크로드에 대한 웹 트래픽 부하 분산 장치로 Application Gateway를 선택했다고 가정합니다. 이 문서의 지침은 Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.
중요합니다
이 가이드를 사용하는 방법
각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록 있습니다.
또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 Application Gateway 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.
주요 권장 사항을 보여주는 기본 아키텍처: 고가용성 및 영역 간 중복 웹 애플리케이션의 기본 아키텍처입니다.
기술 범위
이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.
- Application Gateway v2
- Application Gateway의 WAF(웹 애플리케이션 방화벽)
신뢰도
안정성 기둥의 목적은 충분한 복원력을 구축하고 오류로부터 빠르게 복구할 수 있는 능력을 통해 지속적인 기능을 제공하는 것입니다.
신뢰성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 상위 디자인 전략을 제공합니다.
디자인 검사 목록
안정성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. Application Gateway의 기능과 종속성을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
워크로드에 Application Gateway v1이 특별히 필요하지 않은 경우 새 배포에서 Application Gateway v2를 사용합니다.
디자인에 중복성을 구축하십시오. 가용성 영역에 Application Gateway 인스턴스를 분산하여 내결함성을 개선하고 중복성을 구축합니다. 한 영역이 실패하면 트래픽이 다른 영역으로 이동합니다. 자세한 내용은 가용성 영역 및 지역 사용에 대한권장 사항을 참조하세요.
Application Gateway에 액세스하거나 추가로 변경하기 전에 규칙 업데이트 및 기타 구성 변경에 대한 추가 시간을 계획합니다. 예를 들어 기존 연결을 드레이닝해야 하므로 백 엔드 풀에서 서버를 제거하는 데 추가 시간이 필요할 수 있습니다.
(시스템 건강 상태를 확인하기 위한) 엔드포인트 모니터링 패턴을 구현합니다. 애플리케이션은 애플리케이션의 요청 처리에 필요한 중요한 서비스 및 종속성의 상태를 집계하는 상태 엔드포인트를 노출하도록 해야 합니다. Application Gateway 상태 프로브는 엔드포인트를 사용하여 백 엔드 풀의 서버 상태를 검색합니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴참조하세요.
상태 프로브에 대한 간격 및 임계값 설정의 영향을 평가합니다. 상태 프로브는 설정된 간격으로 구성된 엔드포인트에 요청을 보냅니다. 그리고 백 엔드는 비정상으로 표시되기 전에 제한된 수의 실패한 요청을 허용합니다. 이러한 설정은 충돌할 수 있으며 이는 절충을 제공합니다.
간격이 높을수록 서비스에 대한 부하가 높아질 수 있습니다. 각 Application Gateway 인스턴스는 자체 상태 프로브를 보내므로 30초마다 100개의 인스턴스는 30초마다 100개의 요청과 같습니다.
간격이 낮을수록 상태 프로브가 중단을 감지하기까지의 시간이 늘어나게 됩니다.
낮고 불안정한 임계값은 짧고 일시적인 오류가 백 엔드를 종료시킬 가능성을 높입니다.
임계값이 높을수록 백 엔드가 회전에서 벗어나는 데 걸리는 시간이 증가합니다.
상태 엔드포인트를 통해 다운스트림 종속성을 확인합니다. 오류를 격리하기 위해 각 백 엔드에는 고유한 종속성이 있을 수 있습니다. 예를 들어 Application Gateway 뒤에서 호스트하는 애플리케이션에는 여러 백 엔드가 있을 수 있으며 각 백 엔드는 다른 데이터베이스 또는 복제본에 연결됩니다. 이러한 종속성이 실패하면 애플리케이션이 작동할 수 있지만 유효한 결과를 반환하지는 않습니다. 이러한 이유로 상태 엔드포인트는 모든 종속성의 유효성을 검사하는 것이 이상적입니다.
상태 엔드포인트에 대한 각 호출에 직접 종속성 호출이 있는 경우 해당 데이터베이스는 하나의 쿼리 대신 30초마다 100개의 쿼리를 받습니다. 과도한 쿼리를 방지하기 위해 상태 엔드포인트는 짧은 기간 동안 종속성의 상태를 캐시해야 합니다.
Application Gateway 제한 사항 및 안정성에 영향을 줄 수 있는 알려진 문제를 고려합니다. Application Gateway FAQ를 검토하여 설계별 동작, 시공 중인 수정 사항, 플랫폼 제한 사항 및 가능한 해결 방법 또는 완화 전략에 대한 중요한 정보를 확인합니다. Application Gateway 전용 서브넷에서 UDR을 사용하지 마세요.
Application Gateway의 백 엔드 연결에 영향을 줄 수 있는 디자인에서 SNAT(원본 네트워크 주소 변환) 포트 제한을 고려합니다. 일부 요소는 Application Gateway가 SNAT 포트 제한에 도달하는 방식에 영향을 줍니다. 예를 들어 백 엔드가 공용 IP 주소인 경우 자체 SNAT 포트가 필요합니다. SNAT 포트 제한을 방지하려면 다음 옵션 중 하나를 수행할 수 있습니다.
각 Application Gateway에 대한 인스턴스 수를 늘입니다.
더 많은 IP 주소를 갖도록 백 엔드를 확장합니다.
백 엔드를 동일한 가상 네트워크로 이동하고 백 엔드에 개인 IP 주소를 사용합니다.
Application Gateway가 SNAT 포트 제한에 도달하면 RPS(초당 요청 수)에 영향을 줍니다. 예를 들어 Application Gateway는 백 엔드에 대한 새 연결을 열 수 없으며 요청이 실패합니다.
권장 사항
| 추천 | 이익 |
|---|---|
|
영역 인식 구성에서 Application Gateway 인스턴스를 배포합니다. 모든 지역에서 이 기능을 제공하는 것은 아니므로 지역별 지원에서 영역 중복성을 확인합니다. |
여러 인스턴스를 영역에 분산하는 경우 워크로드는 단일 영역의 오류를 견딜 수 있습니다. 사용할 수 없는 영역이 있는 경우 트래픽이 다른 영역의 정상 인스턴스로 자동으로 전환되어 애플리케이션 안정성이 유지됩니다. |
| Application Gateway 상태 프로브를 사용하여 백 엔드 사용 불가를 감지합니다. | 헬스 프로브는 트래픽을 처리할 수 있는 백 엔드로만 트래픽이 라우팅되도록 보장합니다. Application Gateway는 백 엔드 풀에 있는 모든 서버의 상태를 모니터링하고 비정상으로 간주되는 모든 서버로의 트래픽 전송을 자동으로 중지합니다. |
| 클라이언트가 애플리케이션에 너무 많은 트래픽을 보낼 수 없도록 Azure WAF에 대한 속도 제한 규칙을 구성합니다. | 속도 제한을 통해 재시도 폭풍과 같은 문제를 피하십시오. |
|
백 엔드 상태 보고서가 제대로 작동하고 올바른 로그 및 메트릭을 생성할 수 있도록 Application Gateway에서 UDR을 사용하지 마세요. Application Gateway 서브넷에서 UDR을 사용해야 하는 경우 지원되는 UDR을 참조하세요. |
Application Gateway 서브넷의 UDR은 몇 가지 문제를 일으킬 수 있습니다. 백 엔드 상태, 로그 및 메트릭을 볼 수 있도록 Application Gateway 서브넷에서 UDR을 사용하지 마세요. |
| 백 엔드 애플리케이션의 수신기 및 트래픽 특성과 일치하도록 IdleTimeout 설정을 구성합니다. 기본값은 4분입니다. 최대 30분까지 구성할 수 있습니다. 자세한 내용은 부하 분산 장치 TCP(Transmission Control Protocol) 재설정 및 유휴 시간 제한을 참조하세요. |
백 엔드와 일치하도록 IdleTimeout 을 설정합니다. 이 설정을 사용하면 백 엔드가 요청에 응답하는 데 4분 이상 걸리는 경우 Application Gateway와 클라이언트 간의 연결이 열린 상태로 유지됩니다. 이 설정을 구성하지 않으면 연결이 닫히고 클라이언트에 백 엔드 응답이 표시되지 않습니다. |
안전
보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보증을 제공하는 것입니다.
보안 디자인 원칙은 Application Gateway의 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
보안 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 상태를 개선합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
에지에서 일반적인 위협을 차단합니다. WAF는 Application Gateway와 통합됩니다. 프런트 엔드에서 WAF 규칙을 사용하도록 설정하여 공격 원본에 가까운 네트워크 에지에서 일반적인 악용 및 취약성으로부터 애플리케이션을 보호합니다. 자세한 내용은 Application Gateway의 WAF를 참조하세요.
WAF가 Application Gateway 용량 변경에 미치는 영향을 이해합니다. WAF를 사용하도록 설정하면 Application Gateway:
모든 요청이 완전히 도착할 때까지 버퍼링합니다.
요청이 핵심 규칙 집합의 규칙 위반과 일치하는지 확인합니다.
백 엔드 인스턴스에 패킷을 전달합니다.
30MB 이상의 대용량 파일 업로드는 상당한 대기 시간을 발생할 수 있습니다. WAF를 사용하도록 설정하면 Application Gateway 용량 요구 사항이 변경되므로 이 메서드를 먼저 올바르게 테스트하고 유효성을 검사하는 것이 좋습니다.
Azure Front Door 및 Application Gateway를 사용하여 HTTP 또는 HTTPS 애플리케이션을 보호하는 경우 Azure Front Door에서 WAF 정책을 사용하고 Application Gateway를 잠가 Azure Front Door에서만 트래픽을 수신합니다. 특정 시나리오에서는 Application Gateway에서 특별히 규칙을 구현하도록 강제할 수 있습니다. 예를 들어 ModSec CRS 2.2.9, CRS 3.0 또는 CRS 3.1 규칙이 필요한 경우 Application Gateway에서만 이러한 규칙을 구현할 수 있습니다. 반대로 Azure Front Door는 속도 제한 및 지역 필터링을 지원하며 Application Gateway는 이러한 기능을 지원하지 않습니다.
컨트롤 플레인에 대한 권한 있는 액세스만 허용합니다. Application Gateway RBAC(역할 기반 액세스 제어) 를 사용하여 필요한 ID로만 액세스를 제한합니다.
전송 중인 데이터를 보호합니다. TLS(엔드투엔드 전송 계층 보안), TLS 종료 및 엔드투엔드 TLS 암호화를 사용하도록 설정합니다. 백 엔드 트래픽을 다시 암호화하는 경우 백 엔드 서버 인증서에 루트 및 중간 CA(인증 기관)가 모두 포함되어 있는지 확인합니다.
잘 알려진 CA를 사용하여 백 엔드 서버의 TLS 인증서를 발급합니다. 신뢰할 수 있는 CA를 사용하여 인증서를 발급하지 않는 경우 Application Gateway는 신뢰할 수 있는 CA 인증서를 찾을 때까지 확인합니다. 신뢰할 수 있는 CA를 찾은 경우에만 보안 연결을 설정합니다. 그렇지 않으면 Application Gateway는 백 엔드를 비정상 상태로 표시합니다.
애플리케이션 비밀을 보호합니다. Azure Key Vault를 사용하여 보안 강화 및 인증서 갱신 및 회전 프로세스를 용이하게 하기 위해 TLS 인증서를 저장합니다.
공격 표면을 줄이고 구성을 강화합니다. 필요하지 않은 기본 구성을 제거하고 Application Gateway 구성을 강화하여 보안 제어를 강화합니다. Application Gateway에 대한 모든 NSG(네트워크 보안 그룹) 제한을 준수합니다.
백 엔드 풀 리소스에 적절한 DNS(도메인 이름 시스템) 서버를 사용합니다. 백 엔드 풀에 확인 가능한 FQDN(정규화된 도메인 이름)이 포함된 경우 DNS 확인은 프라이빗 DNS 영역 또는 사용자 지정 DNS 서버(가상 네트워크에 구성된 경우)를 기반으로 하거나 기본 Azure 제공 DNS를 사용합니다.
비정상적인 활동을 모니터링합니다. 정기적으로 로그를 검토하여 공격과 오탐을 확인하십시오. Application Gateway에서 Microsoft Sentinel과 같은 조직의 중앙 집중식 SIEM(보안 정보 및 이벤트 관리)으로 WAF 로그를 보내 위협 패턴을 감지하고 워크로드 디자인에 예방 조치를 통합합니다.
권장 사항
| 추천 | 이익 |
|---|---|
| 보안 강화를 위한 TLS 정책을 설정합니다. 최신 TLS 정책 버전을 사용하는지 확인합니다. | 최신 TLS 정책을 사용하여 TLS 1.2 및 더 강력한 암호화 사용을 적용합니다. TLS 정책에는 TLS 프로토콜 버전 및 암호화 도구 모음의 제어와 TLS 핸드셰이크가 암호화를 사용하는 순서도 포함됩니다. |
| TLS 종료에 Application Gateway를 사용합니다. | 다른 백 엔드로 이동하는 요청이 각 백 엔드에 다시 인증할 필요가 없으므로 성능이 향상됩니다. 게이트웨이는 요청 콘텐츠에 액세스하고 지능형 라우팅 결정을 내릴 수 있습니다. 인증서 관리를 간소화하는 Application Gateway에 인증서를 설치하기만 하면 됩니다. |
| Application Gateway를 Key Vault와 통합하여 TLS 인증서를 저장합니다. | 이 방법은 보다 강력한 보안, 역할 및 책임의 손쉽게 분리, 관리되는 인증서 지원 및 더 쉬운 인증서 갱신 및 회전 프로세스를 제공합니다. |
| Application Gateway에 대한 모든 NSG 제한을 준수합니다. | Application Gateway 서브넷은 NSG를 지원하지만 몇 가지 제한 사항이 있습니다. 예를 들어 특정 포트 범위와의 일부 통신은 금지됩니다. 이러한 제한 사항의 의미를 이해해야 합니다. |
비용 최적화
비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하면서 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.
비용 최적화 디자인 원칙은 Application Gateway 및 해당 환경과 관련된 기술 설계에서 필요에 따라 이러한 목표를 달성하고 절충하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
투자 비용 최적화 을 위한 디자인 검토 체크리스트를 기반으로 디자인 전략을 시작하세요. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.
Application Gateway 및 WAF 가격 책정에 익숙해지세요. 적절한 크기의 옵션을 선택하여 워크로드 용량 수요를 충족하고 리소스를 낭비하지 않고 예상 성능을 제공합니다. 비용을 예측하려면 가격 계산기를 사용합니다.
사용되지 않는 Application Gateway 인스턴스를 제거하고 사용되지 않는 인스턴스를 최적화합니다. 불필요한 비용을 방지하려면 빈 백 엔드 풀이 있는 Application Gateway 인스턴스를 식별하고 삭제합니다. Application Gateway 인스턴스를 사용하지 않을 때 중지합니다.
Application Gateway 인스턴스의 크기 조정 비용을 최적화합니다. 크기 조정 전략을 최적화하고 wokload의 요구를 줄이려면 크기 조정 비용을 최적화하기 위한 권장 사항을 참조하세요.
애플리케이션 트래픽 요구 사항에 따라 서비스를 확장하거나 확장하려면 Application Gateway v2에서 자동 크기 조정을 사용합니다.
Application Gateway 사용 메트릭을 모니터링하고 해당 비용 영향을 이해합니다. 추적된 메트릭에 따라 Application Gateway의 요금제 인스턴스에 대한 Azure 요금이 청구됩니다. 다양한 메트릭 및 용량 단위를 평가하고 비용 드라이버를 결정합니다. 자세한 내용은 Microsoft Cost Management를 참조하세요.
권장 사항
| 추천 | 이익 |
|---|---|
| Application Gateway 인스턴스를 사용하지 않을 때 중지합니다. 자세한 내용은 Stop-AzApplicationGateway 및 Start-AzApplicationGateway를 참조하세요. | 중지된 Application Gateway 인스턴스에는 비용이 발생하지 않습니다. 지속적으로 실행되는 Application Gateway 인스턴스에는 불필요한 비용이 발생할 수 있습니다. 사용 패턴을 평가하고 필요하지 않은 경우 인스턴스를 중지합니다. 예를 들어 개발/테스트 환경에서 업무 시간 후 사용량이 낮을 것으로 예상합니다. |
| 다음과 같은 주요 비용 드라이버 Application Gateway 메트릭을 모니터링합니다. - 예상 청구 용량 단위입니다. - 청구 가능한 용량 단위를 수정했습니다. - 현재 용량 단위입니다. 대역폭 비용을 고려해야 합니다. |
이러한 메트릭을 사용하여 프로비전된 인스턴스 수가 들어오는 트래픽의 양과 일치하는지 확인하고 할당된 리소스를 완전히 활용해야 합니다. |
운영 우수성
운영 우수성은 주로 개발 사례, 관찰 가능성 및 릴리스 관리를 절차에 중점을 둡니다.
운영 우수성 원칙은 워크로드의 운영 요구 사항에 대한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
Application Gateway와 관련된 준수성, 테스트 및 배포에 대한 프로세스를 정의하기 위한 운영 우수성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.
Application Gateway 및 WAF에서 진단을 사용하도록 설정합니다. 워크로드의 상태를 모니터링하고, 워크로드 성능 및 안정성의 추세를 식별하고, 문제를 해결할 수 있도록 로그 및 메트릭을 수집합니다. 전반적인 모니터링 접근 방식을 디자인하려면 모니터링 시스템을 디자인하고 만들기 위한 권장 사항을 참조하세요.
용량 메트릭을 사용하여 프로비전된 Application Gateway 용량의 사용을 모니터링합니다. Application Gateway 또는 백 엔드에서 용량 문제 또는 기타 문제를 알리도록 메트릭에 대한 경고를 설정합니다. 진단 로그를 사용하여 Application Gateway 인스턴스의 문제를 관리하고 해결합니다.
Azure Monitor Network Insights를 사용하여 Application Gateway를 비롯한 네트워크 리소스에 대한 상태 및 메트릭을 포괄적으로 볼 수 있습니다. 중앙 집중식 모니터링을 사용하여 문제를 신속하게 식별 및 해결하고, 성능을 최적화하고, 애플리케이션의 안정성을 보장합니다.
Azure Advisor에서 Application Gateway 권장 사항을 모니터링합니다. Application Gateway 인스턴스에 대한 중요한 새 권장 사항이 있는 경우 팀에 알리도록 경고를 구성합니다. Advisor는 범주, 영향 수준 및 권장 사항 유형과 같은 속성을 기반으로 권장 사항을 생성합니다.
권장 사항
| 추천 | 이익 |
|---|---|
| CPU 사용량 및 컴퓨팅 단위 사용량과 같은 용량 메트릭이 권장 임계값을 초과할 때 팀에 알리도록 경고를 구성합니다. 용량 메트릭에 따라 포괄적인 경고 집합을 구성하려면 Application Gateway 트래픽이 많은 지원을 참조하세요. |
메트릭이 임계값을 초과할 때 경고를 설정하여 사용량이 증가하는 시기를 알 수 있도록 합니다. 이 방법을 사용하면 워크로드에 필요한 변경 내용을 구현할 수 있는 충분한 시간을 확보하고 성능 저하 또는 중단을 방지할 수 있습니다. |
| Application Gateway 또는 백 엔드에서 문제를 나타내는 메트릭에 대해 팀에 알리도록 경고를 구성합니다. 다음 경고를 평가하는 것이 좋습니다. - 비정상인 호스트의 수 - 응답 상태(예: 4xx 및 5xx 오류) - 백 엔드 응답 상태(예: 4xx 및 5xx 오류) - 백 엔드 마지막 바이트 응답 시간 - Application Gateway 총 시간 자세한 내용은 Application Gateway에 대한 메트릭을 참조하세요. |
경고를 사용하여 팀이 적시에 문제에 대응하고 문제 해결을 용이하게 할 수 있도록 합니다. |
| Application Gateway 및 WAF에서 진단 로그 를 사용하도록 설정하여 방화벽 로그, 성능 로그 및 액세스 로그를 수집합니다. | 로그를 사용하여 Application Gateway 인스턴스 및 워크로드 문제를 검색, 조사 및 해결하는 데 도움이 됩니다. |
| Advisor를 사용하여 Key Vault 구성 문제를 모니터링합니다. Application Gateway에 대한 Azure Key Vault 문제를 해결하라는 권장 사항이 표시되면 팀에 알리도록 경고를 설정합니다. | Advisor 경고를 사용하여 최신 상태를 유지하고 문제를 즉시 해결합니다. 컨트롤 플레인 또는 데이터 평면 관련 문제를 방지합니다. Application Gateway는 4시간마다 연결된 Key Vault 인스턴스에서 갱신된 인증서 버전을 확인합니다. 잘못된 Key Vault 구성으로 인해 인증서 버전에 액세스할 수 없는 경우 해당 오류를 기록하고 해당 Advisor 권장 사항을 푸시합니다. |
성능 효율성
성능 효율성은 부하 가 증가하는 경우에도 용량을 관리하여 사용자 경험을 유지합니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.
성능 효율성 설계 원칙은 예상 사용량에 맞춰 용량 목표를 달성하기 위한 고차원 설계 전략을 제공합니다.
디자인 검사 목록
워크로드 요구 사항을 지원하기 위해 Application Gateway의 용량 요구 사항을 예측합니다. Application Gateway v2의 자동 크기 조정 기능을 활용합니다. 최소 및 최대 인스턴스 수에 적절한 값을 설정합니다. Application Gateway에 필요한 전용 서브넷의 크기를 적절하게 조정합니다. 자세한 내용은 용량 계획대한
권장 사항을 참조하세요. Application Gateway v2는 CPU, 네트워크 처리량 및 현재 연결과 같은 여러 측면을 기반으로 확장됩니다. 대략적인 인스턴스 수를 확인하려면 다음 메트릭을 고려합니다.
현재 컴퓨팅 단위: 이 메트릭은 CPU 사용량을 나타냅니다. 하나의 Application Gateway 인스턴스는 약 10개의 컴퓨팅 단위와 같습니다.
처리량: Application Gateway 인스턴스는 약 500Mbps의 처리량을 제공할 수 있습니다. 이 데이터는 페이로드 유형에 따라 달라집니다.
인스턴스 수를 계산할 때 이 수식을 고려합니다.
인스턴스 수를 예측한 후 해당 값을 최대 인스턴스 수와 비교합니다. 이 비교를 사용하여 사용 가능한 최대 용량에 얼마나 근접한지 확인할 수 있습니다.
자동 크기 조정 및 성능 이점을 위한 기능을 활용합니다. v2 SKU는 트래픽이 증가함에 따라 Application Gateway를 확장하는 자동 크기 조정을 제공합니다. v1 SKU에 비해 v2 SKU에는 워크로드의 성능을 향상시키는 기능이 있습니다. 예를 들어 v2 SKU는 더 나은 TLS 오프로드 성능, 더 빠른 배포 및 업데이트 시간 및 영역 중복성 지원을 제공합니다. 자세한 내용은 Application Gateway v2 및 WAF v2 크기 조정을 참조 하세요.
Application Gateway v1을 사용하는 경우 Application Gateway v2로 마이그레이션하는 것이 좋습니다. 자세한 내용은 V1에서 v2로 Application Gateway 및 WAF 마이그레이션을 참조하세요.
권장 사항
| 추천 | 이익 |
|---|---|
| 예상 인스턴스 수, 실제 Application Gateway 자동 크기 조정 추세 및 애플리케이션 패턴에 따라 최소 인스턴스 수를 최적 수준으로 설정합니다. 지난 달의 현재 컴퓨팅 단위를 확인합니다. 이 메트릭은 게이트웨이의 CPU 사용량을 나타냅니다. 최소 인스턴스 수를 정의하려면 최대 사용량을 10으로 나눕니다. 예를 들어 지난 달의 평균 현재 컴퓨팅 단위가 50인 경우 최소 인스턴스 수를 5로 설정합니다. |
Application Gateway v2의 경우 자동 크기 조정은 추가 인스턴스 집합이 트래픽을 처리할 준비가 되기까지 약 3~5분이 걸립니다. 이 시간 동안 Application Gateway의 트래픽 급증이 짧으면 일시적인 대기 시간 또는 트래픽 손실이 예상됩니다. |
|
최대 자동 크기 조정 인스턴스 수를 가능한 최대 125개 인스턴스로 설정합니다. Application Gateway 전용 서브넷에 증가된 인스턴스 집합을 지원하기에 충분한 사용 가능한 IP 주소가 있는지 확인합니다. 트래픽 요구 사항에 125개 이상의 인스턴스가 필요한 경우 Application Gateway 앞에서 Azure Traffic Manager 또는 Azure Front Door를 사용할 수 있습니다. 자세한 내용은 Private Link를 사용하여 Azure Application Gateway에 Azure Front Door Premium 연결 및 Azure Traffic Manager에서 Azure App Gateway 사용을 참조하세요. |
Application Gateway는 애플리케이션에 대한 증가된 트래픽을 처리하기 위해 필요에 따라 스케일 아웃할 수 있습니다. 이 설정은 소비된 용량에 대해서만 비용을 지불하므로 비용이 증가하지 않습니다. |
| Application Gateway 전용 서브넷의 크기를 적절하게 조정합니다. Application Gateway v2 배포에는 /24 서브넷을 사용하는 것이 좋습니다. 동일한 서브넷에 다른 Application Gateway 리소스를 배포하려는 경우 최대 인스턴스 수에 필요한 추가 IP 주소를 고려합니다. 서브넷 크기 조정에 대한 자세한 고려 사항은 Application Gateway 인프라 구성을 참조하세요. |
/24 서브넷을 사용하여 Application Gateway v2 배포에 필요한 모든 IP 주소를 지원합니다. Application Gateway는 프라이빗 프런트 엔드 IP를 구성하는 경우 각 인스턴스에 대해 하나의 개인 IP 주소와 다른 개인 IP 주소를 사용합니다. Standard_v2 또는 WAF_v2 SKU는 최대 125개의 인스턴스를 지원할 수 있습니다. Azure는 내부 사용을 위해 각 서브넷에 5개의 IP 주소를 예약합니다. |
Azure 정책
Azure는 App Service 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. Azure 정책 집합은 이전 권장 사항 중 일부를 감사할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.
Application Gateway에 WAF를 사용하도록 설정해야 합니다. 들어오는 트래픽에 대한 다른 검사 계층을 추가하려면 공용 웹 애플리케이션 앞에 WAF를 배포합니다. WAF는 웹 애플리케이션에 대한 중앙 집중식 보호를 제공합니다. SQL 삽입, 사이트 간 스크립팅, 로컬 및 원격 파일 실행과 같은 일반적인 악용 및 취약성을 방지하는 데 도움이 됩니다. 사용자 지정 규칙을 사용하여 국가 또는 지역, IP 주소 범위 및 기타 HTTP 또는 HTTPS 매개 변수에 따라 웹 애플리케이션에 대한 액세스를 제한할 수도 있습니다.
WAF는 Application Gateway에 대해 지정된 모드를 사용해야 합니다. Application Gateway에 대한 모든 WAF 정책이 검색 또는 방지 모드를 사용하는지 확인합니다.
Azure DDoS Protection을 사용하도록 설정해야 합니다. 공용 IP가 있는 Application Gateway를 포함하는 서브넷이 있는 모든 가상 네트워크에 대해 DDoS Protection을 사용하도록 설정합니다.
포괄적인 거버넌스를 위해 네트워킹에 영향을 줄 수 있는 Azure Policy 기본 제공 정의 및 기타 정책을 검토합니다.
Azure Advisor 권장 사항
Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다. 다음은 Application Gateway의 안정성, 보안, 비용 효율성, 성능 및 운영 우수성을 개선하는 데 도움이 되는 몇 가지 권장 사항입니다.