Cloud Storage 버킷으로 리전 간 내부 애플리케이션 부하 분산기 설정

미리보기

이 제품 또는 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 제품 및 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

이 문서에서는 정적 콘텐츠 요청을 Cloud Storage 버킷으로 라우팅하기 위해 리전 간 내부 애플리케이션 부하 분산기를 만드는 방법을 보여줍니다.

시작하기 전에

설정이 다음 기본 요건을 충족하는지 확인합니다.

Google Cloud CLI 설치

미리보기의 경우 이 가이드의 일부 안내는 Google Cloud CLI를 사용하여야만 실행할 수 있습니다. 설치하려면 gcloud CLI 설치 문서를 참고하세요.

API 및 gcloud CLI 참조 문서에서 부하 분산과 관련된 명령어를 확인할 수 있습니다.

권한

이 가이드를 따르려면 프로젝트에 Cloud Storage 버킷과 네트워크 리소스를 만들어야 합니다. 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 보유해야 합니다.

작업	필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기	Compute 네트워크 관리자 역할 (roles/compute.networkAdmin)
방화벽 규칙 추가 및 삭제	Compute 보안 관리자 역할(roles/compute.securityAdmin)
Cloud Storage 버킷 만들기	스토리지 객체 관리자 역할 (roles/storage.objectAdmin)

자세한 내용은 다음 가이드를 참조하세요.

• 액세스 제어
• IAM 조건

SSL 인증서 리소스 설정

HTTPS를 요청 및 응답 프로토콜로 사용하는 리전 간 내부 애플리케이션 부하 분산기의 경우 다음 문서 중 하나에 설명된 대로 인증서 관리자를 사용하여 SSL 인증서 리소스를 만듭니다.

• CA 서비스 인스턴스에서 발급한 Google 관리형 인증서 만들기
• DNS 승인을 사용하여 전역 Google 관리형 인증서 배포
• 전역 자체 관리형 인증서 배포

인증서를 만든 후 인증서를 HTTPS 대상 프록시에 연결할 수 있습니다.

Google 관리형 인증서를 사용하는 것이 좋습니다.

제한사항

리전 간 내부 애플리케이션 부하 분산기의 백엔드로 제공할 때 Cloud Storage 버킷에는 다음과 같은 제한사항이 적용됩니다.

• 비공개 버킷 액세스는 지원되지 않으므로 백엔드 버킷에 인터넷을 통해 공개적으로 액세스할 수 있어야 합니다.

• 서명된 URL은 지원되지 않습니다.

• 리전 간 내부 애플리케이션 부하 분산기의 백엔드 버킷을 만들 때는 Cloud CDN 통합을 사용할 수 없습니다.

• 리전 간 내부 애플리케이션 부하 분산기를 사용하여 백엔드 버킷에 액세스하는 경우 HTTP GET 메서드만 지원됩니다. 버킷에서 콘텐츠를 다운로드할 수는 있지만 리전 간 내부 애플리케이션 부하 분산기를 통해 버킷에 콘텐츠를 업로드할 수는 없습니다.

설정 개요

다음 다이어그램과 같이 여러 리전에서 리전 간 내부 애플리케이션 부하 분산기를 구성할 수 있습니다.

Cloud Storage로 트래픽 분산 (클릭하여 확대)

아키텍처 다이어그램에서 볼 수 있듯이 이 예시에서는 두 개의 백엔드 버킷이 있는 Virtual Private Cloud (VPC) 네트워크에서 리전 간 내부 애플리케이션 부하 분산기를 만듭니다. 여기서 각 백엔드 버킷은 Cloud Storage 버킷을 참조합니다. Cloud Storage 버킷은 us-east1 및 asia-east1 리전에 있습니다.

이 배포 아키텍처는 고가용성을 제공합니다. 한 리전의 리전 간 내부 애플리케이션 부하 분산기가 실패하면 DNS 라우팅 정책이 다른 리전의 리전 간 내부 애플리케이션 부하 분산기로 트래픽을 라우팅합니다.

