Cloud Run, App Engine 또는 Cloud Functions를 사용하여 전역 외부 애플리케이션 부하 분산기 설정

이 페이지에서는 외부 애플리케이션 부하 분산기를 만들어서 요청을 서버리스 백엔드로 라우팅하는 방법을 보여줍니다. 여기서 서버리스라는 용어는 다음과 같은 서버리스 컴퓨팅 제품을 의미합니다.

App Engine
Cloud Functions
Cloud Run

API 게이트웨이와 외부 애플리케이션 부하 분산기 통합을 통해 서버리스 백엔드가 Cloud Load Balancing에서 제공되는 모든 기능을 활용하도록 지원할 수 있습니다. 트래픽을 API 게이트웨이로 라우팅하도록 외부 애플리케이션 부하 분산기를 구성하려면 API 게이트웨이용 외부 애플리케이션 부하 분산기 시작하기를 참조하세요. API 게이트웨이용 외부 애플리케이션 부하 분산기 지원은 미리보기 상태입니다.

서버리스 NEG를 사용하면 외부 애플리케이션 부하 분산기와 함께 Google Cloud 서버리스 앱을 사용할 수 있습니다. 서버리스 NEG 백엔드로 부하 분산기를 구성하면 부하 분산기에 대한 요청이 서버리스 앱 백엔드로 라우팅됩니다.

서버리스 NEG에 대한 자세한 내용은 서버리스 NEG 개요를 참조하세요.

기본 애플리케이션 부하 분산기의 기존 사용자인 경우 전역 외부 애플리케이션 부하 분산기를 사용하여 새 배포를 계획할 때 전역 외부 애플리케이션 부하 분산기로의 마이그레이션 계획을 검토하세요.

시작하기 전에

App Engine, Cloud Functions 또는 Cloud Run 서비스를 배포합니다.
Google Cloud CLI를 아직 설치하지 않았으면 설치합니다.
권한 구성
SSL 인증서 리소스를 추가합니다.

App Engine, Cloud Functions 또는 Cloud Run 서비스 배포

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

이 페이지의 예시에서는 Cloud Run Python 빠른 시작을 사용하여 us-central1 리전에 Cloud Run 서비스를 배포했습니다. 이 페이지의 나머지 부분에서는 서버리스 NEG 백엔드를 사용하여 요청을 이 서비스로 라우팅하는 외부 애플리케이션 부하 분산기를 설정하는 방법을 보여줍니다.

아직 서버리스 앱을 배포하지 않았거나 샘플 앱으로 서버리스 NEG를 사용해 보려면 다음 빠른 시작 중 하나를 사용하세요. 모든 리전에서 서버리스 앱을 만들 수 있지만 나중에 동일한 리전을 사용하여 서버리스 NEG 및 부하 분산기를 만들어야 합니다.

Cloud Run

간단한 Hello World 애플리케이션을 만들고 컨테이너 이미지에 패키징한 다음 컨테이너 이미지를 Cloud Run에 배포하려면 빠른 시작: 빌드 및 배포를 참조하세요.

Container Registry에 이미 업로드된 샘플 컨테이너가 있는 경우 빠른 시작: 사전 빌드된 샘플 컨테이너 배포를 참조하세요.

Cloud Functions

Cloud Functions: Python 빠른 시작을 참조하세요.

App Engine

Python 3용 App Engine 빠른 시작 가이드를 참조하세요.

Google Cloud CLI 설치

Google Cloud CLI를 설치합니다. 도구에 대한 개념 및 설치 정보는 gcloud 개요를 참조하세요.

이전에 gcloud CLI를 실행한 적이 없으면 먼저 gcloud init를 실행하여 gcloud 디렉터리를 초기화합니다.

권한 구성

이 가이드를 따르려면 서버리스 NEG를 만들고 프로젝트에 외부 HTTP(S) 부하 분산기를 만들어야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 보유해야 합니다.

태스크	필요한 역할
부하 분산기 및 네트워킹 구성요소 만들기	네트워크 관리자
NEG 생성 및 수정	Compute 인스턴스 관리자
SSL 인증서 생성 및 수정	보안 관리자

외부 IP 주소 예약

서비스가 준비되어 실행 중이므로 고객이 부하 분산기에 연결하는 데 사용하는 전역 고정 외부 IP 주소를 설정합니다.

콘솔

Google Cloud 콘솔에서 외부 IP 주소 페이지로 이동합니다.

외부 IP 주소로 이동
외부 고정 IP 주소 예약을 클릭합니다.
이름에 example-ip를 입력합니다.
네트워크 서비스 등급에서 프리미엄을 선택합니다.
IP 버전에서 IPv4를 선택합니다.
유형에서 전역을 선택합니다.
예약을 클릭합니다.

gcloud

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

예약된 IPv4 주소를 확인합니다.

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

SSL 인증서 리소스 만들기

