Cloud Run을 사용하여 리전 간 내부 애플리케이션 부하 분산기 설정

이 문서에서는 Cloud Run을 사용하여 리전 간 내부 애플리케이션 부하 분산기를 배포하는 방법을 설명합니다. 이를 설정하려면 부하 분산기에 서버리스 NEG 백엔드를 사용합니다.

서버리스 NEG를 사용하면 부하 분산기에서 Cloud Run 서비스를 사용할 수 있습니다. 서버리스 NEG 백엔드로 부하 분산기를 구성하면 부하 분산기에 대한 요청이 Cloud Run 백엔드로 라우팅됩니다.

리전 간 부하 분산에서는 중복성을 제공하여 리전에 연결할 수 없는 경우 트래픽이 자동으로 다른 리전으로 전환됩니다. Envoy의 위치에 따라 프록시 트래픽이 다음과 같이 Cloud Run 서비스에 분산됩니다.

멀티 리전 Cloud Run 서비스가 Envoy와 동일한 리전에 구성된 경우 Envoy와 동일한 리전에 있는 NEG를 사용하는 것이 좋습니다. 이상점 감지가 사용 설정되고 로컬 NEG가 비정상인 경우에만 트래픽이 장애 조치 리전으로 전송됩니다.
멀티 리전 Cloud Run 서비스가 Envoy와 동일한 리전에 구성되지 않으면 트래픽이 모든 NEG에 고르게 분산됩니다. 가까운 곳에 있는 NEG가 선호되지 않습니다.
IAP(Identity-Aware Proxy)가 사용 설정된 경우 단일 서버리스 NEG만 지원됩니다. 추가 Cloud Run 서비스를 구성할 수 있지만 부하 분산기에서 트래픽을 전송하지 않습니다.

시작하기 전에

이 가이드를 진행하기 전에 다음 사항을 숙지하세요.

Cloud Run 서비스 배포

이 페이지의 안내에서는 이미 Cloud Run 서비스가 실행 중이라고 가정합니다.

이 페이지의 예시에서는 모든 Cloud Run 빠른 시작을 사용하여 Cloud Run 서비스를 배포할 수 있습니다.

인터넷에서 Cloud Run 서비스에 액세스하지 못하게 하려면 인그레스를 internal로 제한합니다. 내부 애플리케이션 부하 분산기에서 전송되는 트래픽은 내부 트래픽으로 간주됩니다.

Cloud Run 서비스를 여러 리전에 배치하면 단일 리전의 장애를 방지하는 데 도움이 됩니다. REGION_A 및 REGION_B 리전에 Cloud Run 서비스를 배포하려면 다음 명령어를 실행합니다.

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

만드는 서비스의 이름을 기록해 둡니다. 이 페이지의 나머지 부분에서는 이 서비스로 요청을 라우팅하는 부하 분산기를 설정하는 방법을 보여줍니다.

SSL 인증서 리소스 설정

다음과 같이 인증서 관리자 SSL 인증서 리소스를 만듭니다.

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

권한

이 가이드를 진행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정할 수 있어야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.

작업	필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기	Compute 네트워크 관리자
방화벽 규칙 추가 및 삭제	Compute 보안 관리자
인스턴스 만들기	Compute 인스턴스 관리자

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

설정 개요

다음 다이어그램에 설명된 대로 리전 간 내부 애플리케이션 부하 분산기를 구성할 수 있습니다.

Cloud Run 배포를 사용하는 리전 간 내부 애플리케이션 부하 분산기(확대하려면 클릭)

다이어그램에서 볼 수 있듯이 이 예시에서는 REGION_A 및 REGION_B 리전에 하나의 백엔드 서비스와 2개의 Cloud Run 배포가 있는 VPC 네트워크에서 리전 간 내부 애플리케이션 부하 분산기를 만듭니다.

리전 간 내부 애플리케이션 부하 분산기 설정은 다음과 같이 설명됩니다.