네트워크 및 서브넷 구성

VPC 네트워크 내에서 부하 분산기의 전달 규칙을 구성할 각 리전에서 서브넷을 구성합니다. 또한 부하 분산기를 구성하려는 각 리전에 proxy-only-subnet을 구성합니다.

이 예시에서는 다음 VPC 네트워크, 리전 및 서브넷을 사용합니다.

• 네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은 lb-network입니다.

• 부하 분산기용 서브넷 us-east1 리전에 있는 subnet-us라는 이름의 서브넷은 기본 IP 범위로 10.1.2.0/24을 사용합니다. asia-east1 리전에 있는 subnet-asia이라는 이름의 서브넷은 기본 IP 범위로 10.1.3.0/24을 사용합니다.

• Envoy 프록시용 서브넷 us-east1 리전에 있는 proxy-only-subnet-us-east1이라는 이름의 서브넷은 기본 IP 범위로 10.129.0.0/23을 사용합니다. asia-east1 리전에 있는 proxy-only-subnet-asia-east1이라는 이름의 서브넷은 기본 IP 범위로 10.130.0.0/23를 사용합니다.

리전 간 내부 애플리케이션 부하 분산기는 VPC 내의 모든 리전에서 액세스할 수 있습니다. 따라서 모든 리전의 클라이언트가 부하 분산기 백엔드에 전역으로 액세스할 수 있습니다.

부하 분산기의 전달 규칙에 대한 서브넷 구성

콘솔

1. Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

   VPC 네트워크로 이동

2. VPC 네트워크 만들기를 클릭합니다.

3. 이름에 lb-network를 입력합니다.

4. 서브넷 섹션에서 서브넷 생성 모드를 커스텀으로 설정합니다.

5. 새 서브넷 섹션에 다음 정보를 입력합니다.

   • 이름: subnet-us
   • 리전으로 us-east1를 선택합니다.
   • IP 주소 범위: 10.1.2.0/24

6. 완료를 클릭합니다.

7. 서브넷 추가를 클릭합니다.

8. 다른 리전에서 부하 분산기의 전달 규칙에 관한 다른 서브넷을 만듭니다. 새 서브넷 섹션에 다음 정보를 입력합니다.

   • 이름: subnet-asia
   • 리전: asia-east1
   • IP 주소 범위: 10.1.3.0/24

9. 완료를 클릭합니다.

10. 만들기를 클릭합니다.

gcloud

1. gcloud compute networks create 명령어를 사용하여 lb-network라는 커스텀 VPC 네트워크를 만듭니다.

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. gcloud compute networks subnets create 명령어를 사용하여 us-east1 리전의 lb-network VPC 네트워크에 서브넷을 만듭니다.

   gcloud compute networks subnets create subnet-us \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-east1
   

3. gcloud compute networks subnets create 명령어를 사용하여 asia-east1 리전의 lb-network VPC 네트워크에 서브넷을 만듭니다.

   gcloud compute networks subnets create subnet-asia \
       --network=lb-network \
       --range=10.1.3.0/24 \
       --region=asia-east1
   

프록시 전용 서브넷 구성

프록시 전용 서브넷은 Google Cloud 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 프록시는 클라이언트의 연결을 종료하고 백엔드에 새 연결을 만듭니다.

이 프록시 전용 서브넷은 VPC 네트워크와 동일한 리전에 있는 모든 Envoy 기반 리전 부하 분산기에서 사용됩니다. 네트워크당 리전별 활성 프록시 전용 서브넷은 용도별로 하나만 있을 수 있습니다.

중요: 프록시 전용 서브넷의 주소를 부하 분산기의 전달 규칙 또는 백엔드에 할당하지 마세요. 전달 규칙의 IP 주소와 백엔드 인스턴스 IP 주소를 이 서브넷이 아닌 다른 서브넷 범위에서 할당합니다.Google Cloud 는 이 서브넷 범위를 Google Cloud관리형 프록시용으로 예약합니다.

