Application Gateway 구성 요소
애플리케이션 게이트웨이는 클라이언트의 단일 연락 지점으로 사용됩니다. 수신 애플리케이션 트래픽을 Azure VM, 가상 머신 확장 집합, Azure App Service, 온-프레미스/외부 서버가 포함된 여러 백 엔드 풀에 분산합니다. 트래픽을 분산하기 위해 애플리케이션 게이트웨이는 이 문서에 설명된 여러 구성 요소를 사용합니다.
프런트 엔드 IP 주소
프런트 엔드 IP 주소는 애플리케이션 게이트웨이와 연결된 IP 주소입니다. 애플리케이션 게이트웨이에 공용 IP 주소, 개인 IP 주소 또는 둘 다를 포함하도록 구성할 수 있습니다. 애플리케이션 게이트웨이는 하나의 공용 IP 주소 또는 하나의 개인 IP 주소를 지원합니다. 가상 네트워크 및 공용 IP 주소는 애플리케이션 게이트웨이와 동일한 위치에 있어야 합니다. 만든 후에는 프런트 엔드 IP 주소가 수신기와 연결됩니다.
고정 및 동적 공용 IP 주소 비교
Azure Application Gateway V2 SKU는 고정 내부 IP 주소와 고정 공용 IP 주소를 지원하거나 고정 공용 IP 주소만 지원하도록 구성할 수 있습니다. 고정 내부 IP 주소만 지원하도록 구성할 수는 없습니다.
V1 SKU는 고정 또는 동적 내부 IP 주소 및 동적 공용 IP 주소를 지원하도록 구성할 수 있습니다. 실행 중인 게이트웨이에서는 Application Gateway의 동적 IP 주소가 변경되지 않습니다. 게이트웨이를 중지하거나 시작할 때만 변경할 수 있습니다. 시스템 오류, 업데이트, Azure 호스트 업데이트 등에서는 변경되지 않습니다.
애플리케이션 게이트웨이와 연결된 DNS 이름은 게이트웨이 수명 주기 동안 변경되지 않습니다. 따라서 CNAME 별칭을 사용하고 이 별칭이 애플리케이션 게이트웨이의 DNS 주소를 가리키도록 해야 합니다.
수신기
수신기는 수신 연결 요청을 확인하는 논리적 엔터티입니다. 요청과 연결되어 있는 프로토콜, 포트, 호스트 이름, 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 수신기는 암호화 및 암호 해독 작업을 애플리케이션 게이트웨이로 오프로드하므로 웹 서버에 오버헤드로 인한 부담이 없습니다.
사용자 지정 오류 페이지
Application Gateway를 사용하면 기본 오류 페이지를 표시하는 대신 사용자 지정 오류 페이지를 만들 수 있습니다. 사용자 지정 오류 페이지를 사용하여 사용자 고유의 브랜딩과 레이아웃을 사용할 수 있습니다. 요청이 백 엔드에 도달할 수 없는 경우 Application Gateway는 사용자 지정 오류 페이지를 표시합니다.
자세한 내용은 애플리케이션 게이트웨이 사용자 지정 오류 페이지를 참조하세요.
수신기 유형
수신기에는 다음 두 가지 유형이 있습니다.
기본. 이 유형의 수신기는 단일 도메인 사이트에 대해 수신 대기합니다. 이 단일 도메인 사이트에는 애플리케이션 게이트웨이의 IP 주소에 대한 단일 DNS 매핑이 있습니다. 애플리케이션 게이트웨이를 지원하는 단일 사이트를 호스트하는 경우 이 수신기 구성이 필요합니다.
다중 사이트. 동일한 애플리케이션 게이트웨이에서 웹 애플리케이션 두 개 이상의 호스트 이름 또는 도메인 이름을 기반으로 라우팅을 구성하려는 경우 이 수신기 구성이 필요합니다. 이 기능을 사용하면 최대 100개의 웹 사이트를 하나의 애플리케이션 게이트웨이에 추가하여 배포에 대해 보다 효율적인 토폴로지를 구성할 수 있습니다. 각 웹 사이트는 고유한 백 엔드 풀로 이동할 수 있습니다. 예를 들어 contoso.com, fabrikam.com 및 adatum.com이라는 세 개의 도메인이 애플리케이션 게이트웨이의 IP 주소를 가리킵니다. 세 개의 다중 사이트 수신기를 만들고 각 포트 및 프로토콜 설정에 대해 각각의 수신기를 구성합니다.
또한 다중 사이트 수신기에서 와일드카드 호스트 이름을 정의하고 수신기당 최대 5개의 호스트 이름을 정의할 수 있습니다. 자세한 내용은 수신기의 와일드카드 호스트 이름을 참조하세요.
다중 사이트 수신기를 구성하는 방법에 대한 자세한 내용은 Azure Portal을 사용하여 Application Gateway에서 다중 사이트 호스트를 참조하세요.
수신기를 만든 후에는 요청 라우팅 규칙과 연결합니다. 이 규칙에 따라 수신기에서 받은 요청을 백 엔드로 라우팅하는 방법이 결정됩니다. 요청 라우팅 규칙에는 라우팅할 백 엔드 풀과 백 엔드 포트, 프로토콜 등이 언급된 HTTP 설정도 포함되어야 합니다.
라우팅 규칙 요청
요청 라우팅 규칙은 수신기에서 트래픽을 라우팅하는 방법을 결정하므로 애플리케이션 게이트웨이의 주요 구성 요소입니다. 규칙은 수신기, 백 엔드 서버 풀, 백 엔드 HTTP 설정을 바인딩합니다.
수신기에서 요청을 수락하는 경우 요청 라우팅 규칙은 요청을 백 엔드로 전달하거나 다른 위치로 리디렉션합니다. 요청이 백 엔드로 전달되는 경우 요청 라우팅 규칙은 전달할 백 엔드 서버 풀을 정의합니다. 요청 라우팅 규칙은 요청의 헤더를 다시 쓸지 여부도 결정합니다. 하나의 수신기를 하나의 규칙에 연결할 수 있습니다.
요청 라우팅 규칙에는 다음 두 가지 유형이 있습니다.
기본. 연결된 수신기의 모든 요청(예: blog.contoso.com/*)은 연결된 HTTP 설정을 사용하여 연결된 백 엔드 풀로 전달됩니다.
경로 기반. 이 라우팅 규칙을 사용하면 요청의 URL에 따라 연결된 수신기의 요청을 특정 백 엔드 풀로 라우팅할 수 있습니다. 요청의 URL 경로가 경로 기반 규칙의 경로 패턴과 일치하는 경우 규칙은 해당 요청을 라우팅합니다. 경로 패턴은 해당 쿼리 매개 변수가 아닌 URL 경로에만 적용됩니다. 수신기 요청의 URL 경로가 어떤 경로 기반 규칙과도 일치하지 않는 경우 기본 백 엔드 풀 및 HTTP 설정으로 요청을 라우팅합니다.
자세한 내용은 URL 기반 라우팅을 참조하세요.
리디렉션 지원
요청 라우팅 규칙을 사용하면 애플리케이션 게이트웨이에서 트래픽을 리디렉션할 수도 있습니다. 일반적인 리디렉션 메커니즘이므로 규칙을 사용하여 정의된 모든 포트에서 또는 모든 포트로 트래픽을 리디렉션할 수 있습니다.
리디렉션 대상을 다른 수신기(HTTP 및 HTTPS 사이의 자동 리디렉션을 사용하도록 설정하는 데 도움이 될 수 있음) 또는 외부 사이트가 되도록 선택할 수 있습니다. 또한, 리디렉션을 일시적으로 할 것인지 영구적으로 할 것인지 선택하거나 리디렉션된 URL에 URI 경로 및 쿼리 문자열을 추가하도록 선택할 수도 있습니다.
자세한 내용은 애플리케이션 게이트웨이에서 트래픽 리디렉션을 참조하세요.
HTTP 헤더 및 URL 다시 쓰기
다시 쓰기 규칙을 사용하면 요청 및 응답 패킷이 애플리케이션 게이트웨이를 통해 클라이언트와 백 엔드 풀 간에 이동할 때 URL 경로 및 쿼리 문자열 매개 변수뿐만 아니라 HTTP 요청 및 응답 헤더도 추가하거나, 제거하거나, 업데이트할 수 있습니다.
헤더 및 URL 매개 변수는 정적 값이나 다른 헤더와 서버 변수로 설정할 수 있습니다. 이 기능은 클라이언트 IP 주소 추출, 백 엔드에 대한 중요한 정보 제거, 보안 추가 등의 중요한 사용 사례에 도움이 됩니다.
자세한 내용은 애플리케이션 게이트웨이에서 HTTP 헤더 및 URL 다시 작성을 참조하세요.
HTTP 설정
애플리케이션 게이트웨이는 이 구성 요소에 자세히 설명된 포트 번호, 프로토콜, 기타 설정을 사용하여 백 엔드 서버(HTTP 설정을 포함하는 요청 라우팅 규칙에 지정됨)로 트래픽을 라우팅합니다.
HTTP 설정에 사용되는 포트 및 프로토콜에 따라 애플리케이션 게이트웨이와 백 엔드 서버 간 트래픽이 암호화되는지(엔드투엔드 TLS 제공) 암호화되지 않는지 결정됩니다.
이 구성 요소는 다음 작업에도 사용됩니다.
쿠키 기반 세션 선호도를 사용하여 사용자 세션을 동일한 서버에 유지할지 여부를 결정합니다.
연결 드레이닝을 사용하여 백 엔드 풀 멤버를 원활하게 제거합니다.
사용자 지정 프로브를 연결하여 백 엔드 상태를 모니터링하고, 요청 시간 제한 간격을 설정하고, 요청에서 호스트 이름 및 경로를 재정의하고, 한 번 클릭으로 손쉽게 App Service 백 엔드에 대한 설정을 지정할 수 있는 기능을 제공합니다.
백 엔드 풀
백 엔드 풀은 요청을 처리하는 백 엔드 서버로 요청을 라우팅합니다. 백 엔드 풀에는 다음이 포함될 수 있습니다.
- NIC
- 가상 머신 크기 집합
- 공용 IP 주소
- 내부 IP 주소
- FQDN
- 다중 테넌트 백 엔드(예: App Service)
애플리케이션 게이트웨이 백 엔드 풀 멤버는 가용성 집합에 연결되지 않습니다. 애플리케이션 게이트웨이는 연결된 가상 네트워크 외부의 인스턴스와 통신할 수 있습니다. 따라서 백 엔드 풀의 멤버는 IP 연결이 있는 한 여러 클러스터, 여러 데이터 센터 또는 Azure 외부에 있을 수 있습니다.
백 엔드 풀 멤버로 내부 IP를 사용하는 경우 가상 네트워크 피어링 또는 VPN Gateway를 사용해야 합니다. 가상 네트워크 피어링이 지원되며 다른 가상 네트워크에서 트래픽 부하 분산에 유용합니다.
애플리케이션 게이트웨이는 Azure ExpressRoute를 통해 연결된 경우 온-프레미스 서버, 트래픽이 허용된 경우 VPN 터널과 통신할 수도 있습니다.
다양한 유형의 요청에 대해 다양한 백 엔드 풀을 만들 수 있습니다. 예를 들어 일반적인 요청에 대해 하나의 백 엔드 풀을 만든 다음, 애플리케이션의 마이크로 서비스 요청에 대해 또 다른 백 엔드 풀을 만듭니다.
가상 머신 확장 집합을 백 엔드 풀 멤버로 추가한 후에는 가상 머신 확장 집합 인스턴스를 업그레이드해야 합니다. 확장 집합 인스턴스를 업그레이드할 때까지 백 엔드는 비정상 상태가 됩니다.
상태 프로브
기본적으로 애플리케이션 게이트웨이는 해당 백 엔드 풀의 모든 리소스 상태를 모니터링하여 비정상 리소스를 자동으로 제거합니다. 그런 다음, 비정상 인스턴스를 모니터링하여 사용할 수 있게 되고 상태 프로브에 응답하면 정상 백 엔드 풀에 다시 추가합니다.
기본 상태 프로브 모니터링 사용 외에도 애플리케이션 프로그의 요구 사항에 맞게 상태 프로브를 사용자 지정할 수도 있습니다. 사용자 지정 프로브를 사용하면 상태 모니터링을 보다 세부적으로 제어할 수 있습니다. 사용자 지정 프로브를 사용하는 경우 백 엔드 풀 인스턴스를 비정상, 사용자 지정 상태 코드, 응답 본문 일치 등으로 표시하기 전에 사용자 지정 호스트 이름, URL 경로, 프로브 간격, 허용할 실패 응답 횟수를 구성할 수 있습니다. 각 백 엔드 풀의 상태를 모니터링하도록 사용자 지정 프로브를 구성하는 것이 좋습니다.
자세한 내용은 애플리케이션 게이트웨이 상태 모니터링을 참조하세요.
다음 단계
애플리케이션 게이트웨이를 만듭니다.