애플리케이션 배달 및 성능

이 문서는 워크로드에 적합한 Azure 부하 분산 서비스를 선택하는 데 도움이 됩니다. 지역 및 글로벌 트래픽 분산에 대한 Azure Load Balancer, Application Gateway 및 Azure Front Door 비교합니다. 또한 결합하는 시기도 설명합니다. 서비스별 간단한 개요는 '로드 밸런싱과 콘텐츠 전달이란 무엇인가?'를 참고하세요.

이 문서에서 다루는 내용

애플리케이션 딜리버리에는 네트워크 경계에 도달한 후 트래픽이 백엔드 자원에 어떻게 분배되는지 포함됩니다. 이 문서에서는 계층 4 및 계층 7 부하 분산 및 글로벌 트래픽 가속에 대해 설명합니다. 또한 세 가지 기본 Azure 부하 분산 서비스 중에서 선택하기 위한 결정 기준을 다룹니다.

메모

이 문서는 네트워크에 트래픽이 어떻게 도달하는지에 중점을 둔 인터넷 인그레스: 애플리케이션을 인터넷에 노출 문서를 보완합니다. 이 문서에서는 해당 트래픽의 균형을 맞추고 애플리케이션 백 엔드에 전달하는 방법에 중점을 둡니다.

이 문서가 필요한 사람

다음과 같은 경우 이 문서를 읽어보세요.

여러 백 엔드 인스턴스에서 고가용성이 필요한 웹 애플리케이션 또는 API를 호스트합니다.
HTTP/HTTPS 트래픽에 대해 SSL/TLS 오프로드, URL 기반 라우팅, 또는 Web Application Firewall(WAF) 보호가 필요합니다.
성능 또는 재해 복구를 위해 여러 Azure 지역에 트래픽을 분산합니다.
상태 프로브를 사용하여 지역 부하 분산이 필요한 비 HTTP 워크로드(TCP/UDP)를 실행합니다.
트래픽 유형, 지리적 범위 및 보안 요구 사항에 맞는 부하 분산 장치를 이해하려고 합니다.

리프트 앤 시프트 포커스: 다시 호스팅된 많은 내부 앱에는 지역 부하 분산 장치만 필요합니다. 고객에게 앱을 게시할 때 인터넷 연결 배달 서비스를 추가합니다.

현대화 중점: 앱 유형별로 전달 방식을 선택합니다. 전역 웹 앱에는 Azure Front Door를, 웹이 아닌 앱에는 Traffic Manager를 사용하여 액티브-액티브 지역 엔드포인트 앞단에 배치합니다.

클라우드 간 포커스: 다른 클라우드의 부하 분산 장치를 Azure 동등한 항목(예: AWS ALB에서 Application Gateway로, NLB에서 Azure Load Balancer)으로 매핑하고 허브 방화벽 뒤의 스포크에서 전달합니다.

Azure 서비스 및 기능

다음 표에는 세 가지 기본 Azure 부하 분산 서비스가 요약되어 있습니다.

서비스	제공하는 내용	사용 시기	키 제약 조건
Azure 표준 부하 분산 장치	지역 내의 계층 4(TCP/UDP) 부하 분산 네트워크 가상 어플라이언스에 대한 상태 프로브, 영역 중복성, 아웃바운드 SNAT 규칙 및 HA 포트.	가상 머신 확장 집합, AKS 내부 트래픽, HTTP/HTTPS 이외의 지역 워크로드 및 NVA의 고가용성.	SSL/TLS 종료 없음; WAF 없음; URL 기반 라우팅 없음 지역 범위만.
Azure Application Gateway	계층 7(HTTP/HTTPS) 지역 부하 분산 SSL/TLS 종료, URL 경로 기반 라우팅, 멀티 사이트 호스팅, 쿠키 기반 세션 선호도 및 선택적 WAF 통합	SSL 오프로드, URL 라우팅, WebSocket 지원 또는 WAF 보호가 필요한 지역 웹 애플리케이션	지역만 해당; 전용 서브넷이 필요합니다. 전역 라우팅 또는 CDN 시나리오에 적합하지 않습니다.
Azure Front Door	글로벌 애니캐스트 부하 분산 및 CDN. 에지에서의 TLS 종료, 통합 WAF, 오리진 상태 확인 프로브, 트래픽 분할, 그리고 전 세계 190개 이상의 PoP 전반에서의 캐싱.	글로벌 웹 애플리케이션, 다중 리전 active-active 배포, CDN 및 캐싱, 전역 WAF 적용.	HTTP/HTTPS 전용; 오리진은 공개적으로 접근 가능하거나 Private Link(프리미엄 등급)를 통해 접근 가능해야 합니다.