다음 서브넷을 사용하는 VPC 네트워크:
- 서브넷 SUBNET_A 및 REGION_A의 프록시 전용 서브넷
- 서브넷 SUBNET_B 및 REGION_B의 프록시 전용 서브넷
리전 간 내부 애플리케이션 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 프록시 전용 서브넷을 만들어야 합니다. 해당 리전의 프록시 전용 서브넷은 해당 리전의 모든 리전 간 내부 애플리케이션 부하 분산기 간에 공유됩니다. 부하 분산기에서 서비스의 백엔드로 보낸 패킷의 소스 주소는 프록시 전용 서브넷에서 할당됩니다. 이 예시에서 REGION_A 리전의 프록시 전용 서브넷의 기본 IP 주소 범위는 10.129.0.0/23이고 REGION_B의 기본 IP 주소 범위는 권장 서브넷 크기인 10.130.0.0/23입니다.
네트워크에서 프록시 전용 서브넷 트래픽 흐름을 허용하는 방화벽 규칙입니다. 즉, 10.129.0.0/23 및 10.130.0.0/23(이 예시의 프록시 전용 서브넷 범위)의 TCP 포트 80, 443, 8080 트래픽을 허용하는 하나의 규칙을 추가합니다.
상태 점검 프로브의 또 다른 방화벽 규칙입니다.
REGION_A 및 REGION_B 리전에 Cloud Run 배포를 위한 서버리스 백엔드가 있는 고가용성 설정입니다. 한 리전의 백엔드가 다운되면 트래픽이 다른 리전으로 장애 조치됩니다.
백엔드의 사용 및 상태를 모니터링하는 백엔드 서비스입니다. 백엔드 서비스에서 이상점 감지를 사용 설정했는지 확인합니다.
URL 맵은 요청의 URL을 파싱하고 요청 URL의 호스트와 경로에 따라 특정 백엔드 서비스로 요청을 전달합니다.
사용자로부터 요청을 수신하여 URL 맵에 전달하는 전역 대상 HTTP 또는 HTTPS 프록시입니다. HTTPS의 경우 리전별 SSL 인증서 리소스를 구성합니다. HTTPS 부하 분산을 구성할 경우 대상 프록시는 SSL 인증서를 사용하여 SSL 트래픽을 복호화합니다. 대상 프록시는 HTTP나 HTTPS를 사용하여 트래픽을 인스턴스에 전달할 수 있습니다.
각 수신 요청을 대상 프록시로 전달하기 위한 부하 분산기의 내부 IP 주소를 가진 전역 전달 규칙입니다.

전달 규칙에 연결된 내부 IP 주소는 동일한 네트워크 및 리전의 모든 서브넷에서 가져올 수 있습니다. 다음 조건을 참고하세요.
- IP 주소는 백엔드 인스턴스 그룹과 동일한 서브넷에서 가져올 수 있지만 반드시 그럴 필요는 없습니다.
- --purpose 플래그가 GLOBAL_MANAGED_PROXY로 설정된 예약된 프록시 전용 서브넷에서 IP 주소를 가져오면 안 됩니다.
- 여러 전달 규칙에서 같은 내부 IP 주소를 사용하려면 IP 주소 --purpose 플래그를 SHARED_LOADBALANCER_VIP로 설정합니다.
선택사항: GEO 유형의 DNS 라우팅 정책을 구성하여 클라이언트 트래픽을 클라이언트와 가장 가까운 리전의 부하 분산기 VIP로 라우팅합니다.

네트워크 및 서브넷 구성

VPC 네트워크 내에서 백엔드가 구성되는 각 리전에서 서브넷을 구성합니다. 또한 부하 분산기를 구성하려는 각 리전에 proxy-only-subnet을 구성합니다.

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

네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은 NETWORK입니다.
백엔드용 서브넷. REGION_A 리전에 있는 SUBNET_A라는 이름의 서브넷은 기본 IP 범위로 10.1.2.0/24를 사용합니다. REGION_B 리전에 있는 SUBNET_A라는 이름의 서브넷은 기본 IP 범위로 10.1.3.0/24를 사용합니다.
프록시용 서브넷. REGION_A 리전에 있는 PROXY_SN_A라는 이름의 서브넷은 기본 IP 범위로 10.129.0.0/23을 사용합니다. REGION_B 리전에 있는 PROXY_SN_B라는 이름의 서브넷은 기본 IP 범위로 10.130.0.0/23을 사용합니다.

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

백엔드 서브넷 구성

콘솔

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

VPC 네트워크로 이동
VPC 네트워크 만들기를 클릭합니다.
네트워크의 이름을 입력합니다.
서브넷 섹션에서 서브넷 생성 모드를 커스텀으로 설정합니다.
부하 분산기의 백엔드에 대한 서브넷을 만듭니다. 새 서브넷 섹션에 다음 정보를 입력합니다.
- 서브넷 이름을 입력합니다.
- 리전으로 REGION_A를 선택합니다.
- IP 주소 범위로 10.1.2.0/24를 입력합니다.
완료를 클릭합니다.
서브넷 추가를 클릭합니다.
부하 분산기의 백엔드에 대한 서브넷을 만듭니다. 새 서브넷 섹션에 다음 정보를 입력합니다.
- 서브넷 이름을 입력합니다.
- 리전으로 REGION_B를 선택합니다.
- IP 주소 범위로 10.1.3.0/24를 입력합니다.
완료를 클릭합니다.
만들기를 클릭합니다.

gcloud

