스포크 간 네트워킹 패턴

Azure에서 가장 일반적인 네트워킹 디자인 패턴은 하나 또는 여러 Azure 지역에 배포된 허브 및 스포크 가상 네트워크 토폴로지입니다. 이러한 토폴로지에서는 필요에 따라 공용 인터넷을 통해 Azure ExpressRoute 또는 사이트 간 VPN(가상 사설망) 터널을 통해 온-프레미스 네트워크에 연결할 수 있습니다.

대부분의 디자인 가이드는 내부, 온-프레미스 네트워크 또는 인터넷의 사용자로부터 해당 가상 네트워크로 이동하는 애플리케이션 트래픽에 초점을 맞춥니다. 이러한 유형의 트래픽은 일반적으로 네트워크 다이어그램에서 수직 표현을 반영하는 용어인 남북 트래픽이라고 합니다. 이 문서에서는 동서 트래픽에 사용할 수 있는 다양한 패턴에 중점을 둡니다. 단일 지역 내 또는 여러 지역에 걸쳐 Azure 가상 네트워크에 배포된 워크로드 간의 통신 흐름입니다.

네트워크 디자인이 동서 트래픽에 대한 요구 사항을 충족하는지 확인하는 것은 Azure에서 실행되는 애플리케이션에 성능, 확장성 및 복원력을 제공하는 데 매우 중요합니다.

잠재적인 사용 사례

스포크-스포크 트래픽은 다음 시나리오에서 중요할 수 있습니다.

• 단일 애플리케이션의 여러 계층이 별도의 가상 네트워크에 있습니다. 예를 들어 경계 가상 네트워크의 경계 네트워크 서버(DMZ 서버라고도 함)는 내부 가상 네트워크의 애플리케이션 서비스와 통신합니다.

• 개발, 스테이징 및 프로덕션과 같은 다양한 환경의 애플리케이션 워크로드는 서로 간에 데이터를 복제해야 합니다.

• 여러 애플리케이션 또는 마이크로 서비스가 서로 통신해야 합니다.

• 데이터베이스는 재해가 발생할 경우 비즈니스 연속성을 보장하기 위해 지역 간에 데이터를 복제해야 합니다.

• 사용자는 Azure 가상 네트워크 내에 있습니다. 예를 들어 사용자가 Azure Virtual Desktop을 사용합니다.

스포크 간 통신을 위한 패턴 및 토폴로지

여러 가상 네트워크를 교차하는 Azure 디자인에서 사용할 수 있는 두 가지 주요 토폴로지에는 자체 관리형 허브와 스포크 및Azure Virtual WAN이 있습니다. Virtual WAN 환경에서 Microsoft는 허브 가상 네트워크와 그 안의 모든 것을 관리합니다. 자체 관리형 허브 및 스포크 환경에서 허브 가상 네트워크를 관리합니다.

Virtual WAN 및 자체 관리형 허브 및 스포크 토폴로지는 모두 워크로드가 스포크 가상 네트워크에서 실행되는 아키텍처입니다. 온-프레미스에 대한 연결은 허브 가상 네트워크에서 중앙 집중화됩니다. 이 문서에서 설명하는 많은 개념은 자체 관리형 허브 및 스포크 및 Virtual WAN 디자인 모두에 적용됩니다.

스포크 가상 네트워크를 서로 연결하는 두 가지 주요 패턴이 있습니다.

• 스포크는 서로 직접 연결됩니다. 허브 가상 네트워크를 트래버스하지 않고 직접 연결하기 위해 스포크 가상 네트워크 간에 가상 네트워크 피어링 또는 VPN 터널을 만듭니다.

• 스포크가 네트워크 어플라이언스를 통해 통신합니다. 각 스포크 가상 네트워크는 Virtual WAN 또는 허브 가상 네트워크와 연결됩니다. 어플라이언스는 스포크 간에 트래픽을 라우팅합니다. 어플라이언스는 직접 관리하거나 Microsoft에서 직접 관리할 수 있습니다. 이 관리 모델은 Virtual WAN 배포에서 관리가 처리되는 방식과 유사하게 작동합니다.

Pattern 1: 스포크가 서로 직접 연결됩니다.