HTTPS 부하 분산기를 만들려면 부하 분산기의 프런트엔드에 SSL 인증서 리소스를 추가해야 합니다. Google 관리형 SSL 인증서 또는 자체 관리형 SSL 인증서를 사용하여 SSL 인증서 리소스를 만듭니다.

Google 관리형 인증서. Google Cloud는 이러한 인증서를 자동으로 가져오고 관리하며 갱신하므로 Google 관리형 인증서를 사용하는 것이 좋습니다. Google 관리형 인증서를 만들려면 인증서를 프로비저닝할 수 있도록 도메인과 해당 도메인에 대한 DNS 레코드가 있어야 합니다. 도메인이 없으면 Google Domains에서 얻을 수 있습니다. 자세한 내용은 Google Domains 시작하기를 참조하세요. 또한 이전 단계에서 만든 부하 분산기의 IP 주소를 가리키도록 도메인의 DNS A 레코드를 업데이트해야 합니다(example-ip). 자세한 내용은 Google 관리형 인증서 사용을 참조하세요.
자체 서명 인증서. 지금 도메인을 설정하지 않으려면 자체 서명된 SSL 인증서를 사용하여 테스트할 수 있습니다.

이 예시에서는 사용자가 이미 SSL 인증서 리소스를 만들었다고 가정합니다.

SSL 인증서 리소스(또는 Google에서 관리하는 인증서에서 요구하는 도메인)를 만들지 않고 이 프로세스를 테스트하려는 경우에도 이 페이지의 안내에 따라 HTTP 로드를 설정할 수 있습니다.

부하 분산기 만들기

다음 다이어그램에서 부하 분산기는 서버리스 NEG 백엔드를 사용하여 서버리스 Cloud Run 서비스로 요청을 전달합니다. 이 예시에서는 Cloud Run Python 빠른 시작을 사용하여 Cloud Run 서비스를 배포했습니다.

Cloud Run 애플리케이션의 외부 애플리케이션 부하 분산기 아키텍처(확대하려면 클릭)

서버리스 NEG 백엔드가 있는 백엔드 서비스에는 상태 확인이 지원되지 않으므로 부하 분산기에 서버리스 NEG 백엔드만 있는 경우 상태 확인을 허용하는 방화벽 규칙을 만들 필요가 없습니다.

Console

구성 시작

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

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

기본 구성

부하 분산기 이름에 serverless-lb를 입력합니다.
계속하려면 창을 열어둡니다.

프런트엔드 구성

프런트엔드 구성을 클릭합니다.
이름에 이름을 입력합니다.
HTTPS 부하 분산기를 만들려면 SSL 인증서(gcloud compute ssl-certificates list)가 있어야 합니다.
앞선 설명대로 Google 관리 인증서를 사용하는 것이 좋습니다.

외부 애플리케이션 부하 분산기를 구성하려면 다음과 같이 필드를 채웁니다.

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

속성	값(값 입력 또는 지정된 옵션 선택)
프로토콜	HTTPS
네트워크 서비스 계층	프리미엄
IP 버전	IPv4
IP 주소	example-ip
포트	443
선택사항: HTTP 연결 유지 제한 시간	5~1,200초 사이의 제한 시간 값을 입력합니다. 기본값은 610초입니다.
인증서	기존 SSL 인증서를 선택하거나 새 인증서를 만듭니다. HTTPS 부하 분산기를 만들려면 HTTPS 프록시에서 사용할 SSL 인증서 리소스가 있어야 합니다. Google 관리 SSL 인증서나 자체 관리형 SSL 인증서를 사용하여 SSL 인증서 리소스를 만들 수 있습니다. Google 관리형 인증서를 만들려면 도메인이 있어야 합니다. 도메인의 A 레코드는 부하 분산기의 IP 주소(이 예시에서는 `example-ip`)로 확인되어야 합니다. Google Cloud는 이러한 인증서를 자동으로 가져오고 관리 및 갱신하므로 Google 관리형 인증서를 사용하는 것이 좋습니다. 도메인이 없는 경우 자체 서명 SSL 인증서를 사용하여 테스트할 수 있습니다.
선택사항: HTTP-HTTPS 리디렉션 사용 설정	이 체크박스를 사용하여 HTTP에서 HTTPS로 리디렉션을 사용 설정합니다. 이 체크박스를 사용 설정하면 HTTPS 부하 분산기와 동일한 IP 주소를 사용하는 추가적인 부분 HTTP 부하 분산기를 만들고 HTTP 요청을 부하 분산기의 HTTPS 프런트엔드로 리디렉션합니다. 이 체크박스는 HTTPS 프로토콜이 선택되었고 예약된 IP 주소가 사용될 때만 선택할 수 있습니다.

SSL 인증서 리소스(또는 Google 관리 인증서의 요구에 따라 도메인)을 설정하지 않고 이 프로세스를 테스트하려면 HTTP 부하 분산기를 설정하면 됩니다.

HTTP 부하 분산기를 만들려면 다음 옵션이 해당 값으로 구성되었는지 확인합니다.

