단일 지역 데이터 랜딩 존 연결

아티클
07/11/2023

데이터 관리 랜딩 존, 데이터 랜딩 존 및 그 안에 있는 모든 서비스는 단일 지역 설정에서 동일한 지역에 설정됩니다. 모든 랜딩 존은 동일한 연결 허브 구독 내에 있습니다. 이 구독은 공유 네트워크 리소스를 호스트하며, 공유 네트워크 리소스는 네트워크 가상 어플라이언스(예: Azure 방화벽), ExpressRoute 게이트웨이, VPN(가상 사설망) 게이트웨이, 허브 가상 네트워크 또는 가상 WAN(vWAN 허브)입니다.

그림 1: 단일 지역 연결

Azure Networking Services의 현재 기능을 고려할 때, 메시된 네트워크 아키텍처를 사용하는 것이 좋습니다. 다음 두 위치 사이에 Vnet 피어링을 설정해야 합니다.

연결 허브와 데이터 관리 존
연결 허브와 각 데이터 랜딩 존
데이터 관리 존과 각 데이터 랜딩 존
각 데이터 랜딩 존

이 문서에서는 클라우드 규모 분석 옵션으로 고려한 각 네트워크 아키텍처의 장단점을 설명합니다.

이 문서의 첫 번째 섹션에서는 데이터 관리 존과 모든 데이터 랜딩 존이 같은 지역에 호스트되는 단일 지역 패턴에 중점을 둡니다.

각 디자인 패턴은 다음 조건을 사용하여 평가됩니다.

비용
사용자 액세스 관리
서비스 관리
대역폭
대기 시간

다음 데이터 간 랜딩 존 사용 사례를 염두에 두고 각 디자인 옵션을 분석하겠습니다.

참고 항목

데이터 랜딩 존 B에 호스트된 VM B(가상 머신 B)는 데이터 랜딩 존 A에 호스트된 스토리지 계정 A의 데이터 세트를 로드합니다. 그러면 VM B가 이 데이터 세트를 처리하여 스토리지 계정 B에 저장하고, 이 데이터 세트는 데이터 랜딩 존 B에 호스트됩니다.

Important

이 문서 및 네트워킹 섹션의 다른 문서에서는 데이터를 공유하는 전체 사업부를 간략하게 설명합니다. 그러나 이 전략이 고객의 초기 전략이 아닐 수 있으며 이 경우 기본 수준에서 시작해야 할 수 있습니다.

결국 데이터 랜딩 존 간에 권장 설정을 구현할 수 있도록 네트워킹을 디자인해야 합니다. 거버넌스를 위해 랜딩 존에 직접 연결된 데이터 관리 랜딩 존이 있는지 확인해야 합니다.

메시된 네트워크 아키텍처(권장)

클라우드 규모 분석을 채택할 때 네트워크 메시 아키텍처를 사용하는 것이 좋습니다. 테넌트 내에 설정된 기존 허브-스포크 네트워크 디자인 외에도, 네트워크 메시 아키텍처를 구현하려면 다음 두 가지 작업을 수행해야 합니다.

모든 데이터 랜딩 존 Vnet 간에 Vnet 피어링을 추가합니다.
데이터 관리 랜딩 존과 모든 데이터 랜딩 존 간에 Vnet 페어링을 추가합니다.

예제 시나리오에서 스토리지 계정 A에서 로드된 데이터는 두 데이터 랜딩 존 Vnet 간에 설정된 Vnet 피어링 연결(2)을 전송합니다. 이 데이터는 VM B((3) 및 (4))에 로드되어 처리된 다음, 로컬 프라이빗 엔드포인트(5)를 통해 전송되어 스토리지 계정 B에 저장됩니다.

이 시나리오에서는 데이터가 연결 허브를 통과하지 않습니다. 데이터 관리 랜딩 존과 하나 이상의 데이터 랜딩 존으로 구성된 데이터 플랫폼 내에 유지됩니다.

그림 2: 메시된 네트워크 아키텍처

메시된 네트워크 아키텍처의 사용자 액세스 관리

