Google Cloud 시작 영역의 네트워크 설계 결정

Last reviewed 2024-10-31 UTC

시작 영역을 설계할 때는 조직에 적합한 네트워크 설계를 선택해야 합니다. 이 문서에서는 네 가지 일반적인 네트워크 설계에 대해 설명하고 조직의 요구사항에 가장 적합한 옵션 및 중앙 집중식 제어 또는 분산식 제어에 대한 조직의 선호도를 선택하는 데 도움이 됩니다. 이 가이드는 조직의 시작 영역에 맞게 네트워크 설계를 만드는 데 필요한 네트워크 엔지니어, 설계자, 기술 담당자를 대상으로 합니다.

이 문서는 시작 영역에 대한 시리즈의 일부입니다.

네트워크 설계 선택

네트워크 설계 선택은 주로 다음 요소에 따라 달라집니다.

  • 중앙 집중식 또는 분산식 제어: 조직 환경설정에 따라 다음 중 하나를 선택해야 합니다.
    • IP 주소 지정, 라우팅, 여러 다른 워크로드 간 방화벽 구성을 포함하여 네트워크를 통해 제어를 중앙 집중화합니다.
    • 자체 환경을 실행하고 스스로 환경 내에서 네트워크 요소를 빌드하는 데 있어서 더 많은 자율 권한을 팀에 부여합니다.
  • 온프레미스 또는 하이브리드 클라우드 연결 옵션: 이 문서에서 설명하는 모든 네트워크 설계는 Cloud VPN 또는 Cloud Interconnect를 통해 온프레미스에서 클라우드 환경으로의 액세스를 제공합니다. 하지만 일부 설계에서는 여러 연결을 병렬로 설정해야 하고, 일부에서는 모든 워크로드에 대해 동일한 연결이 사용됩니다.
  • 보안 요구사항: 조직에서 차세대 방화벽(NGFW)과 같은 중앙화된 네트워크 어플라이언스를 통과하기 위해 Google Cloud의 다양한 워크로드 간 트래픽이 필요할 수 있습니다. 이 제약조건은 Virtual Private Cloud(VPC) 네트워크 설계에 영향을 미칩니다.
  • 확장성: 배포하려는 워크로드 수, 가상 머신(VM) 수, 내부 부하 분산기 및 사용할 기타 리소스에 따라 조직에 더 적합한 설계가 있을 수 있습니다.

네트워크 설계 결정 사항

다음 플로우 차트는 조직에 가장 적합한 네트워크 설계를 선택하기 위해 결정해야 하는 사항을 보여줍니다.

네트워크 설계 결정 사항입니다.

위의 다이어그램에서는 다음 질문을 안내합니다.

  1. Google Cloud의 여러 워크로드 간에 네트워크 어플라이언스를 사용하는 레이어 7 검사가 필요한가요?
  2. 많은 워크로드에 온프레미스 연결이 필요한가요?
    • 답이 '예'인 경우 결정 지점 4로 이동합니다.
    • 답이 '아니요'라면 다음 질문으로 넘어갑니다.
  3. 워크로드가 서비스 생산자 및 소비자 모델에서 비공개 엔드포인트를 사용하여 통신할 수 있나요?
  4. 방화벽 구성 및 라우팅을 중앙에서 관리하길 원하나요?

이 차트는 결정을 내리는 데 도움이 되지만 여러 설계가 조직에 적합한 경우가 많습니다. 이러한 경우 사용 사례에 가장 적합한 설계를 선택하는 것이 좋습니다.

네트워크 설계 옵션

다음 섹션에서는 일반적인 설계 옵션에 대해 설명합니다. 대부분의 사용 사례에서는 옵션 1이 권장됩니다. 이 섹션에서 설명하는 다른 설계는 특정 조직별로 극단적인 사례 요구사항에 적용되는 대안입니다.

