다음을 통해 공유

Azure Load Balancer에 대한 Well-Architected Framework 관점

  • 아티클

부하 분산 프로세스는 네트워크 트래픽을 둘 이상의 백 엔드 서버 그룹에 분산합니다. Azure Load Balancer는 UDP(사용자 데이터그램 프로토콜) 및 TCP(Transmission Control Protocol)에 대해 계층 4 부하 분산을 수행하는 Azure 네이티브 서비스입니다. Load Balancer는 지역 및 글로벌 배포에 짧은 대기 시간 및 고가용성을 제공하는 데 도움이 됩니다.

이 문서에서는 설계자로서 Azure에서 부하 분산 옵션을 검토하고 워크로드에 대해 Load Balancer를 선택했다고 가정합니다. 이 문서의 지침은 Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.

중요하다

이 가이드를 사용하는 방법

각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록 있습니다.

또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 Load Balancer 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.

주요 권장 사항을 보여 주는 기본 아키텍처:
Azure Virtual Machines 기준 아키텍처.

기술 범위

이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.

  • 부하 분산기

이 지침에서는 표준 Load Balancer SKU에 중점을 둡니다. 기본 Load Balancer 및 게이트웨이 Load Balancer SKU는 이 문서의 범위에서 제외됩니다.

트래픽을 지시하는 부하 분산 장치를 보여 주는 다이어그램

메모

HTTP 애플리케이션의 경우 Load Balancer 대신 Azure Application Gateway 또는 Azure Front Door를 고려합니다. 이러한 대안은 부하 분산을 관리하고 WAF(웹 애플리케이션 방화벽) 및 TLS(전송 계층 보안) 종료와 같은 기능을 제공합니다.

자세한 내용은 다음을 참조하세요.

  • Azure Front Door 대한Well-Architected Framework 관점
  • Azure Application Gateway 대한Well-Architected Framework 관점

신뢰도

안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을지속적인 기능을 제공하는 것입니다.

신뢰성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 상위 디자인 전략을 제공합니다.

디자인 검사 목록

