이전

다음

Azure Application Gateway 계획 및 구현

완료됨

Azure Application Gateway는 웹 애플리케이션 트래픽을 관리할 수 있는 웹 트래픽(OSI 계층 7) 부하 분산 장치입니다. 기존 부하 분산 장치는 전송 계층(OSI 계층 4 - TCP 및 UDP)에서 작동하고 원본 IP 주소와 포트를 기반으로 대상 IP 주소와 포트에 트래픽을 라우팅합니다.

Application Gateway는 URI 경로 또는 호스트 헤더와 같은 HTTP 요청의 추가 특성을 기반으로 라우팅 결정을 내릴 수 있습니다. 예를 들어 들어오는 URL을 기반으로 하는 트래픽을 라우팅할 수 있습니다. 따라서 /images가 들어오는 URL에 있는 경우 이미지에 대해 구성된 서버(풀이라고도 함)의 특정 집합에 트래픽을 라우팅할 수 있습니다. /video가 URL에 있으면 해당 트래픽은 비디오에 대해 최적화된 다른 풀로 라우팅됩니다.

이 유형의 라우팅은 애플리케이션 계층(OSI 계층 7) 부하 분산이라고 합니다. Azure Application Gateway는 URL 기반 라우팅 및 기타 작업을 수행할 수 있습니다.

Application Gateway 구성 요소

애플리케이션 게이트웨이는 클라이언트의 단일 연락 지점으로 사용됩니다. 수신 애플리케이션 트래픽을 Azure VM, 가상 머신 확장 집합, Azure App Service, 온-프레미스/외부 서버가 포함된 여러 백 엔드 풀에 분산합니다.

인프라

Application Gateway 인프라에는 가상 네트워크, 서브넷, 네트워크 보안 그룹 및 사용자 정의 경로가 포함됩니다.

프런트 엔드 IP 주소

공용 IP 주소, 개인 IP 주소 또는 둘 다를 사용하도록 애플리케이션 게이트웨이를 구성할 수 있습니다. 클라이언트가 VIP(인터넷 연결 가상 IP)를 사용하여 인터넷을 통해 액세스해야 하는 백 엔드를 호스트하는 경우 공용 IP가 필요합니다.

공용 IP 주소는 인터넷에 노출되지 않은 내부 엔드포인트에는 필요하지 않습니다. 프라이빗 프런트 엔드 구성은 인터넷에 노출되지 않은 내부 LOB(기간 업무) 애플리케이션에 유용합니다. 이는 인터넷에 노출되지 않은 보안 경계 내 다중 계층 애플리케이션의 서비스와 계층에도 유용하지만 여전히 라운드 로빈 로드를 분배하거나, 세션을 고정하거나, TLS를 종료해야 합니다.

공용 IP 주소와 개인 IP 주소가 각각 하나씩만 지원됩니다. 애플리케이션 게이트웨이를 만들 때 프런트 엔드 IP를 선택합니다.

참고 항목

Application Gateway 프런트 엔드는 이중 스택 IP 주소(공개 미리 보기)를 지원합니다. 프런트 엔드 IP를 최대 4개 만들 수 있습니다. 두 개는 IPv4 주소(공용, 개인)이고 두 개는 IPv6 주소(공용, 개인)입니다.

• 공용 IP 주소의 경우, 새 공용 IP 주소를 만들거나 애플리케이션 게이트웨이와 동일한 위치의 기존 공용 IP를 사용할 수 있습니다. 자세한 내용은 고정 및 동적 공용 IP 주소 비교를 참조하세요.
• 개인 IP 주소의 경우, 애플리케이션 게이트웨이가 생성되는 서브넷의 개인 IP 주소를 지정할 수 있습니다. Application Gateway v2 SKU 배포는 개인 IP 주소를 게이트웨이에 추가할 때 고정 IP 주소를 정의해야 합니다. Application Gateway v1 SKU 배포는 IP 주소를 지정하지 않은 경우 사용 가능한 IP 주소가 서브넷에서 자동으로 선택됩니다. 선택한 IP 주소 유형(고정 또는 동적)은 나중에 변경할 수 없습니다.

프런트 엔드 IP 주소는 프런트 엔드 IP에서 들어오는 요청을 확인하는 수신기에 연결됩니다.

동일한 포트 번호를 사용하여 개인/공용 수신기를 만들 수 있습니다. 그러나 Application Gateway 서브넷과 연결된 NSG(네트워크 보안 그룹)를 알고 있어야 합니다. NSG의 구성에 따라 애플리케이션 게이트웨이의 퍼블릭/프라이빗 프런트 엔드 IP로 대상 IP 주소를 사용하는 인바운드 허용 규칙이 필요할 수 있습니다. 동일한 포트를 사용하는 경우 애플리케이션 게이트웨이는 인바운드 흐름의 대상을 게이트웨이의 프런트 엔드 IP로 변경합니다.

인바운드 규칙:

• 원본: 사용자 요구 사항에 따름
  
• 대상: 애플리케이션 게이트웨이의 공용/개인 프런트 엔드 IP
• 대상 포트: 구성된 수신기에 따름
• 프로토콜: TCP

