다음을 통해 공유

다중 테넌트 및 Azure Private Link

  • 아티클

Azure Private Link는 Azure 가상 머신에서 호스트되는 사용자 고유의 애플리케이션 및 Azure 플랫폼 서비스에 대해 개인 IP 주소를 제공합니다. Private Link 사용하여 테넌트의 Azure 환경에서 프라이빗 연결을 사용하도록 설정할 수 있습니다. 또한 테넌트는 VPN Gateway(가상 사설망 게이트웨이) 또는 ExpressRoute를 통해 연결된 경우 Private Link를 사용하여 온-프레미스 환경에서 솔루션에 액세스할 수도 있습니다.

Azure Private Link는 Snowflake, Confluent Cloud 및 MongoDB Atlas를 비롯한 많은 대규모 SaaS 공급자에서 사용됩니다.

이 문서에서는 Azure에서 호스트하는 다중 테넌트 솔루션에 대해 Private Link를 구성하는 방법을 검토합니다.

주요 고려 사항

겹치는 IP 주소 공간

Private Link는 테넌트가 개인 주소 공간을 통해 서비스에 액세스할 수 있는 다중 테넌트 솔루션을 위한 강력한 기능을 제공합니다.

여러 테넌트가 동일하거나 겹치는 개인 IP 주소 공간을 자주 사용합니다. 예를 들어 다중 테넌트 솔루션은 10.1.0.0/16의 IP 주소 공간을 사용할 수 있습니다. 테넌트 A가 동일한 IP 주소 공간이 있는 자체 온-프레미스 네트워크를 사용하고 우연히 테넌트 B 역시 동일한 IP 주소 공간을 사용한다고 가정해 보겠습니다. IP 주소 범위가 겹치므로 네트워크를 직접 연결하거나 피어링할 수 없습니다.

Private Link를 사용하여 각 테넌트에서 다중 테넌트 솔루션으로의 연결을 사용하도록 설정하면 각 테넌트의 트래픽에 NAT(Network Address Translation)가 자동으로 적용됩니다. 각 테넌트는 자체 네트워크 내에서 개인 IP 주소를 사용할 수 있으며 트래픽은 다중 테넌트 솔루션으로 투명하게 전달됩니다. Private Link는 테넌트와 서비스 공급자가 모두 겹치는 IP 주소 범위를 사용하는 경우에도 트래픽에 대해 NAT를 수행합니다.

테넌트 두 개와 다중 테넌트 서비스 하나 간의 연결을 보여 주는 다이어그램으로, 모두 동일한 IP 주소 공간을 사용합니다.

트래픽이 다중 테넌트 솔루션에 도착하면 이미 변환된 상태입니다. 즉, 트래픽은 다중 테넌트 서비스의 자체 가상 네트워크 IP 주소 공간 내에서 시작된 것으로 보입니다. Private Link는 TCP 프록시 프로토콜 v2 기능을 제공하는데, 이 기능을 통해 다중 테넌트 서비스는 요청을 보낸 테넌트와 원본 네트워크의 원래 IP 주소를 알 수 있습니다.

서비스 선택

Private Link를 사용하는 경우 인바운드 연결을 허용하도록 하려는 서비스를 고려하는 것이 중요합니다.

Azure Private Link 서비스는 표준 Load Balancer 뒤에 있는 가상 머신에서 사용됩니다.

다른 Azure 서비스와 함께 Private Link를 사용할 수도 있습니다. 이러한 서비스에는 Azure App Service와 같은 애플리케이션 호스팅 플랫폼이 포함됩니다. 네트워크 및 API 게이트웨이인 Azure Application Gateway 또는 Azure API Management도 포함됩니다.

사용하는 애플리케이션 플랫폼에 따라 Private Link 구성의 여러 측면과 적용되는 제한이 결정됩니다. 또한 일부 서비스는 인바운드 트래픽에 대해 Private Link를 지원하지 않습니다. Private Link에 대한 지원을 이해하는 데 사용하는 Azure 서비스에 대한 설명서를 검토합니다.

