Application Gateway에 대한 질문과 대답

참고

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Az로 마이그레이션을 참조하세요.

다음은 Azure Application Gateway에 대해 자주 묻는 질문입니다.

일반

Application Gateway란 무엇인가요?

Azure Application Gateway는 애플리케이션 제공 컨트롤러를 서비스로 제공합니다. 애플리케이션에 다양한 레이어 7 부하 분산 기능을 제공합니다. 이 서비스는 Azure에서 관리하는 고가용성의 확장성 있는 완전 관리형 서비스입니다.

Application Gateway가 지원하는 기능은 무엇인가요?

Application Gateway는 자동 스케일링, TLS 오프로딩, 엔드투엔드 TLS, 웹 애플리케이션 방화벽(WAF), 쿠키 기반 세션 선호도, URL 경로 기반 라우팅, 다중 사이트 호스팅 및 여러 기능을 제공합니다. 지원되는 기능의 전체 목록을 보려면 Application Gateway 소개를 참조하세요.

Application Gateway와 Azure Load Balancer는 어떤 차이가 있나요?

Application Gateway는 웹 트래픽(HTTP, HTTPS, WebSocket, HTTP/2) 전용 레이어 7 load balancer 장치입니다. TLS 종료를 지원하며, 쿠키 기반 세션 선호도와 트래픽 부하 분산을 위해 라운드 로빈 방식을 사용합니다. 계층 4(TCP 또는 UDP)에서 트래픽 부하를 분산하는 데에는 Load Balancer 장치가 사용됩니다.

Application Gateway에서 지원하는 프로토콜은 무엇인가요?

Application Gateway는 HTTP, HTTPS, HTTP/2와 WebSocket을 지원합니다.

Application Gateway는 어떻게 HTTP/2를 지원하나요?

HTTP/2 지원을 참조하세요.

어떤 리소스가 백엔드 풀의 일부로 지원되나요?

지원되는 백 엔드 리소스를 참조하세요.

어떤 지역에서 Application Gateway를 사용할 수 있나요?

Application Gateway v1(표준 및 WAF)은 Azure의 모든 지역에서 제공됩니다. Microsoft Azure 및 Azure Government는 21Vianet에서 운영하며, 해당 환경에서도 사용할 수 있습니다.

Application Gateway v2(Standard_v2 및 WAF_v2) 가용성은 Application Gateway v2의 지원되는 지역을 참조하세요.

이 배포는 제 구독에만 해당되는 건가요, 아니면 다른 고객과도 공유되나요?

Application Gateway는 가상 네트워크에서 전용으로 배포됩니다.

Application Gateway는 HTTP에서 HTTPS로 리디렉션을 지원합니까?

리디렉션은 지원됩니다. Application Gateway 리디렉션 개요를 참조하세요.

수신기는 어떤 순서로 처리됩니까?

수신기 처리 순서를 참조하세요.

Application Gateway IP 및 DNS는 어디에서 확인할 수 있나요?

엔드포인트로 공용 IP 주소를 사용하는 경우, 공용 IP 주소 리소스에서 IP와 DNS 정보를 찾으세요. 아니면 Azure Portal의 애플리케이션 게이트웨이 개요 페이지에서 찾아볼 수도 있습니다. 내부 IP 주소를 사용하는 경우에는 개요 페이지에서 정보를 확인하시기 바랍니다. v1 SKU를 사용하는 경우 2023년 5월 1일 이후에 생성된 게이트웨이에는 공용 IP 리소스에 자동으로 연결되는 기본 DNS 이름이 없습니다. v2 SKU를 사용하는 경우, 공용 IP 리소스를 열어서 구성을 선택하세요. DNS 이름 레이블 필드(선택 사항) 를 활용하여 DNS 이름을 구성할 수 있습니다.

Keep-Alive 시간 제한과 TCP 유휴 시간 제한은 어떻게 설정해야 하나요?

Keep-Alive 시간 제한은 클라이언트가 영구 연결을 다시 사용하거나 닫기 전에 애플리케이션 게이트웨이가 대기하는 시간을 제어합니다. 즉, 다른 HTTP 요청을 보내기까지의 대기 시간을 의미합니다. TCP 유휴 시간 제한은 별다른 작업이 이루어지지 않을 때 TCP 연결을 얼마나 오래 유지할지를 결정합니다.

Application Gateway v1 및 v2 SKU에서 HTTP/1.1 연결의 Keep-Alive 제한 시간은 120초입니다. 개인 IP 주소는 TCP 유휴 시간 제한을 5분으로 설정할 수 없습니다. TCP 유휴 시간 제한은 Application Gateway v1 및 v2 SKU의 프런트 엔드 VIP(가상 IP)에서 기본적으로 4분입니다. v1, v2 Application Gateway 인스턴스의 TCP 유휴 시간 제한은 4분에서 30분 사이에서 구성 가능합니다. v1 및 v2 Application Gateway 인스턴스 모두 애플리케이션 게이트웨이의 공용 IP로 연결되므로, 포털의 공용 IP 구성 창에서 TCP 유휴 시간 제한을 변경해야 합니다. 다음 명령을 실행하여 PowerShell을 통해 공용 IP의 TCP 유휴 시간 제한 값을 설정할 수 있습니다.

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Application Gateway v2 SKU의 프런트 엔드 IP 주소에 HTTP/2를 연결하면 유휴 시간 제한이 180초로 설정되고, 사용자가 임의로 구성할 수는 없습니다.

충돌이나 예기치 않은 동작이 발생하지 않도록 TCP 유휴 시간 제한이 유지 시간 제한 이상으로 설정되었는지 확인합니다.

Application Gateway는 백엔드 서버와의 TCP 연결을 재사용하도록 설정되어 있습니까?

네. Application Gateway는 백엔드 서버와 기존 TCP 연결을 다시 설정하지 않고 재사용합니다.

내 Application Gateway 리소스의 이름을 변경할 수 있나요?

아니요. Application Gateway 리소스 이름은 변경이 불가능합니다. 새 리소스를 다른 이름으로 생성해야 합니다.

Application Gateway 리소스와 연결된 공용 IP가 삭제되었을 때 이를 복구할 수 있는 방법이 있습니까?

아니요. Application Gateway 리소스 또는 연결된 공용 IP는 삭제 후 복구가 불가능합니다. 새로운 리소스를 만들어야 합니다.

애플리케이션 게이트웨이의 수명 주기 중에 IP 또는 DNS 이름이 변경되나요?

Application Gateway v1 SKU에서 애플리케이션 게이트웨이를 중지 후 다시 시작하면 VIP가 변경될 수 있습니다. Application Gateway에 연결된 DNS 이름은 게이트웨이 사용 기간 동안 변경되지 않습니다. DNS 이름은 변경되지 않으므로 CNAME 별칭을 사용하여 해당 별칭이 애플리케이션 게이트웨이의 DNS 주소를 가리키도록 설정해야 합니다. Application Gateway v2 SKU에서 IP 주소는 고정되어 있으므로, 애플리케이션 게이트웨이를 사용하는 동안 IP 주소와 DNS 이름이 변경되지 않습니다.

Application Gateway에서 고정 IP를 지원하나요?

네. Application Gateway v2 SKU는 고정된 공용 IP 주소뿐만 아니라 내부 IP 주소도 지원합니다. v1 SKU는 내부 고정 IP를 지원합니다.

Application Gateway에서 게이트웨이에 여러 개의 공용 IP를 지원하나요?

애플리케이션 게이트웨이에서는 IP 프로토콜 하나당 공용 IP 주소를 하나만 지원합니다. 애플리케이션 게이트웨이가 DualStack으로 구성되면 IPv4와 IPv6 각각에 대해 하나의 공용 IP를 지원하므로 총 2개의 공용 IP를 사용할 수 있습니다.

Application Gateway에 대해 얼마나 큰 서브넷을 만들어야 하나요?

Application Gateway 서브넷 크기 고려 사항을 참조하세요.

두 개 이상의 Application Gateway 리소스를 단일 서브넷에 배포할 수 있습니까?

네. 지정된 Application Gateway 배포의 여러 인스턴스를 유지하는 것과 더불어, 다른 애플리케이션 게이트웨이 리소스가 있는 기존 서브넷에 또 다른 고유한 Application Gateway 리소스를 프로비저닝하는 것도 가능합니다.

단일 서브넷은 v2 및 v1 Application Gateway SKU를 둘 다 지원할 수 없습니다.

Application Gateway v2는 사용자 정의 경로를 지원하나요?

예, 그러나 특정 상황에서만 지원됩니다. 자세한 내용은 Application Gateway 인프라 구성을 참조하세요.

Application Gateway에서 x-forwarded-for 헤더를 지원하나요?

네. 요청 수정을 참조하세요.

Application Gateway 인스턴스를 배포하는 데 얼마나 걸립니까? application gateway 업데이트 중에도 계속 작동하나요?

새 Application Gateway v1 SKU 배포 시 프로비전하는 데 최대 20분이 걸릴 수 있습니다. 인스턴스 크기 또는 수를 변경해도 중단되지 않으며, 게이트웨이는 이 시간 동안 활성 상태를 유지합니다.

v2 SKU를 사용하는 대부분의 배포는 프로비저닝하는 데 약 6분이 소요됩니다. 하지만 배포 방식에 따라 처리 시간이 더 오래 걸릴 수도 있습니다. 예를 들어 여러 가용 영역에 다수의 인스턴스를 배포하면 6분 넘게 소요될 수 있습니다.

Exchange Server를 Application Gateway와 함께 백 엔드로 사용할 수 있나요?

Application Gateway는 미리 보기 기능을 통해 L4 프록시에서 TLS/TCP 프로토콜 프록시를 지원합니다.

Application gateway의 계층 7 프록시는 HTTP(S) 프로토콜을 사용하며, SMTP, IMAP, POP3와 같은 이메일 프로토콜은 지원하지 않습니다. 하지만 Outlook Web Access (OWA), ActiveSync, HTTP(S) 프로토콜을 사용하는 AutoDiscovery 트래픽과 같은 일부 지원 이메일 서비스는 계층 7 프록시를 사용해야 하므로 해당 트래픽이 반드시 통과하도록 설정해야 합니다. (참고: WAF SKU를 사용하는 경우에는 WAF 규칙에서 제외해야 할 필요가 있을 수 있습니다.)

v1 SKU에서 v2 SKU로 마이그레이션할 때 사용할 수 있는 지침이 있나요?

네. 자세한 내용은 Azure Application Gateway 및 Web Application Firewall을 v1에서 v2로 마이그레이션을 참조하세요.

Application Gateway v1 SKU는 지원되나요?

네. Application Gateway v1 SKU는 계속 지원될 예정입니다. 해당 SKU의 기능 업데이트를 활용하려면 v2로 업그레이드하는 것이 좋습니다. v1과 v2 기능의 차이점에 대한 자세한 내용은 자동 확장 및 영역 중복을 지원하는 Application Gateway v2를 참조하세요. Application Gateway v1 SKU 배포를 v2로 수동 마이그레이션하는 방법은 v1-v2 마이그레이션 설명서에 자세히 나와 있습니다.

Application Gateway v2는 NTLM 또는 Kerberos 인증을 사용하는 프록시 요청을 지원합니까?

네. Application Gateway v2는 이제 NTLM 또는 Kerberos 인증을 사용하여 프록시 요청을 지원합니다. 자세한 내용은 전용 백 엔드 연결을 참조하세요.

요청이 내 애플리케이션으로 전달될 때 일부 헤더 값이 표시되지 않는 이유는 무엇인가요?

요청 헤더 이름에는 영숫자와 하이픈이 포함될 수 있습니다. 요청 헤더 이름에 다른 문자가 포함된 경우, 백엔드 대상으로 요청을 보낼 때 해당 헤더는 삭제됩니다. 응답 헤더 이름은 RFC 7230에 정의된 바에 따라 영숫자와 특정 기호를 포함할 수 있습니다.

