이 문서는 Cross-Cloud Network를 위한 설계 가이드 시리즈의 일부입니다.
이 시리즈는 다음 문서로 구성됩니다.
- 분산 애플리케이션을 위한 Cross-Cloud Network
- Cross-Cloud Network의 분산형 애플리케이션을 위한 네트워크 세분화 및 연결(이 문서)
- 교차 클라우드 네트워크의 분산형 애플리케이션을 위한 서비스 네트워킹
- Cross-Cloud Network의 분산 애플리케이션을 위한 네트워크 보안
이 파트에서는 설계 기초인 네트워크 세분화 구조와 연결을 살펴봅니다. 이 문서에서는 다음 작업을 수행하는 단계를 설명합니다.
- 전반적인 네트워크 세분화 및 프로젝트 구조
- 워크로드를 배치하는 위치
- 연결, 라우팅, 암호화 설계를 포함하여 프로젝트가 외부 온프레미스 및 기타 클라우드 제공업체 네트워크에 연결되는 방식
- VPC 네트워크가 내부적으로 서로 연결되는 방식
- 서비스 연결 가능성 및 DNS를 설정하는 방법을 포함하여 Google Cloud VPC 서브넷이 서로 연결되고 다른 네트워크에 연결되는 방식
네트워크 세분화 및 프로젝트 구조
계획 단계 중에 다음 두 가지 프로젝트 구조 중 하나를 결정해야 합니다.
- 단일 인프라 호스트 프로젝트를 사용하여 모든 애플리케이션의 모든 네트워킹 리소스를 관리하는 통합 인프라 호스트 프로젝트
- 애플리케이션마다 다른 호스트 프로젝트와 함께 인프라 호스트 프로젝트를 사용하는 세분화된 호스트 프로젝트
계획 단계 중에 워크로드 환경의 관리 도메인도 결정하는 것이 좋습니다. 최소 권한의 원칙에 따라 인프라 관리자와 개발자의 권한 범위를 지정하고 애플리케이션 리소스 범위를 여러 애플리케이션 프로젝트로 지정합니다. 인프라 관리자는 리소스가 공유되도록 연결을 설정해야 하므로 인프라 프로젝트 내에서 인프라 리소스를 처리할 수 있습니다. 예를 들어 공유 인프라 리소스에 대한 연결을 설정하려면 인프라 관리자가 인프라 프로젝트를 사용하여 해당 공유 리소스를 처리하면 됩니다. 동시에 개발팀은 한 프로젝트에서 자신의 워크로드를 관리하고 프로덕션팀은 별도의 프로젝트에서 자신의 워크로드를 관리할 수 있습니다. 그런 다음 개발자는 인프라 프로젝트의 인프라 리소스를 사용하여 자신의 워크로드에 대한 리소스, 서비스, 부하 분산, DNS 라우팅 정책을 만들고 관리합니다.
또한 처음에 구현할 VPC 네트워크 수와 리소스 계층 구조에서 이를 구성하는 방법을 결정해야 합니다. 리소스 계층 구조를 선택하는 방법에 대한 자세한 내용은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참조하세요. VPC 네트워크 수를 선택하는 방법에 대한 자세한 내용은 여러 VPC 네트워크 생성 여부 결정을 참조하세요.
Cross-Cloud Network의 경우 다음 VPC를 사용하는 것이 좋습니다.
- 다른 애플리케이션의 리소스를 호스팅하기 위한 애플리케이션 VPC 하나 이상
- 모든 외부 연결이 처리되는 전송 VPC
- 게시된 서비스에 대한 비공개 액세스 배포를 통합하는 데 사용할 수 있는 선택적 서비스 VPC
다음 다이어그램에서는 방금 설명한 권장 VPC 구조를 시각적으로 보여줍니다. 다음 섹션의 설명처럼 다이어그램에 표시된 VPC 구조를 통합 또는 세분화된 프로젝트 구조로 사용할 수 있습니다. 여기에 표시된 다이어그램에서는 VPC 네트워크 간 연결을 보여주지 않습니다.
통합 인프라 호스트 프로젝트
통합 인프라 호스트 프로젝트를 사용하여 서브넷, 피어링, 부하 분산기와 같은 모든 네트워킹 리소스를 관리할 수 있습니다.
조직 구조와 일치하도록 인프라 호스트 프로젝트에 해당 애플리케이션 서비스 프로젝트가 있는 애플리케이션 공유 VPC 여러 개를 만들 수 있습니다. 여러 애플리케이션 서비스 프로젝트를 사용하여 리소스 관리를 위임합니다. 모든 애플리케이션 VPC의 모든 네트워킹 요금은 통합 인프라 호스트 프로젝트에 청구됩니다.
이 프로젝트 구조에서 여러 애플리케이션 서비스 프로젝트에서 애플리케이션 VPC를 적게 공유할 수 있습니다.
다음 다이어그램에서는 통합 인프라 호스트 프로젝트와 방금 설명한 애플리케이션 서비스 프로젝트 여러 개를 시각적으로 보여줍니다. 이 다이어그램에서는 모든 프로젝트 간의 연결을 보여주지 않습니다.
세분화된 호스트 프로젝트
이 패턴의 각 애플리케이션 그룹에는 자체 애플리케이션 호스트 프로젝트와 VPC가 있습니다. 여러 애플리케이션 서비스 프로젝트를 호스트 프로젝트에 연결할 수 있습니다. 네트워크 서비스 요금 청구는 인프라 호스트 프로젝트와 애플리케이션 호스트 프로젝트 간에 분할됩니다. 인프라 요금은 인프라 호스트 프로젝트에 청구되고 애플리케이션의 네트워크 요금은 각 애플리케이션 호스트 프로젝트에 청구됩니다.
다음 다이어그램에서는 방금 설명한 호스트 프로젝트 여러 개와 애플리케이션 서비스 프로젝트 여러 개를 시각적으로 보여줍니다. 이 다이어그램에서는 모든 프로젝트 간의 연결을 보여주지 않습니다.
워크로드 배치
다양한 연결 옵션은 워크로드의 리전 위치에 따라 달라집니다. 워크로드 배치에 대한 안내는 Compute Engine 리전 선택 권장사항을 참조하세요. 연결 위치를 선택하기 전에 워크로드를 배치할 위치를 결정해야 합니다.
외부 및 하이브리드 연결
이 섹션에서는 다음 연결 경로의 요구사항과 권장사항을 설명합니다.
- 다른 클라우드 제공업체에 대한 비공개 연결
- 온프레미스 데이터 센터에 대한 비공개 연결
- 워크로드 인터넷 연결(특히 아웃바운드 연결)
Cross-Cloud Network에는 멀티 클라우드 네트워크나 온프레미스 네트워크의 상호 연결이 포함됩니다. 여러 조직에서 외부 네트워크를 소유하고 관리할 수 있습니다. 이러한 네트워크는 네트워크 간 인터페이스(NNI) 하나 이상에서 물리적으로 서로 연결됩니다. NNI 조합은 성능, 복원력, 개인 정보 보호, 보안을 위해 설계, 프로비저닝, 구성되어야 합니다.
모듈성, 재사용성, 보안 NVA 삽입 기능을 위해 외부 연결과 라우팅을 전송 VPC에 배치합니다. 그러면 다른 VPC의 공유 연결 서비스 역할을 합니다. 도메인 간의 복원력, 장애 조치, 경로 환경설정을 위한 라우팅 정책은 전송 VPC에서 한 번 구성되며 다른 여러 VPC 네트워크에서 이 정책을 활용할 수 있습니다.
NNI 및 외부 연결 설계는 나중에 내부 연결 및 VPC 네트워킹에 사용됩니다.
다음 다이어그램에서는 VPC 네트워크 피어링, Network Connectivity Center 또는 HA VPN을 통해 연결된 다른 VPC의 공유 연결 서비스 역할을 하는 전송 VPC를 보여줍니다.
다른 클라우드 제공업체에 대한 비공개 연결
다른 클라우드 서비스 제공업체(CSP) 네트워크에서 실행되는 서비스가 있고 이 서비스를 Google Cloud 네트워크에 연결하려면 인터넷이나 비공개 연결을 통해 연결하면 됩니다. 비공개 연결을 사용하는 것이 좋습니다.
옵션을 선택할 때는 처리량, 개인 정보 보호, 비용, 운영 가능성을 고려하세요.
개인 정보 보호를 강화하는 동시에 처리량을 극대화하려면 클라우드 네트워크 간에 고속 직접 연결을 사용합니다. 직접 연결을 사용하면 물리적 중간 네트워킹 장비가 필요하지 않습니다. 이러한 직접 연결뿐만 아니라 MACsec 암호화 및 처리량 속도(링크당 최대 100Gbps)를 제공하는 Cross-Cloud Interconnect를 사용하는 것이 좋습니다.
Cross-Cloud Interconnect를 사용할 수 없으면 코로케이션 시설을 통해 Dedicated Interconnect 또는 Partner Interconnect를 사용하면 됩니다.
대상 리전에 대한 위치 근접성을 기준으로 다른 CSP에 연결할 위치를 선택합니다. 위치 선택 시 다음 사항을 고려하세요.
- 위치 목록을 확인합니다.
- Cross-Cloud Interconnect의 경우 Google Cloud와 CSP 모두에 사용할 수 있는 위치 목록을 확인합니다. 가용성은 클라우드 제공업체에 따라 다릅니다.
- Dedicated Interconnect 또는 Partner Interconnect의 경우 코로케이션 시설에 대한 지연 시간이 짧은 위치를 선택합니다.
- 지정된 접속 지점(POP) 에지와 각 CSP의 관련 리전 간의 지연 시간을 평가합니다.
클라우드 간 연결 신뢰성을 극대화하려면 프로덕션 워크로드에 99.99% 업타임 SLA를 지원하는 구성을 사용하는 것이 좋습니다. 자세한 내용은 Cross-Cloud Interconnect 고가용성, Dedicated Interconnect를 위한 99.99%의 가용성 설정, Partner Interconnect를 위한 99.99%의 가용성 설정을 참조하세요.
서로 다른 CSP 간에 높은 대역폭이 필요하지 않으면 VPN 터널을 사용할 수 있습니다. 이 방식은 시작하는 데 도움이 될 수 있으며 분산 애플리케이션에서 더 많은 대역폭을 사용하면 Cross-Cloud Interconnect로 업그레이드할 수 있습니다. VPN 터널은 99.99% SLA도 달성할 수 있습니다. 자세한 내용은 HA VPN 토폴로지를 참조하세요.
온프레미스 데이터 센터에 대한 비공개 연결
비공개 데이터 센터에 연결하려면 다음 하이브리드 연결 옵션 중 하나를 사용하면 됩니다.
- Dedicated Interconnect
- Partner Interconnect
- HA VPN
이러한 연결의 라우팅 고려사항은 다른 클라우드 제공업체에 대한 비공개 연결의 라우팅 고려사항과 유사합니다.
다음 다이어그램에서는 온프레미스 네트워크 연결과 피어링 정책을 통해 온프레미스 라우터가 Cloud Router에 연결하는 방법을 보여줍니다.
외부 네트워크를 사용한 도메인 간 라우팅
네트워크 간 복원력과 처리량을 향상시키려면 여러 경로를 사용하여 네트워크를 연결합니다.
트래픽이 네트워크 도메인 간에 전송될 때 스테이트풀(Stateful) 보안 기기에서 검사해야 합니다. 따라서 도메인 간 경계에서 흐름이 대칭되어야 합니다.
여러 리전 간에 데이터를 전송하는 네트워크의 경우 각 네트워크의 비용과 서비스 품질 수준이 크게 다를 수 있습니다. 이러한 차이점에 따라 일부 네트워크를 다른 네트워크 대신 사용하도록 결정할 수 있습니다.
리전 간 전송, 트래픽 균형, 처리량, 복원력에 대한 요구사항이 충족되도록 도메인 간 라우팅 정책을 설정합니다.
도메인 간 라우팅 정책 구성은 각 도메인의 에지에서 사용할 수 있는 기능에 따라 다릅니다. 또한 구성은 서로 다른 리전의 자율 시스템과 IP 주소 지정(서브넷) 관점에서 인접 도메인이 구조화되는 방식에 따라 달라집니다. 에지 기기의 프리픽스 한도를 초과하지 않고 확장성을 향상시키려면 IP 주소 지정 계획에서 각 리전과 도메인 조합의 집계 프리픽스를 줄이는 것이 좋습니다.
리전 간 라우팅을 설계할 때는 다음을 고려하세요.
- Google Cloud VPC 네트워크와 Cloud Router 모두 전역 리전 간 라우팅을 지원합니다. 다른 CSP에는 리전 VPC 및 경계 게이트웨이 프로토콜(BGP) 범위가 있을 수 있습니다. 자세한 내용은 다른 CSP의 문서를 참조하세요.
- Cloud Router는 리전 근접성을 기준으로 경로를 미리 결정된 경로 환경설정으로 자동 공지합니다. 이 라우팅 동작은 VPC의 구성된 동적 라우팅 모드에 따라 달라집니다. 원하는 라우팅 동작에 대해 이러한 환경설정을 재정의해야 할 수도 있습니다.
- CSP마다 서로 다른 BGP 및 양방향 전송 감지(BFD) 기능을 지원하며 Google의 Cloud Router에는 BGP 세션 설정에 설명된 특정 경로 정책 기능도 있습니다.
- CSP마다 서로 다른 BGP 결정 속성을 사용하여 경로 환경설정을 지정할 수 있습니다. 자세한 내용은 CSP의 문서를 참조하세요.
단일 리전 도메인 간 라우팅
도메인 간 라우팅을 사용하여 리전 연결 여러 개를 만들기 위해 빌드한 단일 리전 도메인 간 라우팅을 시작하는 것이 좋습니다.
Cloud Interconnect를 사용하는 설계에는 동일한 리전에 있지만 에지 가용성 도메인이 다른 연결 위치가 최소 2개 이상 있어야 합니다.
이러한 중복 연결을 활성/활성 또는 활성/수동 설계에서 구성할지 여부를 결정합니다.
- 활성/활성은 등가 멀티 경로(ECMP) 라우팅을 사용하여 두 경로 모두의 대역폭을 집계하고 도메인 간 트래픽에 동시에 사용합니다. 또한 Cloud Interconnect는 LACP 집계 링크를 사용하여 경로당 집계 대역폭을 최대 200Gbps까지 달성할 수 있습니다.
- 활성/수동은 링크 하나를 준비 대기로 적용하므로 활성 링크가 중단된 경우에만 트래픽을 처리합니다.
리전 내 링크에는 활성/활성 설계를 사용하는 것이 좋습니다. 그러나 스테이트풀(Stateful) 보안 기능 사용과 결합된 특정 온프레미스 네트워킹 토폴로지에는 활성/수동 설계가 필요할 수 있습니다.
Cloud Router는 여러 영역에서 인스턴스화되므로 단일 요소에서 제공하는 복원력 보다 높은 복원력을 제공합니다. 다음 다이어그램에서는 리전 내의 단일 Cloud Router에서 복원력이 우수한 모든 연결이 수렴하는 방식을 보여줍니다. 이 설계는 Dedicated Interconnect를 위한 99.9%의 가용성 설정 가이드라인을 따르면 단일 권역 내에서 99.9% 가용성 SLA를 지원할 수 있습니다.
다음 다이어그램에서는 단일 리전의 관리형 Cloud Router 서비스에 중복으로 연결된 온프레미스 라우터 2개를 보여줍니다.
멀티 리전 도메인 간 라우팅
백업 연결을 제공하기 위해 여러 지리적 영역에서 네트워크를 피어링할 수 있습니다. 여러 리전의 네트워크를 연결하면 가용성 SLA가 99.99%까지 증가할 수 있습니다.
다음 다이어그램에서는 99.99% SLA 아키텍처를 보여줍니다. 서로 다른 두 리전의 관리형 Cloud Router 서비스에 중복으로 연결된 서로 다른 위치 2곳에 있는 온프레미스 라우터를 보여줍니다.
복원력 외에도 멀티 리전 라우팅 설계에서 흐름이 대칭되어야 합니다. 또한 설계는 hot-potato 및 cold-potato 라우팅으로 수행할 수 있는 리전 간 통신에 선호되는 네트워크를 나타내야 합니다. 한 도메인의 cold-potato 라우팅을 피어 도메인의 hot-potato 라우팅과 페어링합니다. cold-potato 도메인의 경우 전역 VPC 라우팅 기능을 제공하는 Google Cloud 네트워크 도메인을 사용하는 것이 좋습니다.
흐름 대칭이 항상 필수는 아니지만 흐름 비대칭으로 인해 스테이트풀(Stateful) 보안 기능에 문제가 발생할 수 있습니다.
다음 다이어그램에서는 hot-potato 및 cold-potato 라우팅을 사용하여 선호하는 리전 간 전송 네트워크를 지정하는 방법을 보여줍니다. 이 경우 프리픽스 X 및 Y의 트래픽은 대상에 가장 가까운 리전(cold-potato 라우팅)에 도달할 때까지 원래 네트워크에서 유지됩니다. 프리픽스 A와 B의 트래픽은 원래 리전의 다른 네트워크로 전환한 후 다른 네트워크에서 대상으로 이동합니다(hot-potato 라우팅).
도메인 간 트래픽 암호화
달리 명시되지 않는 한 트래픽은 서로 다른 CSP 간 또는 Google Cloud와 온프레미스 데이터 센터 간의 Cloud Interconnect 연결에서 암호화되지 않습니다. 조직에서 이 트래픽을 암호화해야 하는 경우 다음 기능을 사용할 수 있습니다.
- Cloud Interconnect용 MACsec: 라우터와 Google 에지 라우터 간의 Cloud Interconnect 연결을 통한 트래픽을 암호화합니다. 자세한 내용은 Cloud Interconnect용 MACsec 개요를 참조하세요.
- Cloud Interconnect를 통한 HA VPN: 기본 Cloud Interconnect 연결의 전체 대역폭을 제공할 수 있도록 HA VPN 터널 여러 개를 사용합니다. HA VPN 터널은 IPsec으로 암호화되며 MACsec 암호화일 수도 있는 Cloud Interconnect 연결을 통해 배포됩니다. 이 구성에서 Cloud Interconnect 연결은 HA VPN 트래픽만 허용하도록 구성됩니다. 자세한 내용은 Cloud Interconnect를 통한 HA VPN 개요를 참조하세요.
워크로드 인터넷 연결
인바운드 및 아웃바운드 인터넷 연결에서는 응답 트래픽이 원래 요청 방향의 역방향을 스테이트풀(Stateful)로 따른다고 가정합니다.
일반적으로 인바운드 인터넷 연결을 제공하는 기능은 아웃바운드 인터넷 기능과 별개이며 두 방향을 동시에 제공하는 외부 IP 주소는 예외입니다.
인바운드 인터넷 연결
인바운드 인터넷 연결은 주로 클라우드에서 호스팅되는 서비스에 공개 엔드포인트를 제공하는 것과 관련이 있습니다. Google Cloud에서 호스팅되는 웹 애플리케이션 서버와 게임 서버에 대한 인터넷 연결이 여기에 해당합니다.
인바운드 인터넷 연결을 제공하는 주요 기능은 Google의 Cloud Load Balancing 제품입니다.
모든 유형의 Cloud Load Balancing은 VPC 특수 반환 경로 또는 사용자 정의 프록시 사용 여부에 관계없이 인터넷 소스로 반환되는 트래픽에 자체 경로를 제공합니다. VPC 설계는 일반적으로 인바운드 인터넷 연결을 제공하는 기능과 무관합니다.
아웃바운드 인터넷 연결
아웃바운드 인터넷 연결(초기 요청이 워크로드에서 인터넷 대상으로 향하는 연결)의 예시로는 서드 파티 API에 액세스하는 워크로드, 소프트웨어 패키지 및 업데이트를 다운로드하는 워크로드, 인터넷에서 푸시 알림을 웹훅 엔드포인트로 보내는 워크로드가 있습니다.
비공개 VM용 인터넷 연결 빌드의 설명대로 아웃바운드 연결에 Google Cloud 기본 제공 옵션을 사용할 수 있습니다. 또는 네트워크 보안의 설명대로 중앙 NGFW NVA를 사용할 수 있습니다.
아웃바운드 인터넷 연결을 제공하는 기본 경로는 VPC 라우팅 테이블의 기본 인터넷 게이트웨이 대상이며 Google VPC의 기본 경로인 경우가 많습니다. 외부 IP와 Cloud NAT(Google Cloud의 관리형 NAT 서비스) 모두 VPC의 기본 인터넷 게이트웨이를 가리키는 경로가 필요합니다. 따라서 기본 경로를 재정의하는 VPC 라우팅 설계에서 다른 방법을 통해 아웃바운드 연결을 제공해야 합니다. 자세한 내용은 Cloud Router 개요를 참조하세요.
아웃바운드 연결을 보호하기 위해 Google Cloud는 Cloud 차세대 방화벽 시행과 보안 웹 프록시를 모두 제공하여 HTTP 및 HTTPS URL에 대해 심층적인 필터링을 제공합니다. 하지만 모든 경우에 트래픽은 기본 인터넷 게이트웨이로 또는 VPC 라우팅 테이블의 커스텀 기본 경로를 통해 나가는 기본 경로를 따릅니다.
자체 IP 사용
인터넷 연결에 Google 소유 IPv4 주소를 사용하거나 자체 IP 주소 사용(BYOIP)을 사용하여 조직에서 소유한 IPv4 공간을 사용할 수 있습니다. 인터넷 라우팅이 가능한 IP 주소가 필요한 대부분의 Google Cloud 제품은 대신 BYOIP 범위를 사용할 수 있습니다.
또한 배타적인 사용을 통해 IP 공간의 평판을 제어할 수 있습니다. BYOIP는 연결 이동성에 도움이 되고 IP 주소 비용을 절약할 수 있습니다.
내부 연결 및 VPC 네트워킹
외부 및 하이브리드 연결 서비스를 구성하면 전송 VPC의 리소스가 외부 네트워크에 연결할 수 있습니다. 다음 단계를 수행하면 다른 VPC에서 호스팅되는 리소스에 이 연결을 사용할 수 있습니다.
다음 다이어그램에서는 외부 연결을 사용 설정한 방법에 관계없이 VPC의 일반적인 구조를 보여줍니다. 외부 연결을 종료하고 모든 리전에서 Cloud Router를 호스팅하는 전송 VPC를 보여줍니다. 각 Cloud Router는 각 리전의 NNI를 통해 외부 피어에서 경로를 수신합니다. 애플리케이션 VPC는 전송 VPC에 연결되므로 외부 연결을 공유할 수 있습니다. 또한 전송 VPC는 스포크 VPC의 허브로 작동합니다. 스포크 VPC는 애플리케이션, 서비스 또는 이 둘의 조합을 호스팅할 수 있습니다.
전송 VPC에서도 DNS 전달과 피어링을 구성합니다. 자세한 내용은 DNS 인프라 설계 섹션을 참조하세요.
성능 향상과 기본 제공 클라우드 네트워킹 서비스를 위해 VPC를 HA VPN 대신 Cross-Cloud Network 또는 VPC 네트워크 피어링과 상호 연결하는 것이 좋습니다.
Private Service Connect 엔드포인트와 비공개 서비스 액세스 프런트엔드는 VPC 네트워크 피어링 또는 Cross-Cloud Network를 통해 연결될 수 없습니다. 이러한 제한사항을 해결하려면 VPC 간 연결에 HA VPN을 사용하는 것이 좋습니다. VPC 간 연결에 HA VPN을 사용하면 처리량이 줄어들고 운영 오버헤드가 증가될 수 있으므로 중앙 집중식 서비스 설계에서는 HA VPN 배포 범위를 줄입니다.
또는 서비스 엔드포인트 앞에 내부 프록시 네트워크 부하 분산기를 배치하여 게시된 서비스 엔드포인트에 대한 VPC 간 전환 연결을 구현할 수 있습니다. 이 방식에는 고려해야 할 몇 가지 제한사항이 있습니다. 이에 대해서는 부하 분산을 사용하여 Network Connectivity Center 스포크와 연결 섹션에서 설명합니다.
다음 섹션에서는 API 엔드포인트 배포는 물론 기본 IP 연결을 지원하는 하이브리드 연결에 사용 가능한 설계를 설명합니다.
공유 서비스 액세스를 위한 VPC 간 연결
게시된 서비스 엔드포인트가 서비스 VPC에 배포되면 애플리케이션 VPC가 VPC 네트워크 피어링을 통해 허브(전송 VPC)에 연결하고 서비스 VPC가 HA VPN을 통해 허브에 연결하는 것을 권장합니다.
이 설계에서 전송 VPC가 허브이며 서비스 VPC에 비공개 서비스 엔드포인트에 대한 소비자 액세스 포인트를 배포합니다.
이 설계는 두 가지 연결 유형의 조합입니다.
- VPC 네트워크 피어링: 허브 VPC 및 애플리케이션 VPC 간의 연결을 제공합니다.
- HA VPN VPC 간 연결: 서비스 VPC의 전환 연결을 허브에 제공합니다.
이러한 연결 유형을 배포하기 위한 자세한 안내와 구성 청사진은 허브 및 스포크 네트워크 아키텍처를 참조하세요.
이러한 아키텍처를 결합할 때는 다음 고려사항을 계획합니다.
- VPC 피어 서브넷을 동적 라우팅으로 재배포(HA VPN 및 하이브리드로)
- 멀티 리전 라우팅 고려사항
- 동적 경로를 VPC 피어링으로 전파(HA VPN 및 하이브리드에서)
다음 다이어그램에서는 HA VPN으로 전송 VPC에 연결된 서비스 VPC와 VPC 네트워크 피어링으로 전송 VPC에 연결된 애플리케이션 VPC를 보여줍니다.
위 다이어그램에 표시된 구조에는 다음과 같은 구성요소가 포함됩니다.
- 고객 위치: 네트워크 장비가 있는 데이터 센터나 원격 사무실입니다. 이 예시에서는 위치가 외부 네트워크를 통해 서로 연결되어 있다고 가정합니다.
- 권역: Cloud Interconnect 에지 가용성 도메인이 하나 이상 포함된 권역입니다. Cloud Interconnect는 이러한 권역의 다른 네트워크에 연결됩니다.
- 허브 프로젝트: 다른 VPC 네트워크의 허브 역할을 하는 VPC 네트워크를 최소 하나 이상 호스팅하는 프로젝트입니다.
- 전송 VPC: 온프레미스와 다른 CSP에서 연결을 수행한 후 다른 VPC에서 온프레미스와 CSP 네트워크까지 전송 경로 역할을 하는 허브 프로젝트의 VPC 네트워크입니다.
- 앱 호스트 프로젝트 및 VPC: 다양한 애플리케이션을 호스팅하는 프로젝트 및 VPC 네트워크입니다.
- 서비스 VPC: 애플리케이션 VPC 네트워크의 애플리케이션에 필요한 서비스에 대한 중앙 집중식 액세스를 호스팅하는 VPC 네트워크입니다.
- 관리형 서비스 VPC: 다른 항목에서 제공하고 관리하지만 VPC 네트워크에서 실행되는 애플리케이션에 액세스할 수 있는 서비스입니다.
허브 및 스포크 설계의 경우 애플리케이션 VPC가 서로 통신해야 하면 애플리케이션 VPC를 스포크로 Network Connectivity Center 허브에 연결하면 됩니다. 이 방법은 Network Connectivity Center 허브의 모든 VPC 간에 연결을 제공합니다. Network Connectivity Center 허브를 여러 개 사용하여 통신 하위 그룹을 만들 수 있습니다. 방화벽 정책을 사용하여 특정 허브 내 엔드포인트 간에 필요한 통신 제한사항을 구현할 수 있습니다.
부하 분산을 사용하여 Network Connectivity Center 스포크 VPC와 연결
이 패턴에는 Network Connectivity Center 허브의 모든 VPC가 스포크로 포함되며 상호 연결된 VPC를 최대 250개까지 수용할 수 있습니다. Network Connectivity Center 허브는 Network Connectivity Center 허브에 스포크로 등록된 모든 VPC 네트워크 간에 전체 메시 데이터 영역 연결을 만드는 관리 영역 구조입니다. 이 패턴은 원활한 연결을 제공하고 모든 VPC의 관리형 서비스에 액세스 포인트를 배포할 수 있게 해줍니다.
전환 제한사항을 해결하기 위해 관리형 서비스 및 하이브리드 연결에 대한 액세스 포인트에 내부 프록시 네트워크 부하 분산기를 통해 액세스합니다. east-west 연결의 워크로드 보안에서 Cloud 차세대 방화벽을 사용할 수 있습니다. 이 패턴에서 Inter-VPC NAT를 사용할 수도 있습니다.
이 패턴에는 몇 가지 제한사항이 있으므로 이 패턴을 채택하기 전에 다음 사항을 고려해야 합니다.
- 이 패턴에서는 경계 방화벽에 NVA를 사용할 수 없습니다. 경계 방화벽은 외부 네트워크에 있어야 합니다.
- 외부 네트워크와의 TCP 트래픽만 지원됩니다. 외부 네트워크에 대한 연결이 내부 프록시 네트워크 부하 분산기를 통해 실행되므로 이 제한이 발생합니다.
- 게시된 서비스에는 프록시 부하 분산기의 추가 프런트엔드가 있습니다. 이 추가 프런트엔드는 DNS에서 추가 레코드를 확산하며 분할 DNS 조회를 요구합니다.
- 레이어 4 서비스에는 모든 새 서비스에 대한 새로운 내부 프록시 네트워크 부하 분산기가 필요합니다. 연결에 필요한 프로토콜에 따라 다른 부하 분산기가 필요할 수 있습니다.
- 부하 분산 할당량은 VPC 네트워크마다 제한됩니다. 레이어 4 서비스에는 대상 서비스마다 새로운 내부 프록시 네트워크 부하 분산기가 필요하므로 이는 중요한 고려사항입니다.
- 선택한 고가용성 및 리전 간 장애 조치 설계 옵션은 요구사항에 따라 달라집니다.
- 하이브리드 경계 간에 암호화된 트래픽은 인증서 관리 조정에 영향을 미칩니다.
앞선 고려사항이 관리 가능한 타협이거나 환경과 관련이 없는 경우에는 이 패턴을 선호하는 옵션으로 사용하는 것이 좋습니다.
다음 다이어그램에서는 Network Connectivity Center 하이브리드 허브를 Cloud Interconnect 연결의 관리 영역으로 보여줍니다. 또한 애플리케이션과 서비스 VPC 스포크를 연결하는 Network Connectivity Center VPC 허브를 보여줍니다.
전이성을 위한 프록시 부하 분산
Network Connectivity Center 스포크 VPC에서는 다음 항목에 연결할 수 없습니다.
- Private Service Connect 서비스 엔드포인트 및 관리형 서비스 프런트엔드
- 하이브리드 연결(Cloud Interconnect 또는 HA VPN) 뒤에 있는 네트워크(동적 경로가 Cross-Cloud Network를 통해 전파되지 않기 때문)
하이브리드 네트워크 엔드포인트 그룹(NEG)으로 처리되는 비전환 리소스와 함께 내부 프록시 네트워크 부하 분산기를 배포하면 이러한 전이성 제한사항을 해결할 수 있습니다. 내부 프록시 네트워크 부하 분산기를 서비스 프런트엔드 앞과 하이브리드 연결을 통해 연결할 수 있는 엔드포인트 앞에 배포할 수 있습니다. 내부 프록시 네트워크 부하 분산기 프런트엔드는 Cross-Cloud Network 스포크 VPC에서 전파되는 VPC 서브넷에 배포됩니다. 내부 프록시 네트워크 부하 분산기는 비전환 리소스의 Cross-Cloud Network를 통해 연결될 수 있습니다. 외부 호스트 및 서비스, Private Service Connect 엔드포인트, 비공개 서비스 액세스 네트워크의 경우 백엔드를 하이브리드 NEG로 구성해야 합니다. Private Service Connect 백엔드는 NEG가 하이브리드일 필요가 없는 유일한 모델입니다.
DNS 인프라 설계
하이브리드 환경에서는 Cloud DNS 또는 외부(온프레미스 또는 CSP) 제공업체가 DNS 조회를 처리할 수 있습니다. 외부 DNS 서버에는 외부 DNS 영역에 대한 권한이 있으며 Cloud DNS에는 Google Cloud 영역에 대한 권한이 있습니다. Google Cloud와 외부 네트워크 간에 DNS 전달을 양방향으로 사용 설정해야 하며 DNS 변환 트래픽이 허용되도록 방화벽을 설정해야 합니다.
여러 애플리케이션 서비스 프로젝트의 관리자가 자체 서비스를 인스턴스화할 수 있는 중앙 서비스 VPC에 공유 VPC를 사용하는 경우 DNS 영역의 프로젝트 간 바인딩을 사용합니다. 프로젝트 간 바인딩을 사용하면 DNS 네임스페이스를 세분화하고 서비스 프로젝트 관리자에게 위임할 수 있습니다.
외부 네트워크가 Google Cloud를 통해 다른 외부 네트워크와 통신하는 전송 케이스에서는 요청이 서로에게 직접 전달되도록 외부 DNS 영역을 구성해야 합니다. Google Cross-Cloud Network는 DNS 요청과 응답이 완료되도록 연결을 제공하지만 Google Cloud DNS는 외부 네트워크의 영역 간에 DNS 변환 트래픽을 전달합니다. Cross-Cloud Network에 적용된 모든 방화벽 규칙은 외부 네트워크 간의 DNS 변환 트래픽을 허용해야 합니다.
다음 다이어그램에서는 이 설계 가이드에서 제안된 모든 허브 및 스포크 VPC 연결 구성에 사용할 수 있는 DNS 설계를 보여줍니다.
위 다이어그램에서는 설계 흐름의 다음 단계를 보여줍니다.
- 온프레미스 DNS
온프레미스 DNS 서버에 온프레미스 DNS 영역에 대한 권한이 있도록 구성합니다. 허브 VPC의 인바운드 서버 정책 구성을 통해 생성된 Cloud DNS 인바운드 전달 IP 주소를 타겟팅하여 DNS 전달(Google Cloud DNS 이름)을 구성합니다. 이 구성을 사용하면 온프레미스 네트워크에서 Google Cloud DNS 이름을 확인할 수 있습니다. - 전송 VPC - DNS 이그레스 프록시
Cloud Router를 사용하여 Google DNS 이그레스 프록시 범위35.199.192.0/19를 온프레미스 네트워크에 공지합니다. Google에서 온프레미스로 전송되는 아웃바운드 DNS 요청을 이 IP 주소 범위에서 가져옵니다. - 전송 VPC - Cloud DNS
- 온프레미스의 인바운드 DNS 요청에 대한 인바운드 서버 정책을 구성합니다.
- 온프레미스 DNS 서버를 타겟팅하는 Cloud DNS 전달 영역(온프레미스 DNS 이름)을 구성합니다.
- 서비스 VPC - Cloud DNS
- 앱 호스트 프로젝트 - Cloud DNS
- 허브 VPC를 피어 네트워크로 설정하여 온프레미스 DNS 이름에 대한 앱 DNS 피어링 영역을 구성합니다. 온프레미스 호스트의 DNS 변환은 허브 VPC를 거칩니다.
- 앱 호스트 프로젝트에서 앱 DNS 비공개 영역을 구성하고 애플리케이션 VPC, 서비스 공유 VPC, 허브 VPC를 영역에 연결합니다. 이 구성을 사용하면 온프레미스 및 모든 서비스 프로젝트의 모든 호스트에서 앱 DNS 이름을 확인할 수 있습니다.
자세한 내용은 스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처를 참조하세요.
다음 단계
- 교차 클라우드 네트워크 애플리케이션을 위한 서비스 네트워킹을 설계합니다.
- 이 설계 가이드에서 사용되는 Google Cloud 제품을 자세히 알아보세요.
- 방화벽 NVA 배포 방법은 Google Cloud의 중앙 집중식 네트워크 어플라이언스를 참조하세요.
- 더 많은 참조 아키텍처, 설계 가이드, 권장사항을 알아보려면 클라우드 아키텍처 센터를 살펴보세요.
기여자
저자:
- 빅터 모레노 | Cloud Networking 제품 관리자
- Ghaleb Al-habian | 네트워크 전문가
- Deepak Michael | 네트워킹 전문 고객 엔지니어
- Osvaldo Costa | 네트워킹 전문 고객 엔지니어
- Jonathan Almaleh | 직원 기술 솔루션 컨설턴트
기타 참여자:
- Zach Seils | 네트워킹 전문가
- Christopher Abraham | 네트워킹 전문가 고객 엔지니어
- Emanuele Mazza | 네트워킹 제품 전문가
- Aurélien Legrand | 전략적 클라우드 엔지니어
- Eric Yu | 네트워킹 전문가 고객 엔지니어
- 저자: 쿠마르 다나고팔 | 크로스 프로덕트 솔루션 개발자
- 마크 슐라겐하우프 | 네트워킹 테크니컬 라이터
- 마르완 알 샤위 | 파트너 고객 엔지니어
- Ammett Williams | 개발자 관계 엔지니어