영역 중복성

영역 중복은 데이터 센터 오류로부터 애플리케이션 배달 계층을 보호합니다. 각 서비스는 가용성 영역을 다르게 처리합니다.

공용 IP 주소는 기본적으로 영역 중복 구성으로 설정되므로 표준 Load Balancer(공용)는 기본적으로 영역 중복입니다. 하나의 가용성 영역이 실패하더라도 트래픽은 계속 흐릅니다. 표준 Load Balancer(내부)에는 명시적 영역 중복 프런트 엔드 구성이 필요합니다. 프런트 엔드 IP를 만들 때 여러 영역을 선택해야 합니다.
Application Gateway v2 는 여러 가용성 영역에 인스턴스를 배포할 때 영역 중복성을 지원합니다. 배포하는 동안 영역을 지정합니다. 영역 중복 Application Gateway는 선택한 영역에 인스턴스를 분산하여 단일 영역이 오프라인 상태가 될 경우 가용성을 유지합니다.
Azure Front Door는 전역 애니캐스트 서비스이므로 기본적으로 영역 중복 구성을 갖습니다. 190개 이상의 에지 PoP는 전 세계 여러 지역에 걸쳐 있으므로 단일 영역 또는 지역 오류가 글로벌 트래픽 라우팅에 영향을 주지 않습니다.

Autoscaling

각 서비스는 크기 조정을 다르게 처리합니다.

Application Gateway v2 (Standard_v2 및 WAF_v2 계층)는 트래픽 부하에 따라 자동 크기 조정을 지원합니다. 최소 및 최대 인스턴스 수를 구성하고 게이트웨이는 해당 범위 내에서 확장됩니다. 가격 책정은 초당 새 연결, 영구 연결 및 처리량의 복합 측정값인 용량 단위를 사용합니다. 트래픽 급증 시 콜드 스타트 지연을 피하기 위해 운영 워크로드에 대해 최소 2개의 인스턴스 수를 설정하세요.
Azure Front Door 관리되는 전역 서비스로 자동으로 확장됩니다. 용량 계획 또는 인스턴스 크기 조정이 필요하지 않습니다.
표준 Load Balancer 수동 개입 또는 구성 변경 없이 수백만 개의 TCP/UDP 흐름으로 확장됩니다. 인스턴스 개념이 없는 완전 관리형 플랫폼 서비스입니다.

상태 확인 프로브

세 서비스 모두 상태 프로브를 사용하여 비정상 백 엔드를 검색하고 트래픽 라우팅을 중지합니다.

표준 Load Balancer TCP, HTTP 및 HTTPS 상태 프로브를 지원합니다. 프로브 간격 및 비정상 임계값을 구성하여 장애 조치(failover) 속도를 제어합니다. 간격이 짧을수록 오류를 더 빠르게 감지하지만 더 많은 프로브 트래픽을 생성합니다.
Application Gateway 는 사용자 지정 가능한 경로, 호스트 이름 및 응답 일치와 함께 HTTP/HTTPS 상태 프로브를 사용합니다. 사용자 지정 프로브를 사용하면 애플리케이션 논리의 유효성을 검사할 수 있습니다(예: 데이터베이스 연결을 확인하는 엔드포인트 확인 /health ).
Front Door 는 원본에 대해 HTTP/HTTPS 상태 프로브를 사용합니다. 구성 가능한 프로브 경로, 간격 및 응답 코드 일치를 지원합니다. Front Door는 여러 PoP의 원본을 프로브하여 분산 상태 확인을 제공합니다.

선택 방법

다음 순서도는 Azure 부하 분산 서비스를 선택하기 위한 기본 의사 결정 경로를 요약합니다.

다음 의사 결정 테이블을 사용하여 시나리오에 적합한 부하 분산 서비스를 선택합니다.

어떤 부하 분산 장치가 필요한가요?