제한

솔루션의 아키텍처에 따라 만들 수 있는 프라이빗 엔드포인트 수를 신중하게 고려하세요. PaaS(Platform as a Service) 애플리케이션 플랫폼을 사용하는 경우 단일 리소스에서 지원할 수 있는 최대 프라이빗 엔드포인트 수를 알고 있어야 합니다. 가상 머신을 실행하는 경우 Private Link 서비스 인스턴스를 SLB(표준 Load Balancer)에 연결할 수 있습니다. 이 구성에서는 일반적으로 더 많은 수의 프라이빗 엔드포인트를 연결할 수 있지만 제한은 여전히 적용됩니다. 이러한 제한은 Private Link를 사용하여 리소스에 연결할 수 있는 테넌트 수를 결정할 수 있습니다. Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 검토하여 엔드포인트 및 연결 수에 대한 제한을 이해하세요.

또한 일부 서비스에는 Private Link를 사용하기 위해 특수 네트워킹 구성이 필요합니다. 예를 들어 Azure Application Gateway와 함께 Private Link를 사용하는 경우 Application Gateway 리소스에 대한 표준 서브넷 외에 전용 서브넷을 프로비저닝해야 합니다.

Private Link 구성이 사용하도록 설정된 상태에서 배포 및 진단 구성을 포함한 솔루션을 신중하게 테스트하세요. 일부 Azure 서비스에서 프라이빗 엔드포인트를 사용하도록 설정하면 공용 인터넷 트래픽이 차단됩니다. 이 동작을 수행하려면 배포 및 관리 프로세스를 변경해야 할 수 있습니다.

인터넷에 연결되고 프라이빗 엔드포인트를 통해 노출될 수 있게 솔루션을 배포하도록 선택할 수 있습니다. 예를 들어 일부 테넌트는 프라이빗 연결이 필요한 반면 다른 테넌트는 공용 인터넷 연결을 사용해야 할 수 있습니다. 전체 네트워크 토폴로지 및 각 테넌트의 트래픽이 따르는 경로를 고려합니다.

솔루션이 표준 Load Balancer 뒤에 있는 가상 머신을 기반으로 하는 경우 Private Link 서비스를 통해 엔드포인트를 노출할 수 있습니다. 이 경우 웹 애플리케이션 방화벽 및 애플리케이션 라우팅은 이미 가상 머신 기반 워크로드의 일부일 수 있습니다.

많은 Azure PaaS 서비스는 다양한 Azure 구독 및 Microsoft Entra 테넌트에서도 인바운드 연결을 위한 Private Link를 지원합니다. 해당 서비스의 Private Link 기능을 사용하여 엔드포인트를 노출할 수 있습니다.

Azure Front Door와 같은 다른 인터넷 연결 서비스를 사용하는 경우 인바운드 트래픽에 대해 Private Link를 지원하는지 여부를 고려해야 합니다. 지원하지 않은 경우 트래픽이 각 경로를 통해 솔루션으로 흐르는 방식을 고려합니다.

예를 들어 가상 머신 확장 집합에서 실행되는 인터넷 연결 애플리케이션을 빌드한다고 가정해 보겠습니다. 보안 및 트래픽 가속을 위해 WAF(Web Application Firewall)를 포함한 Azure Front Door를 사용하고 프라이빗 엔드포인트를 통해 백엔드(원본) 서비스로 트래픽을 보내도록 Front Door를 구성합니다. 테넌트 A는 퍼블릭 엔드포인트를 사용하여 솔루션에 연결하고 테넌트 B는 프라이빗 엔드포인트를 사용하여 연결합니다. Front Door는 들어오는 연결에 대해 Private Link를 지원하지 않으므로 테넌트 B의 트래픽은 Front Door 및 WAF를 우회합니다.