안정성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. VM(가상 머신)의 계층 및 기능을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • Microsoft 지원 보증의 영향을 이해합니다. 아키텍처의 다른 구성 요소 외에도 SLA(서비스 수준 계약)를 워크로드의 안정성 목표에 적용합니다. 다음 중요 사항을 주의하세요.

    • 부하 분산된 엔드포인트가 전체 1분 동안 모든 정상 백 엔드 서버에 연결할 수 없는 경우 해당 분은 사용할 수 없는 것으로 간주됩니다. 그러나 다른 요청이 실패하더라도 동일한 분 내에 하나 이상의 요청이 성공하는 경우 해당 분은 가동 중지 시간으로 간주되지 않습니다.

    • 가동 중지 시간에는 SNAT(원본 네트워크 주소 변환) 포트 고갈로 인한 시간(분)이 포함되지 않습니다. 예상되는 연결 수를 처리하고 그에 따라 포트를 열도록 워크로드를 구성해야 합니다.

  • 워크로드 아키텍처에서 영역 중복을 지원합니다. 표준 Load Balancer SKU를 사용하는 것이 좋습니다. 가용성 영역 지원, 여러 지역의 트래픽 분산 및 백 엔드 풀에서 더 많은 인스턴스를 처리하는 기능과 같은 안정성 기능이 있습니다. 이러한 기능은 영역, 지역 및 개별 VM 인스턴스 수준에서 오류를 견딜 수 있도록 도와줍니다. 최대 백 엔드 풀 크기와 같은 제한 사항에 유의하세요.

    메모

    Load Balancer에서는 부하 분산된 VM 수를 관리하지만 Load Balancer 인스턴스 수는 관리하지 않습니다. 부하 분산 장치 인스턴스를 영역 중복으로 구성하거나 워크로드가 단일 영역에 VM을 배치해야 하는 경우 영역에 고정할 수 있습니다. 프런트 엔드 IP 주소의 영역 또는 다중 영역 구성은 부하 분산 중복성을 나타냅니다.

  • 워크로드 아키텍처에서 지역 중복성을 지원합니다. Load Balancer를 전역 부하 분산 장치로 구성할 수 있습니다. 이 설정에서 Load Balancer에는 여러 지역으로 브로드캐스트하는 고정 애니캐스트 공용 IP 주소가 있습니다. 클라이언트가 이 IP 주소를 요청하면 해당 요청은 가장 가까운 서버 인스턴스로 이동합니다. Load Balancer는 트래픽을 효율적으로 분산하기 위해 지역 부하 분산 장치에 연결합니다.

  • 네트워킹 스택의 변경 내용을 평가하여 안정적인 크기 조정을 지원합니다. 자동 크기 조정 규칙을 사용하여 백 엔드 풀을 확장하는 것이 좋습니다. 아웃바운드 트래픽에 대한 잠재적인 SNAT 포트 소모에 유의하세요. 이 문제를 해결하려면 더 쉬운 구성을 위해 Azure NAT Gateway를 사용하지만 가용성 영역 중복성이 부족하다는 것을 이해합니다. 또는 부하 분산 장치를 사용하여 영역 중복성을 추가합니다. 자세한 내용은 아웃바운드 연결참조하세요.

  • 잠재적인 오류를 완화합니다. 오류 모드 분석을 수행하고 완화를 식별합니다. 다음 표에서는 오류 유형 및 오류를 완화하는 방법을 보여 줍니다.

    실패 완화
    트래픽은 비정상 애플리케이션 인스턴스로 라우팅됩니다. 워크로드 인스턴스 상태를 모니터링합니다. 워크로드 종속성에 대한 검사를 포함하는 HTTP 상태 프로브를 구현합니다.
    트래픽은 중단이 있는 지역으로 라우팅됩니다. 다른 지역에 추가 인스턴스를 배포합니다. 전역 부하 분산 장치를 추가하여 트래픽을 새 지역으로 리디렉션합니다.
    워크로드의 사용자 기반은 새 지역의 사용자를 지원하도록 확장되었으며 대기 시간이 높습니다. 이제 애플리케이션에서 많은 시간 제한 및 오류가 발생합니다. 새 지역에 추가 인스턴스를 배포하고 서비스 구성에 추가합니다. 글로벌 부하 분산 장치인 Azure Load Balancer는 트래픽을 사용자에게 더 가깝게 라우팅합니다.

  • 트래픽을 정상 인스턴스로 라우팅합니다. 상태 프로브에 HTTP 또는 TCP를 사용할 수 있습니다. 더 풍부한 상태 응답을 제공하려면 비 HTTP 앱의 경우에도 상태 검사를 위한 HTTP 엔드포인트를 만드는 것이 좋습니다. 이 방법은 종속성 및 데이터베이스를 확인하는 데 특히 유용합니다. HTTP 프로브가 없으면 부하 분산 장치는 VM 상태를 정확하게 반영하지 않을 수 있는 TCP 연결을 사용합니다.

    Load Balancer에서 상태 프로브를 구성할 수 있습니다. 자세한 내용은 상태 프로브에 대한디자인 지침을 참조하세요.

권장 사항

추천 이익
Standard Load Balancer SKU를 선택합니다.
자세한 내용은 SKU 비교참조하세요.		 이 SKU는 가용성 영역 및 다중Region 부하 분산과 같은 안정성 기능을 지원합니다.
부하 분산을 사용하도록 프런트 엔드 IP 주소를 백 엔드 서버의 IP 주소에 매핑하도록 규칙을 구성합니다.

백 엔드 주소 풀에는 중복성을 위해 부하를 분산하기 위해 두 개 이상의 백 엔드 엔드포인트가 있어야 합니다.		 규칙은 부하 분산 알고리즘의 핵심입니다. 이 구성이 없으면 배포 모드가 비활성화됩니다.
상태 프로브구성합니다.

- 검색 간격 및 임계값을 설정합니다. 오류를 감지할 수 있는 속도와 엔드포인트에 대한 요청 수 간의 절충을 고려합니다.
- 모든 인스턴스에 비정상 상태가 있는 경우 인스턴스에 트래픽을 보낼지 여부를 평가합니다. 이 구성을 사용하여 정상적인 성능 저하 환경을 구현할 수 있습니다. 자세한 내용은 AllProbedUp참조하세요.		 정상 백 엔드 풀 인스턴스만 새 연결을 받습니다. 이 구성은 비정상 인스턴스에서 트래픽을 라우팅하므로 고가용성 및 안정성을 유지하는 데 도움이 됩니다.
프라이빗 및 공용 IP 주소를 영역 중복성을 가능하게 하도록 구성합니다 . IP 주소는 Load Balancer의 영역 중복성을 결정합니다. 영역 중복성은 워크로드가 영역 오류를 견딜 수 있도록 도와줍니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.

