이 문서에서는 Google Cloud에서 허브 및 스포크 네트워크 토폴로지를 설정하기 위한 세 가지 아키텍처 옵션을 보여줍니다. 첫 번째 옵션은 Network Connectivity Center를 사용하고, 두 번째 옵션은 VPC 네트워크 피어링을 사용하며, 세 번째 옵션은 Cloud VPN을 사용합니다.
기업은 결제, 환경 격리, 기타 고려사항을 위해 워크로드를 개별 VPC 네트워크로 분리할 수 있습니다. 하지만 공유 서비스나 온프레미스 연결과 같이 기업에서 이러한 네트워크 간에 특정 리소스를 공유해야 하는 경우도 있습니다. 이 경우 공유 리소스를 허브 네트워크 (이 문서의 나머지 부분에서는 라우팅 네트워크라고 함)에 배치하고 다른 VPC 네트워크를 스포크 네트워크 (이 문서의 나머지 부분에서는 워크로드 네트워크라고 함)로 연결하는 것이 유용할 수 있습니다. 다음 다이어그램은 워크로드 VPC를 더 추가할 수 있지만 워크로드 VPC가 2개인 허브 및 스포크 네트워크를 보여줍니다.
이 예시에서는 대기업 내에서 개별 부서 단위의 워크로드를 위해 별도의 워크로드 VPC 네트워크가 사용됩니다. 각 워크로드 VPC 네트워크는 공유 서비스를 포함하는 중앙 라우팅 VPC 네트워크에 연결되어 있고 이 기업의 온프레미스 네트워크에서 클라우드로의 단일 진입점으로 사용될 수 있습니다.
옵션 요약
이 문서에서 설명한 아키텍처 중 하나를 선택할 때는 Network Connectivity Center, VPC 네트워크 피어링, Cloud VPN의 상대적 이점을 고려해야 합니다.
- Network Connectivity Center는 워크로드 VPC 간에 전체 대역폭을 제공하고 워크로드 VPC 간에 전달성을 제공합니다.
- VPC 네트워크 피어링은 워크로드 VPC와 라우팅 VPC 간에 전체 대역폭을 제공합니다. 워크로드 VPC 간에 전이성을 제공하지 않습니다. VPC 네트워크 피어링은 다른 VPC의 NVA로의 라우팅을 지원합니다.
- Cloud VPN은 전환 라우팅을 허용하지만 네트워크 간의 총 대역폭(인그레스 및 이그레스)이 터널의 대역폭으로 제한됩니다. 터널을 추가하여 대역폭을 늘릴 수 있습니다.
Network Connectivity Center를 사용하는 아키텍처
다음 다이어그램은 Network Connectivity Center를 사용하는 허브 및 스포크 네트워크를 보여줍니다.
Network Connectivity Center에는 컨트롤 플레인 관리를 제공하는 허브 리소스가 있지만 데이터 영역의 허브 네트워크는 아닙니다.
- Network Connectivity Center는 스타 (허브 및 스포크) 또는 메시 토폴로지를 사용하여 네트워크를 서로 연결할 수 있습니다. 스타 토폴로지를 사용하면 VPC 스포크 간 (워크로드 VPC) 통신이 방지되지만 메시 토폴로지는 그렇지 않습니다.
- 라우팅 (허브) VPC 네트워크는 Cloud VPN 또는 Cloud Interconnect 연결을 사용하여 온프레미스에 연결되어 있습니다.
- 동적 경로는 VPC 네트워크 전반에 전파될 수 있습니다.
- Private Service Connect 경로는 워크로드 VPC 간에 전이됩니다.
- 비공개 서비스 액세스 경로는 다양한 Google 제공 서비스의 프로듀서 스포크를 사용하여 워크로드 VPC 간에 전이됩니다. 경로가 전이되지 않는 서비스의 경우 Network Connectivity Center 대신 Cloud VPN을 사용하여 소비자 VPC 네트워크를 라우팅 VPC 네트워크에 연결하는 것이 해결 방법입니다.
- 피어링된 네트워크의 모든 VM은 VM의 전체 대역폭으로 통신할 수 있습니다.
- 각 워크로드 VPC 및 라우팅 VPC 네트워크에는 인터넷과의 아웃바운드 통신을 위한 Cloud NAT 게이트웨이가 있습니다.
- 워크로드 VPC의 워크로드에 온프레미스에서 연결할 수 있도록 DNS 피어링 및 전달이 설정됩니다.
VPC 네트워크 피어링을 사용하는 아키텍처
다음 다이어그램은 VPC 네트워크 피어링을 사용하는 허브 및 스포크 네트워크를 보여줍니다. VPC 네트워크 피어링은 별도의 VPC 네트워크에 있는 리소스 간에 내부 IP 주소를 사용하여 통신하도록 지원합니다. 트래픽은 Google의 내부 네트워크에 머무르며 공개 인터넷을 거치지 않습니다.
- 이 아키텍처에서 각 워크로드 (스포크) VPC 네트워크는 중앙 라우팅 (허브) VPC 네트워크와의 피어링 관계를 갖습니다.
- 라우팅 VPC 네트워크는 Cloud VPN 또는 Cloud Interconnect 연결을 사용하여 온프레미스에 연결되어 있습니다.
- 피어링된 네트워크의 모든 VM은 VM의 전체 대역폭으로 통신할 수 있습니다.
- VPC 네트워크 피어링 연결은 전이성이 없습니다. 이 아키텍처에서 온프레미스 및 워크로드 VPC 네트워크는 라우팅 네트워크와 트래픽을 교환할 수 있지만 서로는 교환할 수 없습니다. 공유 서비스를 제공하려면 라우팅 네트워크에 배치하거나 Cloud VPN을 사용하여 라우팅 네트워크에 연결합니다.
- 각 워크로드 VPC 및 라우팅 VPC 네트워크에는 인터넷과의 아웃바운드 통신을 위한 Cloud NAT 게이트웨이가 있습니다.
- DNS 피어링 및 전달은 워크로드 VPC의 워크로드에 온프레미스에서 연결할 수 있도록 설정됩니다.
Cloud VPN을 사용하는 아키텍처
VPC 네트워크 피어링을 사용하는 허브 및 스포크 토폴로지의 확장성은 VPC 네트워크 피어링 한도에 따라 달라집니다. 또한 앞에서 설명한 것처럼 VPC 네트워크 피어링 연결은 피어링 관계에 있는 두 VPC 네트워크를 벗어나서 전환 트래픽을 허용하지 않습니다. 다음 다이어그램은 VPC 네트워크 피어링의 한계를 극복하기 위해 Cloud VPN을 사용하는 대체 허브 및 스포크 네트워크 아키텍처를 보여줍니다.
- IPsec VPN 터널은 각 워크로드 (스포크) VPC 네트워크를 라우팅 (허브) VPC 네트워크에 연결합니다.
- DNS 비공개 영역은 라우팅 네트워크에 있고 DNS 피어링 영역 및 비공개 영역은 각 워크로드 네트워크에 있습니다.
- 연결은 전이적입니다. 온프레미스 네트워크와 스포크 VPC 네트워크는 라우팅 네트워크를 통해 서로 연결될 수 있지만 제한될 수 있습니다.
- 네트워크 간의 대역폭은 총 터널 대역폭으로 제한됩니다.
- 각 워크로드 (스포크) VPC 및 라우팅 VPC 네트워크에는 인터넷과의 아웃바운드 통신을 위한 Cloud NAT 게이트웨이가 있습니다.
- VPC 네트워크 피어링은 전이 경로 공지사항을 제공하지 않습니다.
- 워크로드 VPC의 워크로드에 온프레미스에서 연결할 수 있도록 DNS 피어링 및 전달이 설정됩니다.
설계 대안
Google Cloud에서 개별 VPC 네트워크에 배포되는 리소스를 상호 연결하기 위해서는 다음과 같은 아키텍처 대안을 고려하세요.
라우팅 VPC 네트워크에서 게이트웨이를 사용하는 스포크 간 연결
스포크 간 통신을 사용 설정하려면 스포크-스포크 트래픽의 게이트웨이로 사용할 수 있도록 라우팅 VPC 네트워크에 네트워크 가상 어플라이언스(NVA) 또는 차세대 방화벽 (NGFW)을 배포하면 됩니다.
여러 공유 VPC 네트워크
네트워크 수준에서 격리하려는 각 리소스 그룹에 대해 공유 VPC 네트워크를 만듭니다. 예를 들어 프로덕션 및 개발 환경에 사용되는 리소스를 구분하려면 프로덕션용으로 공유 VPC 네트워크를 만들고 개발용으로 또 다른 공유 VPC 네트워크를 만듭니다. 그런 후 VPC 네트워크 간 통신을 사용 설정하도록 두 VPC 네트워크를 피어링합니다. 각 애플리케이션 또는 부서에 대해 개별 프로젝트에 있는 리소스는 적절한 공유 VPC 네트워크의 서비스를 사용할 수 있습니다.
VPC 네트워크와 온프레미스 네트워크 간의 연결을 위해서는 각 VPC 네트워크를 위한 개별 VPN 터널을 사용하거나 동일한 Dedicated Interconnect 연결에서 개별 VLAN 연결을 사용할 수 있습니다.
다음 단계
- 허브 및 스포크 네트워크 Terraform 배포
- 교차 클라우드 네트워크 설계 가이드에서 허브 및 스포크 토폴로지를 온프레미스 및 기타 클라우드에 연결하는 방법을 알아보세요.
- 여러 VPC 네트워크 연결을 위한 설계 옵션 자세히 알아보기
- 비용 및 성능에 최적화된 안전하고 복원력이 우수한 클라우드 토폴로지를 빌드하기 위한 권장사항을 알아봅니다.