공유 VPC 개요

공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 공유 VPC를 사용하면 프로젝트를 호스트 프로젝트로 지정한 후 하나 이상의 다른 서비스 프로젝트를 여기에 연결합니다. 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 합니다. 서비스 프로젝트의 운영 가능 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.

공유 VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하면서 서비스 프로젝트 관리자에게 인스턴스 생성 및 관리와 같은 관리 책임을 위임할 수 있습니다. 이 모델을 사용하면 조직에서 다음을 수행할 수 있습니다.

  • 네트워크 관리, 감사, 액세스 제어에 대한 최소 권한의 보안 권장사항을 구현합니다. 공유 VPC 관리자는 서비스 프로젝트 관리자가 네트워크에 영향을 미치는 변경 작업을 하지 않아도 공유 VPC 네트워크의 네트워크 및 보안 관리자에게 네트워크 관리 작업을 위임할 수 있습니다. 서비스 프로젝트 관리자에게는 공유 VPC 네트워크를 사용하는 인스턴스를 만들고 관리할 수 있는 권한만 제공됩니다. 자세한 내용은 관리자 및 IAM 섹션을 참조하세요.
  • 관리 책임을 위임하는 동시에 조직의 여러 서비스 프로젝트에 대해 네트워크 수준에서 일관된 액세스 제어 정책을 적용하고 시행합니다. 예를 들어 서비스 프로젝트 관리자는 프로젝트에서 Compute 인스턴스 관리자가 되어 공유 VPC 호스트 프로젝트에서 승인된 서브넷을 사용하는 인스턴스를 만들고 삭제할 수 있습니다.
  • 서비스 프로젝트를 사용하여 예산 또는 내부 비용 센터를 분리합니다. 자세한 내용은 청구 섹션을 참조하세요.

개념

조직, 폴더, 프로젝트

공유 VPC는 동일한 조직 내에서 프로젝트를 연결합니다. 참여하는 호스트 및 서비스 프로젝트는 다른 조직에 속할 수 없습니다. 연결된 프로젝트는 같거나 다른 폴더 모두에 있을 수 있지만 다른 폴더에 있는 경우에는 관리자에게 두 폴더에 대한 공유 VPC 관리자 권한이 있어야 합니다. 조직, 폴더, 프로젝트에 대한 자세한 내용은 GCP 리소스 계층 구조를 참조하세요.

공유 VPC에 참여하는 프로젝트는 호스트 프로젝트 또는 서비스 프로젝트입니다.

  • 호스트 프로젝트에는 하나 이상의 공유 VPC 네트워크가 포함됩니다. 공유 VPC 관리자가 먼저 프로젝트를 호스트 프로젝트로 사용 설정해야 합니다. 그런 다음 공유 VPC 관리자가 호스트 프로젝트에 하나 이상의 서비스 프로젝트를 연결할 수 있습니다.

  • 서비스 프로젝트는 공유 VPC 관리자가 호스트 프로젝트에 연결한 프로젝트입니다. 이 연결을 통해 서비스 프로젝트가 공유 VPC에 참여할 수 있습니다. 조직의 여러 부서 또는 팀에서 다중 서비스 프로젝트를 운영하고 관리하는 것이 일반적입니다.

  • 프로젝트는 호스트 프로젝트와 서비스 프로젝트가 동시에 될 수 없습니다. 따라서 서비스 프로젝트를 호스트 프로젝트로 설정하여 프로젝트를 더 제공할 수 없습니다.

  • 다중 호스트 프로젝트를 만들어 사용할 수 있지만 각 서비스 프로젝트는 단일 호스트 프로젝트에만 연결할 수 있습니다. 설명은 다중 호스트 프로젝트 예를 참조하세요.

명확하게 하기 위해 공유 VPC에 참여하지 않는 프로젝트를 독립형 프로젝트라고 합니다. 이름을 통해 해당 프로젝트가 호스트 프로젝트가 아니고 서비스 프로젝트도 아님을 잘 알 수 있습니다.

네트워크

공유 VPC 네트워크는 호스트 프로젝트에 정의된 VPC 네트워크이며 서비스 프로젝트에서 실행되는 리소스의 중앙 공유 네트워크로 사용할 수 있습니다. 공유 VPC 네트워크는 자동 또는 커스텀 모드일 수 있지만 레거시 네트워크는 지원되지 않습니다.