메시된 네트워크 아키텍처 디자인에서 데이터 애플리케이션 팀은 다음 두 가지만 있으면 새 서비스(프라이빗 엔드포인트 포함)를 만들 수 있습니다.

데이터 랜딩 존의 전용 리소스 그룹에 대한 쓰기 액세스 권한
지정된 서브넷에 대한 조인 액세스 권한

이 디자인에서 데이터 애플리케이션 팀은 프라이빗 엔드포인트 자체를 배포할 수 있습니다. 프라이빗 엔드포인트를 지정된 스포크의 서브넷에 연결하는 데 필요한 액세스 권한이 있는 한, 팀은 필요한 연결을 설정할 때 지원이 필요하지 않습니다.

요약:

메시된 네트워크 아키텍처의 서비스 관리

메시된 네트워크 아키텍처 디자인에서는 네트워크 가상 어플라이언스가 단일 실패 또는 제한 지점으로 작동하지 않습니다. 해당 가상 어플라이언스를 스케일 아웃할 필요가 없는 경우 연결 허브를 통해 전송되는 데이터 세트가 없으면 중앙 Azure 플랫폼 팀의 오버헤드가 줄어듭니다.

중앙 Azure 플랫폼 팀이 더 이상 데이터 랜딩 존 간에 전송되는 모든 트래픽을 검사하고 기록할 수 없다는 뜻입니다. 그러나 클라우드 규모 분석은 여러 구독에 걸쳐 있는 일관적인 플랫폼으로, 스케일링이 가능하고 플랫폼 수준 제한을 극복하므로 이는 단점이 아닙니다.

모든 리소스가 단일 구독 내에 호스트되므로 중앙 Azure 플랫폼 팀은 더 이상 중앙 연결 허브의 모든 데이터를 검사하지 않습니다. 여전히 네트워크 보안 그룹 흐름 로그를 사용하여 네트워크 로그를 캡처할 수 있습니다. 서비스별 진단 설정을 사용하여 다른 애플리케이션 및 서비스 수준 로그를 통합하고 저장할 수 있습니다.

진단 설정에 Azure Policy 정의를 사용하여 이 모든 로그를 대규모로 캡처할 수 있습니다.

또한 이 디자인에서는 프라이빗 DNS 영역을 기반으로 Azure 네이티브 DNS 솔루션을 만들 수 있습니다. 프라이빗 DNS 그룹에 대한 Azure Policy 정의를 통해 DNS A-레코드 수명 주기를 자동화할 수 있습니다.

요약:

메시된 네트워크 아키텍처 비용

참고 항목

피어링된 네트워크에서 프라이빗 엔드포인트에 액세스할 때, VNet 피어링이 아닌 프라이빗 엔드포인트 자체에 대한 요금만 청구됩니다. 공식적인 내용은 FAQ: 피어링된 네트워크에서 프라이빗 엔드포인트에 액세스하는 경우 청구는 어떻게 되나요?에서 확인할 수 있습니다.

이 네트워크 디자인에서는 다음 요금만 지불하면 됩니다.

프라이빗 엔드포인트(시간당)
프라이빗 엔드포인트를 통해 전송된 수신 및 송신 트래픽은 원시 데이터 세트(1)를 로드하고 처리된 데이터 세트(6)를 저장합니다.

Vnet 피어링에는 요금이 부과되지 않습니다(2). 이 옵션의 비용이 가장 저렴한 이유입니다.

요약:

메시된 네트워크 아키텍처의 대역폭 및 대기 시간

이 디자인은 네트워크 가상 어플라이언스가 데이터 간 랜딩 존 데이터 교환의 처리량을 제한하지 않으므로 알려진 대역폭 또는 대기 시간 제한이 없습니다. 이 디자인의 유일한 제한 요소는 데이터 센터의 물리적 제한(광섬유 케이블 속도)입니다.

요약:

메시된 네트워크 아키텍처 요약

클라우드 규모 분석을 채택하려는 경우 메시된 네트워크 디자인을 사용하는 것이 좋습니다. 메시된 네트워크는 최소한의 비용으로 최대 대역폭과 짧은 대기 시간을 제공하면서도 사용자 액세스 관리 또는 DNS 계층과 관련하여 포기해야 하는 부분이 없습니다.