Azure Front Door를 통해 들어오는 요청과 Front Door를 우회하는 프라이빗 엔드포인트를 통해 들어오는 요청을 보여 주는 다이어그램

격리 모델

Private Link는 테넌트 같은 여러 개별 클라이언트에서 단일 애플리케이션 계층을 사용할 수 있는 시나리오를 지원하도록 설계되었습니다. Private Link에 대한 격리를 고려할 때 주요 관심사는 요구 사항을 지원하기 위해 배포해야 하는 리소스 수에 관한 것입니다. Private Link에 사용할 수 있는 테넌트 격리 모델은 사용 중인 서비스에 따라 달라집니다.

표준 Load Balancer 뒤에 있는 가상 머신에서 Private Link 서비스를 사용하는 경우 고려할 수 있는 몇 가지 격리 모델이 있습니다.

고려 사항 공유 Private Link 서비스 및 공유 부하 분산 장치 전용 Private Link 서비스 및 전용 부하 분산 장치 전용 Private Link 서비스 및 공유 부하 분산 장치
배포 복잡성. 낮음 보통-높음, 테넌트 수에 따라 다름 보통-높음, 테넌트 수에 따라 다름
운영 복잡성 낮음 보통-높음, 리소스 수에 따라 다름 보통-높음, 리소스 수에 따라 다름
고려할 제한 사항 동일한 프라이빗 링크 서비스의 프라이빗 엔드포인트 수 구독당 프라이빗 링크 서비스 수 표준 Load Balancer당 Private Link 서비스 수
예제 시나리오 공유 애플리케이션 계층이 있는 대규모 다중 테넌트 솔루션 각 테넌트마다 별도의 배포 스탬프 많은 수의 테넌트가 있는 단일 스탬프의 공유 애플리케이션 계층

세 가지 모델 모두에서 데이터 격리 및 성능 수준은 솔루션의 다른 요인에 따라 달라지고 Private Link 서비스 배포는 이러한 요인에 실질적으로 영향을 주지 않습니다.

표준 Load Balancer에 연결된 공유 Private Link 서비스를 배포하는 것이 좋습니다. 각 테넌트는 프라이빗 엔드포인트를 만들고 이를 사용하여 솔루션에 연결할 수 있습니다.

단일 Private Link 서비스 인스턴스는 많은 수의 프라이빗 엔드포인트를 지원합니다. 한도를 소진하면 단일 부하 분산 장치에 배포할 수 있는 Private Link 서비스 수에 제한이 있음에도 불구하고 더 많은 Private Link 서비스 인스턴스를 배포할 수 있습니다. 이러한 제한에 근접할 것으로 예상되는 경우 배포 스탬프 기반 접근 방식을 사용할 것을 고려하고 공유 부하 분산 장치 및 Private Link 서비스 인스턴스를 각 스탬프에 배포합니다.

각 테넌트마다 전용 Private Link 서비스 및 전용 부하 분산 장치를 배포할 수 있습니다. 이 접근 방식은 테넌트에 엄격한 규정 준수 요구 사항이 있는 경우와 같이 각 테넌트용 전용 가상 머신 집합이 있는 경우에 적합합니다.

공유 표준 Load Balancer를 사용하여 각 테넌트 전용 Private Link 서비스 인스턴스를 배포할 수도 있습니다. 그러나 이 모델은 많은 이점을 제공하지 못할 수 있습니다. 또한 단일 표준 Load Balancer에 배포할 수 있는 Private Link 서비스 수에 제한이 있으므로 이 모델은 작은 다중 테넌트 솔루션 이상으로 스케일링될 가능성이 없습니다.

더 일반적으로 말하면, 공유 Private Link 서비스를 여러 개 배포할 수 있습니다. 이 접근 방식을 사용하면 솔루션이 하나의 공유 부하 분산 장치에서 지원할 수 있는 프라이빗 엔드포인트 수를 확장할 수 있습니다.

프라이빗 엔드포인트를 사용하는 Azure PaaS 서비스에 대한 격리 모델

