DNS 권장사항

이 문서에서는 다음에 대한 권장사항을 제공합니다.

소개

DNS(도메인 이름 시스템)를 사용하면 사람과 애플리케이션 모두 애플리케이션과 서비스를 더 쉽게 처리할 수 있습니다. 이름은 IP 주소보다 기억하기 쉽고 유연하기 때문입니다. 온프레미스와 하나 이상의 클라우드 플랫폼으로 구성된 하이브리드 환경에서 내부 리소스에 대한 DNS 레코드는 여러 환경에서 액세스해야 하는 경우가 많습니다. 일반적으로 온프레미스 DNS 레코드는 UNIX/Linux 환경의 BIND 또는 Microsoft Windows 환경의 Active Directory와 같은 권한 있는 DNS 서버를 사용하여 수동으로 관리됩니다. 이 문서에서는 비공개 DNS 요청을 환경 간에 전달하여 온프레미스 환경과 Google Cloud 모두에서 서비스를 처리하는 방법에 대한 권장사항을 설명합니다.

일반 원칙

Google Cloud의 DNS 개념 자세히 알아보기

Google Cloud에서 DNS를 사용하는 경우 Google Cloud에서 DNS 확인 및 도메인 이름에 사용할 수 있는 다양한 시스템과 서비스를 이해하는 것이 중요합니다.

  • 내부 DNSCompute Engine의 가상 머신과 내부 부하 분산기에서 DNS 이름을 자동으로 생성하는 서비스입니다.
  • Cloud DNS는 지연 시간이 짧고 가용성이 높은 DNS 영역 서비스를 제공하는 서비스입니다. 인터넷에 공개되는 공개 영역 또는 네트워크 내에서만 보이는 비공개 영역에서 권한 있는 DNS 서버 역할을 할 수 있습니다. 자세한 내용은 Cloud DNS 개요를 참조하세요.
  • Microsoft Active Directory용 관리형 서비스는 가용성이 높고 강화된 서비스로, 도메인 컨트롤러를 포함한 Microsoft Active Directory를 실행합니다.
  • 공개 DNS는 Google Cloud에 포함되지 않은 Google 서비스로, 개방형 재귀 DNS 리졸버 역할을 합니다.
  • Google Domains는 도메인 구매, 이전 또는 관리를 위한 도메인 등록기관입니다. Google Cloud에 포함되지 않은 Google 서비스입니다.

이해관계자, 도구, 프로세스 파악

하이브리드 환경에서 DNS 전략을 수립할 때는 먼저 현재 아키텍처를 숙지하고 모든 이해관계자와 연락하는 것이 중요합니다. 다음을 수행하세요.

  • 조직의 회사 DNS 서버 관리자를 확인하고 연락합니다. Google Cloud의 적절한 아키텍처에 온프레미스 구성을 매핑하는 데 필요한 구성 정보를 요청합니다. 자세한 내용은 조건부 전달을 사용하여 온프레미스에서 DNS 레코드에 액세스에서 Google Cloud DNS 레코드에 액세스하는 방법을 참조하세요.
  • 현재 DNS 소프트웨어를 숙지하고 조직 내에서 비공개로 사용되는 도메인 이름을 확인합니다.
  • Cloud DNS 서버로 들어오는 트래픽이 올바르게 라우팅되는지 확인할 수 있는 네트워킹팀의 담당자를 확인합니다.
  • 하이브리드 및 멀티 클라우드 패턴과 권장사항을 통해 하이브리드 연결 전략을 숙지합니다.

간단하고 일관된 명명 표준 만들기

조직 전체에서 일관적이면서도 기억하기 쉬운 명명 표준을 만듭니다. 예를 들어 조직에서 example.com을 2차 도메인 이름 및 공개 리소스의 도메인(예: www.example.com)으로 사용한다고 가정해 보겠습니다. 공개 영역이 호스팅되는 환경은 이 문서의 주제를 벗어나므로 이 문서에서는 비공개 영역 마이그레이션만 다룹니다.

