애플리케이션 게이트웨이 작동 원리
이 문서에서는 애플리케이션 게이트웨이에서 들어오는 요청을 수락하고 백 엔드로 라우팅하는 방법을 설명합니다.
애플리케이션 게이트웨이에서 요청을 수락하는 방법
클라이언트는 애플리케이션 게이트웨이에 요청을 보내기 전에 DNS(Domain Name System) 서버를 사용하여 애플리케이션 게이트웨이의 도메인 이름을 확인합니다. 모든 애플리케이션 게이트웨이가 azure.com 도메인에 있기 때문에 Azure는 DNS 항목을 제어합니다.
Azure DNS은 클라이언트에 대한 IP 주소를 반환합니다. 이 주소는 애플리케이션 게이트웨이의 프런트 엔드 IP 주소입니다.
애플리케이션 게이트웨이는 하나 이상의 수신기에서 들어오는 트래픽을 수락합니다. 수신기는 연결 요청을 확인하는 논리적 엔터티입니다. 이는 클라이언트에서 애플리케이션 게이트웨이로의 연결을 위한 프런트 엔드 IP 주소, 프로토콜 및 포트 번호를 사용하여 구성됩니다.
WAF(Web Application Firewall)를 사용 중인 경우 애플리케이션 게이트웨이는 요청 헤더와 본문(있는 경우)을 WAF 규칙에 대해 확인합니다. 이 작업은 요청이 유효한 요청인지 아니면 보안 위협인지를 결정합니다. 요청이 올바르면 백 엔드로 라우팅됩니다. 요청이 유효하지 않고 WAF가 방지 모드이면 보안 위협으로 차단됩니다. 검색 모드에 있는 경우 요청은 평가되고 기록되지만 여전히 백 엔드 서버로 전달됩니다.
Azure Application Gateway를 내부 애플리케이션 부하 분산 장치 또는 인터넷 연결 애플리케이션 부하 분산 장치로 사용할 수 있습니다. 인터넷 연결 애플리케이션 게이트웨이는 공용 IP 주소를 사용합니다. 인터넷 연결 애플리케이션 게이트웨이의 DNS 이름은 공용 IP 주소를 통해 공개적으로 확인할 수 있습니다. 결과적으로 인터넷 연결 애플리케이션 게이트웨이는 인터넷에서 클라이언트 요청을 라우팅할 수 있습니다.
내부 애플리케이션 게이트웨이는 개인 IP 주소만 사용합니다. 사용자 지정 또는 프라이빗 DNS 영역을 사용하는 경우 Application Gateway의 개인 IP 주소에서 도메인 이름을 내부적으로 확인할 수 있어야 합니다. 따라서 내부 부하 분산 장치는 애플리케이션 게이트웨이의 가상 네트워크에 대한 액세스 권한이 있는 클라이언트의 요청만 라우팅할 수 있습니다.
애플리케이션 게이트웨이에서 요청을 라우팅하는 방법
요청이 유효하고 WAF에 의해 차단되지 않았다면 애플리케이션 게이트웨이는 수신기와 연결된 요청 라우팅 규칙을 평가합니다. 이 작업은 요청을 라우팅할 백 엔드 풀을 확인합니다.
요청 라우팅 규칙에 따라 애플리케이션 게이트웨이는 수신기의 모든 요청을 특정 백 엔드 풀로 라우팅하도록 할지 여부를 결정하고, URL 경로를 기반으로 하는 다른 백 엔드 풀에 요청을 라우팅하거나, 다른 포트나 외부 사이트에 대한 요청을 리디렉션합니다.
참고 항목
규칙은 v1 SKU 포털에 나열된 순서대로 처리됩니다.
애플리케이션 게이트웨이는 백 엔드 풀을 선택할 때 풀 (y.y.y.y)의 정상 백 엔드 서버 중 하나로 요청을 보냅니다. 서버의 상태는 상태 프로브에 의해 결정됩니다. 백 엔드 풀에 여러 서버가 포함된 경우 애플리케이션 게이트웨이는 라운드 로빈 알고리즘을 사용하여 정상 서버 간에 요청을 라우팅합니다. 이렇게 하면 서버에서 요청 부하가 분산됩니다.
애플리케이션 게이트웨이는 백 엔드 서버를 확인한 후 HTTP 설정에 따라 백 엔드 서버를 사용하여 새 TCP 세션을 엽니다. HTTP 설정은 백 엔드 서버와의 새 세션을 설정하는 데 필요한 프로토콜, 포트 및 기타 라우팅 관련 설정을 지정합니다.
HTTP 설정에 사용되는 포트 및 프로토콜에 따라 애플리케이션 게이트웨이와 백 엔드 서버 간의 트래픽이 암호화되는지(이 경우 엔드투엔드 TLS가 수행됨) 또는 암호화되지 않았는지 판단합니다.
애플리케이션 게이트웨이가 백 엔드 서버에 원래 요청을 보내면 호스트 이름, 경로 및 프로토콜을 재정의하는 것과 관련된 HTTP 설정에서 설정된 사용자 지정 구성이 적용됩니다. 이 작업은 쿠키 기반 세션 선호도, 연결 드레이닝, 호스트 이름 선택이 백 엔드에서 유지되도록 합니다.
참고 항목
백 엔드 풀:
- 공용 엔드포인트인 경우 애플리케이션 게이트웨이는 프런트 엔드 공용 IP를 사용하여 서버에 연결합니다. 프런트 엔드 공용 IP 주소가 없으면 아웃바운드 외부 연결에 대해 하나가 할당됩니다.
- 내부적으로 확인할 수 있는 FQDN 또는 개인 IP 주소를 포함하는 경우 애플리케이션 게이트웨이는 해당 인스턴스 개인 IP 주소를 사용하여 백 엔드 서버로 요청을 라우팅합니다.
- 외부 엔드포인트 또는 외부적으로 확인할 수 있는 FQDN을 포함하는 경우 애플리케이션 게이트웨이는 프런트 엔드 공용 IP 주소를 사용하여 백 엔드 서버로 요청을 라우팅합니다. 서브넷에 서비스 엔드포인트가 포함된 경우 애플리케이션 게이트웨이는 해당 개인 IP 주소를 통해 요청을 서비스로 라우팅합니다. DNS 확인은 프라이빗 DNS 영역 또는 사용자 지정 DNS 서버(구성된 경우)를 기반으로 하거나 Azure에서 제공하는 기본 DNS를 사용합니다. 프런트 엔드 공용 IP 주소가 없으면 아웃바운드 외부 연결에 대해 하나가 할당됩니다.
백 엔드 서버 DNS 확인
백 엔드 풀의 서버가 FQDN(정규화된 도메인 이름)으로 구성된 경우 Application Gateway는 DNS 조회를 수행하여 도메인 이름의 IP 주소를 가져옵니다. IP 값은 들어오는 요청을 처리할 때 대상에 더 빠르게 도달할 수 있도록 애플리케이션 게이트웨이의 캐시에 저장됩니다.
Application Gateway는 DNS 레코드의 TTL(TTL)과 동일한 기간 동안 이 캐시된 정보를 유지하고 TTL이 만료되면 새 DNS 조회를 수행합니다. 게이트웨이가 후속 DNS 쿼리에 대한 IP 주소 변경을 감지하면 트래픽을 이 업데이트된 대상으로 라우팅하기 시작합니다. DNS 조회가 응답을 받지 못하거나 레코드가 더 이상 존재하지 않는 경우 게이트웨이는 마지막으로 알려진 정상 IP 주소를 계속 사용합니다. 이렇게 하면 데이터 경로에 미치는 영향을 최소화할 수 있습니다.
Important
- Application Gateway의 Virtual Network와 함께 사용자 지정 DNS 서버를 사용하는 경우 모든 서버가 동일한 DNS 값으로 일관되게 응답해야 합니다. Application Gateway의 인스턴스는 DNS 쿼리를 발급할 때 먼저 응답하는 서버의 값을 사용합니다.
- 온-프레미스 사용자 지정 DNS 서버의 사용자는 프라이빗 엔드포인트에 프라이빗 DNS 영역을 사용하는 경우 Azure DNS Private Resolver(권장) 또는 DNS 전달자 VM을 통해 Azure DNS에 대한 연결을 확인해야 합니다.
요청에 대한 수정
애플리케이션 게이트웨이는 백 엔드에 요청을 전달하기 전에 모든 요청에 6개의 추가 헤더를 삽입합니다. 이러한 헤더는 x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url 및 x-appgw-trace-id입니다. x-forwarded-for 헤더의 형식은 IP:port의 쉼표로 구분된 목록입니다.
x-forwarded-proto에 대해 유효한 값은 HTTP 또는 HTTPS입니다. X-forwarded-port는 Application Gateway에서 요청이 전송된 포트를 지정합니다. X-original-host에는 도착한 요청의 원래 호스트 헤더가 포함됩니다. 이 헤더는 트래픽을 백 엔드로 라우팅하기 전에 들어오는 호스트 헤더가 수정되는 Azure 웹 사이트 통합에서 유용합니다. 세션 선호도가 옵션으로 사용하도록 설정된 경우 게이트웨이 관리 선호도 쿠키가 추가됩니다.
X-appgw-trace-id는 각 클라이언트 요청에 대해 애플리케이션 게이트웨이에서 생성되고 백 엔드 풀 멤버에게 전달된 요청에 표시되는 고유한 guid입니다. guid는 대시 없이 표시되는 32개의 영숫자로 구성됩니다(예: ac882cd65a2712a0fe1289ec2bb6aee7). 이 guid는 애플리케이션 게이트웨이에서 수신하고 진단 로그의 transactionId 속성을 통해 백 엔드 풀 멤버로 시작된 요청의 상관 관계를 지정하는 데 사용할 수 있습니다.
HTTP 헤더 및 URL 재작성을 사용하여 요청 및 응답 헤더와 URL을 수정하거나 경로 재정의 설정을 사용하여 URI 경로를 수정하도록 애플리케이션 게이트웨이를 구성할 수 있습니다. 그러나 이 작업을 수행하도록 구성되지 않은 경우 들어오는 모든 요청은 백 엔드로 프록시됩니다.