Load Balancer의 안정성

아티클
02/19/2024

이 문서에는 Load Balancer에 대한 특정 안정성 권장 사항과 가용성 영역 및 지역 간 재해 복구 및 비즈니스 연속성을 통한 Load Balancer 지역 복원력에 대한 자세한 정보가 포함되어 있습니다.

Azure의 안정성에 대한 아키텍처 개요는 Azure 안정성을 참조하세요.

안정성 권장 사항

이 섹션에는 복원력과 가용성을 달성하기 위한 권장 사항이 포함되어 있습니다. 각 권장 사항은 다음 두 가지 범주 중 하나에 속합니다.

상태 항목은 Azure 리소스 구성 설정, 다른 서비스에 대한 종속성 등 Azure 워크로드를 구성하는 주요 구성 요소의 적절한 기능 및 구성 항목과 같은 영역을 다룹니다.
위험 항목은 가용성 및 복구 요구 사항, 테스트, 모니터링, 배포 및 해결되지 않은 상태로 둘 경우 환경에서 문제가 될 가능성이 큰 기타 항목과 같은 영역을 다룹니다.

안정성 권장 사항 우선 순위 매트릭스

각 권장 사항은 다음 우선 순위 매트릭스에 따라 표시됩니다.

이미지	우선 순위	설명
	높음	즉시 수정 필요.
	중간	3-6개월 이내에 수정.
	낮음	검토 필요.

안정성 권장 사항 요약

범주	우선 순위	권장
가용성		표준 Load Balancer가 영역 중복인지 확인합니다.
		백 엔드 풀에 인스턴스가 2개 이상 포함되어 있는지 확인합니다.
시스템 효율성		프로덕션 워크로드에 대한 아웃바운드 규칙 대신 NAT Gateway 사용
		표준 Load Balancer SKU 사용

가용성

표준 Load Balancer가 영역 중복인지 확인합니다.

가용성 영역을 지원하는 지역에서는 영역 중복성을 사용하여 표준 Load Balancer를 배포해야 합니다. 영역 중복 Load Balancer를 사용하면 영역 오류를 견딜 수 있는 단일 프런트 엔드 IP 주소로 트래픽을 처리할 수 있습니다. 프런트 엔드 IP는 영역에 관계없이 모든(영향을 받지 않는) 백 엔드 풀 멤버에 연결하는 데 사용될 수 있습니다. 가용성 영역에 장애가 발생하는 경우 해당 지역의 나머지 영역이 정상으로 유지되는 한 데이터 경로는 유지될 수 있습니다. 자세한 내용은 영역 중복 부하 분산 장치를 참조하세요.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

백 엔드 풀에 인스턴스가 2개 이상 포함되어 있는지 확인합니다.

백 엔드에 인스턴스가 2개 이상 포함된 Load Balancer를 배포합니다. 단일 인스턴스로 인해 단일 실패 지점이 발생할 수 있습니다. 크기 조정을 위해 빌드하려면 부하 분산 장치를 Virtual Machine Scale Sets과 쌍으로 구성할 수 있습니다.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

시스템 효율성

프로덕션 워크로드에 아웃바운드 규칙 대신 NAT Gateway 사용

아웃바운드 규칙은 백 엔드 풀의 각 가상 머신 인스턴스에 고정된 양의 SNAT 포트를 할당합니다. 이 할당 방법은 특히 고르지 않은 트래픽 패턴으로 인해 특정 가상 머신에서 더 많은 양의 나가는 연결을 보내는 경우 SNAT 포트가 소모될 수 있습니다. 프로덕션 워크로드의 경우 표준 Load Balancer 또는 모든 서브넷 배포를 Azure NAT Gateway와 결합하는 것이 좋습니다. NAT Gateway는 서브넷의 모든 가상 머신 인스턴스에 걸쳐 SNAT 포트를 동적으로 할당하고 결과적으로 SNAT 포트 소진 위험을 줄입니다.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

표준 Load Balancer SKU 사용

표준 SKU Load Balancer는 가용성 영역 및 영역 복원성을 지원하지만 기본 SKU는 지원하지 않습니다. 영역이 다운되더라도 영역 중복 표준 Load Balancer는 영향을 받지 않으며 지역 내 영역 오류가 발생해도 배포할 수 있습니다. 또한 표준 Load Balancer는 지역 간 부하 분산을 지원하여 애플리케이션이 지역 오류의 영향을 받지 않도록 합니다.