온프레미스 회사 리소스의 이름을 지정하려면 다음 패턴 중에서 선택합니다.

  • 온프레미스 서버와 Google Cloud의 도메인 이름을 분리합니다. 이 패턴은 각기 다른 환경에 별도의 도메인을 사용합니다. 예를 들어 온프레미스 서버에는 corp.example.com을 사용하고 Google Cloud의 모든 리소스에는 gcp.example.com을 사용합니다. 다른 퍼블릭 클라우드 환경을 사용하는 경우 각각 별도의 하위 도메인을 가질 수 있습니다. 환경 간에 요청을 전달하기 쉽기 때문에 권장되는 패턴입니다.

    example.comexample.cloud 같이 완전히 별개의 도메인 이름을 사용할 수도 있습니다.

  • Google Cloud 도메인을 온프레미스 서버가 포함된 도메인의 하위 도메인으로 만듭니다. example.com 도메인을 사용할 경우 온프레미스는 corp.example.com을, Google Cloud는 gcp.corp.example.com을 사용할 수 있습니다. 대부분의 리소스가 온프레미스로 유지되는 경우에 일반적인 패턴입니다.

  • 온프레미스 도메인을 Google Cloud 레코드가 포함된 도메인의 하위 도메인으로 만듭니다. example.com 도메인을 사용할 경우 Google Cloud는 corp.example.com을, 온프레미스는 dc.corp.example.com을 사용할 수 있습니다. 일반적이지 않은 패턴이지만 온프레미스 공간이 작은 디지털 기반 조직에서 사용할 수 있습니다.

  • Google Cloud 및 온프레미스에 동일한 도메인을 사용합니다. 이 경우 Google Cloud와 온프레미스가 모두 corp.example.com 도메인을 사용하는 리소스를 사용합니다. 이 패턴을 사용하면 하이브리드 환경에서 레코드 관리가 훨씬 어려워지므로 피해야 합니다. 권한 있는 단일 DNS 시스템을 사용하는 경우에만 가능합니다.

이 페이지의 나머지 부분에서는 다음 도메인 이름을 사용합니다.

  • example.com - 공개 레코드의 도메인 이름(공개 레코드가 어디서 호스팅되든 관계없음)
  • corp.example.com - 온프레미스 DNS 서버에서 호스팅하는 영역. 이 영역은 온프레미스 리소스의 레코드를 호스팅합니다.
  • gcp.example.com - Google Cloud 리소스의 레코드를 호스팅하는 Cloud DNS 비공개 관리형 영역

다음 다이어그램은 이 방식을 보여줍니다.

도메인 이름 설정 예시(확대하려면 클릭)
도메인 이름 설정 예시(확대하려면 클릭)

VPC 네트워크의 리소스 이름을 지정하려면 VPC 디자인 권장사항 및 참조 아키텍처의 가이드라인을 따르세요.

DNS 확인이 수행되는 위치 선택

하이브리드 환경에서는 여러 위치에서 DNS 확인이 수행될 수 있습니다. 다음 작업을 할 수 있습니다.

  • 권한 있는 DNS 시스템 2개로 하이브리드 접근법을 사용합니다.
  • 온프레미스에서 DNS 확인을 계속 수행합니다.
  • 모든 DNS 확인을 Cloud DNS로 이전합니다.

하이브리드 접근법이 권장되므로 이 문서에서는 이 접근법을 중점적으로 살펴봅니다. 하지만 완전한 설명을 위해 대체 접근법도 간략하게 설명합니다.

권한 있는 DNS 시스템 2개로 하이브리드 접근법 사용

권한 있는 DNS 시스템 2개로 하이브리드 접근법을 사용하는 것이 좋습니다. 이 접근법에 대한 설명은 다음과 같습니다.

  • 비공개 Google Cloud 환경에 대한 권한 있는 DNS 확인은 Cloud DNS에서 수행합니다.
  • 온프레미스 리소스에 대한 권한 있는 DNS 확인은 온프레미스의 기존 DNS 서버에서 호스팅합니다.

