허브 및 스포크 네트워크 아키텍처

Last reviewed 2024-07-29 UTC

이 문서에서는 Google Cloud에서 허브 및 스포크 네트워크 토폴로지를 설정하기 위한 두 가지 아키텍처 옵션을 보여줍니다. 한 가지 옵션은 Virtual Private Cloud(VPC)의 네트워크 피어링 기능을 사용하고, 다른 옵션은 Cloud VPN을 사용합니다.

기업은 결제, 환경 격리, 기타 고려사항을 위해 워크로드를 개별 VPC 네트워크로 분리할 수 있습니다. 하지만 공유 서비스나 온프레미스 연결과 같이 기업에서 이러한 네트워크 간에 특정 리소스를 공유해야 하는 경우도 있습니다. 이러한 경우 공유 리소스를 허브 네트워크에 배치하고 다른 VPC 네트워크를 스포크로 연결하는 것이 유용할 수 있습니다. 다음 다이어그램은 스타 토폴로지라고도 부르는 결과 허브 및 스포크 네트워크의 예시를 보여줍니다.

허브 및 스포크 네트워크 스키마.

이 예시에서는 한 대기업 내에서 개별 부서 단위의 워크로드를 위해 개별 스포크 VPC 네트워크가 사용됩니다. 각 스포크 VPC 네트워크는 공유 서비스를 포함하는 중앙 허브 VPC 네트워크에 연결되어 있고 이 기업의 온프레미스 네트워크에서 클라우드로의 단일 진입점으로 사용될 수 있습니다.

VPC 네트워크 피어링을 사용하는 아키텍처

다음 다이어그램은 VPC 네트워크 피어링을 사용하는 허브 및 스포크 네트워크를 보여줍니다. VPC 네트워크 피어링은 별도의 VPC 네트워크에 있는 리소스 간에 내부 IP 주소를 사용하여 통신하도록 지원합니다. 트래픽은 Google의 내부 네트워크에 머무르며 공개 인터넷을 거치지 않습니다.

VPC 네트워크 피어링을 사용하는 허브 및 스포크 아키텍처
  • 이 아키텍처에서는 네트워크 수준 격리가 필요한 리소스에 개별 스포크 VPC 네트워크가 사용됩니다. 예를 들어 이 아키텍처는 spoke-1 VPC 네트워크의 Compute Engine VM을 보여줍니다. spoke-2 VPC 네트워크에는 Compute Engine VM 및 Google Kubernetes Engine(GKE) 클러스터가 있습니다.
  • 이 아키텍처에서 각 스포크 VPC 네트워크는 중앙 허브 VPC 네트워크와의 피어링 관계를 갖습니다.
  • VPC 네트워크 피어링은 VM 대역폭을 제한하지 않습니다. 각 VM은 개별 VM의 전체 대역폭에서 트래픽을 전송할 수 있습니다.
  • 각 스포크 VPC 네트워크에는 인터넷과의 아웃바운드 통신을 위한 Cloud NAT 게이트웨이가 있습니다.
  • VPC 네트워크 피어링은 전환 경로 공지를 제공하지 않습니다. 추가 메커니즘이 사용되지 않으면 spoke-1 네트워크의 VM이 spoke-2 네트워크의 VM으로 트래픽을 전송할 수 없습니다. 이 비전환 제약조건을 해결하기 위해 이 아키텍처에서는 Cloud VPN을 사용해 네트워크 간에 경로를 전달하는 옵션을 보여줍니다. 이 예시에서 spoke-2 VPC 네트워크와 허브 VPC 네트워크 사이의 VPN 터널은 다른 스포크에서 spoke-2 VPC 네트워크에 대한 연결 가능성을 사용 설정합니다. 몇 가지 특정 스포크 간의 연결만 필요하면 이러한 VPC 네트워크 쌍을 직접 피어링할 수 있습니다.

Cloud VPN을 사용하는 아키텍처

