요청 라우팅 방법

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

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

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

로컬 개발 서버를 사용하여 앱을 테스트할 때 사용할 수 있는 라우팅 및 디스패치 기능은 약간 다릅니다. 프로덕션 서버와 개발 서버 모두에서 작동하는 URL을 프로그래매틱 방식으로 만들려면 get_hostname 메소드를 사용하세요.

자세한 내용은 개발 서버에서 라우팅을 참조하세요.

요청 및 도메인

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]
  • 수동 확장 서비스를 사용하면 인스턴스 ID를 포함하여 인스턴스를 타겟팅하고 인스턴스에 요청을 전송할 수 있습니다. 인스턴스 ID는 0부터 실행 중인 인스턴스의 총 개수 사이의 정수이며 다음과 같이 지정할 수 있습니다.

    요청을 특정 인스턴스 내의 특정 서비스 및 버전으로 보냅니다.

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_ID].[MY_CUSTOM_DOMAIN]

기본 서비스

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

서비스 액세스 제한

모든 서비스는 기본적으로 공개됩니다. 서비스 액세스를 제한하려면 login: admin 요소를 핸들러에 추가하면 됩니다.

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

appcfg

appcfg.py update_dispatch [YOUR_APP_DIR]

개발 서버에서 라우팅

인스턴스 주소 검색

로컬 개발 서버는 시작 시 모든 수동 확장 인스턴스를 만듭니다. 자동 및 기본 확장 서비스의 인스턴스는 동적으로 관리됩니다. 서버는 포트를 각 서비스에 할당하고, 클라이언트는 서버에 따라 부하 분산을 수행하고 인스턴스를 자동으로 선택할 수 있습니다. 각 서비스 주소 지정을 위한 포트 할당은 서버의 로그 메시지 스트림에 나타납니다. 다음은 3가지 서비스를 정의하는 앱용 포트입니다(각 서비스의 확장 유형은 관련 없음).

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

서비스 주소(예: http://localhost:8082/)를 사용하는 경우, 서버는 서비스의 인스턴스를 선택(또는 생성)하고 요청을 해당 인스턴스로 보냅니다.

서버는 서비스의 각 인스턴스에 고유한 포트를 할당합니다. 이러한 포트를 검색하려면 관리 서버를 사용해야 합니다. 관리 서버에는 고유한 포트가 있으며, 이는 메시지 로그에 나타납니다.

INFO Starting admin server at: http://localhost:8000

이 주소를 통해 관리 서버 콘솔로 이동합니다. 인스턴스를 클릭하면 앱 인스턴스의 동적 상태를 확인할 수 있습니다.

dev_appserver 관리 콘솔의 스크린샷

각 수동 인스턴스와 기본 인스턴스에 대해 별도의 항목이 나타납니다. 인스턴스 번호는 각 인스턴스에 고유한 포트 주소가 있는 링크입니다. 링크로 마우스를 가져가면 해당 인스턴스에 할당된 포트를 확인할 수 있으며, 링크를 클릭하여 해당 인스턴스에 직접 요청을 보낼 수 있습니다.

디스패치 파일

앱에 dispatch.yaml 파일이 포함된 경우 로그 메시지 스트림에 디스패처 포트가 포함됩니다.

INFO Starting dispatcher running at: http://localhost:8080

이 포트에 대한 요청은 디스패치 파일의 규칙에 따라 라우팅됩니다. 서버는 호스트 이름이 포함된 dispatch.yaml 파일 규칙(예: url: "customer1.myapp.com/*")을 지원하지 않습니다. 상대 경로 패턴(url: "*/fun")이 있는 규칙이 작동하므로 http://localhost/fun/mobile과 같은 URL을 사용하여 인스턴스에 도달할 수 있습니다. 호스트 기반 규칙이 포함된 dispatch.yaml 파일로 애플리케이션을 실행하려고 시도하면 서버가 로그 스트림에 오류를 보고합니다.