다음 다이어그램은 이 방식을 보여줍니다.

권한 있는 DNS 시스템 2개를 사용하는 하이브리드 아키텍처(확대하려면 클릭)
권한 있는 DNS 시스템 2개를 사용하는 하이브리드 아키텍처(확대하려면 클릭)

이 시나리오는 권장되는 사용 사례이며 이 문서에서 자세히 설명합니다. 이 문서에서는 다음 내용을 다룹니다.

  • 비공개 영역을 사용하는 환경 간 전달과 DNS 전달을 설정하는 방법
  • 방화벽 및 라우팅을 구성하는 방법
  • VPC 1개 또는 여러 개를 사용하는 방법을 보여주는 참조 아키텍처

온프레미스에서 DNS 확인 계속 수행

다른 접근법은 기존의 온프레미스 DNS 서버를 계속 사용하여 모든 내부 도메인 이름을 정식으로 호스팅하는 것입니다. 이 경우 대체 네임서버를 사용한 아웃바운드 DNS 전달을 통해 Google Cloud의 모든 요청을 전달할 수 있습니다. 이 접근법의 장점은 다음과 같습니다.

  • 비즈니스 프로세스에서 변경해야 할 부분이 적습니다.
  • 기존 도구를 계속 사용할 수 있습니다.
  • 온프레미스에서 거부 목록을 사용하여 개별 DNS 요청을 필터링할 수 있습니다.

하지만 다음과 같은 단점이 있습니다.

  • Google Cloud의 DNS 요청 지연 시간이 더 깁니다.
  • 시스템이 DNS 작업 시 온프레미스 연결에 의존합니다.
  • 자동 확장된 인스턴스 그룹과 같은 매우 유연한 환경을 통합하기가 어려울 수 있습니다.
  • Google Cloud 인스턴스 이름을 역확인하는 Cloud Dataproc 같은 제품과 시스템이 호환되지 않을 수 있습니다.

모든 DNS 확인을 Cloud DNS로 이전

또 다른 접근법은 모든 도메인 확인할 수 있는 권한이 있는 서비스인 Cloud DNS로 마이그레이션하는 것입니다. 그런 다음 비공개 영역 및 인바운드 DNS 전달을 사용하여 기존의 온프레미스 이름 확인을 Cloud DNS로 마이그레이션할 수 있습니다. 이 접근법의 장점은 다음과 같습니다.

  • 온프레미스에서 고가용성 DNS 서비스를 유지할 필요가 없습니다.
  • 시스템이 Cloud DNS를 사용하여 중앙 집중식 로깅 및 모니터링을 활용할 수 있습니다.

하지만 다음과 같은 단점이 있습니다.

  • 온프레미스의 DNS 요청 지연 시간이 더 깁니다.
  • 시스템에서 이름 확인을 위해 VPC 네트워크에 안정적으로 연결해야 합니다.

Cloud DNS 비공개 영역 권장사항

비공개 영역은 조직 내에서만 볼 수 있는 DNS 레코드를 호스팅합니다. Cloud DNS의 공개 영역은 이 문서에서 다루지 않습니다. 공개 영역은 공개 웹사이트의 DNS 레코드와 같은 조직의 공개 레코드를 포함하며 하이브리드 설정과 관련이 없기 때문입니다.

팀이 공유 VPC 호스트 프로젝트의 비공개 영역을 관리할 수 있도록 자동화 사용

조직 내에서 공유 VPC 네트워크를 사용하는 경우 호스트 프로젝트 내에서 Cloud DNS의 모든 비공개 영역을 호스팅해야 합니다. 모든 서비스 프로젝트는 공유 VPC 네트워크에 연결된 비공개 영역의 레코드에 자동으로 액세스할 수 있습니다.

다음 다이어그램은 공유 VPC 네트워크에서 비공개 영역이 호스팅되는 방식을 보여줍니다.

공유 VPC 네트워크에서 호스팅되는 비공개 영역(확대하려면 클릭)
공유 VPC 네트워크에서 호스팅되는 비공개 영역(확대하려면 클릭)

