이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Cloud DNS에 대한 권장사항

이 문서에서는 비공개 영역, DNS 전달, 하이브리드 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 확인 및 도메인 이름에 사용할 수 있는 다양한 시스템과 서비스를 이해하는 것이 중요합니다.

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

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

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

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

일관된 명명 표준 만들기

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

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

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

example.com, example.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 비공개 관리형 영역

그림 1은 온프레미스 네트워크와 Google Cloud에서 일관된 도메인 이름 설정을 보여줍니다.

그림 1. 조직 전체에서 일관적인 도메인 이름 설정 — **그림 1.** 도메인 이름 설정이 조직 전체에서 일관적입니다.

Virtual Private Cloud(VPC) 네트워크 내에서 리소스 이름을 지정하려면 솔루션 가이드 VPC 설계에 관한 권장사항 및 참조 아키텍처의 가이드라인을 따르세요.

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

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

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

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

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

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

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

그림 2는 이 방식을 보여줍니다.

그림 2. Cloud DNS와 온프레미스 DNS 서버를 모두 사용하여 권한 DNS 변환을 제공하는 하이브리드 DNS 아키텍처 — **그림 2.** Cloud DNS와 온프레미스 DNS 서버를 모두 사용하는 하이브리드 DNS 아키텍처가 권한 DNS 변환을 제공합니다.

그림 2에 표시된 시나리오는 권장되는 사용 사례입니다. 다음 세부정보는 이 페이지의 뒷부분에서 다룹니다.

비공개 영역을 사용하는 환경 간 전달과 DNS 전달을 설정하는 방법
방화벽 및 라우팅을 구성하는 방법
하나 이상의 VPC 네트워크를 사용하는 방법을 보여주는 참조 아키텍처

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

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

이 접근법의 장점은 다음과 같습니다.

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

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

Google Cloud의 DNS 요청 지연 시간이 더 깁니다.
시스템이 DNS 작업 시 온프레미스 환경과의 연결을 활용합니다.
자동 확장된 인스턴스 그룹과 같은 매우 유연한 환경을 통합하기가 어려울 수 있습니다.
Google 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 네트워크에 연결된 비공개 영역의 레코드에 자동으로 액세스할 수 있습니다. 또는 프로젝트 간 바인딩을 사용하여 서비스 프로젝트에서 영역을 설정할 수 있습니다.

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

그림 3. 공유 VPC 네트워크에서 호스팅되는 비공개 영역(확대하려면 클릭) — **그림 3.** 이 설정은 비공개 영역이 공유 VPC에 연결되는 방식을 보여줍니다.

팀이 자체 DNS 레코드를 설정하도록 하려면 DNS 레코드 생성을 자동화하는 것이 좋습니다. 예를 들어 사용자가 특정 하위 도메인에서 자체 DNS 레코드를 설정하는 웹 애플리케이션 또는 내부 API를 만들 수 있습니다. 앱은 레코드가 조직 규칙을 준수하는지 확인합니다.

또는 DNS 구성을 Cloud Source Repositories와 같은 코드 저장소에 Terraform 또는 Cloud Deployment Manager 설명어 형태로 저장하고 팀의 pull 요청을 수락할 수 있습니다.

두 경우 모두 호스트 프로젝트에서 IAM DNS 관리자 역할이 있는 서비스 계정은 변경사항이 승인된 후 자동으로 배포할 수 있습니다.

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

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

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

DNS 전달 영역 및 서버 정책에 대한 권장사항

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

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

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

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

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

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

온프레미스 호스트가 Cloud DNS 비공개 영역(예: gcp.example.com)에서 호스팅되는 DNS 레코드를 쿼리할 수 있도록 하려면 인바운드 DNS 전달을 사용하여 DNS 서버 정책을 만듭니다. 인바운드 DNS 전달을 사용하면 시스템이 내부 DNS IP 주소와 피어링된 영역뿐 아니라 프로젝트의 모든 비공개 영역을 쿼리할 수 있습니다.

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

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

다음을 수행하여 DNS 트래픽이 VPC 네트워크 또는 온프레미스 환경 내에서 필터링되지 않도록 합니다.

온프레미스 방화벽이 Cloud DNS의 쿼리를 전달하는지 확인합니다. Cloud DNS는 IP 주소 범위 35.199.192.0/19에서 쿼리를 보냅니다. DNS는 요청 또는 응답의 크기에 따라 UDP 포트 53 또는 TCP 포트 53을 사용합니다.
DNS 서버가 쿼리를 차단하지 않는지 확인합니다. 온프레미스 DNS 서버에서 특정 IP 주소의 요청만 허용하는 경우 IP 주소 범위 35.199.192.0/19가 포함되어 있는지 확인합니다.
트래픽이 온프레미스에서 전달 IP 주소로 전달될 수 있는지 확인합니다. Cloud Router 인스턴스에서 VPC 네트워크의 IP 주소 범위 35.199.192.0/19에 대한 커스텀 공지 경로를 온프레미스 환경에 추가합니다.

조건부 전달을 사용하여 온프레미스에서 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 서버로의 아웃바운드 전달은 반환 트래픽에 문제를 일으키므로 사용해서는 안 됩니다. Google Cloud는 쿼리가 발생한 VPC 네트워크로 라우팅된 경우에만 DNS 서버의 응답을 허용합니다. 그러나 모든 VPC 네트워크 쿼리의 소스는 IP 주소 범위 35.199.192.0/19로 동일합니다. 따라서 온프레미스 환경이 분리되지 않으면 응답이 제대로 라우팅되지 않습니다.