아웃바운드 규칙: 특별한 요구 사항 없음

수신기

수신기는 포트, 프로토콜, 호스트, IP 주소를 사용하여 들어오는 연결 요청을 확인하는 논리적 엔터티입니다. 수신기를 구성하는 경우 게이트웨이에 들어오는 요청의 해당 값과 일치하는 설정 값을 입력해야 합니다.

Azure Portal을 사용하여 애플리케이션 게이트웨이를 만들 때 수신기의 프로토콜 및 포트를 선택하여 기본 수신기도 만듭니다. 수신기에서 HTTP2 지원을 사용할지 여부를 선택할 수 있습니다. 애플리케이션 게이트웨이를 만든 후 기본 수신기(appGatewayHttpListener)의 설정을 편집하거나 새 수신기를 만들 수 있습니다.

수신기 유형

수신기는 수신 연결 요청을 확인하는 논리적 엔터티입니다. 요청과 연결되어 있는 프로토콜, 포트, 호스트 이름, IP 주소가 수신기 구성과 연결되어 있는 동일 요소와 일치하면 수신기가 요청을 수락합니다.

애플리케이션 게이트웨이를 사용하기 전에 하나 이상의 수신기를 추가해야 합니다. 애플리케이션 게이트웨이에 연결된 수신기가 여러 개일 수 있으며 해당 수신기를 동일한 프로토콜에 사용할 수 있습니다.

수신기가 클라이언트의 수신 요청을 검색하면 애플리케이션 게이트웨이는 해당 요청을 규칙에 구성된 백 엔드 풀의 멤버로 라우팅합니다.

수신기는 다음 포트 및 프로토콜을 지원합니다.

Ports

포트는 수신기가 클라이언트 요청을 수신 대기하는 위치입니다. 아래와 같이 v1 및 v2 SKU에 대한 포트를 구성할 수 있습니다.

SKU	지원되는 포트 범위	예외
V2	1~64999	22
V1	1~65502	3389

프로토콜

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

참고 항목

Application Gateway 수신기에 연결하는 클라이언트의 경우에만 HTTP/2 프로토콜이 지원됩니다. 백 엔드 서버 풀에 대한 통신은 항상 HTTP/1.1을 통해 이루어집니다. 기본적으로 HTTP/2 지원은 사용할 수 없습니다. 이 지원을 사용하도록 설정할 수 있습니다.

• 수신기 구성에서는 HTTP 및 HTTPS 프로토콜 중에서 지정합니다.
• WebSocket 및 HTTP/2 프로토콜에 대한 지원이 기본적으로 제공되며 WebSocket 지원은 기본적으로 사용하도록 설정되어 있습니다. WebSocket 지원을 선택적으로 사용하거나 사용하지 않도록 설정하는 사용자 구성 가능 설정은 없습니다. HTTP 및 HTTPS 수신기 모두에서 Websocket을 사용합니다.

TLS 종료에는 HTTPS 수신기를 사용합니다. HTTPS 수신기는 암호화 및 암호 해독 작업을 애플리케이션 게이트웨이로 오프로드하므로 웹 서버에 오버헤드로 인한 부담이 없습니다.

라우팅 규칙 요청

Azure Portal을 사용하여 애플리케이션 게이트웨이를 만드는 경우 기본 규칙(rule1)을 만듭니다. 이 규칙은 기본 수신기(appGatewayHttpListener)를 기본 백 엔드 풀(appGatewayBackendPool) 및 기본 백 엔드 HTTP 설정(appGatewayBackendHttpSettings)에 바인딩합니다. 게이트웨이를 만든 후에는 기본 규칙의 설정을 편집하거나 새 규칙을 만들 수 있습니다.

규칙 유형

규칙을 만들 때 ‘기본’과 ‘경로 기반’ 중에서 선택합니다.