Azure PaaS(Platform as a Service) 서비스를 배포하고 테넌트가 프라이빗 엔드포인트를 사용하여 해당 서비스에 액세스할 수 있도록 하려는 경우 특정 서비스의 기능 및 제약 조건을 고려합니다. 또한 애플리케이션 계층 리소스가 특정 테넌트에 전용인지 또는 테넌트 간에 공유되는지를 고려합니다.

각 테넌트의 전용 애플리케이션 계층 리소스 세트를 배포하는 경우 해당 테넌트가 리소스에 액세스하는 데 사용할 프라이빗 엔드포인트를 하나 배포할 수 있습니다. 각 테넌트마다 전용 리소스가 있기 때문에 Private Link 관련 서비스 한도를 모두 소진할 가능성은 거의 없습니다.

테넌트 간에 애플리케이션 계층 리소스를 공유하는 경우 각 테넌트용 프라이빗 엔드포인트를 배포하는 것이 좋습니다. 단일 리소스에 연결할 수 있는 프라이빗 엔드포인트 수에는 제한이 있으며 이러한 제한은 각 서비스마다 다릅니다.

Private Link에는 다중 테넌트 환경에서 유용한 몇 가지 기능이 있습니다. 그러나 사용 가능한 특정 기능은 사용 중인 서비스에 따라 달라집니다. 가상 머신 및 부하 분산 장치의 기본 Azure Private Link 서비스는 아래에서 설명하는 모든 기능을 지원합니다. Private Link를 지원하는 다른 서비스는 이러한 기능의 하위 집합만 제공할 수 있습니다.

서비스 별칭

테넌트가 Private Link 사용하여 서비스에 대한 액세스를 구성하는 경우 Azure에서 연결을 설정할 수 있도록 서비스를 식별할 수 있어야 합니다.

Private Link 서비스 및 Private Link와 호환되는 기타 특정 Azure 서비스를 사용하면 테넌트에 제공하는 별칭을 구성할 수 있습니다. 별칭을 사용하면 Azure 구독 ID 및 리소스 그룹 이름이 공개되는 것을 피할 수 있습니다.

서비스 표시 여부

Private Link 서비스를 사용하면 프라이빗 엔드포인트의 표시 여부를 제어할 수 있습니다. 모든 Azure 고객이 해당 별칭 또는 리소스 ID를 알고 있는 경우 서비스에 연결하도록 허용할 수 있습니다. 또는 알려진 Azure 고객 집합으로 액세스를 제한할 수 있습니다.

프라이빗 엔드포인트에 연결할 수 있는 미리 승인된 Azure 구독 ID 집합을 지정할 수도 있습니다. 이 방법을 사용하도록 선택하는 경우 구독 ID를 수집하고 권한을 부여하는 방법을 고려합니다. 예를 들어 애플리케이션에서 관리 사용자 인터페이스를 제공하여 테넌트의 구독 ID를 수집할 수 있습니다. 그런 다음 Private Link 서비스 인스턴스를 동적으로 다시 구성하여 연결에 대한 해당 구독 ID를 미리 승인할 수 있습니다.

연결 승인

클라이언트(예: 테넌트)와 프라이빗 엔드포인트 간에 연결이 요청되면 Private Link에는 해당 연결에 대한 승인이 필요합니다. 연결이 승인될 때까지 트래픽은 프라이빗 엔드포인트 연결을 통해 전달될 수 없습니다.

Private Link 서비스는 다음을 비롯한 여러 가지 유형의 승인 흐름을 지원합니다.

  • 수동 승인 - 팀에서 모든 연결을 명시적으로 승인합니다. 이 방법은 Private Link를 통해 서비스를 사용하는 테넌트가 몇 개뿐인 경우에 사용할 수 있습니다.
  • API 기반 승인 - 여기서 Private Link 서비스는 연결을 수동 승인이 필요한 것으로 처리하고 애플리케이션은 프라이빗 엔드포인트 연결 업데이트 API, Azure CLI 또는 Azure PowerShell을 사용하여 연결을 승인합니다. 이 방법은 프라이빗 엔드포인트를 사용할 권한이 있는 테넌트 목록이 있는 경우에 유용할 수 있습니다.
  • 자동 승인 - Private Link 서비스가 자동으로 연결이 승인되어야 하는 구독 ID 목록을 자체적으로 유지 관리합니다.

