스포크 간 네트워킹

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 또는 허브 가상 네트워크에 피어링됩니다. 어플라이언스가 트래픽을 스포크로 라우팅합니다. 어플라이언스 관리는 Virtual WAN와 마찬가지로 Microsoft가 할 수도 있고 사용자가 할 수 있습니다.

패턴 1: 스포크를 서로 직접 연결

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

• 가상 네트워크 피어링. 스포크를 통한 직접 가상 네트워크 피어링의 장점은 다음과 같습니다.

  • 필요한 가상 네트워크 피어링 홉이 적기 때문에 비용이 절감됩니다.
  • 트래픽이 대기 시간 또는 잠재적 병목 상태를 발생시키는 네트워크 어플라이언스를 트래버스할 필요가 없으므로 성능이 향상됩니다.

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

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

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

  • 스포크가 서로 직접 연결되지 않고 중간에 홉이 없는 허브-스포크

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

    

    이 문서의 모든 Visio 다이어그램을 다운로드하세요.

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

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

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

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

패턴 1: 단일 지역

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

패턴 1: 다중 지역

모든 스포크 가상 네트워크를 서로 연결하는 디자인도 여러 지역으로 확장할 수 있습니다. 이 토폴로지에서 Azure Virtual Network Manager는 필요한 만큼 많은 연결을 유지 관리해야 하는 관리 오버헤드를 줄이는 데 매우 중요합니다.

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

패턴 2: 스포크가 네트워크 어플라이언스를 통해 통신

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

• Virtual WAN 허브 라우터. 모든 것을 Microsoft에서 관리하는 Virtual WAN은 스포크의 트래픽을 끌어와 ExpressRoute나 사이트 간 또는 지점 및 사이트 간 VPN 터널을 통해 Virtual WAN에 연결된 다른 가상 네트워크 또는 온-프레미스 네트워크로 라우팅하는 가상 라우터를 포함하고 있습니다. Virtual WAN 라우터는 자동으로 스케일 업 및 다운되므로, 스포크 간의 트래픽 볼륨이 Virtual WAN 제한을 넘지 않도록 유지하기만 하면 됩니다.

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

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

• Azure VPN 게이트웨이. Azure VPN 게이트웨이를 사용자 정의 경로의 다음 홉 유형으로 사용할 수 있지만, VPN 가상 네트워크 게이트웨이를 사용하여 스포크 간 트래픽을 라우팅하는 것은 권장하지 않습니다. 온-프레미스 사이트 또는 VPN 사용자에게 전달되는 트래픽을 암호화하는 용도로 설계되었기 때문입니다. 예를 들어 VPN 게이트웨이가 라우팅할 수 있는 스포크 간 대역폭이 보장되지 않습니다.

• 없습니다. 특정 구성에서 ExpressRoute 게이트웨이는 스포크 간 통신을 유도하는 경로를 보급하고, 트래픽을 대상 스포크로 라우팅되는 Microsoft 에지 라우터로 보낼 수 있습니다. 이렇게 하면 트래픽을 Microsoft 백본 에지 및 백으로 전송하여 대기 시간이 발생하므로 이 시나리오는 사용하지 않는 것이 좋습니다. 뿐만 아니라 단일 실패 지점과 큰 폭발 반경도 이 시나리오를 권장하지 않는 이유에 포함됩니다. 또한 이 시나리오는 ExpressRoute 인프라(게이트웨이 및 물리적 라우터)에 추가적인 압력을 가하여 여러 가지 문제를 일으킵니다. 이 추가 압력으로 인해 패킷이 드롭될 수 있습니다.

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

• 수동 가상 네트워크 피어링. 이 방법은 스포크 가상 네트워크의 수가 적을 때 적합하지만, 관리 오버헤드가 대규모로 발생합니다.

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

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

패턴 2: 단일 지역

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

특정 상황에서는 확장성을 위해 스포크 간 트래픽과 인터넷 트래픽을 처리하는 네트워크 가상 어플라이언스를 분리하는 것이 좋을 수 있습니다. 분리하는 방법은 다음과 같습니다.

• 스포크의 경로 테이블을 튜닝하여 개인 주소(RFC 1918 접두사에 대한 경로가 있는 주소)를 Azure 간 및 Azure 온-프레미스 간 트래픽(동서 트래픽이라고도 함)을 담당하는 NVA로 보냅니다.
• 인터넷 트래픽(0.0.0.0/0 경로가 있는)을 보조 NVA로 튜닝합니다. 이 NVA는 Azure 인터넷 간 트래픽(남북 트래픽이라고도 함)을 담당합니다.

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

패턴 2: 다중 지역

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

다중 지역 허브-스포크 토폴로지에서도 남북 및 동서 트래픽에 대한 별도의 Azure 방화벽 또는 네트워크 가상 어플라이언스를 사용하는 디자인 변형이 가능합니다.

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

하이브리드 패턴

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

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

Virtual WAN에 동일한 디자인이 적용됩니다. 그러나 Virtual WAN 리소스가 아닌 가상 네트워크 간에 직접 수동으로 스포크 가상 네트워크 간 직접 연결을 구성해야 한다는 점을 고려해야 합니다. 현재 Azure Virtual Network Manager는 Virtual WAN 기반 아키텍처를 지원하지 않습니다. 예를 들면 다음과 같습니다.

참가자

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

주요 작성자:

• Jay Li | 선임 제품 관리자
• Jose Moreno | 수석 고객 엔지니어
• Alejandra Palacios | 선임 Azure 인프라 고객 엔지니어

기타 기여자:

• Mick Alberts | 테크니컬 라이터
• Mohamed Hassan | 주 PM 관리자
• Andrea Michael | 프로그램 관리자
• Yasukuni Morishima | 고객 엔지니어 II
• Jithin PP| 고객 엔지니어

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

다음 단계

• 클라우드 채택 프레임워크: 랜딩 존 네트워크 토폴로지 및 연결
• 가상 네트워크 피어링
• Azure Virtual Network Manager
• 가상 WAN
• Azure Firewall
• Azure의 보안 네트워크 연결
• Azure 가상 네트워크 소개

관련 참고 자료

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