데이터 플랫폼 내에서 다른 네트워크 정책을 적용해야 하는 경우 중앙 네트워크 가상 어플라이언스 대신 네트워크 보안 그룹을 사용합니다.

기존 허브-스포크 아키텍처(권장하지 않음)

허브-스포크 네트워크 아키텍처 디자인은 가장 명확한 옵션이며, 여러 기업이 채택한 옵션입니다. 이 디자인에서는 VM B에서 Storage 계정 A의 데이터에 액세스할 수 있도록 연결 허브에서 네트워크 전이성이 설정됩니다. 데이터는 두 개의 Vnet 피어링((2) 및 (5))과 연결 허브 내에 호스트되는 네트워크 가상 어플라이언스((3) 및 (4))를 트래버스합니다. 그런 다음, 데이터는 가상 머신(6)에 의해 로드되고 다시 스토리지 계정 B(8)에 저장됩니다.

그림 3: 허브-스포크 아키텍처

기존 허브-스포크 아키텍처의 사용자 액세스 관리

기존 허브-스포크 디자인에서 데이터 애플리케이션 팀은 다음 두 가지만 있으면 새 서비스(프라이빗 엔드포인트 포함)를 만들 수 있습니다.

데이터 랜딩 존의 리소스 그룹에 대한 쓰기 액세스 권한
지정된 서브넷에 대한 조인 액세스 권한

요약:

기존 허브-스포크 아키텍처의 서비스 관리

이 네트워크 디자인은 잘 알려져 있으며 대부분의 조직의 기존 네트워크 설정과 일치합니다. 따라서 디자인을 쉽게 설명하고 구현할 수 있습니다. 또한 프라이빗 DNS 영역에 중앙 집중식 및 Azure 네이티브 DNS 솔루션을 사용하여 Azure 테넌트 내에서 FQDN 확인을 제공할 수 있습니다. 프라이빗 DNS 영역을 사용하면 Azure Policy를 통해 DNS A-레코드 수명 주기를 자동화할 수 있습니다.

이 디자인의 또 다른 이점은 트래픽이 중앙 네트워크 가상 어플라이언스를 통해 라우팅되기 때문에 한 스포크에서 다른 스포크로 전송되는 네트워크 트래픽을 기록하고 검사할 수 있다는 것입니다.

이 디자인의 한 가지 단점은 중앙 Azure 플랫폼 팀이 경로 테이블을 수동으로 관리해야 한다는 것입니다. 이는 스포크 간의 전이성을 보장하는 데 필요하며, 이렇게 하면 여러 데이터 랜딩 존에서 데이터 자산 공유가 가능합니다. 시간이 지나면서 경로 관리가 점점 복잡해지고 오류가 발생할 수 있으므로 미리 고려해야 합니다.

이 네트워크 설정의 또 다른 단점은 중앙 네트워크 가상 어플라이언스의 설정 방식입니다. 네트워크 가상 어플라이언스가 단일 실패 지점 역할을 하며 장애 발생 시 데이터 플랫폼 내에서 심각한 가동 중지 시간을 유발할 수 있습니다. 또한 데이터 플랫폼의 데이터 세트 크기가 커지고 데이터 간 랜딩 존 사용 사례의 수가 증가할수록 중앙 네트워크 가상 어플라이언스를 통해 더 많은 트래픽이 전송됩니다.

시간이 지나면 중앙 인스턴스를 통해 전송되는 데이터 양이 수 기가바이트, 심지어 수 테라바이트에 달할 수 있습니다. 기존 네트워크 가상 어플라이언스의 대역폭이 한 자리 또는 두 자릿수 기가바이트 처리량으로 제한되는 경우가 많기 때문에, 중앙 네트워크 가상 어플라이언스는 데이터 랜딩 존 간의 트래픽 흐름을 심각하게 제한하고 데이터 자산 공유 가능성을 제한하는 병목이 될 수 있습니다.