또한 이 섹션에서 설명된 여러 설계 옵션의 요소들을 조합한 네트워크가 사용 사례에 가장 적합할 수 있습니다. 예를 들어 협업 향상, 중앙 집중식 제어, VPC 스포크 수 제한을 위해 허브 및 스포크 토폴로지에서 공유 VPC 네트워크를 사용할 수 있습니다. 또는 공유 VPC 토폴로지에서 대부분의 워크로드를 설계할 수 있지만 Private Service Connect를 사용해 일부 정의된 엔드포인트를 통해서만 서비스를 노출하는 별도의 VPC 네트워크에 소수의 네트워크를 격리할 수 있습니다.

옵션 1: 각 환경의 공유 VPC 네트워크

이 네트워크 설계는 대부분의 사용 사례에서 권장됩니다. 이 설계에서는 Google Cloud에 있는 각 배포 환경(개발, 테스트, 프로덕션)에 대해 개별 공유 VPC 네트워크가 사용됩니다. 이 설계는 일반 네트워크의 네트워크 리소스를 중앙 집중식으로 관리할 수 있고 서로 다른 환경 간에 네트워크 격리를 제공합니다.

다음 조건에 해당할 경우 이 설계를 사용합니다.

  • 방화벽 구성 및 라우팅 규칙에 대한 중앙 관리가 필요합니다.
  • 간단하고 확장 가능한 인프라가 필요합니다.
  • 중앙 집중식 IP 주소 공간 관리가 필요합니다.

다음 조건에 해당하는 경우 이 설계를 사용하지 마세요.

  • 자체 방화벽 규칙, 라우팅, 다른 팀 네트워크에 대한 피어링을 관리하는 기능을 포함하여 완전한 자율 권한을 개발자 팀에 부여해야 합니다.
  • NGFW 어플라이언스를 사용하는 레이어 7 검사가 필요합니다.

다음 다이어그램은 이 설계의 구현 예시를 보여줍니다.

옵션 1 다이어그램.

앞의 다이어그램은 다음을 보여줍니다.

  • 온프레미스 네트워크가 2개의 지리적 위치에 분산되어 있습니다.
  • 온프레미스 네트워크가 중복 Cloud Interconnect 인스턴스를 통해 각각 프로덕션 및 개발용에 해당하는 2개의 개별 공유 VPC 네트워크에 연결합니다.
  • 프로덕션 및 개발 환경이 서로 다른 VLAN 연결을 사용하여 두 Cloud Interconnect 인스턴스에 연결됩니다.
  • 각 공유 VPC에 워크로드를 호스팅하는 서비스 프로젝트가 포함됩니다.
  • 방화벽 규칙이 호스트 프로젝트에서 중앙 집중식으로 관리됩니다.
  • 개발 환경에 프로덕션 환경과 동일한 VPC 구조가 포함됩니다.

설계상 한 환경의 트래픽은 다른 환경에 도달할 수 없습니다. 하지만 특정 워크로드가 서로 통신해야 하는 경우 온프레미스의 제어된 채널을 통해 데이터를 전송하거나 Cloud Storage 또는Pub/Sub 등의 Google Cloud 서비스로 애플리케이션 간에 데이터를 공유할 수 있습니다. 환경 간에 데이터가 혼합될 위험이 증가하므로 VPC 네트워크 피어링을 통해 구분된 환경을 직접 연결하는 것은 권장되지 않습니다. 대규모 환경 간에 VPC 네트워크 피어링을 사용해도 피어링 및 피어링 그룹과 관련된 VPC 할당량에 도달할 위험이 증가합니다.

자세한 내용은 다음을 참조하세요.

이 설계 옵션을 구현하려면 만들기 옵션 1: 각 환경의 공유 VPC 네트워크를 참조하세요.

옵션 2: 중앙 집중식 어플라이언스를 사용하는 허브 및 스포크 토폴로지

이 네트워크 설계에서는 허브 및 스포크 토폴로지가 사용됩니다. 허브 VPC 네트워크에는 워크로드를 포함하는 스포크 VPC 네트워크에 연결된 NGFW와 같은 어플라이언스 VM 집합이 포함되어 있습니다. 워크로드, 온프레미스 네트워크, 인터넷 사이의 트래픽은 검사 및 필터링을 위해 어플라이언스 VM을 통해 라우팅됩니다.