gcloud compute networks create 명령어를 사용하여 커스텀 VPC 네트워크를 만듭니다.
```
gcloud compute networks create NETWORK --subnet-mode=custom
```
gcloud compute networks subnets create 명령어를 사용하여 REGION_A 리전의 NETWORK 네트워크에 서브넷을 만듭니다.
```
gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A
```
gcloud compute networks subnets create 명령어를 사용하여 REGION_B 리전의 NETWORK 네트워크에 서브넷을 만듭니다.
```
gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B
```

API

networks.insert 메서드에 대해 POST 요청을 실행합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

subnetworks.insert 메서드에 대해 POST 요청을 실행합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

subnetworks.insert 메서드에 대해 POST 요청을 실행합니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

프록시 전용 서브넷 구성

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

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

Console

Google Cloud 콘솔을 사용하는 경우에는 기다렸다가 나중에 부하 분산 페이지에서 프록시 전용 서브넷을 만들 수 있습니다.

지금 프록시 전용 서브넷을 만들려면 다음 단계를 사용합니다.

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

VPC 네트워크로 이동
VPC 네트워크의 이름을 클릭합니다.
서브넷 탭에서 서브넷 추가를 클릭합니다.
프록시 전용 서브넷의 이름을 입력합니다.
리전 목록에서 REGION_A을 선택합니다.
용도 목록에서 리전 간 관리형 프록시를 선택합니다.
IP 주소 범위 필드에 10.129.0.0/23을 입력합니다.
추가를 클릭합니다.

REGION_B에 프록시 전용 서브넷 만들기

서브넷 추가를 클릭합니다.
프록시 전용 서브넷의 이름을 입력합니다.
리전 목록에서 REGION_B을 선택합니다.
용도 목록에서 리전 간 관리형 프록시를 선택합니다.
IP 주소 범위 필드에 10.130.0.0/23을 입력합니다.
추가를 클릭합니다.

gcloud

gcloud compute networks subnets create 명령어로 프록시 전용 서브넷을 만드세요.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

subnetworks.insert 메서드로 프록시 전용 서브넷을 만드세요. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

서버리스 NEG 만들기

Cloud Run 서비스의 서버리스 NEG를 만듭니다.

gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

부하 분산기 구성

부하 분산기에서 서버리스 NEG 백엔드로 이동하는 트래픽은 방화벽 규칙이 적용되지 않는 VPC 외부에 정의된 특수 경로를 사용합니다. 따라서 부하 분산기에 서버리스 NEG 백엔드만 있으면 프록시 전용 서브넷에서 서버리스 백엔드로 이동하는 트래픽을 허용하는 방화벽 규칙을 만들 필요가 없습니다.

콘솔

구성 시작

Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

부하 분산으로 이동
부하 분산기 만들기를 클릭합니다.
부하 분산기 유형에서 애플리케이션 부하 분산기(HTTP/HTTPS)를 선택하고 다음을 클릭합니다.
공개 또는 내부에 내부를 선택하고 다음을 클릭합니다.
리전 간 또는 단일 리전 배포에서 리전 간 워크로드에 적합을 선택하고 다음을 클릭합니다.
구성을 클릭합니다.

기본 구성

부하 분산기의 이름을 입력합니다.
네트워크에 NETWORK을 선택합니다.

2개의 전달 규칙으로 프런트엔드 구성

HTTP의 경우:

프런트엔드 구성을 클릭합니다.

전달 규칙의 이름을 제공합니다.
서브네트워크 리전 목록에서 REGION_A를 선택합니다.
프록시 전용 서브넷 예약

서브네트워크 목록에서 SUBNET_A를 선택합니다.
IP 주소 목록에서 IP 주소 만들기를 클릭합니다. 고정 내부 IP 주소 예약 페이지가 열립니다.

고정 IP 주소의 이름을 입력합니다.
고정 IP 주소 목록에서 직접 선택을 선택합니다.
커스텀 IP 주소 필드에 10.1.2.99를 입력합니다.
예약을 선택합니다.

완료를 클릭합니다.
두 번째 전달 규칙을 추가하려면 프런트엔드 IP 및 포트 추가를 클릭합니다.

전달 규칙의 이름을 제공합니다.
서브네트워크 리전 목록에서 REGION_B를 선택합니다.
프록시 전용 서브넷 예약

서브네트워크 목록에서 SUBNET_B를 선택합니다.
IP 주소 목록에서 IP 주소 만들기를 클릭합니다. 고정 내부 IP 주소 예약 페이지가 열립니다.

고정 IP 주소의 이름을 입력합니다.
고정 IP 주소 목록에서 직접 선택을 선택합니다.
커스텀 IP 주소 필드에 10.1.3.99를 입력합니다.
예약을 선택합니다.

완료를 클릭합니다.