이 문제를 방지하는 유일한 방법은 여러 인스턴스에서 중앙 네트워크 가상 어플라이언스를 스케일 아웃하는 것입니다. 이 방법은 디자인의 비용에 큰 영향을 미칩니다.

요약:

기존 허브-스포크 아키텍처 비용

참고 항목

이 네트워크의 경우 스토리지 계정의 프라이빗 엔드포인트에 대한 시간당 요금이 청구됩니다. 원시 데이터 세트(1)를 로드하고 처리된 데이터 세트(8)를 저장하기 위해 프라이빗 엔드포인트를 통해 전송된 수신 및 송신 트래픽에 대한 요금도 청구됩니다.

고객에게는 Vnet 피어링 하나(5)의 수신 및 송신 요금이 청구됩니다. 앞에서 설명한 것처럼, 첫 번째 Vnet 피어링에는 요금이 청구되지 않습니다(2).

이 네트워크 디자인((3) 및 (4))을 사용하면 결국에는 중앙 네트워크 가상 어플라이언스 비용이 높아집니다. 추가 라이선스를 구매하고 수요에 따라 중앙 네트워크 가상 어플라이언스를 스케일링하거나 Azure Firewall에서 처리된 대로 기가바이트당 처리 요금을 지불해야 합니다.

요약:

기존 허브-스포크 아키텍처의 대역폭 및 대기 시간

이 네트워크 디자인에는 심각한 대역폭 제한 사항이 있습니다. 플랫폼이 커질수록 중앙 네트워크 가상 어플라이언스는 심각한 병목이 되어 데이터 간 랜딩 존 사용 사례 및 데이터 세트 공유를 제한합니다. 또한 시간이 지나면 데이터 세트의 여러 복사본을 만들 가능성이 높습니다.

이 디자인은 대기 시간에도 큰 영향을 미치며, 이는 실시간 분석 시나리오에서 특히 중요합니다.

요약:

기존 허브-스포크 아키텍처 요약

이 허브-스포크 네트워크 디자인은 액세스 관리 및 일부 서비스 관리 측면에서 이점이 있지만, 서비스 관리와 대역폭 및 대기 시간의 심각한 제한으로 인해 데이터 간 랜딩 존 사용 사례에는 이 네트워크 디자인을 사용하지 않는 것이 좋습니다.

프라이빗 엔드포인트 프로젝션 아키텍처(권장하지 않음)

또 다른 디자인 옵션은 각 랜딩 존에서 프라이빗 엔드포인트를 프로젝션하는 것입니다. 이 디자인에서는 스토리지 계정 A에 대한 프라이빗 엔드포인트가 각 랜딩 존에 만들어집니다. 데이터 랜딩 존 A의 Vnet에 연결된 데이터 랜딩 존 A의 첫 번째 프라이빗 엔드포인트, 데이터 랜딩 존 B의 Vnet에 연결된 두 번째 프라이빗 엔드포인트가 만들어지는 식입니다.

스토리지 계정 B와 데이터 랜딩 존 내의 잠재적 다른 서비스에도 동일하게 적용됩니다. 데이터 랜딩 존 수를 n으로 정의하면 적어도 모든 스토리지 계정 및 데이터 랜딩 존 내의 잠재적 다른 서비스에 대해 n개의 프라이빗 엔드포인트가 만들어집니다. 따라서 프라이빗 엔드포인트 수가 기하급수적으로 증가합니다.

그림 4: 프라이빗 엔드포인트 프로젝션 아키텍처

특정 서비스(예: 스토리지 계정 A)의 모든 프라이빗 엔드포인트에 동일한 FQDN(예: storageaccounta.privatelink.blob.core.windows.net)이 있으므로 이 솔루션은 DNS 계층에서 프라이빗 DNS 영역으로 해결할 수 없는 문제를 만듭니다. 대신 요청자의 원본/IP 주소를 기반으로 DNS 이름을 확인할 수 있는 사용자 지정 DNS 솔루션이 필요합니다. 이렇게 하면 VMA를 데이터 랜딩 존 A의 Vnet에 연결된 프라이빗 엔드포인트에 연결하고 VM B를 데이터 랜딩 존 B의 Vnet에 연결된 프라이빗 엔드포인트에 연결할 수 있습니다. 이 작업은 Windows Server 기반 설정으로 수행할 수 있는 반면 활동 로그와 Azure Functions의 조합을 통해 DNS A-레코드 수명 주기를 자동화할 수 있습니다.