• 연결된 수신기(예: blog.contoso.com/*)의 모든 요청을 단일 백 엔드 풀로 전달하려면 기본을 선택합니다.
  
• 특정 URL 경로에서 특정 백 엔드 풀로 요청을 회람하려면 경로 기반을 선택합니다. 경로 패턴은 해당 쿼리 매개 변수가 아닌 URL 경로에만 적용됩니다.

연결된 수신기

수신기와 연결된 요청 회람 규칙을 평가하여 요청을 회람할 백 엔드 풀을 결정하도록 수신기를 규칙에 연결합니다.

연결된 백 엔드 풀

수신기가 받는 요청을 제공하는 백 엔드 대상이 포함된 백 엔드 풀을 규칙에 연결합니다.

• 기본 규칙의 경우 하나의 백 엔드 풀만 허용됩니다. 연결된 수신기의 모든 요청은 해당 백 엔드 풀에 전달됩니다.
  
• 경로 기반 규칙의 경우 각 URL 경로에 해당하는 여러 백 엔드 풀을 추가합니다. 입력된 URL 경로와 일치하는 요청은 해당 백 엔드 풀에 전달됩니다. 기본 백 엔드 풀도 추가합니다. 규칙의 URL 경로와 일치하지 않는 요청은 해당 풀에 전달됩니다.
  

연결된 백 엔드 HTTP 설정

각 규칙에 대한 백 엔드 HTTP 설정을 추가합니다. 요청은 이 설정에 지정된 포트 번호, 프로토콜, 기타 정보를 사용하여 애플리케이션 게이트웨이에서 백 엔드 대상으로 회람됩니다.

기본 규칙의 경우 하나의 백 엔드 HTTP 설정만 허용됩니다. 연결된 수신기의 모든 요청은 이 HTTP 설정을 사용하여 해당 백 엔드 대상에 전달됩니다.

경로 기반 규칙의 경우 각 URL 경로에 해당하는 여러 백 엔드 HTTP 설정을 추가합니다. 이 설정의 URL 경로와 일치하는 요청은 각 URL 경로에 해당하는 HTTP 설정을 사용하여 해당 백 엔드 대상에 전달됩니다. 기본 HTTP 설정도 추가합니다. 이 규칙의 URL 경로와 일치하지 않는 요청은 기본 HTTP 설정을 사용하여 기본 백 엔드 풀에 전달됩니다.

리디렉션 설정

기본 규칙에 대해 리디렉션을 구성하면 연결된 수신기의 모든 요청이 대상으로 리디렉션됩니다. 이 경우 ‘전역’ 리디렉션입니다. 경로 기반 규칙에 대해 리디렉션을 구성하면 특정 사이트 영역의 요청만 리디렉션됩니다. 예를 들어 /cart/*로 표시되는 쇼핑 카트 영역이 있습니다. 이 경우 ‘경로 기반’ 리디렉션입니다.

수신기

한 수신기에서 다른 수신기로 트래픽을 리디렉션하려면 수신기를 리디렉션 대상으로 선택합니다. 이 설정은 HTTP 및 HTTPS 간 리디렉션을 사용하도록 설정하려는 경우에 필요합니다. 들어오는 HTTP 요청을 확인하는 원본 수신기에서 들어오는 HTTPS 요청을 확인하는 대상 수신기로 트래픽을 리디렉션합니다. 리디렉션 대상에 전달되는 요청에 원래 요청의 쿼리 문자열과 경로를 포함하도록 선택할 수도 있습니다.

외부 사이트

이 규칙과 연결된 수신기의 트래픽을 외부 사이트로 리디렉션하려는 경우 외부 사이트를 선택합니다. 리디렉션 대상에 전달되는 요청에 원래 요청의 쿼리 문자열을 포함하도록 선택할 수 있습니다. 원래 요청에 있던 외부 사이트 경로는 전달할 수 없습니다.

HTTP 헤더 및 URL 다시 쓰기

다시 쓰기 규칙을 사용하면 요청 및 응답 패킷이 애플리케이션 게이트웨이를 통해 클라이언트와 백 엔드 풀 간에 이동할 때 URL 경로 및 쿼리 문자열 매개 변수뿐만 아니라 HTTP 요청 및 응답 헤더도 추가하거나, 제거하거나, 업데이트할 수 있습니다.

헤더 및 URL 매개 변수는 정적 값이나 다른 헤더와 서버 변수로 설정할 수 있습니다. 이 기능은 클라이언트 IP 주소 추출, 백 엔드에 대한 중요한 정보 제거, 보안 추가 등의 중요한 사용 사례에 도움이 됩니다.

HTTP 설정

애플리케이션 게이트웨이는 여기에서 지정한 구성을 사용하여 트래픽을 백 엔드 서버로 라우팅합니다. HTTP 설정을 만든 후에는 하나 이상의 요청 라우팅 규칙과 연결해야 합니다.

쿠키 기반 선호도

Azure Application Gateway는 사용자 세션을 유지 관리하기 위해 게이트웨이 관리 쿠키를 사용합니다. 사용자가 Application Gateway에 첫 번째 요청을 보내면 세션 정보를 포함하는 해시 값으로 응답의 선호도 쿠키가 설정되므로 해당 선호도 쿠키를 포함하는 후속 요청은 연결 유지 관리를 위해 동일한 백 엔드 서버로 라우팅됩니다.

이 기능은 동일한 서버에 사용자 세션을 유지하려는 경우와 사용자 세션의 세션 상태가 서버에 로컬로 저장되는 경우에 유용합니다. 애플리케이션에서 쿠키 기반 선호도를 처리할 수 없는 경우에는 이 기능을 사용할 수 없습니다. 기능을 사용하려면 클라이언트에서 쿠키를 지원하는지 확인합니다.

참고 항목

일부 취약성 검색에서는 Secure 또는 HttpOnly 플래그가 설정되지 않아 Application Gateway 선호도 쿠키가 플래그 지정될 수 있습니다. 이러한 검색은 쿠키의 데이터가 단방향 해시를 사용하여 생성된다는 점을 고려하지 않습니다. 쿠키에는 사용자 정보가 포함되어 있지 않으며 라우팅에만 사용됩니다.

연결 드레이닝

연결 드레이닝은 예정된 서비스 업데이트 중에 백 엔드 풀 멤버를 정상적으로 제거하는 데 도움이 됩니다. 백 엔드 풀에서 명시적으로 제거되거나

• 스케일 인 작업 중에 제거되거나
  
• 상태 프로브에서 비정상으로 보고된
• 백 엔드 인스턴스에 적용됩니다.

백 엔드 설정에서 연결 드레이닝을 사용하도록 설정하여 모든 백 엔드 풀 멤버에 이 설정을 적용할 수 있습니다. 구성된 제한 시간 값까지 기존 연결을 유지하면서 백 엔드 풀의 모든 등록 취소 인스턴스가 새 요청/연결을 수신하지 않도록 합니다. 이는 WebSocket 연결에서도 마찬가지입니다.

구성 형식	값
백 엔드 설정에서 연결 드레이닝이 사용하도록 설정되지 않은 경우 기본값	30초
백 엔드 설정에서 연결 드레이닝이 사용하도록 설정된 경우 사용자 정의 값	1~3600초

단, 게이트웨이 관리형 세션 선호도로 인해 등록 취소 인스턴스에 바인딩된 요청은 예외이며 계속해서 등록 취소 인스턴스에 전달됩니다.

프로토콜

Application Gateway는 요청을 백 엔드 서버로 라우팅할 때 HTTP와 HTTPS를 모두 지원합니다. HTTP를 선택하면 백 엔드 서버에 대한 트래픽이 암호화되지 않습니다. 암호화되지 않은 통신이 허용되지 않는 경우 HTTPS를 선택합니다.

이 설정은 수신기의 HTTPS와 결합되어 엔드투엔드 TLS를 지원합니다. 이렇게 하면 암호화된 중요한 데이터를 백 엔드에 안전하게 전송할 수 있습니다. 엔드투엔드 TLS를 사용할 수 있는 백 엔드 풀의 각 백 엔드 서버가 보안 통신을 허용하는 인증서로 구성되어야 합니다.

포트

이 설정은 백 엔드 서버가 애플리케이션 게이트웨이의 트래픽을 수신 대기하는 포트를 지정합니다. 1에서 65535 사이의 포트를 구성할 수 있습니다.

신뢰할 수 있는 루트 인증서

HTTPS를 백 엔드 프로토콜로 선택하는 경우 Application Gateway에는 엔드투엔드 SSL에 대한 백 엔드 풀을 신뢰하기 위해 신뢰할 수 있는 루트 인증서가 필요합니다. 기본적으로 잘 알려진 CA 인증서 사용 옵션은 아니요로 설정되어 있습니다. 자체 서명된 인증서 또는 내부 인증 기관에서 서명한 인증서를 사용하려는 경우 백 엔드 풀에서 사용할 일치하는 공용 인증서를 Application Gateway에 제공해야 합니다. 이 인증서는 .CER 형식으로 Application Gateway에 직접 업로드해야 합니다.

신뢰할 수 있는 공용 인증 기관에서 서명한 백 엔드 풀의 인증서를 사용하려는 경우 잘 알려진 CA 인증서 사용 옵션을 예로 설정하고 공용 인증서 업로드를 건너뛸 수 있습니다.

요청 시간 초과

이 설정은 애플리케이션 게이트웨이가 백 엔드 서버에서 응답을 받기 위해 대기하는 시간(초)입니다.

백 엔드 경로 재정의

이 설정을 사용하면 요청이 백 엔드로 전달될 때 사용할 선택적 사용자 지정 전달 경로를 구성할 수 있습니다. 백 엔드 경로 재정의 필드의 사용자 지정 경로와 일치하는 들어오는 경로 부분이 전달된 경로에 복사됩니다. 다음 표는 이 기능의 작동 방식을 보여 줍니다.

HTTP 설정이 기본 요청 라우팅 규칙에 연결된 경우

원래 요청	백 엔드 경로 재정의	요청이 백 엔드로 전달됨
/home/	/override/	/override/home/
/home/secondhome/	/override/	/override/home/secondhome/

HTTP 설정이 경로 기반 요청 라우팅 규칙에 연결된 경우

원래 요청	경로 규칙	백 엔드 경로 재정의	요청이 백 엔드로 전달됨
/pathrule/home/	/pathrule*	/override/	/override/home/
/pathrule/home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
/home/	/pathrule*	/override/	/override/home/
/home/secondhome/	/pathrule*	/override/	/override/home/secondhome/
/pathrule/home/	/pathrule/home*	/override/	/override/
/pathrule/home/secondhome/	/pathrule/home*	/override/	/override/secondhome/
/pathrule/	/pathrule/	/override/	/override/

사용자 지정 프로브 사용

이 설정은 HTTP 설정과 사용자 지정 프로브를 연결합니다. 사용자 지정 프로브 1개만 HTTP 설정과 연결할 수 있습니다. 사용자 지정 프로브를 명시적으로 연결하지 않으면 기본 프로브가 백 엔드의 상태를 모니터링하는 데 사용됩니다. 백 엔드의 상태 모니터링을 보다 효율적으로 제어하려면 사용자 지정 프로브를 만드는 것이 좋습니다.

참고 항목

해당 HTTP 설정이 수신기와 명시적으로 연결되지 않은 경우 사용자 지정 프로브는 백 엔드 풀의 상태를 모니터링하지 않습니다.

호스트 이름 구성

Application Gateway는 클라이언트가 Application Gateway에 연결하는 데 사용하는 것과 다른 호스트 이름을 사용하도록 백 엔드에 설정된 연결을 허용합니다. 이 구성은 경우에 따라 유용할 수 있지만 클라이언트와 애플리케이션 게이트웨이 및 백 엔드 대상에 대한 애플리케이션 게이트웨이 간에 서로 다른 호스트 이름을 재정의하는 것은 주의해서 수행해야 합니다.

프로덕션에서는 애플리케이션 게이트웨이가 백 엔드 대상에 사용하는 것과 동일한 호스트 이름으로 클라이언트가 애플리케이션 게이트웨이를 향해 사용하는 호스트 이름을 유지하는 것이 좋습니다. 이렇게 하면 절대 URL, 리디렉션 URL 및 호스트 바인딩 쿠키와 관련된 잠재적인 문제를 피할 수 있습니다.

이를 벗어나는 Application Gateway를 설정하기 전에 Architecture Center에서 자세히 설명하는 구성의 의미를 검토하세요. 역방향 프록시와 해당 백 엔드 웹 애플리케이션 간에 원래 HTTP 호스트 이름을 유지합니다.

백 엔드에 연결하기 위해 Application Gateway에서 사용하는 호스트 HTTP 헤더에 영향을 미치는 HTTP 설정에는 두 가지 측면이 있습니다.

• 백 엔드 주소에서 호스트 이름 선택
  
• 호스트 이름 재정의

백 엔드 주소에서 호스트 이름 선택

이 기능은 동적으로 요청의 호스트 헤더를 백 엔드 풀의 호스트 이름으로 설정합니다. IP 주소 또는 FQDN이 사용됩니다.

이 기능은 백 엔드의 도메인 이름이 애플리케이션 게이트웨이의 DNS 이름과 다르고 백 엔드가 특정 호스트 헤더를 사용하여 올바른 엔드포인트를 확인하는 경우에 도움이 됩니다.

예를 들어 다중 테넌트 서비스를 백 엔드로 사용합니다. 앱 서비스는 단일 IP 주소가 있는 공유 공간을 사용하는 다중 테넌트 서비스입니다. 따라서 사용자 지정 도메인 설정에서 구성된 호스트 이름을 통해서만 App Service에 액세스할 수 있습니다.

기본적으로 사용자 지정 도메인 이름은 example.azurewebsites.net입니다. App Service에 명시적으로 등록되지 않은 호스트 이름 또는 애플리케이션 게이트웨이의 FQDN을 통해 애플리케이션 게이트웨이를 사용하여 App Service에 액세스하려면 원래 요청의 호스트 이름을 App Service의 호스트 이름을 재정의할 수 있습니다. 이렇게 하려면 백 엔드 주소에서 호스트 이름 선택 설정을 사용하도록 설정합니다.

기존 사용자 지정 DNS 이름이 App Service에 매핑된 사용자 지정 도메인의 경우 권장되는 구성은 백 엔드 주소에서 호스트 이름 선택을 사용하도록 설정하지 않는 것이 좋습니다.

호스트 이름 재정의

이 기능은 애플리케이션 게이트웨이에 들어오는 요청의 ‘호스트’ 헤더를 지정한 호스트 이름으로 바꿉니다.

예를 들어, 호스트 이름 설정에 www.contoso.com이 지정된 경우 요청이 백 엔드 서버로 전달될 때 원래 요청 *https://appgw.eastus.cloudapp.azure.com/path1이 *https://www.contoso.com/path1로 변경됩니다.

백 엔드 풀

백 엔드 풀에서 특정 가상 머신, 가상 머신 확장 집합, IP 주소/FQDN 또는 앱 서비스라는 네 가지 유형의 백 엔드 멤버를 가리킬 수 있습니다.

백 엔드 풀을 만든 후에는 하나 이상의 요청 회람 규칙과 연결해야 합니다. 또한 애플리케이션 게이트웨이의 각 백 엔드 풀에 대해 상태 프로브를 구성해야 합니다. 요청 회람 규칙 조건이 충족되면 애플리케이션 게이트웨이는 해당 백 엔드 풀의 정상 서버(상태 프로브를 통해 확인됨)에 트래픽을 전달합니다.

상태 프로브

Azure Application Gateway는 백 엔드 풀에 있는 모든 서버의 상태를 모니터링하고 비정상으로 간주되는 모든 서버에 대한 트래픽 전송을 자동으로 중지합니다. 프로브는 이러한 비정상 서버를 계속 모니터링하고, 게이트웨이는 프로브가 해당 서버를 정상으로 감지하는 즉시 트래픽을 다시 한 번 라우팅하기 시작합니다.

기본 프로브는 연결된 백 엔드 설정 및 기타 미리 설정된 구성의 포트 번호를 사용합니다. 사용자 지정 프로브를 사용하여 원하는 방식으로 구성할 수 있습니다.

프로브 동작

원본 IP 주소

프로브의 원본 IP 주소는 백 엔드 서버 유형에 따라 달라집니다.

• 백 엔드 풀의 서버가 퍼블릭 엔드포인트인 경우 원본 주소는 애플리케이션 게이트웨이의 프런트 엔드 공용 IP 주소가 됩니다.
  
• 백 엔드 풀의 서버가 프라이빗 엔드포인트인 경우 원본 IP 주소는 애플리케이션 게이트웨이 서브넷의 주소 공간에서 가져옵니다.

프로브 작업

게이트웨이는 규칙을 백 엔드 설정 및 백 엔드 풀(및 리스너)과 연결하여 규칙을 구성한 직후 프로브 실행을 시작합니다. 이 그림에서는 게이트웨이가 모든 백 엔드 풀 서버를 독립적으로 프로브하는 것을 보여 줍니다. 도착하기 시작하는 들어오는 요청은 정상 서버로만 전송됩니다. 백 엔드 서버는 프로브 응답이 성공적으로 수신될 때까지 기본적으로 비정상으로 표시됩니다.

필요한 프로브는 백 엔드 서버와 백 엔드 설정의 고유한 조합에 따라 결정됩니다. 예를 들어 서버 2개와 백 엔드 설정 2개가 각각 다른 포트 번호를 갖는 단일 백 엔드 풀이 있는 게이트웨이를 고려해 보세요. 이러한 고유한 백 엔드 설정이 해당 규칙을 사용하여 동일한 백 엔드 풀과 연결된 경우 게이트웨이는 각 서버에 대한 프로브와 백 엔드 설정의 조합을 만듭니다. 백 엔드 상태 페이지를 볼 수 있습니다.

또한 애플리케이션 게이트웨이의 모든 인스턴스는 서로 독립적으로 백 엔드 서버를 프로브합니다.

참고 항목

백 엔드 상태 보고서는 각 프로브의 새로 고침 간격에 따라 업데이트되며 사용자의 요청에 따라 달라지지 않습니다.

기본 상태 프로브

애플리케이션 게이트웨이는 사용자 지정 프로브 구성을 설정하지 않는 경우 기본 상태 프로브를 자동으로 구성합니다. 모니터링 동작은 백 엔드 풀에서 구성된 IP 주소 또는 FQDN에 대해 HTTP GET 요청을 수행하는 방식으로 작동합니다. 기본 프로브의 경우 백 엔드 HTTP 설정이 HTTPS로 구성되어 있으면 프로브는 HTTPS를 사용하여 백 엔드 서버의 상태를 테스트합니다.

예: 포트 80에서 HTTP 네트워크 트래픽을 수신할 백 엔드 서버 A, B, C를 사용하도록 애플리케이션 게이트웨이를 구성합니다. 기본 상태 모니터링은 30초마다 서버 3대를 테스트하여 각 요청에 30초 시간 제한으로 정상 HTTP 응답을 확인합니다. 정상 HTTP 응답은 상태 코드 200에서 399 사이입니다. 예제에서 상태 프로브에 대한 HTTP GET 요청은 http://127.0.0.1/과 같이 표시됩니다. Application Gateway의 HTTP 응답 코드도 참조하세요.

서버 A에 대한 기본 프로브 검사가 실패하면 애플리케이션 게이트웨이는 이 서버에 더 이상 요청을 전달하지 않습니다. 기본 프로브는 서버 A에 대해 30초마다 계속 확인합니다. 서버 A가 기본 상태 프로브의 요청에 성공적으로 응답하면 애플리케이션 게이트웨이가 다시 서버에 요청을 전달하기 시작합니다.

기본 상태 프로브 설정

프로브 속성	값	설명
프로브 URL	<protocol>://127.0.0.1:<port>/	프로토콜과 포트는 프로브가 연결된 백 엔드 HTTP 설정에서 상속됩니다.
간격	30	다음 상태 프로브가 전송되기 전에 대기할 시간의 양(초)입니다.
시간 제한	30	프로브를 비정상으로 표시하기 전에 애플리케이션 게이트웨이에서 프로브 응답에 대해 대기할 시간의 양(초)입니다. 프로브가 정상으로 반환하는 경우 해당 백 엔드는 즉시 정상으로 표시됩니다.
비정상 임계값	3	일반 상태 프로브에 오류가 발생하는 경우 보내는 프로브의 수를 제어합니다. v1 SKU에서는 추가 상태 프로브가 연속해서 빠르게 전송되어 백 엔드의 상태를 빠르게 확인하고 프로브 간격 동안 기다리지 않습니다. v2 SKU의 경우 상태 프로브에서 간격을 기다립니다. 연속된 프로브 실패 횟수가 비정상 임계값에 도달하면 백 엔드 서버가 다운된 것으로 표시됩니다.

기본 프로브는 <protocol>://127.0.0.1:<port>만 조사하여 상태를 확인합니다. 사용자 지정 URL로 이동하거나 다른 모든 설정을 수정하도록 상태 프로브를 구성하려면 사용자 지정 프로브를 사용해야 합니다.

사용자 지정 상태 프로브

사용자 지정 프로브를 통해 상태 모니터링을 보다 세부적으로 제어할 수 있습니다. 사용자 지정 프로브를 사용하는 경우 사용자 지정 호스트 이름, URL 경로, 프로브 간격, 백 엔드 풀 인스턴스를 비정상으로 표시하기 전에 허용할 실패 응답 횟수를 구성할 수 있습니다.

사용자 지정 상태 프로브 설정

다음 표에는 사용자 지정 상태 프로브의 속성을 위한 정의가 나와 있습니다.

프로브 속성	설명
속성	프로브 이름입니다. 이 이름은 백 엔드 HTTP 설정에서 프로브를 식별하고 참조하는 데 사용됩니다.
프로토콜	프로브를 보내는 데 사용하는 프로토콜입니다. 연결된 백 엔드 HTTP 설정에서 정의된 프로토콜과 일치해야 합니다.
호스트	프로브를 보내는 데 사용할 호스트 이름입니다. v1 SKU에서 이 값은 프로브 요청의 호스트 헤더에만 사용됩니다. v2 SKU에서는 호스트 헤더와 SNI로 모두 사용됩니다.
경로	프로브의 상대 경로입니다. 올바른 경로는 '/'부터 시작합니다.
포트	정의된 경우 이 포트가 대상 포트로 사용됩니다. 그렇지 않으면 연결된 HTTP 설정과 동일한 포트가 사용됩니다. 이 속성은 v2 SKU에서만 사용할 수만 있습니다.
간격	프로브 간격(초). 이 값은 연속된 두 프로브 사이의 시간 간격입니다.
시간 제한	프로브 시간 제한(초) 이 시간 제한 기간 내에 유효한 응답을 받지 못하면 프로브가 실패로 표시됩니다.
비정상 임계값	프로브 재시도 횟수. 연속된 프로브 실패 횟수가 비정상 임계값에 도달하면 백 엔드 서버가 다운된 것으로 표시됩니다.

프로브 일치

기본적으로 상태 코드가 200-399인 HTTP(S) 응답은 정상으로 간주됩니다. 사용자 지정 상태 프로브는 또한 일치하는 두 조건을 지원합니다. 일치하는 조건을 사용하여 정상 응답을 만드는 항목에 대한 기본 해석을 필요에 따라 수정할 수 있습니다.

다음이 일치하는 조건입니다.

• HTTP 응답 상태 코드 일치 - 사용자 지정 http 응답 코드 또는 응답 코드 범위를 수용하기 위한 프로브 일치 조건입니다. 응답 상태 코드 또는 상태 코드 범위를 구분하는 개별 쉼표가 지원됩니다.
  
• HTTP 응답 본문 일치 - HTTP 응답 본문을 살펴보고 사용자 지정 문자열과 일치하는 프로브 일치 조건입니다. 일치는 응답 본문에서 사용자 지정 문자열의 존재만 찾으며 전체 정규식과 일치하지는 않습니다. 지정된 일치 항목은 4090자 이하여야 합니다.

New-AzApplicationGatewayProbeHealthResponseMatch cmdlet을 사용하여 일치 조건을 지정할 수 있습니다.

예:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

PowerShell에서 -Match 연산자를 사용하여 일치 기준을 프로브 구성에 연결할 수 있습니다.

사용자 지정 프로브 사용 사례

• 백 엔드 서버가 인증된 사용자에게만 액세스를 허용하는 경우 애플리케이션 게이트웨이 프로브는 200 대신 403 응답 코드를 수신합니다. 클라이언트(사용자)는 라이브 트래픽에 대해 자신을 인증하도록 바인딩되므로 예상 응답으로 403을 허용하도록 프로브 트래픽을 구성할 수 있습니다.
• 백 엔드 서버에 다른 하위 도메인을 제공하기 위해 와일드카드 인증서(*.contoso.com)가 설치된 경우 성공적인 TLS 프로브를 설정하고 해당 서버를 정상으로 보고하는 데 허용되는 특정 호스트 이름(SNI에 필요)이 있는 사용자 지정 프로브를 사용할 수 있습니다. 백 엔드 설정에서 "호스트 이름 재정의"를 NO로 설정하면 다른 수신 호스트 이름(하위 도메인)이 그대로 백 엔드에 전달됩니다.

NSG(네트워크 보안 그룹) 고려 사항

공개 미리 보기에서는 NSG 규칙을 통해 Application Gateway 서브넷을 세밀하게 제어할 수 있습니다. 자세한 내용은 여기에서 찾을 수 있습니다.

현재 기능에는 몇 가지 제한 사항이 있습니다.

들어오는 인터넷 트래픽을 Application Gateway v1 SKU의 경우 65503-65534 TCP 포트에서 허용하고, 대상 서브넷이 Any이고 원본이 GatewayManager 서비스 태그인 v2 SKU의 경우 65200-65535 TCP 포트에서 허용해야 합니다. 이 포트 범위는 Azure 인프라 통신에 필요합니다.

또한 아웃바운드 인터넷 연결은 차단될 수 없으며, AzureLoadBalancer 태그에서 오는 인바운드 트래픽은 허용되어야 합니다.

애플리케이션 게이트웨이 작동 원리

애플리케이션 게이트웨이에서 요청을 수락하는 방법

1. 클라이언트는 애플리케이션 게이트웨이에 요청을 보내기 전에 DNS(Domain Name System) 서버를 사용하여 애플리케이션 게이트웨이의 도메인 이름을 확인합니다. 모든 애플리케이션 게이트웨이가 azure.com 도메인에 있기 때문에 Azure는 DNS 항목을 제어합니다.
2. Azure DNS은 클라이언트에 대한 IP 주소를 반환합니다. 이 주소는 애플리케이션 게이트웨이의 프런트 엔드 IP 주소입니다.
   
3. 애플리케이션 게이트웨이는 하나 이상의 수신기에서 들어오는 트래픽을 수락합니다. 수신기는 연결 요청을 확인하는 논리적 엔터티입니다. 이는 클라이언트에서 애플리케이션 게이트웨이로의 연결을 위한 프런트 엔드 IP 주소, 프로토콜 및 포트 번호를 사용하여 구성됩니다.
   
4. WAF(Web Application Firewall)를 사용 중인 경우 애플리케이션 게이트웨이는 요청 헤더와 본문(있는 경우)을 WAF 규칙에 대해 확인합니다. 이 작업은 요청이 유효한 요청인지 아니면 보안 위협인지를 결정합니다. 요청이 올바르면 백 엔드로 라우팅됩니다. 요청이 유효하지 않고 WAF가 방지 모드이면 보안 위협으로 차단됩니다. 검색 모드에 있는 경우 요청은 평가되고 기록되지만 여전히 백 엔드 서버로 전달됩니다.
   

Azure Application Gateway를 내부 애플리케이션 부하 분산 장치 또는 인터넷 연결 애플리케이션 부하 분산 장치로 사용할 수 있습니다. 인터넷 연결 애플리케이션 게이트웨이는 공용 IP 주소를 사용합니다. 인터넷 연결 애플리케이션 게이트웨이의 DNS 이름은 공용 IP 주소를 통해 공개적으로 확인할 수 있습니다. 결과적으로 인터넷 연결 애플리케이션 게이트웨이는 인터넷에서 클라이언트 요청을 라우팅할 수 있습니다.

내부 애플리케이션 게이트웨이는 개인 IP 주소만 사용합니다. 사용자 지정 또는 프라이빗 DNS 영역을 사용하는 경우 Application Gateway의 개인 IP 주소에서 도메인 이름을 내부적으로 확인할 수 있어야 합니다. 따라서 내부 부하 분산 장치는 애플리케이션 게이트웨이의 가상 네트워크에 대한 액세스 권한이 있는 클라이언트의 요청만 라우팅할 수 있습니다.

애플리케이션 게이트웨이에서 요청을 라우팅하는 방법

요청이 유효하고 WAF에 의해 차단되지 않았다면 애플리케이션 게이트웨이는 수신기와 연결된 요청 라우팅 규칙을 평가합니다. 이 작업은 요청을 라우팅할 백 엔드 풀을 확인합니다.

요청 라우팅 규칙에 따라 애플리케이션 게이트웨이는 수신기의 모든 요청을 특정 백 엔드 풀로 라우팅할지, URL 경로에 따라 요청을 다른 백 엔드 풀로 라우팅할지, 요청을 다른 포트나 외부 사이트로 리디렉션할지 여부를 결정합니다.

애플리케이션 게이트웨이는 백 엔드 풀을 선택할 때 풀 (y.y.y.y)의 정상 백 엔드 서버 중 하나로 요청을 보냅니다. 서버의 상태는 상태 프로브에 의해 결정됩니다. 백 엔드 풀에 여러 서버가 포함된 경우 애플리케이션 게이트웨이는 라운드 로빈 알고리즘을 사용하여 정상 서버 간에 요청을 라우팅합니다. 이렇게 하면 서버에서 요청 부하가 분산됩니다.

애플리케이션 게이트웨이는 백 엔드 서버를 확인한 후 HTTP 설정에 따라 백 엔드 서버를 사용하여 새 TCP 세션을 엽니다. HTTP 설정은 백 엔드 서버와의 새 세션을 설정하는 데 필요한 프로토콜, 포트 및 기타 라우팅 관련 설정을 지정합니다.

HTTP 설정에 사용되는 포트 및 프로토콜은 애플리케이션 게이트웨이와 백 엔드 서버 간의 트래픽이 암호화되는지(따라서 엔드투엔드 TLS 수행) 여부를 결정합니다.

참고 항목

규칙은 v1 SKU 포털에 나열된 순서대로 처리됩니다.

애플리케이션 게이트웨이는 원래 요청을 백 엔드 서버로 보낼 때 호스트 이름, 경로 및 프로토콜 재정의와 관련된 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 주소를 계속 사용합니다. 이렇게 하면 데이터 경로에 미치는 영향을 최소화할 수 있습니다.

• Application Gateway의 Virtual Network와 함께 사용자 지정 DNS 서버를 사용하는 경우 모든 서버가 동일해야 하고 같은 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:포트 목록입니다.

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 경로를 수정하도록 애플리케이션 게이트웨이를 구성할 수 있습니다. 그러나 그렇게 구성하지 않는 한 들어오는 모든 요청은 백 엔드로 프록시됩니다.

계속