일반적으로 스포크 간의 직접 연결은 허브에서 NVA(네트워크 가상 어플라이언스)를 통과하는 연결보다 더 나은 처리량, 대기 시간 및 확장성을 제공합니다. NVA를 통해 트래픽을 전송하면 NVA가 다른 가용성 영역에 있고 허브를 통해 트래픽이 전송될 때 적어도 2개의 가상 네트워크 피어링이 교차해야 하는 경우 트래픽 대기 시간이 늘어날 수 있습니다. 두 스포크 가상 네트워크를 서로 직접 연결하는 옵션에는 가상 네트워크 피어링, Azure Virtual Network Manager 및 VPN 터널이 포함됩니다.

• 가상 네트워크 피어링: 스포크보다 직접 가상 네트워크 피어링의 장점을 고려합니다.

  • 필요한 가상 네트워크 피어링 홉 수가 적기 때문에 비용이 절감됩니다.

  • 트래픽이 대기 시간 또는 잠재적 병목 상태를 발생시키는 네트워크 어플라이언스를 트래버스할 필요가 없으므로 성능 향상

  다른 시나리오로는 테넌트 간 연결이 있습니다. 그러나 스포크 가상 네트워크 간의 트래픽을 검사해야 할 수도 있습니다. 이 프로세스를 수행하려면 허브 가상 네트워크의 중앙 집중식 네트워킹 디바이스를 통해 트래픽을 보내야 할 수 있습니다.

• 서브넷 피어링: 가상 네트워크 피어링과 비슷하지만 서브넷 피어링을 사용하면 피어링 양쪽에서 서로 통신할 수 있는 서브넷을 지정하여 보다 세분성을 높일 수 있습니다.

• Virtual Network 관리자: 가상 네트워크 피어링의 이점 외에도 Virtual Network Manager는 가상 네트워크 환경을 관리하고 대규모로 연결을 만들 수 있는 관리 서비스를 제공합니다. Virtual Network Manager를 사용하여 구독 간에 세 가지 유형의 토폴로지 빌드할 수 있습니다. 이러한 토폴로지들은 기존 가상 네트워크와 새 가상 네트워크 모두에서 작동합니다.

  • 스포크가 서로 연결되지 않는 허브-스포크

  • 허브와 스포크 구조에서 스포크들이 중간 홉 없이 서로 직접 연결된 형태.

  • 상호 연결되는 메시된 가상 네트워크 그룹

    

    이러한 토폴로지에는 허브 및 스포크, 메시, 그리고 스포크 간에 직접 연결이 가능한 허브 및 스포크가 포함됩니다.

    이 아키텍처의 Visio 파일을 다운로드합니다.

    스포크가 서로 연결되는 Virtual Network Manager를 사용하여 허브 및 스포크 토폴로지 생성 시 동일한 네트워크 그룹의 스포크 가상 네트워크 간 직접 연결이 양방향으로 자동으로 생성됩니다. Virtual Network Manager를 사용하면 가상 네트워크 연결을 자동으로 만드는 특정 네트워크 그룹의 스포크 가상 네트워크 멤버를 정적 또는 동적으로 만들 수 있습니다.

    여러 네트워크 그룹을 만들어 스포크 가상 네트워크 클러스터를 직접 연결과 분리할 수 있습니다. 각 네트워크 그룹은 스포크-스포크 연결에 대해 동일한 지역 및 다중 리전 지원을 제공합니다. Virtual Network Manager의 최대 한도 아래로 유지해야 합니다.

• 가상 네트워크를 연결하는 VPN 터널: Microsoft VPN Gateway 또는 타사 VPN NVA를 사용하여 스포크 가상 네트워크를 직접 연결하도록 VPN 서비스를 구성할 수 있습니다. 이 옵션의 장점은 스포크 가상 네트워크가 동일한 클라우드 공급자 또는 연결 클라우드 간 공급자 내부의 상용 및 소버린 클라우드 간에 연결된다는 것입니다. 각 스포크 가상 네트워크에 소프트웨어 정의 광역 네트워크 NVA가 있는 경우 타사 공급자의 제어 평면 및 기능 집합을 사용하여 가상 네트워크 연결을 관리할 수 있습니다.

  이 옵션은 Media Access Control Security 암호화에서 제공하지 않는 단일 Azure 데이터 센터의 가상 네트워크 간 트래픽 암호화에 대한 규정 준수 요구 사항을 충족하는 데도 도움이 될 수 있습니다. 그러나 이 옵션에는 인터넷 프로토콜 보안 터널의 대역폭 제한(터널당 1.25Gbps) 및 허브 및 스포크 가상 네트워크 모두에 가상 네트워크 게이트웨이를 두는 디자인 제약 조건으로 인해 고유한 과제 집합이 있습니다. 스포크 가상 네트워크에 가상 네트워크 게이트웨이가 있는 경우 Virtual WAN에 연결하거나 허브의 가상 네트워크 게이트웨이를 사용하여 온-프레미스 네트워크에 연결할 수 없습니다.