…해야 합니다.	사용하세요
단일 지역 내에서 TCP/UDP 트래픽 부하 분산	Azure 표준 Load Balancer: 상태 프로브, 영역 중복성 및 HA 포트를 지원하는 4계층 트래픽 분산
SSL/TLS를 종료하고, URL 경로 또는 호스트 이름으로 라우팅하고, 지역 웹앱에 대한 WAF를 추가합니다.	Azure Application Gateway: 통합 WAF(v2 SKU)를 사용한 계층 7 지역 부하 분산
HTTP/HTTPS 트래픽을 전 세계적으로 라우팅하거나, 엣지 캐싱으로 지연을 줄이거나, 지역 간 장애 조치를 할 수 있습니다	Azure Front Door: CDN, WAF 및 다중 지역 원본 상태 확인 프로브를 갖춘 전역 애니캐스트.

키 제약 조건 비교

서비스	레이어	Scope	주요 제한 사항
표준 부하 분산 장치 (표준 Load Balancer)	계층 4(TCP/UDP)	지역	애플리케이션 인식 없음: HTTP 헤더, URL 또는 쿠키를 검사할 수 없습니다.
응용 프로그램 게이트웨이	계층 7(HTTP/HTTPS)	지역	전용 서브넷 필요(/24 권장); 는 트래픽을 전역적으로 라우팅할 수 없습니다.
Front Door	계층 7(HTTP/HTTPS)	전역	Origins는 공개 또는 Private Link(프리미엄 등급 한정)를 통해 접근 가능해야 하며; TCP/UDP 지원은 불가.

서비스 결합

많은 프로덕션 아키텍처는 여러 부하 분산 서비스를 체인에 결합합니다. 각 서비스는 가장 잘하는 작업을 처리합니다.

Front Door + Application Gateway: 전역 트래픽 분산 및 에지 WAF에 Front Door를 사용한 다음 URL 경로 기반 라우팅 및 백 엔드 풀 관리를 위해 지역 Application Gateway 인스턴스로 라우팅합니다. Front Door Premium은 Private Link 통해 Application Gateway에 연결하여 Application Gateway를 비공개로 유지할 수 있습니다. 이 패턴은 각 지역에 복잡한 URL 라우팅 요구 사항이 있는 다중 리전 배포에 적합합니다.
Front Door + Load Balancer: Front Door를 사용하여 전 세계 HTTP/HTTPS 배포를 담당하고, 내부 표준 Load Balancer를 통해 지역 내 Virtual Machine Scale Sets 또는 NVA 간에 트래픽을 분산시킵니다. Front Door는 전역 라우팅 및 캐싱을 처리하는 반면 Load Balancer 컴퓨팅 인스턴스에 계층 4 배포를 제공합니다.
Application Gateway + Load Balancer: 프런트 엔드에서 HTTP/HTTPS 트래픽 관리에 Application Gateway를 사용하고 동일한 배포에서 비 HTTP 백 엔드 계층(데이터베이스, 메시지 큐)에 대해 Load Balancer. 이 패턴은 7계층 지능을 가장자리에 두고 내부적으로 경량 4층 지능 분포를 유지합니다.

라우팅 기능

라우팅 기능을 이해하면 선택의 범위를 좁힐 수 있습니다.

Capability	표준 부하 분산 장치 (표준 Load Balancer)	응용 프로그램 게이트웨이	Front Door
URL 경로 기반 라우팅	No	예	예
다중 사이트(호스트 헤더) 라우팅	No	예	예
쿠키 기반 세션 선호도	No	예	예
가중치 기반 트래픽 분할	No	No	예
지리적 라우팅	No	No	예
SSL/TLS 오프로드	No	예	예
WebSocket 지원	투명	예	예
HTTP/2 지원	No	예	예

팁 (조언)

Application Gateway v2는 최소 인스턴스 수와 최대 인스턴스 수 사이에 자동 크기 조정되며 트래픽이 유휴 상태인 경우에도 최소 용량에 대한 비용을 지불합니다. 최소 인스턴스 수를 피크가 아닌 기준 부하로 설정하고 자동 크기 조정이 급증을 흡수하도록 합니다. 최소값을 과도하게 프로비전하는 것은 피할 수 있는 Application Gateway 비용의 일반적인 원인입니다.