콘솔

1. Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

   VPC 네트워크로 이동

2. 만든 VPC 네트워크의 이름을 클릭합니다.

3. 서브넷 탭에서 서브넷 추가를 클릭합니다.

4. 다음 정보를 입력합니다.

   • 이름: proxy-only-subnet-us
   • 리전: us-east1
   • IP 주소 범위: 10.129.0.0/23

5. 추가를 클릭합니다.

6. 다른 리전에서 부하 분산기의 전달 규칙에 관한 다른 서브넷을 만듭니다. 서브넷 탭에서 서브넷 추가를 클릭합니다.

7. 다음 정보를 입력합니다.

   • 이름: proxy-only-subnet-asia
   • 리전: asia-east1
   • IP 주소 범위: 10.130.0.0/23

8. 추가를 클릭합니다.

gcloud

1. gcloud compute networks subnets create 명령어를 사용하여 us-east1 리전에 프록시 전용 서브넷을 만듭니다.

   gcloud compute networks subnets create proxy-only-subnet-us \
       --purpose=GLOBAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=us-east1 \
       --network=lb-network \
       --range=10.129.0.0/23
   

2. gcloud compute networks subnets create 명령어를 사용하여 asia-east1 리전에 프록시 전용 서브넷을 만듭니다.

   gcloud compute networks subnets create proxy-only-subnet-asia \
       --purpose=GLOBAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=asia-east1 \
       --network=lb-network \
       --range=10.130.0.0/23
   

방화벽 규칙 구성

이 예시에서는 다음과 같은 방화벽 규칙을 사용합니다.

• 클라이언트 VM에 대한 포트 22의 SSH 액세스를 허용하는 인그레스 규칙입니다. 이 예시에서 이 방화벽 규칙의 이름은 fw-allow-ssh입니다.

콘솔

1. Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.

   방화벽 정책으로 이동

2. 방화벽 규칙 만들기를 클릭하여 클라이언트 VM에서 수신 SSH 연결을 허용하는 규칙을 만듭니다.

   • 이름: fw-allow-ssh
   • 네트워크: lb-network
   • 트래픽 방향: 인그레스
   • 일치 시 작업: 허용
   • 대상: 지정된 대상 태그
   • 대상 태그: allow-ssh
   • 소스 필터: IPv4 범위
   • 소스 IPv4 범위: 0.0.0.0/0
   • 프로토콜 및 포트:
     • 지정된 프로토콜 및 포트를 선택합니다.
     • TCP 체크박스를 선택한 후 포트 번호에 22을 입력합니다.

3. 만들기를 클릭합니다.

gcloud

1. allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-ssh 방화벽 규칙을 만듭니다. --source-ranges를 생략하면Google Cloud 가 모든 소스를 의미하는 것으로 규칙을 해석합니다.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

Cloud Storage 버킷 구성

Cloud Storage 버킷을 구성하는 프로세스는 다음과 같습니다.

• 버킷을 만듭니다.
• 버킷에 콘텐츠를 복사합니다.

Cloud Storage 버킷 만들기

이 예에서는 us-east1 리전에 하나, asia-east1 리전에 하나씩 Cloud Storage 버킷 두 개를 만듭니다. 프로덕션 배포의 경우 여러 리전에 객체를 자동으로 복제하는 멀티 리전 버킷을 선택하는 것이 좋습니다. Google Cloud 이렇게 하면 콘텐츠의 가용성이 향상되고 애플리케이션 전체의 내결함성이 개선됩니다.

콘솔

1. Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
   

   버킷으로 이동

2. 만들기를 클릭합니다.

3. 버킷 이름 지정 상자에 이름 지정 가이드라인에 따라 전역적으로 고유한 이름을 입력합니다.