HTTPS의 경우:

클라이언트와 부하 분산기 사이에 HTTPS를 사용하는 경우 프록시를 구성할 하나 이상의 SSL 인증서 리소스가 필요합니다. all-regions Google 관리 인증서를 만들려면 다음 문서를 참조하세요.

Google 관리 인증서를 만든 후 인증서를 대상 프록시에 직접 연결합니다. 인증서 맵은 리전 간 내부 애플리케이션 부하 분산기에서 지원되지 않습니다.

all-regions 자체 관리형 인증서를 만들려면 리전 자체 관리형 인증서 배포 문서를 참조하세요.

프런트엔드 구성을 클릭합니다.

전달 규칙의 이름을 제공합니다.
프로토콜 필드에서 HTTPS (includes HTTP/2)를 선택합니다.
포트가 443으로 설정되었는지 확인합니다.
서브네트워크 리전 목록에서 REGION_A를 선택합니다.
프록시 전용 서브넷 예약

서브네트워크 목록에서 SUBNET_A를 선택합니다.
IP 주소 목록에서 IP 주소 만들기를 클릭합니다. 고정 내부 IP 주소 예약 페이지가 열립니다.

고정 IP 주소의 이름을 입력합니다.
고정 IP 주소 목록에서 직접 선택을 선택합니다.
커스텀 IP 주소 필드에 10.1.3.99를 입력합니다.
예약을 선택합니다.

인증서 추가 섹션에서 인증서를 선택합니다.
선택사항: 기본 SSL 인증서 외에 인증서를 추가하려면 다음 안내를 따르세요.

인증서 추가를 클릭합니다.
목록에서 인증서를 선택합니다.

SSL 정책 목록에서 SSL 정책을 선택합니다. SSL 정책을 만들지 않았다면 기본 Google Cloud SSL 정책이 적용됩니다.
완료를 클릭합니다.

두 번째 프런트엔드 구성 추가:

프런트엔드 구성의 이름을 입력합니다.
프로토콜 필드에서 HTTPS (includes HTTP/2)를 선택합니다.
포트가 443으로 설정되었는지 확인합니다.
서브네트워크 리전 목록에서 REGION_B를 선택합니다.
프록시 전용 서브넷 예약

서브네트워크 목록에서 SUBNET_B를 선택합니다.
IP 주소 목록에서 IP 주소 만들기를 클릭합니다. 고정 내부 IP 주소 예약 페이지가 열립니다.

고정 IP 주소의 이름을 입력합니다.
고정 IP 주소 목록에서 직접 선택을 선택합니다.
커스텀 IP 주소 필드에 10.1.3.99를 입력합니다.
예약을 선택합니다.

인증서 추가 섹션에서 인증서를 선택합니다.
선택사항: 기본 SSL 인증서 외에 인증서를 추가하려면 다음 안내를 따르세요.

인증서 추가를 클릭합니다.
목록에서 인증서를 선택합니다.

SSL 정책 목록에서 SSL 정책을 선택합니다. SSL 정책을 만들지 않았다면 기본 Google Cloud SSL 정책이 적용됩니다.
완료를 클릭합니다.

백엔드 서비스 구성

백엔드 구성을 클릭합니다.
백엔드 서비스 만들기 또는 선택 목록에서 백엔드 서비스 만들기를 클릭합니다.
백엔드 서비스의 이름을 입력합니다.
프로토콜에서 HTTP를 선택합니다.
이름이 지정된 포트에 http를 입력합니다.
백엔드 유형 목록에서 서버리스 네트워크 엔드포인트 그룹을 선택합니다.
새 백엔드 섹션에서 다음을 수행합니다.

서버리스 네트워크 엔드포인트 그룹 목록에서 gl7ilb-serverless-neg-a를 선택합니다.
완료를 클릭합니다.
다른 백엔드를 추가하려면 백엔드 추가를 클릭합니다.
서버리스 네트워크 엔드포인트 그룹 목록에서 gl7ilb-serverless-neg-b를 선택합니다.
완료를 클릭합니다.

라우팅 규칙 구성

라우팅 규칙을 클릭합니다.
모드에서 단순한 호스트 및 경로 규칙을 선택합니다.
일치하지 않는 모든 호스트 및 일치하지 않는 모든 경로에 대해 하나의 백엔드 서비스만 있는지 확인합니다.

구성 검토

검토 및 완료를 클릭합니다.
부하 분산기 구성 설정을 검토합니다.
만들기를 클릭합니다.

gcloud

gcloud compute backend-services create 명령어로 백엔드 서비스를 정의합니다.

gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

gcloud compute backend-services add-backend 명령어로 백엔드 서비스에 백엔드를 추가합니다.

gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