팀이 자체 DNS 레코드를 설정하도록 하려면 DNS 레코드 생성을 자동화하는 것이 좋습니다. 예를 들어 사용자가 특정 하위 도메인에서 자체 DNS 레코드를 설정하는 웹 애플리케이션 또는 내부 API를 만들 수 있습니다. 앱은 레코드가 조직 규칙을 준수하는지 확인합니다. 또는 DNS 구성을 Cloud Source Repositories와 같은 코드 저장소에 Terraform 또는 Cloud Deployment Manager 설명어 형태로 저장하고 팀의 pull 요청을 수락할 수 있습니다. 두 경우 모두 호스트 프로젝트에서 DNS 관리자 IAM 역할이 있는 서비스 계정은 변경사항이 승인된 후 자동으로 배포할 수 있습니다.

최소 권한 원칙을 사용하여 IAM 역할 설정

최소 권한의 보안 원칙을 사용하여 이 작업을 수행해야 하는 조직의 구성원에게만 DNS 레코드 변경 권한을 부여합니다. 기본 역할은 사용자에게 필요 이상의 리소스 액세스 권한을 부여할 수 있으므로 사용하지 마세요. Cloud DNS는 DNS에 한정된 읽기 및 쓰기 액세스 권한을 부여하는 권한과 역할을 제공합니다.

비공개 DNS 영역을 만드는 권한과 공개 영역을 만드는 권한을 구분해야 한다면 dns.networks.bindPrivateDNSZone 권한을 사용하세요.

DNS 전달 영역 권장사항

Cloud DNS는 온프레미스와 Google Cloud 환경 간에 DNS 이름 조회를 허용하기 위해 DNS 서버 정책DNS 전달 영역을 제공합니다. DNS 전달을 구성하는 옵션은 여러 가지가 있습니다. 다음 섹션에는 하이브리드 DNS 설정에 대한 권장사항이 나와 있습니다. 이러한 권장사항은 하이브리드 DNS용 참조 아키텍처에 설명되어 있습니다.

DNS 전달은 상호 연결 방식에 관계없이 서로 다른 Google Cloud 환경 간 전달에 사용할 수 없습니다. 이 사용 사례에서는 DNS 피어링을 사용합니다.

전달 영역을 사용하여 온프레미스 서버 쿼리

온프레미스 환경에서 DNS 레코드를 쿼리하려면 온프레미스에서 회사 리소스에 사용 중인 도메인(예: corp.example.com)의 전달 영역을 설정합니다. 이 접근법은 대체 네임서버를 사용 설정하는 DNS 정책을 사용하는 것보다 더 좋습니다. Compute Engine 내부 DNS 이름에 대한 액세스 권한이 유지되고 추가 홉 없이도 온프레미스 네임서버를 통해 공개 IP 주소를 계속 확인할 수 있습니다.

이 설정을 사용하는 트래픽 흐름은 참조 아키텍처에 나와 있습니다.

모든 DNS 트래픽을 온프레미스에서 모니터링 또는 필터링해야 하고 비공개 DNS 로깅으로 요구사항이 충족되지 않는 경우에만 대체 네임서버를 사용해야 합니다.

DNS 서버 정책을 사용하여 온프레미스의 쿼리 허용

온프레미스 호스트가 Cloud DNS 비공개 영역(예: gcp.example.com)에서 호스팅되는 DNS 레코드를 쿼리할 수 있도록 하려면 인바운드 DNS 전달을 사용하여 DNS 서버 정책을 만듭니다. 인바운드 DNS 전달을 사용하면 시스템이 내부 DNS 주소와 피어링된 영역뿐 아니라 프로젝트의 모든 비공개 영역을 쿼리할 수 있습니다. 각 서브넷마다 별도의 인바운드 전달자 IP 주소가 있지만 모든 DNS 쿼리가 동일한 응답을 반환하며 지연 시간에 차이가 없습니다. 앱에서 이러한 주소로 요청을 보낼 수 있습니다.

