허브 및 스포크 네트워크 토폴로지

허브 및 스포크는 일반 통신 또는 보안 요구 사항을 효율적으로 관리하기 위한 네트워킹 모델입니다. 이를 통해 Azure 구독 제한 사항을 방지할 수 있습니다. 이 모델은 다음과 같은 문제를 해결합니다.

• 비용 절감 및 효율적인 관리: NVA(네트워크 가상 어플라이언스) 및 DNS 서버와 같은 여러 워크로드에서 공유할 수 있는 서비스를 중앙 집중화합니다. 서비스에 대한 단일 위치를 사용하면 IT에서 중복 리소스 및 관리 노력을 최소화할 수 있습니다.

• 구독 제한 극복: 대규모 클라우드 기반 워크로드에는 단일 Azure 구독에 포함된 것보다 더 많은 리소스를 사용해야 할 수 있습니다. 다른 구독에서 중앙 허브로 워크로드 가상 네트워크를 피어링하면 이러한 제한을 극복할 수 있습니다. 자세한 내용은 Azure 구독 제한을 참조하세요.

• 우려 사항 분리: 중앙 IT 팀과 워크로드 팀 간에 개별 워크로드를 배포할 수 있습니다.

소규모 클라우드 자산의 경우 이 모델이 제공하는 추가된 구조 및 기능의 이점을 활용하지 못할 수 있습니다. 그러나 더 큰 클라우드 채택 노력은 이전에 나열된 문제가 있는 경우 허브 및 스포크 네트워킹 아키텍처를 구현하는 것을 고려해야 합니다.

개요

그림 1: 허브 및 스포크 네트워크 토폴로지의 예제

다이어그램에 표시된 것처럼 두 가지 유형의 허브 및 스포크 디자인을 Azure 지원. 첫 번째 유형은 통신, 공유 리소스 및 중앙 집중식 보안 정책을 지원합니다. 이 유형은 다이어그램에서 VNet 허브로 레이블이 지정됩니다. 두 번째 유형은 다이어그램에서 Virtual WAN으로 레이블이 지정된 Azure Virtual WAN을 기반으로 합니다. 이 유형은 대규모 분기-분기 및 분기-Azure 통신용입니다.

허브는 인터넷, 온-프레미스 및 스포크 영역 간의 수신 또는 송신 트래픽을 제어하고 검사하는 중앙 네트워크 영역입니다. 허브 및 스포크 토폴로지에서는 IT 부서가 중앙 위치에서 보안 정책을 적용할 수 있는 효과적인 방법을 제공합니다. 또한 잘못된 구성 및 노출 가능성을 줄입니다.

허브에는 스포크에서 사용되는 공통 서비스 구성 요소가 포함되는 경우가 많습니다. 일반적인 중앙 서비스의 예제는 다음과 같습니다.

• DNS 서비스는 Azure DNS가 사용되지 않는 경우 온-프레미스 및 인터넷에서 리소스에 액세스하기 위해 스포크의 워크로드에 대한 이름을 확인합니다.
• 공개 키 인프라는 워크로드에 대한 Single Sign-On을 구현합니다.
• TCP 및 UDP 트래픽 흐름은 스포크 네트워크 영역과 인터넷 간에 제어됩니다.
• 흐름은 스포크와 온-프레미스 간에 제어됩니다.
• 필요한 경우 흐름은 한 스포크와 다른 스포크 간에 제어됩니다.

공유 허브 인프라를 사용하여 여러 스포크 지원을 통해 중복성을 최소화하고, 관리를 간소화하고, 전체 비용을 줄일 수 있습니다.

각 스포크 역할은 다양한 유형의 워크로드를 호스트하는 것입니다. 스포크는 동일한 워크로드의 반복 가능한 배포에 대한 모듈식 접근 방식도 제공합니다. 예를 들어 개발/테스트, 사용자 승인 테스트, 준비 및 프로덕션이 있습니다.

스포크는 조직 내에서 다른 그룹을 분리하고 사용하도록 설정할 수도 있습니다. 예를 들어 Azure DevOps 그룹이 있습니다. 스포크 내에서 계층 간 트래픽 제어를 통해 기본 워크로드 또는 복잡한 다중 계층 워크로드를 배포할 수 있습니다.