4. 데이터 저장 위치 선택을 클릭합니다.

5. 위치 유형을 리전으로 설정합니다.

6. 리전 목록에서 us-east1을 선택합니다.

7. 만들기를 클릭합니다.

8. 버킷을 클릭하여 Cloud Storage 버킷 페이지로 돌아갑니다. 다음 안내를 따라 두 번째 버킷을 만들되, 위치를 asia-east1로 설정합니다.

gcloud

1. gcloud storage buckets create 명령어를 사용하여 us-east1 리전에 첫 번째 버킷을 만듭니다.

   gcloud storage buckets create gs://BUCKET1_NAME \
       --default-storage-class=standard \
       --location=us-east1 \
       --uniform-bucket-level-access
   

2. gcloud storage buckets create 명령어를 사용하여 asia-east1 리전에 두 번째 버킷을 만듭니다.

   gcloud storage buckets create gs://BUCKET2_NAME \
       --default-storage-class=standard \
       --location=asia-east1 \
       --uniform-bucket-level-access
   

BUCKET1_NAME 및 BUCKET2_NAME 변수를 Cloud Storage 버킷 이름으로 바꿉니다.

Cloud Storage 버킷에 그래픽 파일 복사

설정을 테스트하려면 공개 Cloud Storage 버킷의 그래픽 파일을 자체 Cloud Storage 버킷으로 복사합니다.

Cloud Shell에서 다음 명령어를 실행하여 버킷 이름 변수를 고유한 Cloud Storage 버킷 이름으로 바꿉니다.

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/never-fetch/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

Cloud Storage 버킷을 공개적으로 읽을 수 있도록 설정

공개 인터넷의 모든 사용자가 버킷의 모든 객체를 읽을 수 있도록 하려면 주 구성원 allUsers에게 스토리지 객체 뷰어 역할(roles/storage.objectViewer)을 부여합니다.

콘솔

모든 사용자에게 버킷의 객체를 볼 수 있는 액세스 권한을 부여하려면 버킷마다 다음 절차를 반복합니다.

1. Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
   

   버킷으로 이동

2. 버킷 목록에서 공개하려는 버킷의 이름을 클릭합니다.

3. 페이지 상단의 권한 탭을 선택합니다.

4. 권한 섹션에서 액세스 권한 부여 버튼을 클릭합니다. 액세스 권한 부여 대화상자가 표시됩니다.

5. 새 주 구성원 필드에 allUsers를 입력합니다.

6. 역할 선택 필드에서 필터 상자에 Storage Object Viewer를 입력하고 필터링된 결과에서 스토리지 객체 뷰어를 선택합니다.

7. 저장을 클릭합니다.

8. 공개 액세스 허용을 클릭합니다.

gcloud

모든 사용자에게 버킷의 객체를 볼 수 있는 액세스 권한을 부여하려면 buckets add-iam-policy-binding 명령어를 실행합니다.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer

버킷 이름 변수를 고유한 Cloud Storage 버킷 이름으로 바꿉니다.

백엔드 버킷으로 부하 분산기 구성

이 섹션에서는 리전 간 내부 애플리케이션 부하 분산기에 다음 리소스를 만드는 방법을 보여줍니다.

• 백엔드 버킷 2개 백엔드 버킷은 앞서 만든 Cloud Storage 버킷의 래퍼 역할을 합니다.
• URL 맵
• 대상 프록시
• 리전 IP 주소가 있는 전역 전달 규칙 2개. 전달 규칙에는 부하 분산기의 전달 규칙을 위해 생성된 서브넷의 IP 주소가 할당됩니다. 프록시 전용 서브넷의 전달 규칙에 IP 주소를 할당하려고 하면 전달 규칙 생성에 실패합니다.