이 설정을 사용하는 트래픽 흐름은 참조 아키텍처에 나와 있습니다.

Google Cloud 및 온프레미스 방화벽을 열어 DNS 트래픽 허용

DNS 트래픽이 VPC 또는 온프레미스 내에서 필터링되지 않는지 확인합니다. 여기에는 다음이 포함됩니다.

  • 온프레미스 방화벽이 Cloud DNS에서 쿼리를 전달하는지 확인합니다. Cloud DNS는 35.199.192.0/19 IP 주소 범위에서 쿼리를 보냅니다. DNS는 요청 또는 응답의 크기에 따라 UDP 포트 53 또는 TCP 포트 53을 사용합니다.

  • DNS 서버가 쿼리를 차단하지 않는지 확인합니다. 온프레미스 DNS 서버에서 특정 IP 주소의 요청만 허용하는 경우 35.199.192.0/19 범위가 포함되어 있는지 확인합니다.

  • 트래픽이 온프레미스에서 전달 IP 주소로 전달될 수 있는지 확인합니다. 인바운드 전달의 경우 온프레미스 DNS 서버나 다른 클라이언트에서 전달 IP 주소로 전달되는 트래픽이 온프레미스 방화벽으로 인해 차단되지 않는지 확인합니다. UDP 포트 53의 모든 클라이언트에서 전달 IP 주소로 전달되는 트래픽을 허용하려면 온프레미스 방화벽에 방화벽 규칙을 만들어야 합니다.

조건부 전달을 사용하여 온프레미스에서 DNS 레코드에 액세스

Cloud DNS를 사용하여 회사 DNS 서버에서 호스팅되는 비공개 레코드에 액세스할 때는 전달 영역만 사용할 수 있습니다. 하지만 사용 중인 DNS 서버 소프트웨어에 따라 온프레미스에서 Google Cloud의 DNS 레코드에 액세스하는 옵션이 여러 개 있을 수 있습니다. 각각의 경우에 레코드에 대한 액세스는 인바운드 DNS 전달을 사용하여 이루어집니다.

  • 조건부 전달: 조건부 전달을 사용하면 회사 DNS 서버가 특정 영역 또는 하위 도메인에 대한 요청을 Google Cloud의 전달 IP 주소로 전달합니다. 이 접근법은 가장 덜 복잡하며 회사 DNS 서버의 모든 DNS 요청을 중앙 집중식으로 모니터링할 수 있으므로 권장됩니다.

  • 위임: Google Cloud의 비공개 영역이 온프레미스에서 사용하는 영역의 하위 도메인일 경우 해당 영역에 NS 항목을 설정하여 Google Cloud 네임서버에 하위 도메인을 위임할 수 있습니다. 이 설정을 사용하면 클라이언트가 Google Cloud에서 전달 IP 주소와 직접 통신할 수 있으므로 방화벽에서 이러한 요청을 허용해야 합니다.

  • 영역 전송: Cloud DNS는 영역 전송을 지원하지 않으므로 영역 전송을 사용하여 DNS 레코드를 온프레미스 DNS 서버와 동기화할 수 없습니다.

DNS 피어링을 사용하여 여러 VPC 네트워크의 아웃바운드 전달 방지

여러 VPC 네트워크에서 온프레미스 DNS 서버로의 아웃바운드 전달은 반환 트래픽에 문제를 일으키므로 사용해서는 안 됩니다. DNS 서버의 응답은 쿼리가 발생한 VPC로 라우팅된 경우에만 GCP에 의해 승인됩니다. 그러나 모든 VPC 쿼리의 소스는 35.199.192.0/19 IP 범위로 동일합니다. 따라서 온프레미스 환경이 완전히 분리되지 않으면 응답이 제대로 라우팅되지 않습니다.

다음 다이어그램은 아웃바운드 전달을 수행하는 여러 VPC의 문제를 보여줍니다.