다음 조건에 해당할 경우 이 설계를 사용합니다.

  • 워크로드 또는 애플리케이션 간에 레이어 7 검사가 필요합니다.
  • 모든 트래픽에 대해 보안 어플라이언스 공급업체를 지정하는 회사 규정이 있습니다.

다음 조건에 해당하는 경우 이 설계를 사용하지 마세요.

  • 대부분의 워크로드에 레이어 7 검사가 필요하지 않습니다.
  • Google Cloud의 워크로드가 서로 통신하지 않기를 원합니다.
  • 온프레미스 네트워크로 이동하는 트래픽에 대한 레이어 7 검사만 필요합니다.

다음 다이어그램은 이 패턴의 구현 예시를 보여줍니다.

옵션 2 다이어그램.

앞의 다이어그램은 다음을 보여줍니다.

  • 허브 VPC 네트워크가 포함된 프로덕션 환경과 워크로드를 포함하는 여러 스포크 VPC 네트워크
  • 스포크 VPC 네트워크가 VPC 네트워크 피어링을 사용해서 허브 VPC 네트워크에 연결됩니다.
  • 허브 VPC 네트워크에 관리형 인스턴스 그룹의 가상 어플라이언스에 대한 여러 인스턴스가 포함되어 있습니다. 관리형 인스턴스 그룹에 대한 트래픽이 내부 패스 스루 네트워크 부하 분산기를 통과합니다.
  • 스포크 VPC 네트워크가 내부 부하 분산기가 포함된 정적 경로를 다음 홉으로 사용하여 가상 어플라이언스를 통해 서로 통신합니다.
  • Cloud Interconnect가 전송 VPC 네트워크를 온프레미스 위치에 연결합니다.
  • 온프레미스 네트워크가 개별 VLAN 연결을 사용해서 동일한 Cloud Interconnect를 통해 연결됩니다.
  • 전송 VPC 네트워크가 가상 어플라이언스의 개별 네트워크 인터페이스에 연결되고, 이를 통해 어플라이언스를 사용해서 네트워크에 대한 모든 트래픽을 검사하고 필터링할 수 있습니다.
  • 개발 환경에 프로덕션 환경과 동일한 VPC 구조가 포함됩니다.
  • 이 설정은 소스 네트워크 주소 변환(SNAT)을 사용하지 않습니다. Google Cloud에서 대칭적 해싱이 사용되기 때문에 SNAT가 필요하지 않습니다. 자세한 내용은 대칭적 해싱을 참조하세요.

설계상 한 스포크 네트워크의 트래픽은 다른 스포크 네트워크에 도달할 수 없습니다. 하지만 특정 워크로드가 서로 통신해야 하는 경우 VPC 네트워크 피어링을 사용해서 스포크 네트워크 간에 다이렉트 피어링을 설정하거나 Cloud Storage 또는 Pub/Sub 등의 Google Cloud 서비스로 애플리케이션 간에 데이터를 공유할 수 있습니다.

어플라이언스가 워크로드 간에 통신할 때 지연 시간을 낮게 유지하려면 어플라이언스가 워크로드와 동일한 리전에 있어야 합니다. 클라우드 배포에 여러 리전을 사용할 경우 각 리전의 각 환경에 대해 하나의 어플라이언스 집합과 하나의 허브 VPC를 지정할 수 있습니다. 또는 모든 인스턴스가 가장 가까운 어플라이언스와 통신하도록 경로에 네트워크 태그를 사용할 수 있습니다.

방화벽 규칙은 워크로드가 포함된 스포크 VPC 네트워크 내의 연결을 제한할 수 있습니다. 또한 워크로드를 관리하는 팀이 이러한 방화벽 규칙을 관리하는 경우도 많습니다. 중앙 정책의 경우 계층식 방화벽 정책을 사용할 수 있습니다. 중앙 네트워크팀에서 방화벽 규칙을 완전히 제어해야 하는 경우 GitOps 접근 방식을 사용하여 중앙에서 이러한 규칙을 모든 VPC 네트워크에 배포해야 합니다. 이 경우 IAM 권한은 방화벽 규칙을 변경할 수 있는 관리자로만 제한합니다. 또한 여러 팀이 스포크에서 배포하는 경우에는 스포크 VPC 네트워크가 공유 VPC 네트워크일 수 있습니다.