위의 다이어그램에 표시된 Application Gateway는 더 나은 관리 및 스케일링을 위해 제공하는 애플리케이션과 함께 스포크로 사용할 수 있습니다. 그러나 회사 정책에 따라 중앙 집중식 관리 및 의무 분리를 위해 Application Gateway를 허브에 배치할 수 있습니다.

구독 제한 및 여러 허브

Azure에서 모든 유형의 구성 요소는 Azure 구독에 배포됩니다. 다른 Azure 구독에서 Azure 구성 요소를 격리하면 차별화된 수준의 액세스 및 권한 부여 설정과 같은 다양한 비즈니스 라인의 요구 사항을 충족할 수 있습니다.

단일 허브 및 스포크 구현은 많은 수의 스포크로 스케일 업할 수 있지만 모든 IT 시스템과 마찬가지로 플랫폼 제한이 있습니다. 허브 배포는 제한 및 제한이 있는 특정 Azure 구독에 바인딩됩니다. 예를 들어 허용되는 최대 가상 네트워크 피어링 수가 있습니다. 자세한 내용은 Azure 구독 및 서비스 제한을 참조하세요.

제한이 문제가 될 수 있는 경우 모델을 허브 및 스포크의 클러스터로 확장하여 아키텍처를 스케일 업할 수 있습니다. 다음을 사용하여 하나 이상의 Azure 지역에서 여러 허브를 연결할 수 있습니다.

• 가상 네트워크 피어링
• Azure ExpressRoute
• Azure 가상 WAN
• 사이트 간 VPN

그림 2: 허브 및 스포크의 클러스터

여러 허브를 도입하면 시스템 비용 및 관리 오버헤드가 증가합니다. 이 증가는 다음을 통해서만 정당화됩니다.

• 확장성
• 시스템 제한
• 사용자 성능 또는 재해 복구를 위한 중복성 및 지역 복제

여러 허브가 필요한 시나리오에서는 모든 허브가 작동 편의를 위해 동일한 서비스 집합을 제공하려고 합니다.

스포크 간 상호 연결

단일 스포크 내에서 복잡한 다중 계층 워크로드를 구현할 수 있습니다. 동일한 가상 네트워크에서 서브넷(모든 계층에 대해 하나씩)을 사용하고 네트워크 보안 그룹을 사용하여 흐름을 필터링하여 다중 계층 구성을 구현할 수 있습니다.

설계자는 여러 가상 네트워크에 다중 계층 워크로드를 배포하려고 할 수 있습니다. 가상 네트워크 피어링을 사용하면 스포크는 동일한 허브 또는 다른 허브의 다른 스포크에 연결할 수 있습니다.

이 시나리오의 일반적인 예는 애플리케이션 처리 서버가 하나의 스포크 또는 가상 네트워크에 있는 경우입니다. 데이터베이스는 다른 스포크 또는 가상 네트워크에 배포됩니다. 이 경우 가상 네트워크 피어링을 통해 스포크를 쉽게 상호 연결하여 허브를 통한 전송을 방지할 수 있습니다. 허브를 무시해도 허브에만 있는 중요한 보안 또는 감사 지점을 무시하지 않도록 아키텍처 및 보안을 신중하게 검토합니다.

그림 3: 서로 허브에 연결하는 스포크 예제

스포크는 허브 역할을 하는 스포크에 상호 연결할 수도 있습니다. 이 접근법은 두 수준의 계층 구조를 만듭니다. 여기서는 상위 수준, 수준 0의 스포크가 계층 구조에서 하위 스포크 또는 수준 1의 허브가 됩니다. 스포크는 중앙 허브로 트래픽을 전달하는 데 필요합니다. 이 요구 사항은 트래픽이 온-프레미스 네트워크 또는 공용 인터넷의 대상으로 전송할 수 있도록 하기 위한 것입니다. 두 가지 수준의 허브를 사용하는 아키텍처에서는 라우팅이 복잡해져서 간단한 허브 및 스포크 관계의 이점이 사라집니다.

다음 단계

이제 네트워킹에 대한 모범 사례를 살펴보았으므로 ID 및 액세스 제어에 접근하는 방법을 알아봅니다.