참고 항목

기본 부하 분산 장치에는 SLA(Service Level Agreement(서비스 수준 약정))가 없습니다.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

가용성 영역 지원

Azure 가용성 영역은 각 Azure 지역 내에서 물리적으로 분리된 세 개 이상의 데이터 센터 그룹입니다. 각 영역 내의 데이터 센터에는 독립적인 전원, 냉각, 네트워킹 인프라가 장착되어 있습니다. 가용성 영역은 로컬 영역이 실패한 경우에 한 영역이 영향을 받는 경우 나머지 두 영역에서 지역 서비스, 용량 및 고가용성을 지원하도록 설계되었습니다.

오류는 소프트웨어 및 하드웨어 오류에서 지진, 홍수 및 화재와 같은 이벤트에 이르기까지 다양합니다. Azure 서비스의 중복성과 논리적 격리로 인해 오류 허용성에 도달합니다. Azure의 가용성 영역에 대한 자세한 내용은 지역 및 가용성 영역을 참조하세요.

Azure 가용성 영역 지원 서비스는 적절한 수준의 복원력과 유연성을 제공하도록 설계되었습니다. 두 가지 방법으로 구성할 수 있습니다. 영역 간 자동 복제를 사용하는 영역 중복 또는 특정 영역에 고정된 인스턴스를 사용하는 영역일 수 있습니다. 이러한 방식을 결합할 수도 있습니다. 영역 및 영역 중복 아키텍처에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.

Azure Load Balancer는 가용성 영역 시나리오를 지원합니다. 표준 Load Balancer를 사용하여 리소스를 영역에 따라 정렬하고 영역에 배포하여 시나리오 전체에서 가용성을 높일 수 있습니다. 이러한 개념과 기본 시나리오 디자인 지침을 이해하려면 이 문서를 검토하세요.

영역 중복성을 사용하여 Load Balancer를 배포하는 것이 권장되지만 Load Balancer는 영역 중복, 영역 또는 비 영역일 수 있습니다. 부하 분산 장치의 가용성 영역 선택은 프런트 엔드 IP의 영역 선택과 동일합니다. 공용 부하 분산 장치의 경우 부하 분산 장치의 프런트 엔드에 있는 공용 IP가 영역 중복인 경우 부하 분산 장치도 영역 중복입니다. 부하 분산 장치의 프런트 엔드에 있는 공용 IP가 영역인 경우 부하 분산 장치도 동일한 영역으로 지정됩니다. 부하 분산 장치에 대한 영역 관련 속성을 구성하려면 필요한 적절한 유형의 프런트 엔드를 선택합니다.

참고 항목

각 영역에 대한 부하 분산 장치가 필요하지는 않고, 대신 해당 백 엔드 풀에 연결된 프런트 엔드(영역 또는 영역 중복)가 여럿 있는 단일 부하 분산 장치가 그 용도로 사용됩니다.

필수 조건

Load Balancer로 가용성 영역을 사용하려면 가용성 영역을 지원하는 지역에 Load Balancer를 만들어야 합니다. 가용성 영역을 지원하는 지역을 확인하려면 지원되는 지역 목록을 참조하세요.
부하 분산 장치에 표준 SKU를 사용하고 가용성 영역 지원에 공용 IP를 사용합니다.
기본 SKU 형식은 지원되지 않습니다.
리소스를 만들려면 네트워크 기여자 역할 이상이 필요합니다.

제한 사항

영역을 만든 후에는 리소스에 대해 변경, 업데이트 또는 만들 수 없습니다.
리소스는 생성 후 영역에서 영역 중복으로 또는 그 반대로 업데이트할 수 없습니다.

영역 중복 부하 분산 장치

가용성 영역 있는 지역에서 표준 Load Balancer 단일 IP 주소에서 제공하는 트래픽과 영역이 중복될 수 있습니다. 단일 프런트 엔드 IP 주소는 영역에서 오류가 발생해도 계속 유지됩니다. 프런트 엔드 IP는 영역에 관계없이 영향을 받지 않은 모든 백 엔드 풀 구성원에 도달하는 데 사용할 수 있습니다. 최대 하나의 가용성 영역이 실패할 수 있으며 해당 지역의 나머지 영역이 정상으로 유지되는 한 데이터 경로는 유지됩니다.