아웃바운드 전달을 수행하는 여러 VPC의 문제(확대하려면 클릭)
아웃바운드 전달을 수행하는 여러 VPC의 문제(확대하려면 클릭)

아웃바운드 전달을 통해 온프레미스 네임서버를 쿼리하도록 단일 VPC를 지정하는 것이 좋습니다. 그러면 추가 VPC가 DNS 피어링 영역을 통해 지정된 VPC를 타겟팅하여 온프레미스 네임서버를 쿼리할 수 있습니다. 그러면 해당 쿼리가 지정된 VPC의 VPC 이름 확인 순서에 따라 온프레미스 네임서버에 전달됩니다. 이 설정은 참조 아키텍처 섹션에 나와 있습니다.

DNS 피어링과 VPC 네트워크 피어링의 차이점 이해

VPC 네트워크 피어링은 DNS 피어링과 다릅니다. VPC 네트워크 피어링을 사용하면 여러 프로젝트의 VM이 서로 연결될 수 있지만 이름 확인은 변경되지 않습니다. 각 VPC의 리소스는 계속 자체 확인 순서를 따릅니다. 반면 DNS 피어링을 사용하면 특정 영역의 요청을 다른 VPC로 전달하도록 허용할 수 있습니다. 따라서 VPC가 상호 연결되었는지 여부에 관계없이 다른 Google Cloud 환경으로 요청을 전달할 수 있습니다.

VPC 네트워크 피어링과 DNS 피어링도 서로 다르게 설정됩니다. VPC 네트워크 피어링의 경우 두 VPC 모두 다른 VPC와의 피어링 관계를 설정해야 합니다. 이때 피어링은 양방향으로 자동 설정됩니다.

DNS 피어링은 DNS 요청을 단방향으로 전달하며 VPC 간의 양방향 관계를 필요로 하지 않습니다. DNS 소비자 네트워크라고 하는 VPC 네트워크는 DNS 공급자 네트워크라고 하는 다른 VPC 네트워크의 Cloud DNS 피어링 영역에 대한 조회를 수행합니다. 공급자 네트워크의 프로젝트에 대한 IAM dns.networks.targetWithPeeringZone 권한이 있는 사용자는 소비자 네트워크와 공급자 네트워크 사이에 DNS 피어링을 설정할 수 있습니다. 소비자 VPC 네트워크의 DNS 피어링을 설정하려면 공급자 VPC 네트워크의 호스트 프로젝트에 대한 DNS 피어 역할이 필요합니다.

자동 생성 이름을 사용하는 경우 내부 영역에 DNS 피어링 사용

내부 DNS 서비스에서 만든 VM에 자동 생성 이름을 사용하는 경우 DNS 피어링을 사용하여 projectname.internal 영역을 다른 프로젝트에 전달할 수 있습니다. 모든 .internal 영역을 온프레미스에서 사용할 수 있도록 허브 프로젝트에 집계할 수 있습니다.

이 설정은 다음 다이어그램에 나와 있습니다.

메시 설정의 DNS 피어링(확대하려면 클릭)
메시 설정의 DNS 피어링(확대하려면 클릭)

문제가 있는 경우 문제해결 가이드를 따르세요.

Cloud DNS 문제해결 가이드는 Cloud DNS를 설정할 때 발생할 수 있는 일반적인 오류를 해결하는 방법에 대한 지침을 제공합니다.

하이브리드 DNS용 참조 아키텍처

이 섹션에서는 하이브리드 환경에서 Cloud DNS 비공개 영역을 사용하는 일반적인 시나리오에 대한 몇 가지 참조 아키텍처를 제공합니다. 각각의 경우에 온프레미스 리소스와 Google Cloud 리소스 레코드 및 영역이 모두 하이브리드 환경 내에서 관리됩니다. 온프레미스 및 Google Cloud 호스트의 모든 레코드를 쿼리할 수 있습니다.

