이 문서에서는 멀티 리전 부하 분산기를 Google DNS 라우팅 정책과 결합하여 전역 부하 분산 아키텍처를 만드는 방법을 설명합니다. 이 문서는 네트워크 엔지니어, 솔루션 아키텍트, 운영 전문가를 대상으로 합니다. 여기서는 Google Compute Engine에 대한 기본 지식이 있고 부하 분산기, DNS 조회와 같은 네트워킹 개념에 익숙하다고 가정합니다.
소개
여러 리전에서 실행되는 애플리케이션으로 구현되는 전역 서비스를 빌드하는 경우 위치정보 DNS 라우팅 정책을 사용하여 리전 부하 분산기에 대한 전역 DNS 엔드포인트를 만들 수 있습니다. 이 방식에서는 가장 가까운 로컬 서비스로 트래픽을 라우팅하는 전역 엔드포인트를 만듭니다.
사용 중인 부하 분산기 유형에 따라 전역 프록시 기반 부하 분산 옵션을 사용하여 이 시나리오를 실현할 수 있습니다. 그러나 서비스가 UDP 트래픽을 제공하는 경우와 같은 일부 사용 사례에서는 리전 부하 분산 제품을 사용해야 합니다. 위치정보 DNS 라우팅 정책은 Google Cloud를 다른 클라우드 서비스 제공업체나 온프레미스 배포와 함께 사용하는 하이브리드 애플리케이션에 단일 DNS 엔드포인트를 제공하는 데에도 도움이 됩니다.
아키텍처
다음 다이어그램은 서로 다른 세 리전의 부하 분산기 세 개를 사용하는 샘플 아키텍처를 보여줍니다. DNS 라우팅 정책을 사용하여 리전이 결합됩니다.
위 다이어그램은 오리건, 독일, 싱가포르의 클라이언트가 www.example.com의 Cloud DNS에 대해 DNS 조회를 수행하는 모습을 보여줍니다. 각 클라이언트에 가까운 리전 부하 분산기로 요청이 라우팅되어 서로 다른 세 리전에서 호스팅되는 애플리케이션에 도달합니다.
위치정보 DNS 라우팅 정책의 사용 사례
이 섹션에서는 위치정보 DNS 라우팅 정책을 사용하여 멀티 리전 부하 분산기로 전역 서비스를 만드는 다음과 같은 사용 사례를 설명합니다.
전 세계에서 액세스 가능한 글로벌 분산형 내부 서비스
위치정보 DNS 라우팅 정책을 사용하여 멀티 리전 내부 부하 분산기를 결합하면 전 세계에서 액세스 가능한 글로벌 분산형 내부 서비스를 만들 수 있습니다. 내부 패스 스루 네트워크 부하 분산기 또는 내부 애플리케이션 부하 분산기를 사용하면 됩니다. DNS 라우팅 정책이 없으면 내부 애플리케이션 부하 분산기가 리전 엔드포인트만 사용할 수 있습니다. 전역 액세스를 사용하는 내부 패스 스루 네트워크 부하 분산기를 통해 전 세계에 서비스를 제공할 수 있지만, 이 경우 백엔드를 단일 리전에만 둘 수 있습니다. 그러나 DNS 라우팅 정책을 사용하면 백엔드를 여러 리전에 둘 수 있습니다.
다음 다이어그램은 이 아키텍처를 보여줍니다.
앞의 다이어그램은 여러 리전에 있는 내부 클라이언트가 Cloud DNS를 사용하여 service.corp.example.com을 해석하는 방법을 보여줍니다. 클라이언트가 받는 응답에는 클라이언트의 리전에 위치한 내부 패스 스루 네트워크 부하 분산기에 속하는 IP 주소가 항상 포함됩니다. 부하 분산기는 동일한 리전에 있는 애플리케이션을 가리킵니다. 이 예시에서는 애플리케이션이 Google Kubernetes Engine(GKE)에서 실행되지만 필수 조건은 아닙니다. 클라이언트는 애플리케이션 트래픽을 애플리케이션의 로컬 인스턴스로 전송하지만 모두 동일한 service.corp.example.com DNS 엔드포인트를 사용합니다.
다음 단계에 따라 이 구성을 만들 수 있습니다.
- 각 리전에 내부 부하 분산기를 만듭니다. 내부 패스 스루 네트워크 부하 분산기를 사용하는 경우 다른 리전의 클라이언트가 서비스에 연결할 수 있도록 전역 액세스를 사용 설정해야 합니다.
DNS 라우팅 정책을 만듭니다. 정책에서 유형을
GEO로 설정하고--routing-policy-data값을 해당 내부 부하 분산기에 매핑되는 대상 리전 목록으로 설정합니다. 다음 명령어를 사용하여 다이어그램에 표현된 설정을 만들 수 있습니다.gcloud beta dns record-sets create service.corp.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \ --enable-health-checking
이 예시에서는 정책이 변경되는 경우 클라이언트가 DNS 레코드를 자주 새로고침하도록 TTL 값이 30초인 레코드를 만듭니다.
DNS 라우팅 정책을 사용하면 각 클라이언트가 리전의 내부 부하 분산기의 IP 주소가 포함된 DNS 응답을 수신합니다. 내부 부하 분산기가 정의된 리전 외부에 클라이언트가 있는 경우 가장 가까운 리전에 있는 내부 부하 분산기의 IP 주소를 수신합니다.
DNS 라우팅 정책은 가장 가까운 내부 부하 분산기 리전을 기준으로 트래픽을 라우팅합니다. 지리적 DNS 라우팅 정책과 함께 상태 점검 기능을 사용하는 경우 해당 리전의 백엔드 중 80% 이상이 비정상 상태이면 트래픽이 리전 간에 장애 조치됩니다.
리전 간 장애 조치가 필요하지 않으면 다음과 같이 명령어를 변경할 수 있습니다.
--enable-health-checking플래그를 삭제합니다.- 내부 부하 분산기의 각 전달 규칙 이름을 해당 IP 주소로 바꿉니다.
TCP 및 UDP를 지원하는 외부 서비스의 전역 엔드포인트
위치정보 DNS 라우팅 정책을 사용하여 여러 리전 외부 부하 분산기를 결합하면 외부 서비스의 전역 DNS 엔드포인트를 만들 수도 있습니다. 가장 일반적인 사용 사례는 TCP 기반 또는 UDP 기반 애플리케이션에 외부 패스 스루 네트워크 부하 분산기를 사용하는 것입니다. Google Cloud에서 UDP용으로 제공되는 전역 부하 분산 옵션이 없으므로 이 방법은 UDP를 사용하는 애플리케이션에 특히 유용합니다.
외부 프록시 네트워크 부하 분산기 또는 외부 애플리케이션 부하 분산기에서 지원하는 TCP 트래픽을 사용하는 애플리케이션의 경우 DNS 엔드포인트를 사용하는 대신 해당 전역 부하 분산기의 인스턴스를 사용할 수도 있습니다. 이러한 부하 분산기는 모든 백엔드 인스턴스에 단일 IP 주소를 프런트엔드로 제공하는 anycast를 사용하여 리전 간 부하 분산을 제공합니다.
전역 부하 분산 옵션을 사용하면 DNS 엔드포인트에 비해 다음과 같은 이점이 있습니다.
- 장애 조치가 즉시 수행됩니다. 장애 조치가 발생해도 사용자 입장에서 트래픽 흐름의 변화가 인지되지 않습니다.
- 인터넷 라우팅이 부하 분산 대상을 결정합니다. Cloud DNS가 대상 위치를 선택하는 대신 인터넷 라우팅 프로토콜이 최단 경로를 기준으로 트래픽을 전달합니다.
- 리전 간 부하 분산. Google의 전역 부하 분산은 리전 간 장애 조치를 지원합니다. 반면에 외부 패스 스루 네트워크 부하 분산기를 사용할 때는 DNS 라우팅 정책에 대한 상태 점검이 없습니다.
따라서 애플리케이션이 TCP 기반이고 해당 제품에서 지원되는 경우 Google의 전역 부하 분산 옵션을 사용하는 것이 좋습니다.
다음 다이어그램은 전역 DNS 엔드포인트를 사용하는 아키텍처를 보여줍니다.
앞의 다이어그램은 여러 리전의 외부 클라이언트가 Cloud DNS를 사용하여 www.example.com을 해석하는 방법을 보여줍니다. 클라이언트는 클라이언트의 리전에 있는 네트워크 TCP/UDP 부하 분산기에 속하는 IP 주소로 응답을 받습니다. 그러면 클라이언트가 동일한 리전에서 실행 중인 애플리케이션에 연결할 수 있습니다. 각 클라이언트는 애플리케이션 트래픽을 서비스의 로컬 인스턴스로 전송하지만 모두 동일한 www.example.com DNS 엔드포인트를 사용합니다.
다음 단계에 따라 이 구성을 만들 수 있습니다.
- 각 리전에 네트워크 TCP/UDP 부하 분산기를 만듭니다.
DNS 라우팅 정책을 만듭니다. 정책에서 유형을
GEO로 설정하고--routing-policy-data값을 해당 네트워크 TCP/UDP 부하 분산기에 매핑되는 대상 리전 목록으로 설정합니다. 다음 명령어를 사용하여 다이어그램에 표현된 설정을 만들 수 있습니다.gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
이 정책을 적용한 후 클라이언트가 DNS 요청을 수행하면 각 클라이언트가 자신과 가장 가까운 리전에 있는 외부 패스 스루 네트워크 부하 분산기의 IP 주소가 포함된 DNS 응답을 받습니다.
외부 패스 스루 네트워크 부하 분산기를 사용할 때는 상태 점검이 없으므로 전역 엔드포인트 www.example.com을 사용하면 리전 간에 트래픽 장애 조치를 자동으로 수행할 수 없습니다. 사용자가 DNS 레코드를 변경하여 장애 조치를 수동으로 트리거해야 합니다.
이 방식으로 해결 가능한 또 다른 사용 사례는 애플리케이션에서 데이터의 리전성 요구사항에 따라 HTTP(S)를 사용하지만 여전히 전역 엔드포인트를 사용하여 데이터를 제공하려는 경우입니다. 위치정보 DNS 라우팅 정책을 사용하여 여러 리전 외부 애플리케이션 부하 분산기 인스턴스를 결합하면 이 시나리오를 구현할 수 있습니다. 리전 요구사항이 없으면 전역 외부 애플리케이션 부하 분산기를 사용할 수 있습니다.
하이브리드 서비스의 전역 DNS 엔드포인트
경우에 따라 위치정보 DNS 라우팅 정책을 사용하여 하이브리드 애플리케이션에 단일 엔드포인트를 제공할 수 있습니다.
다음 다이어그램은 이 아키텍처를 보여줍니다.
앞의 다이어그램은 여러 리전의 외부 클라이언트가 Cloud DNS를 사용하여 www.example.com을 해석하는 방법을 보여줍니다. Cloud DNS는 아시아와 미국의 인터넷 사용자를 사용자에게 가까운 리전에 있는 네트워크 TCP/UDP 부하 분산기에 속하는 IP 주소로 연결합니다. 부하 분산기가 가리키는 애플리케이션은 동일한 리전의 GKE에서 실행됩니다. 유럽의 인터넷 사용자를 위해 Cloud DNS는 VMware용 GKE에서 호스팅되는 애플리케이션을 사용하여 유럽 온프레미스 데이터 센터의 부하 분산기를 가리키는 IP 주소를 반환합니다. 이 예시에서는 애플리케이션이 VMware용 GKE와 GKE에서 실행되지만 필수 조건은 아닙니다.
다음 단계에 따라 이 구성을 만들 수 있습니다.
- 각 리전에 네트워크 TCP/UDP 부하 분산기와 온프레미스 부하 분산기를 만듭니다.
DNS 라우팅 정책을 만듭니다. 정책에서 유형을
GEO로 설정하고--routing-policy-data값을 해당 네트워크 TCP/UDP 부하 분산기에 매핑되는 대상 리전 목록으로 설정합니다. 다음 명령어를 사용하여 다이어그램에 표현된 설정을 만들 수 있습니다.gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
--routing-policy-data 플래그를 설정하면 Cloud DNS에서 가장 가까운 Google Cloud 리전을 기준으로 다른 IP 주소를 반환할 수 있습니다.
그러나 클라이언트의 정확한 국가 또는 지리적 리전을 기준으로 트래픽을 라우팅할 수는 없습니다. 앞의 예시에서 대부분의 사용자는 자신의 대륙에 위치한 리전이나 온프레미스 데이터 센터로 전송됩니다. 그러나 Cloud DNS가 가장 가까운 Google Cloud 리전을 판단하는 데 사용하는 알고리즘은 특정 국가 또는 지역 경계와 일치하지 않을 수 있습니다. 따라서 규정 준수 사용 사례에는 위치정보 DNS 라우팅 정책을 사용할 수 없습니다.
이 예시에서 보여주는 대륙 수준보다 더 세밀한 관리가 필요한 여타 사용 사례는 이 하이브리드 접근 방식으로 해결할 수 없습니다. 예를 들어 Google Cloud 리전이 없는 국가에 온프레미스 데이터 센터가 있는 경우 해당 국가 또는 리전의 사용자에 대해 온프레미스로 트래픽을 전송할 수 없으며, 가장 가까운 Google Cloud 리전을 기준으로 IP 주소를 반환하도록 부하 분산기를 구성할 수만 있습니다. 정확한 지리적 위치 또는 국가를 기준으로 트래픽을 제한하거나 라우팅하려는 경우 DNS 기반 전역 서버 부하 분산(GSLB) 서비스를 제공하는 타사 제공업체를 이용할 수 있습니다.
다음 단계
- DNS 라우팅 정책 관리
- DNS 권장사항
- 부하 분산기 특징
- 부하 분산으로 애플리케이션 지연 최적화
- 클라우드 아키텍처 센터에서 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항 알아보기