이 예시에서는 클라이언트와 부하 분산기 간의 요청 및 응답 프로토콜로 HTTP 또는 HTTPS를 사용할 수 있습니다. HTTPS 부하 분산기를 만들려면 SSL 인증서 리소스를 부하 분산기의 프런트엔드에 추가해야 합니다.

참고: 미리보기의 경우 gcloud CLI만 사용하여 백엔드 버킷이 있는 리전 간 내부 애플리케이션 부하 분산기를 구성할 수 있습니다.

gcloud CLI를 사용하여 앞서 언급한 부하 분산 구성요소를 만들려면 다음 단계를 따르세요.

1. gcloud beta compute backend-buckets create 명령어를 사용하여 us-east1 리전에 하나, asia-east1 리전에 하나씩 백엔드 버킷 두 개를 만듭니다. 백엔드 버킷의 부하 분산 스키마는 INTERNAL_MANAGED입니다.

   gcloud beta compute backend-buckets create backend-bucket-cats \
       --gcs-bucket-name=BUCKET1_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   gcloud beta compute backend-buckets create backend-bucket-dogs \
       --gcs-bucket-name=BUCKET2_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   참고: 리전 간 내부 애플리케이션 부하 분산기의 백엔드 버킷을 만들 때는 Cloud CDN을 사용 설정할 수 없습니다. 즉, --load-balancing-scheme=INTERNAL_MANAGED인 경우 Cloud CDN 통합을 사용할 수 없습니다.

2. gcloud compute url-maps create 명령어를 사용하여 수신되는 요청을 백엔드 버킷으로 라우팅하는 URL 맵을 만듭니다.

   gcloud compute url-maps create lb-map \
       --default-backend-bucket=backend-bucket-cats \
       --global
   