프런트 엔드의 IP 주소는 여러 가용성 영역의 여러 독립 인프라 배포를 통해 동시에 처리됩니다. 모든 다시 시도 또는 다시 설정은 영역 실패의 영향을 받지 않는 다른 영역에서 성공합니다.

Figure depicts a zone-redundant standard load balancer directing traffic in three different zones to three different subnets in a zone redundant configuration.

참고 항목

VM 1, 2, 3은 동일한 서브넷에 속할 수 있으며 다이어그램 제안과 같이 반드시 별도의 영역에 있을 필요는 없습니다.

부하 분산 장치의 백 엔드 풀에 있는 구성원은 일반적으로 단일 영역(예: 영역 가상 머신)에 연결됩니다. 프로덕션 워크로드에 대한 일반적인 디자인은 여러 영역 리소스를 갖는 것입니다. 예를 들어 영역 중복 프런트 엔드가 있는 부하 분산 장치의 백엔드에 영역 1, 2, 3의 가상 머신을 배치하면 이 디자인 원칙을 충족합니다.

영역 부하 분산 장치

단일 영역에서 사용 가능하도록 보장되는 프런트 엔드, 즉 영역 프런트 엔드를 선택할 수 있습니다. 이 시나리오에서는 지역의 단일 영역이 모든 인바운드 또는 아웃바운드 흐름을 처리합니다. 프런트 엔드는 영역의 상태와 수명을 공유합니다. 데이터 경로는 보장된 영역 이외의 영역에서 오류가 발생해도 영향을 받지 않습니다. 영역 프런트 엔드를 사용하여 가용성 영역별 IP 주소를 공개할 수 있습니다.

또한 각 영역 내에서 부하가 분산된 엔드포인트에 대해 영역 프런트 엔드를 직접 사용할 수 있습니다. 이 구성을 통해 부하 분산된 영역별 엔드포인트를 공개하여 각 영역을 개별적으로 모니터링할 수도 있습니다. 공용 엔드포인트의 경우 Traffic Manager와 같은 DNS 부하 분산 제품과 통합하고 단일 DNS 이름을 사용할 수 있습니다.

Figure depicts three zonal standard load balancers each directing traffic in a zone to three different subnets in a zonal configuration.

공용 부하 분산 장치 프런트 엔드의 경우 공용 IP에 영역 매개 변수를 추가합니다. 이 공용 IP는 해당 규칙에서 사용하는 프런트 엔드 IP 구성에서 참조됩니다.

내부 부하 분산 장치 프런트 엔드의 경우 내부 부하 분산 장치 프런트 엔드 IP 구성에 zones 매개 변수를 추가합니다. 영역 프런트 엔드는 서브넷의 IP 주소를 특정 영역에 대해 보장합니다.

비 영역 부하 분산 장치

Load Balancer는 "no-zone" 프런트 엔드를 사용하여 비영역 구성에서 만들 수도 있습니다. 이러한 시나리오에서 공용 부하 분산 장치는 공용 IP 또는 공용 IP 접두사를 사용하고 내부 부하 분산 장치는 개인 IP를 사용합니다. 이 옵션은 중복성을 보장하지 않습니다.

참고 항목

기본 SKU에서 표준 SKU로 업그레이드된 모든 공용 IP 주소는 "영역 없음" 유형이 됩니다. Azure Portal에서 공용 IP 주소를 업그레이드하는 방법을 알아보세요.

SLA 개선 사항

가용성 영역은 물리적으로 분리되어 있고 고유한 전원, 네트워크 및 냉각을 제공하기 때문에 SLA(서비스 수준 계약)가 증가할 수 있습니다. 자세한 내용은 온라인 서비스에 대한 SLA(서비스 수준 계약)을 참조하세요.

가용성 영역을 사용하도록 설정된 리소스 만들기

Load Balancer를 사용하여 한 영역 내에서 또는 여러 영역에 걸쳐 VM의 부하 분산을 수행하는 방법을 알아보려면 빠른 시작: VM 부하 분산을 위한 공용 부하 분산 장치 만들기를 참조하세요.

참고 항목

영역을 만든 후에는 리소스에 대해 변경, 업데이트 또는 만들 수 없습니다.
리소스는 생성 후 영역에서 영역 중복으로 또는 그 반대로 업데이트할 수 없습니다.

내결함성