속성	값(값 입력 또는 지정된 옵션 선택)
프로토콜	HTTP
네트워크 서비스 계층	프리미엄
IP 버전	IPv4
IP 주소	example-ip
포트	80
선택사항: HTTP 연결 유지 제한 시간	5~1,200초 사이의 제한 시간 값을 입력합니다. 기본값은 610초입니다.

완료를 클릭합니다.

백엔드 구성

백엔드 구성을 클릭합니다.
백엔드 서비스 및 백엔드 버킷 목록에서 백엔드 서비스 만들기를 클릭합니다.
이름에 이름을 입력합니다.
백엔드 유형에서 서버리스 네트워크 엔드포인트 그룹을 선택합니다.
프로토콜은 그대로 둡니다. 이 매개변수는 무시됩니다.
백엔드 섹션의 새 백엔드에서 서버리스 네트워크 엔드포인트 그룹 만들기를 선택합니다.
이름에 이름을 입력합니다.
리전에서 us-central1을 선택한 후 Cloud Run을 선택합니다.
서비스 이름 선택을 선택합니다.
서비스 목록에서 부하 분산기를 만들려는 Cloud Run 서비스를 선택합니다.
만들기를 클릭합니다.
새 백엔드 섹션에서 완료를 클릭합니다.
만들기를 클릭합니다.

라우팅 규칙

라우팅 규칙은 트래픽의 전달 방식을 결정합니다. 라우팅을 구성하려면 외부 애플리케이션 부하 분산기의 URL 맵의 구성 구성요소에 해당하는 호스트 규칙 및 경로 일치자를 설정합니다.

라우팅 규칙을 클릭합니다.
기본 호스트 및 경로를 유지합니다. 이 예시에서는 모든 요청이 이전 단계에서 생성된 백엔드 서비스로 이동합니다.

구성 검토

검토 및 완료를 클릭합니다.
모든 설정을 검토합니다.
선택사항: 부하 분산기를 만드는 데 사용되는 REST API 요청을 보려면 상응하는 코드를 클릭합니다.
만들기를 클릭합니다.
부하 분산기가 생성될 때까지 기다립니다.
부하 분산기의 이름을 클릭합니다(serverless-lb).
다음 태스크를 위해 부하 분산기의 IP 주소를 기록합니다. 이를 IP_ADDRESS라고 합니다.

gcloud

서버리스 앱의 서버리스 NEG를 만듭니다.
Cloud Run 서비스로 서버리스 NEG를 만들려면 다음을 실행합니다.
```
   gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=CLOUD_RUN_SERVICE_NAME
   
```
다른 옵션은 gcloud compute network-endpoint-groups create의 gcloud 참조 가이드를 확인하세요.

백엔드 서비스를 만듭니다.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --global

서버리스 NEG를 백엔드 서비스에 백엔드로 추가합니다.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --global \
       --network-endpoint-group=SERVERLESS_NEG_NAME \
       --network-endpoint-group-region=us-central1

수신되는 요청을 백엔드 서비스로 라우팅하는 URL 맵을 만듭니다.
```
   gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME
   
```
이 예시 URL 맵은 단일 서버리스 앱을 나타내는 백엔드 서비스 하나만 대상으로 지정하므로 호스트 규칙이나 경로 일치자를 설정할 필요가 없습니다. 백엔드 서비스가 두 개 이상 있으면 호스트 규칙을 사용하여 호스트 이름을 기준으로 다른 서비스로 요청을 전달하고 경로 일치자를 설정하여 요청 경로를 기준으로 다른 서비스로 요청을 전달할 수 있습니다.
HTTPS 부하 분산기를 만들려는 경우에만 이 단계를 수행합니다. HTTP 부하 분산기에는 이 작업이 필요하지 않습니다.
HTTPS 부하 분산기를 만들려면 HTTPS 대상 프록시에서 사용할 SSL 인증서 리소스가 있어야 합니다. Google 관리형 SSL 인증서나 자체 관리형 SSL 인증서를 사용하여 SSL 인증서 리소스를 만들 수 있습니다. Google Cloud는 이러한 인증서를 자동으로 가져오고 관리 및 갱신하므로 Google 관리형 인증서를 사용하는 것이 좋습니다.

Google 관리형 인증서를 만들려면 도메인이 있어야 합니다. 도메인이 없는 경우 자체 서명 SSL 인증서를 사용하여 테스트할 수 있습니다.

Google 관리형 SSL 인증서 리소스를 만들려면 다음 안내를 따르세요.
```
   gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
   
```
자체 관리형 SSL 인증서 리소스를 만들려면 다음 안내를 따르세요.
```
   gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --certificate CRT_FILE_PATH \
       --private-key KEY_FILE_PATH
   
```
대상 HTTP(S) 프록시를 만들어 요청을 URL 맵으로 라우팅합니다.