패턴 1a: 단일 지역

스포크 가상 네트워크를 서로 연결하는 데 사용하는 기술에 관계없이 네트워크 토폴로지의 모양은 단일 지역에 대한 다음 이미지와 같습니다.

패턴 1b: 여러 지역

모든 스포크 가상 네트워크를 서로 연결하는 디자인은 여러 지역에 걸쳐 확장할 수 있습니다. 이 토폴로지에서 Virtual Network Manager는 더욱 중요해집니다. 이를 통해 많은 수의 연결을 유지하는 데 필요한 관리 오버헤드를 줄일 수 있습니다.

완전히 메시된 토폴로지에서 스포크 가상 네트워크를 서로 직접 연결하는 경우 많은 수의 가상 네트워크 피어링이 필요할 수 있다는 점을 고려해야 합니다. 다음 다이어그램에서는 이 문제를 보여줍니다. 이 시나리오에서는 가상 네트워크 연결을 자동으로 만들 수 있도록 Virtual Network Manager를 사용하는 것이 좋습니다.

패턴 2: 스포크는 네트워크 어플라이언스를 통해 통신합니다.

스포크 가상 네트워크를 서로 직접 연결하는 대신 네트워크 어플라이언스를 사용하여 스포크 간에 트래픽을 전달할 수 있습니다. 네트워크 어플라이언스는 심층 패킷 검사, 트래픽 세분화 또는 모니터링과 같은 다른 네트워크 서비스를 제공합니다. 그러나 크기가 제대로 조정되지 않으면 대기 시간 및 성능 병목 현상이 발생할 수 있습니다. 이러한 어플라이언스는 일반적으로 스포크가 연결하는 허브 가상 네트워크에 있습니다. 네트워크 어플라이언스를 사용하여 스포크 간에 트래픽을 전달하는 다음과 같은 여러 옵션이 있습니다.

• Virtual WAN 허브 라우터: Virtual WAN은 Microsoft에서 완전히 관리됩니다. 여기에는 스포크에서 트래픽을 끌어들이고 Virtual WAN에 연결된 다른 가상 네트워크 또는 ExpressRoute 또는 사이트 간 또는 지점 및 사이트 간 VPN 터널을 통해 온-프레미스 네트워크로 라우팅하는 가상 라우터가 포함되어 있습니다. Virtual WAN 라우터는 자동으로 확장 및 축소되므로 스포크 간의 트래픽 볼륨이 Virtual WAN 제한 내에서 유지되는지 확인해야 합니다.

• Azure Firewall:Azure Firewall 은 Microsoft에서 관리하는 네트워크 어플라이언스이며 관리하는 허브 가상 네트워크 또는 Virtual WAN 허브에 배포할 수 있습니다. IP 주소 패킷을 전달할 수 있으며, 이를 검사하고 정책에 정의된 트래픽 구분 규칙을 적용할 수도 있습니다. 병목 현상이 발생하지 않도록 Azure Firewall 제한 까지 자동 크기 조정을 제공합니다. Azure Firewall은 Virtual WAN과 함께 사용할 때만 기본 제공 다지역 기능을 제공합니다. Virtual WAN이 없으면 지역 간의 스포크 간 통신을 달성하려면 사용자 정의 경로를 구현해야 합니다.

• 타사 NVA: Microsoft 파트너의 NVA를 사용하여 라우팅 및 네트워크 구분을 수행하려는 경우 허브 및 스포크 또는 Virtual WAN 토폴로지에서 NVA를 배포할 수 있습니다. 자세한 내용은 Virtual WAN 허브에서고가용성 NVA 또는 NVA 배포를 참조하세요. NVA가 스포크 간 통신이 생성하는 대역폭을 지원하는지 확인해야 합니다.