가상 머신은 클러스터의 다른 서버로 장애 조치할 수 있으며, 새 서버에서 VM의 운영 체제가 다시 시작됩니다. 재해 복구를 위한 장애 조치 프로세스, 복구 계획에서 가상 머신 수집 및 재해 복구 훈련을 실행하여 내결함성 솔루션이 성공하도록 해야 합니다.

자세한 내용은 사이트 복구 프로세스를 참조하세요.

영역 다운 환경

영역 중복은 비충돌 데이터 평면 또는 컨트롤 플레인을 의미하지 않습니다. 영역 중복 흐름은 모든 영역을 사용할 수 있으며 사용자 흐름은 지역의 모든 정상 영역을 사용합니다. 영역 실패 시 정상 영역을 사용하는 트래픽 흐름은 영향을 받지 않습니다.

영역 실패 시 영역을 사용하는 트래픽 흐름은 영향을 받을 수 있지만 애플리케이션은 복구할 수 있습니다. Azure가 영역 실패를 중심으로 수렴된 경우 트래픽은 다시 전송 시 지역 내의 정상 영역에서 계속됩니다.

실패 시나리오에 대한 애플리케이션의 복원력을 개선하기 위한 Azure 클라우드 디자인 패턴을 검토합니다.

여러 프런트 엔드

여러 프런트 엔드를 사용하면 둘 이상의 포트 및/또는 IP 주소에서 트래픽을 부하 분산할 수 있습니다. 아키텍처를 디자인할 때 영역 중복이 여러 프런트 엔드와 상호 작용하는 방식을 고려해야 합니다. 모든 프런트엔드가 실패에 대한 복원력을 항상 갖도록 하는 것이 목표라면 프런트 엔드로 할당된 모든 IP 주소는 영역 중복이어야 합니다. 프런트 엔드 집합이 단일 영역과 연결되도록 의도된 경우 해당 집합의 모든 IP 주소는 해당 특정 영역과 연결되어야 합니다. 각 영역에 대한 부하 분산 장치가 필요하지 않습니다. 대신 각 영역 프런트 엔드 또는 영역 프런트 엔드 집합을 해당 특정 가용성 영역의 일부인 백 엔드 풀의 가상 머신과 연결할 수 있습니다.

안전한 배포 기술

실패 시나리오에 대한 애플리케이션의 복원력을 개선하기 위한 Azure 클라우드 디자인 패턴을 검토합니다.

가용성 영역 지원으로 마이그레이션

지역이 확장되어 가용성 영역을 갖게 되는 경우, 기존 IP는 부하 분산 장치 프런트 엔드에 사용되는 IP와 같이 비영역으로 유지됩니다. 아키텍처가 새 영역을 활용할 수 있도록 하려면 새 프런트 엔드 IP를 만드는 것이 좋습니다. 일단 만들어지면 기존의 비 영역 프런트 엔드를 새로운 영역 중복 프런트 엔드로 바꿀 수 있습니다. VM을 가용성 영역 지원으로 마이그레이션하는 방법을 알아보려면 가용성 영역 지원으로 Load Balancer 마이그레이션을 참조하세요.

지역 간 재해 복구 및 비즈니스 연속성

DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.

DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 자신의 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.

Azure 표준 Load Balancer는 다음과 같은 지역 중복 고가용성 시나리오를 가능하게 하는 지역 간 부하 분산을 지원합니다.

여러 지역에서 발생하여 들어오는 트래픽.
다음으로 최적인 지역 배포로의 즉각적인 전역 장애 조치(failover).
매우 낮은 대기 시간으로 가장 가까운 Azure 지역에 지역 간 로드 분산.
단일 엔드포인트 뒤에서의 스케일 업/스케일 다운 기능.
정적 애니캐스트 글로벌 IP 주소
클라이언트 IP 유지
학습 곡선 없이 기존 부하 분산 장치 솔루션에 빌드

지역 간 부하 분산 장치의 프런트 엔드 IP 구성은 정적이며 대부분의 Azure 지역에서 보급됩니다.

Diagram of cross-region load balancer.

참고 항목

지역 간 부하 분산 장치에 대한 부하 분산 규칙의 백 엔드 포트는 지역 표준 부하 분산 장치에 대한 부하 분산 규칙/인바운드 Nat 규칙의 프런트 엔드 포트와 일치해야 합니다.

다중 지역 지리의 재해 복구

지역 중복