그림 4. 여러 VPC가 네트워크 외부로 트래픽을 전달하는 경우 문제가 발생합니다. — **그림 4.** 여러 VPC 네트워크가 아웃바운드 전달을 수행하는 경우의 문제

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

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 영역을 다른 프로젝트에 전달할 수 있습니다. 그림 5와 같이 허브 프로젝트에서 모든 .internal 영역을 그룹화하여 온프레미스 네트워크에서 액세스하도록 할 수 있습니다.

그림 5. DNS 피어링은 모든 .internal 영역을 허브로 구성하는 데 사용됩니다. — **그림 5.** DNS 피어링은 모든 `.internal` 영역을 허브로 구성하는 데 사용됩니다.

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

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

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

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

VPC 네트워크 설계에 매핑되는 참조 아키텍처를 사용합니다.

단일 공유 VPC 네트워크를 사용하는 하이브리드 아키텍처: 온프레미스 환경과 연결된 단일 VPC 네트워크를 사용합니다.
여러 개의 개별 VPC 네트워크를 사용하는 하이브리드 아키텍처: 서로 다른 VPN 터널 또는 VLAN 연결을 통해 여러 VPC 네트워크를 온프레미스 환경에 연결하고 온프레미스에서 동일한 DNS 인프라를 공유합니다.
스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용하는 하이브리드 아키텍처: VPC 네트워크 피어링을 사용하여 여러 개의 독립된 스포크 VPC 네트워크에 허브 VPC 네트워크를 연결합니다.

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

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

가장 일반적인 사용 사례는 그림 6과 같이 온프레미스 환경에 연결된 단일 공유 VPC 네트워크입니다.

그림 6. 하이브리드 아키텍처는 단일 공유 VPC 네트워크를 사용하여 온프레미스 네트워크에 연결합니다. — **그림 6.** 하이브리드 아키텍처는 단일 공유 VPC 네트워크를 사용하여 온프레미스 네트워크에 연결합니다.

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

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

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

하이브리드 아키텍처의 또 다른 옵션은 여러 개의 개별 VPC 네트워크를 사용하는 것입니다. Google Cloud 환경의 이러한 VPC 네트워크는 VPC 네트워크 피어링을 통해 서로 연결되어 있지 않습니다. 모든 VPC 네트워크는 별도의 Cloud VPN 터널 또는 VLAN 연결을 사용하여 온프레미스 환경에 연결합니다.

그림 7에 표시된 것처럼 이 아키텍처의 일반적인 사용 사례는 서로 통신하지 않고 DNS 서버를 공유하는 별도의 프로덕션 및 개발 환경이 있는 경우입니다.

그림 7. 하이브리드 아키텍처는 여러 개의 개별 VPC 네트워크를 사용할 수 있습니다. — **그림 7.** 하이브리드 아키텍처는 여러 개의 개별 VPC 네트워크를 사용할 수 있습니다.

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

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

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

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

다음 다이어그램은 이 아키텍처를 보여줍니다.

그림 8. 하이브리드 아키텍처는 VPC 네트워크 피어링을 사용하여 스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용할 수 있습니다. — **그림 8.** 하이브리드 아키텍처는 스포크 VPC 네트워크에 연결된 허브 VPC 네트워크를 사용할 수 있습니다.

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

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

Cloud DNS를 사용하는 다중 공급업체 공개 DNS

애플리케이션 네트워킹의 기본 구성요소인 안정적인 DNS는 사용자가 애플리케이션 또는 서비스를 사용할 수 있게 하는 데 필수적입니다. 여러 DNS 제공업체를 구성하여 애플리케이션과 서비스의 가용성과 복원력을 향상시킬 수 있습니다. 여러 DNS 공급업체가 구성되면 DNS 제공업체 중 하나에서 서비스 중단이 발생하더라도 사용자가 애플리케이션 또는 서비스를 사용할 수 있습니다. 또한 다중 공급업체 DNS 구성을 통해 온프레미스 및 클라우드 환경에서 종속 항목이 있는 하이브리드 애플리케이션의 배포 및 마이그레이션을 간소화할 수 있습니다.

Google Cloud는 다중 DNS 제공업체를 통해 환경을 설정하고 운영하는 데 도움이 되는 octoDNS 기반의 오픈소스 솔루션을 제공합니다. 다중 제공업체 DNS 솔루션은 Cloud DNS를 활성-활성(권장) 또는 활성-수동 구성에서 DNS 제공업체 중 하나로 활용하여 고가용성 DNS 아키텍처를 보장합니다. 솔루션을 배포하면 octoDNS가 현재 DNS 영역과 Cloud DNS에서 호스팅되는 관리형 DNS 영역 간에 지속적인 동기화는 물론 일회성 동기화도 수행합니다. 개별 DNS 레코드가 업데이트되면 CI/CD 파이프라인을 변경하지 않아도 Cloud DNS에서 호스팅되는 해당 DNS 영역에 변경사항이 전파됩니다.

다중 공급업체 공개 DNS 구성에서 Cloud DNS를 구성하려면 multi-provider-dns-with-clouddns를 참조하세요.

다음 단계

Cloud DNS를 사용할 때 발생할 수 있는 일반적인 문제에 대한 해결책을 찾으려면 문제 해결을 참조하세요.
Google Cloud를 사용하는 하이브리드 설정에 접근하고 구현하는 방법에 대한 안내는 하이브리드 및 멀티 클라우드 패턴과 권장사항 솔루션 가이드를 참조하세요.
그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.