이 설계에서는 복잡성이 최소화되도록 VPC 네트워크 피어링을 사용하여 허브 VPC 네트워크 및 스포크 VPC 네트워크를 연결하는 것이 좋습니다. 하지만 최대 스포크 수는 다음에 따라 제한됩니다.

  • 단일 VPC 네트워크에서의 VPC 네트워크 피어링 연결 한도
  • 각 피어링 그룹의 내부 TCP/UDP 부하 분산에 대한 최대 전달 규칙 수와 같은 피어링 그룹 한도

이러한 한도에 도달할 것으로 예상되면 Cloud VPN을 통해 스포크 네트워크를 연결할 수 있습니다. Cloud VPN을 사용하면 비용 및 복잡성이 추가되고 각 Cloud VPN 터널은 대역폭 한도가 있습니다.

자세한 내용은 다음을 참조하세요.

이 설계 옵션을 구현하려면 만들기 옵션 2: 중앙 집중식 어플라이언스로 허브 및 스포크 토폴로지를 참고하세요.

옵션 3: 어플라이언스가 없는 허브 및 스포크 토폴로지

이 네트워크 설계는 온프레미스 네트워크 및 워크로드가 포함된 스포크 VPC 네트워크에 연결하는 허브 VPC 네트워크와 함께 허브 및 스포크 토폴로지도 사용합니다. VPC 네트워크 피어링은 전환할 수 없기 때문에 스포크 네트워크는 서로 직접 통신할 수 없습니다.

다음 조건에 해당할 경우 이 설계를 사용합니다.

  • Google Cloud의 워크로드 또는 환경이 내부 IP 주소를 사용하여 서로 통신하는 것은 완전히 방지하지만 온프레미스 연결은 공유하려고 합니다.
  • 팀에게 자체 방화벽 및 라우팅 규칙을 관리할 수 있는 자율성을 부여하려고 합니다.

다음 조건에 해당하는 경우 이 설계를 사용하지 마세요.

  • 워크로드 간에 레이어 7 검사가 필요합니다.
  • 라우팅 및 방화벽 규칙을 중앙에서 관리해야 합니다.
  • VPC 네트워크 피어링은 전환할 수 없기 때문에 온프레미스 서비스에서 다른 VPC 네트워크 피어링을 통해 스포크에 연결된 관리형 서비스로의 통신이 필요합니다.

다음 다이어그램은 이 설계의 구현 예시를 보여줍니다.

옵션 3 다이어그램.

앞의 다이어그램은 다음을 보여줍니다.

  • 허브 VPC 네트워크가 포함된 프로덕션 환경과 워크로드를 포함하는 여러 스포크 VPC 네트워크
  • 스포크 VPC 네트워크가 VPC 네트워크 피어링을 사용해서 허브 VPC 네트워크에 연결됩니다.
  • 온프레미스 위치에 대한 연결이 허브 VPC 네트워크의 Cloud Interconnect 연결을 통과합니다.
  • 온프레미스 네트워크가 개별 VLAN 연결을 사용하여 Cloud Interconnect 인스턴스를 통해 연결됩니다.
  • 개발 환경에 프로덕션 환경과 동일한 VPC 구조가 포함됩니다.

설계상 한 스포크 네트워크의 트래픽은 다른 스포크 네트워크에 도달할 수 없습니다. 하지만 특정 워크로드가 서로 통신해야 하는 경우 VPC 네트워크 피어링을 사용해서 스포크 네트워크 간에 다이렉트 피어링을 설정하거나 Cloud Storage 또는 Pub/Sub 등의 Google Cloud 서비스로 애플리케이션 간에 데이터를 공유할 수 있습니다.

이 네트워크 설계는 팀이 자율적으로 운영되고 방화벽 및 라우팅 규칙에 대해 중앙 집중식 제어가 필요하지 않은 환경에서 자주 사용됩니다. 하지만 이 설계의 규모는 다음에 따라 제한됩니다.

