API 게이트웨이용 HTTP(S) 부하 분산 시작하기

이 튜토리얼에서는 Google Cloud HTTP(S) 외부 부하 분산기를 사용해서 API 게이트웨이로 요청을 라우팅하는 방법을 보여줍니다. 이 구성 프로세스에서는 Cloud Run, Cloud Functions, App Engine과 같은 다른 서버리스 제품으로 Cloud Load Balancing 통합을 구성할 때와 동일한 단계를 수행합니다.

API 게이트웨이가 작동하는 데 부하 분산기가 필요하지 않으면 게이트웨이가 Cloud Load Balancing의 여러 이점을 활용할 수 없습니다. 예를 들어 API 게이트웨이에 Cloud Load Balancing을 사용하면 다음을 수행할 수 있습니다.

커스텀 도메인을 사용합니다.
Google Cloud Armor를 네트워크 보안 서비스로 활용합니다.
여러 위치의 게이트웨이에서 효율적인 부하 분산을 관리합니다.
고급 트래픽 관리를 구현합니다.

시작하기 전에

아직 수행하지 않았으면 Google Cloud CLI를 다운로드하고 설치합니다.
gcloud CLI 다운로드
gcloud 구성요소를 업데이트합니다.
```
gcloud components update
```
API 게이트웨이 빠른 시작에 따라 Cloud Run 서비스를 배포하고 이 서비스를 가리키는 게이트웨이를 만듭니다.
권한 구성
SSL 인증서 리소스 추가

Cloud Run 서비스 및 API 게이트웨이 인스턴스 배포

이 튜토리얼에서는 'hello-world' 서비스를 Cloud Run에 배포하고, Cloud Run 서비스로 라우팅되는 게이트웨이를 만들고, 커스텀 도메인으로 요청을 라우팅하도록 HTTP(S) 부하 분산기를 구성합니다.

이 튜토리얼에서는 API 게이트웨이의 백엔드 서비스로 Cloud Run이 사용되지만 API 게이트웨이에서 현재 지원되는 모든 백엔드 서비스에도 이 단계가 적용됩니다.

API 게이트웨이 빠른 시작을 성공적으로 완료했으면 Cloud Run 서비스를 가리키는 배포된 게이트웨이 URL을 사용할 수 있습니다.

권한 구성

이 튜토리얼에서는 서버리스 네트워크 엔드포인트 그룹(NEG)을 만들고 클라우드 프로젝트에 외부 HTTP(S) 부하 분산기를 만듭니다. 이를 위해서는 프로젝트 소유자 또는 편집자 역할이나 다음 Compute Engine IAM 역할이 필요합니다.

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

SSL 인증서 리소스 만들기

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

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

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

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

HTTP(S) 부하 분산기 만들기

API 게이트웨이에 대해 서버리스 NEG를 만듭니다.

네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드 엔드포인트 그룹을 지정합니다. 서버리스 NEG는 아래 그림에 표시된 것처럼 API 게이트웨이와 같은 서비스를 가리키는 백엔드입니다.

게이트웨이에 대해 서버리스 NEG를 만들려면 다음 명령어를 실행합니다. 각 항목의 의미는 다음과 같습니다.
- SERVERLESS_NEG_NAME은 만들려는 서버리스 NEG의 이름입니다.
- GATEWAY_ID는 게이트웨이의 이름을 지정합니다.
- REGION_ID는 서버리스 NEG의 배포 리전입니다(게이트웨이 리전과 일치해야 함).
```
gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
예를 들면 다음과 같습니다.
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway
```
백엔드 서비스를 만들어 Cloud Load Balancing의 트래픽 분산 방법을 정의합니다.

아래 그림에 표시된 것처럼 백엔드 서비스 구성에는 백엔드에 연결하는 데 사용되는 프로토콜, 다양한 배포 및 세션 설정, 상태 확인, 제한 시간 등의 다양한 값 집합이 포함됩니다.

