Load Balancer의 안정성

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

가용성 영역 지원

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.

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 주소는 여러 가용성 영역의 여러 독립 인프라 배포를 통해 동시에 처리됩니다. 모든 다시 시도 또는 다시 설정은 영역 실패의 영향을 받지 않는 다른 영역에서 성공합니다.

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

영역 부하 분산 장치

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

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

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

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

비 영역 부하 분산 장치

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

SLA 개선 사항

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

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

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

내결함성

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

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

영역 다운 환경

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

영역 실패 시 영역을 사용하는 트래픽 흐름은 영향을 받을 수 있지만 애플리케이션은 복구할 수 있습니다. 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 지역에서 보급됩니다.

다중 지역 지리의 재해 복구

지역 중복

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

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

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

매우 낮은 대기 시간

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

클라이언트에서 시작된 트래픽은 가장 가까운 참여 지역에 도달한 다음, 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가 보급되는 지역입니다.

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

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

참여 지역

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

제한 사항

• 지역 간 프런트 엔드 IP 구성은 퍼블릭으로만 사용됩니다. 내부 프런트 엔드는 현재 지원되지 않습니다.

• 프라이빗 또는 내부 부하 분산 장치는 지역 간 부하 분산 장치의 백 엔드 풀에 추가할 수 없습니다.

• NAT64 변환은 현재 지원되지 않습니다. 프런트 엔드 및 백 엔드 IP는 동일한 유형(v4 또는 v6)이어야 합니다.

• IPv6에 대한 지역 간 Load Balancer에서는 UDP 트래픽이 지원되지 않습니다.

• 지역 간 Load Balancer에서는 포트 3의 UDP 트래픽이 지원되지 않습니다.

• 지역 간 Load Balancer에서는 아웃바운드 규칙이 지원되지 않습니다. 아웃바운드 연결의 경우 지역 부하 분산 장치의 아웃바운드 규칙 또는 NAT 게이트웨이를 활용합니다.

가격 및 SLA

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

다음 단계

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