디자인 고려 사항

Lift-and-shift 애플리케이션 제공 설계 중점 사항

리호스팅된 앱의 계층 간 동서 트래픽에는 내부 Azure Load Balancer를 사용하여, 해당 앱이 이미 사용하던 부하 분산 방식에 맞춥니다.
인터넷에 노출하는 앱에 대해서만 공용 배달 서비스를 추가합니다. 마이그레이션된 많은 내부 워크로드에는 아무 것도 필요하지 않습니다.
처음 다시 호스팅하는 동안 배달 디자인을 단순하고 단일 영역으로 유지합니다.
워크로드에 도달하기 전에 허브 방화벽을 통해 인바운드 인터넷 트래픽을 라우팅합니다.

애플리케이션 제공 설계를 현대화

애플리케이션 유형별로 선택: 글로벌 웹 앱(에지 종료, WAF)에는 Azure Front Door를, DNS 기반 지역 분산이 필요한 비웹 앱에는 Azure Traffic Manager를 선택합니다.
지역별로 액티브-액티브를 배포하고, 각 지역의 공용 엔드포인트(허브 방화벽 뒤에 있는 SNAT와 DNAT 역할을 하는)로 트래픽을 분산시킵니다.
글로벌 딜리버리가 필요할 때는 Front Door 뒤에서 지역 레이어 7 라우팅과 TLS 종료를 위해 애플리케이션 게이트웨이를 사용하세요.
Front Door와 Traffic Manager를 모두 동일한 흐름에 배포하지 마세요. 앱이 웹인지 웹이 아닌지에 따라 선택합니다.

클라우드 간 애플리케이션 제공 설계 중점

다른 클라우드의 서비스를 Azure 서비스에 매핑합니다. AWS Application Load Balancer 또는 Google Cloud Application Load Balancing은 Azure Application Gateway에, 네트워크 로드 밸런서는 Azure Load Balancer에 매핑합니다.
스포크에서 계층 7 전달(Application Gateway, WAF 포함)을 호스팅하고 공용 IP를 가상 머신에 직접 할당하지 마세요.
퍼블릭 인그레스 트래픽이 마이그레이션된 워크로드에 도달하기 전에 보안이 적용된 허브 방화벽을 거치도록 라우팅하세요.
워크로드가 둘 이상의 Azure 지역에서 실행되면 다중 지역 배달에 Front Door 또는 Traffic Manager를 사용합니다.

사전 요구 사항

애플리케이션 배달 서비스를 구현하기 전에 다음을 수행합니다.

배포된 가상 네트워크: 서브넷이 있는 가상 네트워크가 하나 이상 필요합니다. 서브넷 계획 지침은 가상 네트워크 및 서브넷 디자인을 참조하세요.
식별된 워크로드 트래픽 유형: 워크로드가 HTTP/HTTPS(계층 7) 또는 TCP/UDP(계층 4)를 사용하는지 여부를 확인합니다. 이 트래픽 유형이 주요 부하 분산 선택지를 결정합니다.
정의된 지리적 범위: 사용자가 단일 지역에 있는지 아니면 전역적으로 분산되어 있는지 확인합니다. 전 세계 사용자들은 Front Door의 애니캐스트 가속의 이점을 누립니다.
Application Gateway의 서브넷 용량: Application Gateway에는 다른 리소스가 없는 전용 서브넷이 필요합니다. /24 서브넷은 최대 125개의 인스턴스와 5개의 Azure 예약 주소를 지원합니다.

보안 고려 사항

부하 분산 서비스는 보안 경계의 일부입니다. 들어오는 트래픽을 처리하는 첫 번째 구성 요소로, 보안 구성이 중요합니다. 애플리케이션 배달 계층을 보호하려면 다음 방법을 따르세요.

WAF(웹 애플리케이션 방화벽)

모든 프로덕션 웹 워크로드에 대해 Application Gateway 또는 Front Door의 방지 모드 에서 WAF를 사용하도록 설정합니다. 검색 모드는 위협을 차단하지 않고만 기록합니다. 초기 튜닝 중에 이를 사용해 가양성을 식별한 다음, 운영 트래픽이 유입되기 전에 방지 모드로 전환하십시오.

WAF는 다음을 비롯한 일반적인 웹 악용으로부터 보호합니다.