호스트 프로젝트가 사용 설정되면 기존의 모든 VPC 네트워크가 공유 VPC 네트워크가 되며 이 VPC 네트워크에서 생성된 모든 새 네트워크는 자동으로 공유 VPC 네트워크가 됩니다. 따라서 단일 호스트 프로젝트가 둘 이상의 공유 VPC 네트워크를 가질 수 있습니다.

호스트 및 서비스 프로젝트는 프로젝트 수준에서 첨부파일로 연결됩니다. 호스트 프로젝트의 공유 VPC 네트워크 서브넷은 다음 섹션인 관리자 및 IAM에서 설명하는 대로 서비스 프로젝트 관리자가 액세스할 수 있습니다.

관리자 및 IAM

공유 VPC는 위임된 관리를 위해 Identity and Access Management(IAM) 역할을 사용합니다. 사용자, Google 그룹, Google 도메인 또는 GCP 서비스 계정과 같은 IAM 구성원에게 부여할 수 있는 역할은 다음과 같습니다. 이러한 관리자에게 문의해야 하는 경우 조직 또는 프로젝트의 IAM 정책을 찾아볼 수 있습니다. 필수 권한이 없으면 조직의 네트워크 또는 프로젝트 관리자에게 문의해야 합니다.

필수 관리 역할

관리자 목적
조직 관리자
  • 조직의 IAM 구성원
조직 관리자는 조직에서 resourcemanager.organizationAdmin 역할을 합니다. 조직 관리자는 적절한 프로젝트 생성 및 삭제 역할과 조직의 공유 VPC 관리자 역할을 부여하여 공유 VPC 관리자를 지정합니다. 이러한 관리자는 조직 수준 정책을 정의할 수 있지만 특정 폴더 및 프로젝트 작업에는 추가 폴더 및 프로젝트 역할이 필요합니다.
공유 VPC 관리자
  • 조직의 IAM 구성원 또는
  • 폴더의 IAM 구성원(베타)
공유 VPC 관리자에게는 조직 또는 하나 이상의 폴더에 대한 공유 VPC 관리자(compute.xpnAdmin) 역할이 있습니다. 공유 VPC 관리자는 호스트 프로젝트 사용 설정, 호스트 프로젝트에 서비스 프로젝트 연결, 서비스 프로젝트 관리자에게 공유 VPC 네트워크의 일부 또는 모든 서브넷에 대한 액세스 권한 위임과 같은 공유 VPC 설정에 필요한 다양한 작업을 수행합니다. 지정된 호스트 프로젝트의 공유 VPC 관리자는 일반적으로 프로젝트 소유자이기도 합니다.
조직의 공유 VPC 관리자 역할이 할당된 사용자에게는 조직의 모든 폴더에 대한 역할이 있습니다. 폴더에 대한 역할이 할당된 사용자에게는 지정된 폴더와 그 아래에 중첩된 폴더에 대한 해당 역할이 있습니다. 공유 VPC 관리자는 관리자에게 폴더 두 개에 대한 역할이 있는 경우에만 두 개의 다른 폴더에 있는 프로젝트를 연결할 수 있습니다.
서비스 프로젝트 관리자
  • 서비스 프로젝트의 IAM 구성원 또는
  • 조직의 IAM 구성원
공유 VPC 관리자는 IAM 구성원에게 전체 호스트 프로젝트 또는 공유 VPC 네트워크의 일부 서브넷에 대한 네트워크 사용자(compute.networkUser) 역할을 부여하여 서비스 프로젝트 관리자를 정의합니다. 또한 서비스 프로젝트 관리자는 소유권을 유지하고 서비스 프로젝트에 정의된 리소스를 제어하므로 해당 서비스 프로젝트에 대한 인스턴스 관리자(compute.instanceAdmin) 역할을 가지고 있어야 합니다. 이들은 프로젝트 소유자와 같이 서비스 프로젝트에 대한 추가 IAM 역할을 수행할 수 있습니다.

서비스 프로젝트 관리자