이 설정에서는 로컬 프라이빗 엔드포인트(1)를 통해 데이터 세트에 액세스하여 스토리지 계정 A의 원시 데이터 세트를 VM B에 로드할 수 있습니다. 데이터 세트((2) 및 (3))를 로드하고 처리한 후에는 로컬 프라이빗 엔드포인트(4)에 직접 액세스하여 스토리지 계정 B에 데이터 세트를 저장할 수 있습니다. 이 시나리오에서는 데이터가 Vnet 피어링을 트래버스하면 안 됩니다.

프라이빗 엔드포인트 프로젝션 아키텍처의 사용자 액세스 관리

이 디자인의 사용자 액세스 관리 방식은 메시된 네트워크 아키텍처와 유사합니다. 그러나 이 디자인에서는 지정된 데이터 랜딩 존 및 Vnet 내부는 물론이고 다른 데이터 랜딩 존과 각 Vnet에도 프라이빗 엔드포인트를 만들려면 다른 데이터 랜딩 존에 대한 액세스 권한이 필요하도록 요구할 수 있습니다.

이 때문에 데이터 애플리케이션 팀은 새 서비스를 직접 만들려면 2개가 아닌 3개가 필요합니다.

지정된 데이터 랜딩 존의 리소스 그룹에 대한 쓰기 액세스
지정된 서브넷에 대한 조인 액세스 권한
다른 모든 데이터 랜딩 존 내의 리소스 그룹 및 서브넷에 액세스하여 해당 로컬 프라이빗 엔드포인트를 만듭니다.

이 네트워크 디자인은 데이터 애플리케이션 팀이 모든 단일 데이터 랜딩 존에서 권한을 요구하기 때문에 액세스 관리 계층의 복잡성이 증가합니다. 이 디자인은 혼동 가능성이 있으며 시간이 지나면 RBAC가 일관적이지 않게 될 수 있습니다.

데이터 랜딩 존 팀과 데이터 애플리케이션 팀에 필요한 액세스 권한이 부여되지 않은 경우 기존 허브-스포크 아키텍처(권장하지 않음)에 설명된 문제가 발생합니다.

요약:

프라이빗 엔드포인트 프로젝션 아키텍처의 서비스 관리

이 네트워크 디자인은 메시된 네트워크 아키텍처의 디자인과 비슷하지만, 단일 실패 지점으로 작동하거나 처리량을 제한하는 네트워크 가상 어플라이언스가 없다는 이점이 있습니다. 또한 가상 어플라이언스를 스케일 아웃할 필요가 없으므로 연결 허브를 통해 데이터 세트를 보내지 않기 때문에 중앙 Azure 플랫폼 팀의 관리 오버헤드가 감소합니다. 중앙 Azure 플랫폼 팀이 더 이상 데이터 랜딩 존 간에 전송되는 모든 트래픽을 검사하고 기록할 수 없다는 뜻입니다. 그러나 클라우드 규모 분석은 여러 구독에 걸쳐 있는 일관적인 플랫폼으로, 스케일링이 가능하고 플랫폼 수준 제한을 극복하므로 이는 단점이 아닙니다.

모든 리소스가 단일 구독 내에 호스트되므로 중앙 연결 허브에서 트래픽을 검사하지 않습니다. 계속해서 네트워크 보안 그룹 흐름 로그를 사용하여 네트워크 로그를 캡처할 수 있으며, 서비스별 진단 설정을 사용하여 다른 애플리케이션 및 서비스 수준 로그를 통합하고 저장할 수 있습니다. Azure 정책을 사용하여 이 모든 로그를 대규모로 캡처할 수 있습니다. 반면, 필요한 프라이빗 엔드포인트가 기하급수적 증가하기 때문에 데이터 플랫폼에 필요한 네트워크 주소 공간도 증가합니다. 따라서 최적의 옵션이 아닙니다.