HTTP 부하 분산기의 경우 HTTP 대상 프록시를 만듭니다.
```
   gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
      --url-map=URL_MAP_NAME
   
```
HTTPS 부하 분산기의 경우 HTTPS 대상 프록시를 만듭니다. 프록시는 HTTPS 부하 분산에 사용되는 SSL 인증서가 포함된 부하 분산기의 일부분이므로 이 단계에서 인증서도 로드합니다.
```
   gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
       --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
       --ssl-certificates=SSL_CERTIFICATE_NAME \
       --url-map=URL_MAP_NAME
   
```
다음을 바꿉니다.
- TARGET_HTTP_PROXY_NAME: 대상 HTTP 프록시의 이름입니다.
- TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시의 이름입니다.
- HTTP_KEEP_ALIVE_TIMEOUT_SEC: 클라이언트 HTTP 연결 유지 제한 시간을 지정하는 데 사용되는 필드입니다(선택사항). 제한 시간 값은 5~1,200초 사이여야 합니다. 기본값은 610초입니다.
- SSL_CERTIFICATE_NAME: SSL 인증서의 이름입니다.
- URL_MAP_NAME: URL 맵의 이름입니다.

수신되는 요청을 프록시로 라우팅하는 전달 규칙을 만듭니다.

HTTP 부하 분산기의 경우:

   gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=example-ip \
   --target-http-proxy=TARGET_HTTP_PROXY_NAME \
   --global \
   --ports=80

HTTPS 부하 분산기의 경우:

   gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

부하 분산기에 도메인 연결

부하 분산기를 만든 후 부하 분산기와 연결된 IP 주소를 확인합니다(예: 30.90.80.100). 도메인이 부하 분산기를 가리키도록 하려면 도메인 등록 서비스를 사용하여 A 레코드를 만듭니다. SSL 인증서에 여러 도메인을 추가했다면 모두 부하 분산기의 IP 주소를 가리키는 A 레코드를 도메인마다 추가해야 합니다. 예를 들어 www.example.com 및 example.com의 A 레코드를 만들려면 다음을 사용합니다.

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Cloud DNS를 DNS 제공업체로 사용하는 경우 레코드 추가, 수정, 삭제를 참조하세요.

부하 분산기 테스트

부하 분산기를 구성했으므로 부하 분산기의 IP 주소로 트래픽을 전송할 수 있습니다. 도메인을 구성한 경우 트래픽을 도메인 이름으로도 전송할 수 있습니다. 하지만 DNS 전파는 완료하는 데 시간이 오래 걸릴 수 있으므로, IP 주소를 사용하여 테스트를 시작할 수 있습니다.

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

부하 분산으로 이동
방금 만든 부하 분산기를 클릭합니다.
부하 분산기의 IP 주소를 확인합니다.
HTTP 부하 분산기의 경우 http://IP_ADDRESS로 이동하여 웹브라우저를 사용해서 부하 분산기를 테스트할 수 있습니다. IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다. helloworld 서비스 홈페이지로 이동해야 합니다.
HTTPS 부하 분산기의 경우 https://IP_ADDRESS로 이동하여 웹브라우저를 사용해서 부하 분산기를 테스트할 수 있습니다. IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다. helloworld 서비스 홈페이지로 이동해야 합니다.
그래도 문제가 해결되지 않고 Google 관리형 인증서를 사용 중인 경우 인증서 리소스가 활성 상태인지 확인합니다. 자세한 내용은 Google 관리형 SSL 인증서 리소스 상태를 참조하세요.
자체 서명 인증서를 테스트에 사용하면 브라우저에 경고가 표시됩니다. 브라우저가 자체 서명 인증서를 수락하도록 명시적으로 지시해야 합니다. 실제 페이지를 보려면 경고를 클릭하세요.

추가 구성 옵션

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

멀티 리전 부하 분산 설정

이 페이지의 앞부분에서 설명한 예시에서는 us-central1 리전에 백엔드로 제공되는 Cloud Run 서비스가 하나뿐입니다. 서버리스 NEG는 한 번에 하나의 엔드포인트만 가리킬 수 있으므로 여러 리전에서 부하 분산이 수행되지 않습니다. 외부 애플리케이션 부하 분산기는 프런트엔드 역할만 하며 지정된 helloworld 앱 엔드포인트로 트래픽을 프록시합니다. 하지만 최종 사용자의 지연 시간을 개선하기 위해 둘 이상의 리전에서 Cloud Run 앱을 제공할 수 있습니다.

백엔드 서비스에 여러 서버리스 NEG가 연결된 경우 부하 분산기는 사용 가능한 가장 가까운 리전의 서버리스 NEG로 요청을 전달하여 트래픽을 분산합니다. 그러나 백엔드 서비스는 리전당 서버리스 NEG 하나만 포함할 수 있습니다. 여러 리전에서 Cloud Run 서비스를 사용하려면 리전 간 라우팅을 설정해야 합니다. 전 세계 어디서나 작동하지만 사용자와 가장 가까운 리전의 사용자 요청을 처리하는 단일 URL 스키마를 사용할 수 있어야 합니다.