Application Gateway는 SameSite 특성을 지원하는 선호도 쿠키를 사용하나요?

네. Chromium 브라우저v80 업데이트 에서는 SameSite 속성이 지정되지 않은 HTTP 쿠키를 SameSite=Lax로 취급하는 요구를 수용했습니다. 즉, 타사 컨텍스트에서는 브라우저가 Application Gateway의 선호도 쿠키를 전송하지 않습니다.

Application Gateway는 이 시나리오를 지원하고자 기존 ApplicationGatewayAffinity 쿠키 외에 ApplicationGatewayAffinityCORS 라는 쿠키를 하나 더 삽입합니다. 이 쿠키는 ApplicationGatewayAffinityCORS 의 쿠키와 비슷하지만, SameSite=None 와 Secure이라는 두 가지 특징이 더해졌습니다. 이러한 특성 덕분에 원본 간 요청 시에도 세션이 유지됩니다. 더 자세한 내용은 쿠키 기반 선호도 섹션을 참조하세요.

어떤 기준으로 수신기를 활성 또는 비활성 수신기로 분류하나요?

활성 수신기는 규칙 과 에 연결되어 백엔드 풀로 트래픽을 전송하는 역할을 합니다. 트래픽을 리디렉션만 하는 수신기는 활성 수신기가 아닙니다. 리디렉션 규칙과 연결된 수신기는 활성으로 간주되지 않습니다. 경로 기반 리디렉션 규칙의 경우, 해당 규칙에 포함된 모든 경로는 트래픽을 리디렉션해야만 수신기가 활성 상태로 유지됩니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건에서 개별 구성 요소 제한을 참조하세요.

성능

Application Gateway는 고가용성과 확장성을 어떤 방식으로 지원하나요?

Application Gateway v1 SKU는 인스턴스를 2개 이상 배포하면 고가용성 시나리오를 지원합니다. Azure는 모든 인스턴스가 동시에 실패하지 않도록 업데이트 및 장애 도메인에 인스턴스를 배포합니다. v1 SKU는 로드를 공유하기 위해 동일한 게이트웨이의 여러 인스턴스를 추가하여 확장성을 지원합니다.

v2 SKU는 장애 도메인 및 업데이트 도메인에서 새 인스턴스가 자동으로 분산되도록 보장합니다. 중복 수준을 0으로 선택하면, 영역에 장애가 발생했을 때 복원력을 제공할 수 있도록 최신 인스턴스 또한 여러 가용 영역으로 분산됩니다.

데이터 센터에서 재해 복구 시나리오를 구현하려고 하는데, Application Gateway를 사용하는 방법을 알려주세요.

Azure Traffic Manager를 통해 여러 데이터 센터에 있는 여러 애플리케이션 게이트웨이에 트래픽 분산이 가능합니다.

Application Gateway는 연결 드레이닝을 지원하나요?

네. 중지 없이 백 엔드 풀 내에서 멤버를 변경하도록 연결 드레이닝을 설정할 수 있습니다. 자세한 내용은 Application Gateway 연결 드레이닝 섹션을 참조하세요.

Application Gateway는 자동 크기 조정을 지원합니까?

예, Application Gateway v2 SKU는 자동 크기 조정 기능을 지원합니다. 더 자세한 내용은 자동 스케일링 및 영역 중복 Application Gateway를 참조하세요.

수동 또는 자동 스케일 업/스케일 다운 시 가동 중지 시간이 발생하나요?

아니요. 인스턴스들은 업그레이드 도메인과 장애 도메인에 걸쳐 분산됩니다.

서비스 중단 없이 Standard에서 WAF SKU로 변경할 수 있나요?

네.

인스턴스 크기를 중단 없이 중간에서 큰 크기로 변경할 수 있나요?

네.

Maintenance

Application Gateway는 일반적인 유지 관리 작업을 어떻게 처리합니까?

Application Gateway에 대해 시작된 업데이트는 한 번에 하나의 업데이트 도메인 씩 순차적으로 적용됩니다. 각 업데이트 도메인의 인스턴스가 업데이트됨에 따라 다른 업데이트 도메인의 나머지 인스턴스는 계속해서 트래픽을 처리합니다. 업데이트가 시작되기 전에 다른 업데이트 도메인의 인스턴스에 대한 연결을 설정하는 데 도움이 되도록 최대 5분 동안 업데이트되는 인스턴스에서 활성 연결이 정상적으로 드레이닝됩니다. 현재 인스턴스 세트가 성공적으로 업그레이드되어야 업데이트 프로세스가 다음 인스턴스 세트로 넘어갑니다.

Azure Application Gateway는 기존 인스턴스를 오프라인으로 전환하지 않고 롤링 업그레이드 중에 새 인스턴스를 프로비전할 수 있는 기능인 MaxSurge도 지원합니다. 이를 통해 고객은 용량 저하 없이 최신 게이트웨이 버전으로 전환할 수 있습니다. MaxSurge는 Application Gateway에서 자동으로 사용하도록 설정되며 구성이 필요하지 않습니다.

메모: MaxSurge에서 사용하는 임시 인스턴스를 프로비전하려면 추가 IP 공간이 필요합니다. 업데이트 중에 충분한 IP 공간을 사용할 수 없는 경우 Application Gateway는 기존 업그레이드 방법으로 대체되므로 인스턴스 수에 따라 최대 용량이 감소할 수 있습니다.

구성

Application Gateway가 가상 네트워크에서 항상 배포되나요?

네. Application Gateway는 항상 가상 네트워크 서브넷에 배포됩니다. 이 서브넷은 애플리케이션 게이트웨이만 포함할 수 있습니다. 자세한 내용은 가상 네트워크 및 서브넷 요구 사항을 참조하세요.

Application Gateway는 가상 네트워크 외부 또는 구독 외부의 인스턴스와 통신할 수 있습니까?

IP 연결이 설정된 경우, Application Gateway는 현재 속해 있는 가상 네트워크 외부의 인스턴스와 통신할 수 있습니다. 또한 Application Gateway는 현재 속한 구독 외부의 인스턴스와 통신할 수 있습니다. 내부 IP를 백 엔드 풀 멤버로 사용하려면 가상 네트워크 피어링 또는 Azure VPN Gateway를 구성해야 합니다.

FQDN을 기반으로 하는 백엔드 서버의 IP 주소를 어떻게 업데이트해야 하나요?

Application Gateway 리소스는 DNS 확인자와 동일하게 백 엔드 서버 DNS 레코드의 Time to Live (TTL) 값을 적용합니다. 게이트웨이는 TTL이 만료되면 DNS 정보를 조회 후 업데이트합니다. 조회 과정에서 애플리케이션 게이트웨이가 응답을 받지 못하거나 DNS 레코드를 찾을 수 없을 때, 게이트웨이는 마지막으로 확인된 정상 DNS 값을 사용하여 트래픽을 처리합니다. 자세한 내용은 애플리케이션 게이트웨이의 작동 원리를 참조하세요.

가상 네트워크의 DNS 서버를 변경한 후 502 오류가 발생하거나 백엔드 서버가 비정상적으로 표시되는 원인은 무엇인가요?

애플리케이션 게이트웨이의 인스턴스는 가상 네트워크의 DNS 구성을 사용하여 이름 확인을 수행합니다. DNS 서버 구성이 변경되면 애플리케이션 게이트웨이가 새 DNS 서버를 할당받도록 게이트웨이를 다시 시작(중지 및 시작)해야 합니다. 그때까지 아웃바운드 연결에 대해 FQDN 기반 이름 확인이 제대로 되지 않을 수 있습니다.

Application Gateway는 짧은 이름 또는 단일 레이블 도메인 이름을 지원하나요?

네. Application Gateway는 DNS 서버가 확인할 수 있는 경우 백엔드 풀에서 짧은 이름(예: server1 또는 backend)을 해결할 수 있습니다. 온-프레미스, Azure 가상 네트워크 또는 하이브리드 환경을 비롯한 모든 네트워크 설정에서 작동합니다.

짧은 이름 확인을 활성화하려면 다음 단계를 따르세요.

• 가상 네트워크의 DNS 서버는 짧은 이름을 IP 주소로 변환할 수 있어야 합니다.
• FQDN(정규화된 도메인 이름)과 마찬가지로 짧은 이름 함수 - 게이트웨이가 DNS 서버에 IP 주소를 요청하고 사용합니다.

참고: Azure의 기본 DNS(168.63.129.16)를 사용하는 경우 동일한 가상 네트워크의 리소스에 대한 짧은 이름만 확인할 수 있습니다. 온-프레미스 짧은 이름을 확인하려면 내부 도메인 이름을 처리할 수 있는 사용자 지정 DNS 서버를 설정합니다.

자세한 내용은 Application Gateway의 DNS 확인 이해를 참조하세요.

Application Gateway 서브넷에서 다른 항목을 배포할 수 있나요?

아니요. 하지만 다른 애플리케이션 게이트웨이의 경우 서브넷에 배포하는 것이 가능합니다.

기존 Application Gateway의 가상 네트워크 또는 서브넷 변경이 가능한가요?

애플리케이션 게이트웨이는 같은 가상 네트워크 안에서 서브넷 간 이동만 지원합니다. v1은 퍼블릭 및 프라이빗 프런트 엔드(동적 할당)를 모두 지원하며, v2는 퍼블릭 프런트 엔드만 지원합니다. 프라이빗 프런트 엔드 IP 구성이 정적 할당된 애플리케이션 게이트웨이는 다른 서브넷으로 이동할 수 없습니다. 애플리케이션 게이트웨이가 중지되어 있어야 이 작업을 수행할 수 있습니다. v1을 중단하거나 시작할 때 공용 IP가 변경됩니다. 이 작업은 Azure PowerShell과 Azure CLI를 통해 다음 명령을 실행해야만 가능합니다.

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

더 자세한 내용은 Set-AzApplicationGatewayIPConfiguration을 참조하세요.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Application Gateway 서브넷에 네트워크 보안 그룹을 사용할 수 있나요?

Application Gateway 서브넷의 네트워크 보안 그룹을 참조하세요.

Application Gateway 서브넷은 사용자 지정 경로를 지원합니까?

Application Gateway 서브넷에서 사용자 정의 경로를 지원을 참조하세요.

Application Gateway 서브넷에서 지원되는 서비스 엔드포인트 정책이 있습니까?

아니요. 스토리지 계정에 대한 서비스 엔드포인트 정책은 Application Gateway 서브넷에서 지원되지 않으므로, 이를 구성할 경우 Azure 인프라 트래픽이 차단될 수 있습니다.

Application Gateway의 제한 사항은 무엇인가요? 이러한 한도를 늘릴 수 있나요?

Application Gateway 제한을 참조하세요.

Application Gateway를 외부 트래픽과 내부 트래픽에 동시에 사용할 수 있습니까?

네. Application Gateway는 애플리케이션 게이트웨이마다 내부 IP 하나와 외부 IP 하나를 지원합니다.

Application Gateway는 가상 네트워크 피어링을 지원하나요?

네. 가상 네트워크 피어링을 통해 다른 가상 네트워크의 트래픽 부하를 분산할 수 있습니다.

온프레미스 서버가 Azure ExpressRoute나 VPN 터널을 통해 연결되어 있다면, 이 서버와 통신이 가능한가요?

네, 트래픽만 허용된다면 가능합니다.

하나의 백엔드 풀에서 서로 다른 포트를 사용하여 여러 애플리케이션을 제공할 수 있습니까?

마이크로서비스 아키텍처를 지원합니다. 여러 포트에서 검색하려면 다양한 백엔드 설정을 구성해야 합니다.

사용자 지정 프로브에서 응답 데이터에 와일드 카드나 regex를 사용할 수 있나요?

아니요.

Application Gateway에서 라우팅 규칙은 어떻게 처리되나요?

처리 규칙 순서를 참조하세요.

사용자 지정 프로브의 **호스트** 필드가 나타내는 바는 무엇인가요?