gcloud compute url-maps create 명령어로 URL 맵을 만듭니다.

gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

대상 프록시를 만듭니다.

HTTP의 경우:

gcloud compute target-http-proxies create 명령어를 사용하여 대상 프록시를 만듭니다.
```
gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global
```
HTTPS의 경우:

Google 관리 인증서를 만들려면 다음 문서를 참조하세요.
- Certificate Authority Service 인스턴스가 발급한 Google 관리형 인증서를 만듭니다.
- DNS 승인을 사용하여 Google 관리형 인증서 만들기
Google 관리 인증서를 만든 후 인증서를 대상 프록시에 직접 연결합니다. 인증서 맵은 리전 간 내부 애플리케이션 부하 분산기에서 지원되지 않습니다.

자체 관리형 인증서를 만들려면 다음 문서를 참조하세요.
- 비공개 키 및 인증서 만들기
파일 경로를 변수 이름에 할당합니다.
```
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
```
```
export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
```
gcloud certificate-manager certificates create 명령어를 사용하여 모든 리전 SSL 인증서를 만듭니다.
```
gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  –-scope=all-regions
```
SSL 인증서를 사용하여 gcloud compute target-https-proxies create 명령어로 대상 프록시를 만듭니다.
```
gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate
```

REGION_B 리전에 VIP(10.1.2.99)가 있는 전달 규칙과 REGION_A 리전에 VIP(10.1.3.99)가 있는 전달 규칙 두 개를 만듭니다.

커스텀 네트워크의 경우 전달 규칙에서 서브넷을 참조해야 합니다. 프록시 서브넷이 아닌 가상 머신(VM) 인스턴스 서브넷입니다.

HTTP의 경우:

올바른 플래그와 함께 gcloud compute forwarding-rules create 명령어를 사용하세요.

gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

HTTPS의 경우:

올바른 플래그와 함께 gcloud compute forwarding-rules create 명령어를 사용하여 전달 규칙을 만듭니다.

gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

backendServices.insert 메서드에 POST 요청을 수행하여 전역 백엔드 서비스를 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

urlMaps.insert 메서드에 POST 요청을 수행하여 URL 맵을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

HTTP의 경우:

targetHttpProxies.insert 메서드에 POST 요청을 수행하여 대상 HTTP 프록시를 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

globalforwardingRules.insert 메서드에 POST 요청을 수행하여 전달 규칙을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

HTTPS의 경우:

인증서 및 비공개 키 파일을 읽은 다음 SSL 인증서를 만듭니다. 다음 예시에서는 Python을 사용하여 이 작업을 수행하는 방법을 보여줍니다.

targetHttpsProxies.insert 메서드에 POST 요청을 수행하여 대상 HTTPS 프록시를 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

globalForwardingRules.insert 메서드에 POST 요청을 수행하여 전달 규칙을 만듭니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

부하 분산기 테스트

부하 분산 서비스가 실행 중이므로 이제 전달 규칙으로 트래픽을 전송하고 다른 인스턴스로 분산되는 트래픽을 관찰할 수 있습니다.

방화벽 규칙 구성

이 예시에서는 테스트 클라이언트 VM에 대한 fw-allow-ssh 방화벽 규칙이 필요합니다. fw-allow-ssh는 테스트 클라이언트 VM에 적용할 수 있으며 TCP 포트 22에서 임의의 주소로부터 수신되는 SSH 연결을 허용하는 인그레스 규칙입니다. 이 규칙에 더 제한적인 소스 IP 주소 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작할 시스템의 IP 주소 범위만 지정할 수도 있습니다. 이 예시에서는 대상 태그 allow-ssh를 사용합니다.

gcloud

allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-ssh 방화벽 규칙을 만듭니다. source-ranges를 생략하면 Google Cloud는 모든 소스를 의미하는 것으로 규칙을 해석합니다.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```

VM 인스턴스를 생성하여 연결 테스트

클라이언트 VM을 만듭니다.

gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

각 클라이언트 인스턴스에 SSH를 통해 연결합니다.

gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

IP 주소가 호스트 이름을 제공하는지 확인합니다.
- 클라이언트 VM이 두 IP 주소 모두에 연결할 수 있는지 확인합니다. 명령어가 성공하고 요청을 처리한 백엔드 VM의 이름을 반환합니다.
```
curl 10.1.2.99
```
```
curl 10.1.3.99
```
  HTTPS 테스트의 경우 curl을 다음으로 바꿉니다.
```
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
```
```
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443
```
  -k 플래그로 인해 curl이 인증서 유효성 검사를 건너뜁니다.
- 선택사항: 구성된 DNS 레코드를 사용하여 IP 주소를 변환합니다.
```
curl service.example.com
```

100개의 요청을 실행하고 부하 분산되었는지 확인

HTTP의 경우:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

HTTPS의 경우:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

장애 조치 테스트

REGION_B 리전의 백엔드가 비정상이거나 연결할 수 없는 경우 REGION_A 리전의 백엔드로 장애 조치되는지 확인합니다. 이를 시뮬레이션하기 위해 REGION_B에서 모든 백엔드를 삭제합니다.
```
gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B
```
SSH를 사용하여 REGION_B의 클라이언트 VM에 연결합니다.
```
gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B
```

REGION_B 리전의 부하 분산된 IP 주소로 요청을 전송합니다. 명령어 결과에 REGION_A의 백엔드 VM의 응답이 표시됩니다.

{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

추가 구성 옵션

이 섹션에서는 대체 및 추가 구성 옵션을 제공하는 구성 예시를 살펴봅니다. 모든 태스크는 선택사항입니다. 원하는 순서대로 수행할 수 있습니다.

URL 마스크 사용

서버리스 NEG를 만들 때 특정 Cloud Run 서비스를 선택하는 대신 URL 마스크를 사용하여 동일한 도메인에서 제공하는 여러 서비스를 가리킬 수 있습니다. URL 마스크는 URL 스키마 템플릿입니다. 서버리스 NEG는 이 템플릿을 사용하여 수신 요청의 URL에서 서비스 이름을 추출하고 요청을 적절한 서비스에 매핑합니다.

URL 마스크는 Google Cloud가 배포된 서비스에 제공하는 기본 주소가 아닌 커스텀 도메인에 서비스가 매핑되는 경우에 특히 유용합니다. URL 마스크를 사용하면 애플리케이션이 커스텀 URL 패턴을 사용하는 경우에도 단일 규칙으로 여러 서비스와 버전을 대상으로 지정할 수 있습니다.

아직 수행하지 않았으면 서버리스 NEGS 개요: URL 마스크를 읽어보세요.

URL 마스크 구성

부하 분산기의 URL 마스크를 구성하려면 서비스의 URL로 시작합니다. 이 예시에서는 https://example.com/login에서 실행되는 샘플 서버리스 앱을 사용합니다. 앱의 login 서비스가 제공될 URL입니다.

URL에서 http 또는 https를 삭제합니다. example.com/login이 남았습니다.
서비스 이름을 URL 마스크의 자리표시자로 바꿉니다.
- Cloud Run: Cloud Run 서비스 이름을 자리표시자 <service>로 바꿉니다. Cloud Run 서비스에 연결된 태그가 있으면 태그 이름을 자리표시자 <tag>로 바꿉니다. 이 예시에서 남은 URL 마스크는 example.com/<service>입니다.
선택사항: URL의 경로 부분에서 서비스 이름을 추출할 수 있으면 도메인을 생략할 수 있습니다. URL 마스크의 경로 부분은 첫 번째 슬래시(/) 문자로 구분됩니다. URL 마스크에 슬래시(/)가 없으면 마스크는 호스트만 나타내는 것으로 이해됩니다. 따라서 이 예시에서는 URL 마스크를 /<service>로 줄일 수 있습니다.

마찬가지로 URL의 호스트 부분에서 <service>를 추출할 수 있으면 URL 마스크에서 경로를 모두 생략할 수 있습니다.

또한 첫 번째 자리표시자 앞에 오는 모든 호스트 또는 하위 도메인 구성요소와 마지막 자리표시자 다음에 오는 모든 경로 구성요소를 생략할 수 있습니다. 이러한 경우 자리표시자는 구성요소에 필요한 정보를 캡처합니다.

다음은 이러한 규칙을 보여주는 몇 가지 예시입니다.

이 표에서는 example.com이라는 커스텀 도메인이 있고 모든 Cloud Run 서비스가 이 도메인에 매핑되어 있다고 가정합니다.

서비스, 태그 이름	Cloud Run 커스텀 도메인 URL	URL 마스크
서비스: 로그인	https://login-home.example.com/web	<service>-home.example.com
서비스: 로그인	https://example.com/login/web	example.com/<service> 또는 /<service>
서비스: 로그인, 태그: 테스트	https://test.login.example.com/web	<tag>.<service>.example.com
서비스: 로그인, 태그: 테스트	https://example.com/home/login/test	example.com/home/<service>/<tag> 또는 /home/<service>/<tag>
서비스: 로그인, 태그: 테스트	https://test.example.com/home/login/web	<tag>.example.com/home/<service>

URL 마스크를 사용하여 서버리스 NEG 만들기

콘솔

새 부하 분산기에 대해 이 문서의 앞에서 설명한 것과 동일한 엔드 투 엔드 프로세스를 사용할 수 있습니다. 백엔드 서비스를 구성할 때 특정 서비스를 선택하는 대신 URL 마스크를 입력합니다.

기존 부하 분산기가 있는 경우 백엔드 구성을 수정하여 서버리스 NEG가 특정 서비스 대신 URL 마스크를 가리키도록 할 수 있습니다.

URL 마스크 기반 서버리스 NEG를 기존 백엔드 서비스에 추가하려면 다음을 수행합니다.

Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
부하 분산으로 이동
수정하려는 백엔드 서비스가 포함된 부하 분산기 이름을 클릭합니다.
부하 분산기 세부정보 페이지에서 수정을 클릭합니다.
전역 외부 애플리케이션 부하 분산기 수정 페이지에서 백엔드 구성을 클릭합니다.
백엔드 구성 페이지에서 수정하려는 백엔드 서비스에 대해 수정을 클릭합니다.
백엔드 추가를 클릭합니다.
서버리스 네트워크 엔드포인트 그룹 만들기를 선택합니다.

이름에 helloworld-serverless-neg를 입력합니다.
리전 아래에 부하 분산기의 리전이 표시됩니다.
서버리스 네트워크 엔드포인트 그룹 유형에서 Cloud Run은 지원되는 유일한 네트워크 엔드포인트 그룹 유형입니다.

URL 마스크 사용을 선택합니다.
URL 마스크를 입력합니다. URL 마스크를 만드는 방법에 대한 자세한 내용은 URL 마스크 구성을 참조하세요.
만들기를 클릭합니다.

새 백엔드에서 완료를 클릭합니다.
업데이트를 클릭합니다.

gcloud

샘플 URL 마스크가 example.com/<service>인 서버리스 NEG를 만들려면 다음 명령어를 실행합니다.

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

여러 내부 전달 규칙 간에 같은 IP 주소 사용

여러 내부 전달 규칙이 동일한 내부 IP 주소를 공유하려면 IP 주소를 예약하고 --purpose 플래그를 SHARED_LOADBALANCER_VIP로 설정해야 합니다.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

HTTP 트래픽을 HTTPS로 리디렉션해야 하는 경우 공통 IP 주소를 사용하는 전달 규칙 두 개를 만들 수 있습니다. 자세한 내용은 내부 애플리케이션 부하 분산기에 HTTP-HTTPS 리디렉션 설정을 참조하세요.

DNS 라우팅 정책 구성

클라이언트가 여러 리전에 있는 경우 해당 리전에서 VIP를 사용하여 리전 간 내부 애플리케이션 부하 분산기에 액세스해야 할 수 있습니다. 이 멀티 리전 설정은 지연 시간과 네트워크 전송 비용을 최소화해 줍니다. 이를 통해 리전 서비스 중단에 대한 복원력을 제공하는 DNS 기반의 전역 부하 분산 솔루션도 설정할 수 있습니다. 자세한 내용은 DNS 라우팅 정책 및 상태 점검 관리를 참조하세요.

gcloud

30초 TTL로 DNS 항목을 만들려면 gcloud dns record-sets create 명령어를 사용하세요.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

다음을 바꿉니다.

DNS_ENTRY: 레코드 모음의 DNS 또는 도메인 이름
예를 들면 service.example.com입니다.
REGION_A 및 REGION_B: 부하 분산기를 구성한 리전

API

POST 요청을 ResourceRecordSets.create 메서드에 보내 DNS 레코드를 만듭니다. PROJECT_ID를 프로젝트 ID로 바꿉니다.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-a",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-b",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

이상점 감지 사용 설정

전역 백엔드 서비스에 이상점 감지를 사용 설정하여 비정상 서버리스 NEG를 식별하고 비정상 서버리스 NEG에 전송되는 요청 수를 줄일 수 있습니다.

다음 방법 중 하나를 사용하여 이상점 감지를 백엔드 서비스에 사용 설정합니다.

5xx 시리즈 HTTP 상태 코드가 오류에 해당하는 consecutiveErrors 메서드(outlierDetection.consecutiveErrors)
502, 503, 504 HTTP 상태 코드만 오류에 해당하는 consecutiveGatewayFailure 메서드(outlierDetection.consecutiveGatewayFailure)

다음 단계에 따라 기존 백엔드 서비스에 대한 이상점 감지를 사용 설정합니다. 이상점 감지를 사용 설정하더라도 일부 요청이 비정상 서비스로 전송되어 클라이언트에 5xx 상태 코드를 반환할 수 있습니다. 오류율을 더 줄이기 위해 이상점 감지 매개변수에 대해 보다 공격적인 값을 구성할 수 있습니다. 자세한 내용은 outlierDetection 필드를 참조하세요.

콘솔

Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

부하 분산으로 이동
백엔드 서비스를 수정할 부하 분산기의 이름을 클릭합니다.
부하 분산기 세부정보 페이지에서 수정을 클릭합니다.
리전 간 내부 애플리케이션 부하 분산기 수정 페이지에서 백엔드 구성을 클릭합니다.
백엔드 구성 페이지에서 수정하려는 백엔드 서비스에 대해 수정 을 클릭합니다.
아래로 스크롤하여 고급 구성 섹션을 펼칩니다.
이상점 감지 섹션에서 사용 설정 체크박스를 선택합니다.
수정을 클릭하여 이상점 감지를 구성합니다.

다음 옵션이 이러한 값으로 구성되었는지 확인합니다.

속성 가치

연속 오류 5

간격 1000

기본 제거 시간 30000

최대 제거 비율 50

연속 오류 시 시행 100

이 예시에서는 이상점 감지 분석이 1초마다 실행됩니다. Envoy 프록시에서 수신하는 연속 HTTP 5xx 상태 코드 수가 5개 이상이면 30초 동안 해당 Envoy 프록시의 부하 분산 풀에서 백엔드 엔드포인트가 제거됩니다. 적용 비율이 100%로 설정되면 백엔드 서비스는 이상점 감지 분석이 실행될 때마다 해당 특정 Envoy 프록시의 부하 분산 풀에서 비정상 엔드포인트를 제거합니다. 제거 조건이 충족되면 부하 분산 풀에서 백엔드 엔드포인트의 최대 50%를 제거할 수 있습니다.
저장을 클릭합니다.
백엔드 서비스를 업데이트하려면 업데이트를 클릭합니다.
부하 분산기를 업데이트하려면 리전 간 내부 애플리케이션 부하 분산기 수정 페이지에서 업데이트를 클릭합니다.

속성	가치
연속 오류	5
간격	1000
기본 제거 시간	30000
최대 제거 비율	50
연속 오류 시 시행	100

gcloud

백엔드 서비스를 YAML 파일로 내보냅니다.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global
```
BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.
백엔드 서비스의 YAML 구성을 수정하여 다음 YAML 구성에 강조표시된 대로 이상점 감지 필드를 추가합니다.