• Azure VPN Gateway: VPN 게이트웨이를 사용자 정의 경로의 다음 홉 유형으로 사용할 수 있습니다. 그러나 스포크 간 트래픽을 라우팅하기 위해 VPN 가상 네트워크 게이트웨이를 사용하는 것은 권장되지 않습니다. 이러한 디바이스는 온-프레미스 사이트 또는 VPN 사용자에 대한 트래픽을 암호화하도록 설계되었습니다. 예를 들어 VPN 게이트웨이가 라우팅할 수 있는 스포크 간에 보장된 대역폭은 없습니다.

• ExpressRoute: 특정 구성에서 ExpressRoute 게이트웨이는 스포크 간의 통신을 유도하는 경로를 알리거나, 트래픽을 Microsoft Edge 라우터로 보내서, 라우터가 이를 최종 목적지 스포크로 라우팅할 수 있습니다. 이 패턴은 ExpressRoute 헤어핀이라고도 하며 명시적으로 설정해야 합니다. 트래픽을 Microsoft 백본 엣지로 전송했다가 다시 돌아오는 방식으로 대기 시간이 발생하므로, 이 시나리오는 강력히 권장하지 않습니다. 또한 단일 실패 지점과 큰 폭발 반경을 만듭니다. 또한 ExpressRoute 인프라, 특히 게이트웨이 및 물리적 라우터에 추가적인 압력을 가하여 패킷이 떨어질 수 있습니다.

NVA를 중앙 집중식으로 사용하는 자체 관리형 허브 및 스포크 네트워크 디자인에서 어플라이언스는 일반적으로 허브에 배치됩니다. 가상 네트워크 관리자를 사용하여 허브 및 스포크 가상 네트워크 간의 가상 네트워크 피어링을 수동으로 또는 자동으로 만들어야 합니다.

• 수동 가상 네트워크 피어링 또는 서브넷 피어링: 이 방법은 스포크 가상 네트워크 수가 적은 경우에 충분합니다. 그러나 대규모로 관리 오버헤드가 발생합니다.

• Virtual Network 관리자: Virtual Network Manager는 가상 네트워크 환경 및 피어링을 대규모로 관리하는 기능을 제공합니다. 허브-스포크 가상 네트워크 간의 피어링 구성은 네트워크 그룹에 대해 양방향으로 자동 구성됩니다.

  Virtual Network Manager는 특정 네트워크 그룹에 스포크 가상 네트워크 멤버 자격을 정적 또는 동적으로 추가할 수 있으며, 새 멤버에 대한 피어링 연결이 자동으로 생성됩니다. 네트워크 그룹의 스포크 가상 네트워크는 허브 VPN 또는 ExpressRoute 게이트웨이를 연결에 사용할 수 있습니다. Virtual Network Manager의 최대 한도 아래로 유지해야 합니다.

패턴 2a: 단일 지역

다음 다이어그램은 허브 가상 네트워크에 배포된 Azure 방화벽을 통해 스포크 간에 트래픽을 전송하는 단일 지역 허브-스포크 토폴로지를 보여줍니다. 트래픽은 스포크 서브넷에 적용되는 사용자 정의 경로를 통해 허브의 중앙 집중식 어플라이언스로 전달됩니다.

특정 상황에서는 확장성을 위해 스포크 간 및 인터넷 트래픽을 처리하는 NVA를 분리하는 것이 유용할 수 있습니다. 다음 작업을 수행하여 이 분리를 달성할 수 있습니다.

• 각 스포크의 경로 테이블을 조정하여 RFC 1918 접두사(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)를 사용하는 개인 주소 트래픽과 같은 트래픽을 NVA로 보냅니다. 이 어플라이언스는 Azure-Azure 및 Azure-to-on-프레미스 트래픽(종종 동서 트래픽이라고 함)을 처리합니다.

• 경로를 가진 인터넷 트래픽을 0.0.0.0/0 두 번째 NVA로 조정합니다. 이 NVA는 Azure-인터넷 트래픽( 남북 트래픽이라고도 함)을 담당합니다.

다음 다이어그램에서는 이 구성을 보여 줍니다.

패턴 2b: 여러 지역

