이 문서에서는 Cloud Storage 버킷이 있는 공유 VPC 환경에서regional internal Application Load Balancer 을 설정하는 두 가지 샘플 구성을 보여줍니다.
- 첫 번째 예시에서는 단일 서비스 프로젝트에 모든 부하 분산기 구성요소와 백엔드를 만듭니다.
- 두 번째 예시에서는 부하 분산기의 프런트엔드 구성요소 및 URL 맵은 단일 서비스 프로젝트에 만들지만 부하 분산기의 백엔드 버킷 및 Cloud Storage 버킷을 다른 서비스 프로젝트에서 만듭니다.
두 예시 모두 부하 분산기를 만들기 전에 동일한 초기 구성을 통해 필요한 역할을 부여하고 공유 VPC를 설정해야 합니다.
다른 유효한 공유 VPC 아키텍처에 대한 자세한 내용은 공유 VPC 아키텍처를 참고하세요.
공유 VPC 네트워크를 사용하지 않으려면 Cloud Storage 버킷으로 regional internal Application Load Balancer 설정을 참고하세요.
시작하기 전에
설정이 다음 기본 요건을 충족하는지 확인합니다.
Google Cloud 프로젝트 만들기
호스트 프로젝트 하나와 서비스 프로젝트 두 개에 Google Cloud 프로젝트를 만듭니다.
필요한 역할
Cloud Storage 버킷이 있는 공유 VPC 환경에서 regional internal Application Load Balancer 를 설정하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.
-
공유 VPC 설정, 호스트 프로젝트 사용 설정, 서비스 프로젝트 관리자에게 액세스 권한 부여:
호스트 프로젝트에 대한 Compute 공유 VPC 관리자 (
roles/compute.xpnAdmin) -
방화벽 규칙 추가 및 삭제:
호스트 프로젝트의 Compute 보안 관리자 (
roles/compute.securityAdmin) -
공유 VPC 네트워크를 사용하기 위한 서비스 프로젝트 관리자 액세스 권한:
호스트 프로젝트의 Compute 네트워크 사용자 (
roles/compute.networkUser) -
부하 분산 리소스 만들기: 서비스 프로젝트의 Compute 네트워크 관리자 (
roles/compute.networkAdmin) -
Compute Engine 인스턴스 만들기: 서비스 프로젝트에 대한 Compute 인스턴스 관리자 (
roles/compute.instanceAdmin.v1) -
Compute Engine SSL 인증서 생성 및 수정: 서비스 프로젝트의 Compute 보안 관리자 (
roles/compute.securityAdmin) -
인증서 관리자 SSL 인증서를 만들고 수정합니다.
서비스 프로젝트의 인증서 관리자 소유자 (
roles/certificatemanager.owner) -
다른 서비스 프로젝트에서 부하 분산기 참조 백엔드 버킷을 사용 설정합니다.
서비스 프로젝트에서 Compute 부하 분산기 서비스 사용자 (
roles/compute.loadBalancerServiceUser)
역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
공유 VPC 환경 설정
공유 VPC 환경을 설정하려면 호스트 프로젝트에서 다음 단계를 완료하세요.
- 호스트 프로젝트에서 VPC 네트워크를 구성합니다.
- 호스트 프로젝트에서 프록시 전용 서브넷을 구성합니다.
- 호스트 프로젝트에서 방화벽 규칙을 구성합니다.
- 호스트 프로젝트에서 공유 VPC를 설정합니다.
새 부하 분산기를 만들 때마다 이 섹션의 단계를 수행할 필요는 없습니다. 하지만 부하 분산기를 만들기 전에 여기에 설명된 리소스에 액세스할 수 있는지 확인해야 합니다.
이 예시에서는 다음 VPC 네트워크, 리전, 프록시 전용 서브넷을 사용합니다.
네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은
lb-network입니다.부하 분산기의 서브넷
us-east1리전에 있는subnet-us이라는 이름의 서브넷은 기본 IP 범위로10.1.2.0/24를 사용합니다.Envoy 프록시의 서브넷.
us-east1리전에 있는proxy-only-subnet-us이라는 이름의 서브넷은 기본 IP 범위로10.129.0.0/23를 사용합니다.
호스트 프로젝트의 VPC 구성
호스트 프로젝트에 커스텀 모드 VPC를 구성하고 부하 분산기의 전달 규칙을 구성해야 하는 동일한 리전에 서브넷을 만듭니다.
새 부하 분산기를 만들 때마다 이 단계를 수행할 필요는 없습니다. 서비스 프로젝트에 프록시 전용 서브넷 외에 공유 VPC 네트워크의 서브넷에 대한 액세스 권한만 있으면 됩니다.
콘솔
Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.
VPC 네트워크 만들기를 클릭합니다.
이름 필드에
lb-network를 입력합니다.서브넷 생성 모드에 커스텀을 선택합니다.
새 서브넷 섹션에 다음 정보를 입력합니다.
- 이름 필드에
subnet-us를 입력합니다. - 리전 목록에서
us-east1을 선택합니다. - IPv4 범위 필드에
10.1.2.0/24를 입력합니다. - 완료를 클릭합니다.
- 이름 필드에
만들기를 클릭합니다.
gcloud
gcloud compute networks create명령어를 사용하여lb-network라는 커스텀 VPC 네트워크를 만듭니다.gcloud compute networks create lb-network \ --subnet-mode=custom \ --project=HOST_PROJECT_IDHOST_PROJECT_ID를 공유 VPC 환경에서 호스트 프로젝트로 사용 설정된 프로젝트에 할당된Google Cloud 프로젝트 ID로 바꿉니다.gcloud compute networks subnets create명령어를 사용하여us-east1리전의lb-networkVPC 네트워크에 서브넷을 만듭니다.gcloud compute networks subnets create subnet-us \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-east1 \ --project=HOST_PROJECT_ID
호스트 프로젝트에서 프록시 전용 서브넷 구성
프록시 전용 서브넷은 Google Cloud 에서 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 프록시는 클라이언트의 연결을 종료하고 백엔드에 새 연결을 만듭니다.
이 프록시 전용 서브넷은 VPC 네트워크와 동일한 리전에 있는 모든 Envoy 기반 리전 부하 분산기에서 사용됩니다. 네트워크당 리전별 활성 프록시 전용 서브넷은 용도별로 하나만 있을 수 있습니다.
이 예시에서는 us-east1 리전에 프록시 전용 서브넷을 만듭니다.
콘솔
Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.
만든 VPC 네트워크의 이름을 클릭합니다.
서브넷 탭에서 서브넷 추가를 클릭하고 다음 정보를 입력합니다.
- 이름 필드에
proxy-only-subnet-us를 입력합니다. - 리전 목록에서
us-east1을 선택합니다. - 용도에서 Regional Managed Proxy을 선택합니다.
- IPv4 범위 필드에
10.129.0.0/23를 입력합니다.
- 이름 필드에
추가를 클릭합니다.
gcloud
gcloud compute networks subnets create명령어를 사용하여us-east1리전에 프록시 전용 서브넷을 만듭니다.gcloud compute networks subnets create proxy-only-subnet-us \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-east1 \ --network=lb-network \ --range=10.129.0.0/23 \ --project=HOST_PROJECT_ID
호스트 프로젝트에서 방화벽 규칙 구성
이 예에서는 TCP 포트 22에서 임의의 주소로부터 수신되는 SSH 연결을 허용하는 fw-allow-ssh 인그레스 방화벽 규칙을 사용합니다. 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작할 시스템의 IP 범위만 지정할 수 있습니다. 이 예시에서는 allow-ssh 대상 태그를 사용하여 방화벽 규칙이 적용되는 가상 머신 (VM)을 식별합니다. 이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다.
콘솔
Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
방화벽 규칙 만들기를 클릭하여Google Cloud 상태 점검을 허용하는 규칙을 만듭니다.
다음 정보를 제공합니다.
- 이름 필드에
fw-allow-ssh를 입력합니다. - 네트워크 목록에서 lb-network를 선택합니다.
- 트래픽 방향으로 수신을 선택합니다.
- 일치 시 작업으로 허용을 선택합니다.
- 대상 목록에서 지정된 대상 태그를 선택합니다.
- 대상 태그 필드에
allow-ssh를 입력합니다. - 소스 필터 목록에서 IPv4 범위를 선택합니다.
- 소스 IPv4 범위 필드에
0.0.0.0/0를 입력합니다. - 프로토콜 및 포트로 지정된 프로토콜 및 포트를 선택합니다.
- TCP 체크박스를 선택하고 포트 번호로
22을 입력합니다.
- 이름 필드에
만들기를 클릭합니다.
gcloud
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 \ --project=HOST_PROJECT_ID
호스트 프로젝트에서 공유 VPC 설정
서비스 프로젝트가 공유 VPC 네트워크를 사용할 수 있도록 공유 VPC 호스트 프로젝트를 사용 설정하고 호스트 프로젝트에 서비스 프로젝트를 연결합니다. 호스트 프로젝트에서 공유 VPC를 설정하려면 다음 페이지를 참고하세요.
이전 단계를 완료한 후 다음 설정 중 하나를 완료합니다.
서비스 프로젝트에서 부하 분산기 구성
이 예시에서는 모든 부하 분산 구성요소 (전달 규칙, 대상 프록시, URL 맵, 백엔드 버킷)와 Cloud Storage 버킷이 서비스 프로젝트에 생성되는 regional internal Application Load Balancer 를 만듭니다.
regional internal Application Load Balancer의 네트워킹 리소스(예: 프록시 전용 서브넷)가 호스트 프로젝트에 생성됩니다.
이 섹션에서는 부하 분산기와 백엔드를 설정하는 방법을 보여줍니다.
이 페이지의 예시에서는 임시 IP 주소 할당을 허용하는 대신 regional internal Application Load Balancer의 전달 규칙에 예약된 IP 주소를 명시적으로 설정합니다. 권장사항에 따라 전달 규칙에 IP 주소를 예약하는 것이 좋습니다.
Cloud Storage 버킷 구성
Cloud Storage 버킷을 구성하는 프로세스는 다음과 같습니다.
- Cloud Storage 버킷을 만듭니다.
- 버킷에 콘텐츠를 복사합니다.
- 버킷을 공개적으로 읽을 수 있도록 설정합니다.
Cloud Storage 버킷 만들기
이 예시에서는 us-east1 리전에 Cloud Storage 버킷 두 개를 만듭니다.
콘솔
- Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
만들기를 클릭합니다.
시작하기 섹션에서 이름 지정 가이드라인에 따라 전역적으로 고유한 이름을 입력합니다.
데이터 저장 위치 선택을 클릭합니다.
위치 유형을 리전으로 설정합니다.
리전 목록에서 us-east1을 선택합니다.
만들기를 클릭합니다.
버킷을 클릭하여 Cloud Storage 버킷 페이지로 돌아갑니다. 위의 안내를 사용하여 us-east1 리전에 두 번째 버킷을 만듭니다.
gcloud
gcloud storage buckets create명령어를 사용하여us-east1리전에 버킷을 만듭니다.gcloud storage buckets create gs://BUCKET1_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access \ --project=SERVICE_PROJECT_ID
gcloud storage buckets create gs://BUCKET2_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access \ --project=SERVICE_PROJECT_ID다음을 바꿉니다.
BUCKET1_NAME: 첫 번째 Cloud Storage 버킷의 이름BUCKET2_NAME: 두 번째 Cloud Storage 버킷의 이름SERVICE_PROJECT_ID: 서비스 프로젝트에 할당된 Google Cloud 프로젝트 ID
Cloud Storage 버킷에 콘텐츠 복사
Cloud Storage 버킷을 채우려면 공개 Cloud Storage 버킷의 그래픽 파일을 자체 Cloud Storage 버킷으로 복사합니다.
gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/
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)을 부여합니다.
콘솔
모든 사용자에게 버킷의 객체를 볼 수 있는 액세스 권한을 부여하려면 버킷마다 다음 절차를 반복합니다.
- Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
버킷 목록에서 공개하려는 각 버킷의 체크박스를 선택합니다.
권한 버튼을 클릭합니다. 권한 대화상자가 표시됩니다.
권한 대화상자에서 주 구성원 추가 버튼을 클릭합니다. 액세스 권한 부여 대화상자가 나타납니다.
새 주 구성원 필드에
allUsers를 입력합니다.역할 선택 필드에서 필터 상자에
Storage Object Viewer를 입력하고 필터링된 결과에서 스토리지 객체 뷰어를 선택합니다.저장을 클릭합니다.
공개 액세스 허용을 클릭합니다.
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
고정 내부 IP 주소 예약
부하 분산기의 전달 규칙에 사용할 고정 내부 IP 주소를 예약합니다. 자세한 내용은 고정 내부 IP 주소 예약을 참고하세요.
콘솔
Google Cloud 콘솔에서 내부 고정 IP 주소 예약 페이지로 이동합니다.
이름 필드에 새 주소의 이름을 입력합니다.
IP 버전 목록에서 IPv4를 선택합니다.
네트워크 목록에서 lb-network를 선택합니다.
서브네트워크 목록에서 subnet-us를 선택합니다.
리전으로 us-east1을 선택합니다.
고정 IP 주소 목록에서 자동 할당을 선택합니다. 부하 분산기를 만들면 이 IP 주소가 부하 분산기의 전달 규칙에 연결됩니다.
예약을 클릭하여 IP 주소를 예약합니다.
gcloud
gcloud compute를 사용하여 고정 내부 IP 주소를 예약하려면compute addresses create명령어를 사용합니다.gcloud compute addresses create ADDRESS_NAME \ --region=REGION \ --subnet=subnet-us \ --project=SERVICE_PROJECT_ID다음을 바꿉니다.
ADDRESS_NAME: 이 주소의 이름입니다.REGION: 이 주소를 예약할 리전으로 바꿉니다. 이 리전은 부하 분산기와 동일한 리전이어야 합니다. 예를 들면us-east1입니다.SERVICE_PROJECT_ID: 서비스 프로젝트에 할당된 Google Cloud프로젝트 ID입니다.
결과를 보려면
compute addresses describe명령어를 사용하세요.gcloud compute addresses describe ADDRESS_NAME
반환된 IP 주소를 복사하여 다음 섹션에서
RESERVED_IP_ADDRESS로 사용합니다.
SSL 인증서 리소스 설정
HTTPS를 요청 및 응답 프로토콜로 사용하는 regional internal Application Load Balancer 의 경우 Compute Engine SSL 인증서 또는 인증서 관리자 인증서를 사용하여 SSL 인증서 리소스를 만들 수 있습니다.
이 예시에서는 다음 문서 중 하나에 설명된 대로 인증서 관리자를 사용하여 SSL 인증서 리소스를 만듭니다.
인증서를 만든 후 인증서를 HTTPS 대상 프록시에 연결할 수 있습니다.
Google 관리형 인증서를 사용하여 수동 인증서 관리와 관련된 보안 위험과 같은 운영 오버헤드를 줄이는 것이 좋습니다.
백엔드 버킷으로 부하 분산기 구성
이 섹션에서는regional internal Application Load Balancer에 대해 다음 리소스를 만드는 방법을 보여줍니다.
- 백엔드 버킷 2개. 백엔드 버킷은 앞에서 만든 Cloud Storage 버킷에 대한 래퍼로 작동합니다.
- URL 맵
- 대상 프록시
- 리전 IP 주소가 있는 전달 규칙 전달 규칙에는 부하 분산기의 전달 규칙에 대해 생성된 서브넷의 IP 주소가 할당됩니다. 프록시 전용 서브넷에서 전달 규칙에 IP 주소를 할당하려고 시도하면 전달 규칙 만들기가 실패합니다.
이 예시에서는 클라이언트와 부하 분산기 간의 요청 및 응답 프로토콜로 HTTP 또는 HTTPS를 사용할 수 있습니다. HTTPS 부하 분산기를 만들려면 부하 분산기의 프런트엔드에 SSL 인증서 리소스를 추가해야 합니다.
gcloud CLI를 사용하여 앞에서 언급한 부하 분산 구성요소를 만들려면 다음 단계를 따르세요.
gcloud beta compute backend-buckets create명령어를 사용하여us-east1리전에 백엔드 버킷 두 개를 만듭니다. 백엔드 버킷에는INTERNAL_MANAGED의 부하 분산 스키마가 포함됩니다.gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 \ --project=SERVICE_PROJECT_IDgcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 --project=SERVICE_PROJECT_IDgcloud beta compute url-maps create명령어를 사용해서 들어오는 요청을 백엔드 버킷으로 라우팅하는 URL 맵을 만듭니다.gcloud beta compute url-maps create URL_MAP_NAME \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_IDURL_MAP_NAME을 URL 맵의 이름으로 바꿉니다.gcloud beta 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 beta compute url-maps add-path-matcher URL_MAP_NAME \ --path-matcher-name=path-matcher-pets \ --new-hosts=* \ --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_IDgcloud compute target-http-proxies create명령어를 사용하여 대상 프록시를 만듭니다.HTTP
HTTP 트래픽의 경우 대상 HTTP 프록시를 만들어 요청을 URL 맵으로 라우팅합니다.
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_IDTARGET_HTTP_PROXY_NAME을 대상 HTTP 프록시의 이름으로 바꿉니다.HTTPS
HTTPS 트래픽의 경우 대상 HTTPS 프록시를 만들어 요청을 URL 맵으로 라우팅합니다. 프록시는 HTTPS 부하 분산기에 대해 SSL 인증서를 포함하는 부하 분산기의 일부입니다. 인증서를 만든 후 인증서를 HTTPS 대상 프록시에 연결할 수 있습니다.
인증서 관리자 인증서를 연결하려면 다음 명령어를 실행합니다.
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --url-map=URL_MAP_NAME \ --certificate-manager-certificates=CERTIFICATE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_ID다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시의 이름입니다.CERTIFICATE_NAME: 인증서 관리자를 사용하여 만든 SSL 인증서의 이름
gcloud compute forwarding-rules create명령어를 사용하여us-east1리전의 IP 주소로 전달 규칙을 만듭니다.IP 주소 예약은 HTTP 전달 규칙의 경우 선택사항이지만 HTTPS 전달 규칙의 경우에는 IP 주소 예약이 필수입니다.
이 예시에서는 임시 IP 주소가 부하 분산기의 HTTP 전달 규칙에 연결되어 있습니다. 전달 규칙이 존재하는 동안 임시 IP 주소는 일정하게 유지됩니다. 전달 규칙을 삭제하고 다시 만들어야 하는 경우 전달 규칙에 새 IP 주소가 수신될 수 있습니다.
HTTP
HTTP 트래픽의 경우 리전 전달 규칙을 만들어 수신 요청을 HTTP 대상 프록시로 라우팅합니다.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS --ports=80 \ --region=us-east1 \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --target-http-proxy-region=us-east1 \ --project=SERVICE_PROJECT_ID다음을 바꿉니다.
FORWARDING_RULE_NAME: 전달 규칙의 이름입니다.RESERVED_IP_ADDRESS: 고정 내부 IP 주소 예약 섹션에서 복사한 예약된 IP 주소
HTTPS
HTTPS 트래픽의 경우 리전 전달 규칙을 만들어 수신 요청을 HTTPS 대상 프록시로 라우팅합니다.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --region=us-east1 \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --target-https-proxy-region=us-east1 \ --project=SERVICE_PROJECT_ID다음을 바꿉니다.
FORWARDING_RULE_NAME: 전달 규칙의 이름입니다.RESERVED_IP_ADDRESS: 고정 내부 IP 주소 예약 섹션에서 복사한 예약된 IP 주소
부하 분산기로 HTTP 요청 전송
이제 부하 분산 서비스가 실행 중이므로 내부 클라이언트 VM에서 부하 분산기의 전달 규칙으로 요청을 전송합니다.
us-east1리전에 있는 부하 분산기의 전달 규칙에 해당하는 IP 주소를 가져옵니다.gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_ID반환된 IP 주소를 복사하여
FORWARDING_RULE_IP_ADDRESS로 사용합니다.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클라이언트 VM에 대한 SSH 연결을 설정합니다.
gcloud compute ssh client-a --zone=us-east1-c
이 예시에서 regional internal Application Load Balancer 에는 VPC 네트워크의
us-east1리전에 프런트엔드 가상 IP 주소 (VIP)가 있습니다. curl을 사용하여 해당 리전의 VIP로 HTTP 요청을 수행합니다.curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
FORWARDING_RULE_IP_ADDRESS를 첫 번째 단계에서 복사한 IP 주소로 바꿉니다.
프로젝트 간 구성으로 부하 분산기 구성
이 페이지의 이전 예시에서는 모든 부하 분산기 구성 요소와 백엔드가 서비스 프로젝트에 생성되는 공유 VPC 배포를 설정하는 방법을 보여줍니다.
리전 내부 애플리케이션 부하 분산기를 사용하면 단일 호스트 또는 서비스 프로젝트의 URL 맵에서 공유 VPC 환경의 여러 서비스 프로젝트에 위치한 백엔드 버킷을 참조할 수 있는 공유 VPC 배포도 구성할 수 있습니다.
이 섹션의 단계를 참조하면 여기에 나온 지원되는 조합을 구성할 수 있습니다.
- 호스트 프로젝트의 전달 규칙, 대상 프록시, URL 맵, 단일 서비스 프로젝트의 백엔드 버킷
- 서비스 프로젝트의 전달 규칙, 대상 프록시, URL 맵, 다른 서비스 프로젝트의 백엔드 버킷
이 섹션에서는 후자 구성이 예시로 설명되어 있습니다.
설정 개요
이 예시에서는 프런트엔드 및 백엔드가 서로 다른 두 서비스 프로젝트에 있는 부하 분산기를 구성합니다.
아직 수행하지 않았으면 공유 VPC를 설정하고 이 예시에 필요한 네트워크, 서브넷, 방화벽 규칙을 구성하는 모든 기본 요건 단계를 완료해야 합니다. 자세한 내용은 이 페이지에서 다음 섹션을 참고하세요.
서비스 프로젝트 B에서 Cloud Storage 버킷 및 백엔드 버킷 구성
이 섹션의 모든 단계는 서비스 프로젝트 B에서 수행되어야 합니다.
백엔드 버킷을 만들려면 다음을 수행해야 합니다.
- Cloud Storage 버킷을 만듭니다.
- 버킷에 콘텐츠를 복사합니다.
- 버킷을 공개적으로 읽을 수 있도록 설정합니다.
- 백엔드 버킷을 만들고 Cloud Storage 버킷을 가리키도록 합니다.
Cloud Storage 버킷 만들기
이 예시에서는 us-east1 리전에 Cloud Storage 버킷을 만듭니다.
콘솔
- Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
만들기를 클릭합니다.
시작하기 섹션에서 이름 지정 가이드라인에 따라 전역적으로 고유한 이름을 입력합니다.
데이터 저장 위치 선택을 클릭합니다.
위치 유형을 리전으로 설정합니다.
리전 목록에서 us-east1을 선택합니다.
만들기를 클릭합니다.
버킷을 클릭하여 Cloud Storage 버킷 페이지로 돌아갑니다. 위의 안내를 사용하여 us-east1 리전에 두 번째 버킷을 만듭니다.
gcloud
gcloud storage buckets create 명령어를 사용하여 us-east1 리전에 버킷을 만듭니다.
gcloud storage buckets create gs://BUCKET1_NAME \
--default-storage-class=standard \
--location=us-east1 \
--uniform-bucket-level-access \
--project=SERVICE_PROJECT_B_ID
gcloud storage buckets create gs://BUCKET2_NAME \
--default-storage-class=standard \
--location=us-east1 \
--uniform-bucket-level-access \
--project=SERVICE_PROJECT_B_ID
다음을 바꿉니다.
BUCKET1_NAME: 첫 번째 Cloud Storage 버킷의 이름BUCKET2_NAME: 두 번째 Cloud Storage 버킷의 이름SERVICE_PROJECT_B_ID: 서비스 프로젝트 B에 할당된 Google Cloud 프로젝트 ID
Cloud Storage 버킷에 그래픽 파일 복사
설정을 테스트하려면 공개 Cloud Storage 버킷의 그래픽 파일을 자체 Cloud Storage 버킷으로 복사합니다.
gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/
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)을 부여합니다.
콘솔
모든 사용자에게 버킷의 객체를 볼 수 있는 액세스 권한을 부여하려면 버킷마다 다음 절차를 반복합니다.
- Google Cloud 콘솔에서 Cloud Storage 버킷 페이지로 이동합니다.
버킷 목록에서 공개하려는 각 버킷의 체크박스를 선택합니다.
권한 버튼을 클릭합니다. 권한 대화상자가 표시됩니다.
권한 대화상자에서 주 구성원 추가 버튼을 클릭합니다. 액세스 권한 부여 대화상자가 나타납니다.
새 주 구성원 필드에
allUsers를 입력합니다.역할 선택 필드에서 필터 상자에
Storage Object Viewer를 입력하고 필터링된 결과에서 스토리지 객체 뷰어를 선택합니다.저장을 클릭합니다.
공개 액세스 허용을 클릭합니다.
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
백엔드 버킷으로 부하 분산기 구성
백엔드 버킷을 만들려면 다음 단계를 따르세요.
gcloud beta compute backend-buckets create명령어를 사용하여us-east1리전에 백엔드 버킷 두 개를 만듭니다. 백엔드 버킷에는INTERNAL_MANAGED의 부하 분산 스키마가 포함됩니다.gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 \ --project=SERVICE_PROJECT_B_IDgcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1 --project=SERVICE_PROJECT_B_ID
서비스 프로젝트 A에서 부하 분산기 프런트엔드 구성요소 구성
이 섹션의 모든 단계는 서비스 프로젝트 A에서 수행되어야 합니다.
서비스 프로젝트 A에서 다음 프런트엔드 부하 분산 구성요소를 만듭니다.
- 대상 프록시에 연결된 SSL 인증서 리소스를 설정합니다. 자세한 내용은 이 문서의 SSL 인증서 리소스 설정을 참고하세요.
- 부하 분산기의 전달 규칙에 사용할 고정 내부 IP 주소를 만들고 예약합니다. 자세한 내용은 이 문서의 고정 내부 IP 주소 예약 을 참고하세요.
gcloud beta compute url-maps create명령어를 사용해서 들어오는 요청을 서비스 프로젝트 B의 백엔드 버킷으로 라우팅하는 URL 맵을 만듭니다.gcloud beta compute url-maps create URL_MAP_NAME \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID다음을 바꿉니다.
URL_MAP_NAME: URL 맵의 이름SERVICE_PROJECT_A_ID: 서비스 프로젝트 A에 할당된 Google Cloud프로젝트 ID
gcloud beta 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 beta compute url-maps add-path-matcher URL_MAP_NAME \ --path-matcher-name=path-matcher-pets \ --new-hosts=* \ --backend-bucket-path-rules="/love-to-fetch/*=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-dogs" \ --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/regional/backendBuckets/backend-bucket-cats \ --region=us-east1 --project=SERVICE_PROJECT_A_IDgcloud compute target-http-proxies create명령어를 사용하여 대상 프록시를 만듭니다.HTTP
HTTP 트래픽의 경우 대상 HTTP 프록시를 만들어 요청을 URL 맵으로 라우팅합니다.
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --url-map=URL_MAP_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_IDTARGET_HTTP_PROXY_NAME을 대상 HTTP 프록시의 이름으로 바꿉니다.HTTPS
HTTPS 트래픽의 경우 대상 HTTPS 프록시를 만들어 요청을 URL 맵으로 라우팅합니다. 프록시는 HTTPS 부하 분산기에 대해 SSL 인증서를 포함하는 부하 분산기의 일부입니다. 인증서를 만든 후 인증서를 HTTPS 대상 프록시에 연결할 수 있습니다.
인증서 관리자 인증서를 연결하려면 다음 명령어를 실행합니다.
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --url-map=lb-map \ --certificate-manager-certificates=CERTIFICATE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID다음을 바꿉니다.
TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시의 이름입니다.CERTIFICATE_NAME: 인증서 관리자를 사용하여 만든 SSL 인증서의 이름입니다.
gcloud compute forwarding-rules create명령어를 사용하여us-east1리전의 IP 주소로 전달 규칙을 만듭니다.IP 주소 예약은 HTTP 전달 규칙의 경우 선택사항이지만 HTTPS 전달 규칙의 경우에는 IP 주소 예약이 필수입니다.
이 예시에서는 임시 IP 주소가 부하 분산기의 HTTP 전달 규칙에 연결되어 있습니다. 전달 규칙이 존재하는 동안 임시 IP 주소는 일정하게 유지됩니다. 전달 규칙을 삭제하고 다시 만들어야 하는 경우 전달 규칙에 새 IP 주소가 수신될 수 있습니다.
HTTP
HTTP 트래픽의 경우 리전 전달 규칙을 만들어 수신 요청을 HTTP 대상 프록시로 라우팅합니다.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --address=RESERVED_IP_ADDRESS --ports=80 \ --region=us-east1 \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --target-http-proxy-region=us-east1 \ --project=SERVICE_PROJECT_A_ID다음을 바꿉니다.
FORWARDING_RULE_NAME: 전달 규칙의 이름입니다.RESERVED_IP_ADDRESS: 예약된 IP 주소
HTTPS
HTTPS 트래픽의 경우 리전 전달 규칙을 만들어 수신 요청을 HTTPS 대상 프록시로 라우팅합니다.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=projects/HOST_PROJECT_ID/global/networks/lb-network \ --subnet=subnet-us \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --region=us-east1 \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --target-https-proxy-region=us-east1 \ --project=SERVICE_PROJECT_A_ID다음을 바꿉니다.
FORWARDING_RULE_NAME: 전달 규칙의 이름입니다.RESERVED_IP_ADDRESS: 예약된 IP 주소
Compute 부하 분산기 관리자에게 백엔드 버킷을 사용할 수 있는 권한 부여
부하 분산기가 다른 서비스 프로젝트의 백엔드 버킷을 참조하게 하려면 부하 분산기 관리자에게 compute.backendBuckets.use 권한이 있어야 합니다. 이 권한을 부여하려면 Compute 부하 분산기 서비스 사용자 (roles/compute.loadBalancerServiceUser)라는 사전 정의된 IAM 역할을 사용하면 됩니다. 이 역할은 서비스 프로젝트 관리자가 부여해야 하며 서비스 프로젝트 수준 또는 개별 백엔드 버킷 수준에서 적용할 수 있습니다.
이 예시에서는 서비스 프로젝트 B의 서비스 프로젝트 관리자가 다음 명령어 중 하나를 실행하여 서비스 프로젝트 A의 부하 분산기 관리자에게 compute.backendBuckets.use 권한을 부여해야 합니다. 프로젝트 수준 (프로젝트의 모든 백엔드 버킷) 또는 백엔드 버킷별로 이 작업을 수행할 수 있습니다.
콘솔
프로젝트 수준 권한
다음 단계에 따라 프로젝트의 모든 백엔드 버킷에 대해 권한을 부여합니다.
이 단계를 완료하려면 compute.regionBackendBuckets.setIamPolicy 및 resourcemanager.projects.setIamPolicy 권한이 필요합니다.
Google Cloud 콘솔에서 IAM 페이지로 이동합니다.
프로젝트를 선택합니다.
액세스 권한 부여를 클릭합니다.
새 주 구성원 필드에 주 구성원의 이메일 주소 또는 다른 식별자를 입력합니다.
역할 할당 섹션에서 역할 추가를 클릭합니다.
역할 선택 대화상자의 역할 검색 필드에
Compute Load Balancer Services User를 입력합니다.Compute 부하 분산기 서비스 사용자 체크박스를 선택합니다.
적용을 클릭합니다.
선택사항: 역할에 조건을 추가합니다.
저장을 클릭합니다.
개별 백엔드 버킷에 대한 리소스 수준 권한
다음 단계에 따라 프로젝트의 개별 백엔드 버킷에 대해 권한을 부여합니다.
이 단계를 완료하려면 compute.regionBackendBuckets.setIamPolicy 권한이 필요합니다.
Google Cloud 콘솔에서 백엔드 페이지로 이동합니다.
백엔드 목록에서 액세스 권한을 부여할 백엔드 버킷을 선택하고 권한을 클릭합니다.
주 구성원 추가를 클릭합니다.
새 주 구성원 필드에 주 구성원의 이메일 주소 또는 다른 식별자를 입력합니다.
역할 선택 목록에서 Compute 부하 분산기 서비스 사용자를 선택합니다.
저장을 클릭합니다.
gcloud
프로젝트 수준 권한
다음 단계에 따라 프로젝트의 모든 백엔드 버킷에 대해 권한을 부여합니다.
이 단계를 완료하려면 compute.regionBackendBuckets.setIamPolicy 및 resourcemanager.projects.setIamPolicy 권한이 필요합니다.
gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser"
다음을 바꿉니다.
SERVICE_PROJECT_B_ID: 서비스 프로젝트 B에 할당된 Google Cloud프로젝트 IDLOAD_BALANCER_ADMIN: 바인딩이 추가되는 주 구성원
개별 백엔드 버킷에 대한 리소스 수준 권한
백엔드 버킷 수준에서 서비스 프로젝트 관리자는 다음 명령어 중 하나를 사용하여 Compute 부하 분산기 서비스 사용자 역할(roles/compute.loadBalancerServiceUser)을 부여할 수 있습니다.
gcloud projects add-iam-policy-binding명령어gcloud compute backend-buckets add-iam-policy-binding명령어
gcloud projects add-iam-policy-binding 명령어를 사용하여 Compute 부하 분산기 서비스 사용자 역할을 부여합니다.
이 단계를 완료하려면 compute.regionBackendBuckets.setIamPolicy 권한이 필요합니다.
gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser" \
--condition='expression=resource.name=="projects/SERVICE_PROJECT_B_ID/regions/REGION/backendBuckets/BACKEND_BUCKET_NAME",title=Shared VPC condition'
SERVICE_PROJECT_B_ID: 서비스 프로젝트 B에 할당된 Google Cloud프로젝트 IDLOAD_BALANCER_ADMIN: 바인딩이 추가되는 주 구성원REGION: 백엔드 버킷이 있는 Google Cloud 리전BACKEND_BUCKET_NAME: 백엔드 버킷의 이름
gcloud compute backend-buckets add-iam-policy-binding 명령어를 사용하여 Compute 부하 분산기 서비스 사용자 역할을 부여합니다.
gcloud compute backend-buckets add-iam-policy-binding BACKEND_BUCKET_NAME \
--member="user:LOAD_BALANCER_ADMIN" \
--role="roles/compute.loadBalancerServiceUser" \
--project=SERVICE_PROJECT_B_ID \
--region=REGION
부하 분산기로 HTTP 요청 전송
이제 부하 분산 서비스가 실행 중이므로 내부 클라이언트 VM에서 부하 분산기의 전달 규칙으로 요청을 전송합니다.
us-east1리전에 있는 부하 분산기의 전달 규칙에 해당하는 IP 주소를 가져옵니다.gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \ --region=us-east1 \ --project=SERVICE_PROJECT_A_ID반환된 IP 주소를 복사하여
FORWARDING_RULE_IP_ADDRESS로 사용합니다.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클라이언트 VM에 대한 SSH 연결을 설정합니다.
gcloud compute ssh client-a --zone=us-east1-c
이 예시에서 regional internal Application Load Balancer 에는 VPC 네트워크의
us-east1리전에 프런트엔드 VIP가 있습니다. curl을 사용하여 해당 리전의 VIP로 HTTP 요청을 수행합니다.curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
FORWARDING_RULE_IP_ADDRESS을 첫 번째 단계에서 복사한 IP 주소로 바꿉니다.