VPC 네트워크 피어링을 사용하는 허브 및 스포크 기술의 확장성은 VPC 네트워크 피어링 한계에 따라 달라집니다. 또한 앞에서 설명한 것처럼 VPC 네트워크 피어링 연결은 피어링 관계에 있는 두 VPC 네트워크를 벗어나서 전환 트래픽을 허용하지 않습니다. 다음 다이어그램은 VPC 네트워크 피어링의 한계를 극복하기 위해 Cloud VPN을 사용하는 대체 허브 및 스포크 네트워크 아키텍처를 보여줍니다.

Cloud VPN을 사용하는 허브 및 스포크 아키텍처
  • 네트워크 수준 격리가 필요한 리소스는 별도의 스포크 VPC 네트워크를 사용합니다.
  • IPSec VPN 터널은 각 스포크 VPC 네트워크를 허브 VPC 네트워크에 연결합니다.
  • DNS 비공개 영역은 허브 네트워크에 있고 DNS 피어링 영역 및 비공개 영역은 각 스포크 네트워크에 있습니다.
  • 네트워크 간의 대역폭은 총 터널 대역폭으로 제한됩니다.

지금까지 설명한 두 아키텍처 중에서 선택할 때는 VPC 네트워크 피어링 및 Cloud VPN의 상대적 이점을 고려해야 합니다.

  • VPC 네트워크 피어링은 비전환 제약조건을 갖고 있지만, 네트워크 대역폭을 결정하는 VM의 머신 유형 및 기타 요소에 따라 정의된 전체 대역폭을 지원합니다. 하지만 VPN 터널을 추가하여 전환 라우팅을 추가할 수 있습니다.
  • Cloud VPN은 전환 라우팅을 허용하지만 총 대역폭(인그레스 및 이그레스)이 터널의 대역폭으로 제한됩니다.

설계 대안

Google Cloud에서 개별 VPC 네트워크에 배포되는 리소스를 상호 연결하기 위해서는 다음과 같은 아키텍처 대안을 고려하세요.

허브 VPC 네트워크에서 게이트웨이를 사용하는 스포크 간 연결
스포크 간 통신을 사용 설정하려면 스포크-스포크 트래픽의 게이트웨이로 사용할 수 있도록 허브 VPC 네트워크에 네트워크 가상 어플라이언스(NVA) 또는 차세대 방화벽(NGFW)을 배포하면 됩니다.
허브가 없는 VPC 네트워크 피어링
온프레미스 연결 또는 VPC 네트워크 간 서비스 공유에 중앙 집중식 제어가 필요하지 않으면 허브 VPC 네트워크가 필요하지 않습니다. 연결이 필요한 VPC 네트워크 쌍에 대해 피어링을 설정하고 상호 연결을 개별적으로 관리할 수 있습니다. VPC 네트워크당 피어링 연결 수에는 제한을 두지 마세요.
여러 공유 VPC 네트워크

네트워크 수준에서 격리하려는 각 리소스 그룹에 대해 공유 VPC 네트워크를 만듭니다. 예를 들어 프로덕션 및 개발 환경에 사용되는 리소스를 구분하려면 프로덕션용으로 공유 VPC 네트워크를 만들고 개발용으로 또 다른 공유 VPC 네트워크를 만듭니다. 그런 후 VPC 네트워크 간 통신을 사용 설정하도록 두 VPC 네트워크를 피어링합니다. 각 애플리케이션 또는 부서에 대해 개별 프로젝트에 있는 리소스는 적합한 공유 VPC 네트워크의 서비스를 사용할 수 있습니다.

VPC 네트워크와 온프레미스 네트워크 사이의 연결을 위해서는 각 VPC 네트워크를 위한 개별 VPN 터널을 사용하거나 동일한 Dedicated Interconnect 연결에서 개별 VLAN 연결을 사용할 수 있습니다.

다음 단계