동일한 구성을 여러 지역으로 확장할 수 있습니다. 예를 들어 Azure Firewall을 사용하는 자체 관리형 허브 및 스포크 디자인에서 원격 지역의 스포크에 대해 각 허브의 Azure Firewall 서브넷에 추가 경로 테이블을 적용해야 합니다. 이 구성을 사용하면 각 허브 가상 네트워크의 Azure 방화벽 간에 지역 간 트래픽을 전달할 수 있습니다. 스포크 가상 네트워크 간의 지역 간 트래픽은 두 Azure 방화벽을 모두 트래버스합니다. 자세한 내용은 Azure Firewall을 사용하여 다중 허브 및 스포크 토폴로지 라우팅을 참조하세요.

다중 리전 허브 및 스포크 토폴로지에서도 남북 및 동서 트래픽에 대해 별도의 Azure 방화벽 또는 NVA가 있는 디자인 변형이 가능합니다.

Virtual WAN은 유사한 토폴로지를 만들고 라우팅 복잡성을 처리합니다. Microsoft에서 관리하는 허브 및 스포크에서 라우팅을 관리하며, 수동 경로 테이블 편집 없이 경로를 삽입할 수 있습니다. 네트워크 관리자는 스포크 가상 네트워크를 Virtual WAN 허브에 연결하기만 하면 되며 지역 간 트래픽 전달에 대해 걱정할 필요가 없습니다.

혼합 패턴

일부 시나리오에서는 앞에서 설명한 두 패턴을 결합하는 하이브리드 접근 방식이 필요할 수 있습니다. 이 경우 특정 스포크 간의 트래픽은 직접 연결을 통해 이동해야 하지만 나머지 스포크는 중앙 네트워크 어플라이언스를 통해 통신합니다. 예를 들어 Virtual WAN 환경에서는 대역폭이 높고 대기 시간이 짧은 스포크 2개를 직접 연결할 수 있습니다. 또 다른 시나리오로 단일 환경에 포함된 스포크 가상 네트워크가 있습니다. 예를 들어 스포크 개발 가상 네트워크가 다른 스포크 개발 가상 네트워크에 직접 연결하도록 허용할 수 있지만 개발 및 프로덕션 워크로드가 중앙 어플라이언스를 통해 통신하도록 강제할 수 있습니다.

일반적인 또 다른 패턴은 직접 가상 네트워크 피어링 또는 Virtual Network Manager 연결 그룹을 통해 한 지역의 스포크를 연결하지만 지역 간 트래픽이 NVA를 통과하도록 허용합니다. 일반적으로 이 모델을 사용하는 주요 목적은 아키텍처의 가상 네트워크 피어링 수를 줄이는 것입니다. 그러나 첫 번째 모델(스포크 간 직접 연결)에 비해 이 모델의 한 가지 단점은 지역 간 트래픽을 처리하는 가상 네트워크 피어링 홉이 더 많다는 것입니다. 여러 가상 네트워크 피어링이 교차하기 때문에 이러한 홉은 비용을 증가시킵니다. 또 다른 단점은 모든 지역 간 트래픽을 처리하기 위해 허브 NVA에 추가 부하가 걸린다는 것입니다.

동일한 디자인이 Virtual WAN에 적용됩니다. 그러나 한 가지 고려 사항은 가상 WAN 리소스가 아닌 가상 네트워크 자체 간에 스포크 가상 네트워크 간의 직접 연결을 수동으로 구성해야 한다는 것입니다. Virtual Network Manager는 현재 Virtual WAN을 기반으로 하는 아키텍처를 지원하지 않습니다. 다음 다이어그램을 살펴보세요.

기여자

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

주요 작성자:

• Jay Li | 선임 제품 관리자
• 호세 모레노 | 수석 고객 엔지니어
• 알레한드라 팔라시오스 | 선임 Azure 인프라 고객 엔지니어

기타 기여자:

• Mick Alberts | 테크니컬 라이터
• 모하메드 하산 | 주 PM 관리자
• 안드레아 마이클 | 프로그램 관리자
• 야스쿠니 모리시마 | 고객 엔지니어 II
• Jithin PP| 고객 엔지니어

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

• 클라우드 채택 프레임워크: 랜딩 존 네트워크 토폴로지 및 연결
• Virtual Network Manager
• 가상 WAN
• Azure Firewall
• Azure에서 네트워크 연결 보호
• Azure 가상 네트워크 소개
• 기존 Azure 네트워킹 토폴로지

관련 리소스

• Azure의 허브-스포크 네트워크 토폴로지
• Virtual WAN을 사용하여 허브-스포크 네트워크 토폴로지