이 네트워크 아키텍처와 관련된 주요 관심사는 앞에서 언급한 DNS 과제입니다. Azure 네이티브 솔루션을 프라이빗 DNS 영역 형식으로 사용할 수 없으므로, 이 아키텍처에는 요청자의 원본/IP 주소를 기반으로 FQDN을 확인할 수 있는 타사 솔루션이 필요합니다. 또한 제안된 Azure Policy 기반 솔루션에 비해 관리 오버헤드가 크게 증가하는 프라이빗 DNS A-레코드를 자동화하는 도구와 워크플로를 개발하고 유지 관리해야 합니다.

프라이빗 DNS 영역을 사용하여 분산 DNS 인프라를 만들 수 있지만, 이렇게 하면 DNS 섬이 만들어지고 결국에는 테넌트 내의 다른 랜딩 존에 호스트되는 프라이빗 링크 서비스에 액세스하려고 할 때 문제가 발생합니다. 따라서 이 디자인은 실현 가능한 옵션이 아닙니다.

요약:

프라이빗 엔드포인트 프로젝션 아키텍처 비용

참고 항목

피어링된 네트워크에서 프라이빗 엔드포인트에 액세스할 때 VNet 피어링이 아닌 프라이빗 엔드포인트 자체에 대한 요금만 청구됩니다. 공식적인 내용은 FAQ: 피어링된 네트워크에서 프라이빗 엔드포인트에 액세스하는 경우 청구는 어떻게 되나요?에서 확인할 수 있습니다.

이 네트워크 디자인에서는 프라이빗 엔드포인트(시간당) 요금과 원시 데이터 세트(1)를 로드하고 처리된 데이터 세트(4)를 저장하기 위해 이러한 프라이빗 엔드포인트를 통해 전송된 수신 및 송신 트래픽 요금만 부과됩니다. 그러나 데이터 플랫폼의 프라이빗 엔드포인트 수가 기하급수적으로 증가하므로 추가 비용을 예상해야 합니다. 시간당 요금이 청구되므로 추가 비용은 만들어지는 프라이빗 엔드포인트 수에 따라 크게 달라집니다.

요약:

프라이빗 엔드포인트 프로젝션 아키텍처의 대역폭 및 대기 시간

이 디자인은 네트워크 가상 어플라이언스가 데이터 간 랜딩 존 데이터 교환의 처리량을 제한하지 않으므로 알려진 대역폭 및 대기 시간 제한이 없습니다. 이 디자인의 유일한 제한 요소는 데이터 센터의 물리적 제한(광섬유 케이블 속도)입니다.

요약:

프라이빗 엔드포인트 프로젝션 아키텍처 요약

이 네트워크 아키텍처에서 프라이빗 엔드포인트가 기하급수적으로 증가하면 어떤 프라이빗 엔드포인트가 어떤 위치에서 어떤 목적으로 사용되는지 추적하지 못하게 될 수 있습니다. 액세스 관리 문제 및 DNS 계층 복잡성으로 인한 제한도 발생합니다. 이러한 문제로 인해 데이터 간 랜딩 존 사용 사례에는 이 네트워크 디자인을 사용하지 않는 것이 좋습니다.

연결 허브 아키텍처의 프라이빗 엔드포인트(권장하지 않음)

또 다른 네트워크 옵션은 연결 허브에 프라이빗 엔드포인트를 호스트하고 허브 Vnet에 연결하는 것입니다. 이 솔루션에서는 각 서비스의 단일 프라이빗 엔드포인트를 회사 Vnet에 호스트합니다. 대부분의 기업에서 기존 허브-스포크 네트워크 아키텍처를 사용하고 연결 허브가 이 솔루션에서 프라이빗 엔드포인트를 호스트하기 때문에 전이성이 필요하지 않습니다. 연결 허브와 데이터 랜딩 존 간의 Vnet 피어링을 통해 직접 액세스할 수 있습니다.