VPC 디자인에 해당하는 참조 아키텍처를 사용해야 합니다.

  • 단일 공유 VPC를 사용하는 하이브리드 아키텍처 - 온프레미스와 연결된 단일 VPC 네트워크 사용

  • 여러 개의 개별 VPC 네트워크를 사용하는 하이브리드 아키텍처 - 여러 개의 VPN 터널 또는 VLAN 연결을 통해 여러 VPC를 온프레미스에 연결하고 온프레미스에서 동일한 DNS 인프라를 공유하는 경우

  • 스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처 - VPC 네트워크 피어링을 사용하여 여러 개의 독립된 스포크 VPC 네트워크에 허브 VPC 네트워크를 연결하는 경우

각각의 경우에 온프레미스 환경은 각각 1개 또는 여러 개의 Cloud VPN 터널이나 Cloud Interconnect를 통해 Google Cloud VPC에 연결됩니다(전용 또는 파트너 연결). 각 VPC 네트워크에 사용된 연결 방법은 관계없습니다.

단일 공유 VPC 네트워크를 사용하는 하이브리드 아키텍처

가장 일반적인 경우는 온프레미스 환경에 연결된 단일 공유 VPC 네트워크이며 다음 다이어그램에 나와 있습니다.

단일 공유 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)
단일 공유 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)

이 아키텍처를 설정하려면 다음 안내를 따르세요.

  1. 온프레미스 DNS 서버를 corp.example.com에 대한 권한이 있는 서버로 설정합니다.
  2. 공유 VPC 네트워크의 호스트 프로젝트에서 Cloud DNS의 권한 있는 비공개 영역(예: gcp.example.com)을 구성하고 리소스에 대한 모든 레코드를 해당 영역에 설정합니다.
  3. 공유 VPC 네트워크가 인바운드 DNS 전달을 허용하도록 호스트 프로젝트의 DNS 서버 정책 설정
  4. corp.example.com을 온프레미스 DNS 서버로 전달하는 DNS 전달 영역을 설정합니다. 공유 VPC는 전달 영역을 쿼리할 권한이 있어야 합니다.
  5. 온프레미스 DNS 서버에 gcp.example.com으로의 전달을 설정하고 공유 VPC 네트워크의 인바운드 전달자 IP 주소를 가리킵니다.
  6. DNS 트래픽이 온프레미스 방화벽에서 허용되는지 확인합니다.
  7. Cloud Router 인스턴스에서 35.199.192.0/19 범위의 커스텀 경로 공지를 온프레미스에 추가합니다.

여러 개의 개별 VPC 네트워크를 사용하는 하이브리드 아키텍처

하이브리드 아키텍처의 또 다른 옵션은 여러 개의 개별 VPC 네트워크를 사용하는 것입니다. Google Cloud 환경의 이러한 VPC 네트워크는 VPC 네트워크 피어링을 통해 서로 연결되어 있지 않습니다. 모든 VPC 네트워크는 별도의 Cloud VPN 터널 또는 VLAN 연결을 사용하여 온프레미스 환경에 연결됩니다. 이 아키텍처의 일반적인 사용 사례는 서로 통신하지 않고 DNS 서버를 공유하는 별도의 환경이 있는 경우입니다. 일반적인 사용 사례는 별도의 프로덕션 및 개발 환경을 사용하는 경우입니다.

이 아키텍처는 다음 다이어그램에 나와 있습니다.

여러 개의 개별 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)
여러 개의 개별 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)

