여러 리전의 트래픽 제공

전 세계 사용자에게 더 빠르게 응답을 반환하려면 여러 리전에 서비스를 배포하고 사용자를 가장 가까운 리전으로 라우팅해야 합니다.

하지만 Cloud Run(완전 관리형) 서비스는 개별 리전에 배포됩니다. 사용자를 서비스의 다른 리전으로 라우팅하려면 외부 HTTP(S) 부하 분산을 구성해야 합니다.

이 가이드에서는 외부 HTTP(S) 부하 분산기를 전역 Anycast IP 주소(서비스가 배포된 가장 가까운 Google 데이터 센터로 사용자를 라우팅함)를 가리키면서 관리형 TLS 인증서를 사용하여 보호되는 도메인과 함께 구성하는 방법을 보여줍니다.

시작하기 전에

부하 분산기 만들기

외부 부하 분산기를 만들려면 다음 안내에 따라 다양한 네트워킹 리소스를 만들고 서로 연결해야 합니다.

명령줄

  1. 부하 분산기를 다시 만들 때 DNS 레코드를 업데이트할 필요가 없도록 고정 IP 주소를 예약합니다.
    gcloud compute addresses create --global SERVICE_IP
    위의 명령어에서 SERVICE_IP를 IP 주소 리소스 이름(예: myservice-ip)으로 바꿉니다.

    이 IP 주소는 Google 데이터 센터 또는 방문자와 가장 가까운 접속 지점으로 라우팅하는 전역 Anycast IPv4 주소입니다.

  2. 백엔드 서비스를 만듭니다.
    gcloud compute backend-services create --global BACKEND_NAME

    위 명령어에서 BACKEND_NAME를 백엔드 서비스에 지정할 이름으로 바꿉니다(예: myservice-backend).

  3. URL 맵을 만듭니다.
    gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME

    URLMAP_NAME을 URL 맵에 지정할 이름으로 바꿉니다(예: myservice-urlmap).

  4. 도메인에서 HTTPS 트래픽을 제공하도록 관리형 TLS 인증서를 만듭니다. example.com을 도메인 이름으로 바꿉니다.
    gcloud beta compute ssl-certificates create CERT_NAME \
      --domains=example.com

    CERT_NAME을 관리형 SSL 인증서에 사용할 이름으로 바꿉니다(예: myservice-cert).

  5. 대상 HTTPS 프록시를 만듭니다.
    gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
      --ssl-certificates=CERT_NAME \
      --url-map=URLMAP_NAME

    HTTPS_PROXY_NAME을 대상 HTTPS 프록시에 지정할 이름으로 바꿉니다(예: myservice-https).

  6. 생성한 네트워킹 리소스를 IP 주소에 연결하는 전달 규칙을 만듭니다.
    gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \
      --target-https-proxy=HTTPS_PROXY_NAME \
      --address=SERVICE_IP \
      --ports=443

    FORWARDING_RULE_NAME을 만들려는 전달 규칙 리소스의 이름으로 바꿉니다(예: myservice-lb).

여러 리전에 배포

사용 가능한 Cloud Run(완전 관리형) 리전에 서비스를 배포합니다. 손쉬운 관리를 위해 여러 리전에서 동일한 서비스 이름을 사용할 수 있습니다.

  1. 서비스를 사용할 리전을 선택합니다.

  2. Cloud Run 서비스를 개별 리전에 배포합니다.

      gcloud run deploy SERVICE_NAME \
          --platform=managed \
          --allow-unauthenticated \
          --image=IMAGE_URL \
          --region=REGION
    

    다음 변수를 바꿉니다.

    • REGION을 배포할 리전 중 하나로 바꿉니다.
    • SERVICE_NAME을 서비스 이름으로 바꿉니다. 여러 리전에서 동일한 서비스 이름을 사용하면 멀티 리전 배포를 더 쉽게 추적할 수 있습니다.
    • IMAGE_URL을 컨테이너 이미지에 대한 참조(예: gcr.io/myproject/my-image:latest)로 바꿉니다.
  3. 각 리전에 대해 이전 단계를 반복합니다.

Cloud Run 위치

Cloud Run은 리전을 기반으로 합니다. 즉, Cloud Run 서비스를 실행하는 인프라가 특정 리전에 위치해 있으며 해당 리전 내의 모든 영역에서 중복으로 사용할 수 있도록 Google이 관리합니다.

Cloud Run 서비스를 실행하는 리전을 선택하는 데 있어 중요한 기준은 지연 시간, 가용성 또는 내구성 요구사항입니다. 일반적으로 사용자와 가장 가까운 리전을 선택할 수 있지만 Cloud Run 서비스에서 사용하는 다른 Google Cloud 제품 위치도 고려해야 합니다. 여러 위치에서 Google Cloud 제품을 함께 사용하면 서비스 지연 시간과 비용에 영향을 미칠 수 있습니다.

Cloud Run은 다음 리전에서 사용할 수 있습니다.

등급 1 가격 적용

  • asia-east1(타이완)
  • asia-northeast1(도쿄)
  • asia-northeast2(오사카)
  • europe-north1(핀란드)
  • europe-west1(벨기에)
  • europe-west4(네덜란드)
  • us-central1(아이오와)
  • us-east1(사우스캐롤라이나)
  • us-east4(북 버지니아)
  • us-west1(오리건)

