요청 라우팅 방법

리전 ID

REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google이 할당하는 코드입니다. 기존 앱은 App Engine URL에 REGION_ID.r을 포함하는 것이 선택사항이고, 신규 앱은 모두 곧 필수가 될 예정입니다.

원활한 전환을 위해 리전 ID를 사용하도록 App Engine을 천천히 업데이트하고 있습니다. 아직 Google Cloud 프로젝트가 업데이트되지 않은 경우에는 앱의 리전 ID가 표시되지 않습니다. 기존 앱에서 ID는 선택사항이므로 기존 앱에서 리전 ID를 사용할 수 있게 되더라도 URL을 업데이트하거나 다른 변경을 수행할 필요가 없습니다.

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

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

  • 도메인 수준에서 끝나는 URL을 사용하는 요청에는 App Engine의 기본 라우팅 규칙이 적용됩니다.

  • 또는 사용자가 지정한 규칙에 따라 특정 URL 패턴을 라우팅하는 디스패치 파일을 사용할 수도 있습니다.

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

요청 및 도메인

App Engine에서 앱이 실행되면 다음 URL을 사용하여 앱에 HTTP 요청을 보낼 수 있습니다.
https://PROJECT_ID.REGION_ID.r.appspot.com

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

이 URL은 트래픽을 수신하도록 구성한 앱 버전으로 요청을 보냅니다.

앱의 각 버전에도 자체 URL이 있으므로 새 버전을 배포하고 테스트한 후에 버전에서 트래픽을 수신하도록 구성할 수 있습니다. 버전별 URL은 프로젝트 ID, 리전 ID, appspot.com 도메인 이름 외에 특정 버전의 ID를 사용합니다. 예를 들면 https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com입니다.

하위 도메인

또한 appspot.com 도메인은 SUBDOMAIN-dot-PROJECT_ID.REGION_ID.r.appspot.com 형식의 하위 도메인을 지원합니다. 여기서 SUBDOMAIN은 도메인 이름의 한 부분에서 허용되는 문자열(. 문자 제외)일 수 있습니다. 이러한 방식으로 하위 도메인에 전송되는 요청은 앱으로 라우팅됩니다.

하위 도메인을 버전별 URL과 함께 사용할 수도 있습니다.
https://SUBDOMAIN-dot-VERSION_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com.

자세한 내용과 예시는 URL을 통한 라우팅을 참조하세요.

커스텀 도메인

G Suite를 사용하여 커스텀 최상위 도메인을 설정한 후 Google Mail 또는 Google 사이트 도구와 같은 다양한 앱에 하위 도메인을 할당할 수 있습니다. App Engine 앱을 하위 도메인과 연결할 수도 있습니다. 커스텀 도메인을 앱에 매핑하는 방법에 대한 자세한 내용은 SSL로 커스텀 도메인 보호를 참조하세요.

도메인 이름이 요청 데이터에 포함됩니다.

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

리전 ID

REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google이 할당하는 코드입니다. 기존 앱은 App Engine URL에 REGION_ID.r을 포함하는 것이 선택사항이고, 신규 앱은 모두 곧 필수가 될 예정입니다.

원활한 전환을 위해 리전 ID를 사용하도록 App Engine을 천천히 업데이트하고 있습니다. 아직 Google Cloud 프로젝트가 업데이트되지 않은 경우에는 앱의 리전 ID가 표시되지 않습니다. 기존 앱에서 ID는 선택사항이므로 기존 앱에서 리전 ID를 사용할 수 있게 되더라도 URL을 업데이트하거나 다른 변경을 수행할 필요가 없습니다.

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

콘솔

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

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

gcloud

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

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

  1. gcloud app versions list 명령어를 입력하여 특정 서비스의 버전을 나열합니다. 예를 들어 기본 서비스 버전을 나열하려면 gcloud app versions list --service=default를 입력합니다.

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

URL을 통한 라우팅

다양한 수준의 특이성에 따라 HTTP 요청을 타겟팅할 수 있습니다. 다음 예에서는 REGION_ID.r.appspot.com을 앱의 커스텀 도메인(있는 경우)으로 바꿀 수 있습니다. URL 하위 문자열 VERSION_ID, SERVICE_ID, PROJECT_ID는 각 앱의 리소스 ID를 나타냅니다.

다음 도구를 사용하여 앱의 리소스 ID를 검색할 수 있습니다.

콘솔

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

gcloud

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

API

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

기본 라우팅

다음 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_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
    https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

기본 서비스

App Engine에 앱의 초기 버전을 배포하면 default 서비스가 생성됩니다. 서비스를 지정하지 않거나 잘못된 서비스를 지정하는 요청은 default 서비스로 라우팅됩니다. 그런 다음 default 서비스 내에서 트래픽을 수신하도록 구성된 버전에서 이 요청을 처리합니다. Cloud Console의 버전 페이지에서 트래픽에 구성된 버전을 확인할 수 있습니다.

URL 패턴을 설명하기 위해 ID가 requestsProject이고 2가지 서비스와 버전을 실행하는 앱이 포함된 Cloud 프로젝트가 있다고 가정해 보겠습니다. 이 예시에서 앱의 default 서비스에는 vFrontend 버전이, 그리고 두 번째 서비스인 service2에는 vBackend 버전이 포함되어 있습니다. Google은 uc를 두 앱의 리전 ID로 할당했습니다.

특정 서비스 및 버전을 타겟팅하려면 다음과 같은 URL 패턴을 사용합니다.

  1. HTTPS를 사용하여 default 서비스의 버전을 타겟팅하려면 다음을 사용합니다.

        https://vFrontend-dot-default-dot-requestsProject.uc.r.appspot.com
        https://vFrontend-dot-requestsProject.uc.r.appspot.com
    

  2. 커스텀 도메인을 사용하여 vBackend 버전을 타겟팅하려면 다음을 사용하면 됩니다.

    https://vBackend.service2.example.net
    https://vBackend.example.net
    

    여기서 requestsProject.uc.r.appspot.comexample.net 도메인에 매핑됩니다.

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

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

디스패치 파일 만들기에 대한 자세한 내용은 dispatch.yaml 참조를 확인하세요.

디스패치 파일 만들기

디스패치 파일은 프로젝트 디렉터리의 루트 또는 default 서비스의 루트 디렉터리에 있어야 합니다. 디스패치 파일에서 최대 20개의 라우팅 규칙을 정의할 수 있으며, 각 규칙은 service 요소와 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

dispatch.yaml을 정의하는 방법에 대한 자세한 내용은 dispatch.yaml 참조 문서를 확인하세요.

디스패치 파일 배포

디스패치 구성 파일을 배포하려면 다음 명령어를 실행합니다.

gcloud

gcloud app deploy dispatch.yaml