지역 간 부하 분산 장치를 기존 지역 부하 분산 장치에 원활하게 연결하여 지역 중복성을 구성합니다.

한 지역이 실패하는 경우 트래픽이 다음의 가장 가까운 정상적인 지역 부하 분산 장치로 라우팅됩니다.

지역 간 부하 분산 장치의 상태 프로브는 5초마다 각 지역 부하 분산 장치의 가용성에 대한 정보를 수집합니다. 한 지역 부하 분산 장치에서 가용성이 0으로 떨어지면 지역 간 부하 분산 장치에서 실패를 검색합니다. 그러면 해당 지역 부하 분산 장치는 순환에서 제외됩니다.

Diagram of global region traffic view.

매우 낮은 대기 시간

지리적 근접 부하 분산 알고리즘은 사용자 및 지역 배포의 지리적 위치를 기반으로 합니다.

클라이언트에서 시작된 트래픽은 가장 가까운 참여 지역에 도달한 다음, Microsoft 전역 네트워크 백본을 통해 이동하여 가장 가까운 지역 배포에 도착합니다.

예를 들어 다음 Azure 지역에 표준 부하 분산 장치가 포함된 지역 간 부하 분산 장치가 있습니다.

미국 서부
북유럽

시애틀에서 흐름이 시작되면 트래픽이 미국 서부에 들어갑니다. 이 지역은 시애틀에서 가장 가까운 참여 지역입니다. 트래픽은 가장 가까운 지역인 미국 서부의 부하 분산 장치로 라우팅됩니다.

Azure 지역 간 부하 분산 장치는 라우팅 의사 결정을 위해 지역 근접 부하 분산 알고리즘을 사용합니다.

지역 부하 분산 장치에 구성된 부하 배포 모드는 지역 근접을 위해 여러 지역 부하 분산 장치가 사용되는 경우 최종 라우팅 결정을 내리는 데 사용됩니다.

자세한 내용은 Azure Load Balancer의 배포 모드 구성을 참조하세요.

송신 트래픽은 지역 부하 분산 장치에 설정된 라우팅 기본 설정을 따릅니다.

단일 엔드포인트 뒤에서 확장/축소할 수 있음

지역 간 부하 분산 장치의 전역 엔드포인트를 고객에게 노출하는 경우 전역 엔드포인트 뒤에서 지역 배포를 중단 없이 추가하거나 제거할 수 있습니다.

정적 애니캐스트 글로벌 IP 주소

지역 간 부하 분산 장치에는 IP 주소가 동일하게 유지되는 고정 공용 IP가 제공됩니다. 고정 IP에 대해 자세히 알아보려면 여기를 참조하세요.

클라이언트 IP 유지

지역 간 부하 분산 장치는 레이어-4 통과 네트워크 부하 분산 장치입니다. 이 통과는 패킷의 원래 IP를 유지합니다. 원래 IP는 가상 머신에서 실행되는 코드에 사용할 수 있습니다. 이러한 유지는 IP 주소와 관련된 논리를 적용할 수 있게 해 줍니다.

부동 IP

부동 IP는 전역 IP 수준 및 지역 IP 수준에서 구성할 수 있습니다. 자세한 내용은 Azure Load Balancer의 다중 프런트 엔드를 참조하세요.

Azure 지역 간 Load Balancer에서 구성된 부동 IP는 백 엔드 지역 부하 분산 장치의 부동 IP 구성과 독립적으로 작동한다는 점에 유의해야 합니다. 지역 간 부하 분산 장치에서 부동 IP를 사용하는 경우 적절한 루프백 인터페이스를 백 엔드 VM에 추가해야 합니다.

상태 프로브

Azure 지역 간 부하 분산 장치는 트래픽을 분산할 위치를 결정할 때 백 엔드 지역 부하 분산 장치의 상태를 활용합니다. 지역 간 부하 분산 장치에 의한 상태 검사는 사용자가 지역 부하 분산 장치에 상태 프로브를 설정한 경우 5초마다 자동으로 수행됩니다.

기존 Azure Load Balancer에 지역 간 솔루션 빌드

지역 간 부하 분산 장치의 백 엔드 풀에는 지역 부하 분산 장치가 하나 이상 포함되어 있습니다.

가용성이 높은 지역 간 배포를 위해 기존 부하 분산 배포를 지역 간 부하 분산 장치에 추가하세요.