이 아키텍처를 설정하려면 다음 안내를 따르세요.

  1. 온프레미스 DNS 서버를 corp.example.com에 대한 권한이 있는 서버로 설정합니다.
  2. 프로덕션 공유 VPC 네트워크의 호스트 프로젝트에서 Cloud DNS의 비공개 영역(예: prod.gcp.example.com)을 구성하고 해당 영역에 있는 리소스의 모든 레코드를 설정합니다.
  3. 개발 공유 VPC 네트워크의 호스트 프로젝트에서 Cloud DNS의 비공개 영역(예: dev.gcp.example.com)을 구성하고 해당 영역에 있는 리소스의 모든 레코드를 설정합니다.
  4. 프로덕션 공유 VPC 네트워크의 호스트 프로젝트에 DNS 서버 정책을 설정하고 인바운드 DNS 전달을 허용합니다.
  5. 프로덕션 공유 VPC 네트워크에서 corp.example.com을 온프레미스 DNS 서버로 전달하도록 DNS 영역을 설정합니다.
  6. 개발 공유 VPC 네트워크에서 프로덕션 공유 VPC 네트워크로의 DNS 피어링 영역을 example.com에 설정합니다.
  7. 프로덕션 공유 VPC 네트워크에서 개발 공유 VPC 네트워크로의 DNS 피어링 영역을 dev.gcp.example.com에 설정합니다.
  8. 온프레미스 DNS 서버에 gcp.example.com으로의 전달을 설정하고 프로덕션 공유 VPC 네트워크의 인바운드 전달자 IP를 가리킵니다.
  9. 방화벽에서 온프레미스 방화벽과 Google Cloud 방화벽의 DNS 트래픽을 모두 허용하는지 확인합니다.
  10. Cloud Router 인스턴스에서 프로덕션 공유 VPC 네트워크의 35.199.192.0/19 범위에 대한 커스텀 경로 공지를 온프레미스에 추가합니다.

스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처

또 다른 옵션은 Cloud Interconnect 또는 Cloud VPN을 사용하여 온프레미스 인프라를 단일 허브 VPC 네트워크에 연결하는 것입니다. VPC 네트워크 피어링을 사용하여 이 VPC 네트워크를 여러 스포크 VPC 네트워크와 피어링합니다. 각 스포크 VPC 네트워크는 Cloud DNS에서 자체 비공개 영역을 호스팅합니다. VPC 네트워크 피어링의 커스텀 경로와 Cloud Router의 커스텀 경로 공지는 온프레미스 및 모든 스포크 VPC 네트워크 간의 완전한 경로 교환과 연결을 허용합니다. DNS 피어링은 VPC 네트워크 피어링 연결과 동시에 실행되어 환경 간 이름 확인을 허용합니다.

이 아키텍처는 다음 다이어그램에 나와 있습니다.

스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)
스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처(확대하려면 클릭)

이 아키텍처를 설정하려면 다음 안내를 따르세요.

  1. 온프레미스 DNS 서버를 corp.example.com에 대한 권한이 있는 서버로 설정합니다.
  2. 각 스포크 VPC에서 Cloud DNS의 비공개 영역(예: projectX.gcp.example.com)을 구성하고 해당 영역에 있는 리소스의 모든 레코드를 설정합니다.
  3. 프로덕션 공유 VPC 네트워크의 허브 프로젝트에 DNS 서버 정책을 설정하여 인바운드 DNS 전달을 허용합니다.
  4. 허브 VPC에서 corp.example.com의 비공개 DNS 영역을 만들고 온프레미스 DNS 서버에 대한 아웃바운드 전달을 구성합니다.
  5. 허브 VPC에서 각 스포크 VPC로의 DNS 피어링 영역을 projectX.gcp.example.com에 설정합니다.
  6. 각 스포크 VPC에서 허브 VPC로의 DNS 피어링 영역을 example.com에 설정합니다.
  7. 온프레미스 DNS 서버에 gcp.example.com으로의 전달을 설정하여 허브 VPC의 인바운드 전달자 IP 주소를 가리킵니다.
  8. 방화벽에서 온프레미스 방화벽과 Google Cloud 방화벽의 DNS 트래픽을 모두 허용하는지 확인합니다.
  9. Cloud Router 인스턴스에서 허브 VPC의 35.199.192.0/19 범위에 대한 커스텀 경로 공지를 온프레미스에 추가합니다.
  10. (선택사항) 자동으로 생성되는 내부 DNS 이름을 사용하는 경우 각 스포크 프로젝트 영역(예: spoke-project-x.internal)을 허브 프로젝트와 피어링하고 온프레미스의 .internal에 대한 모든 쿼리를 전달합니다.

다음 단계