등급 2 가격 적용

  • asia-east2(홍콩)
  • asia-northeast3(대한민국 서울)
  • asia-southeast1(싱가포르)
  • asia-southeast2 (자카르타)
  • asia-south1(인도 뭄바이)
  • australia-southeast1(시드니)
  • europe-west2(영국 런던)
  • europe-west3(독일 프랑크푸르트)
  • europe-west6(스위스 취리히)
  • northamerica-northeast1(몬트리올)
  • southamerica-east1(브라질 상파울루)

Cloud Run 서비스를 이미 만들었다면 Cloud Console의 Cloud Run 대시보드에서 리전을 확인할 수 있습니다.

리전 백엔드 구성

이전 단계에서 배포한 각 리전에 대해 다음 안내에 따라 서버리스 네트워크 엔드포인트 그룹(NEG)을 만들고 백엔드 서비스에 추가해야 합니다.

  1. REGION에서 Cloud Run(완전 관리형) 서비스의 네트워크 엔드포인트 그룹을 만듭니다.

    gcloud beta compute network-endpoint-groups create NEG_NAME \
        --region=REGION \
        --network-endpoint-type=SERVERLESS \
        --cloud-run-service=SERVICE_NAME 

    위의 명령어에서 다음과 같이 바꿉니다.

    • NEG_NAME을 네트워크 엔드포인트 그룹 리소스의 이름으로 바꿉니다 (예: myservice-neg-uscentral1).
    • REGION을 서비스가 배포된 리전으로 바꿉니다.
    • SERVICE_NAME을 서비스 이름으로 바꿉니다.
  2. 백엔드 서비스에 네트워크 엔드포인트 그룹을 추가합니다.

    gcloud beta compute backend-services add-backend --global BACKEND_NAME \
        --network-endpoint-group-region=REGION \
        --network-endpoint-group=NEG_NAME

    이전 단계에서 만든 리전의 NEG_NAME을 지정합니다.

  3. 각 리전에 대해 위의 단계를 반복합니다.

도메인에 DNS 레코드 구성

도메인 이름이 앞에서 만든 전달 규칙을 가리키도록 하려면 앞에서 만든 IP 주소를 사용하여 DNS 레코드를 업데이트해야 합니다.

  1. 다음을 실행하여 부하 분산기의 예약된 IP 주소를 찾습니다.

      gcloud compute addresses describe --global SERVICE_IP --format='value(address)'

    SERVICE_IP를 이전에 만든 IP 주소의 이름으로 바꿉니다. 이 명령어는 IP 주소를 출력에 인쇄합니다.

  2. 이 IP 주소로 A 레코드를 추가하여 도메인의 DNS 레코드를 업데이트합니다.

부하 분산기 프로비저닝 대기 중

부하 분산기 IP 주소로 도메인을 구성한 후 DNS 레코드가 적용될 때까지 기다려야 합니다. 마찬가지로 도메인에서 관리형 TLS 인증서가 발급될 때까지 기다린 후 HTTPS 트래픽을 전역적으로 제공할 준비를 해야 합니다.

부하 분산기가 트래픽을 제공하기까지 데 최대 30분이 걸릴 수 있습니다.

준비가 되면 https:// 프리픽스가 있는 웹사이트의 URL을 방문하여 직접 사용해 보세요.

상태 확인

  1. DNS 레코드 전파의 상태를 확인하려면 dig 명령줄 유틸리티를 사용합니다.

    dig A +short example.com

    출력에 DNS 레코드에서 구성한 IP 주소가 표시됩니다.

  2. 관리형 인증서 발급 상태를 확인하고 다음 명령어를 실행합니다.

    gcloud beta compute ssl-certificates describe CERT_NAME

    CERT_NAME을 이전에 SSL 인증서 리소스에 대해 선택한 이름으로 바꿉니다.

    출력에 status: ACTIVE가 포함된 줄이 표시됩니다.

HTTP에서 HTTPS로 리디렉션 설정

기본적으로 전달 규칙은 단일 프로토콜만 처리하므로 http:// 엔드포인트에 대한 요청은 404 Not Found로 응답합니다. http:// URL에 대한 요청을 https:// 프로토콜로 리디렉션해야 하는 경우 다음 안내에 따라 추가 URL 맵 및 전달 규칙을 만들어야 합니다.

  1. 리디렉션 규칙을 사용하여 URL 맵을 만듭니다.

    gcloud compute url-maps import HTTP_URLMAP_NAME \
        --global \
        --source /dev/stdin <<EOF
    name: HTTP_URLMAP_NAME
    defaultUrlRedirect:
      redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
      httpsRedirect: True
    EOF

    HTTP_URLMAP_NAME을 만들려는 URL 맵 리소스의 이름으로 바꿉니다(예: myservice-httpredirect).

  2. URL 맵을 사용하여 대상 HTTP 프록시를 만듭니다.

    gcloud compute target-http-proxies create HTTP_PROXY_NAME \
      --url-map=HTTP_URLMAP_NAME

    HTTP_PROXY_NAME을 만들려는 대상 HTTP 프록시의 이름으로 바꿉니다(예: myservice-http).

  3. 포트 80에 예약된 IP 주소가 동일한 전달 규칙을 만듭니다.

    gcloud compute forwarding-rules create --global HTTP_FORWARDING_RULE_NAME \
      --target-http-proxy=HTTP_PROXY_NAME \
      --address=SERVICE_IP \
      --ports=80
    

    HTTP_FORWARDING_RULE_NAME을 만들려는 새 전달 규칙의 이름으로 바꿉니다(예: myservice-httplb).