홈 지역은 전역 계층의 지역 간 부하 분산 장치 또는 공용 IP 주소가 배포되는 위치입니다. 이 지역은 트래픽이 라우팅되는 방식에 영향을 주지 않습니다. 홈 지역이 다운되는 경우 트래픽 흐름은 영향을 받지 않습니다.

홈 지역

미국 중부
동아시아
미국 동부 2
북유럽
동남 아시아
영국 남부
US Gov 버지니아
서유럽
미국 서부

참고 항목

나열된 홈 지역 중 하나의 글로벌 계층에서만 지역 간 부하 분산 장치 또는 공용 IP만 배포할 수 있습니다.

참여 지역은 부하 분산 장치의 글로벌 공용 IP가 보급되는 지역입니다.

사용자가 시작한 트래픽은 Microsoft 코어 네트워크를 통해 가장 가까운 참여 지역으로 이동합니다.

지역 간 부하 분산 장치는 해당 지역 부하 분산 장치로 트래픽을 라우팅합니다.

Diagram of multiple region global traffic.

참여 지역

오스트레일리아 동부
오스트레일리아 남동부
인도 중부
미국 중부
동아시아
미국 동부
미국 동부 2
일본 동부
미국 중북부
북유럽
미국 중남부
동남아시아
영국 남부
US DoD 중부
US DoD 동부
US Gov 애리조나
US Gov 텍사스
US Gov 버지니아
미국 중서부
서유럽
미국 서부
미국 서부 2

참고 항목

백 엔드 지역 부하 분산 장치는 공개적으로 사용 가능한 모든 Azure 지역에 배포할 수 있으며 참여 지역에만 국한되지 않습니다.

제한 사항

지역 간 프런트 엔드 IP 구성은 퍼블릭으로만 사용됩니다. 내부 프런트 엔드는 현재 지원되지 않습니다.
프라이빗 또는 내부 부하 분산 장치는 지역 간 부하 분산 장치의 백 엔드 풀에 추가할 수 없습니다.
NAT64 변환은 현재 지원되지 않습니다. 프런트 엔드 및 백 엔드 IP는 동일한 유형(v4 또는 v6)이어야 합니다.
IPv6에 대한 지역 간 Load Balancer에서는 UDP 트래픽이 지원되지 않습니다.
지역 간 Load Balancer에서는 포트 3의 UDP 트래픽이 지원되지 않습니다.
지역 간 Load Balancer에서는 아웃바운드 규칙이 지원되지 않습니다. 아웃바운드 연결의 경우 지역 부하 분산 장치의 아웃바운드 규칙 또는 NAT 게이트웨이를 활용합니다.

가격 및 SLA

지역 간 부하 분산 장치는 표준 부하 분산 장치의 SLA를 공유합니다.

다음 단계

Azure의 안정성
지역 간 부하 분산 장치를 만드는 방법은 자습서: Azure Portal을 사용하여 지역 간 부하 분산 장치 만들기를 참조하세요.
지역 간 부하 분산 장치에 대해 자세히 알아보세요.
Azure Load Balancer에 대해 자세히 알아보세요.

Load Balancer의 안정성

안정성 권장 사항

안정성 권장 사항 우선 순위 매트릭스

안정성 권장 사항 요약

가용성

표준 Load Balancer가 영역 중복인지 확인합니다.

백 엔드 풀에 인스턴스가 2개 이상 포함되어 있는지 확인합니다.

시스템 효율성

프로덕션 워크로드에 아웃바운드 규칙 대신 NAT Gateway 사용

표준 Load Balancer SKU 사용

가용성 영역 지원

필수 조건

제한 사항

영역 중복 부하 분산 장치

영역 부하 분산 장치

비 영역 부하 분산 장치

SLA 개선 사항

가용성 영역을 사용하도록 설정된 리소스 만들기

내결함성

영역 다운 환경

여러 프런트 엔드

안전한 배포 기술

가용성 영역 지원으로 마이그레이션

지역 간 재해 복구 및 비즈니스 연속성

다중 지역 지리의 재해 복구

지역 중복

매우 낮은 대기 시간

단일 엔드포인트 뒤에서 확장/축소할 수 있음

정적 애니캐스트 글로벌 IP 주소

클라이언트 IP 유지

부동 IP

상태 프로브

기존 Azure Load Balancer에 지역 간 솔루션 빌드

홈 지역

참여 지역

제한 사항

가격 및 SLA

다음 단계

추가 리소스