스토리지 계정 A에 저장된 데이터 세트를 VM B에 로드하기 위해 데이터는 연결 허브와 데이터 랜딩 존 간의 단일 Vnet 피어링을 트래버스합니다. 해당 데이터 세트가 로드되고 처리되면((3) 및 (4)) 동일한 Vnet 피어링을 두 번째로 트래버스한 후(5) 마지막으로 허브 Vnet에 연결된 프라이빗 엔드포인트를 통해 스토리지 계정 B에 저장됩니다(6).

그림 5: 연결 허브 아키텍처의 프라이빗 엔드포인트

연결 허브 아키텍처의 사용자 액세스 관리

이 네트워크 디자인에서는 데이터 랜딩 존 팀과 데이터 애플리케이션 팀이 프라이빗 엔드포인트를 허브 Vnet에 연결하려면 다음과 같은 두 가지가 필요합니다.

연결 허브 구독의 리소스 그룹에 대한 쓰기 권한
허브 Vnet에 대한 권한 조인

연결 허브는 조직의 Azure 플랫폼 팀을 위해 지정되며 조직의 필수 및 공유 네트워크 인프라(방화벽, 게이트웨이 및 네트워크 관리 도구 포함)를 호스트하는 전용 허브로 사용됩니다. 이 네트워크 옵션은 엔터프라이즈급 랜딩 존 기본 원칙의 액세스 관리 원칙을 따르지 않기 때문에 디자인의 일관성을 해칩니다. 따라서 대부분의 Azure 플랫폼 팀은 이 디자인 옵션을 승인하지 않습니다.

요약:

연결 허브 아키텍처의 서비스 관리

이 디자인은 메시된 네트워크 아키텍처의 디자인과 비슷하지만, 단일 실패 지점으로 작동하거나 처리량을 제한하는 네트워크 가상 어플라이언스가 없습니다. 또한 가상 어플라이언스를 스케일 아웃할 필요가 없으므로 연결 허브를 통해 데이터 세트를 보내지 않기 때문에 중앙 Azure 플랫폼 팀의 관리 오버헤드가 감소합니다. 중앙 Azure 플랫폼 팀이 더 이상 데이터 랜딩 존 간에 전송되는 모든 트래픽을 검사하고 기록할 수 없다는 뜻입니다. 그러나 클라우드 규모 분석은 여러 구독에 걸쳐 있는 일관적인 플랫폼으로, 스케일링이 가능하고 플랫폼 수준 제한을 극복하므로 이는 단점이 아닙니다.

모든 리소스가 단일 구독 내에 호스트되므로 중앙 연결 허브에서 트래픽을 검사하지 않습니다. 계속해서 네트워크 보안 그룹 흐름 로그를 사용하여 네트워크 로그를 캡처할 수 있으며, 서비스별 진단 설정을 사용하여 다른 애플리케이션 및 서비스 수준 로그를 통합하고 저장할 수 있습니다. Azure 정책을 사용하여 이 모든 로그를 대규모로 캡처할 수 있습니다.

또한 이 디자인을 사용하면 프라이빗 DNS 영역을 기반으로 Azure 네이티브 DNS 솔루션을 만들 수 있으며, Azure 정책을 통해 DNS A 레코드 수명 주기를 자동화할 수 있습니다.

요약:

연결 허브 아키텍처 비용

참고 항목

이 네트워크 디자인에서는 프라이빗 엔드포인트(시간당) 요금과 원시 데이터 세트(1)를 로드하고 처리된 데이터 세트(6)를 저장하기 위해 이러한 프라이빗 엔드포인트를 통해 전송된 수신 및 송신 트래픽 요금만 부과됩니다.

요약:

연결 허브 아키텍처의 대역폭 및 대기 시간

요약:

연결 허브 아키텍처의 프라이빗 엔드포인트 요약

이 네트워크 아키텍처 디자인은 여러 가지 이점을 제공하지만 앞에서 언급했듯이 액세스 관리가 일관적이지 않기 때문에 좋은 옵션이 아닙니다. 따라서 이 디자인 접근 방식을 사용하지 않는 것이 좋습니다.