각 서비스 프로젝트 관리자를 정의할 때 공유 VPC 관리자는 전체 호스트 프로젝트 또는 일부 서브넷을 사용할 수 있는 권한을 부여할 수 있습니다.

  • 프로젝트 수준 권한: 공유 VPC 관리자가 전체 호스트 프로젝트에 대한 compute.networkUser 역할을 서비스 프로젝트 관리자에게 부여한 경우, 서비스 프로젝트 관리자가 호스트 프로젝트의 모든 서브넷을 사용할 권한을 갖도록 정의할 수 있습니다. 결과적으로 서비스 프로젝트 관리자는 앞으로 호스트 프로젝트에 추가되는 서브넷 및 VPC 네트워크를 포함하여 호스트 프로젝트의 모든 VPC 네트워크에서 모든 서브넷을 사용할 수 있는 권한을 갖게 됩니다.

  • 서브넷 수준 권한: 또는 공유 VPC 관리자가 일부 서브넷에 대한 compute.networkUser 역할을 서비스 프로젝트 관리자에게 부여한 경우, 서비스 프로젝트 관리자에게 일부 서브넷만 사용할 수 있는 제한된 권한을 부여할 수도 있습니다. 서브넷 수준의 권한만 가진 서비스 프로젝트 관리자는 해당 서브넷만 사용할 수 있습니다. 새 공유 VPC 네트워크 또는 새 서브넷이 호스트 프로젝트에 추가된 후 공유 VPC 관리자는 compute.networkUser 역할에 대한 권한 바인딩을 검토하여 모든 서비스 프로젝트 관리자의 서브넷 수준 권한이 의도한 구성과 일치하는지 확인해야 합니다.

네트워크 및 보안 관리자

공유 VPC 관리자는 공유 VPC 네트워크 관리를 포함하여 호스트 프로젝트의 리소스를 완벽하게 제어할 수 있습니다. 원하는 경우 특정 네트워크 관리 작업을 다른 IAM 구성원에게 위임할 수 있습니다.

관리자 목적
네트워크 관리자
  • 호스트 프로젝트의 IAM 구성원 또는
  • 조직의 IAM 구성원
공유 VPC 관리자는 IAM 구성원에게 호스트 프로젝트에 대한 네트워크 관리자(compute.networkAdmin) 역할을 부여하여 네트워크 관리자를 정의합니다. 네트워크 관리자는 방화벽 규칙 및 SSL 인증서를 제외한 모든 네트워크 리소스를 완벽하게 제어할 수 있습니다.
보안 관리자
  • 호스트 프로젝트의 IAM 구성원 또는
  • 조직의 IAM 구성원
공유 VPC 관리자는 IAM 구성원에게 호스트 프로젝트에 대한 보안 관리자(compute.securityAdmin) 역할을 부여하여 보안 관리자를 정의할 수 있습니다. 보안 관리자는 방화벽 규칙 및 SSL 인증서를 관리합니다.

사양

할당량 및 한도

공유 VPC 호스트 프로젝트에는 표준 프로젝트별 VPC 할당량이 적용됩니다. 공유 VPC 네트워크에는 VPC 네트워크의 네트워크별 한도인스턴스별 한도가 적용됩니다. 또한 호스트 프로젝트와 서비스 프로젝트 간의 관계에는 공유 VPC에 한정되는 한도가 적용됩니다.

결제

공유 VPC 네트워크에 참여하는 리소스에 대한 결제는 리소스가 호스트 프로젝트에서 공유 VPC 네트워크를 사용하더라도 리소스가 있는 서비스 프로젝트에서 발생합니다.

  • 공유 VPC 네트워크를 사용하는 서비스 프로젝트에서 리소스 청구 금액을 계산하는 데 사용되는 요율 및 규칙은 리소스가 호스트 프로젝트 자체에 있는 경우와 같습니다.
  • 리소스에 의해 생성된 송신 트래픽에 대한 요금은 리소스가 정의된 프로젝트에 대해 청구됩니다.
    • 인스턴스의 송신 트래픽은 해당 인스턴스가 포함된 프로젝트에 대해 청구됩니다. 예를 들어 인스턴스가 서비스 프로젝트에서 생성되었지만 공유 VPC 네트워크를 사용하는 경우 생성되는 송신 트래픽에 대한 요금은 해당 서비스 프로젝트에 대해 청구됩니다. 이런 식으로 공유 VPC를 사용하여 리소스를 조직의 비용 센터로 구성할 수 있습니다.
    • 부하 분산기 관련 비용은 부하 분산기 구성요소가 포함된 프로젝트에 청구됩니다. 부하 분산 및 공유 VPC에 대한 자세한 내용은 부하 분산 섹션을 참조하세요.
    • VPN에 대한 송신 트래픽은 VPN 게이트웨이 리소스를 포함하는 프로젝트에 청구합니다. 예를 들어, VPN 게이트웨이가 공유 VPC 네트워크에서 생성된 경우 호스트 프로젝트에 포함됩니다. 어느 서비스 프로젝트에서 송신이 시작되었는지에 관계없이 VPN 게이트웨이를 통한 송신 트래픽은 호스트 프로젝트로 청구됩니다.

