Azure Application Gateway 작동 방식

  • 5분

Azure 애플리케이션 Gateway에는 웹 서버 풀에서 요청을 안전하게 라우팅하고 부하를 분산하기 위해 결합된 일련의 구성 요소가 있습니다. Application Gateway에는 다음과 같은 구성 요소가 있습니다.

Diagram that shows Azure Application Gateway components.

  • 프런트 엔드 IP 주소: 클라이언트 요청은 프런트 엔드 IP 주소를 통해 받습니다. 공용 IP 주소, 사설 IP 주소 또는 둘 모두를 사용하도록 Application Gateway를 구성할 수 있습니다. Application Gateway는 한 개의 공용 IP 주소와 한 개의 개인 IP주소보다 더 많이 가질 수 없습니다.
  • 수신기: Application Gateway는 하나 이상의 수신기를 사용하여 들어오는 요청을 받습니다. 수신기는 프로토콜, 포트, 호스트 및 IP 주소의 지정된 조합에 도착하는 트래픽을 허용합니다. 각 수신기는 지정한 라우팅 규칙에 따라 요청을 서버의 백 엔드 풀로 라우팅합니다. 수신기는 기본 또는 다중 사이트일 수 있습니다. 기본 수신기는 URL의 경로에 따라 요청을 라우팅합니다. 다중 사이트 수신기는 URL의 호스트 이름 요소를 사용하여 요청을 라우팅할 수도 있습니다. 또한 수신기는 사용자와 Application Gateway 간에 애플리케이션을 보호하기 위한 TLS/SSL 인증서를 처리합니다.
  • 회람 규칙: 회람 규칙은 수신기를 백 엔드 풀에 바인딩합니다. 규칙은 요청의 URL에서 호스트 이름 및 경로 요소를 해석하고 해당 요청을 적절한 백 엔드 풀로 보내는 방법을 지정합니다. 라우팅 규칙에는 연결된 HTTP 설정 세트도 있습니다. 이러한 HTTP 설정은 Application Gateway와 백 엔드 서버 간의 트래픽 암호화 여부를 나타냅니다. 다른 구성 정보에는 프로토콜, 세션 연결 유지, 연결 드레이닝, 요청 시간 초과 기간 및 상태 프로브가 포함됩니다.

Application Gateway의 부하 분산

Application Gateway는 라운드 로빈 메커니즘을 사용하여 각 백 엔드 풀의 서버로 전송된 요청의 부하를 자동으로 분산합니다. 부하 분산은 Application Gateway 라우팅에서 구현된 OSI 계층 7 라우팅을 통해 작동합니다. 즉 Application Gateway 규칙에 사용되는 라우팅 매개 변수(호스트 이름 및 경로)에 따라 요청의 부하를 분산시킵니다. 반면 Azure Load Balancer와 같은 다른 부하 분산 장치는 OSI 계층 4 수준에서 작동하고 요청 대상의 IP 주소에 따라 트래픽을 분산시킵니다.

동일한 세션에서 클라이언트에 대한 모든 요청을 백 엔드 풀의 동일한 서버로 라우팅해야 하는 경우 세션 연결 유지를 구성할 수 있습니다.

웹 애플리케이션 방화벽

WAF(웹 애플리케이션 방화벽)는 들어오는 요청이 수신기에 도달하기 전에 이를 처리하는 선택적 구성 요소입니다. 웹 애플리케이션 방화벽은 각 요청에 OWASP(Open Web Application Security Project)에서 발표한 다양한 일반적인 위협이 있는지 확인합니다. 일반적인 위협에는 SQL 삽입, 사이트 간 스크립팅, 명령 주입, HTTP 요청 밀수, HTTP 응답 분할, 원격 파일 포함, 봇, 크롤러 및 스캐너, HTTP 프로토콜 위반 및 변칙이 포함됩니다.

OWASP는 공격을 탐지하기 위한 일반 규칙 집합을 정의합니다. 이러한 규칙은 CRS(핵심 규칙 집합)로 참조됩니다. 공격이 정교하게 진화함에 따라 규칙 집합이 지속적으로 검토되고 있습니다. WAF는 CRS 3.2, 3.1, 3.0 및 2.2.9의 네 가지 규칙 집합을 지원합니다. CRS 3.1이 기본값입니다. 필요한 경우 규칙 집합에서 특정 위협을 대상으로 하는 특정 규칙만 선택하도록 할 수 있습니다. 또한 방화벽을 사용자 지정하여 요청에서 검사할 요소를 지정하고, 메시지 크기를 제한하여 대량 업로드로 인한 서버의 과도한 부하를 방지할 수 있습니다.

