이 문서는 Google Cloud에서 중앙 집중식 네트워크 어플라이언스를 실행하는 네트워크 관리자, 솔루션 설계자, 운영 전문가를 대상으로 합니다. Google Cloud의 Compute Engine 및 Virtual Private Cloud(VPC) 네트워킹에 대한 지식이 필요합니다.
기업 환경은 트래픽을 모니터링, 변환, 차단하는 가상의 VM 기반 어플라이언스를 통해 인터넷, 온프레미스 네트워크, 다른 클라우드, 동일한 클라우드 환경의 다른 부분으로 트래픽을 라우팅해야 하는 경우가 있습니다.
이 문서에서는 VPC 네트워크를 분할하고 중앙 집중식의 가상화된 네트워크 어플라이언스와 상호 연결하는 여러 설계 옵션을 검토합니다. VPC 네트워크, 온프레미스 네트워크, 인터넷 간의 모든 통신은 중앙 집중식 기기를 통해 라우팅됩니다. 중복 어플라이언스 그룹을 배포하여 고가용성 구성을 가져올 수 있습니다. 고가용성이 필요하지 않은 경우 단일 네트워크 어플라이언스를 배포할 수 있습니다.
가상화된 어플라이언스를 통해 트래픽을 라우팅하는 것은 어려울 수 있습니다. 예를 들어 Google Cloud에서는 인터넷으로 연결되는 경로를 대체하고 가상화된 어플라이언스 집합으로 트래픽을 리디렉션할 수 있지만 VPC 네트워크 내의 서브네트워크 간 라우팅 동작을 변경할 수는 없습니다. 서브네트워크 간 라우팅은 자동으로 이루어지며 이러한 경로는 삭제하거나 재정의할 수 없습니다.
또한 가상화된 어플라이언스의 중요한 역할로 인해 고가용성 구성에 배포되어야 합니다. 이는 모든 트래픽이 가상 어플라이언스 중 하나를 통해 라우팅되고 이러한 어플라이언스 간의 장애 조치가 자동으로 이루어지도록 해야 하므로 어렵습니다.
아키텍처
다음 다이어그램은 중앙 집중식의 가상화된 네트워크 어플라이언스를 특징으로 하는 여러 설계 옵션의 일반적인 사용 사례를 보여줍니다.
위의 다이어그램은 분할된 VPC 네트워크, 온프레미스 네트워크, 인터넷 간의 통신 경로와 중앙 집중식의 가상화된 네트워크 어플라이언스를 통해 라우팅되는 방식을 보여줍니다.
이 아키텍처의 주요 사용 사례
이 아키텍처는 트래픽이 라우팅되는 가상화된 네트워크 어플라이언스가 포함된 여러 사용 사례에 사용할 수 있습니다. 다음 사항에 유의하세요.
- 다양한 공급업체의 여러 어플라이언스는 Google Cloud Marketplace에서 찾을 수 있습니다.
- 일부 어플라이언스 공급업체는 웹사이트 또는 지원 페이지에서 Google Cloud용으로 맞춤 설정된 Compute Engine 이미지를 제공합니다.
- 오픈소스 네트워킹 소프트웨어를 사용하여 가상화된 어플라이언스를 직접 만들 수 있습니다. 자체 이미지를 만들 수도 있습니다.
공급업체는 종종 고가용성 구성에서 가상화된 어플라이언스를 실행하기 위한 자체 참조 아키텍처 또는 배포 가이드를 제공합니다. 자세한 내용은 공급업체의 웹사이트를 참조하세요.
공급업체의 참조 아키텍처는 이 문서에 제시된 모든 옵션을 포함하지 않을 수 있습니다.
각 접근 방식의 장단점을 이해하는 것이 중요합니다. 트래픽이 라우팅되는 가상 어플라이언스의 일반적인 사용 사례는 다음과 같습니다.
- 차세대 방화벽(NGFW) 중앙 집중식 방화벽 집합은 VPC 방화벽 규칙을 사용하는 경우 사용할 수 없는 기능을 제공하는 가상 머신으로 실행됩니다. 가장 일반적인 사용 사례입니다. NGFW 제품의 일반적인 기능에는 애플리케이션 계층의 딥 패킷 검사(DPI)와 방화벽이 있습니다. 일부 NGFW 방화벽은 TLS/SSL 트래픽 검사와 함께 다음 글머리기호 항목의 사용 사례에 설명된 다른 네트워킹 기능도 제공합니다.
- 침입 감지 시스템/침입 방지 시스템(IDS/IPS) 네트워크 기반 IDS를 사용하려면 잠재적으로 악의적인 트래픽을 모두 확인해야 합니다. 침입을 방지하기 위해 트래픽은 일반적으로 트래픽 경로의 IPS에 의해 차단됩니다.
- 투명한 프록시 투명한 프록시는 HTTP(S) 트래픽을 모니터링하고 웹 액세스에 제한을 적용하는 데 자주 사용됩니다.
- 네트워크 주소 변환(NAT) 게이트웨이 NAT 게이트웨이는 IP 주소와 포트를 번역합니다. 예를 들어 IP 주소가 겹치지 않도록 할 수 있습니다. Google Cloud는 Cloud NAT를 관리형 서비스로 제공하지만 이 서비스는 온프레미스 트래픽 또는 Google Cloud의 다른 VPC 네트워크가 아닌 인터넷으로 이동하는 트래픽에만 사용할 수 있습니다.
- 웹 애플리케이션 방화벽(WAF) WAF는 웹 애플리케이션으로 이동하는 악성 HTTP 트래픽을 차단합니다. Google Cloud는 Google Cloud Armor 보안 정책을 통해 WAF 기능을 제공합니다. 정확한 기능은 WAF 공급업체마다 다르므로 필요한 사항을 정확하게 파악하는 것이 중요합니다.
일반적인 요구사항
중앙 집중식 가상 어플라이언스를 통한 트래픽 라우팅 요구사항은 특정 사용 사례에 따라 다릅니다. 그러나 일반적으로 다음과 같은 요구사항이 적용됩니다.
- 다른 네트워크 세그먼트 간의 모든 트래픽은(예: 별도의 보안 요구 사항이 있거나 서로 다른 애플리케이션 모듈 간에 서로 다른 팀이 관리하는 환경) 중앙 집중식 가상 어플라이언스를 통과해야 합니다.
- 인터넷과 보안 환경을 오가는 모든 트래픽은 중앙 집중식 가상 어플라이언스를 통과해야 합니다.
- Cloud VPN, Dedicated Interconnect, Partner Interconnect을 통해 Google Cloud에 연결된 온프레미스 시스템과 주고받는 모든 트래픽은 중앙 집중식 가상 어플라이언스를 통과해야 합니다.
- 여러 중앙 집중식 가상 어플라이언스는 활성/활성 또는 활성/수동 구성의 고가용성 구성으로 설정됩니다. 장애 조치는 소프트웨어 또는 하드웨어 문제가 가상화된 어플라이언스 중 하나에서 발생할 경우 자동으로 수행됩니다.
- 모든 트래픽은 스테이트풀별로 라우팅되므로 두 가상 머신 간의 트래픽 흐름은 항상 동일한 가상 어플라이언스를 통과합니다.
- 중앙 집중식 가상 어플라이언스 시스템의 처리량은 다음 두 가지 옵션 중 하나로 확장할 수 있습니다.
- 가상 어플라이언스를 수직으로 확장: 코어 수 또는 각 가상 머신의 메모리 양을 늘립니다.
- 가상 어플라이언스를 수평으로 확장: 트래픽 분산에 사용되는 가상 어플라이언스 수를 늘립니다.
아키텍처 옵션
가상 어플라이언스 간에 고가용성을 달성하기 위한 여러 옵션이 있습니다. 네트워크 세그먼트를 가상 어플라이언스에 연결하기 위한 여러 가지 옵션도 있습니다.
고가용성 옵션과 네트워크 세그먼트 연결 옵션을 결합할 수 있습니다. 이 문서의 뒷부분에서 설명하는 일반적인 옵션은 VPC 네트워크 피어링과 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하는 아키텍처입니다.
고가용성 옵션 선택
다음 두 가지 방법으로 여러 인스턴스를 사용하여 중앙 어플라이언스의 가용성을 높이기 위한 아키텍처를 빌드할 수 있습니다.
내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용합니다. 이 방식에서는 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 관리형 인스턴스 그룹에 여러 가상 어플라이언스를 배치합니다. 이 부하 분산기는 어플라이언스에 연결된 VPC 네트워크의 기본 경로를 대체하는 기본 경로의 다음 홉으로 사용됩니다. 내부 패스 스루 네트워크 부하 분산기를 위한 장애 조치를 사용하여 표준 구성인 활성/활성 구성 또는 활성/수동 구성에서 어플라이언스를 사용할 수 있습니다. 상태 확인은 트래픽을 정상 인스턴스로 보냅니다. 실패 시 어플라이언스를 자동으로 다시 만들려면 자동 복구를 사용하면 됩니다. 기기에서 다중 네트워크 인터페이스를 사용하는 경우 다음 홉으로 사용되는 내부 패스 스루 네트워크 부하 분산기는 모든 네트워크 인터페이스에서 백엔드를 가질 수 있습니다.
다음 다이어그램은 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하는 토폴로지를 보여줍니다.
위의 다이어그램은 다음 홉 역할을 하는 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 여러 가상 어플라이언스를 포함한 VPC 네트워크의 관리형 인스턴스 그룹을 보여줍니다.
라우팅 사용. 이 접근 방식에서 Google Cloud 경로는 연결된 VPC 네트워크에서 가상 어플라이언스로 트래픽을 전달합니다. 다른 우선순위 경로를 사용하여 활성/수동 구성에서 어플라이언스를 사용하거나, 경로가 동일한 우선순위로 구성될 경우 활성/활성 구성에서 어플라이언스를 사용할 수 있습니다. 이 경우동일 비용 다중 경로(ECMP) 라우팅을 사용하여 트래픽을 분산할 수 있습니다. 자동 복구를 사용하면 어플라이언스가 비정상일 때 다시 시작하도록 할 수 있습니다.
다음 다이어그램은 라우팅을 사용하는 토폴로지를 보여줍니다.
위의 다이어그램은 연결된 VPC 네트워크에서 가상 어플라이언스로 트래픽을 전달하는 Google Cloud Routes가 있는 VPC 네트워크의 관리형 인스턴스 그룹을 보여줍니다.
내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하면 고가용성을 위해 Google Cloud 라우팅을 사용하는 것에 비해 다음과 같은 이점이 있습니다.
- 상태 확인은 트래픽이 전달되는 위치를 결정하므로 트래픽이 정상적인 인스턴스에만 전달되도록 합니다. 로컬 인스턴스가 확인되거나 엔드 투 엔드 경로가 확인되도록 상태 확인을 노출할 수 있습니다.
- 더 빠른 장애 조치를 위해 상태 확인 타이머를 미세 조정할 수 있습니다. 이 접근 방식은 비정상 인스턴스의 경우 장애 조치를 가장 빠르게 수행합니다.
- 대칭 해싱을 사용하여 반환 트래픽이 송신 트래픽과 동일한 가상 머신으로 라우팅되도록 확인할 수 있습니다.
Google Cloud 라우팅을 사용하면 다음과 같은 장점이 있습니다.
- 일관된 대칭 해싱은 프로토콜 및 세션 어피니티 선택에 따라 지정된 연결의 패킷이 요청 및 응답 모두에 대해 동일한 백엔드 VM에서 처리되도록 합니다. 프로토콜 및 세션 어피니티 선택에 따라 연결 추적의 사용 여부가 결정됩니다. 백엔드 인스턴스에 소스 NAT(SNAT) 구성이 있으면 유용한 사용 사례도 있습니다. 예를 들어 한 네트워크에서 다른 네트워크로의 응답 연결이 이 두 네트워크 간에 동일한 방향으로 진행되는 별도의 요청 연결과 일치해야 하는 경우가 여기에 해당합니다.
Google Cloud 라우팅을 사용하면 다음과 같은 단점이 있습니다.
- 상태 확인은 인스턴스 풀에서 비정상 인스턴스를 삭제하고 다시 만듭니다. 그러나 비정상 인스턴스를 삭제하고 정상적인 새 인스턴스를 만드는 데 시간이 걸리므로 상태 확인이 실패할 경우 트래픽 흐름이 즉시 변경되지 않습니다. 이렇게 하면 장애 조치 시간이 느려집니다.
- 인스턴스를 불필요하게 삭제하고 다시 만들지 않도록 상태 확인 타이머를 설정하면 장애 조치 시간이 느려집니다.
내부 패스 스루 네트워크 부하 분산기를 다음 홉 또는 Google Cloud 라우팅으로 사용하는 경우 모든 프로토콜 트래픽이 지원됩니다. 이러한 지원에 대한 자세한 내용은 TCP, UDP, 기타 프로토콜 트래픽 처리를 참조하세요.
마찬가지로 두 솔루션 모두 특정 네트워크 태그로의 경로 제한을 지원합니다. 예를 들어 VM 인스턴스는 리전별로 분류되어 다양한 어플라이언스 집합을 사용할 수 있습니다.
네트워크 세그먼트 연결 옵션 선택
서브네트워크 간 라우팅은 재정의할 수 없으므로 네트워크 세그먼트는 별도의 VPC 네트워크를 사용하여 구현됩니다. 이러한 VPC 네트워크, 온프레미스 환경, 인터넷 간의 트래픽은 중앙 집중식 어플라이언스를 통해 라우팅해야 합니다. 이러한 모든 네트워크 세그먼트는 독립형 VPC 네트워크 또는 공유 VPC 네트워크일 수 있습니다.
다음과 같이 여러 가지 방법으로 네트워크 세그먼트를 연결할 수 있습니다.
다중 네트워크 인터페이스 가상 어플라이언스를 통해 여러 VPC 네트워크를 연결하는 가장 간단한 방법은 각 인터페이스가 VPC 네트워크 중 하나에 연결되는 여러 네트워크 인터페이스를 사용하는 것입니다. 인터넷 및 온프레미스 연결은 하나 또는 두 개의 개별 네트워크 인터페이스를 통해 제공됩니다. 많은 NGFW 제품에서는 인터넷 연결이 NGFW 소프트웨어에서 신뢰할 수 없는 것으로 표시된 인터페이스를 통해 연결됩니다.
다음 다이어그램은 이 토폴로지를 보여줍니다.
위의 다이어그램은 여러 네트워크 인터페이스를 사용하여 가상 어플라이언스를 통해 연결되는 여러 VPC 네트워크를 보여줍니다. 각 인터페이스는 VPC 네트워크 중 하나에 연결됩니다. 이 다이어그램은 신뢰할 수 없는 인터페이스를 통한 인터넷 연결을 포함하여 별도의 네트워크 인터페이스를 통한 인터넷 및 온프레미스 연결도 보여줍니다.
VPC 네트워크 피어링 이 토폴로지는 VPC 네트워크 피어링과 함께 허브 및 스포크 개념을 사용합니다. 네트워크 세그먼트는 허브 VPC 네트워크와 함께 VPC 네트워크 피어링을 사용하여 피어링되는 스포크 VPC 네트워크 집합으로 구현되며 여기에서 트래픽이 가상화된 어플라이언스의 중앙 집중식 풀을 통해 라우팅됩니다. 내부 패스 스루 네트워크 부하 분산기를 다음 홉 또는 가상 어플라이언스로 직접 가리키는 기본 경로는 VPC 네트워크 피어링을 통해 커스텀 경로로 내보내집니다. 인터넷 및 온프레미스 연결은 하나 또는 두 개의 개별 네트워크 인터페이스를 통해 제공됩니다.
다음 다이어그램은 이 토폴로지를 보여줍니다.
위의 다이어그램은 여러 허브 VPC 네트워크에 연결된 여러 네트워크 인터페이스가 포함된 가상화된 어플라이언스의 중앙 집중식 풀을 보여줍니다. 각 허브 VPC 네트워크는 VPC 네트워크 피어링을 통해 여러 VPC 네트워크에 연결됩니다. 두 VPC 네트워크 간의 트래픽은 가상화된 어플라이언스의 중앙 집중식 풀을 통해 라우팅됩니다.
여러 네트워크 인터페이스와 VPC 네트워크 피어링 결합 이 접근 방식은 추가 확장성을 위해 앞의 두 가지 옵션을 결합합니다. 다중 네트워크 인터페이스는 여러 허브 VPC 네트워크에 연결되며 각 네트워크는 VPC 네트워크 피어링을 통해 여러 스포크 VPC 네트워크에 연결됩니다. 각 허브 및 스포크 VPC 네트워크에는 VPC 네트워크 피어링 케이스에 설명된 것과 동일한 접근 방식을 사용합니다.
다음 다이어그램은 이 토폴로지를 보여줍니다.
위의 다이어그램은 VPC 네트워크 피어링을 통해 여러 VPC 네트워크에 연결된 허브 VPC 네트워크를 보여줍니다. 트래픽은 허브 네트워크에 하나의 네트워크 인터페이스가 있는 가상화된 어플라이언스의 중앙 집중식 풀을 통해 라우팅됩니다.
다음 결정 트리는 네트워크 세그먼트 연결에 가장 적합한 접근 방식을 결정하는 데 도움이 됩니다.
다중 네트워크 인터페이스(이전 사례에서 제시하는 첫 번째 접근 방식)를 사용하는 것이 가장 쉬운 구현 방법입니다.
그러나 여러 네트워크 인터페이스를 사용하면 다음과 같은 단점이 있습니다.
- 가상 머신 인스턴스당 네트워크 인터페이스가 8개로 제한됩니다. 인터넷 연결과 온프레미스 연결 하나에 하나의 네트워크 인터페이스를 사용하는 경우 Google Cloud에서 6개의 네트워크 세그먼트만 연결할 수 있습니다. 일부 어플라이언스에는 추가 관리 인터페이스가 필요하며 네트워크 세그먼트는 5개로 제한됩니다.
- 인스턴스가 생성된 후에는 네트워크 인터페이스를 추가하거나 삭제할 수 없습니다.
VPC 네트워크 피어링을 사용하면 다음과 같은 이점이 있습니다.
- 단일 VPC 네트워크의 VPC 네트워크 피어링 연결 한도까지 확장할 수 있습니다. 이 한도를 늘리는 방법에 대해 궁금한 점이 있으면 Google Cloud 영업팀에 문의하세요.
- VPC 네트워크 피어링을 설정하여 이 아키텍처에서 VPC 네트워크를 쉽게 추가하거나 삭제할 수 있습니다.
그러나 VPC 네트워크 피어링을 사용하면 다음과 같은 단점이 있습니다.
- 이 접근 방식은 여러 네트워크 인터페이스를 사용하는 방식보다 약간 더 복잡합니다.
- 연결할 수 있는 VPC 수는 결합된 접근 방식과 비교하여 여전히 제한적입니다.
결합된 접근 방식(다중 네트워크 인터페이스, VPC 네트워크 피어링)을 사용하면 다음과 같은 이점이 있습니다.
- 이 한도는 네트워크 인터페이스의 한도와 VPC 피어링 연결의 한도의 산물이므로 가장 확장성이 뛰어난 접근 방식입니다. 예를 들어 각 인터페이스에 25개의 스포크 VPC 네트워크가 연결된 상태에서 6개의 허브 VPC 네트워크를 연결하여 별도의 네트워크 인터페이스를 구성할 수 있습니다. 이렇게 하면 하나의 가상 어플라이언스 집합을 통해 트래픽을 교환하는 VPC 네트워크가 150개로 제한됩니다.
그러나 이 접근 방식에는 다음과 같은 단점이 있습니다.
- 가장 복잡한 구현 방식입니다.
아키텍처 예시
다음은 두 가지 아키텍처의 예시입니다. 첫 번째 아키텍처 예시에서는 고가용성을 위해 내부 패스 스루 네트워크 부하 분산기를 사용하는 방법과 VPC 네트워크 피어링을 결합하여 네트워크 세그먼트에 연결하는 방법을 보여줍니다. 특수한 사용 사례인 두 번째 아키텍처 예시에서는 Google Cloud의 단일 공유 VPC 네트워크에서 온프레미스 환경과 인터넷으로 트래픽을 라우팅하는 방법을 보여줍니다.
VPC 네트워크 피어링과 내부 패스스루 네트워크 부하 분산기를 다음 홉으로 사용하는 아키텍처 예시
이 아키텍처는 고가용성을 위해 내부 패스 스루 네트워크 부하 분산기를 사용하고 네트워크 세그먼트를 연결하기 위해 VPC 네트워크 피어링과 결합하는 엔터프라이즈 환경의 일반적인 사용 사례입니다.
다음 다이어그램은 이 아키텍처의 토폴로지를 보여줍니다.
위의 다이어그램은 VPC 네트워크 피어링을 사용하여 허브 VPC 네트워크와 피어링된 허브 VPC 네트워크와 여러 스포크 VPC 네트워크를 보여줍니다. 허브 VPC 네트워크에는 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 관리형 인스턴스 그룹에 2개의 가상 어플라이언스 인스턴스가 있습니다. 정적 기본 경로는 내부 패스 스루 네트워크 부하 분산기에 다음 홉으로 연결됩니다. 이 정적 기본 경로는 커스텀 경로를 사용하여 VPC 네트워크 피어링을 통해 내보내집니다. 스포크 VPC 네트워크에서 인터넷 게이트웨이의 기본 경로가 삭제됩니다.
다음과 같은 방법으로 요구사항을 충족할 수 있습니다.
- VPC 네트워크 피어링은 비전이적이므로 스포크 간의 연결은 방화벽을 통해 자동으로 라우팅되기 때문에 스포크 VPC 네트워크는 서로 직접 데이터를 교환할 수 없습니다. 가상 어플라이언스를 구성하여 스포크가 트래픽을 교환할 수 있는 조건과 정책을 설정할 수 있습니다.
- 인터넷 게이트웨이의 기본 경로가 스포크 VPC 네트워크에서 삭제되었으므로 가상 어플라이언스를 통해서만 인터넷에 연결할 수 있습니다. 가상 어플라이언스에는 별도의 네트워크 인터페이스를 통한 기본 경로가 있으며, 이 경로는 NGFW의 경우 신뢰할 수 없음으로 표시될 수 있습니다.
- 온프레미스 네트워크에 대한 연결은 별도의 네트워크 인터페이스에서 가상 어플라이언스에 연결된 연결 VPC 네트워크를 통해 이루어집니다. 이 연결 VPC 네트워크에서 Cloud VPN 또는 Cloud Interconnect 연결이 종료됩니다.
- 고가용성은 내부 부하 분산기의 맞춤 상태 확인을 통해 이루어집니다. 내부 패스 스루 네트워크 부하 분산기의 장애 조치를 사용하여 어플라이언스를 활성/수동으로 구성할 수 있습니다. 이렇게 하면 트래픽이 항상 단일 가상 어플라이언스를 통해 전달됩니다.
다른 VPC 네트워크 간의 통신이 TCP/UDP 또는 다른 프로토콜 트래픽인 경우 이 아키텍처 예를 사용할 수 있습니다. VPC 네트워크당 VPC 네트워크 피어링 연결 한도까지 확장할 수 있습니다.
NAT 게이트웨이를 가상 어플라이언스로 사용하는 이 아키텍처의 샘플 구현은 부하 분산기를 다음 홉으로 사용한 허브 및 스포크 네트워크 배포를 참조하세요. 앞의 사용 사례 섹션에 설명된 대로 동일한 패턴을 사용하여 다른 가상 어플라이언스를 배포 할 수 있습니다.
Google Cloud에 공유 VPC 네트워크가 하나인 특수한 사용 사례
한번의 특수한 사용에서는 서로 다른 VPC 네트워크 간의 트래픽이 가상 어플라이언스를 통과할 필요가 없습니다. 대신 단일 공유 VPC 네트워크의 트래픽만 온프레미스 환경과 인터넷으로 라우팅됩니다. 공유 VPC 네트워크, 온프레미스, Google Cloud에 연결하기 위해 이 문서의 앞부분에서 설명한 고가용성 옵션을 각각 하나의 네트워크 인터페이스와 함께 사용하여 이 사용 사례를 구현할 수 있습니다. 중앙 집중식 어플라이언스를 통해 서브넷을 실행하지 않고 서브넷 간 트래픽을 확인하려는 경우 패킷 미러링이 도움이 될 수 있습니다.
다음 다이어그램은 이 토폴로지를 보여줍니다.
위의 다이어그램은 온프레미스 네트워크와 가상 어플라이언스 풀을 통해 인터넷으로 라우팅되는 단일 공유 VPC 네트워크의 트래픽을 보여줍니다.
가상 어플라이언스로 아키텍처 구현
세그먼트와 내부 패스 스루 네트워크 부하 분산기 간의 VPC 네트워크 피어링을 고가용성 옵션으로 사용하는 방법에 대한 자세한 내용은 부하 분산기를 다음 홉으로 사용한 허브 및 스포크 네트워크 배포를 참조하세요.
Cloud Marketplace 같은 Google Cloud 파트너의 어플라이언스를 배포하려면 어플라이언스 공급업체에 문의하거나 공급업체 웹사이트에서 Google Cloud에 어플라이언스를 배포하는 방법에 대한 가이드라인을 검색하세요.
다음 단계
- VPC 설계에 관한 권장사항 및 참조 아키텍처
- 하이브리드 및 멀티 클라우드 네트워크 토폴로지
- Google Cloud 아키텍처 프레임워크의 네트워크 설계 권장사항
- VPC 문서
- 내부 패스 스루 네트워크 부하 분산기 문서
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.