이 예시에서는 이상점 감지 분석이 1초마다 실행됩니다. Envoy 프록시에서 수신하는 연속 HTTP 5xx 상태 코드 수가 5개 이상이면 30초 동안 해당 Envoy 프록시의 부하 분산 풀에서 백엔드 엔드포인트가 제거됩니다. 적용 비율이 100%로 설정되면 백엔드 서비스는 이상점 감지 분석이 실행될 때마다 해당 특정 Envoy 프록시의 부하 분산 풀에서 비정상 엔드포인트를 제거합니다. 제거 조건이 충족되면 부하 분산 풀에서 백엔드 엔드포인트의 최대 50%를 제거할 수 있습니다.
```
name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...
```
다음을 바꿉니다.
- BACKEND_SERVICE_NAME: 백엔드 서비스 이름
- PROJECT_ID: 프로젝트의 ID
- REGION_A 및 REGION_B: 부하 분산기가 구성된 리전
- SERVERLESS_NEG_NAME: 첫 번째 서버리스 NEG의 이름
- SERVERLESS_NEG_NAME_2: 두 번째 서버리스 NEG의 이름
최신 구성을 가져와서 백엔드 서비스를 업데이트합니다.
```
gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global
```
백엔드 서비스에 이상점 감지가 사용 설정되었습니다.