리소스

운영 가능 리소스

다음 서비스 프로젝트 리소스는 공유 VPC에 참여할 수 있지만 몇 가지 실질적 제한사항이 적용됩니다.

운영 가능 리소스에 대한 실질적인 제한사항

공유 VPC 시나리오에 참여할 수 있는 리소스에는 다음 제한사항이 적용됩니다.

  • 공유 VPC 네트워크 사용은 필수 사항이 아닙니다. 예를 들어, 인스턴스 관리자는 해당 프로젝트에서 VPC 네트워크를 사용하는 인스턴스를 서비스 프로젝트에 만들 수 있습니다. 서비스 프로젝트에서 정의된 네트워크는 공유되지 않습니다.

  • 공유 VPC 네트워크를 사용하려면 일부 리소스를 다시 만들어야 합니다. 공유 VPC 관리자가 기존 프로젝트를 호스트 프로젝트에 연결하면 이 프로젝트는 서비스 프로젝트가 되지만 기존 리소스는 공유 네트워크 리소스를 자동으로 사용하지 않습니다. 공유 VPC 네트워크를 사용하려면 서비스 프로젝트 관리자는 운영 가능 리소스를 생성하고 공유 VPC 네트워크의 서브넷을 사용하도록 구성해야 합니다. 예를 들어 서비스 프로젝트의 기존 인스턴스는 공유 VPC 네트워크를 사용하도록 재구성할 수 없지만 새 인스턴스를 만들어 공유 VPC 네트워크에서 사용 가능한 서브넷을 사용할 수 있습니다. 이 제한은 비공개 영역에 적용됩니다.

사용 불가 리소스

서비스 프로젝트에서 App Engine 가변형 리소스는 공유 VPC에 참여할 수 없습니다.

IP 주소

동일한 공유 VPC 네트워크를 통해 호스트 프로젝트에 연결된 서비스 프로젝트의 인스턴스는 임시 또는 예약된 고정 내부 IP 주소를 사용하여 서로 통신할 수 있습니다. 이때 관련 방화벽 규칙이 적용됩니다.

임시 내부 IP 주소가 서비스 프로젝트의 인스턴스에 자동으로 할당될 수 있습니다. 예를 들어 서비스 프로젝트 관리자가 인스턴스를 만들 때 영역, 공유 VPC 네트워크, 사용 가능한 서브넷을 선택합니다. IP 주소는 선택한 공유 서브넷에서 사용 가능한 IP 주소의 범위에서 가져옵니다.

또는 서비스 프로젝트 관리자가 정적 내부 IP 주소를 예약하도록 선택할 수 있습니다. IP 주소 값은 공유 VPC 네트워크에서 선택한 공유 서브넷에 있는 사용 가능한 IP 범위에서 가져 오지만 IP 주소 객체 자체는 해당 IP 주소 객체를 사용할 인스턴스와 동일한 서비스 프로젝트에서 만들어야 합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 고정 내부 IP 예약을 참조하세요.

호스트 프로젝트에서 정의된 외부 IP 주소는 해당 프로젝트의 리소스에서만 사용할 수 있습니다. 서비스 프로젝트에는 사용할 수 없습니다. 서비스 프로젝트는 자체 외부 IP 주소 모음을 유지할 수 있습니다. 예를 들어 서비스 프로젝트의 인스턴스는 동일한 서비스 프로젝트에서 정의된 외부 IP 주소를 사용해야 합니다. 인스턴스가 호스트 프로젝트에서 공유 VPC 네트워크의 내부 IP 주소를 사용하는 경우에도 마찬가지입니다.

내부 DNS

동일한 서비스 프로젝트에 있는 여러 VM은 GCP에서 자동 생성하는 내부 DNS 이름을 사용하여 서로 통신할 수 있습니다. 이러한 DNS 이름이 호스트 프로젝트의 내부 IP 주소를 가리키는 경우에도 해당 이름은 VM이 생성되는 서비스 프로젝트의 프로젝트 ID를 사용합니다. 전체 설명은 내부 DNS 문서의 내부 DNS 이름 및 공유 VPC를 참조하세요.

Cloud DNS 비공개 영역

공유 VPC 네트워크에서 Cloud DNS 비공개 영역을 사용할 수 있습니다. 호스트 프로젝트에서 비공개 영역을 만들고 공유 VPC 네트워크에 해당 영역에 대한 액세스를 승인해야 합니다.

부하 분산

공유 VPC는 부하 분산과 함께 사용할 수 있습니다. 모든 부하 분산 구성요소는 모두 호스트 프로젝트에 있거나 모두 서비스 프로젝트에 있는 등 동일한 프로젝트에 있어야 합니다. 일부 부하 분산기 구성요소를 호스트 프로젝트에서 만들고 나머지는 연결된 서비스 프로젝트에서 만드는 것은 지원되지 않습니다. 그러나 서비스 프로젝트에서 만든 내부 부하 분산기의 내부 전달 규칙은 서비스 프로젝트가 연결된 호스트 프로젝트의 공유 서브넷을 참조할 수 있습니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 내부 부하 분산기 만들기를 참조하세요.

다음 표에는 HTTP(S), SSL 프록시, TCP 프록시 부하 분산에 대한 구성요소가 요약되어 있습니다. 대부분의 경우 서비스 프로젝트에서 백엔드 인스턴스를 만듭니다. 이 경우 모든 부하 분산기 구성요소가 해당 프로젝트에서 생성됩니다. 호스트 프로젝트에서 백엔드 인스턴스를 만들 수도 있습니다. 이 경우 모든 부하 분산기 구성요소가 호스트 프로젝트에 있어야 합니다.

부하 분산기 IP 주소 전달 규칙 기타 프론트엔드 구성 요소 백엔드 구성요소
HTTP(S) 부하 분산 외부 IP 주소는 부하 분산 중인 인스턴스와 동일한 프로젝트(서비스 프로젝트)에서 정의되어야 합니다. 외부 전달 규칙은 백엔드 인스턴스와 동일한 프로젝트(서비스 프로젝트)에서 정의되어야 합니다. 대상 HTTP 프록시 또는 대상 HTTPS 프록시 및 연결된 URL 맵은 백엔드 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 전역 백엔드 서비스는 백엔드 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 이 인스턴스는 백엔드 서비스에 백엔드로 연결된 인스턴스 그룹에 있어야 합니다. 백엔드 서비스와 관련된 상태 확인은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.
SSL 프록시 부하 분산 대상 SSL 프록시는 백엔드 인스턴스와 동일한 프로젝트에서 정의되어야 합니다.
TCP 프록시 부하 분산 대상 TCP 프록시는 백엔드 인스턴스와 동일한 프로젝트에서 정의되어야 합니다.

다음 표에는 두 유형의 지역 부하 분산기에 대한 구성요소가 요약되어 있습니다. 이 표에서는 내부 부하 분산기의 내부 전달 규칙이 공유 VPC 네트워크의 공유 서브넷을 참조하여 공유 VPC 네트워크 내에서 내부 부하 분산을 제공하는 방법이 강조 표시됩니다.

부하 분산기 IP 주소 전달 규칙 백엔드 구성요소
네트워크 부하 분산 지역 외부 IP 주소는 부하 분산 중인 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 지역 외부 전달 규칙은 대상 풀의 인스턴스와 동일한 프로젝트(서비스 프로젝트)에서 정의되어야 합니다. 대상 풀은 대상 풀의 인스턴스가 있는 동일한 프로젝트 및 동일한 영역에서 정의되어야 합니다. 대상 풀과 관련된 상태 검사도 동일한 프로젝트에서 정의되어야 합니다.
내부 부하 분산 내부 IP 주소는 호스트 또는 서비스 프로젝트에서 가져올 수 있습니다.
  • 부하 분산기를 공유 VPC 네트워크에서 사용할 수 있어야 하는 경우 내부 IP 주소는 공유 서브넷의 기본 IP 주소 범위에서 가져와야 합니다.
  • 부하 분산기가 하나의 서비스 프로젝트에 대해 로컬이어야 하는 경우 내부 IP 주소는 해당 서비스 프로젝트의 네트워크에 있는 서브넷에서 가져올 수 있습니다.