안전

보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보증을 제공하는 것입니다.

보안 디자인 원칙은 Load Balancer의 기술 설계에 접근 방식을 활용해 그러한 목표를 달성하기 위한 고수준 디자인 전략을 제공합니다.

디자인 검사 목록

보안 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 상태를 개선합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • 보안 기준을 검토합니다. Azure Load Balancer에서 부하 분산된 애플리케이션의 보안 상태를 향상하려면 Load Balancer 대한보안 기준을 검토합니다.

  • 백 엔드 서버를 보호합니다. 직접 인터넷에 노출되지 않는 가상 네트워크에 리소스를 배포합니다. 부하 분산 장치를 사용하여 가상 네트워크를 전면에 배치합니다. 이상적으로 부하 분산 장치에는 방화벽 기능이 있어야 합니다. HTTP 애플리케이션의 경우 Application Gateway 또는 Azure Front Door를 고려합니다. HTTP가 아닌 애플리케이션의 경우 개인 IP 주소(내부 부하 분산 장치)가 있는 Load Balancer를 고려하고 보안을 강화하려면 Azure Firewall을 통해 트래픽을 라우팅합니다. 자세한 내용은 내부 부하 분산 장치참조하세요.

    Load Balancer를 역방향 프록시로 사용할 수도 있습니다. 이 경우, 부하 분산 장치는 리소스를 노출시키면서 IP 주소를 마스킹하기 위해 SNAT 기능이 포함된 공용 IP 주소를 사용합니다.

    메모

    백 엔드 서버로 트래픽을 필터링하려면 프런트 엔드 및 백 엔드가 포함된 서브넷에서 NSG(네트워크 보안 그룹)를 사용합니다. Load Balancer 서비스에 직접 NSG를 적용하지 마세요. NSG가 규칙을 적용할 때 부하 분산 장치가 아닌 원본 포트, 대상 포트 및 원래 컴퓨터와 대상 컴퓨터의 주소 범위를 고려합니다.

  • 프라이빗 연결을 위한 디자인입니다. Load Balancer는 Azure Private Link에서 작동합니다. 가상 네트워크에 애플리케이션 리소스를 분산하는 경우 다른 가상 네트워크의 리소스를 연결할 수 있습니다. 가상 네트워크 피어링을 사용하거나 내부 부하 분산 장치 앞에 Private Link를 배치합니다. Private Link 옵션은 공용 IP 주소 없이도 더 안전한 액세스를 제공합니다. 또한 피어링되지 않은 네트워크에서의 액세스를 제한합니다.

    역할 기반 액세스 제어 통해 프라이빗 링크에 권한을 부여하여 필요한 ID로만 액세스를 제한할 수 있습니다.

  • 네트워크 에지의 위협으로부터 애플리케이션을 보호합니다. Load Balancer를 진입점으로 사용하는 디자인의 경우 엔드포인트 수준에서 트래픽 검사를 구현합니다. 이 디자인에는 WAF와 같은 기본 제공 보안 기능이 없으므로 HTTP 애플리케이션을 보호하는 데 도움이 되는 추가 조치를 추가해야 합니다. 자세한 내용은 공용 부하 분산 장치참조하세요. 또한 분산 서비스 거부(DDoS) 공격으로부터 부하 분산 장치 엔드포인트를 보호해야 합니다.

  • 네트워크 트래픽을 암호화합니다. Load Balancer는 계층 4에서 작동하며 부하 분산 TCP 및 UDP 트래픽을 완벽하게 지원합니다. Load Balancer는 SSL(Secure Sockets Layer) 및 TLS 종료를 지원하지 않습니다. 애플리케이션 계층에서 HTTPS 부하 분산의 경우 Application Gateway를 사용합니다.

권장 사항

추천 이익
가상 네트워크의 개인 IP 주소로 프런트 엔드 IP 주소를 구성합니다. 이 방법을 사용하면 프런트 엔드 IP 주소와 가상 네트워크가 직접 인터넷 노출로부터 격리된 상태로 유지됩니다. 내부 부하 분산 장치는 인터넷에서 들어오는 트래픽을 허용할 수 없으므로 잠재적인 공격 벡터가 줄어듭니다.
Azure DDoS Protection을 사용하여 공용 부하 분산 장치를 보호합니다. DDoS Protection 계획은 엔드포인트의 위협 및 남용 징후를 모니터링하는 탐지 기능과 같은 고급 보호를 제공합니다.

비용 최적화

비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하면서 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.

비용 최적화 설계 원칙은 이러한 목표를 달성하고 로드 밸런서 및 그 환경과 관련된 기술 설계에서 필요 시에 절충안을 만들기 위한 고수준 설계 전략을 제공합니다.

디자인 검사 목록

투자 비용 최적화 을 위한 디자인 검토 체크리스트를 기반으로 디자인 전략을 시작하세요. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.

  • 비용 모델에 부하 분산 비용을 고려합니다. Load Balancer가 처리하는 데이터의 양과 인바운드 및 아웃바운드 부하 분산 규칙의 수와 같은 주요 요인을 고려합니다. 정확한 비용 추정을 위해 트래픽 로그를 사용하여 인바운드 및 아웃바운드 트래픽 요구 사항을 측정합니다.

  • 지출에 대한 컨트롤을 설정합니다. Load Balancer 비용을 기록하고 분석합니다. 비용을 효과적으로 관리하려면 Microsoft Cost Management 사용하여 예산을 만들고 경고를 구성합니다. 비용은 기록된 데이터의 양과 스토리지 기간에 따라 누적될 수 있으며 이는 대역폭 및 스토리지 비용에 영향을 줍니다.

  • 사용하지 않는 리소스를 제거합니다. 사용되지 않는 부하 분산 장치 인스턴스를 식별하고 제거합니다. 로그를 분석하여 사용량을 평가합니다. 백 엔드 VM과 연결되지 않은 부하 분산 장치 인스턴스를 삭제합니다. 트래픽 로그를 검사하여 사용되지 않은 리소스를 찾습니다.

  • 흐름 비용을 최적화합니다. 효율적인 프로토콜 및 데이터 압축을 사용하여 트래픽 흐름의 부하를 줄이고 비용을 최소화합니다.

    비용을 최적화하기 위해 규칙 수를 줄일 수 있습니다. 각 엔드포인트에 대해 개별 IP 주소 및 포트를 사용하는 규칙을 사용하는 대신 백 엔드 풀에 연결하는 프런트 엔드의 포트 범위에 대한 규칙을 정의합니다.

    백 엔드 흐름에서 최적화를 구현합니다. 예를 들어 부하 분산 장치가 가로채는 여러 데이터베이스 쿼리는 쿼리당 비용을 증가시킬 수 있습니다. 이 추가 비용을 방지하려면 저장 프로시저를 구현하여 쿼리 시퀀스를 통합하는 것이 좋습니다.

  • 작업 비용을 평가합니다. 유지 관리, 크기 조정 및 규정 준수와 같은 리소스 비용 및 운영 비용을 고려합니다. 부하 분산 장치 규칙은 비용에 큰 영향을 줄 수 있습니다. 재무 및 관리 비용을 최적화하기 위한 규칙 수를 줄입니다.

권장 사항

추천 이익
Azure 가격 계산기를 사용하여 비용을 예측합니다. 예상 트래픽 사용량을 예상 비용 예측으로 변환할 수 있으므로 계획 및 예산을 더 쉽게 계획할 수 있습니다.
규칙 수를 평가하고 가능한 경우 줄입니다.

개별 IP 주소에 대한 여러 규칙을 정의하는 대신 하나의 규칙을 사용하여 포트 범위를 요약할 수 있는지 여부를 평가합니다.
예를 들어 인바운드 NAT 규칙 사용하여 IP 주소 및 포트를 개별 VM이 아닌 백 엔드 풀에 매핑할 수 있습니다.		 통합 규칙은 비용을 최적화하고 작업을 간소화합니다.

강화 또는 축소할 때 규칙을 변경하지 않고 백 엔드 풀에서 IP 주소를 추가하거나 제거할 수 있습니다.

운영 우수성

운영 우수성은 주로 개발 사례, 관찰 가능성 및 릴리스 관리대한 절차에 중점을 둡니다.

운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.

디자인 검사 목록

디자인 전략을 시작할 때 운영 우수성 을 위한 디자인 검토 검사 목록을 기반으로 하여 관찰 가능성, 테스트 및 배포와 관련된 Load Balancer의 프로세스를 정의하십시오.

  • 인프라를 코드로 사용합니다. 가상 네트워크, 네트워크 피어링, 프라이빗 엔드포인트 및 NSG와 같은 다른 네트워킹 구성 요소와 함께 Load Balancer를 배포하고 구성합니다. Microsoft.Network loadBalancers 리소스 종류 숙지하세요.

  • 허브 및 스포크 아키텍처에 계층화된 배포를 사용합니다. 허브는 스포크 네트워크에 배포된 워크로드보다 덜 자주 변경되므로 먼저 배포합니다. 워크로드를 사용하여 부하 분산 장치를 배포합니다. 여러 워크로드에서 단일 부하 분산 장치를 다시 사용하는 경우 허브에 배치하는 것이 좋습니다.

  • 포괄적인 네트워킹 모니터링 시스템을 구현합니다. 실시간 인사이트 및 경고에 대한 다차원 메트릭, 상태 이벤트 스키마를 기반으로 하는 리소스 로그 및 포괄적인 부하 분산 장치 모니터링을 위한 Azure Monitor Insights 대시보드와 같은 진단 기능을 강화합니다.

권장 사항

추천 이익
다차원 메트릭사용합니다.

과도한 경고를 최소화하려면 집계 유형을 Average설정하고 95개의% 임계값이 있는 5분 데이터 창을 사용합니다. 자세한 내용은 다차원 메트릭대한 경고 구성을 참조하세요. 인바운드 및 아웃바운드 가용성에 대한 예제를 검토합니다.		 포괄적인 실시간 인사이트 및 경고 구성은 문제의 향상된 검색을 제공하고 프롬프트 응답을 사용하도록 설정합니다.
리소스 로그를 캡처합니다. Load Balancer 항목은 상태 이벤트 스키마따라 달라집니다. 로그는 문제를 신속하게 식별하고 해결할 수 있도록 이벤트에 대한 자세한 레코드를 제공합니다.
Load Balancer 에 대해 기본 제공 Azure Monitor Insights대시보드를 사용합니다. 시각화는 잘 알고 있는 디자인 선택을 용이하게 하며 문제를 신속하게 식별, 진단 및 해결하는 데 도움이 됩니다.
유지 관리 작업 중에 관리 상태Down 설정하여 기존 연결을 방해하지 않고 백 엔드 인스턴스를 순환에서 제외합니다. 이 구성은 기존 연결이 정상적으로 종료되는 동안 새 연결이 백 엔드 인스턴스로 전달되지 않도록 하는 데 도움이 됩니다. 이 관리 상태 구성은 정기적인 유지 관리 또는 패치를 위해 부하 분산 회전에서 VM을 꺼낼 때 오버헤드 및 복잡성을 줄이는 데 도움이 됩니다.

백 엔드 인스턴스를 순환에서 제외하는 대체 옵션으로, NSG를 적용하여 Load Balancer 상태 프로브 또는 클라이언트의 IP 주소 및 포트에서 트래픽을 차단할 수 있습니다. 이 옵션은 복잡성을 증가합니다.

성능 효율성

성능 효율성은 용량을 관리하여 부하 증가하는 경우에도 사용자 환경을 유지 관리합니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.

성능 효율성 디자인 원칙은 예상 사용량에 대해 그러한 용량 목표를 달성하기 위한 고수준의 설계 전략을 제공합니다.

디자인 검사 목록

Load Balancer의 주요 성능 지표를 기반으로 하는 기준을 정의하기 위한 성능 효율성 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.

  • 네트워크 성능 대상을 확인합니다. 부하 분산 장치는 지원할 수 있는 트래픽에 제한이 없습니다. 그러나 성능 목표를 정의하고 용량을 계획할 때 네트워크 성능을 테스트해야 합니다.

    스트레스 테스트를 사용하여 워크로드의 대역폭 요구 사항을 이해합니다. 해당 테스트에 부하 분산 장치를 포함합니다. 여러 VM이 있는 단일 가상 머신 확장 집합으로 충분하지 않은 경우 동일한 부하 분산 장치를 사용하여 다른 확장 집합을 추가할 수 있습니다. VM이 요청을 충분히 빨리 받지 못하는 경우 부하 분산 장치 추가와 같은 네트워킹 구성 요소를 조정해야 할 수 있습니다. 그러나 부하 분산 장치를 변경하는 대신 디자인을 변경하고 부하를 더 잘 처리하도록 워크로드를 최적화하는 것이 좋습니다.

  • 크기 조정 전략을 설계할 때의 제한을 이해합니다. 성능 요구 사항을 충족하고 워크로드 크기를 조정하려면 백 엔드 풀에서 VM을 추가하거나 제거합니다. 표준 Load Balancer의 단일 백 엔드 풀은 최대 5,000개의 VM을 처리할 수 있습니다.

    Load Balancer는 처리량 제한을 적용하지 않습니다. 그러나 VM 및 가상 네트워크에 대한 처리량 제한은 여전히 적용됩니다. 자세한 내용은 VM 네트워크 대역폭 참조하세요.

  • 요청을 신속하게 처리합니다. 표준 Load Balancer에는 사용자에 대한 지리적 근접성을 기반으로 백 엔드 엔드포인트로 트래픽을 라우팅하는 계층이 있습니다.

    Load Balancer는 세션 지속성을 기반으로 부하 분산도 지원합니다. 이 기능을 사용하도록 설정하면 동일한 클라이언트의 요청이 이전 세션을 처리한 동일한 백 엔드 서버로 일관되게 전달됩니다.

  • 데이터를 수집하여 성능을 분석합니다. Load Balancer 다차원 메트릭 서비스의 성능을 분석할 수 있습니다. 성능 변경을 검색하도록 경고를 구성합니다. Azure Monitor Insights 대시보드 같은 도구를 사용하여 Load Balancer의 상태를 시각화합니다. 리소스 상태 기능이 상태를 모니터링하고 성능 문제 및 중단에 대한 정보를 유지해야 합니다.

  • 네트워크 트래픽을 최적화합니다. 별도의 단계에서 동일한 데이터를 여러 번 처리하지 마세요. 대신 필요한 모든 계산을 일괄 처리로 수행한 다음 데이터를 유지합니다. 이 방법은 대기 시간을 줄이고 네트워크 트래픽을 최소화하여 전반적인 성능을 향상시킵니다.

권장 사항

추천 이익
전역 사용자가 있는 경우 표준 로드 밸런서 에서 글로벌 계층을 선택합니다. 이 계층의 지리적 근접 배포 모드는 가장 가까운 지역의 엔드포인트에서 사용자 요청을 제공하므로 성능이 향상됩니다.
동일한 사용자의 요청이 동일한 백 엔드 서버로 전달되도록 할 때 세션 지속성 사용하도록 설정해야 하는지 여부를 평가합니다.

안정성 관점에서 이 방법은 권장하지 않습니다. 이 옵션을 사용하는 경우 애플리케이션은 사용자 세션을 방해하지 않고 정상적으로 복구해야 합니다.

또한 여러 백 엔드에 트래픽을 균등하게 분산하는 유연성을 제한하기 때문에 부하 분산 절충이 있습니다.		 세션 지속성은 특히 애플리케이션이 상태 정보를 로컬로 유지 관리하는 경우 사용자 세션에 대한 성능을 최적화하고 연속성을 유지할 수 있습니다. 그러나 장단 사항이 있습니다.
스케일 아웃하는 동안 애플리케이션이 완전히 초기화되고 요청을 처리할 준비가 될 때까지 프로브 다운 신호 보냅니다.

축소 중인 엔드포인트에서 새 연결에 대해 '프로브 다운' 신호를 보내십시오. 기존 연결에 대한 보류 중인 요청은 계속 처리됩니다.		 헬스 프로브는 스케일링 작업을 최적화하는 데 도움이 될 수 있습니다. 스케일 아웃 중에 애플리케이션이 들어오는 부하를 처리할 수 있도록 합니다. 규모 감축 작업 전에 진행 중인 작업을 방해하지 않고 인스턴스를 원활하게 축소할 수 있습니다.

Azure 정책

Azure는 Load Balancer 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 이전 권장 사항 중 일부는 Azure Policy를 통해 감사할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.

  • 기본 SKU 부하 분산 장치를 제외한 부하 분산 장치에는 프런트 엔드의 공용 IP 주소에 대해 복원력 기능이 활성화되어 있습니다.
  • 리소스 로그를 사용하여 리소스에서 발생하는 활동 및 이벤트를 추적하고 변경 내용에 대한 가시성과 인사이트를 제공할 수 있습니다.

포괄적인 거버넌스를 위해 Load Balancer 대한 Azure Policy 기본 제공 정의 및 트래픽 배포의 보안에 영향을 미칠 수 있는 기타 정책을 검토합니다.

Azure Advisor 권장 사항

Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다. Advisor 권장 사항은 Well-Architected Framework 핵심 요소와 일치합니다.

자세한 내용은 Azure Advisor권장 사항을 참조하세요.