다음을 통해 공유


부하 분산 옵션

부하 분산이라는 용어는 여러 컴퓨팅 리소스에서 처리 분산을 의미합니다. 부하를 분산하여 리소스 사용량을 최적화하고, 처리량을 최대화하고, 응답 시간을 최소화하고, 단일 리소스 오버로드를 방지합니다. 부하 분산은 중복 컴퓨팅 리소스 간에 워크로드를 공유하여 가용성을 향상시킬 수도 있습니다.

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로 작업하세요.

모든 애플리케이션에는 간단한 의사 결정 트리에서 캡처되지 않은 고유한 요구 사항이 있습니다. 이 흐름도 또는 코필로트 권장 사항을 시작점으로 처리합니다. 그런 다음, 더 자세한 평가를 수행합니다.

Azure에서 부하 분산을 위한 의사 결정 트리를 보여 주는 다이어그램

이미지는 각 경로가 부하 분산 솔루션으로 이어지는 분기된 순서도를 보여줍니다. 첫 번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작하여 No 화살표를 통해 인터넷과 연결된 애플리케이션을 가리킨 다음, 또 다른 No 화살표를 통해 로드 밸런서로 연결됩니다. 두 번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작되어 No 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, Yes 화살표를 통해 전 세계 여러 지역에 배포된 애플리케이션을 가리킨 다음, No 화살표를 통해 Load Balancer를 가리킵니다. 세 번째 경로는 웹 애플리케이션(HTTP/HTTPs)에서 시작하고, '아니요' 화살표를 따라 인터넷에 노출된 애플리케이션으로 가리킨 뒤, '예' 화살표를 통해 여러 지역에 배포된 전역으로 가리킨 다음, '예' 화살표를 통해 Traffic Manager 및 Load Balancer로 연결됩니다. 네 번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작되어, '예' 화살표를 따라 인터넷 연결 애플리케이션과 연결되고, '아니요' 화살표를 따라 API만 호스팅으로 연결된 후, '예' 화살표를 통해 API 관리에 연결됩니다. 다섯 번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작하며 "Yes" 화살표를 통해 인터넷 연결 애플리케이션을 가리킨 후, "No" 화살표를 통해 API만 호스팅하는 방향으로, 다시 "No" 화살표를 통해 Application Gateway로 연결됩니다. 여섯 번째 경로는 웹 애플리케이션(HTTP/HTTPs)에서 시작하여, 예 화살표를 통해 인터넷 연결 애플리케이션을 가리킵니다. 그 다음 예 화살표를 통해 여러 지역에 전역적으로 배포되는 환경으로 이동하고, 요청당 SSL 오프로드 또는 애플리케이션 계층 처리가 필요한지를 묻습니다. 그리고 예 화살표를 통해 Azure Front Door 및 Application Gateway로 향합니다. 일곱 번째 경로는 웹 애플리케이션(HTTP/HTTPs)에서 시작되며 '예' 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, '예' 화살표를 통해 전역/배포된 여러 지역으로 이동합니다. 요청당 SSL 오프로드 또는 애플리케이션 계층 처리가 필요합니까? 'Only APIs' 화살표를 통해 Azure Front Door와 API Management로 연결합니다. 여덟 번째 경로는 웹 애플리케이션(HTTP/HTTP)에서 시작되며, 예 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, 예 화살표를 통해 전역/배포된 여러 지역으로, 요청당 SSL 오프로드 또는 애플리케이션 계층 처리가 필요합니까, 호스팅 - PaaS, IaaS, NO 화살표를 통한 AKS, PaaS 화살표를 통해 Azure Front Door로 이동합니다. 아홉 번째 경로는 웹 애플리케이션(HTTP/HTTPs)에서 시작되며 예 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, 예 화살표를 통해 글로벌/배포된 여러 지역으로, 요청당 SSL 오프로드 또는 애플리케이션 계층 처리가 필요한지 묻고, 아니오 화살표를 통해 호스팅 - PaaS, IaaS, AKS로 이동한 다음 AKS 화살표를 통해 Azure Front Door 및 Application Gateway 수신 컨트롤러로 연결합니다. 열 번째 경로는 웹 애플리케이션(HTTP/HTTPs)에서 시작되며, Yes 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, Yes 화살표를 통해 전역/여러 지역에 배포된 애플리케이션을 가리킨 뒤, 각 요청에 대해 SSL 오프로드 또는 애플리케이션 계층 처리가 필요한지 확인합니다. No 화살표를 통해 호스팅 - PaaS, IaaS, AKS로 이동하며, IaaS VM 화살표를 통해 Azure Front Door 및 Load Balancer로 향합니다. 11번째 경로는 웹 애플리케이션(HTTP/HTTP)에서 시작되며 예 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, 예 화살표를 통해 전역/배포된 여러 지역으로, 아니요 화살표를 통해 성능 가속이 필요합니까, 아니요 화살표를 통해 Application Gateway로 연결합니다. 12번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작하여, 예 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, 다시 예 화살표를 통해 여러 지역에 배포된 전역 애플리케이션으로 안내됩니다. 아니요 화살표를 통해 성능 가속이 필요한지 묻고, 예 화살표를 통해 요청별 SSL 오프로드 또는 애플리케이션 계층 처리가 필요한지 확인하여, 최종적으로 또다른 예 화살표를 통해 Azure Front Door 및 Application Gateway로 이동합니다. 13번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작하여 예 화살표를 통해 인터넷 연결 애플리케이션으로, 예 화살표를 통해 전 세계에 배포된 여러 지역으로 연결됩니다. 아니요 화살표를 따라 성능 가속이 필요한지, 예 화살표를 통해 요청당 SSL 오프로드 또는 애플리케이션 계층 처리가 필요한지 묻습니다. 그런 다음 API 전용 화살표를 통해 Azure Front Door 및 API 관리로 연결됩니다. 14번째 경로는 웹 애플리케이션(HTTP/HTTPS)에서 시작되며, 예 화살표를 통해 인터넷을 향한 애플리케이션을 가리키고, 예 화살표를 통해 전 세계/여러 지역에 배포된 것으로, 아니요 화살표를 통해 성능 가속이 필요하지 않는 경우, 아니요 화살표를 통해 Application Gateway로 연결합니다. 15번째 경로는 웹 애플리케이션(HTTP/HTTP)에서 시작되며 예 화살표를 통해 인터넷 연결 애플리케이션을 가리키고, 예 화살표를 통해 전역/배포된 여러 지역으로, 아니요 화살표를 통해 성능 가속이 필요합니까, 유일한 API 화살표를 통해 Application Gateway 및 API Management로 연결합니다.

워크로드에 부하 분산이 필요한 여러 서비스가 포함된 경우 각 서비스를 개별적으로 평가합니다. 효과적인 설정은 종종 둘 이상의 부하 분산 솔루션을 사용합니다. 이러한 솔루션을 워크로드 아키텍처의 여러 위치에 통합하여 고유한 함수 또는 역할을 제공할 수 있습니다.

정의

  • 웹 애플리케이션(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 지역에 복원력 있는 다중 계층 애플리케이션을 배포하는 방법을 알아봅니다.

다음 단계