Application Gateway 작동 방식

  • 5분

Azure Application Gateway는 웹 서버 풀의 전반에 걸쳐 안전하게 경로와 부하 분산 요청을 조합한 일련의 구성 요소입니다. Application Gateway에는 다음과 같은 구성 요소가 있습니다.

Azure Application Gateway 구성 요소를 보여 주는 다이어그램.

  • 프런트 엔드 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(Open Systems Interconnection) 계층 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 App Services에서 호스트되는 앱 또는 온-프레미스 서버 컬렉션으로 구성될 수 있는 웹 서버 컬렉션입니다.

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

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

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

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

  • 서버가 HTTPS 프로토콜을 통한 트래픽을 기대할 수 있습니다.
  • 트래픽을 암호화하고 서버에 대한 연결을 인증하는 데 사용할 인증서.

Application Gateway 라우팅

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

경로 기반 라우팅

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

Azure Application Gateway의 경로 기반 라우팅을 보여 주는 다이어그램.

다중 사이트 라우팅

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

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 인증서를 사용하여 게이트웨이로 들어오는 트래픽을 암호 해독할 수 있습니다. 그런 다음, 수신기는 개발자가 정의하는 규칙을 사용하여 수신 요청을 백 엔드 풀에 전달합니다.

Azure Application Gateway에서 TLS/SSL 종료를 보여 주는 다이어그램.

또한 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(Transmission Control Protocol) 연결을 통해 서버와 클라이언트 간에 전체 이중 통신을 수행할 수 있습니다. 이러한 형식의 통신은 웹 서버와 클라이언트 사이에서 더욱 상호 작용적이며, HTTP 기반 구현에서 요구되는 폴링 없이도 양방향으로 이루어질 수 있습니다. 이러한 프로토콜은 HTTP와 달리 오버헤드가 낮고 동일한 TCP 연결을 여러 요청/응답에 다시 사용하므로 리소스를 더 효율적으로 활용할 수 있습니다. 이러한 프로토콜은 기존의 HTTP 포트 80 및 443을 통해 작동하도록 디자인되었습니다.