내부 전달 규칙은 부하 분산 중인 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 하지만 이 규칙이 참조하는 서브넷은 부하 분산기가 공유 VPC 시나리오에서 작동하는지 확인합니다.
  •부하 분산기를 공유 VPC 네트워크에서 사용할 수 있어야 하는 경우 전달 규칙이 공유 서브넷을 참조해야 합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 내부 부하 분산기 만들기를 참조하세요.
  •부하 분산기가 하나의 서비스 프로젝트에 대해 로컬이어야 하는 경우 전달 규칙은 해당 서비스 프로젝트의 네트워크에 있는 서브넷을 참조할 수 있습니다.
지역 백엔드 서비스는 부하 분산 중인 인스턴스와 동일한 프로젝트에서 정의되어야 합니다. 부하 분산 중인 인스턴스는 백엔드 서비스에 백엔드로 연결된 인스턴스 그룹에 있어야 합니다. 백엔드 서비스와 관련된 상태 확인은 백엔드 서비스와 동일한 프로젝트에서 정의되어야 합니다.

예제 및 사용 사례

기본 개념

다음 예는 간단한 공유 VPC 시나리오를 보여줍니다.

기본 개념(확대하려면 클릭)
기본 개념(확대하려면 클릭)
  • 조직의 공유 VPC 관리자가 호스트 프로젝트를 만들고 여기에 두 개의 서비스 프로젝트를 연결했습니다.

    • Service Project A의 서비스 프로젝트 관리자는 공유 VPC 네트워크의 모든 서브넷 또는 일부 서브넷에 액세스하도록 구성할 수 있습니다. 10.0.1.0/24 Subnet에 대해 서브넷 수준 이상의 권한을 가진 서비스 프로젝트 관리자가 us-west1 지역의 특정 영역에 Instance A를 만들었습니다. 이 인스턴스는 10.0.1.0/24 CIDR 블록에서 내부 IP 주소 10.0.1.3을 수신합니다.

    • Service Project B의 서비스 프로젝트 관리자가 공유 VPC 네트워크의 모든 서브넷 또는 일부 서브넷에 액세스하도록 구성할 수 있습니다. 10.15.2.0/24 Subnet에 대해 서브넷 수준 이상의 권한을 가진 서비스 프로젝트 관리자가 us-east1 지역의 특정 영역에 Instance B를 만들었습니다. 이 인스턴스는 10.15.2.0/24 CIDR 블록에서 내부 IP 주소 10.15.2.4를 수신합니다.

  • 독립형 프로젝트는 공유 VPC에 전혀 참여하지 않습니다. 호스트도 아니고 서비스 프로젝트도 아닙니다. 독립형 인스턴스는 프로젝트에 대해 compute.InstanceAdmin 이상의 권한을 가진 IAM 구성원이 만듭니다.

여러 호스트 프로젝트

다음 예제에서는 공유 VPC를 사용하여 별도의 테스트 및 프로덕션 환경을 구축하는 방법을 보여줍니다. 이 경우 조직에서는 별도의 두 호스트 프로젝트인 테스트 환경프로덕션 환경을 사용하기로 결정했습니다.

여러 호스트 프로젝트(확대하려면 클릭)
여러 호스트 프로젝트(확대하려면 클릭)
  • 조직의 공유 VPC 관리자가 두 개의 호스트 프로젝트를 만들고 여기에 두 개의 서비스 프로젝트를 다음과 같이 연결했습니다.

    • Apps TestingMobile Testing 서비스 프로젝트는 Test Environment 호스트 프로젝트에 연결되었습니다. 각 서비스 프로젝트 관리자는 Testing Network의 서브넷 전체 또는 일부에 액세스하도록 구성될 수 있습니다.

    • Apps ProductionMobile Production 서비스 프로젝트는 Production Environment 호스트 프로젝트에 연결되었습니다. 각 서비스 프로젝트 관리자는 Production Network의 서브넷 전체 또는 일부에 액세스하도록 구성될 수 있습니다.

  • 두 호스트 프로젝트에는 동일한 CIDR 범위를 사용하도록 구성된 서브넷이 있는 공유 VPC 네트워크가 하나 있습니다. Testing NetworkProduction Network에서 두 서브넷은 다음과 같습니다.

    • us-west1 지역의 10.0.1.0/24 Subnet

    • us-east1 지역의 10.15.2.0/24 Subnet

  • Apps Testing 서비스 프로젝트에서는 Instance AT를, 그리고 Apps Production 서비스 프로젝트에서는 Instance AP를 고려합니다.

    • 서비스 프로젝트 관리자는 10.0.1.0/24 Subnet에 대한 서브넷 수준 이상의 권한이 있는 인스턴스를 만들 수 있습니다.

    • 두 인스턴스 모두 IP 주소 10.0.1.3을 사용합니다. 이는 각 인스턴스가 자체 공유 VPC 네트워크가 포함된 고유한 호스트 프로젝트에 연결된 서비스 프로젝트에 존재하기 때문에 허용됩니다. 테스트 네트워크와 프로덕션 네트워크는 동일한 방식으로 의도적으로 구성되었습니다.

    • 서브넷과 인스턴스가 별도의 프로젝트에 정의되어 있더라도 10.0.1.0/24 Subnet을 사용하는 인스턴스는 서브넷과 동일한 지역에 있어야 합니다. 10.0.1.0/24 Subnetus-west1 지역에 있기 때문에 해당 서브넷을 사용하여 인스턴스를 만드는 서비스 프로젝트 관리자는 같은 지역(예: us-west1-a)에 있는 영역을 선택해야 합니다.