백엔드 서비스를 만들려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services create BACKEND_SERVICE_NAME --global
```
여기서 BACKEND_SERVICE_NAME은 새 백엔드 서비스의 이름입니다.

예를 들면 다음과 같습니다.
```
gcloud compute backend-services create api-gateway-backend-service --global
```
서버리스 NEG를 백엔드 서비스에 대한 백엔드로 추가하려면 다음 명령어를 실행합니다. 각 항목에 대한 설명은 다음과 같습니다.
- BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.
- SERVERLESS_NEG_NAME은 이전 단계에서 만든 서버리스 NEG의 이름입니다.
- REGION_ID는 서버리스 NEG의 배포 리전입니다(게이트웨이 리전과 일치해야 함).
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID
```
예를 들면 다음과 같습니다.
```
gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg \
  --network-endpoint-group-region=us-central1
```
아래 그림에 표시된 것처럼 수신되는 요청을 백엔드 서비스로 라우팅하도록 URL 맵을 만듭니다.

URL 맵을 만들려면 다음 명령어를 실행합니다. 각 항목의 의미는 다음과 같습니다.
- URL_MAP_NAME은 만들려는 URL 맵의 이름입니다.
- BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
예를 들면 다음과 같습니다.
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
이 예시 URL 맵은 단일 게이트웨이를 나타내는 하나의 백엔드 서비스만 대상으로 하므로, 호스트 규칙 또는 경로 일치자가 필요하지 않습니다. 백엔드 서비스가 2개 이상 있으면 호스트 규칙을 사용해서 호스트 이름에 따라 요청을 다른 서비스로 전달할 수 있습니다. 경로 일치자를 사용해서 요청 경로에 따라 요청을 다른 서비스로 전달합니다.

예를 들면 다음과 같습니다.
```
gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2  \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
```
```
gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher
```
호스트 규칙 및 경로 일치자에 대한 자세한 내용은 URL 맵 문서를 참조하세요.
아래 그림에 표시된 것처럼 대상 프록시에 대해 SSL 인증서를 만듭니다.

HTTP(S) 부하 분산기를 만들려면 HTTP(S) 대상 프록시에 대해 SSL 인증서 리소스가 필요합니다. Google 관리형 SSL 인증서 또는 자체 관리형 SSL 인증서를 사용하여 SSL 인증서 리소스를 만들 수 있습니다. Google 관리 인증서를 사용하는 것이 좋습니다. SSL 인증서 리소스 없이 이 프로세스를 테스트할 때 HTTP 부하 분산기를 설정하려면 이 단계를 건너뛸 수 있습니다.

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 프록시를 만들어 URL 맵에 요청을 라우팅합니다.

대상 프록시를 만들려면 다음 명령어를 사용합니다. 각 항목의 의미는 다음과 같습니다.
- TARGET_HTTPS_PROXY_NAME은 만들려는 대상 HTTP(S) 프록시의 이름입니다.
- URL_MAP_NAME은 이전 단계에서 만든 URL 맵의 이름입니다.
- 선택사항: SSL_CERT_NAME은 생성된 SSL 인증서의 이름입니다.
```
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME \
  --url-map=URL_MAP_NAME
```
예를 들면 다음과 같습니다.
```
gcloud compute target-https-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert \
  --url-map=api-gateway-url-map
```
위에 설명된 것처럼 SSL 인증서 리소스를 만들지 않고 HTTP 부하 분산기를 만들 수 있습니다. 이렇게 하려면 다음 명령어를 사용합니다.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME
```
예를 들면 다음과 같습니다.
```
gcloud compute target-http-proxies create api-gateway-http-proxy \
  --url-map=api-gateway-url-map