자세한 내용은 서비스 액세스 제어를 참조하세요.

프록시 프로토콜 v2

Private Link 서비스를 사용하는 경우 기본적으로 애플리케이션에는 NAT(네트워크 주소 변환)를 통과한 IP 주소만 표시됩니다. 이 동작은 트래픽이 사용자 고유의 가상 네트워크 내에서 흐르는 것처럼 보임을 의미합니다.

Private Link를 사용하면 테넌트의 가상 네트워크에서 원래 클라이언트 IP 주소에 액세스할 수 있습니다. 이 기능은 TCP 프록시 프로토콜 v2를 사용합니다.

예를 들어 테넌트 관리자가 IP 주소 기반 액세스 제한을 추가해야 한다고 가정해 보겠습니다. 예를 들어, 호스트 10.0.0.10은 서비스에 액세스할 수 있지만 호스트 10.0.0.20은 액세스할 수 없습니다. 프록시 프로토콜 v2를 사용하는 경우 테넌트가 애플리케이션에서 이러한 유형의 액세스 제한을 구성하도록 설정할 수 있습니다. 그러나 애플리케이션 코드는 클라이언트의 원래 IP 주소를 검사하고 제한을 적용해야 합니다.

  • 공급자(SaaS ISV) 및 소비자 관점에서 본 Azure Private Link 서비스 설명 및 데모: 다중 테넌트 서비스 공급자(예: SaaS 제품을 빌드하는 독립 소프트웨어 공급업체)를 지원하는 Azure Private Link 서비스 기능을 살펴보는 비디오입니다. 이 솔루션을 사용하면 소비자가 소비자 고유의 Azure 가상 네트워크에서 개인 IP 주소를 사용하여 공급자의 서비스에 액세스할 수 있습니다.
  • Azure Private Link 서비스와 TCP 프록시 프로토콜 v2 — 심층 분석: Azure Private Link 서비스의 고급 기능인 TCP 프록시 프로토콜 v2에 대한 심층 분석을 제공하는 비디오입니다. 다중 테넌트 및 SaaS 시나리오에서 유용합니다. 이 비디오에서는 Azure Private Link 서비스에서 프록시 프로토콜 v2를 사용하도록 설정하는 방법을 보여 줍니다. 또한 프라이빗 엔드포인트를 통해 서비스에 액세스하기 위해 NAT IP가 아닌 원래 클라이언트의 원본 개인 IP 주소를 읽도록 NGINX 서비스를 구성하는 방법도 보여 줍니다.
  • NGINX Plus를 사용하여 linkIdentifierAzure Private Link 서비스에서 프록시 프로토콜 TLV 디코딩: NGINX Plus를 사용하여 Azure Private Link 서비스에서 TCP 프록시 프로토콜 v2 TLV를 가져오는 방법을 보여 주는 비디오입니다. 이 비디오에서는 프라이빗 엔드포인트 연결의 숫자 linkIdentifier(LINKID라고도 함)를 추출하고 디코딩하는 방법을 보여 줍니다. 이 솔루션은 연결이 만들어진 특정 소비자 테넌트를 식별해야 하는 다중 테넌트 공급자에게 유용합니다.
  • SaaS 프라이빗 연결 패턴: Azure Managed Applications를 사용하여 프라이빗 엔드포인트 연결의 승인을 자동화하는 한 가지 방법을 보여 주는 예제 솔루션입니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

다른 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다중 테넌시에 대한 네트워킹 접근 방식을 검토합니다.