하이브리드 클라우드 시나리오

다음 예는 하이브리드 환경에서 공유 VPC를 사용하는 방법을 보여줍니다.

하이브리드 클라우드(확대하려면 클릭)
하이브리드 클라우드(확대하려면 클릭)

이 예에서 조직은 단일 공유 VPC 네트워크가 있는 단일 호스트 프로젝트를 만들었습니다. 공유 VPC 네트워크는 Cloud VPN을 통해 사내 네트워크에 연결됩니다. 일부 서비스 및 애플리케이션은 GCP에서 호스팅되는 반면 다른 서비스 및 애플리케이션은 온프레미스로 유지됩니다.

  • 공유 VPC 관리자는 호스트 프로젝트를 사용 설정하고 여기에 세 가지 서비스 프로젝트(Service Project A, Service Project B, Service Project C)를 연결했습니다.

    • 별도의 팀이 각 서비스 프로젝트를 관리할 수 있습니다. 한 프로젝트의 서비스 프로젝트 관리자가 다른 서비스 프로젝트에 대한 권한을 가지지 않도록 IAM 권한이 구성되었습니다.

    • 공유 VPC 관리자는 공유 VPC 네트워크를 사용하는 인스턴스를 만들 수 있도록 필요한 서비스 프로젝트 관리자에게 서브넷 수준 또는 프로젝트 수준 권한을 부여했습니다.

      • 10.0.1.0/24 Subnet에 대해 서브넷 수준 권한을 가진 Service Project A 서비스 프로젝트 관리자는 여기에 Instance A를 만들 수 있습니다. 서비스 프로젝트 관리자는 us-west1 지역에서 인스턴스 영역을 선택해야 합니다. 해당 지역이 10.0.1.0/24 Subnet을 포함하는 지역이기 때문입니다. Instance A10.0.1.0/24 Subnet의 사용 가능한 IP 주소 범위에서 IP 주소 10.0.1.3을 수신합니다.

      • Service Project B에 대해 서브넷 수준 권한을 가진 10.15.2.0/24 Subnet 서비스 프로젝트 관리자는 여기에 Instance B를 만들 수 있습니다. 서비스 프로젝트 관리자는 us-east1 지역에서 인스턴스 영역을 선택해야 합니다. 해당 지역이 10.15.2.0/24 Subnet을 포함하는 지역이기 때문입니다. Instance B10.15.2.0/24 Subnet의 사용 가능한 IP 주소 범위에서 IP 주소 10.15.2.4를 수신합니다.

      • 전체 호스트 프로젝트에 대한 프로젝트 수준 권한을 가진 Service Project C의 서비스 프로젝트 관리자는 호스트 프로젝트의 모든 VPC 네트워크에 있는 서브넷 중 하나에 인스턴스를 만들 수 있습니다. 예를 들어 서비스 프로젝트 관리자는 us-east1 지역에서 해당 서브넷의 지역과 일치하는 영역을 선택하여 10.7.1.0/24 SubnetInstance C를 만들 수 있습니다. Instance C10.7.1.0/24 Subnet의 사용 가능한 IP 주소 범위에서 IP 주소 10.7.1.50을 수신합니다.

    • 각 서비스 프로젝트는 별도로 청구됩니다.

    • 각 프로젝트의 서비스 프로젝트 관리자는 리소스를 만들고 관리해야 합니다.

  • 공유 VPC 관리자가 네트워크 관리 작업을 공유 VPC 네트워크의 네트워크 및 보안 관리자인 다른 IAM 구성원에게 위임했습니다.

    • 네트워크 관리자가 Cloud VPN 게이트웨이를 만들고 인터넷을 통해 온프레미스 게이트웨이로 VPN 터널을 구성했습니다. Cloud VPN은 동일한 us-east1 리전에서 해당 Cloud Router가 구성되었기 때문에 온프레미스 대응 라우터로 경로를 교환하고 수신합니다.

    • VPC의 동적 라우팅 모드가 전역인 경우 Cloud 라우터는 학습된 경로를 VPC 네트워크의 모든 서브넷에 있는 온프레미스 네트워크에 적용하고 온프레미스 대응 라우터와 함께 모든 VPC 서브넷에 대한 경로를 공유합니다.

    • 보안 관리자는 공유 VPC 네트워크에서 방화벽 규칙을 만들고 관리하여 GCP 및 온프레미스 네트워크의 인스턴스 간 트래픽을 제어합니다.

    • 적용 가능한 방화벽 규칙에 따라 서비스 프로젝트의 인스턴스를 온프레미스 데이터베이스 또는 디렉토리 서버와 같은 내부 서비스와 통신하도록 구성할 수 있습니다.