```
HTTP 프록시에 대해 다음 명령어를 적용하려면 --target-http-proxy 플래그를 포함하고 해당 HTTP(S)에 대해 TARGET_HTTP_PROXY_NAME을 사용해야 합니다.
아래 그림에 표시된 것처럼 수신 요청을 프록시로 라우팅하는 전달 규칙을 만듭니다.

다음 명령어를 사용해서 전달 규칙을 만듭니다. 각 항목의 의미는 다음과 같습니다.
- HTTPS_FORWARDING_RULE_NAME은 만들려는 규칙의 이름입니다.
- TARGET_HTTPS_PROXY_NAME은 HTTP(S) 대상 프록시의 이름입니다.
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
예를 들면 다음과 같습니다.
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

부하 분산기 IP 주소로 DNS 레코드 업데이트

커스텀 도메인이 있는 경우 서비스의 새 IP 주소를 가리키도록 도메인의 DNS 설정을 지정하기 위해 이 단계가 필요합니다. 또한 Google 관리형 인증서(도메인 필요)로 HTTP(S) 부하 분산기를 만든 경우에도 필요합니다. DNS와 함께 사용될 때는 고정 IP 주소를 할당하고 사용하는 것이 좋습니다. 이 단계의 세부 안내는 DNS 제공업체에 따라 달라집니다.

부하 분산기로 트래픽을 보내려면 도메인의 DNS 레코드(이 튜토리얼에서는 my-app-domain)가 부하 분산기의 IP 주소를 가리켜야 합니다.

전역 전달 규칙의 IP 주소를 찾으려면 다음 명령어를 사용합니다.
```
gcloud compute forwarding-rules list
```
기존 커스텀 도메인 URL로 전송된 트래픽이 대신 부하 분산기를 통해 라우팅되도록 부하 분산기의 IP 주소를 가리키도록 도메인의 DNS A 또는 AAAA 레코드를 업데이트합니다. 이 변경사항이 DNS 서버에 전달되려면 짧게는 몇 초부터 길게는 몇 시간까지 걸릴 수 있습니다.
curl을 사용해서 또는 브라우저에서 URL을 방문하여 게이트웨이가 트래픽을 수신하는지 확인합니다. 예를 들면 https://my-app-domain입니다.

테스트 후에는 Cloud Run 서비스로 생성된 응답이 표시됩니다. 예를 들어 'Hello World' HTML 페이지이거나 백엔드 서비스에서 직접 생성된 다른 예상 응답일 수 있습니다. 즉, 요청이 부하 분산기를 통과하고, 백엔드 서비스가 게이트웨이로 전송하도록 부하 분산기를 설정합니다.

부하 분산기 구성 테스트

부하 분산기를 구성했으므로 전달 규칙의 IP 주소로 트래픽을 전송할 수 있습니다.

전역 전달 규칙의 IP 주소를 찾으려면 다음 명령어를 사용합니다.

gcloud compute forwarding-rules list

curl 명령어를 사용하여 서비스의 여러 URL에 대한 응답을 테스트합니다. 예를 들면 다음과 같습니다.

curl https://HOST_URL/hello/

curl https://HOST_URL

API 게이트웨이 Cloud Console을 사용하여 요청이 올바른 서비스에 연결되는지 확인할 수 있습니다.

수고하셨습니다. API 게이트웨이용 HTTP(S) 부하 분산^미리보기이 성공적으로 구성되었습니다.

삭제

이 빠른 시작에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 생성된 Cloud Load Balancing 리소스를 삭제하면 됩니다. 이러한 리소스를 자체 프로젝트 내에 만든 경우 전체 프로젝트를 삭제할 수 있습니다. 그렇지 않은 경우 리소스를 개별적으로 삭제할 수 있습니다.

프로젝트 삭제

PROJECT_ID를 프로젝트 ID로 바꾸고 다음 명령어를 실행합니다.

gcloud projects delete PROJECT_ID

개별 리소스 삭제

부하 분산기에서 각 구성요소를 삭제합니다.

전달 규칙을 삭제합니다.

gcloud compute forwarding-rules delete HTTPS_FORWARDING_RULE_NAME --global

전역 외부 IP 주소를 삭제합니다.

gcloud compute addresses delete IP_ADDRESSES --global

대상 프록시를 삭제합니다.

gcloud compute target-https-proxies delete TARGET_HTTP_PROXY_NAME

URL 맵을 삭제합니다.

gcloud compute url-maps delete URL_MAP_NAME

백엔드 서비스를 삭제합니다.

gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

(선택사항) SSL 인증서를 삭제합니다.

gcloud compute ssl-certificates delete SSL_CERTIFICATE_NAME

서버리스 NEG를 삭제합니다.

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