API 게이트웨이의 멀티 리전 배포 만들기

이 튜토리얼에서는 API 게이트웨이에 대해 멀티 리전 배포를 사용 설정하도록 HTTP(S) 부하 분산기를 구성하는 방법을 보여줍니다.

API 게이트웨이의 멀티 리전 배포를 지원하도록 HTTP(S) 부하 분산기를 만들면 두 개 이상의 리전을 사용해서 서비스의 가용성을 높이고 지연 시간을 줄일 수 있습니다. 또한 사용자에게 가장 가까운 리전에서 요청을 처리하는 리전 간 라우팅 기능으로 지연 시간을 최소화하고 업타임을 극대화할 수 있습니다.

이 튜토리얼에서는 전 세계 어디에서든 작동하지만 가장 가까운 API 게이트웨이 배포에서 사용자 요청을 처리하는 단일 비리전 URL 스킴을 구성합니다. 이 구성을 사용하면 이상적으로 사용자에 대한 지연 시간이 가장 낮은 리전으로 요청이 라우팅됩니다. 가장 가까운 리전을 사용할 수 없거나 용량이 초과된 경우에는 가용성 보장을 위해 다른 리전으로 요청이 라우팅됩니다.

시작하기 전에

멀티 리전 배포를 구성하려면 먼저 API 게이트웨이 빠른 시작에 따라 Cloud Run 서비스를 배포하고 이 서비스를 가리키는 게이트웨이를 만듭니다.

이 튜토리얼에서는 서비스를 2개의 서로 다른 리전에 배포합니다. 예를 들어 다음 2개의 API 게이트웨이 인스턴스를 배포할 수 있습니다.

my-gateway-eu를 유럽 리전에 배포
my-gateway-us를 미국 리전에 배포

권한 구성

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

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

SSL 인증서 리소스 만들기

HTTPS 부하 분산기를 만들려면 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-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway-eu
```
이 명령어를 반복하여 두 번째 게이트웨이 인스턴스에 대해 적절한 값을 사용해서 다음 게이트웨이 인스턴스에 대해 서버리스 NEG를 만듭니다. 예를 들어 us-central1 리전에서 my-gateway-us에 대해 api-gateway-serverless-neg-us를 사용합니다.
백엔드 서비스를 만들어 Cloud Load Balancing의 트래픽 분산 방법을 정의합니다.

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

백엔드 서비스를 만들고 서버리스 NEG를 백엔드 서비스에 백엔드로 추가하려면 다음 명령어를 실행합니다. 각 항목의 의미는 다음과 같습니다.
- BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.
- SERVERLESS_NEG_NAME은 이전 단계에서 만든 서버리스 NEG의 이름입니다.
- REGION_ID는 서버리스 NEG의 배포 리전입니다(게이트웨이 리전과 일치해야 함).
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --global \ 
```
```
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-eu \
  --network-endpoint-group-region=europe-west1
```
이 명령어를 반복하여 두 번째 서버리스 NEG에 대해 적합한 값을 사용해서 두 번째 서버리스 NEG를 백엔드 서비스에 추가합니다. 예를 들어 us-central1 리전에서 my-gateway-us에 대해 api-gateway-serverless-neg-us를 사용합니다.
아래 그림에 표시된 것처럼 수신되는 요청을 백엔드 서비스로 라우팅하도록 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 인증서를 만듭니다.

HTTPS 부하 분산기를 만들려면 HTTPS 대상 프록시에 대해 SSL 인증서 리소스가 필요합니다. Google 관리형 SSL 인증서 또는 자체 관리형 SSL 인증서를 사용하여 SSL 인증서 리소스를 만들 수 있습니다. 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 프록시를 만들어 URL 맵에 요청을 라우팅합니다.

대상 프록시를 만들려면 다음 명령어를 사용합니다. 각 항목의 의미는 다음과 같습니다.
- TARGET_HTTP_PROXY_NAME은 만들려는 대상 프록시의 이름입니다.
- URL_MAP_NAME은 이전 단계에서 만든 URL 맵의 이름입니다.
- 선택사항: SSL_CERT_NAME은 생성된 SSL 인증서의 이름입니다.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
예를 들면 다음과 같습니다.
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
아래 그림에 표시된 것처럼 수신 요청을 프록시로 라우팅하는 전달 규칙을 만듭니다.

다음 명령어를 사용해서 전달 규칙을 만듭니다. 각 항목의 의미는 다음과 같습니다.
- HTTPS_FORWARDING_RULE_NAME은 만들려는 규칙의 이름입니다.
- TARGET_HTTP_PROXY_NAME은 만들려는 대상 프록시의 이름입니다.
```
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 페이지이거나 백엔드 서비스에서 직접 생성된 다른 예상 응답일 수 있습니다. 즉, 요청이 부하 분산기를 통과하고, 백엔드 서비스가 게이트웨이로 전송하도록 부하 분산기를 설정합니다.

고려사항

API 게이트웨이의 멀티 리전 배포를 구현하려면 먼저 다음을 고려하세요.

API 게이트웨이는 현재 상태 확인을 지원하지 않습니다. 위에 설명된 리전 간 라우팅 구성을 사용할 때 게이트웨이 또는 백엔드 서비스가 한 리전에서 오류를 반환하지만 해당 리전의 API 게이트웨이 인프라는 전반적으로 사용 가능한 상태이고 용량이 있으면 HTTP(S) 부하 분산기가 트래픽을 다른 리전으로 전달하지 않습니다.
단일 전달 규칙에 여러 리전을 결합하려면 프리미엄 등급 가격 책정이 필요합니다. 가격 책정 및 사용량 계산에 대한 자세한 내용은 네트워크 서비스 등급 가격 책정을 참조하세요.

권장사항

멀티 리전 서비스를 사용할 때는 Cloud Spanner와 같은 전역적으로 복제되는 관리형 데이터 스토리지를 사용해서 모든 데이터가 전역적으로 관리되는지 확인하는 것이 좋습니다.