3. gcloud compute url-maps add-path-matcher 명령어를 사용하여 URL 맵의 호스트 및 경로 규칙을 구성합니다.

   이 예에서 기본 백엔드 버킷은 backend-bucket-cats이며, 이 버킷은 버킷 내에 있는 모든 경로를 처리합니다. 그러나 http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg를 타겟팅하는 모든 요청은 backend-bucket-dogs 백엔드를 사용합니다. 예를 들어 /love-to-fetch/ 폴더가 기본 백엔드(backend-bucket-cats) 내에 있는 경우에도 부하 분산기는 /love-to-fetch/*에 관한 특정 경로 규칙이 있으므로 backend-bucket-dogs 백엔드에 우선순위를 둡니다.

   gcloud compute url-maps add-path-matcher lb-map \
       --path-matcher-name=path-matcher-pets \
       --new-hosts=* \
       --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
       --default-backend-bucket=backend-bucket-cats
   

4. gcloud compute target-http-proxies create 명령어를 사용하여 대상 프록시를 만듭니다.

   HTTP 트래픽의 경우 대상 HTTP 프록시를 만들어 요청을 URL 맵으로 라우팅합니다.

   gcloud compute target-http-proxies create http-proxy \
       --url-map=lb-map \
       --global
   

   HTTPS 트래픽의 경우 대상 HTTPS 프록시를 만들어 요청을 URL 맵으로 라우팅합니다. 프록시는 HTTPS 부하 분산기의 SSL 인증서를 보유하는 부하 분산기의 일부입니다. 인증서를 만든 후 인증서를 HTTPS 대상 프록시에 연결할 수 있습니다.

   gcloud compute target-https-proxies create https-proxy \
       --url-map=lb-map \
       --certificate-manager-certificates=CERTIFICATE_NAME \
       --global
   

   CERTIFICATE_NAME을 Certificate Manager를 사용하여 만든 SSL 인증서의 이름으로 바꿉니다.

5. gcloud compute forwarding-rules create 명령어를 사용하여 us-east1 리전의 IP 주소가 있는 전역 전달 규칙과 asia-east1 리전의 IP 주소가 있는 전역 전달 규칙을 각각 하나씩 만듭니다.

   부하 분산기의 전달 규칙에 고정 내부 IP 주소를 예약하려면 새 고정 내부 IPv4 또는 IPv6 주소 예약을 참고하세요. HTTP 전달 규칙의 경우 IP 주소를 예약하는 것이 선택사항이지만 HTTPS 전달 규칙의 경우 IP 주소를 예약해야 합니다.

   이 예시에서 임시 IP 주소는 부하 분산기의 HTTP 전달 규칙과 연결됩니다. 전달 규칙이 존재하는 동안 임시 IP 주소는 일정하게 유지됩니다. 전달 규칙을 삭제하고 다시 만들어야 하는 경우 전달 규칙에 새 IP 주소가 수신될 수 있습니다.

   HTTP 트래픽의 경우 전역 전달 규칙을 만들어 수신 요청을 HTTP 대상 프록시로 라우팅합니다.

   gcloud compute forwarding-rules create http-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --global-target-http-proxy \
       --global
   

   gcloud compute forwarding-rules create http-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --global-target-http-proxy \
       --global
   

   HTTPS 트래픽의 경우 전역 전달 규칙을 만들어 수신 요청을 HTTPS 대상 프록시로 라우팅합니다.

   gcloud compute forwarding-rules create https-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --global-target-https-proxy \
       --global
   

   gcloud compute forwarding-rules create https-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --global-target-https-proxy \
       --global
   

부하 분산기에 HTTP 요청 전송

내부 클라이언트 VM에서 부하 분산기의 전달 규칙으로 요청을 전송합니다.

부하 분산기의 전달 규칙에 해당하는 IP 주소 가져오기

1. us-east1 리전에 있는 부하 분산기의 전달 규칙 (http-fw-rule-1)의 IP 주소를 가져옵니다.

   gcloud compute forwarding-rules describe http-fw-rule-1 \
       --global
   

2. asia-east1 리전에 있는 부하 분산기의 전달 규칙 (http-fw-rule-2)의 IP 주소를 가져옵니다.

   gcloud compute forwarding-rules describe http-fw-rule-2 \
       --global
   

클라이언트 VM을 만들어 연결 테스트

1. us-east1 리전에 클라이언트 VM을 만듭니다.

   gcloud compute instances create client-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=lb-network \
       --subnet=subnet-us \
       --zone=us-east1-c \
       --tags=allow-ssh
   

2. 클라이언트 VM에 대한 SSH 연결을 설정합니다.

   gcloud compute ssh client-a --zone=us-east1-c
   

3. 이 예시에서 리전 간 내부 애플리케이션 부하 분산기에는 VPC 네트워크의 us-east1 및 asia-east1 리전 모두에 프런트엔드 가상 IP 주소 (VIP)가 있습니다. curl을 사용하여 두 지역의 VIP에 HTTP 요청을 보냅니다.

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
   

   curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
   

고가용성 테스트

1. us-east1 리전에서 전달 규칙 (http-fw-rule-1)을 삭제하여 지역 중단을 시뮬레이션하고 us-east 리전의 클라이언트가 여전히 백엔드 버킷의 데이터에 액세스할 수 있는지 확인합니다.

   gcloud compute forwarding-rules delete http-fw-rule-1 \
       --global
   

2. curl을 사용하여 두 리전 중 하나의 전달 규칙 VIP에 HTTP 요청을 보냅니다.

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
   

   curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
   

   us-east1 리전의 VIP에 HTTP 요청을 보낸 경우 DNS 라우팅 정책은 이 VIP가 응답하지 않는 것을 감지하고 그 다음으로 적합한 VIP (이 예에서는 asia-east1)를 클라이언트에 반환하여 리전 중단 시에도 애플리케이션을 계속 가동합니다.

다음 단계

• 내부 애플리케이션 부하 분산기 개요
• Envoy 기반 부하 분산기용 프록시 전용 서브넷
• 인증서 관리하기
• 부하 분산 설정 삭제