2단계 웹 서비스

다음 예는 공유 VPC를 사용하여 관리 책임을 위임하고 최소 권한 원칙을 유지하는 방법을 보여줍니다. 이 경우 조직에는 두 개의 단계로 분리된 웹 서비스가 있으며 각기 다른 팀이 각 단계를 관리합니다. 단계 1은 전역 HTTP 부하 분산기 뒤에 있는 외부 지향적 구성 요소를 나타냅니다. 단계 2는 단계 1이 의존하는 내부 서비스를 나타내며 내부 부하 분산기를 사용하여 균형을 이룹니다.

2단계 웹 서비스(확대하려면 클릭)
2단계 웹 서비스(확대하려면 클릭)

공유 VPC를 사용하면 웹 서비스의 각 단계를 다른 프로젝트에 매핑하여 공통 VPC 네트워크를 공유하면서 다른 팀에서 관리할 수 있습니다.

  • 각 단계의 인스턴스 및 부하 분산기 구성요소와 같은 리소스는 여러 팀이 관리하는 개별 서비스 프로젝트에 배치됩니다.

  • 각 단계 서비스 프로젝트는 공유 VPC 관리자에 의해 호스트 프로젝트에 연결되었습니다. 공유 VPC 관리자는 호스트 프로젝트도 사용 설정했습니다.

    • 개별 팀은 적절한 서비스 프로젝트에서 서비스 프로젝트 관리자가 되어 웹 서비스의 각 단계를 관리할 수 있습니다.

    • 각 서비스 프로젝트는 별도로 청구됩니다.

    • 각 프로젝트의 서비스 프로젝트 관리자는 리소스를 만들고 관리해야 합니다.

  • 네트워크 액세스 제어는 다음과 같이 구분됩니다.

    • 1단계에서만 작업하는 IAM 구성원은 Tier 1 Service Project의 서비스 프로젝트 관리자이고 10.0.1.0/24 Subnet에 대한 서브넷 수준의 권한만 부여됩니다. 이 예에서 해당 서비스 프로젝트 관리자는 해당 서브넷에 세 개의 Tier 1 Instances를 만들었습니다.

    • 2단계에서만 작업하는 IAM 구성원은 Tier 2 Service Project의 서비스 프로젝트 관리자이고 10.0.2.0/24 Subnet에 대한 서브넷 수준의 권한만 부여됩니다. 이 예에서 다른 서비스 프로젝트 관리자는 전달 규칙이 해당 서브넷에서 사용할 수 있는 범위의 IP 주소를 사용하는 내부 부하 분산기와 함께 해당 서브넷에 세 개의 Tier 2 Instances를 만들었습니다.

    • 전체 웹 서비스를 감독하는 IAM 구성원은 두 서비스 프로젝트의 서비스 프로젝트 관리자이며 호스트 프로젝트에 대한 프로젝트 수준의 권한을 가지고 있어 여기에서 정의된 모든 서브넷을 사용할 수 있습니다.

    • 원하는 경우 공유 VPC 관리자는 네트워크 관리 작업을 네트워크 및 보안 관리자에게 위임할 수 있습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...