백 엔드 풀

백 엔드 풀은 가상 머신의 고정 집합, 가상 머신 확장 집합, Azure 앱 Services에서 호스트하는 앱 또는 온-프레미스 서버 컬렉션으로 구성할 수 있는 웹 서버의 컬렉션입니다.

각 백 엔드 풀에는 작업을 풀 전체에 분산시키는 연결된 부하 분산 장치가 있습니다. 풀을 구성할 때 각 웹 서버의 IP 주소 또는 이름을 제공합니다. 백 엔드 풀의 모든 서버에 보안 설정을 포함하여 동일한 방식으로 구성합니다.

TLS/SSL를 사용하는 중인 경우 백 엔드 풀에는 백 엔드 서버를 인증하는 데 사용되는 인증서를 참조하는 HTTP 설정이 있습니다. 게이트웨이는 이 인증서를 사용하여 트래픽을 다시 암호화한 후 백 엔드 풀의 서버 중 하나에 보냅니다.

Azure App Service를 사용하여 백 엔드 애플리케이션을 호스트하는 경우 Application Gateway에 인증서를 설치하지 않아도 백 엔드 풀에 연결할 수 있습니다. 모든 통신은 자동으로 암호화됩니다. Application Gateway는 Azure가 서버를 관리하기 때문에 서버를 신뢰합니다.

Application Gateway는 규칙을 사용하여 수신 포트에서 수신하는 메시지를 백 엔드 풀의 서버로 전달하는 방법을 지정합니다. 서버에서 TLS/SSL을 사용하는 경우 다음을 나타내는 규칙을 구성해야 합니다.

  • 서버에서 HTTPS 프로토콜을 통해 트래픽을 예상합니다.
  • 트래픽을 암호화하고 서버에 대한 연결을 인증하는 데 사용할 인증서.

Application Gateway 라우팅

게이트웨이가 클라이언트 요청을 백 엔드 풀의 웹 서버로 라우팅하는 경우 게이트웨이에 대해 구성된 규칙 집합을 사용하여 요청을 전달할 위치를 결정합니다. 이러한 클라이언트 요청을 라우팅하는 방법에는 경로 기반 라우팅 및 다중 사이트 라우팅의 두 가지 기본 방법이 있습니다.

경로 기반 라우팅