멀티 리전을 제공하려면 모든 리전 Cloud Run 배포가 호환되고 모든 리전의 트래픽을 처리할 수 있는 프리미엄 네트워크 등급을 사용해야 합니다.

멀티 리전 부하 분산기를 설정하려면 다음 안내를 따르세요.

서로 다른 리전에 2개의 Cloud Run 서비스를 설정합니다. 미국 리전과 유럽 리전에 각각 1개씩 2개의 Cloud Run 서비스를 배포했다고 가정합시다.
다음 설정으로 외부 애플리케이션 부하 분산기를 만듭니다.
1. 서버리스 NEG 2개로 전역 백엔드 서비스를 설정합니다.
  1. 미국에 배포된 Cloud Run 서비스와 동일한 리전에 첫 번째 NEG를 만듭니다.
  2. 유럽에 배포된 Cloud Run 서비스와 동일한 리전에 두 번째 NEG를 만듭니다.
2. 프리미엄 네트워크 서비스 등급으로 프런트엔드 구성을 설정합니다.

다음 다이어그램에 결과 설정이 나와 있습니다.

이 섹션에서는 이 페이지의 앞부분에서 설명한 부하 분산기 설정을 기반으로 합니다. 여기에서는 동일한 리전의 Cloud Run 서비스를 가리키는 us-central1 리전에 하나의 서버리스 NEG를 만들었습니다. 또한 europe-west1 리전에서 두 번째 Cloud Run 서비스를 만들었다고 가정합니다. 만드는 두 번째 서버리스 NEG는 europe-west1 리전의 이 Cloud Run 서비스를 가리킵니다.

이 예시에서는 다음 단계를 완료합니다.

europe-west1 리전에 두 번째 서버리스 NEG를 만듭니다.
두 번째 서버리스 NEG를 백엔드 서비스에 연결합니다.

두 번째 서버리스 NEG를 기존 백엔드 서비스에 추가하려면 다음 단계를 완료합니다.

콘솔

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

부하 분산으로 이동
백엔드 서비스를 수정할 부하 분산기의 이름을 클릭합니다.
부하 분산기 세부정보 페이지에서 수정을 클릭합니다.
전역 외부 애플리케이션 부하 분산기 수정 페이지에서 백엔드 구성을 클릭합니다.
백엔드 구성 페이지에서 수정하려는 백엔드 서비스에 대해 수정 을 클릭합니다.
백엔드 섹션에서 백엔드 추가를 클릭합니다.
서버리스 네트워크 엔드포인트 그룹 목록에서 서버리스 네트워크 엔드포인트 그룹 만들기를 선택합니다.
서버리스 NEG의 이름을 입력합니다.
리전에서 europe-west1을 선택합니다.
서버리스 네트워크 엔드포인트 그룹 유형에 Cloud Run을 선택한 후 다음을 수행합니다.
1. 서비스 선택 옵션을 선택합니다.
2. 서비스 목록에서 부하 분산기를 만들려는 Cloud Run 서비스를 선택합니다.
만들기를 클릭합니다.
새 백엔드 페이지에서 완료를 클릭합니다.
저장을 클릭합니다.
백엔드 서비스를 업데이트하려면 업데이트를 클릭합니다.
부하 분산기를 업데이트하려면 전역 외부 애플리케이션 부하 분산기 수정 페이지에서 업데이트를 클릭합니다.

gcloud

Cloud Run 서비스가 배포된 것과 동일한 리전에서 두 번째 서버리스 NEG를 만듭니다.
```
gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
  --region=europe-west1 \
  --network-endpoint-type=SERVERLESS \
  --cloud-run-service=CLOUD_RUN_SERVICE_2
```
다음을 바꿉니다.
- SERVERLESS_NEG_NAME_2: 두 번째 서버리스 NEG의 이름
- CLOUD_RUN_SERVICE_2: Cloud Run 서비스의 이름
두 번째 서버리스 NEG를 백엔드 서비스에 백엔드로 추가합니다.
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
  --network-endpoint-group-region=europe-west1
