개인 네트워크 커넥터 및 애플리케이션의 고가용성 및 부하 분산
이 문서에서는 트래픽 배포가 애플리케이션 프록시 배포에서 작동하는 방식을 설명합니다. 커넥터 성능 최적화에 대한 팁과 함께 사용자 및 커넥터 간에 트래픽이 분산되는 방식을 알아봅니다. 여러 백 엔드 서버 간 부하 분산에 대한 권장 사항과 함께 커넥터와 백 엔드 앱 서버 간에 트래픽이 흐르는 방식을 알아봅니다.
커넥터 간 트래픽 분산
커넥터는 고가용성을 위한 원칙에 따라 연결을 설정합니다. 트래픽이 커넥터 간에 균등하게 분산되며 세션 선호도가 없다는 보장은 없습니다. 그러나 사용량은 다르며 요청은 애플리케이션 프록시 서비스 인스턴스에 무작위로 보내집니다. 결과적으로 트래픽은 일반적으로 커넥터 간에 거의 균등하게 분산됩니다. 다이어그램 및 단계에서는 사용자와 커넥터 간에 연결을 설정하는 방법을 보여줍니다.
- 클라이언트 디바이스의 사용자가 애플리케이션 프록시를 통해 게시된 온-프레미스 애플리케이션에 액세스하려고 합니다.
- 요청은 요청을 수행해야 하는 애플리케이션 프록시 서비스 인스턴스를 확인하기 위해 Azure Load Balancer를 거칩니다. 해당 지역의 모든 트래픽에 대한 요청을 수락할 수 있는 수십 개의 인스턴스가 있습니다. 이 방법은 서비스 인스턴스 간에 트래픽을 균등하게 분산하는 데 유용합니다.
- 요청은 Service Bus로 전송됩니다.
- Service Bus는 사용 가능한 커넥터에 신호를 보냅니다. 그런 다음, 커넥터는 Service Bus에서 요청을 선택합니다.
- 2단계에서 요청은 다른 애플리케이션 프록시 서비스 인스턴스로 이동하므로 서로 다른 커넥터를 사용하여 연결을 만들 수 있습니다. 결과적으로 커넥터는 그룹 내에서 거의 균등하게 사용됩니다.
- 커넥터는 애플리케이션의 백 엔드 서버에 요청을 전달합니다. 그런 다음, 애플리케이션이 응답을 커넥터로 다시 보냅니다.
- 커넥터는 요청이 시작된 서비스 인스턴스에 대한 아웃바운드 연결을 열어 응답을 완료합니다. 그러면 이 연결이 즉시 닫힙니다. 기본적으로 각 커넥터는 200개의 동시 아웃바운드 연결로 제한됩니다.
- 그러면 응답이 서비스 인스턴스에서 클라이언트로 다시 전달됩니다.
- 동일한 연결의 후속 요청은 해당 단계를 반복합니다.
애플리케이션에는 종종 많은 리소스가 있으며, 애플리케이션이 로드될 때 여러 연결을 엽니다. 연결 각각은 서비스 인스턴스에 할당되는 단계를 진행합니다. 연결이 커넥터와 페어링되지 않은 경우, 사용 가능한 새 커넥터를 선택합니다.
커넥터의 고가용성에 대한 모범 사례
고가용성을 위해 트래픽이 커넥터 간에 분산되는 방식 때문에 항상 커넥터 그룹에 두 개 이상의 커넥터가 있어야 합니다. 커넥터 간에 추가 버퍼를 제공하기 위해 세 개의 커넥터가 선호됩니다. 필요한 커넥터의 올바른 수를 확인하려면 용량 계획 설명서를 따르세요.
단일 실패 지점을 방지하기 위해 다른 아웃바운드 연결에 커넥터를 배치합니다. 커넥터가 동일한 아웃바운드 연결을 사용하는 경우 연결에 대한 네트워크 문제가 해당 연결을 사용하는 모든 커넥터에 영향을 미칠 수 있습니다.
프로덕션 애플리케이션에 연결할 때 커넥터를 강제로 다시 시작하지 않도록 합니다. 이렇게 하면 커넥터 간 트래픽 분산에 부정적인 영향을 줄 수 있습니다. 커넥터를 다시 시작하면 더 많은 커넥터를 사용할 수 없게 되고 사용 가능한 나머지 커넥터에 강제로 연결됩니다. 결과적으로 초기에는 커넥터가 균등하게 사용되지 않습니다.
커넥터와 Azure 간의 아웃바운드 TLS(전송 계층 보안) 통신에 대한 모든 형태의 인라인 검사를 방지합니다. 이 유형의 인라인 검사를 수행하면 통신 흐름이 저하됩니다.
커넥터에 대해 자동 업데이트를 계속 실행해야 합니다. 개인 네트워크 커넥터 업데이터 서비스가 실행 중인 경우 커넥터가 자동으로 업데이트되고 업데이트된 최신 커넥터가 수신됩니다. 서버에 Connector Updater 서비스가 표시되지 않는 경우 업데이트를 받으려면 커넥터를 다시 설치해야 합니다.
커넥터와 백 엔드 애플리케이션 서버 간 트래픽 흐름
고가용성이 중요한 요소인 또 다른 주요 영역은 커넥터와 백 엔드 서버 간의 연결입니다. Microsoft Entra 애플리케이션 프록시를 통해 애플리케이션을 게시할 때 사용자에게서 애플리케이션으로 이동하는 트래픽은 다음 3가지 홉을 통과합니다.
- 사용자는 Azure에서 Microsoft Entra 애플리케이션 프록시 퍼블릭 엔드포인트에 연결합니다. 연결은 클라이언트의 원래 클라이언트 IP 주소(공용)와 애플리케이션 프록시 엔드포인트의 IP 주소 간에 설정됩니다.
- 개인 네트워크 커넥터는 애플리케이션 프록시 서비스에서 클라이언트의 HTTP 요청을 끌어옵니다.
- 개인 네트워크 커넥터에서 대상 애플리케이션에 연결 커넥터는 연결을 설정하기 위해 자체 IP 주소를 사용합니다.
X-Forwarded-For 헤더 필드 고려 사항
일부 상황(예: 감사, 부하 분산 등)에서는 외부 클라이언트의 원래 IP 주소를 온-프레미스 환경과 공유해야 합니다. 요구 사항을 해결하기 위해 Microsoft Entra 개인 네트워크 커넥터는 원래 클라이언트 IP 주소(공용)와 함께 X-Forwarded-For 헤더 필드를 HTTP 요청에 추가합니다. 그러면 적절한 네트워크 디바이스(부하 분산 장치, 방화벽)나 웹 서버 또는 백 엔드 애플리케이션에서 정보를 읽고 사용할 수 있습니다.
여러 애플리케이션 서버 간 부하 분산에 대한 모범 사례
부하 분산은 애플리케이션 프록시 애플리케이션에 할당된 커넥터 그룹에 둘 이상의 커넥터가 있는 경우에 중요합니다. 여러 서버에서 백 엔드 웹 애플리케이션을 실행하는 경우에도 부하 분산은 중요합니다.
시나리오 1: 백 엔드 애플리케이션에 세션 지속성이 필요 없음
가장 간단한 시나리오는 백 엔드 웹 애플리케이션에 세션의 공동 작업이 필요하지 않은 경우(세션 지속성)입니다. 백 엔드 애플리케이션 인스턴스는 서버 팜에서 사용자 요청을 처리합니다. 계층 4 부하 분산 장치를 사용하고 선호도 없이 구성할 수 있습니다. 일부 옵션에는 Microsoft Network Load Balancing 및 Azure Load Balancer 또는 다른 공급업체의 부하 분산 장치가 포함됩니다. 아니면 라운드 로빈 DNS(도메인 이름 시스템) 전략을 구성합니다.
시나리오 2: 백 엔드 애플리케이션에 세션 지속성 필요
이 시나리오에서 백 엔드 웹 애플리케이션을 사용하려면 인증된 세션 중에 세션 유지(세션 지속성)가 필요합니다. 백 엔드 애플리케이션 인스턴스는 사용자 요청을 처리합니다. 해당 요청은 서버 팜의 동일한 서버에서 실행됩니다. 이 시나리오는 클라이언트가 일반적으로 애플리케이션 프록시 서비스에 대해 여러 연결을 설정하기 때문에 좀 더 복잡할 수 있습니다. 여러 다른 연결에 대한 요청이 팜의 다른 커넥터 및 서버에 도달할 수 있습니다. 각 커넥터는 이 통신에 자체 IP 주소를 사용하므로 부하 분산 장치가 커넥터의 IP 주소를 기준으로 세션 연결을 보장할 수 없습니다. 원본 IP 선호도는 사용할 수 없습니다. 시나리오 2에 대한 몇 가지 옵션은 다음과 같습니다.
옵션 1: 세션 지속성은 부하 분산 장치에 의해 설정된 세션 쿠키를 기준으로 합니다. 백 엔드 서버 간에 부하를 균등하게 분산할 수 있으므로 이 옵션을 사용하는 것이 좋습니다. 이 옵션을 사용하려면 이 기능이 있으며 HTTP 트래픽을 처리하고 TLS 연결을 종료할 수 있는 계층 7 부하 분산 장치가 필요합니다. 다른 공급업체의 부하 분산 장치 또는 Azure Application Gateway(세션 선호도)를 사용할 수 있습니다.
옵션 2: 세션 지속성은 X-Forwarded-For 헤더 필드를 기준으로 합니다. 이 옵션을 사용하려면 이 기능이 있으며 HTTP 트래픽을 처리하고 TLS 연결을 종료할 수 있는 계층 7 부하 분산 장치가 필요합니다.
옵션 3: 세션 지속성을 요구하지 않도록 백 엔드 애플리케이션을 구성합니다.
백 엔드 애플리케이션의 부하 분산 요구 사항을 이해하려면 소프트웨어 공급업체의 설명서를 참조하세요.