호스트 필드는 Application Gateway에 다중 사이트가 구성되었을 때 프로브를 전송할 이름을 지정합니다. 그렇지 않으면 127.0.0.1를 사용합니다. 이 값은 가상 머신 호스트 이름과 차이가 있습니다. 형식은 <프로토콜>://<호스트>:<포트><경로>입니다.

Application Gateway가 특정 IP 주소에서만 액세스가 가능하도록 설정할 수 있습니까?

네. 특정 원본 IP로 액세스 제한을 참조하세요.

퍼블릭 연결 수신기와 프라이빗 연결 수신기에 같은 포트를 사용할 수 있습니까?

네, 같은 포트 번호를 사용하는 퍼블릭 연결 수신기와 프라이빗 연결 수신기를 통해 퍼블릭 클라이언트와 프라이빗 클라이언트를 동시에 지원하는 것이 가능합니다. application gateway의 서브넷이 NSG(네트워크 보안 그룹)와 연결되면, 해당 구성에 따라 특정 인바운드 규칙이 필요할 수 있습니다. 자세히 알아보기.

Application Gateway는 IPv6를 지원하나요?

Application Gateway v2는 IPv4 프런트 엔드와 IPv6 프런트 엔드를 지원합니다. IPv6 지원 기능은 현재 새로운 애플리케이션 게이트웨이에서만 제공됩니다. IPv6 지원을 위해 가상 네트워크는 이중 스택 구조를 갖춰야 합니다. Application Gateway v1에서는 듀얼 스택 가상 네트워크가 지원되지 않습니다.

Application Gateway는 FIPS를 어떻게 지원합니까?

Application Gateway SKU는 일반적으로 "FIPS 모드"라고 하는 FIPS 140-2 승인된 작업 모드에서 실행할 수 있습니다. FIPS 모드는 FIPS 140-2 유효성이 검사된 암호화 모듈을 호출하여 사용하도록 설정할 때 암호화, 해시 및 서명을 위한 FIPS 규격 알고리즘을 보장합니다. FIPS 모드를 사용하도록 설정 FIPSMode 하려면 포털(V2), PowerShell, Azure Resource Manager 템플릿 또는 REST API를 통해 설정을 구성해야 합니다.

V2 SKU에서 FIPS 모드를 사용하도록 설정하는 단계: Azure Application Gateway V2 SKU에 FIPS 모드 사용을 참조하세요.

V1 SKU에서 FIPS 모드를 활성화하는 단계:

단계 1: ‘AllowApplicationGatewayEnableFIPS’ 기능을 등록하여 FIPS 모드 구성에 대해 구독을 등록합니다.

Azure PowerShell을 사용하여 등록하려면 Cloud Shell 프롬프트에서 다음을 입력하세요.

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Azure Portal을 사용하여 등록하려면:

• Azure Portal로 로그인하여 미리 보기 기능을 검색합니다.
• 필터 상자에 AllowApplicationGatewayEnableFIPS를 입력합니다. Application Gateway V1 FIPS 모드 허용을 선택한 다음 등록을 선택합니다.

2단계: PowerShell, Azure Resource Manager 템플릿 또는 REST API를 사용하여 enableFips 속성을 True로 설정합니다.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

FIPS 모드를 변경하더라도 V1 게이트웨이에서 사용 가능한 모든 암호화 제품군에는 영향이 없습니다. 하지만 타원 곡선 암호화 에서 FIPS 모드가 비활성화되면 curve25519, NistP256, NistP384를 사용할 수 있으나, 활성화되면 NistP256, NistP384만 사용 가능하고 curve25519는 사용할 수 없습니다. FIPS 모드에서는 curve25519를 사용할 수 없으므로, FIPS를 활성화하기 전에 클라이언트가 보안 통신 시 NistP256 또는 NistP384를 지원하는지 확인해야 합니다.

Application Gateway v2를 사용할 때 개인 프런트 엔드 IP 주소만 사용하도록 구성하려면 어떻게 해야 합니까?

Application Gateway v2는 이제 프라이빗 IP 프런트 엔드 구성만 지원합니다. 자세한 내용은 프라이빗 Application Gateway 배포를 참조하세요.

Application Gateway v2는 다음 조합을 지원합니다.

• 개인 IP 및 공용 IP
• 공용 IP 전용
• 개인 IP만

Azure Application Gateway를 중지했다가 다시 시작하는 방법은 무엇인가요?

Application Gateway는 Azure PowerShell 또는 Azure CLI를 사용하여 중지했다가 시작할 수 있습니다. Application Gateway를 중지하고 시작하면 청구도 중지되고 시작됩니다. 애플리케이션 게이트웨이가 중지된 상태에서 태그, 상태 프로브, 수신기 추가 등의 PUT 작업을 수행하면 게이트웨이 시작이 트리거됩니다. application gateway 구성을 업데이트한 후에는 중지하는 것이 좋습니다.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

구성: TLS

Application Gateway에서 지원하는 인증서는 무엇인가요?

Application Gateway는 자체 서명된 인증서, CA(인증 기관) 인증서, EV(확장 유효성 검사) 인증서, 다중 도메인(SAN) 인증서 및 와일드 카드 인증서를 지원합니다.

Application Gateway는 어떤 암호 그룹을 지원하나요?

Application Gateway에서는 다음 암호화 도구 모음을 지원합니다.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS 옵션을 사용자 지정하는 방법은 Application Gateway에서 TLS 정책 버전 및 암호 그룹 구성을 참조하세요.

Application Gateway는 백엔드에 대한 트래픽 재암호화를 지원합니까?

네. Application Gateway는 TLS 오프로드 외에도 백 엔드로 전송되는 트래픽을 다시 암호화하는 엔드 투 엔드 TLS를 지원합니다.

TLS 프로토콜 버전을 제어하는 TLS 정책을 구성할 수 있습니까?

네. Application Gateway를 구성하여 TLS1.0, TLS1.1, 및 TLS1.2. 버전을 거부할 수 있습니다. SSL 2.0 및 3.0은 기본적으로 비활성화되어 있으며, 사용자가 임의로 구성할 수 없습니다.

암호 그룹과 정책 순서를 설정할 수 있나요?

네. Application Gateway에서는 암호 그룹을 구성할 수 있습니다. 사용자 지정 정책을 정의할 때, 다음 암호화 도구 모음 중에서 하나 이상을 선택하여 사용해야 합니다.

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway는 백엔드 관리를 위해 SHA256을 사용합니다.

Application Gateway에서 TLS/SSL 인증서는 몇 개까지 지원 가능합니까?

Application Gateway는 최대 100의 TLS/SSL 인증서를 지원합니다.

Application Gateway는 OCSP와 OCSP 스테이플링을 지원합니까?

네, Application Gateway는 서버 인증서에 대해 OCSP 확장 및 OCSP 스테이플링을 사용하는 인증서를 지원합니다.

Application Gateway는 백엔드 재암호화 시 최대 몇 개의 인증 인증서를 지원합니까?

Application Gateway는 최대 100개의 인증 인증서를 지원합니다.

Application Gateway는 Azure Key Vault와 기본적으로 통합되나요?

예, Application Gateway v2 SKU는 주요 자격 증명 모음을 지원합니다. 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

.com 및 .NET 사이트에 대해 HTTPS 수신기를 구성하려면 어떻게 해야 하나요?

다중 도메인 기반(호스트 기반) 라우팅을 위해 여러 사이트 수신기를 생성하고, HTTPS 프로토콜을 사용하는 수신기를 설정한 다음, 해당 수신기를 라우팅 규칙과 연결할 수 있습니다. 자세한 내용은 Application Gateway를 사용하여 여러 사이트 호스팅을 참조하세요.

.pfx 파일 암호에 특수 문자를 사용해도 괜찮은가요?

아니요. .pfx 파일 암호로는 영숫자 문자만 사용해야 합니다.

제 EV 인증서는 DigiCert에서 발급되었지만, 제 중간 인증서가 해지되었습니다. Application Gateway에서 인증서를 갱신하는 방법은 무엇인가요?

Certificate Authority(CA) Browser 포럼은 최근 본사 고객, Microsoft, 그리고 기술 커뮤니티에서 널리 사용되지만, 공개적으로 신뢰할 수 있는 CA의 산업 표준을 준수하지 않는 CA 공급업체에서 발급된 여러 인증서에 대한 정보를 담은 보고서를 발표했습니다. 규격에 맞지 않는 CA 관련 보고서는 다음 위치에서 찾아볼 수 있습니다.

• 버그 1649951
• 버그 1650910

업계 규정 준수 요구 사항에 따라 CA 공급업체에서 규정을 준수하지 않는 CA를 해지하고, 이제 요구 사항을 준수하는 CA를 발급하기 시작했으므로 고객은 인증서를 다시 발급받아야 합니다. Microsoft는 Azure 서비스에 대한 잠재적 영향을 최소화하기 위해 해당 공급업체와 긴밀하게 협력하고 있습니다. 하지만 Bring Your Own Certificate (BYOC) 환경에서 쓰이는 자체 발급 인증서는 예상치 못한 이유로 해지될 가능성이 남아 있습니다.

애플리케이션에서 사용하는 인증서의 해지 여부를 확인하려면 DigiCert 발표 및 인증서 해지 추적기를 참고하세요. 인증서가 해지되었거나 해지될 예정인 경우, 애플리케이션에서 사용하려면 CA 공급업체에 새 인증서를 요청해야 합니다. 인증서가 예기치 않게 해지되어 애플리케이션의 가용성이 중단되는 상황을 방지하거나, 해지된 인증서를 업데이트해야 하는 경우, 고객의 Azure 서비스에 영향을 줄 수 있는 비규격 인증 기관의 해지 정보를 참조하세요.

Application Gateway와 관련된 자세한 내용:

해지된 ICA에서 발급한 인증서를 사용하는 경우 애플리케이션을 사용하지 못할 수 있습니다. 애플리케이션에 따라 다음을 포함한 여러 오류 메시지가 나타날 수 있습니다.

• 잘못된 인증서/해지된 인증서
• 연결 시간이 초과됨
• HTTP 502

애플리케이션이 이 문제로 인해 중단되는 것을 방지하거나 해지된 CA를 재발급하려면 다음 작업을 수행해야 합니다.

1. 인증서 다시 발급 방법을 인증서 공급자에게 문의합니다.
2. 인증서를 재발급받았다면 전체 신뢰 체인(리프, 중간, 루트 인증서)을 사용하여 Azure Application Gateway/WAF에서 해당 인증서를 업데이트하세요. 애플리케이션 게이트웨이의 수신기 또는 HTTP 설정에서 인증서 사용 위치에 따라 다음 단계에 따라 인증서를 업데이트합니다. 자세한 내용은 언급된 설명서 링크를 참조하시기 바랍니다.
3. 재발급된 인증서를 사용하려면 백 엔드 애플리케이션 서버를 업데이트합니다. 인증서 업데이트 단계는 사용 중인 백엔드 서버에 따라 다를 수 있습니다. 공급업체의 설명서를 확인합니다.

수신기에서 인증서를 업데이트하려면 다음을 수행합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서에 연결된 수신기 설정을 엽니다.
3. 선택한 인증서 갱신 또는 편집을 선택하세요.
4. 암호를 사용하여 새 PFX 인증서를 업로드한 다음, 저장을 클릭합니다.
5. 웹 사이트에 액세스하여 사이트가 예상대로 작동하는지 확인합니다. 자세한 내용은 Application Gateway 인증서 갱신을 참조하세요.

Application Gateway 수신기에서 Key Vault 인증서를 참조하는 경우, 다음 단계에 따라 신속하게 변경하는 것이 좋습니다.