따라서 이 설계는 Google Cloud에서 여러 개별 워크로드를 갖는 대규모 조직에서 일반적으로 사용되지 않습니다.

이 설계의 변형으로 VPC 네트워크 피어링 대신 Cloud VPN을 사용할 수 있습니다. Cloud VPN은 스포크 수를 늘릴 수 있지만 각 터널의 대역폭 한도가 추가되고 복잡성 및 비용이 증가합니다. 커스텀 공지 경로를 사용할 때는 모든 스포크 네트워크를 직접 연결할 필요 없이 Cloud VPN에서 스포크 간 전환이 허용됩니다.

자세한 내용은 다음을 참조하세요.

이 설계 옵션을 구현하려면 만들기 옵션 3: 어플라이언스가 없는 허브 및 스포크 토폴로지를 참조하세요.

옵션 4: Private Service Connect를 사용하여 소비자 제작자 모델의 서비스 노출

이 네트워크 설계에서는 각 팀 또는 워크로드가 공유 VPC 네트워크일 수도 있는 자체 VPC 네트워크를 가져옵니다. 각 VPC 네트워크는 독립적으로 관리되며 Private Service Connect를 사용해서 VPC 네트워크 외부에서 액세스해야 하는 모든 서비스를 노출합니다.

다음 조건에 해당할 경우 이 설계를 사용합니다.

  • 워크로드는 정의된 엔드포인트를 통해서만 서로 그리고 온프레미스 환경과 통신합니다.
  • 팀이 서로 독립적이며 자체 IP 주소 공간, 방화벽, 라우팅 규칙을 관리하기를 원합니다.

다음 조건에 해당하는 경우 이 설계를 사용하지 마세요.

  • 서비스와 애플리케이션 사이의 통신에는 여러 다른 포트 또는 채널이 사용되고, 또는 포트 및 채널이 자주 변경됩니다.
  • 워크로드 간 통신에는 TCP 또는 UDP 이외의 프로토콜이 사용됩니다.
  • 워크로드 간에 레이어 7 검사가 필요합니다.

다음 다이어그램은 이 패턴의 구현 예시를 보여줍니다.

옵션 4 다이어그램.

앞의 다이어그램은 다음을 보여줍니다.

  • 개별 워크로드가 개별 프로젝트 및 VPC 네트워크에 있습니다.
  • 한 VPC 네트워크의 클라이언트 VM이 Private Service Connect 엔드포인트를 통해 다른 VPC 네트워크의 워크로드에 연결할 수 있습니다.
  • 엔드포인트가 서비스가 있는 VPC 네트워크의 서비스 연결에 연결됩니다. 엔드포인트가 전역 액세스용으로 구성된 경우 서비스 연결이 엔드포인트와 다른 리전에 있을 수 있습니다.
  • 서비스 연결은 Cloud Load Balancing을 통해 워크로드에 연결됩니다.
  • 워크로드 VPC의 클라이언트는 다음과 같이 온프레미스에 있는 워크로드에 연결할 수 있습니다.
    • 엔드포인트는 전송 VPC 네트워크의 서비스 연결에 연결됩니다.
    • 서비스 연결은 Cloud Interconnect를 사용하여 온프레미스 네트워크에 연결됩니다.
  • 내부 애플리케이션 부하 분산기가 서비스 연결에 연결되고 하이브리드 네트워크 엔드포인트 그룹을 사용해서 온프레미스에 있는 엔드포인트 간의 트래픽 부하를 균형 조정합니다.
  • 또한 온프레미스 클라이언트가 워크로드 VPC 네트워크의 서비스 연결에 연결되는 전송 VPC 네트워크의 엔드포인트에 연결할 수 있습니다.

자세한 내용은 다음을 참조하세요.

이 설계 옵션을 구현하려면 만들기 옵션 4: Private Service Connect를 사용하여 소비자 제작자 모델의 서비스 노출을 참조하세요.

네트워크 배포 권장사항

사용 사례에 맞게 최상의 네트워크 설계를 선택한 후에는 다음 권장사항을 구현하는 것이 좋습니다.

자세한 내용은 VPC 설계에 관한 권장사항 및 참조 아키텍처를 참조하세요.

다음 단계