```
다음을 바꿉니다.
- BACKEND_SERVICE_NAME: 백엔드 서비스의 이름
- SERVERLESS_NEG_NAME_2: 두 번째 서버리스 NEG의 이름

멀티 리전 Cloud Run 배포에 인증된 Pub/Sub 푸시 구독 사용

인증된 푸시 요청의 경우 Cloud Run은 기본적으로 리전별 대상 필드를 예상합니다. 멀티 리전 Cloud Run 배포의 경우 푸시 요청이 다른 리전의 Cloud Run 서비스로 라우팅되는 경우 대상 불일치로 인해 JWT 토큰 확인이 실패합니다.

이 리전 관련 제한사항을 해결하려면 다음 안내를 따르세요.

다른 리전의 서비스 배포와 동일한 커스텀 대상을 구성합니다.
커스텀 대상을 JWT 토큰의 대상으로 사용하도록 Pub/Sub 푸시 메시지를 구성합니다.

리전 라우팅 설정

여러 리전에서 애플리케이션을 제공하는 일반적인 이유는 데이터 지역 요구사항을 충족하기 위해서입니다. 예를 들어 유럽 사용자의 요청이 항상 유럽에 있는 리전에서 제공되도록 할 수 있습니다. 이를 설정하려면 EU 사용자와 EU 이외의 사용자를 위한 별도의 URL이 있는 URL 스키마가 필요하며 EU 사용자를 EU URL로 안내해야 합니다.

이러한 시나리오에서는 URL 맵을 사용하여 특정 URL의 요청을 해당 리전으로 라우팅합니다. 이렇게 설정하면 한 리전에 대한 요청이 다른 리전으로 전달되지 않습니다. 이렇게 하면 리전 간 격리할 수 있습니다. 반면 리전에 장애가 발생해도 요청이 다른 리전으로 라우팅되지 않습니다. 따라서 이 설정은 서비스의 가용성을 높이지 않습니다.

리전 라우팅을 설정하려면 단일 전달 규칙에서 여러 리전을 결합할 수 있도록 프리미엄 네트워크 등급을 사용해야 합니다.

리전 라우팅을 사용하여 부하 분산기를 설정하려면 다음 안내를 따르세요.

서로 다른 리전에 2개의 Cloud Run 서비스를 설정합니다. 유럽의 리전에 hello-world-eu, 미국 리전에 hello-world-us로 두 개의 Cloud Run 서비스를 배포했다고 가정합니다.
다음 설정으로 외부 애플리케이션 부하 분산기를 만듭니다.
1. 유럽에서 서버리스 NEG를 사용하여 백엔드 서비스를 설정합니다. 서버리스 NEG는 유럽에 배포된 Cloud Run 서비스와 동일한 리전에 만들어야 합니다.
2. 미국에서 다른 서버리스 NEG로 두 번째 백엔드 서비스를 설정합니다. 이 서버리스 NEG는 미국에 배포된 Cloud Run 서비스와 동일한 리전에 생성해야 합니다.
3. 모든 요청이 미국 백엔드 서비스로 라우팅되는 동시에 하나의 URL 집합이 유럽 백엔드 서비스로 라우팅되도록 적절한 호스트 및 경로 규칙을 사용하여 URL 맵을 설정합니다.
4. 프리미엄 네트워크 등급으로 프런트엔드 구성을 설정합니다.

나머지 설정은 이전에 설명한 것과 동일해도 됩니다. 설정 결과는 다음과 같습니다.

URL 마스크 사용

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

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

아직 읽어보지 않았다면 서버리스 NEG 개요: URL 마스크를 읽어보세요.

URL 마스크 구성

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

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

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

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

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

Cloud Run

이 표에서는 example.com이라는 커스텀 도메인이 있고 모든 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>

Cloud Functions

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

함수 이름	커스텀 도메인 URL	URL 마스크
로그인	https://example.com/login	/<function>
로그인	https://example.com/home/login	/home/<function>
로그인	https://login.example.com	<function>.example.com
로그인	https://login.home.example.com	<function>.home.example.com

App Engine

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

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

API 게이트웨이

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

게이트웨이 이름	API 게이트웨이(미리보기) 커스텀 도메인 URL	URL 마스크
로그인	https://example.com/login	/<gateway>
로그인	https://example.com/home/login	/home/<gateway>
로그인	https://login.example.com	<gateway>.example.com
로그인	https://login.home.example.com	<gateway>.home.example.com

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

콘솔

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

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

URL 마스크 기반 서버리스 NEG를 기존 백엔드 서비스에 추가하려면 다음 안내를 따르세요.

Google Cloud 콘솔의 부하 분산 페이지로 이동합니다.
부하 분산 페이지로 이동
백엔드 서비스를 수정할 부하 분산기의 이름을 클릭합니다.
부하 분산기 세부정보 페이지에서 수정 을 클릭합니다.
전역 외부 애플리케이션 부하 분산기 수정 페이지에서 백엔드 구성을 클릭합니다.
백엔드 구성 페이지에서 수정하려는 백엔드 서비스에 대해 수정 을 클릭합니다.
백엔드 추가를 클릭합니다.
서버리스 네트워크 엔드포인트 그룹 만들기를 선택합니다.
1. 이름에 helloworld-serverless-neg을 입력합니다.
2. 리전에서 us-central1을 선택합니다.
3. 서버리스 네트워크 엔드포인트 그룹 유형에서 서버리스 앱(또는 서비스 또는 함수)을 만든 플랫폼을 선택합니다.
  1. URL 마스크 사용을 선택합니다.
  2. URL 마스크를 입력합니다. URL 마스크를 만드는 방법에 대한 자세한 내용은 URL 마스크 구성을 참조하세요.
  3. 만들기를 클릭합니다.
새 백엔드 섹션에서 완료를 클릭합니다.
업데이트를 클릭합니다.

gcloud: Cloud Run

샘플 URL 마스크가 example.com/<service>인 서버리스 NEG를 만들려면 다음 안내를 따르세요.

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

gcloud: Cloud Functions

샘플 URL 마스크가 example.com/<service>인 서버리스 NEG를 만들려면 다음 안내를 따르세요.

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud: App Engine

샘플 URL 마스크가 example.com/<service>인 서버리스 NEG를 만들려면 다음 안내를 따르세요.

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud: API 게이트웨이

샘플 URL 마스크가 example.com/<gateway>인 서버리스 NEG를 만들려면 다음 안내를 따르세요.

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

부하 분산기가 URL 마스크 불일치 문제를 처리하는 방법을 알아 보려면 서버리스 NEG 관련 문제 해결을 참조하세요.

외부 애플리케이션 부하 분산기에서 제공할 커스텀 도메인 이동

서버리스 컴퓨팅 앱이 커스텀 도메인에 매핑되어 있는 경우 기존 Cloud Run, Cloud Functions, API 게이트웨이 또는 App Engine 커스텀 도메인 URL로 전송되는 트래픽이 대신 부하 분산기를 통해 라우팅되도록 DNS 레코드를 업데이트할 수 있습니다.

예를 들어 example.com이라는 커스텀 도메인이 있고 모든 Cloud Run 서비스가 이 도메인에 매핑된 경우 example.com의 DNS 레코드를 업데이트하여 부하 분산기의 IP 주소를 가리켜야 합니다.

DNS 레코드를 업데이트하기 전에 커스텀 도메인의 로컬 DNS 확인을 부하 분산기의 IP 주소로 강제 실행하여 구성을 로컬에서 테스트할 수 있습니다. 로컬에서 테스트하려면 로컬 머신의 /etc/hosts/ 파일을 수정하여 example.com이 부하 분산기의 IP 주소를 가리키도록 하거나 curl --resolve 플래그를 사용하여 curl이 요청에 대한 부하 분산기의 IP를 사용하도록 강제합니다.

example.com의 DNS 레코드가 HTTP(S) 부하 분산기의 IP 주소로 확인되면 example.com으로 전송된 요청이 부하 분산기를 통해 라우팅됩니다. 부하 분산기는 URL 맵에 따라 관련 백엔드 서비스로 요청을 전달합니다. 또한 백엔드 서비스가 URL 마스크로 구성된 경우 서버리스 NEG는 마스크를 사용하여 요청을 적절한 Cloud Run, Cloud Functions, API 게이트웨이 또는 App Engine 서비스로 라우팅합니다.

Cloud CDN 사용 설정

Cloud Run 서비스에 Cloud CDN을 사용하면 사용자에게 가까운 콘텐츠를 캐시하여 콘텐츠 전송을 최적화할 수 있습니다.

gcloud compute backend-services update 명령어를 사용하여 전역 외부 애플리케이션 부하 분산기에서 사용하는 백엔드 서비스에서 Cloud CDN을 사용 설정할 수 있습니다.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN은 Cloud Run, Cloud Functions, API 게이트웨이, App Engine 백엔드가 있는 백엔드 서비스에서 지원됩니다.

외부 애플리케이션 부하 분산기에서 IAP 사용 설정

참고: IAP는 Cloud CDN과 호환되지 않습니다.

IAP를 사용 설정 또는 사용 중지(기본값)하도록 구성할 수 있습니다. 사용 설정된 경우 oauth2-client-id 및 oauth2-client-secret 값을 제공해야 합니다.

IAP를 사용 설정하려면 --iap=enabled 플래그를 oauth2-client-id 및 oauth2-client-secret과 함께 포함하도록 백엔드 서비스를 업데이트하세요.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Google Cloud Armor 사용 설정

Google Cloud Armor는 DDoS 공격으로부터 모든 GCLB 프록시 부하 분산기를 보호하는 보안 제품입니다. Google Cloud Armor는 외부 애플리케이션 부하 분산기를 통해 액세스한 서비스에 구성 가능한 보안 정책도 제공합니다. 외부 애플리케이션 부하 분산기용 Google Cloud Armor 보안 정책에 대한 자세한 내용은 Google Cloud Armor 보안 정책 개요를 참조하세요.

Cloud Functions를 사용하는 경우 internal-and-gclb 인그레스 설정을 사용하여 기본 URL로 전송된 요청이 차단되도록 할 수 있습니다.

Cloud Run을 사용하는 경우 인그레스를 '내부 및 클라우드 부하 분산'으로 제한하여 기본 URL 또는 Cloud Run을 통해 설정된 다른 커스텀 도메인으로 전송된 요청이 차단되도록 할 수 있습니다.

App Engine을 사용하는 경우 인그레스 제어를 사용하여 앱이 부하 분산기(및 사용하는 경우 VPC)에서 전송되는 요청만 수신하도록 할 수 있습니다.

적절한 인그레스 설정이 없으면 사용자는 서버리스 애플리케이션의 기본 URL을 사용하여 부하 분산기를 통해 전달되는 부하 분산기, Google Cloud Armor 보안 정책, SSL 인증서, 비공개 키를 우회할 수 있습니다.

선택사항: 기본 백엔드 보안 정책을 구성합니다. 기본 보안 정책은 사용자가 구성한 기준점을 통해 트래픽을 제한합니다. 기본 보안 정책에 대한 자세한 내용은 비율 제한 개요를 참조하세요.

Google Cloud Armor 기본 보안 정책을 선택 해제하려면 백엔드 보안 정책 목록 메뉴에서 None을 선택합니다.
보안 섹션에서 기본 보안 정책을 선택합니다.
정책 이름 필드에 자동으로 생성된 이름을 사용하거나 보안 정책 이름을 입력합니다.
요청 수 필드에서 기본 요청 수를 수락하거나 1~10,000 사이의 정수를 입력합니다.
간격 필드에서 간격을 선택합니다.
키에 적용 필드에서 모두, IP 주소, X-Forwarded-For IP 주소 값 중 하나를 선택합니다. 이러한 옵션에 대한 자세한 내용은 비율 제한을 위한 클라이언트 식별을 참조하세요.

로깅 및 모니터링 사용 설정

외부 애플리케이션 부하 분산기 백엔드 서비스에 대한 로그를 사용 설정, 사용 중지, 조회할 수 있습니다. Google Cloud 콘솔을 사용하는 경우 서버리스 NEG 백엔드가 있는 백엔드 서비스에 로깅이 기본적으로 사용 설정됩니다. 필요에 따라 gcloud를 사용하여 각 백엔드 서비스의 로깅을 사용 중지할 수 있습니다. 자세한 내용은 Logging을 참조하세요.

또한 부하 분산기는 모니터링 데이터를 Cloud Monitoring으로 내보냅니다. 모니터링 측정항목을 사용하여 부하 분산기의 구성, 사용, 성능을 평가할 수 있습니다. 또한 측정항목을 사용하여 문제를 해결하고 리소스 사용률 및 사용자 환경을 개선하는 데 사용할 수도 있습니다. 자세한 내용은 Monitoring을 참조하세요.

클라이언트 HTTP 연결 유지 제한 시간 업데이트

이전 단계에서 만든 부하 분산기는 클라이언트 HTTP 연결 유지 제한 시간의 기본값으로 구성되었습니다. 클라이언트 HTTP 연결 유지 제한 시간을 업데이트하려면 다음 안내를 따르세요.

콘솔

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

부하 분산으로 이동
수정할 부하 분산기의 이름을 클릭합니다.
수정을 클릭합니다.
프런트엔드 구성을 클릭합니다.
고급 기능을 펼칩니다. HTTP 연결 유지 제한 시간에 제한 시간 값을 5~1,200초로 입력합니다.
업데이트를 클릭합니다.
변경사항을 검토하려면 검토 및 완료를 클릭한 다음 업데이트를 클릭합니다.

gcloud

HTTP 부하 분산기의 경우 gcloud compute target-http-proxies update 명령어를 사용하여 대상 HTTP 프록시를 업데이트합니다.

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

HTTPS 부하 분산기의 경우 gcloud compute target-https-proxies update 명령어를 사용하여 대상 HTTPS 프록시를 업데이트합니다.

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global

다음을 바꿉니다.

TARGET_HTTP_PROXY_NAME: 대상 HTTP 프록시의 이름입니다.
TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시의 이름입니다.
HTTP_KEEP_ALIVE_TIMEOUT_SEC: HTTP 연결 유지 제한 시간 값은 5~1,200초 사이입니다.

이상점 감지 사용 설정

전역 백엔드 서비스에 이상점 감지를 사용 설정하여 비정상 서버리스 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을 백엔드 서비스 이름으로 바꿉니다.
outlierDetection 섹션에서 백엔드 서비스의 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가 현재 사용 중인 경우:
1. 서버리스 NEG를 사용하는 백엔드 서비스의 이름을 클릭합니다.
2. 수정 을 클릭합니다.
3. 백엔드 목록에서 를 클릭하여 백엔드 서비스에서 서버리스 NEG 백엔드를 삭제합니다.
4. 저장을 클릭합니다.
Google Cloud 콘솔의 네트워크 엔드포인트 그룹 페이지로 이동합니다.
네트워크 엔드포인트 그룹 페이지로 이동
삭제할 서버리스 NEG의 체크박스를 선택합니다.
삭제를 클릭합니다.
삭제를 다시 클릭하여 확인합니다.

gcloud

백엔드 서비스에서 서버리스 NEG를 삭제하려면 NEG가 생성된 리전을 지정해야 합니다. helloworld-backend-service는 전역 리소스이므로 --global 플래그도 지정해야 합니다.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

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

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1