1. Azure Portal에서 애플리케이션 게이트웨이에 연결된 Key Vault 설정으로 이동합니다.
2. 저장소에서 재발급된 인증서를 추가하거나 저장소로 가져옵니다. 자세한 내용은 빠른 시작: Azure Portal을 사용하여 키 자격 증명 모음 만들기를 참조하세요.
3. 인증서를 가져왔다면 Application Gateway 수신기 설정으로 이동하여 Key Vault에서 인증서 선택에서 인증서 드롭다운 목록을 선택하고, 최근에 추가한 인증서 를 선택합니다.
4. 저장을 선택합니다. Application Gateway에서 Key Vault 인증서를 사용하여 TLS를 종료하는 방법에 대한 자세한 내용은 관련 문서를 참조하세요.

HTTP 설정에서 인증서를 업데이트하려면 다음 단계를 따르세요.

Application Gateway/WAF 서비스에서 v1 SKU를 사용하는 경우, 백엔드 인증서 인증을 위해 새 인증서를 업로드해야 합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서에 연결된 HTTP 설정을 엽니다.
3. 인증서 추가를 선택하고, 재발급된 인증서를 업로드한 다음 저장 버튼을 선택합니다.
4. 이전 인증서는 나중에 해당 인증서 옆에 있는 ... 옵션 버튼을 선택하여 제거할 수 있습니다. 삭제을 선택한 후 저장를 선택합니다. 자세한 내용은 포털에서 Application Gateway를 사용하여 엔드투엔드 TLS 구성을 참조하세요.

Application Gateway/WAF 서비스 V2 SKU를 사용하는 경우, V2 SKU는 ‘신뢰할 수 있는 루트 인증서’를 사용하므로 HTTP 설정에서 별도로 새 인증서를 업로드할 필요가 없습니다.

구성 - TLS/TCP 프록시

Application Gateway의 Layer 7과 Layer 4는 동일한 프런트 엔드 IP 주소를 사용합니까?

네. Application Gateway를 통한 L7 및 L4 라우팅은 모두 동일한 프런트 엔드 IP 구성을 사용합니다. 이 방식을 사용하면 모든 클라이언트는 단일 IP 주소(공용 또는 사설)로 지정되며, 동일한 게이트웨이 리소스에 구성된 수신 프로토콜 및 포트에 따라 클라이언트가 라우팅됩니다.

HTTP(S) 트래픽에 TCP 또는 TLS 프록시를 사용할 수 있습니까?

HTTP(S) 트래픽은 L4 프록시 프로토콜을 통해 제공될 수도 있지만, 권장하지는 않습니다. Application Gateway의 L7 프록시 솔루션은 HTTP(S) 프로토콜에 대한 강력한 제어 및 보안을 제공하며, 재작성, 세션 선호도, 리디렉션, WebSocket, WAF 등의 유용한 기능을 지원합니다.

계층 4 프록시의 속성 이름은 무엇입니까?

계층 4 기능의 리소스 속성은 계층 7 기능의 리소스 속성과 다릅니다. 그러므로 REST API나 CLI를 사용할 때에는 다음 속성을 활용해야 합니다.

속성	목적
수신기	TLS 또는 TCP 기반 수신기의 경우
routingRule	계층 4 수신기를 계층 4 백 엔드 설정과 연결하려면
backendSettingsCollection	TLS 또는 TCP 기반 백 엔드 설정의 경우

• REST API
• CLI

참고

계층 4 속성은 HTTP 또는 HTTPS 프로토콜 설정에 사용할 수 없습니다.

HTTP(S) 프로토콜 백엔드 설정을 통해 TCP/TLS 프로토콜 수신기를 매핑할 수 있습니까?

아니요. 계층 4와 계층 7 속성은 상호 연결할 수 없습니다. 결과적으로, 라우팅 규칙을 적용하면 L4 형식의 수신기는 반드시 L4 형식의 백엔드 설정과 연결되도록 제한됩니다.

L7과 L4 속성이 같은 이름을 가질 수 있습니까?

L7(httpListeners)과 L4(수신기)의 이름은 동일하게 지정할 수 없습니다. 이는 backendSettingsCollection, RoutingRules와 같은 다른 L4 속성에도 마찬가지로 적용됩니다.

계층 4(TCP 또는 TLS 프로토콜)를 사용할 때 백 엔드 풀에 프라이빗 엔드포인트를 추가할 수 있습니까?

그럼요. 계층 7 프록시처럼 애플리케이션 게이트웨이의 백 엔드 풀에 프라이빗 엔드포인트를 추가할 수 있습니다. 이 프라이빗 엔드포인트는 애플리케이션 게이트웨이와 동일한 가상 네트워크에서 인접한 서브넷에 배포해야 합니다.

Application Gateway는 백엔드 서버에 Keepalive 연결을 사용합니까?

백엔드 연결에서는 Keepalive를 사용하지 않습니다. Application Gateway는 프런트 엔드 수신기 연결을 통해 들어오는 각 요청을 처리하기 위해 새로운 백 엔드 연결을 시작합니다.

Application Gateway에 연결이 설정되면 백엔드 서버에는 어떤 IP 주소가 표시됩니까?

백엔드 서버에서는 애플리케이션 게이트웨이의 IP 주소를 확인합니다. 현재 백엔드 애플리케이션은 클라이언트 IP 보존을 지원하지 않아, 원래 클라이언트의 IP 주소를 인식할 수 없습니다.

TLS 리스너에 대한 TLS 정책은 어떻게 설정해야 하나요?

계층 7(HTTPS)과 계층 4(TLS) 모두에 동일한 TLS/SSL 정책 구성이 적용됩니다. 이제 TLS 수신기에 SSL 프로필을 사용하여 수신기별 TLS 정책 및 상호 인증을 구성할 수 있습니다. 하지만 현재 SSL 프로필은 CLI, PowerShell 또는 REST API를 통해서만 TLS 수신기에 연결할 수 있습니다.

Application Gateway에서 계층 4 라우팅 시 세션 선호도를 지원하나요?

아니요. 현재 클라이언트를 동일한 백엔드 서버로 라우팅하는 기능은 지원되지 않습니다. 연결은 백엔드 풀의 서버에 라운드 로빈 방식으로 분산됩니다.

계층 4 프록시에서 자동 크기 조정 기능이 지원되나요?

네, 자동 크기 조절 기능은 TLS 또는 TCP 프로토콜 트래픽의 급증 및 감소에도 효과적으로 작동합니다.

계층 4 트래픽에 Web Application Firewall (WAF)가 지원되나요?

Web Application Firewall (WAF) 기능은 레이어 4 환경에서는 작동하지 않습니다.

Application Gateway에서 계층 4 프록시가 UDP 프로토콜을 지원합니까?

아니요. 현재 UDP 지원은 제공되지 않고 있습니다.

TLS/TCP 수신기는 어떤 포트를 지원합니까?

동일한 허용 포트 범위 및 예외 목록은 레이어 4 프록시에도 동일하게 적용됩니다.

공용 TLS/TCP 프록시 수신기와 개인 TLS/TCP 프록시 수신기에 동일한 포트 번호를 사용하려면 어떻게 해야 합니까?

현재 TLS/TCP 수신기에 공통 포트를 사용하는 기능은 지원되지 않습니다.

구성 - AKS 수신 컨트롤러

수신 컨트롤러는 무엇을 말하는 건가요?

Kubernetes를 통해 deployment 과 service 리소스를 만들어 클러스터 내에서 Pod 그룹을 외부에 공개할 수 있습니다. 외부에 동일한 서비스를 공개할 때 필요한 부하 분산, TLS 종료, 이름 기반 가상 호스팅을 제공하는 Ingress 리소스가 정의됩니다. 이러한 Ingress 리소스 요구 사항을 충족하려면 Ingress리소스 변경 사항을 수신 대기하고 load balancer 정책을 구성하는 수신 컨트롤러가 필요합니다.

Application Gateway Ingress Controller(AGIC)는 AKS 클러스터라고도 하는 Azure Kubernetes Service에서 Application Gateway 를 수신으로 사용할 수 있도록 합니다.

수신 컨트롤러 대신에 Application Gateway를 직접 구성하는 것이 가능한가요?

Application Gateway를 직접 구성하는 기능은 지원되지 않습니다.

Application Gateway의 설정을 변경해야 할 때는 수신 컨트롤러나 다른 Kubernetes 개체에 구성된 내용(예: 지원되는 주석)을 이용하여 변경해야 합니다. Application Gateway가 AGIC(Application Gateway 수신 컨트롤러)에 연결되면 해당 게이트웨이의 거의 모든 구성이 수신 컨트롤러에 의해 동기화되고 제어됩니다. 명령 또는 코드 형태의 인프라를 통해 Application Gateway를 직접 구성하더라도, 결국 수신 컨트롤러가 이러한 변경 사항을 덮어쓰게 됩니다.

단일 인스턴스의 수신 컨트롤러를 사용하여 여러 애플리케이션 게이트웨이를 관리할 수 있습니까?

현재는 하나의 수신 컨트롤러 인스턴스만 하나의 Application Gateway에 연결할 수 있습니다.

AGIC에서 kubenet을 사용하는 AKS 클러스터가 작동하지 않는 이유는 무엇인가요?

AGIC는 Application Gateway 서브넷에 경로 테이블 리소스를 자동으로 연결하려 하지만, 필요한 권한이 없어 실패할 가능성이 있습니다. AGIC가 경로 테이블을 Application Gateway 서브넷에 연결하지 못할 경우 AGIC 로그에 오류가 표시됩니다. 이러한 경우, AKS 클러스터에서 생성된 경로 테이블을 Application Gateway 서브넷에 수동으로 연결해야 합니다. 자세한 내용은 지원되는 사용자 정의 경로를 참조하세요.

AKS 클러스터와 애플리케이션 게이트웨이를 별도의 가상 네트워크에서 연결할 수 있나요?

가상 네트워크가 피어링되어 연결되어 있고, 주소 공간이 중복되지 않는다면 가능합니다. Kubenet을 사용하는 경우, AKS에서 생성된 경로 테이블을 Application Gateway 서브넷에 연결해야 AKS가 실행됩니다.

AGIC 추가 기능에서 지원되지 않는 기능은 무엇인가요?

AGIC가 Helm을 통해 배포된 경우와 AKS 추가 기능으로 배포된 경우의 차이점은 Helm 배포와 AKS 추가 기능 간의 차이점을 참고하면 됩니다.

추가 항목과 Helm 배포는 각각 언제 사용하는 것이 좋을까요?

AGIC를 Helm을 통해 배포했을 때와 AKS 추가 항목으로 배포했을 때의 차이점은, Helm 배포와 AKS 추가 항목 간의 차이점을 비교하여 AKS 추가 항목이 아닌 Helm을 통해 배포된 AGIC에서 지원하는 시나리오를 표로 정리한 문서를 참조하세요. Helm을 통해 배포할 때, 일반적으로 공식 릴리스 전 베타 기능 및 릴리스 후보를 테스트하는 것이 가능합니다.

추가적으로 배포되는 AGIC 버전을 사용자가 제어할 수 있나요?

아니요. AGIC 추가 기능은 관리형 서비스이므로 Microsoft에서 추가 기능을 최신 안정화 버전으로 자동 업데이트합니다.

AGIC가 설치된 경우, Azure CNI 오버레이를 사용하여 Kubenet 또는 Azure CNI로 실행 중인 클러스터를 업그레이드할 수 있습니까?

예, Kubenet 또는 CNI에서 CNI 오버레이로 AKS 클러스터를 업그레이드하면 Application Gateway 수신 컨트롤러에서 자동으로 이를 감지합니다. 트래픽 중단을 방지하기 위해 유지 관리 기간에 업그레이드를 예약하는 것이 좋습니다. 컨트롤러가 클러스터 업그레이드 후 CNI 오버레이에 대한 지원을 검색하고 구성하는 데 몇 분 정도 소요될 수 있습니다.

구성: 상호 인증

상호 인증이란 무엇인가요?

상호 인증은 클라이언트와 서버가 서로를 인증하는 양방향 인증 방식입니다. 현재까지 Application Gateway에서는 상호 인증을 통해 게이트웨이가 클라이언트 인증인 요청을 전송하는 클라이언트를 확인할 수 있습니다. 일반적으로 클라이언트는 Application Gateway에 대해 인증하는 유일한 항목입니다. 이제는 Application Gateway도 클라이언트를 인증할 수 있기 때문에 Application Gateway와 클라이언트가 서로를 상호 인증하는 상호 인증이 되었습니다.

Application Gateway와 백엔드 풀 간에 상호 인증을 사용할 수 있습니까?

아니요, 현재 상호 인증은 프런트 엔드 클라이언트와 애플리케이션 게이트웨이 간에만 지원됩니다. 현재 백엔드 상호 인증은 지원되지 않습니다.

진단 및 로깅

Application Gateway에서 제공하는 로그 유형은 무엇인가요?

Application Gateway는 다음 세 가지 로그를 제공합니다.

• ApplicationGatewayAccessLog: 이 액세스 로그에는 애플리케이션 게이트웨이 프런트 엔드로 제출된 각 요청에 대한 정보가 담겨 있습니다. 이 데이터는 호출자의 IP 주소, 요청 URL, 응답 대기 시간, 반환 코드, 바이트 입출력 정보를 담고 있으며, 각 애플리케이션 게이트웨이에 대해 하나의 레코드로 기록됩니다.
• ApplicationGatewayPerformanceLog: 이 성능 로그는 각 애플리케이션 게이트웨이의 성능 관련 정보를 수집합니다. 이 정보에는 처리량(바이트 단위), 총 요청 처리 건수, 실패 요청 건수, 정상 및 비정상 백엔드 인스턴스 수가 포함됩니다.
• ApplicationGatewayFirewallLog: WAF를 사용하여 구성된 Application Gateway의 방화벽 로그에는 검색 모드 또는 방지 모드로 기록된 요청이 포함됩니다.

로그는 전부 60초마다 한 번씩 수집됩니다. 자세한 내용은 Application Gateway에 대한 백 엔드 상태, 진단 로그 및 메트릭을 참조하시길 바랍니다.

내 백 엔드 풀 멤버가 정상인지 어떻게 알 수 있나요?

PowerShell cmdlet Get-AzApplicationGatewayBackendHealth 또는 포털을 사용하여 상태를 확인할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

진단 로그 보존 정책은 어떻게 되나요?

진단 로그는 고객의 스토리지 계정으로 전송됩니다. 고객은 필요에 따라 보존 정책을 자유롭게 설정할 수 있습니다. 진단 로그는 이벤트 허브나 Azure Monitor 로그로도 전송할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

Application Gateway에 대한 감사 로그는 어떻게 얻을 수 있습니까?

감사 로그에 액세스하려면 포털의 Application Gateway 메뉴 블레이드에서 활동 로그 를 클릭하면 됩니다.

Application Gateway로 경고를 설정할 수 있나요?

네. Application Gateway에서 경고는 메트릭을 기준으로 구성됩니다. 자세한 내용은 Application Gateway 메트릭 및 경고 알림 받기를 참조하세요.

Application Gateway에 대한 트래픽 통계를 분석하려면 어떻게 해야 하나요?

액세스 로그는 다양한 방식으로 살펴보고 분석할 수 있습니다. Azure Monitor 로그, Excel, Power BI 등을 활용합니다.

Application Gateway 액세스 로그 분석을 위해 널리 사용되는 GoAccess 로그 분석기를 설치하고 실행할 수 있는 Resource Manager 템플릿이 있습니다. GoAccess는 고유 방문자 수, 요청된 파일, 호스트, 운영 체제, 브라우저, HTTP 상태 코드 등 HTTP 트래픽에 대한 유용한 통계 자료를 제공합니다. 자세한 내용은 GitHub의 Resource Manager 템플릿 폴더에 있는 Readme 파일 을 참조하세요.

백 엔드 상태가 알 수 없는 상태로 돌아가는 이유는 무엇인가요?

일반적으로 Application Gateway 서브넷에서 NSG, 사용자 지정 DNS 또는 사용자 정의 라우팅으로 인해 백 엔드 액세스가 차단되면 알 수 없는 상태가 표시됩니다. 자세한 내용은 Application Gateway의 백 엔드 상태, 진단 로그 및 메트릭 을 참조하시기 바랍니다.

Application Gateway v2 서브넷과 연결된 NSG에서 NSG 흐름 로그가 지원됩니까?

현재 플랫폼의 한계로 인해 NSG가 Application Gateway v2(Standard_v2, WAF_v2) 서브넷에 있는 경우 NSG 흐름 로그를 사용하면 예측 불가능한 동작이 발생할 수 있습니다. 이 시나리오는 현재 지원되지 않습니다.

Application Gateway는 고객 데이터를 어디에 저장하나요?

Application Gateway는 고객 데이터를 배포된 지역 외부에 이동하거나 저장하는 일이 없습니다.

다음 단계

• Application Gateway 메트릭에 대해 자세히 알아보려면 Azure Application Gateway란 무엇입니까를 참조하세요.
• Application Gateway를 사용한 TLS 종료 및 엔드투엔드 TLS에 대해 알아보려면 Azure Application Gateway에서 엔드투엔드 TLS 사용을 참조하세요.

참고

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Az로 마이그레이션을 참조하세요.

다음은 Azure Application Gateway에 대해 자주 묻는 질문입니다.

Azure Application Gateway는 애플리케이션 제공 컨트롤러를 서비스로 제공합니다. 애플리케이션에 다양한 레이어 7 부하 분산 기능을 제공합니다. 이 서비스는 Azure에서 관리하는 고가용성의 확장성 있는 완전 관리형 서비스입니다.

Application Gateway는 자동 스케일링, TLS 오프로딩, 엔드투엔드 TLS, 웹 애플리케이션 방화벽(WAF), 쿠키 기반 세션 선호도, URL 경로 기반 라우팅, 다중 사이트 호스팅 및 여러 기능을 제공합니다. 지원되는 기능의 전체 목록을 보려면 Application Gateway 소개를 참조하세요.

Application Gateway는 웹 트래픽(HTTP, HTTPS, WebSocket, HTTP/2) 전용 레이어 7 load balancer 장치입니다. TLS 종료를 지원하며, 쿠키 기반 세션 선호도와 트래픽 부하 분산을 위해 라운드 로빈 방식을 사용합니다. 계층 4(TCP 또는 UDP)에서 트래픽 부하를 분산하는 데에는 Load Balancer 장치가 사용됩니다.

Application Gateway는 HTTP, HTTPS, HTTP/2와 WebSocket을 지원합니다.

HTTP/2 지원을 참조하세요.

지원되는 백 엔드 리소스를 참조하세요.

Application Gateway v1(표준 및 WAF)은 Azure의 모든 지역에서 제공됩니다. Microsoft Azure 및 Azure Government는 21Vianet에서 운영하며, 해당 환경에서도 사용할 수 있습니다.

Application Gateway v2(Standard_v2 및 WAF_v2) 가용성은 Application Gateway v2의 지원되는 지역을 참조하세요.

Application Gateway는 가상 네트워크에서 전용으로 배포됩니다.

리디렉션은 지원됩니다. Application Gateway 리디렉션 개요를 참조하세요.

수신기 처리 순서를 참조하세요.

엔드포인트로 공용 IP 주소를 사용하는 경우, 공용 IP 주소 리소스에서 IP와 DNS 정보를 찾으세요. 아니면 Azure Portal의 애플리케이션 게이트웨이 개요 페이지에서 찾아볼 수도 있습니다. 내부 IP 주소를 사용하는 경우에는 개요 페이지에서 정보를 확인하시기 바랍니다. v1 SKU를 사용하는 경우 2023년 5월 1일 이후에 생성된 게이트웨이에는 공용 IP 리소스에 자동으로 연결되는 기본 DNS 이름이 없습니다. v2 SKU를 사용하는 경우, 공용 IP 리소스를 열어서 구성을 선택하세요. DNS 이름 레이블 필드(선택 사항) 를 활용하여 DNS 이름을 구성할 수 있습니다.

Keep-Alive 시간 제한은 클라이언트가 영구 연결을 다시 사용하거나 닫기 전에 애플리케이션 게이트웨이가 대기하는 시간을 제어합니다. 즉, 다른 HTTP 요청을 보내기까지의 대기 시간을 의미합니다. TCP 유휴 시간 제한은 별다른 작업이 이루어지지 않을 때 TCP 연결을 얼마나 오래 유지할지를 결정합니다.

Application Gateway v1 및 v2 SKU에서 HTTP/1.1 연결의 Keep-Alive 제한 시간은 120초입니다. 개인 IP 주소는 TCP 유휴 시간 제한을 5분으로 설정할 수 없습니다. TCP 유휴 시간 제한은 Application Gateway v1 및 v2 SKU의 프런트 엔드 VIP(가상 IP)에서 기본적으로 4분입니다. v1, v2 Application Gateway 인스턴스의 TCP 유휴 시간 제한은 4분에서 30분 사이에서 구성 가능합니다. v1 및 v2 Application Gateway 인스턴스 모두 애플리케이션 게이트웨이의 공용 IP로 연결되므로, 포털의 공용 IP 구성 창에서 TCP 유휴 시간 제한을 변경해야 합니다. 다음 명령을 실행하여 PowerShell을 통해 공용 IP의 TCP 유휴 시간 제한 값을 설정할 수 있습니다.

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Application Gateway v2 SKU의 프런트 엔드 IP 주소에 HTTP/2를 연결하면 유휴 시간 제한이 180초로 설정되고, 사용자가 임의로 구성할 수는 없습니다.

충돌이나 예기치 않은 동작이 발생하지 않도록 TCP 유휴 시간 제한이 유지 시간 제한 이상으로 설정되었는지 확인합니다.

네. Application Gateway는 백엔드 서버와 기존 TCP 연결을 다시 설정하지 않고 재사용합니다.

아니요. Application Gateway 리소스 이름은 변경이 불가능합니다. 새 리소스를 다른 이름으로 생성해야 합니다.

아니요. Application Gateway 리소스 또는 연결된 공용 IP는 삭제 후 복구가 불가능합니다. 새로운 리소스를 만들어야 합니다.

Application Gateway v1 SKU에서 애플리케이션 게이트웨이를 중지 후 다시 시작하면 VIP가 변경될 수 있습니다. Application Gateway에 연결된 DNS 이름은 게이트웨이 사용 기간 동안 변경되지 않습니다. DNS 이름은 변경되지 않으므로 CNAME 별칭을 사용하여 해당 별칭이 애플리케이션 게이트웨이의 DNS 주소를 가리키도록 설정해야 합니다. Application Gateway v2 SKU에서 IP 주소는 고정되어 있으므로, 애플리케이션 게이트웨이를 사용하는 동안 IP 주소와 DNS 이름이 변경되지 않습니다.

네. Application Gateway v2 SKU는 고정된 공용 IP 주소뿐만 아니라 내부 IP 주소도 지원합니다. v1 SKU는 내부 고정 IP를 지원합니다.

애플리케이션 게이트웨이에서는 IP 프로토콜 하나당 공용 IP 주소를 하나만 지원합니다. 애플리케이션 게이트웨이가 DualStack으로 구성되면 IPv4와 IPv6 각각에 대해 하나의 공용 IP를 지원하므로 총 2개의 공용 IP를 사용할 수 있습니다.

Application Gateway 서브넷 크기 고려 사항을 참조하세요.

네. 지정된 Application Gateway 배포의 여러 인스턴스를 유지하는 것과 더불어, 다른 애플리케이션 게이트웨이 리소스가 있는 기존 서브넷에 또 다른 고유한 Application Gateway 리소스를 프로비저닝하는 것도 가능합니다.

단일 서브넷은 v2 및 v1 Application Gateway SKU를 둘 다 지원할 수 없습니다.

예, 그러나 특정 상황에서만 지원됩니다. 자세한 내용은 Application Gateway 인프라 구성을 참조하세요.

네. 요청 수정을 참조하세요.

새 Application Gateway v1 SKU 배포 시 프로비전하는 데 최대 20분이 걸릴 수 있습니다. 인스턴스 크기 또는 수를 변경해도 중단되지 않으며, 게이트웨이는 이 시간 동안 활성 상태를 유지합니다.

v2 SKU를 사용하는 대부분의 배포는 프로비저닝하는 데 약 6분이 소요됩니다. 하지만 배포 방식에 따라 처리 시간이 더 오래 걸릴 수도 있습니다. 예를 들어 여러 가용 영역에 다수의 인스턴스를 배포하면 6분 넘게 소요될 수 있습니다.

Application Gateway는 미리 보기 기능을 통해 L4 프록시에서 TLS/TCP 프로토콜 프록시를 지원합니다.

Application gateway의 계층 7 프록시는 HTTP(S) 프로토콜을 사용하며, SMTP, IMAP, POP3와 같은 이메일 프로토콜은 지원하지 않습니다. 하지만 Outlook Web Access (OWA), ActiveSync, HTTP(S) 프로토콜을 사용하는 AutoDiscovery 트래픽과 같은 일부 지원 이메일 서비스는 계층 7 프록시를 사용해야 하므로 해당 트래픽이 반드시 통과하도록 설정해야 합니다. (참고: WAF SKU를 사용하는 경우에는 WAF 규칙에서 제외해야 할 필요가 있을 수 있습니다.)

네. 자세한 내용은 Azure Application Gateway 및 Web Application Firewall을 v1에서 v2로 마이그레이션을 참조하세요.

네. Application Gateway v1 SKU는 계속 지원될 예정입니다. 해당 SKU의 기능 업데이트를 활용하려면 v2로 업그레이드하는 것이 좋습니다. v1과 v2 기능의 차이점에 대한 자세한 내용은 자동 확장 및 영역 중복을 지원하는 Application Gateway v2를 참조하세요. Application Gateway v1 SKU 배포를 v2로 수동 마이그레이션하는 방법은 v1-v2 마이그레이션 설명서에 자세히 나와 있습니다.

네. Application Gateway v2는 이제 NTLM 또는 Kerberos 인증을 사용하여 프록시 요청을 지원합니다. 자세한 내용은 전용 백 엔드 연결을 참조하세요.

요청 헤더 이름에는 영숫자와 하이픈이 포함될 수 있습니다. 요청 헤더 이름에 다른 문자가 포함된 경우, 백엔드 대상으로 요청을 보낼 때 해당 헤더는 삭제됩니다. 응답 헤더 이름은 RFC 7230에 정의된 바에 따라 영숫자와 특정 기호를 포함할 수 있습니다.

네. Chromium 브라우저v80 업데이트 에서는 SameSite 속성이 지정되지 않은 HTTP 쿠키를 SameSite=Lax로 취급하는 요구를 수용했습니다. 즉, 타사 컨텍스트에서는 브라우저가 Application Gateway의 선호도 쿠키를 전송하지 않습니다.

Application Gateway는 이 시나리오를 지원하고자 기존 ApplicationGatewayAffinity 쿠키 외에 ApplicationGatewayAffinityCORS 라는 쿠키를 하나 더 삽입합니다. 이 쿠키는 ApplicationGatewayAffinityCORS 의 쿠키와 비슷하지만, SameSite=None 와 Secure이라는 두 가지 특징이 더해졌습니다. 이러한 특성 덕분에 원본 간 요청 시에도 세션이 유지됩니다. 더 자세한 내용은 쿠키 기반 선호도 섹션을 참조하세요.

활성 수신기는 규칙 과 에 연결되어 백엔드 풀로 트래픽을 전송하는 역할을 합니다. 트래픽을 리디렉션만 하는 수신기는 활성 수신기가 아닙니다. 리디렉션 규칙과 연결된 수신기는 활성으로 간주되지 않습니다. 경로 기반 리디렉션 규칙의 경우, 해당 규칙에 포함된 모든 경로는 트래픽을 리디렉션해야만 수신기가 활성 상태로 유지됩니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건에서 개별 구성 요소 제한을 참조하세요.

Application Gateway v1 SKU는 인스턴스를 2개 이상 배포하면 고가용성 시나리오를 지원합니다. Azure는 모든 인스턴스가 동시에 실패하지 않도록 업데이트 및 장애 도메인에 인스턴스를 배포합니다. v1 SKU는 로드를 공유하기 위해 동일한 게이트웨이의 여러 인스턴스를 추가하여 확장성을 지원합니다.

v2 SKU는 장애 도메인 및 업데이트 도메인에서 새 인스턴스가 자동으로 분산되도록 보장합니다. 중복 수준을 0으로 선택하면, 영역에 장애가 발생했을 때 복원력을 제공할 수 있도록 최신 인스턴스 또한 여러 가용 영역으로 분산됩니다.

Azure Traffic Manager를 통해 여러 데이터 센터에 있는 여러 애플리케이션 게이트웨이에 트래픽 분산이 가능합니다.

네. 중지 없이 백 엔드 풀 내에서 멤버를 변경하도록 연결 드레이닝을 설정할 수 있습니다. 자세한 내용은 Application Gateway 연결 드레이닝 섹션을 참조하세요.

예, Application Gateway v2 SKU는 자동 크기 조정 기능을 지원합니다. 더 자세한 내용은 자동 스케일링 및 영역 중복 Application Gateway를 참조하세요.

아니요. 인스턴스들은 업그레이드 도메인과 장애 도메인에 걸쳐 분산됩니다.

네.

네.

Application Gateway에 대해 시작된 업데이트는 한 번에 하나의 업데이트 도메인 씩 순차적으로 적용됩니다. 각 업데이트 도메인의 인스턴스가 업데이트됨에 따라 다른 업데이트 도메인의 나머지 인스턴스는 계속해서 트래픽을 처리합니다. 업데이트가 시작되기 전에 다른 업데이트 도메인의 인스턴스에 대한 연결을 설정하는 데 도움이 되도록 최대 5분 동안 업데이트되는 인스턴스에서 활성 연결이 정상적으로 드레이닝됩니다. 현재 인스턴스 세트가 성공적으로 업그레이드되어야 업데이트 프로세스가 다음 인스턴스 세트로 넘어갑니다.

Azure Application Gateway는 기존 인스턴스를 오프라인으로 전환하지 않고 롤링 업그레이드 중에 새 인스턴스를 프로비전할 수 있는 기능인 MaxSurge도 지원합니다. 이를 통해 고객은 용량 저하 없이 최신 게이트웨이 버전으로 전환할 수 있습니다. MaxSurge는 Application Gateway에서 자동으로 사용하도록 설정되며 구성이 필요하지 않습니다.

메모: MaxSurge에서 사용하는 임시 인스턴스를 프로비전하려면 추가 IP 공간이 필요합니다. 업데이트 중에 충분한 IP 공간을 사용할 수 없는 경우 Application Gateway는 기존 업그레이드 방법으로 대체되므로 인스턴스 수에 따라 최대 용량이 감소할 수 있습니다.

네. Application Gateway는 항상 가상 네트워크 서브넷에 배포됩니다. 이 서브넷은 애플리케이션 게이트웨이만 포함할 수 있습니다. 자세한 내용은 가상 네트워크 및 서브넷 요구 사항을 참조하세요.

IP 연결이 설정된 경우, Application Gateway는 현재 속해 있는 가상 네트워크 외부의 인스턴스와 통신할 수 있습니다. 또한 Application Gateway는 현재 속한 구독 외부의 인스턴스와 통신할 수 있습니다. 내부 IP를 백 엔드 풀 멤버로 사용하려면 가상 네트워크 피어링 또는 Azure VPN Gateway를 구성해야 합니다.

Application Gateway 리소스는 DNS 확인자와 동일하게 백 엔드 서버 DNS 레코드의 Time to Live (TTL) 값을 적용합니다. 게이트웨이는 TTL이 만료되면 DNS 정보를 조회 후 업데이트합니다. 조회 과정에서 애플리케이션 게이트웨이가 응답을 받지 못하거나 DNS 레코드를 찾을 수 없을 때, 게이트웨이는 마지막으로 확인된 정상 DNS 값을 사용하여 트래픽을 처리합니다. 자세한 내용은 애플리케이션 게이트웨이의 작동 원리를 참조하세요.

애플리케이션 게이트웨이의 인스턴스는 가상 네트워크의 DNS 구성을 사용하여 이름 확인을 수행합니다. DNS 서버 구성이 변경되면 애플리케이션 게이트웨이가 새 DNS 서버를 할당받도록 게이트웨이를 다시 시작(중지 및 시작)해야 합니다. 그때까지 아웃바운드 연결에 대해 FQDN 기반 이름 확인이 제대로 되지 않을 수 있습니다.

네. Application Gateway는 DNS 서버가 확인할 수 있는 경우 백엔드 풀에서 짧은 이름(예: server1 또는 backend)을 해결할 수 있습니다. 온-프레미스, Azure 가상 네트워크 또는 하이브리드 환경을 비롯한 모든 네트워크 설정에서 작동합니다.

짧은 이름 확인을 활성화하려면 다음 단계를 따르세요.

• 가상 네트워크의 DNS 서버는 짧은 이름을 IP 주소로 변환할 수 있어야 합니다.
• FQDN(정규화된 도메인 이름)과 마찬가지로 짧은 이름 함수 - 게이트웨이가 DNS 서버에 IP 주소를 요청하고 사용합니다.

참고: Azure의 기본 DNS(168.63.129.16)를 사용하는 경우 동일한 가상 네트워크의 리소스에 대한 짧은 이름만 확인할 수 있습니다. 온-프레미스 짧은 이름을 확인하려면 내부 도메인 이름을 처리할 수 있는 사용자 지정 DNS 서버를 설정합니다.

자세한 내용은 Application Gateway의 DNS 확인 이해를 참조하세요.

아니요. 하지만 다른 애플리케이션 게이트웨이의 경우 서브넷에 배포하는 것이 가능합니다.

애플리케이션 게이트웨이는 같은 가상 네트워크 안에서 서브넷 간 이동만 지원합니다. v1은 퍼블릭 및 프라이빗 프런트 엔드(동적 할당)를 모두 지원하며, v2는 퍼블릭 프런트 엔드만 지원합니다. 프라이빗 프런트 엔드 IP 구성이 정적 할당된 애플리케이션 게이트웨이는 다른 서브넷으로 이동할 수 없습니다. 애플리케이션 게이트웨이가 중지되어 있어야 이 작업을 수행할 수 있습니다. v1을 중단하거나 시작할 때 공용 IP가 변경됩니다. 이 작업은 Azure PowerShell과 Azure CLI를 통해 다음 명령을 실행해야만 가능합니다.

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

더 자세한 내용은 Set-AzApplicationGatewayIPConfiguration을 참조하세요.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Application Gateway 서브넷의 네트워크 보안 그룹을 참조하세요.

Application Gateway 서브넷에서 사용자 정의 경로를 지원을 참조하세요.

아니요. 스토리지 계정에 대한 서비스 엔드포인트 정책은 Application Gateway 서브넷에서 지원되지 않으므로, 이를 구성할 경우 Azure 인프라 트래픽이 차단될 수 있습니다.

Application Gateway 제한을 참조하세요.

네. Application Gateway는 애플리케이션 게이트웨이마다 내부 IP 하나와 외부 IP 하나를 지원합니다.

네. 가상 네트워크 피어링을 통해 다른 가상 네트워크의 트래픽 부하를 분산할 수 있습니다.

네, 트래픽만 허용된다면 가능합니다.

마이크로서비스 아키텍처를 지원합니다. 여러 포트에서 검색하려면 다양한 백엔드 설정을 구성해야 합니다.

아니요.

처리 규칙 순서를 참조하세요.