서버리스 NEG 삭제

네트워크 엔드포인트 그룹이 백엔드 서비스에 연결되어 있으면 삭제할 수 없습니다. NEG를 삭제하기 전에 백엔드 서비스에서 분리하세요.

콘솔

삭제하려는 서버리스 NEG가 백엔드 서비스에서 사용되고 있지 않은지 확인하려면 부하 분산 구성요소 페이지의 백엔드 서비스 탭으로 이동합니다.
백엔드 서비스로 이동
서버리스 NEG가 사용 중인 경우 다음을 수행합니다.

서버리스 NEG를 사용하는 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
백엔드 목록에서 를 클릭하여 백엔드 서비스에서 서버리스 NEG 백엔드를 삭제합니다.
저장을 클릭합니다.

Google Cloud 콘솔의 네트워크 엔드포인트 그룹 페이지로 이동합니다.
네트워크 엔드포인트 그룹으로 이동
삭제할 서버리스 NEG의 체크박스를 선택합니다.
삭제를 클릭합니다.
삭제를 다시 클릭하여 확인합니다.

gcloud

백엔드 서비스에서 서버리스 NEG를 삭제하려면 NEG가 생성된 리전을 지정해야 합니다.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

서버리스 NEG를 삭제하려면 다음 안내를 따르세요.

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION