요청 라우팅 방법

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

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

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

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

요청 및 도메인

App Engine은 수신되는 요청의 도메인 이름을 사용하여 요청 대상이 사용자 앱인지 확인합니다. 도메인 이름이 http://[YOUR_PROJECT_ID].appspot.com인 요청은 ID가 [YOUR_PROJECT_ID]인 앱으로 라우팅됩니다. 모든 앱에는 appspot.com 도메인 이름이 무료로 제공됩니다.

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

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

이러한 URL에 대한 요청은 모두 트래픽을 수신하도록 구성한 버전의 앱으로 이동합니다. 앱의 각 버전에도 자체 URL이 있으므로 새 버전을 배포하고 테스트한 후에 해당 버전에서 트래픽을 수신하도록 구성할 수 있습니다. 버전별 URL은 appspot.com 도메인 이름 외에도 특정 버전의 ID를 사용합니다(예: http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com). 하위 도메인을 버전별 URL과 함께 사용할 수도 있습니다(예: http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com). 자세한 내용 및 예는 URL을 통한 라우팅을 참조하세요.

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

URL을 통한 라우팅

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

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

Console

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

gcloud

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

API

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

기본 라우팅

다음 URL 패턴에는 기본 라우팅 동작이 있습니다. 디스패치 파일에 정의된 패턴과 일치하는 패턴이 있으면 기본 라우팅이 재정의됩니다.

  • default 서비스의 사용 가능한 인스턴스로 요청을 보냅니다.
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_CUSTOM_DOMAIN]

    default 서비스에서 트래픽에 대해 구성된 모든 버전에서 요청을 수신합니다.

  • 특정 서비스의 사용 가능한 인스턴스로 요청을 보냅니다.
    https://[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[SERVICE_ID].[MY_CUSTOM_DOMAIN]

    타겟팅 서비스에서 트래픽에 대해 구성된 모든 버전에서 요청을 수신합니다. 타겟팅하는 서비스가 없으면 요청이 소프트 라우팅됩니다.

  • 요청을
    default 서비스에서 지정된 버전의 사용 가능한 인스턴스로 보냅니다.
    https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_CUSTOM_DOMAIN]

    서비스가 타겟팅되지 않았다면 default 서비스로 요청이 전송됩니다.

소프트 라우팅

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

타겟팅된 라우팅

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

  • 요청을 특정 서비스 및 버전의 사용 가능한 인스턴스로 보냅니다.
    https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_CUSTOM_DOMAIN]

기본 서비스

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

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

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

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

    https://vFrontend-dot-default-dot-requestsProject.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. HTTPS 없이 커스텀 도메인을 사용하여 vBackend 버전을 타겟팅하려면 다음을 사용합니다.

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

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

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

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

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

디스패치 파일 만들기

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

예를 들어 http://simple-sample.appspot.com/mobile/과 같은 모바일 요청은 모바일 프런트엔드로 라우팅하고 http://simple-sample.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
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Go용 Google App Engine Flexible Environment