호스트 필드는 Application Gateway에 다중 사이트가 구성되었을 때 프로브를 전송할 이름을 지정합니다. 그렇지 않으면 127.0.0.1를 사용합니다. 이 값은 가상 머신 호스트 이름과 차이가 있습니다. 형식은 <프로토콜>://<호스트>:<포트><경로>입니다.

네. 특정 원본 IP로 액세스 제한을 참조하세요.

네, 같은 포트 번호를 사용하는 퍼블릭 연결 수신기와 프라이빗 연결 수신기를 통해 퍼블릭 클라이언트와 프라이빗 클라이언트를 동시에 지원하는 것이 가능합니다. application gateway의 서브넷이 NSG(네트워크 보안 그룹)와 연결되면, 해당 구성에 따라 특정 인바운드 규칙이 필요할 수 있습니다. 자세히 알아보기.

Application Gateway v2는 IPv4 프런트 엔드와 IPv6 프런트 엔드를 지원합니다. IPv6 지원 기능은 현재 새로운 애플리케이션 게이트웨이에서만 제공됩니다. IPv6 지원을 위해 가상 네트워크는 이중 스택 구조를 갖춰야 합니다. Application Gateway v1에서는 듀얼 스택 가상 네트워크가 지원되지 않습니다.

Application Gateway SKU는 일반적으로 "FIPS 모드"라고 하는 FIPS 140-2 승인된 작업 모드에서 실행할 수 있습니다. FIPS 모드는 FIPS 140-2 유효성이 검사된 암호화 모듈을 호출하여 사용하도록 설정할 때 암호화, 해시 및 서명을 위한 FIPS 규격 알고리즘을 보장합니다. FIPS 모드를 사용하도록 설정 FIPSMode 하려면 포털(V2), PowerShell, Azure Resource Manager 템플릿 또는 REST API를 통해 설정을 구성해야 합니다.

V2 SKU에서 FIPS 모드를 사용하도록 설정하는 단계: Azure Application Gateway V2 SKU에 FIPS 모드 사용을 참조하세요.

V1 SKU에서 FIPS 모드를 활성화하는 단계:

단계 1: ‘AllowApplicationGatewayEnableFIPS’ 기능을 등록하여 FIPS 모드 구성에 대해 구독을 등록합니다.

Azure PowerShell을 사용하여 등록하려면 Cloud Shell 프롬프트에서 다음을 입력하세요.

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Azure Portal을 사용하여 등록하려면:

• Azure Portal로 로그인하여 미리 보기 기능을 검색합니다.
• 필터 상자에 AllowApplicationGatewayEnableFIPS를 입력합니다. Application Gateway V1 FIPS 모드 허용을 선택한 다음 등록을 선택합니다.

2단계: PowerShell, Azure Resource Manager 템플릿 또는 REST API를 사용하여 enableFips 속성을 True로 설정합니다.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

FIPS 모드를 변경하더라도 V1 게이트웨이에서 사용 가능한 모든 암호화 제품군에는 영향이 없습니다. 하지만 타원 곡선 암호화 에서 FIPS 모드가 비활성화되면 curve25519, NistP256, NistP384를 사용할 수 있으나, 활성화되면 NistP256, NistP384만 사용 가능하고 curve25519는 사용할 수 없습니다. FIPS 모드에서는 curve25519를 사용할 수 없으므로, FIPS를 활성화하기 전에 클라이언트가 보안 통신 시 NistP256 또는 NistP384를 지원하는지 확인해야 합니다.

Application Gateway v2는 이제 프라이빗 IP 프런트 엔드 구성만 지원합니다. 자세한 내용은 프라이빗 Application Gateway 배포를 참조하세요.

Application Gateway v2는 다음 조합을 지원합니다.

• 개인 IP 및 공용 IP
• 공용 IP 전용
• 개인 IP만

Application Gateway는 Azure PowerShell 또는 Azure CLI를 사용하여 중지했다가 시작할 수 있습니다. Application Gateway를 중지하고 시작하면 청구도 중지되고 시작됩니다. 애플리케이션 게이트웨이가 중지된 상태에서 태그, 상태 프로브, 수신기 추가 등의 PUT 작업을 수행하면 게이트웨이 시작이 트리거됩니다. application gateway 구성을 업데이트한 후에는 중지하는 것이 좋습니다.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway는 자체 서명된 인증서, CA(인증 기관) 인증서, EV(확장 유효성 검사) 인증서, 다중 도메인(SAN) 인증서 및 와일드 카드 인증서를 지원합니다.

Application Gateway에서는 다음 암호화 도구 모음을 지원합니다.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS 옵션을 사용자 지정하는 방법은 Application Gateway에서 TLS 정책 버전 및 암호 그룹 구성을 참조하세요.

네. Application Gateway는 TLS 오프로드 외에도 백 엔드로 전송되는 트래픽을 다시 암호화하는 엔드 투 엔드 TLS를 지원합니다.

네. Application Gateway를 구성하여 TLS1.0, TLS1.1, 및 TLS1.2. 버전을 거부할 수 있습니다. SSL 2.0 및 3.0은 기본적으로 비활성화되어 있으며, 사용자가 임의로 구성할 수 없습니다.

네. Application Gateway에서는 암호 그룹을 구성할 수 있습니다. 사용자 지정 정책을 정의할 때, 다음 암호화 도구 모음 중에서 하나 이상을 선택하여 사용해야 합니다.

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway는 백엔드 관리를 위해 SHA256을 사용합니다.

Application Gateway는 최대 100의 TLS/SSL 인증서를 지원합니다.

네, Application Gateway는 서버 인증서에 대해 OCSP 확장 및 OCSP 스테이플링을 사용하는 인증서를 지원합니다.

Application Gateway는 최대 100개의 인증 인증서를 지원합니다.

예, Application Gateway v2 SKU는 주요 자격 증명 모음을 지원합니다. 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

다중 도메인 기반(호스트 기반) 라우팅을 위해 여러 사이트 수신기를 생성하고, HTTPS 프로토콜을 사용하는 수신기를 설정한 다음, 해당 수신기를 라우팅 규칙과 연결할 수 있습니다. 자세한 내용은 Application Gateway를 사용하여 여러 사이트 호스팅을 참조하세요.

아니요. .pfx 파일 암호로는 영숫자 문자만 사용해야 합니다.

Certificate Authority(CA) Browser 포럼은 최근 본사 고객, Microsoft, 그리고 기술 커뮤니티에서 널리 사용되지만, 공개적으로 신뢰할 수 있는 CA의 산업 표준을 준수하지 않는 CA 공급업체에서 발급된 여러 인증서에 대한 정보를 담은 보고서를 발표했습니다. 규격에 맞지 않는 CA 관련 보고서는 다음 위치에서 찾아볼 수 있습니다.

• 버그 1649951
• 버그 1650910

업계 규정 준수 요구 사항에 따라 CA 공급업체에서 규정을 준수하지 않는 CA를 해지하고, 이제 요구 사항을 준수하는 CA를 발급하기 시작했으므로 고객은 인증서를 다시 발급받아야 합니다. Microsoft는 Azure 서비스에 대한 잠재적 영향을 최소화하기 위해 해당 공급업체와 긴밀하게 협력하고 있습니다. 하지만 Bring Your Own Certificate (BYOC) 환경에서 쓰이는 자체 발급 인증서는 예상치 못한 이유로 해지될 가능성이 남아 있습니다.

애플리케이션에서 사용하는 인증서의 해지 여부를 확인하려면 DigiCert 발표 및 인증서 해지 추적기를 참고하세요. 인증서가 해지되었거나 해지될 예정인 경우, 애플리케이션에서 사용하려면 CA 공급업체에 새 인증서를 요청해야 합니다. 인증서가 예기치 않게 해지되어 애플리케이션의 가용성이 중단되는 상황을 방지하거나, 해지된 인증서를 업데이트해야 하는 경우, 고객의 Azure 서비스에 영향을 줄 수 있는 비규격 인증 기관의 해지 정보를 참조하세요.

Application Gateway와 관련된 자세한 내용:

해지된 ICA에서 발급한 인증서를 사용하는 경우 애플리케이션을 사용하지 못할 수 있습니다. 애플리케이션에 따라 다음을 포함한 여러 오류 메시지가 나타날 수 있습니다.

• 잘못된 인증서/해지된 인증서
• 연결 시간이 초과됨
• HTTP 502

애플리케이션이 이 문제로 인해 중단되는 것을 방지하거나 해지된 CA를 재발급하려면 다음 작업을 수행해야 합니다.

1. 인증서 다시 발급 방법을 인증서 공급자에게 문의합니다.
2. 인증서를 재발급받았다면 전체 신뢰 체인(리프, 중간, 루트 인증서)을 사용하여 Azure Application Gateway/WAF에서 해당 인증서를 업데이트하세요. 애플리케이션 게이트웨이의 수신기 또는 HTTP 설정에서 인증서 사용 위치에 따라 다음 단계에 따라 인증서를 업데이트합니다. 자세한 내용은 언급된 설명서 링크를 참조하시기 바랍니다.
3. 재발급된 인증서를 사용하려면 백 엔드 애플리케이션 서버를 업데이트합니다. 인증서 업데이트 단계는 사용 중인 백엔드 서버에 따라 다를 수 있습니다. 공급업체의 설명서를 확인합니다.

수신기에서 인증서를 업데이트하려면 다음을 수행합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서에 연결된 수신기 설정을 엽니다.
3. 선택한 인증서 갱신 또는 편집을 선택하세요.
4. 암호를 사용하여 새 PFX 인증서를 업로드한 다음, 저장을 클릭합니다.
5. 웹 사이트에 액세스하여 사이트가 예상대로 작동하는지 확인합니다. 자세한 내용은 Application Gateway 인증서 갱신을 참조하세요.

Application Gateway 수신기에서 Key Vault 인증서를 참조하는 경우, 다음 단계에 따라 신속하게 변경하는 것이 좋습니다.

1. Azure Portal에서 애플리케이션 게이트웨이에 연결된 Key Vault 설정으로 이동합니다.
2. 저장소에서 재발급된 인증서를 추가하거나 저장소로 가져옵니다. 자세한 내용은 빠른 시작: Azure Portal을 사용하여 키 자격 증명 모음 만들기를 참조하세요.
3. 인증서를 가져왔다면 Application Gateway 수신기 설정으로 이동하여 Key Vault에서 인증서 선택에서 인증서 드롭다운 목록을 선택하고, 최근에 추가한 인증서 를 선택합니다.
4. 저장을 선택합니다. Application Gateway에서 Key Vault 인증서를 사용하여 TLS를 종료하는 방법에 대한 자세한 내용은 관련 문서를 참조하세요.

HTTP 설정에서 인증서를 업데이트하려면 다음 단계를 따르세요.

Application Gateway/WAF 서비스에서 v1 SKU를 사용하는 경우, 백엔드 인증서 인증을 위해 새 인증서를 업로드해야 합니다.

1. Azure Portal에서 Application Gateway 리소스를 엽니다.
2. 인증서에 연결된 HTTP 설정을 엽니다.
3. 인증서 추가를 선택하고, 재발급된 인증서를 업로드한 다음 저장 버튼을 선택합니다.
4. 이전 인증서는 나중에 해당 인증서 옆에 있는 ... 옵션 버튼을 선택하여 제거할 수 있습니다. 삭제을 선택한 후 저장를 선택합니다. 자세한 내용은 포털에서 Application Gateway를 사용하여 엔드투엔드 TLS 구성을 참조하세요.

Application Gateway/WAF 서비스 V2 SKU를 사용하는 경우, V2 SKU는 ‘신뢰할 수 있는 루트 인증서’를 사용하므로 HTTP 설정에서 별도로 새 인증서를 업로드할 필요가 없습니다.

네. Application Gateway를 통한 L7 및 L4 라우팅은 모두 동일한 프런트 엔드 IP 구성을 사용합니다. 이 방식을 사용하면 모든 클라이언트는 단일 IP 주소(공용 또는 사설)로 지정되며, 동일한 게이트웨이 리소스에 구성된 수신 프로토콜 및 포트에 따라 클라이언트가 라우팅됩니다.

