부하 분산이라는 용어는 여러 컴퓨팅 리소스에서 처리 분산을 의미합니다. 부하를 분산하여 리소스 사용량을 최적화하고, 처리량을 최대화하고, 응답 시간을 최소화하고, 단일 리소스 오버로드를 방지합니다. 부하 분산은 중복 컴퓨팅 리소스 간에 워크로드를 공유하여 가용성을 향상시킬 수도 있습니다.
Azure는 여러 컴퓨팅 리소스에 워크로드를 분산하는 데 사용할 수 있는 다양한 부하 분산 서비스를 제공합니다. 이러한 서비스에는 Azure API Management, Azure Application Gateway, Azure Front Door, Azure Load Balancer 및 Azure Traffic Manager가 포함됩니다.
이 문서에서는 워크로드 요구 사항에 적합한 부하 분산 솔루션을 결정하는 데 도움이 되는 고려 사항을 설명합니다.
Azure 부하 분산 서비스
Azure에서는 다음과 같은 주요 부하 분산 서비스 및 부하 분산 기능을 사용하는 서비스를 사용할 수 있습니다.
API Management 는 HTTP(S) API를 게시, 보안, 변환, 유지 관리 및 모니터링하는 데 사용할 수 있는 관리되는 서비스입니다. API에 대한 게이트웨이를 제공하고 지정된 부하 분산 백 엔드 풀의 노드 간에 트래픽 부하를 분산하도록 구성할 수 있습니다. 라운드 로빈, 가중치 및 우선 순위 기반의 세 가지 부하 분산 방법 중에서 선택할 수 있습니다.
중요합니다
API Management는 일반적인 범용 부하 분산 장치가 아닙니다. HTTP API용으로 특별히 설계되었으며, 부하 분산 기능은 광범위한 API 관리 기능 내에서 선택 사항입니다. API Management는 특정 API 호스팅 토폴로지의 부하 분산 기능을 제공하기 때문에 완전성을 위해 이 문서에 포함되어 있습니다. 그러나 주요 목적은 부하 분산이 아닌 API 게이트웨이 기능입니다.
Application Gateway 는 웹 트래픽 부하 분산 장치입니다. 관리되는 서비스로 애플리케이션 배달 컨트롤러 기능을 제공합니다. 또한 다양한 계층 7 부하 분산 기능 및 웹 애플리케이션 방화벽 기능을 제공합니다. Application Gateway를 사용하여 공용 네트워크 공간에서 지역 내의 프라이빗 네트워크 공간에 호스트되는 웹 서버로 트래픽을 전환합니다.
Azure Front Door 는 웹 애플리케이션에 대한 글로벌 부하 분산 및 사이트 가속을 제공하는 애플리케이션 배달 네트워크입니다. SSL(Secure Sockets Layer) 오프로드, 경로 기반 라우팅, 빠른 장애 조치(failover) 및 캐싱과 같은 애플리케이션에 대한 Layer-7 기능을 제공하여 성능 및 고가용성을 향상시킵니다.
Load Balancer 는 모든 UDP(사용자 데이터그램 프로토콜) 및 TCP(Transmission Control Protocol) 프로토콜에서 인바운드 및 아웃바운드 트래픽을 처리하는 Layer-4 서비스입니다. 고성능 및 매우 낮은 대기 시간을 위해 설계되었습니다. 솔루션의 고가용성을 보장하면서 초당 수백만 개의 요청을 처리하도록 빌드되었습니다. Load Balancer는 영역 중복성을 가지며, 가용 영역 간의 고가용성을 보장합니다. 지역 배포 토폴로지와 지역 간 토폴로지 모두를 지원합니다.
Traffic Manager 는 고가용성 및 응답성을 제공하면서 글로벌 Azure 지역에 걸쳐 서비스에 트래픽을 최적으로 분산할 수 있는 DNS(Domain Name System) 기반 트래픽 부하 분산 장치입니다. Traffic Manager는 DNS 기반 부하 분산 서비스이므로 도메인 수준에서만 부하를 분산합니다. 이러한 이유로 Azure Front Door만큼 빠르게 장애 조치(failover)할 수 없습니다. DNS 캐싱 및 DNS TTL(Time-to-Live) 값을 무시하는 시스템은 종종 이 지연을 발생합니다.
비고
Azure Container Apps 또는 AKS(Azure Kubernetes Service)와 같은 클러스터링 기술에는 부하 분산 구문이 포함됩니다. 이러한 구문은 대부분 자체 클러스터 경계 범위 내에서 작동합니다. 준비 상태 및 상태 프로브에 따라 트래픽을 사용 가능한 애플리케이션 인스턴스로 라우팅합니다. 이 문서에서는 이러한 부하 분산 옵션을 다루지 않습니다.
서비스 분류
Azure 부하 분산 서비스는 전역 및 지역 및 HTTP(S) 및 비 HTTP(S)의 두 가지 차원을 따라 분류할 수 있습니다.
전역 및 지역
글로벌: 이러한 부하 분산 서비스는 지역 백 엔드, 클라우드 또는 하이브리드 온-프레미스 서비스에 트래픽을 분산합니다. 사용자 트래픽을 사용 가능한 백 엔드로 전역적으로 라우팅하는 단일 컨트롤 플레인을 제공합니다. 이러한 서비스는 가용성 및 성능을 최대화하기 위해 서비스 안정성 또는 성능의 변화에 대응합니다. 여러 지역 또는 지역에서 호스트되는 애플리케이션 스탬프, 엔드포인트 또는 배율 단위 간에 부하를 분산하는 시스템으로 생각할 수 있습니다.
국부의: 이러한 부하 분산 서비스는 VM(가상 머신) 또는 지역 내 영역 및 영역 중복 서비스 엔드포인트에 걸쳐 가상 네트워크 내에서 트래픽을 분산합니다. 가상 네트워크의 지역 내에서 VM, 컨테이너 또는 클러스터 간에 부하를 분산하는 시스템으로 생각할 수 있습니다.
HTTP(S) 및 비HTTP(S)
HTTP(S): 이러한 부하 분산 서비스는 HTTP(S) 트래픽만 허용하는 계층 7 부하 분산 장치입니다. 웹 애플리케이션 또는 다른 HTTP(S) 엔드포인트용으로 설계되었습니다. 기능에는 SSL 오프로드, 웹 애플리케이션 방화벽, 경로 기반 부하 분산 및 세션 선호도가 포함됩니다.
비 HTTP(S): 이러한 부하 분산 서비스에는 계층 4 TCP 및 UDP 서비스 또는 DNS 기반 부하 분산 서비스가 포함됩니다.
다음 표에는 Azure 부하 분산 서비스가 요약되어 있습니다.
서비스 | 전역 또는 지역 | 권장 트래픽 |
---|---|---|
API 관리 | 지역 또는 글로벌 | HTTP(S) API만 |
애플리케이션 게이트웨이 | 지역 | HTTP(S) |
Azure Front Door (Azure의 웹 트래픽 관리 서비스) | 글로벌 | HTTP(S) |
부하 분산기 | 지역 또는 글로벌 | Non-HTTP(S) |
트래픽 매니저 | 글로벌 | Non-HTTP(S) |
비고
Traffic Manager 및 Load Balancer는 HTTP(S)를 비롯한 모든 트래픽 유형을 배포할 수 있습니다. 그러나 이러한 서비스는 계층 7 기능을 제공하지 않습니다. Load Balancer와 달리 Traffic Manager는 트래픽을 직접 처리하지 않습니다. Traffic Manager는 DNS를 사용하여 클라이언트를 적절한 엔드포인트로 전달합니다.
시나리오에 대한 부하 분산 솔루션 선택
부하 분산 솔루션을 선택할 때 다음 요소를 고려합니다.
트래픽 유형: 웹 HTTP(S) 애플리케이션인지 여부와 공용 또는 프라이빗 애플리케이션인지 확인합니다.
전역 및 지역: 단일 가상 네트워크 내에서 VM 또는 컨테이너의 부하를 분산해야 하는지, 지역 간에 배율 단위 또는 배포의 부하를 분산해야 하는지 또는 둘 다의 부하를 분산해야 하는지를 명확히 합니다.
가용도:SLA(서비스 수준 계약)를 검토합니다.
비용: 서비스 자체의 비용과 해당 서비스를 기반으로 구축된 솔루션을 관리하는 운영 비용을 고려합니다. 자세한 내용은 Azure 가격 책정을 참조하세요.
기능 및 제한 사항: 각 서비스에서 지원하는 기능 및 해당 서비스 제한을 식별합니다.
다음 순서도는 애플리케이션에 대한 부하 분산 솔루션을 선택하는 데 도움이 됩니다. 순서도는 권장 사항에 도달하기 위한 주요 결정 조건 집합을 안내합니다.
팁 (조언)
Azure에서 Microsoft Copilot를 사용하여 여기에 설명된 순서도와 유사하게 이 결정을 안내할 수 있습니다. 자세한 내용은 Azure에서 Microsoft Copilot를 사용하여 Azure Load Balancer로 작업하세요.
모든 애플리케이션에는 간단한 의사 결정 트리에서 캡처되지 않은 고유한 요구 사항이 있습니다. 이 흐름도 또는 코필로트 권장 사항을 시작점으로 처리합니다. 그런 다음, 더 자세한 평가를 수행합니다.
워크로드에 부하 분산이 필요한 여러 서비스가 포함된 경우 각 서비스를 개별적으로 평가합니다. 효과적인 설정은 종종 둘 이상의 부하 분산 솔루션을 사용합니다. 이러한 솔루션을 워크로드 아키텍처의 여러 위치에 통합하여 고유한 함수 또는 역할을 제공할 수 있습니다.
정의
웹 애플리케이션(HTTP/HTTPS) 은 다음 기능 중 하나 이상이 필요한 애플리케이션을 나타냅니다.
- URL 경로와 같은 계층 7 데이터에 대한 라우팅 결정을 내립니다.
- HTTP 요청 본문과 같은 통신 페이로드 검사를 지원합니다.
- TLS(전송 계층 보안) 기능 처리
인터넷 연결 애플리케이션은 인터넷 에서 공개적으로 액세스할 수 있는 애플리케이션을 나타냅니다. 애플리케이션 소유자는 웹 애플리케이션 방화벽 및 분산 서비스 거부 보호와 같은 제품을 설정하여 제한적인 액세스 정책을 적용하거나 애플리케이션을 보호하는 것이 가장 좋습니다.
전역 또는 여러 지역에 배포됨 은 부하 분산 장치에 전역적으로 분산된 애플리케이션의 퍼블릭 엔드포인트로 트래픽을 라우팅하는 고가용성 제어 평면이 하나 있어야 임을 의미합니다. 이 구성은 지역 전체에서 활성-활성 또는 활성-수동 토폴로지 중 하나를 지원할 수 있습니다.
비고
Application Gateway와 같은 지역 서비스를 사용하여 여러 지역에 걸쳐 있는 백 엔드 간 부하를 분산하고 단일 제어 평면을 통해 라우팅을 제어할 수 있습니다. 지역 간 프라이빗 링크, 글로벌 가상 네트워크 피어링 또는 다른 지역의 서비스의 공용 IP 주소를 사용하여 작동합니다.
이 시나리오는 이 결정의 기본 지점이 아닙니다.
지역 리소스를 전역적으로 분산된 백 엔드에 대한 라우터로 사용하면 지역별 단일 실패 지점이 발생합니다. 또한 트래픽이 다른 지역으로 이동한 다음 다시 돌아가기 전에 한 지역을 통해 강제되기 때문에 추가 대기 시간이 발생합니다.
PaaS(Platform as a Service) 는 VM 또는 네트워킹 리소스를 관리할 필요 없이 애플리케이션을 배포할 수 있는 관리되는 호스팅 환경을 제공합니다. 이 경우 PaaS는 한 지역 내에서 통합 부하 분산을 제공하는 서비스를 의미합니다. 자세한 내용은 확장성을 위해 컴퓨팅 서비스 선택을 참조하세요.
AKS 를 사용하면 컨테이너화된 애플리케이션을 배포하고 관리할 수 있습니다. AKS는 서버리스 Kubernetes, CI/CD(통합 연속 통합 및 지속적인 업데이트) 환경, 엔터프라이즈급 보안 및 거버넌스를 제공합니다. 자세한 내용은 AKS 아키텍처 디자인을 참조하세요.
IaaS(Infrastructure as a Service) 는 연결된 네트워크 및 스토리지 구성 요소와 함께 필요한 VM을 프로비전하는 컴퓨팅 옵션입니다. IaaS 애플리케이션에는 Load Balancer를 사용하여 가상 네트워크 내에서 내부 부하 분산이 필요합니다.
애플리케이션 계층 처리 는 가상 네트워크 내의 특수 라우팅을 의미합니다. 예를 들어 VM 또는 가상 머신 확장 집합에서 경로 기반 라우팅이 있습니다. 자세한 내용은 Azure Front Door 뒤에 Application Gateway 배포를 참조하세요.
API만 웹 애플리케이션이 아닌 HTTP(S) API의 부하를 분산해야 하는 필요성을 나타냅니다. 이 경우 워크로드가 게이트웨이 기능에 이미 API Management를 사용하는 경우 선택적 부하 분산 기능을 사용하여 다른 메커니즘을 통해 부하가 아직 분산되지 않은 API 백 엔드 간에 트래픽을 전달하도록 고려할 수 있습니다. 워크로드가 API Management를 사용하지 않는 경우 부하 분산에만 사용하지 마세요.
성능 가속 은 웹 액세스를 가속화하는 기능을 나타냅니다. 성능 가속은 콘텐츠 전송 네트워크 또는 최적화된 네트워크 접속 지점을 사용하여 대상 네트워크에 가속화된 클라이언트 온보딩을 통해 달성할 수 있습니다. Azure Front Door는 콘텐츠 배달 네트워크 와 Anycast 트래픽 가속을 모두 지원합니다. 아키텍처에서 Application Gateway를 사용하거나 사용하지 않는 두 기능의 이점을 모두 얻을 수 있습니다.
기타 고려 사항
각 부하 분산 서비스에는 고려해야 할 기능 지원 또는 구현 세부 정보도 있습니다. 다음은 부하 분산 시나리오와 관련될 수 있는 몇 가지 예입니다.
- WebSockets 지원
- 서버에서 보낸 이벤트 지원
- HTTP/2 지원(백 엔드 노드 수신 및 계속)
- 고정 세션 지원
- 백 엔드 노드 상태 모니터링 메커니즘
- 클라이언트 환경 또는 비정상 노드 검색과 라우팅 논리에서 제거 사이의 지연
부하 분산 장치에 기능 오프로드
Azure의 일부 부하 분산 옵션을 사용하면 백 엔드 노드에서 부하 분산 장치로 기능을 오프로드할 수 있습니다. 이러한 옵션은 게이트웨이 오프로드 클라우드 디자인 패턴을 구현합니다. 예를 들어 Application Gateway는 TLS를 오프로드할 수 있으므로 워크로드의 공용 인증서는 백 엔드 노드가 아닌 한 위치에서 관리됩니다. JWT(JSON Web Token) 액세스 토큰에서 클레임 유효성 검사와 같은 몇 가지 기본 권한 부여 문제를 오프로드하도록 API Management를 구성할 수 있습니다. 교차 절단 문제를 오프로드하면 백 엔드에서 논리의 복잡성을 줄이고 성능을 향상시키는 데 도움이 될 수 있습니다.
예시
다음 표에서는 솔루션에 사용되는 부하 분산 서비스를 기반으로 하는 다양한 문서를 나열합니다.
서비스 | 조항 | 설명 |
---|---|---|
부하 분산기 | 가용성 영역에 VM 부하 분산 | 가용성 영역 간에 VM 부하를 분산하여 전체 데이터 센터의 실패 또는 손실로부터 앱과 데이터를 보호합니다. 영역 중복을 사용하면 하나 이상의 가용성 영역이 실패할 수 있으며 해당 지역의 한 영역이 정상 상태로 유지되는 한 데이터 경로가 유지됩니다. |
트래픽 매니저 | 고가용성 및 재해 복구를 위해 빌드된 다중 계층 웹 애플리케이션 | 고가용성 및 재해 복구를 위해 빌드된 복원력 있는 다중 계층 애플리케이션을 배포합니다. 주 지역을 사용할 수 없게 되면 Traffic Manager가 보조 지역으로 장애 조치합니다. |
애플리케이션 게이트웨이 및 API 관리 | API Management 랜딩 존 아키텍처 | Application Gateway를 사용하여 웹 애플리케이션 방화벽 및 TLS를 오프로드합니다. API Management를 사용하여 API 백 엔드 간에 부하를 분산합니다. |
Traffic Manager 및 Application Gateway | Traffic Manager 및 Application Gateway를 사용한 다중Region 부하 분산 | 고가용성 및 강력한 재해 복구 인프라를 달성하기 위해 웹 워크로드를 제공하고 여러 Azure 지역에 복원력 있는 다중 계층 애플리케이션을 배포하는 방법을 알아봅니다. |