요청 라우팅 방식

리전 ID

REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google에서 할당하는 축약된 코드입니다. 일부 리전 ID는 일반적으로 사용되는 국가 및 주/도 코드와 비슷하게 표시될 수 있지만 코드는 국가 또는 주/도와 일치하지 않습니다. 2020년 2월 이후에 생성된 앱의 경우 REGION_ID.r이 App Engine URL에 포함됩니다. 이 날짜 이전에 만든 기존 앱의 경우 URL에서 리전 ID는 선택사항입니다.

리전 ID에 대해 자세히 알아보세요.

이 페이지에서는 사용자의 HTTP 요청이 적합한 서비스 버전에 도달하는지에 대해 설명합니다. 요청은 다음 방법으로 라우팅될 수 있습니다.

URL을 사용한 라우팅
디스패치 파일을 사용한 라우팅
Cloud Load Balancing으로 라우팅

이러한 옵션은 배포된 앱에만 적용됩니다. 로컬에서 테스트할 때는 사용 중인 특정 런타임 및 개발 환경에 따라 라우팅 동작이 달라집니다.

기존 번들 서비스를 사용하여 로컬 개발 서버로 앱을 테스트하는 경우 사용 가능한 라우팅과 디스패치 기능은 약간 다릅니다. 프로덕션 서버와 개발 서버 모두에서 작동하는 URL을 프로그래매틱 방식으로 만들려면 get_hostname 메서드. 자세한 내용은 개발 서버에서 라우팅을 참조하세요.

URL을 사용한 라우팅

App Engine에서 앱이 실행되면 다음 URL을 사용하여 앱에 HTTP 요청을 보낼 수 있습니다.

https://PROJECT_ID.REGION_ID.r.appspot.com

여기서 PROJECT_ID는 앱이 포함된 Google Cloud 프로젝트의 ID입니다.

이 URL은 트래픽을 수신하도록 구성한 버전의 앱 기본 서비스로 요청을 전송합니다.

서비스 및 버전의 URL

앱에서 서비스를 두 개 넘게 만드는 경우 서비스마다 자체 URL이 있습니다. 각 서비스 버전에도 자체 URL이 있으므로 새 버전을 배포하고 테스트한 후에 이 버전에서 트래픽을 수신하도록 구성할 수 있습니다.

특정 서비스 및 버전의 URL 형식은 다음과 같습니다.

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

특정 버전을 타겟팅할 필요가 없으면 VERSION-dot-를 생략할 수 있습니다.

앱 서비스 및 버전의 ID를 검색하려면 다음과 같은 도구를 사용하면 됩니다.

콘솔

Google Cloud 콘솔에서 해당 인스턴스, 서비스, 버전 페이지를 볼 수 있습니다.

gcloud

gcloud app instances list 명령어를 실행하여 특정 Google Cloud 프로젝트의 리소스 ID를 나열합니다.

API

리소스 ID를 프로그래매틱 방식으로 검색하려면 Admin API의 list메서드를 참조하세요.

예시 URL

다음은 App Engine이 앱에 할당하는 appspot.com 도메인과 앱에 설정할 수 있는 커스텀 도메인을 모두 보여주는 App Engine의 URL 예시입니다.

default 서비스의 사용 가능한 인스턴스로 요청을 보냅니다.
```
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN
```
default 서비스에서 트래픽에 대해 구성된 모든 버전에서 요청을 수신합니다.
특정 서비스의 사용 가능한 인스턴스로 요청을 보냅니다.
```
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN
```
타겟팅 서비스에서 트래픽에 대해 구성된 모든 버전에서 요청을 수신합니다. 타겟팅하는 서비스가 없으면 요청이 소프트 라우팅됩니다.
요청을

default 서비스에서 특정 버전의 사용 가능한 인스턴스로 보냅니다.
```
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN
```
서비스가 타겟팅되지 않았다면 default 서비스로 요청이 전송됩니다.

소프트 라우팅

호스트 이름의 PROJECT_ID.REGION_ID.r.appspot.com 부분과 일치하지만 존재하지 않는 서비스, 버전 또는 인스턴스 이름이 포함된 요청은 default 서비스로 라우팅됩니다. 소프트 라우팅은 커스텀 도메인에는 적용되지 않습니다. 호스트 이름이 잘못된 경우 커스텀 도메인을 요청하면 HTTP 404 상태 코드가 반환됩니다.

타겟팅된 라우팅

다음 URL 패턴은 항상 타겟에 도달합니다(타겟이 있는 경우). 이러한 요청은 디스패치 파일에 정의된 패턴으로 가로채기되거나 다시 라우팅되지 않습니다.

요청을 특정 서비스 및 버전의 사용 가능한 인스턴스로 보냅니다.


https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

수동 확장 서비스를 사용하면 인스턴스 ID를 포함하여 인스턴스를 타겟팅하고 인스턴스에 요청을 전송할 수 있습니다. 인스턴스 ID는 0부터 실행 중인 인스턴스의 총 개수까지의 범위에 있는 정수이며 다음과 같이 지정할 수 있습니다.