HTTP(S) 트래픽은 L4 프록시 프로토콜을 통해 제공될 수도 있지만, 권장하지는 않습니다. Application Gateway의 L7 프록시 솔루션은 HTTP(S) 프로토콜에 대한 강력한 제어 및 보안을 제공하며, 재작성, 세션 선호도, 리디렉션, WebSocket, WAF 등의 유용한 기능을 지원합니다.

계층 4 기능의 리소스 속성은 계층 7 기능의 리소스 속성과 다릅니다. 그러므로 REST API나 CLI를 사용할 때에는 다음 속성을 활용해야 합니다.

속성	목적
수신기	TLS 또는 TCP 기반 수신기의 경우
routingRule	계층 4 수신기를 계층 4 백 엔드 설정과 연결하려면
backendSettingsCollection	TLS 또는 TCP 기반 백 엔드 설정의 경우

• REST API
• CLI

참고

계층 4 속성은 HTTP 또는 HTTPS 프로토콜 설정에 사용할 수 없습니다.

아니요. 계층 4와 계층 7 속성은 상호 연결할 수 없습니다. 결과적으로, 라우팅 규칙을 적용하면 L4 형식의 수신기는 반드시 L4 형식의 백엔드 설정과 연결되도록 제한됩니다.

L7(httpListeners)과 L4(수신기)의 이름은 동일하게 지정할 수 없습니다. 이는 backendSettingsCollection, RoutingRules와 같은 다른 L4 속성에도 마찬가지로 적용됩니다.

그럼요. 계층 7 프록시처럼 애플리케이션 게이트웨이의 백 엔드 풀에 프라이빗 엔드포인트를 추가할 수 있습니다. 이 프라이빗 엔드포인트는 애플리케이션 게이트웨이와 동일한 가상 네트워크에서 인접한 서브넷에 배포해야 합니다.

백엔드 연결에서는 Keepalive를 사용하지 않습니다. Application Gateway는 프런트 엔드 수신기 연결을 통해 들어오는 각 요청을 처리하기 위해 새로운 백 엔드 연결을 시작합니다.

백엔드 서버에서는 애플리케이션 게이트웨이의 IP 주소를 확인합니다. 현재 백엔드 애플리케이션은 클라이언트 IP 보존을 지원하지 않아, 원래 클라이언트의 IP 주소를 인식할 수 없습니다.

계층 7(HTTPS)과 계층 4(TLS) 모두에 동일한 TLS/SSL 정책 구성이 적용됩니다. 이제 TLS 수신기에 SSL 프로필을 사용하여 수신기별 TLS 정책 및 상호 인증을 구성할 수 있습니다. 하지만 현재 SSL 프로필은 CLI, PowerShell 또는 REST API를 통해서만 TLS 수신기에 연결할 수 있습니다.

아니요. 현재 클라이언트를 동일한 백엔드 서버로 라우팅하는 기능은 지원되지 않습니다. 연결은 백엔드 풀의 서버에 라운드 로빈 방식으로 분산됩니다.

네, 자동 크기 조절 기능은 TLS 또는 TCP 프로토콜 트래픽의 급증 및 감소에도 효과적으로 작동합니다.

Web Application Firewall (WAF) 기능은 레이어 4 환경에서는 작동하지 않습니다.

아니요. 현재 UDP 지원은 제공되지 않고 있습니다.

동일한 허용 포트 범위 및 예외 목록은 레이어 4 프록시에도 동일하게 적용됩니다.

현재 TLS/TCP 수신기에 공통 포트를 사용하는 기능은 지원되지 않습니다.

Kubernetes를 통해 deployment 과 service 리소스를 만들어 클러스터 내에서 Pod 그룹을 외부에 공개할 수 있습니다. 외부에 동일한 서비스를 공개할 때 필요한 부하 분산, TLS 종료, 이름 기반 가상 호스팅을 제공하는 Ingress 리소스가 정의됩니다. 이러한 Ingress 리소스 요구 사항을 충족하려면 Ingress리소스 변경 사항을 수신 대기하고 load balancer 정책을 구성하는 수신 컨트롤러가 필요합니다.

Application Gateway Ingress Controller(AGIC)는 AKS 클러스터라고도 하는 Azure Kubernetes Service에서 Application Gateway 를 수신으로 사용할 수 있도록 합니다.

Application Gateway를 직접 구성하는 기능은 지원되지 않습니다.

Application Gateway의 설정을 변경해야 할 때는 수신 컨트롤러나 다른 Kubernetes 개체에 구성된 내용(예: 지원되는 주석)을 이용하여 변경해야 합니다. Application Gateway가 AGIC(Application Gateway 수신 컨트롤러)에 연결되면 해당 게이트웨이의 거의 모든 구성이 수신 컨트롤러에 의해 동기화되고 제어됩니다. 명령 또는 코드 형태의 인프라를 통해 Application Gateway를 직접 구성하더라도, 결국 수신 컨트롤러가 이러한 변경 사항을 덮어쓰게 됩니다.

현재는 하나의 수신 컨트롤러 인스턴스만 하나의 Application Gateway에 연결할 수 있습니다.

AGIC는 Application Gateway 서브넷에 경로 테이블 리소스를 자동으로 연결하려 하지만, 필요한 권한이 없어 실패할 가능성이 있습니다. AGIC가 경로 테이블을 Application Gateway 서브넷에 연결하지 못할 경우 AGIC 로그에 오류가 표시됩니다. 이러한 경우, AKS 클러스터에서 생성된 경로 테이블을 Application Gateway 서브넷에 수동으로 연결해야 합니다. 자세한 내용은 지원되는 사용자 정의 경로를 참조하세요.

가상 네트워크가 피어링되어 연결되어 있고, 주소 공간이 중복되지 않는다면 가능합니다. Kubenet을 사용하는 경우, AKS에서 생성된 경로 테이블을 Application Gateway 서브넷에 연결해야 AKS가 실행됩니다.

AGIC가 Helm을 통해 배포된 경우와 AKS 추가 기능으로 배포된 경우의 차이점은 Helm 배포와 AKS 추가 기능 간의 차이점을 참고하면 됩니다.

AGIC를 Helm을 통해 배포했을 때와 AKS 추가 항목으로 배포했을 때의 차이점은, Helm 배포와 AKS 추가 항목 간의 차이점을 비교하여 AKS 추가 항목이 아닌 Helm을 통해 배포된 AGIC에서 지원하는 시나리오를 표로 정리한 문서를 참조하세요. Helm을 통해 배포할 때, 일반적으로 공식 릴리스 전 베타 기능 및 릴리스 후보를 테스트하는 것이 가능합니다.

아니요. AGIC 추가 기능은 관리형 서비스이므로 Microsoft에서 추가 기능을 최신 안정화 버전으로 자동 업데이트합니다.

예, Kubenet 또는 CNI에서 CNI 오버레이로 AKS 클러스터를 업그레이드하면 Application Gateway 수신 컨트롤러에서 자동으로 이를 감지합니다. 트래픽 중단을 방지하기 위해 유지 관리 기간에 업그레이드를 예약하는 것이 좋습니다. 컨트롤러가 클러스터 업그레이드 후 CNI 오버레이에 대한 지원을 검색하고 구성하는 데 몇 분 정도 소요될 수 있습니다.

상호 인증은 클라이언트와 서버가 서로를 인증하는 양방향 인증 방식입니다. 현재까지 Application Gateway에서는 상호 인증을 통해 게이트웨이가 클라이언트 인증인 요청을 전송하는 클라이언트를 확인할 수 있습니다. 일반적으로 클라이언트는 Application Gateway에 대해 인증하는 유일한 항목입니다. 이제는 Application Gateway도 클라이언트를 인증할 수 있기 때문에 Application Gateway와 클라이언트가 서로를 상호 인증하는 상호 인증이 되었습니다.

아니요, 현재 상호 인증은 프런트 엔드 클라이언트와 애플리케이션 게이트웨이 간에만 지원됩니다. 현재 백엔드 상호 인증은 지원되지 않습니다.

Application Gateway는 다음 세 가지 로그를 제공합니다.

• ApplicationGatewayAccessLog: 이 액세스 로그에는 애플리케이션 게이트웨이 프런트 엔드로 제출된 각 요청에 대한 정보가 담겨 있습니다. 이 데이터는 호출자의 IP 주소, 요청 URL, 응답 대기 시간, 반환 코드, 바이트 입출력 정보를 담고 있으며, 각 애플리케이션 게이트웨이에 대해 하나의 레코드로 기록됩니다.
• ApplicationGatewayPerformanceLog: 이 성능 로그는 각 애플리케이션 게이트웨이의 성능 관련 정보를 수집합니다. 이 정보에는 처리량(바이트 단위), 총 요청 처리 건수, 실패 요청 건수, 정상 및 비정상 백엔드 인스턴스 수가 포함됩니다.
• ApplicationGatewayFirewallLog: WAF를 사용하여 구성된 Application Gateway의 방화벽 로그에는 검색 모드 또는 방지 모드로 기록된 요청이 포함됩니다.

로그는 전부 60초마다 한 번씩 수집됩니다. 자세한 내용은 Application Gateway에 대한 백 엔드 상태, 진단 로그 및 메트릭을 참조하시길 바랍니다.

PowerShell cmdlet Get-AzApplicationGatewayBackendHealth 또는 포털을 사용하여 상태를 확인할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

진단 로그는 고객의 스토리지 계정으로 전송됩니다. 고객은 필요에 따라 보존 정책을 자유롭게 설정할 수 있습니다. 진단 로그는 이벤트 허브나 Azure Monitor 로그로도 전송할 수 있습니다. 자세한 내용은 Application Gateway 진단을 참조하세요.

감사 로그에 액세스하려면 포털의 Application Gateway 메뉴 블레이드에서 활동 로그 를 클릭하면 됩니다.

네. Application Gateway에서 경고는 메트릭을 기준으로 구성됩니다. 자세한 내용은 Application Gateway 메트릭 및 경고 알림 받기를 참조하세요.

액세스 로그는 다양한 방식으로 살펴보고 분석할 수 있습니다. Azure Monitor 로그, Excel, Power BI 등을 활용합니다.

Application Gateway 액세스 로그 분석을 위해 널리 사용되는 GoAccess 로그 분석기를 설치하고 실행할 수 있는 Resource Manager 템플릿이 있습니다. GoAccess는 고유 방문자 수, 요청된 파일, 호스트, 운영 체제, 브라우저, HTTP 상태 코드 등 HTTP 트래픽에 대한 유용한 통계 자료를 제공합니다. 자세한 내용은 GitHub의 Resource Manager 템플릿 폴더에 있는 Readme 파일 을 참조하세요.

일반적으로 Application Gateway 서브넷에서 NSG, 사용자 지정 DNS 또는 사용자 정의 라우팅으로 인해 백 엔드 액세스가 차단되면 알 수 없는 상태가 표시됩니다. 자세한 내용은 Application Gateway의 백 엔드 상태, 진단 로그 및 메트릭 을 참조하시기 바랍니다.

현재 플랫폼의 한계로 인해 NSG가 Application Gateway v2(Standard_v2, WAF_v2) 서브넷에 있는 경우 NSG 흐름 로그를 사용하면 예측 불가능한 동작이 발생할 수 있습니다. 이 시나리오는 현재 지원되지 않습니다.

Application Gateway는 고객 데이터를 배포된 지역 외부에 이동하거나 저장하는 일이 없습니다.

다음 단계

• Application Gateway 메트릭에 대해 자세히 알아보려면 Azure Application Gateway란 무엇입니까를 참조하세요.
• Application Gateway를 사용한 TLS 종료 및 엔드투엔드 TLS에 대해 알아보려면 Azure Application Gateway에서 엔드투엔드 TLS 사용을 참조하세요.