SQL 삽입 및 XSS(사이트 간 스크립팅)
프로토콜 이상 및 요청 스머글링
봇 및 크롤러(봇 보호 규칙 포함)
관리되는 규칙 집합을 통한 OWASP 상위 10개 취약성

Application Gateway WAF와 Front Door WAF는 모두 동일한 규칙 엔진을 사용하지만 범위는 다릅니다. Application Gateway WAF는 지역 배포를 보호하고 Front Door WAF는 트래픽이 원본에 도달하기 전에 전역 에지에 정책을 적용합니다. 자세한 WAF 튜닝 및 규칙 집합 구성은 Web Application Firewall 참조하세요.

DDoS protection

부하 분산 서비스와 연관된 모든 공인 IP 주소에 대해 Azure DDoS 보호를 활성화하세요. 표준 Load Balancer 공용 프런트 엔드 IP 및 Application Gateway 공용 IP는 대량 공격의 주요 대상입니다. 이러한 IP는 애플리케이션의 진입점을 나타냅니다.

Azure DDoS Protection은 다음을 제공합니다.

적응형 조정을 통한 상시 트래픽 모니터링
트래픽이 임계값을 초과하는 경우 자동 공격 완화.
Azure Monitor를 통한 공격 텔레메트리 및 경고
DDoS 공격이 유발하는 자원 확장에 대한 보호 비용(서비스 크레딧).

DDoS 보호 계획 및 구성은 DDoS 보호를 참조하세요.

오리진에 대한 Private Link(Front Door Premium)

Azure Front Door Premium은 원본에 대한 Private Link 연결을 지원합니다. 이 기능을 사용하면 공개적으로 액세스할 수 있는 백 엔드 서버가 필요하지 않습니다. Front Door는 공용 인터넷 대신 Azure 백본 네트워크를 통해 원본에 연결합니다. 다음과 같은 경우 Private Link 원본을 사용합니다.

백 엔드는 공용 IP 주소가 없어야 하는 내부 서비스입니다.
원본 서버 액세스를 Front Door 트래픽으로만 제한해야 합니다.
규정 준수 요구 사항은 애플리케이션 서버에서 퍼블릭 엔드포인트를 금지합니다.
공개적으로 노출된 원본의 공격 표면을 제거하려고 합니다.

지원되는 Private Link 원본에는 App Service, Azure Storage, Application Gateway, 내부 표준 Load Balancer 및 Private Link 서비스를 사용하는 사용자 지정 원본이 포함됩니다.

Private Link 아키텍처 패턴은 Azure PaaS 서비스에 대한 프라이빗 액세스를 참조하세요.

Important

Front Door 표준 계층은 원본에 대한 Private Link 지원하지 않습니다. Front Door Premium만 이 기능을 제공합니다.

상호 TLS(mTLS) - 상호 전송 계층 보안

Application Gateway v2는 백 엔드 인증을 위해 상호 TLS를 지원합니다. 백 엔드 서버에 게이트웨이에서 인증서 기반 클라이언트 인증이 필요한 경우 mTLS를 사용합니다. 이 인증은 신뢰 확인 계층을 추가합니다. 백엔드는 트래픽이 게이트웨이를 우회한 악의적인 행위자가 아닌 합법적인 애플리케이션 게이트웨이 인스턴스에서 들어오는지 확인할 수 있습니다.

로드 밸런싱과 콘텐츠 전달이란 무엇인가요?: Azure Application Gateway, Load Balancer, Front Door의 서비스별 개요.
인터넷 인바운드: 애플리케이션을 인터넷에 노출하기: 트래픽이 Azure 네트워크 경계에 유입되는 방식.
가상 네트워크 및 서브넷 디자인: Application Gateway 전용 서브넷 크기 조정을 포함한 서브넷 계획.
Azure PaaS 서비스에 대한 프라이빗 액세스: 원본에 Front Door Premium을 포함한 Private Link 패턴입니다.
지역 간 연결성: Front Door를 글로벌 진입 지점으로 하는 다중 지역 아키텍처.
인터넷 아웃바운드 송신: 부하 분산 백엔드의 아웃바운드 트래픽 송신을 위한 SNAT, 아웃바운드 규칙 및 NAT 게이트웨이

자세히 알아보기

다음 단계