특정 인스턴스의 특정 서비스 및 버전에 요청을 전송합니다.
```
https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN
```
참고: 자동 확장 또는 기본 확장으로 구성된 서비스에서는 인스턴스 타겟팅이 지원되지 않습니다. 인스턴스 ID는 0부터 실행 중인 총 인스턴스 수까지의 범위에 해당되는 정수여야 합니다. 확장 유형 또는 인스턴스 클래스에 상관없이 인스턴스의 서비스 또는 버전을 타겟팅하지 않고는 특정 인스턴스에 요청을 전송할 수 없습니다.

디스패치 파일을 사용한 라우팅

디스패치 파일을 만들어 App Engine의 URL 기반 라우팅 규칙을 재정의하고 자체 커스텀 라우팅 규칙을 정의할 수 있습니다. 디스패치 파일을 사용하면 요청 URL의 경로 또는 호스트 이름에 따라 수신 요청을 특정 서비스로 보낼 수 있습니다.

디스패치 파일 만들기

디스패치 파일을 만들려면 다음을 수행합니다.

다른 구성 파일(예: app.yaml)에 사용된 디렉터리와 동일한 디렉터리에 dispatch.yaml는 프로젝트 디렉터리의 루트 또는 default 서비스의 루트 디렉터리에 있습니다.
dispatch.yaml 참조의 설명대로 파일에서 라우팅 규칙을 정의합니다.

라우팅 규칙에 대해서는 다음을 참조하세요.

라우팅 규칙을 최대 20개까지 정의할 수 있습니다. 각 규칙에는 url 및 service 요소가 포함되어야 합니다.
규칙에는 '.' 표기법으로 하위 도메인을 구분하는 HTTP URL 패턴을 사용해야 합니다. HTTPS '-dot-' 표기법을 사용하여 정의된 URL은 지원되지 않습니다.
cron.yaml 파일에 정의하는 URL에도 이 규칙이 적용됩니다.

예를 들어 https://simple-sample.uc.r.appspot.com/mobile/과 같은 모바일 요청을 모바일 프런트엔드로 라우팅하고 https://simple-sample.uc.r.appspot.com/work/와 같은 작업자 요청을 정적 백엔드로 라우팅하는 디스패치 파일을 만들 수 있습니다.

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

디스패치 파일 배포

gcloud를 사용하여 디스패치 파일을 배포하려면 다음 명령어를 실행합니다.

gcloud app deploy dispatch.yaml

Cloud Load Balancing으로 라우팅

Cloud Load Balancing은 Google Cloud에서 실행되는 모든 애플리케이션에 대해 고급 네트워크 구성을 지원하는 별도의 제품입니다.

서버리스 앱에 HTTP(S) 부하 분산이 사용 설정된 경우 다음을 수행할 수 있습니다.

다른 서비스와 공유되지 않는 전용 IPv4 또는 IPv6 IP 주소에서 제공되도록 서버리스 앱을 구성할 수 있습니다.
Compute Engine, Google Kubernetes Engine, Cloud Storage에 사용하는 것과 동일한 SSL 인증서와 비공개 키를 재사용할 수 있습니다. 이렇게 하면 서버리스 앱용 별도 인증서를 관리할 필요가 없습니다.

부하 분산기는 dispatch.yaml 파일의 라우팅 규칙을 간섭하거나 상호작용하지 않습니다. dispatch.yaml 규칙은 서버리스 NEG가 트래픽을 App Engine으로 전송할 때까지 평가되지 않습니다.

다음에 유의하세요.

앱이 부하 분산기(및 사용하는 경우 VPC)에서 전송되는 요청만 수신하도록 인그레스 제어를 사용하는 것이 좋습니다. 그렇지 않으면 사용자가 앱의 App Engine URL을 사용하여 부하 분산기를 통해 전달되는 부하 분산기, Google Cloud Armor 보안 정책, SSL 인증서, 비공개 키를 우회할 수 있습니다.

App Engine URL에 대한 추가 세부정보

URL의 리전 ID 이해

다음 도구를 사용하여 앱의 리전 ID를 볼 수 있습니다.

콘솔

Google Cloud 콘솔에서 앱의 인스턴스, 서비스, 버전의 URL을 볼 수 있습니다.

이러한 모든 URL에는 리전 ID가 포함됩니다.

gcloud

앱 또는 서비스를 배포할 경우 gcloud app deploy 명령어는 배포가 성공한 후에 URL을 표시합니다. 이 URL에는 리전 ID가 포함됩니다.

이미 배포된 서비스의 URL을 보려면 다음 안내를 따르세요.

gcloud app versions list 명령어를 입력하여 특정 서비스의 버전을 나열합니다. 예를 들어 기본 서비스 버전을 나열하려면 gcloud app versions list --service=default를 입력합니다.
gcloud app versions describe 명령어를 입력합니다. 이 명령어 출력에는 앱의 리전 ID가 있는 버전 URL이 포함됩니다. 예를 들어 기본 서비스의 20191023t101741 버전을 설명하려면 gcloud app versions describe 20191023t101741 --service=default를 입력합니다.

도메인 이름이 요청 데이터에 포함됨

요청에 사용되는 도메인 이름은 앱에 전달되는 요청 데이터에 포함됩니다. 따라서 요청 데이터를 사용하면 요청의 도메인 이름에 따라 앱의 응답 방식을 제어할 수 있습니다. 예를 들어 공식 도메인으로 리디렉션하려면 Host 요청 헤더를 확인한 다음 도메인 이름에 따라 응답하도록 앱을 코딩하면 됩니다.