경로 기반 라우팅은 서로 다른 백 엔드 서버 풀에 서로 다른 URL 경로를 사용하여 요청을 보냅니다. 예를 들어, /video/* 경로의 요청은 비디오 스트리밍을 처리하도록 최적화된 서버가 있는 백 엔드 풀로 전달하고, /images/* 경로의 요청은 이미지 검색을 처리하는 서버 풀로 전달할 수 있습니다.

Diagram that depicts path-based routing in Azure Application Gateway.

다중 사이트 라우팅

다중 사이트 라우팅은 동일한 Application Gateway 인스턴스에서 둘 이상의 웹 애플리케이션을 구성합니다. 다중 사이트 구성에서는 Application Gateway의 IP 주소에 여러 개의 DNS 이름(CNAME)을 등록하여 각 사이트의 이름을 지정합니다. Application Gateway는 별도의 수신기를 사용하여 각 사이트에 대한 요청을 기다립니다. 각 수신기에서 요청을 다른 규칙에 전달하여 요청을 다른 백 엔드 풀의 서버로 라우팅할 수 있습니다. 예를 들어 http://contoso.com에 대한 모든 요청을 한 백 엔드 풀의 서버로 전달하고 http://fabrikam.com에 대한 요청을 다른 백 엔드 풀로 전달할 수 있습니다. 다음 다이어그램에서는 이 구성을 보여 줍니다.

Diagram that depicts multi-site routing in Azure Application Gateway.

다중 사이트 구성은 각 테넌트에 고유한 가상 머신 집합 또는 웹 애플리케이션을 호스팅하는 다른 리소스가 있는 다중 테넌트 애플리케이션을 지원하는 데 유용합니다.

Application Gateway 라우팅에는 다음 기능도 포함됩니다.

  • 리디렉션. 다른 사이트로 리디렉션하거나 HTTP에서 HTTPS로 리디렉션하는 데 사용할 수 있습니다.
  • HTTP 헤더 다시 쓰기. HTTP 헤더를 통해 클라이언트와 서버는 요청 또는 응답을 사용하여 매개 변수 정보를 전달할 수 있습니다.
  • 사용자 지정 오류 페이지. Application Gateway를 사용하면 기본 오류 페이지를 표시하는 대신 사용자 지정 오류 페이지를 만들 수 있습니다. 사용자 지정 오류 페이지를 사용하여 사용자 고유의 브랜딩과 레이아웃을 사용할 수 있습니다.

TLS/SSL 종료

애플리케이션 게이트웨이에서 TLS/SSL 연결을 종료하면 애플리케이션 게이트웨이는 CPU 집약적인 TLS/SSL 종료 워크로드를 서버에서 오프로드합니다. 또한 서버에 인증서를 설치하고 TLS/SSL을 구성할 필요가 없습니다.

엔드투엔드 암호화가 필요한 경우 Application Gateway는 프라이빗 키를 사용하여 게이트웨이의 트래픽을 암호 해독한 다음, 백 엔드 풀에서 실행되는 서비스의 공개 키를 사용하여 다시 암호화할 수 있습니다.

트래픽은 프런트 엔드 포트를 통해 게이트웨이로 들어갑니다. 여러 포트를 열 수 있으며, Application Gateway는 아무 포트에서나 메시지를 받을 수 있습니다. 트래픽이 포트를 통해 게이트웨이로 들어갈 때 가장 먼저 만나는 것이 수신기입니다. 수신기는 특정 호스트 이름 및 특정 IP 주소의 특정 포트를 수신 대기하도록 설정됩니다. 수신기는 TLS/SSL 인증서를 사용하여 게이트웨이로 들어오는 트래픽을 암호 해독할 수 있습니다. 그런 다음, 수신기는 개발자가 정의하는 규칙을 사용하여 수신 요청을 백 엔드 풀에 전달합니다.

Diagram that depicts TLS/SSL termination in Azure Application Gateway.

또한 Application Gateway를 통해 웹 사이트 또는 웹 애플리케이션을 노출한다는 것은 서버를 웹에 직접 연결하지 않는다는 의미입니다. 애플리케이션 게이트웨이에서 포트 80 또는 포트 443만 노출하면 백 엔드 풀 서버로 전달됩니다. 이 구성에서는 인터넷에서 웹 서버에 직접 액세스할 수 없으므로 인프라의 공격 노출 영역이 감소합니다.

상태 프로브

상태 프로브는 백 엔드 풀에서 부하 분산에 사용할 수 있는 서버를 결정합니다. Application Gateway는 상태 프로브를 사용하여 요청을 서버에 보냅니다. 서버에서 200~399 상태 코드의 HTTP 응답을 반환하는 경우 해당 서버가 정상적인 상태로 간주됩니다. 상태 프로브를 구성하지 않으면 Application Gateway에서 서버를 사용할 수 없다고 결정할 때까지 30초 동안 기다리는 기본 프로브를 만듭니다. 상태 프로브는 트래픽이 백 엔드 풀에서 응답하지 않거나 실패한 웹 엔드포인트로 전달되지 않도록 합니다.

자동 확장

Application Gateway는 자동 크기 조정을 지원하며, 트래픽 부하 패턴의 변화에 따라 스케일 업 또는 다운할 수 있습니다. 또한 자동 크기 조정을 사용하면 프로비전 시 배포 크기 또는 인스턴스 수를 선택할 필요가 없습니다.

WebSocket 및 HTTP/2 트래픽

Application Gateway는 WebSocket 및 HTTP/2 프로토콜에 대한 네이티브 지원을 제공합니다. WebSocket 및 HTTP/2 프로토콜은 장기 실행 TCP 연결을 통해 서버와 클라이언트 간의 전이중 통신을 지원합니다. 이 유형의 통신은 웹 서버와 클라이언트 간에 더 대화형이며 HTTP 기반 구현에서 필요에 따라 폴링할 필요 없이 양방향일 수 있습니다. 이러한 프로토콜은 HTTP와 달리 오버헤드가 낮고 동일한 TCP 연결을 여러 요청/응답에 다시 사용하므로 리소스를 더 효율적으로 활용할 수 있습니다. 이러한 프로토콜은 기존의 HTTP 포트 80 및 443을 통해 작동하도록 디자인되었습니다.