appengine-web.xml 참조

리전 ID

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

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

확인

참고: 기존 번들 서비스를 사용하고 자바 21로 업그레이드하려면 자바 Enterprise Edition 8(EE8)에서 앱이 실행되는 경우에만 javax.servlet.* API를 계속 사용하도록 선택할 수 있습니다. EE8을 유지하도록 선택한 경우 appengine-web.xml 파일을 업데이트해야 합니다. 구성 옵션에 대한 자세한 내용은 기존 애플리케이션 업그레이드를 참조하세요.

기존 앱을 App Engine 자바 8 런타임에서 지원되는 최신 자바 버전으로 기존 앱을 마이그레이션하려고 기존 번들 서비스를 사용하려는 경우에만 앱 구성에 appengine-web.xml 파일을 사용해야 합니다. 프로젝트에서 appengine-web.xml을 사용하는 경우 app.yaml은 배포 시 자동으로 생성됩니다.

App Engine Java 애플리케이션은 appengine-web.xml이라는 구성 파일을 사용하여 앱에 대한 정보를 지정하고 앱의 WAR 파일에서 이미지와 같은 정적 파일이 무엇인지 식별하고 애플리케이션에서 사용되는 리소스 파일을 식별합니다.

구문

App Engine Java 앱에는 appengine-web.xml 디렉터리의 WAR에 WEB-INF/이라는 파일이 있어야 합니다. 이 파일은 루트 요소가 <appengine-web-app>인 XML 파일입니다.

appengine-web.xml에 대한 문서 유형 정의와 스키마 사양은 SDK의 docs/ 디렉터리에서 찾을 수 있습니다.

참고: 표준 appengine-web.xml 파일은 기본 서비스를 정의합니다. 이전에 모듈로 알려졌던 각각의 비기본 서비스에 대한 추가 구성 매개변수를 지정해야 합니다. 이와 관련해서는 App Engine 개요에서 설명합니다. 이러한 구성 매개변수를 기본 서비스에 적용할 수도 있습니다.

요소	설명
<application>	gcloud app deploy 명령어, IntelliJ 또는 Eclipse 플러그인, Maven 또는 Gradle 플러그인과 같은 Google Cloud SDK 기반 도구를 사용하여 앱을 배포하는 경우에는 필요하지 않습니다. Google Cloud SDK 기반 도구는 이 요소를 무시하고 gcloud config 프로젝트 속성에서 프로젝트 ID를 가져옵니다. gcloud 명령줄 도구를 사용하여 프로젝트 ID를 재정의할 수는 있지만 이렇게 하면 머신 전체 프로젝트 ID가 설정되므로, 여러 프로젝트 개발 시에 혼란이 야기될 수 있습니다. <application> 요소는 애플리케이션의 프로젝트 ID를 포함합니다. 이 프로젝트 ID는 Google Cloud console에서 프로젝트를 만들 때 등록하는 프로젝트 ID입니다.
<app-engine-apis>	선택사항. 2세대 런타임용 App Engine 기존 번들 서비스를 사용하려면 이 필드를 true로 설정합니다.
<entrypoint>	선택사항이며 2세대 런타임에만 해당됩니다. Java 애플리케이션을 부팅하는 프로세스 명령줄인 기본 진입점을 재정의합니다. 기본적으로 F4 인스턴스 클래스에 대해 생성된 진입점(메모리 설정은 인스턴스 클래스에서 계산됨)은 다음 구성과 동일합니다. <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app> JVM 프로세스 플래그를 추가하도록 구성을 수정하거나 자체 부팅 프로세스를 정의할 수 있습니다. 애플리케이션은 /workspace 디렉터리에 배포되고 런타임 JAR은 /base/java_runtime 디렉터리 아래에 있습니다. 환경 변수를 사용해서 Java 런타임에 대해 진입점을 맞춤설정하는 방법을 알아봅니다.
<async-session-persistence>	선택사항. 애플리케이션이 HTTP 세션 데이터를 Datastore에 비동기식으로 쓰도록 구성하여 요청 지연 시간을 줄일 수 있습니다. <async-session-persistence enabled="true" /> 비동기 세션 지속성을 사용하면 App Engine은 데이터를 Memcache에 쓰기 전에 세션 데이터를 Datastore에 쓰는 태스크 큐 태스크를 제출합니다. 기본적으로 태스크는 `default` 큐에 제출됩니다. 다른 큐를 사용하려면 `queue-name` 속성을 추가합니다. <async-session-persistence enabled="true" queue-name="myqueue"/> 세션 데이터는 항상 동기식으로 Memcache에 기록됩니다. memcache를 사용할 수 없을 때(또는 세션 데이터가 비워졌을 때) 요청이 세션 데이터를 읽으려고 시도하면, 아직 최신 세션 데이터가 포함되지 않을 수 있는 Datastore로 장애 조치됩니다. 이는 비동기 세션 지속성으로 인해 애플리케이션에 비활성 세션 데이터가 보일 수 있음을 의미합니다. 그러나 대부분 애플리케이션의 경우, 지연 시간의 이점이 이러한 위험을 훨씬 능가합니다.
<auto-id-policy>	선택사항. 항목 식별자를 자동으로 설정하는 경우, 자동 ID 정책을 설정하여 사용되는 방법을 변경할 수 있습니다. 유효한 옵션은 다음과 같습니다. default 기본값. 64비트 부동 소수점으로 표시될 수 있을 만큼 작고 적절하게 분포된 큰 정수인 분산형 자동 ID를 사용합니다. legacy 이전 옵션은 이후 출시 버전에서 지원 중단되고 결국 삭제될 예정입니다. 자세한 내용은 이 변경 사항을 알리는 블로그 게시물을 참조하세요.
<automatic-scaling>	선택사항. 자세한 설명은 자동 확장 섹션을 참조하세요.
<basic-scaling>	선택사항. 자세한 설명은 기본 확장 섹션을 참조하세요.
<env-variables>	선택사항. appengine-web.xml 파일은 애플리케이션이 실행 중에 설정되는 환경 변수를 정의할 수 있습니다. <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> 로컬 환경과의 충돌을 방지하기 위해 개발 서버는 이 파일을 바탕으로 환경 변수를 설정하지 않으며 로컬 환경에서 이러한 변수가 이미 일치하는 값으로 설정되어 있도록 요구합니다. export DEFAULT_ENCODING="UTF-8" dev_appserver war App Engine에 배포하면 이러한 변수가 이미 설정된 환경이 생성됩니다.
<inbound-services>	선택사항. 애플리케이션에서 이메일을 수신하려면 먼저 해당 서비스를 사용 설정하도록 애플리케이션을 구성해야 합니다. Java 앱에 서비스를 사용 설정하려면 appengine-web.xml 파일에 <inbound-services> 섹션을 포함합니다. 다음과 같은 인바운드 서비스를 사용할 수 있습니다. mail 애플리케이션이 메일을 수신하도록 허용합니다.
<instance-class>	선택사항. 이 모듈의 인스턴스 클래스 크기입니다. 다른 확장 옵션을 지정하는 경우에 다음과 같은 인스턴스 클래스를 사용할 수 있습니다. automatic_scaling 자동 확장을 사용하면 F1, F2, F4, F4_1G 인스턴스 클래스를 사용할 수 있습니다. 기본값: automatic_scaling 요소 사용 시 인스턴스 클래스를 지정하지 않으면 F1이 할당됩니다. basic_scaling 기본 확장을 사용하면 B1, B2, B4, B4_1G, B8 인스턴스 클래스를 사용할 수 있습니다. 기본값: basic_scaling 요소 사용 시 인스턴스 클래스를 지정하지 않으면 B2가 할당됩니다. manual_scaling 수동 확장을 사용하면 B1, B2, B4, B4_1G, B8 인스턴스 클래스를 사용할 수 있습니다. 기본값: manual_scaling 요소 사용 시 인스턴스 클래스를 지정하지 않으면 B2가 할당됩니다. 참고: instance-class가 F2 이상으로 설정되면 max-concurrent-requests를 기본값인 10보다 큰 값으로 설정하여 인스턴스를 최적화할 수 있습니다. 최적 값을 찾으려면 값을 점차적으로 늘리면서 애플리케이션 성능을 모니터링하세요.
<manual-scaling>	선택사항. 자세한 설명은 수동 확장 섹션을 참조하세요.
<precompilation-enabled>	선택사항. App Engine은 Java 런타임 환경에서 앱의 성능을 향상시키기 위해 앱의 Java 바이트코드를 '사전 컴파일'합니다. 사전 컴파일된 코드는 원래의 바이트코드와 동일하게 작동합니다. 어떤 이유로 앱이 사전 컴파일을 사용하지 않게 하려면 appengine-web.xml 파일에 다음을 추가하여 사전 컴파일을 사용 중지할 수 있습니다. <precompilation-enabled>false</precompilation-enabled>
<module>	참고: 서비스의 이전 명칭은 '모듈'이며 appengine-web.xml 파일에서 서비스는 계속해서 모듈로 선언됩니다. 예를 들면 <module>service_name</module>입니다. 서비스를 만들 경우 필수 항목입니다. 기본 서비스의 경우에는 선택사항입니다. 각 서비스와 버전에는 이름이 있어야 합니다. 이름에는 숫자, 문자, 하이픈이 포함될 수 있습니다. 63자(영문)를 초과할 수 없으며 하이픈으로 시작하거나 끝날 수 없고 문자열 `-dot`를 포함할 수 없습니다. 각 서비스와 버전에 고유한 이름을 선택하세요. 서비스와 버전 간에 이름을 재사용하지 마세요. 서비스를 참조하세요.
<public-root>	선택사항. <public-root>는 애플리케이션의 정적 파일이 포함된 애플리케이션의 디렉터리입니다. 정적 파일에 대한 요청이 실행되면 요청 경로 앞에 애플리케이션의 <public-root>가 추가됩니다. 이에 따라 요청된 콘텐츠가 있는 애플리케이션 파일 경로가 제공됩니다. <public-root>의 기본값은 /입니다. 예를 들어 다음은 URL 경로 /index.html을 애플리케이션 파일 경로 /static/index.html로 매핑합니다. <public-root>/static</public-root>
<resource-files>	선택사항. <resource-files> 요소에 나열된 파일은 파일 시스템을 사용하여 애플리케이션 코드에 액세스할 수 있습니다. 이러한 파일은 정적 파일을 저장하고 제공하는 방식과 달리 앱과 함께 애플리케이션 서버에 저장됩니다. <resource-files> 요소는 다음 요소를 포함할 수 있습니다. <include> <include> 요소는 파일을 리소스 파일로 지정하며 애플리케이션 코드에서 사용될 수 있습니다. 이 파일은 트래픽 서비스 제공이 아닌 읽기 전용으로만 코드에서 사용될 수 있습니다. 파일 포함 및 제외. <exclude> <exclude> 패턴과 일치하는 파일 및 디렉터리는 애플리케이션 코드에 업로드하거나 사용할 수 없습니다. 단, 로컬 개발 서버에서 실행하는 경우에는 이러한 파일과 디렉터리는 애플리케이션에 계속 액세스할 수 있습니다. 자세한 내용은 파일 포함 및 제외를 참조하세요. 예시: <resource-files> <include path="/**.xml" /> <exclude path="/feeds/**.xml" /> </resource-files> 이 예시는 feeds/ 디렉터리와 해당 하위 디렉터리의 파일을 제외하고 모든 .xml 파일을 리소스 파일로 지정하는 방법을 보여줍니다. App Engine 리소스 파일은 java.io.File 또는 javax.servlet.ServletContext.getResource/getResourceAsStream을 사용하여 읽습니다. 이들은 Class.getResourceAsStream()을 통해 액세스할 수 없습니다.
<runtime>	지원되는 최신 자바 버전을 사용하려면 java21 값으로 이 항목을 지정해야 합니다. 예: <runtime>java21</runtime>
<service>	서비스의 이전 명칭은 모듈입니다. 현재는 gcloud app 명령어를 통해 <service>service_name</service >로 서비스를 정의하는 것만 지원됩니다.
<service-account>	선택사항. <service-account> 요소를 사용하면 사용자 관리 서비스 계정을 버전의 ID로 지정할 수 있습니다. 지정된 서비스 계정은 다른 Google Cloud 서비스에 액세스하고 태스크를 실행할 때 사용됩니다. 예: <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
<sessions-enabled>	선택사항. App Engine에는 서블릿 세션 인터페이스를 사용하여 구현된 세션이 포함됩니다. 이 구현은 지속성을 위해 Datastore의 세션 데이터를 저장하며 속도를 높이기 위해 Memcache도 사용합니다. 대부분의 다른 서블릿 컨테이너와 마찬가지로, 요청 중에 `session.setAttribute()`로 설정된 세션 속성은 요청이 끝날 때까지 지속됩니다. 이 기능은 기본적으로 사용 중지되어 있습니다. 이 기능을 사용 설정하려면 appengine-web.xml에 다음을 추가하세요. 예시: <sessions-enabled>true</sessions-enabled> 이 구현은 _ah_SESSION 종류의 Datastore 항목과 프리픽스가 _ahs인 키를 사용하여 Memcache 항목을 만듭니다. 이러한 항목은 Dataflow 템플릿을 사용하여 삭제할 수 있습니다. 참고: App Engine은 Datastore와 Memcache에 세션 데이터를 저장하므로, 세션에 저장된 모든 값은 java.io.Serializable 인터페이스를 구현해야 합니다. 세션 데이터 스토리지 지연 시간을 줄이기 위한 방법은 async-session-persistence 요소를 참조하세요.
<ssl-enabled>	선택사항. 기본적으로 모든 사용자는 HTTP 또는 HTTPS를 사용하여 모든 URL에 액세스할 수 있습니다. 사용자는 배포 설명자의 특정 URL에 대해 HTTPS를 요구하도록 앱을 구성할 수 있습니다. 배포 설명자: 보안 URL을 참조하세요. 애플리케이션에 HTTPS 사용을 허용하지 않으려면 appengine-web.xml 파일에 다음을 추가합니다. <ssl-enabled>false</ssl-enabled> Java 런타임 환경에서 일부 URL 경로에 대해서만 HTTPS를 허용하지 않는 방법은 없습니다.
<static-error-handlers>	선택사항. 특정 오류가 발생하면 App Engine은 일반 오류 페이지를 제공합니다. 커스텀 오류 데이터가 10KB 미만인 경우, 이러한 일반 오류 페이지 대신 커스텀 정적 파일을 제공하도록 앱을 구성할 수 있습니다. 앱의 appengine-web.xml 파일에 여러 파일을 지정하여 지원되는 각 오류 코드에 대해 제공할 다양한 정적 파일을 설정할 수 있습니다. 커스텀 오류 페이지를 제공하려면 이 예시와 같이 appengine-web.xml에 <static-error-handlers> 섹션을 추가합니다. <static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers> 경고: 오류 응답 파일의 경로가 정적 파일 핸들러 경로와 겹치지 않는지 확인하세요. 각 file 항목은 일반 오류 응답을 대신 제공해야 하는 정적 파일을 나타냅니다. error-code는 연관된 파일 제공을 유발하는 오류 코드를 나타냅니다. 지원되는 오류 코드는 다음과 같습니다. over_quota 앱이 리소스 할당량을 초과했음을 나타냅니다. timeout 앱에서 응답하기 전 기한에 도달한 경우에 사용됩니다. error-code는 선택사항입니다. 지정하지 않으면 제공된 파일이 앱의 기본 오류 응답이 됩니다. 커스텀 오류를 처리할 때 사용할 mime-type을 선택사항으로 지정할 수 있습니다. MIME 유형의 전체 목록을 참조하세요.
<static-files>	선택사항. <static-files> 요소는 정적 파일 목록에 포함하거나 해당 목록에서 제외할 파일 경로와 일치하는 패턴을 지정하여 기본 동작을 재정의하거나 수정합니다. 정적 파일은 애플리케이션 서버와는 별도의 전용 서버 및 캐시에서 제공되고 이미지, CSS 스타일시트 또는 자바스크립트 파일과 같은 정적 콘텐츠를 제공하는 데 유용합니다. <static-files> 요소는 다음 요소를 포함할 수 있습니다. <include> <include> 요소는 모든 비JSP 파일을 포함하는 기본 동작을 재정의합니다. <include> 요소는 지정된 리소스에 대한 요청 응답 시에 사용할 HTTP 헤더를 지정할 수 있습니다. 자세한 내용은 파일 포함 및 제외를 참조하세요. include 요소에 expiration 속성을 지정하여 기본 정적 캐시 만료 시간을 재정의할 수 있습니다. 값은 공백으로 구분된 숫자와 단위 문자열입니다. 단위는 d(일), h(시간), m(분), s(초)일 수 있습니다. 예를 들어 "4d 5h"는 파일이 처음 요청된 후 4일 5시간으로 캐시 만료 시간을 설정합니다. 자세한 내용은 캐시 만료를 참조하세요. <exclude> 앱을 App Engine에 배포하면 <exclude> 패턴과 일치하는 파일과 디렉터리는 업로드되지 않습니다. 단, 로컬 개발 서버에서 실행하는 경우에는 이러한 파일과 디렉터리는 애플리케이션에 계속 액세스할 수 있습니다. 자세한 내용은 파일 포함 및 제외를 참조하세요. 예시 <static-files> <include path="/my_static-files" > <http-header name="Access-Control-Allow-Origin" value="http://example.org" /> </include> </static-files>
<system-properties>	선택사항. appengine-web.xml 파일은 애플리케이션이 실행 중에 설정되는 시스템 속성과 환경 변수를 정의할 수 있습니다. <system-properties> <property name="myapp.maximum-message-length" value="140" /> <property name="myapp.notify-every-n-signups" value="1000" /> <property name="myapp.notify-url" value="http://www.example.com/signupnotify" /> </system-properties> <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> 선택사항. CPU 및 메모리 사용률을 개선하기 위해 HTTP 커넥터를 구성할 수 있습니다. 애플리케이션이 Datastore 또는 태스크 큐 작업과 상호작용하는 경우 이 기능을 사용 설정한 후 성능 및 동작 영향을 모니터링하도록 모니터링을 설정하세요. <system-properties> <property name="appengine.use.httpconnector" value="true"/> </system-properties> 선택사항. 다음 시스템 속성을 사용하여 EE8 또는 EE10에서 작동하도록 기본 런타임을 구성할 수 있습니다. EE 지원에 관한 자세한 내용은 Java 21로 업그레이드를 참고하세요. <system-properties> <property name="appengine.use.EE10" value="true"/> <!-- or EE8 --> </system-properties> 자바 21부터는 가상 스레드를 사용하도록 Java 웹 서버를 구성할 수 있습니다. 예를 들면 다음과 같습니다. <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> 스레드 지원에 관한 자세한 내용은 Jetty 12 - 가상 스레드 지원을 참고하세요.
<url-stream-handler>	선택사항. 가능한 값은 native 또는 urlfetch입니다. 기본값은 native이며, 이는 표준 Java 네트워크 클래스가 표준 Java HTTP(S) 전송을 사용함을 의미합니다. 이 설정을 사용하려면 앱에서 결제를 사용 설정해야 합니다. 그렇지 않으면 발행 요청에 설명된 것처럼 예외가 발생합니다. url-stream-handler를 urlfetch로 설정하면 URL.openConnection 및 관련 메서드가 http 및 https 전송에 URL 가져오기를 사용합니다. <url-stream-handler>urlfetch</url-stream-handler>
<version>	<version> 요소에는 앱 코드의 최신 버전에 대한 버전 식별자가 포함됩니다. 버전 식별자는 소문자, 숫자, 하이픈을 포함할 수 있습니다. 프리픽스 'ah-'로 시작될 수 없으며, 'default'와 'latest' 이름은 예약된 이름이므로 사용될 수 없습니다. 항상 숫자로 지정되는 숫자 인스턴스와 구분되도록 버전 이름은 문자로 시작되어야 합니다. 이렇게 하면 123.my-module.uc.r.appspot.com과 같이 2가지로 해석될 수 있는 URL의 모호성을 방지할 수 있습니다. 즉, URL에 버전 '123'이 있으면 대상은 제공된 모듈의 버전 '123'이 됩니다. 해당 버전이 존재하지 않으면 타겟팅은 모듈 기본 버전의 123번 인스턴스입니다.
<warmup-requests-enabled>	선택사항. 기본값은 true입니다. 준비 요청은 기본적으로 Java 애플리케이션에서 사용 설정됩니다. 준비 요청이 사용 설정되면 App Engine 인프라는 /_ah/warmup에 `GET` 요청을 보내 <load-on-startup> 서블릿, ServletContextListeners, 커스텀 준비 서블릿을 초기화합니다. 따라서 애플리케이션 코드를 필요에 따라 초기화할 수 있습니다. 선택한 방법에 따라 /_ah/warmup에 대한 고유한 핸들러를 구현해야 할 수도 있습니다. 준비 요청을 중지하려면 이 요소에 대해 false를 지정합니다. <warmup-requests-enabled>false</warmup-requests-enabled>
<vpc-access-connector>	선택사항. 서버리스 VPC 액세스 커넥터를 사용하도록 애플리케이션을 구성하여 애플리케이션이 VPC 네트워크의 내부 리소스에 요청을 보낼 수 있게 합니다. <name> 요소에 커넥터의 정규화된 이름을 지정합니다. <vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector> 자세한 내용은 VPC 네트워크의 내부 리소스에 연결을 참조하세요.

요소 확장

다음 표에는 애플리케이션 확장을 지정하는 방법을 정의하는 옵션이 나와 있습니다.

확장 유형의 성능 특징 비교에 대해서는 동적 인스턴스 확장을 참조하세요.

요소	설명
<automatic-scaling>	선택사항. 달리 지정되지 않는 한 기본적으로 자동 확장에는 기본 인스턴스 클래스 F1이 사용됩니다. automatic_scaling 요소는 모듈의 인스턴스 수, 지연 시간, 동시 연결에 대한 최소 및 최대 수준을 설정합니다. 이 요소는 다음 요소를 포함할 수 있습니다. <target-cpu-utilization> 선택사항. 0.5에서 0.95 사이의 값을 지정합니다. 이 매개변수는 트래픽 처리를 위해 새 인스턴스가 시작되는 CPU 사용량 기준점을 지정합니다. 이렇게 하면 성능과 비용 간의 균형을 유지할 수 있습니다. 값을 낮추면 성능과 비용이 높아지고, 값을 높이면 성능이 낮아지지만 비용도 낮아집니다. 예를 들어 값이 0.7이면 CPU 사용량이 70%에 도달한 후 새 인스턴스가 시작됩니다. <target-throughput-utilization> 선택사항. 0.5에서 0.95 사이의 값을 지정합니다. 동시 요청으로 인해 새 인스턴스가 시작되는 경우를 지정하기 위해 max-concurrent-requests과 함께 사용됩니다. 동시 요청 수가 max-concurrent-requests와 target-throughput-utilization을 곱한 값에 도달하면 스케줄러는 새 인스턴스를 시작합니다. <max-instances> 선택사항. 이 애플리케이션 버전에 대해 App Engine이 만들 수 있는 최대 인스턴스 수입니다. 이 값은 모듈 비용을 제한하는 데 유용합니다. 0에서 2147483647 사이의 값을 지정합니다. <min-instances> 선택사항. 이 모듈 버전에 대해 App Engine이 만들 수 있는 최소 인스턴스 수입니다. 이러한 인스턴스는 요청이 도착했을 때 트래픽을 처리하고 트래픽 처리를 위해 추가 인스턴스가 시작되었을 때도 계속 트래픽을 처리합니다. 0에서 1,000 사이의 값을 지정합니다. 매개변수를 값 0으로 설정하면 요청이 처리되지 않을 때 비용 절감을 위해 인스턴스를 0개로 조정할 수 있습니다. 트래픽 수신 여부에 관계없이 지정된 인스턴스 수에 따라 비용이 청구됩니다. <max-concurrent-requests> 선택사항. 스케줄러가 새 인스턴스를 만들기 전에 자동 확장 인스턴스가 수락할 수 있는 동시 요청 수입니다(기본값: 10, 최대값: 80). 이 설정이 너무 높으면 API 지연 시간이 늘어날 수 있습니다. 스케줄러는 실제 최대 요청 수에 도달하기 전에 새 인스턴스를 생성할 수 있습니다. 참고: instance-class가 F2 이상으로 설정되면 max-concurrent-requests를 기본값인 10보다 큰 값으로 설정하여 인스턴스를 최적화할 수 있습니다. 최적 값을 찾으려면 값을 점차적으로 늘리면서 애플리케이션 성능을 모니터링하세요. <max-idle-instances> 이 버전에 대해 App Engine이 유지해야 하는 최대 유휴 인스턴스 수입니다. 기본값은 'automatic'입니다. 다음 사항에 유의하세요. 최댓값이 높으면 부하 수준이 급상승 이후 정상으로 돌아갈 때 유휴 인스턴스 수가 보다 점진적으로 줄어듭니다. 이렇게 하면 요청 부하가 변동되더라도 애플리케이션이 성능을 안정적으로 유지할 수 있지만 높은 부하 기간 중에 유휴 인스턴스 수가 증가하므로 실행 비용도 늘어납니다. 최댓값이 낮으면 실행 비용이 낮아지지만 부하 수준의 변동 폭이 클 때 성능이 저하될 수 있습니다. 참고: 부하 급증 후 정상 수준으로 다시 조정될 때는 유휴 인스턴스 수가 사용자가 지정한 최댓값을 일시적으로 초과할 수 있습니다. 하지만 사용자가 지정한 최대 개수를 초과하는 인스턴스에 대해서는 비용이 청구되지 않습니다. <max-pending-latency> 대기 지연 시간이 감소되도록 요청 처리를 위해 추가 인스턴스를 시작하기 전에 App Engine이 대기 큐에서 요청에 허용해야 하는 최대 대기 시간입니다. 최대값이 낮으면 App Engine이 대기 중인 요청에 대해 새 인스턴스를 더 빠르게 시작하므로, 성능이 향상되지만 실행 비용도 높아집니다. 최댓값이 높으면 (대기 중인 요청이 있지만 이를 처리할 유휴 인스턴스가 없는 경우) 요청을 처리하는 데 오래 기다려야 할 수 있지만 애플리케이션 실행 비용은 낮아집니다. <min-idle-instances> 실행 상태로 유지되고 트래픽을 처리할 수 있는 인스턴스 수입니다. 이 설정은 트래픽을 가장 많이 수신하는 버전에만 적용됩니다. 다음 사항에 유의하세요. 최솟값이 낮으면 유휴 기간 중의 실행 비용이 낮아지지만, 갑작스러운 부하 증가에 대응하기 위해 즉시 사용할 수 있는 인스턴스 수가 부족할 수 있습니다. 최솟값이 높으면 요청 부하가 급증하더라도 애플리케이션을 우선적으로 처리할 수 있습니다. App Engine은 들어오는 요청을 처리하기 위해 실행 중인 최소 인스턴스 수를 유지합니다. 요청 처리 여부에 관계없이 인스턴스에 대한 요금은 청구됩니다. 이 기능이 올바르게 작동하기 위해서는 준비 요청이 사용 설정되었고 애플리케이션이 준비 요청을 처리할 수 있는지 확인해야 합니다. 유휴 인스턴스의 최소 개수를 설정하면, 대기 지연 시간이 애플리케이션 성능에 영향을 덜 줍니다. App Engine은 유휴 인스턴스를 예약된 상태로 유지하므로, 부하가 매우 크게 증가하는 경우를 제외하고 요청이 대기 중인 큐에 진입할 가능성이 낮습니다. 예약 상태로 유지할 이상적인 인스턴스 수를 결정하려면 애플리케이션과 예상 트래픽 볼륨을 테스트해야 합니다. <min-pending-latency> App Engine이 요청 처리를 위해 새 인스턴스를 시작하기 전에 대기 중인 대기열에서 요청 대기 시간을 허용하는 최소 시간(초)입니다. 0.01에서 15 사이의 값을 지정합니다. 최소값이 낮으면 기존의 모든 인스턴스가 활성화 상태인 경우에 요청이 대기 중인 대기열에 있어야 하는 시간이 줄어듭니다. 따라서 성능은 향상되지만 애플리케이션 실행 비용이 증가합니다. 최솟값이 높으면 기존의 모든 인스턴스가 활성화 상태인 경우에 요청이 대기 중 상태로 유지되는 시간이 늘어납니다. 따라서 실행 비용은 낮아지지만 요청 처리를 위해 사용자가 기다려야 하는 시간이 늘어납니다. 예 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>F2</instance-class> <automatic-scaling> <target-cpu-utilization>0.65</target-cpu-utilization> <min-instances>5</min-instances> <max-instances>100</max-instances> <max-concurrent-requests>50</max-concurrent-requests> </automatic-scaling> </appengine-web-app>
<basic-scaling>	선택사항. <basic-scaling> 요소는 모듈의 인스턴스 수를 설정합니다. 이 요소는 다음 요소를 포함할 수 있습니다. <idle-timeout> 선택사항. 마지막 요청을 받은 후 이 시간이 경과되면 인스턴스가 종료됩니다. 기본값은 5분입니다. <max-instances> 필수사항. 이 모듈 버전에 대해 App Engine이 만들 수 있는 최대 인스턴스 수입니다. 이 값은 모듈 비용을 제한하는 데 유용합니다. 예시 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <basic-scaling> <max-instances>11</max-instances> <idle-timeout>10m</idle-timeout> </basic-scaling> </appengine-web-app>
<manual-scaling>	선택사항. <manual-scaling> 요소는 모듈에 대해 수동 확장을 사용 설정하고 모듈의 인스턴스 수를 설정합니다. 이 요소는 다음 요소를 포함할 수 있습니다. <instances> 시작 시 모듈에 할당할 인스턴스 수입니다. 예시 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <manual-scaling> <instances>5</instances> </manual-scaling> </appengine-web-app>

스테이징 요소

배포 중에 수행되는 대부분의 작업은 스테이징이라 하는 준비 단계에서 로컬로 수행되며, 이 과정에서 JAR 파일 어셈블, JSP 컴파일 등의 작업이 수행됩니다. 선택사항으로 애플리케이션 구성 파일의 스테이징 요소를 사용하여 스테이징 동작의 특정 부분을 구성할 수 있습니다. 대부분의 애플리케이션은 스테이징 동작을 수동으로 구성하지 않고도 성공적으로 배포됩니다. 앱이 배포되지 않는 경우, 아래에 있는 옵션을 사용하여 스테이징을 구성해야 할 수도 있습니다.

요소

설명

<staging>

선택사항. 대부분의 애플리케이션은 기본 동작을 변경할 필요가 없습니다. 스테이징 요소를 사용하면 배포를 위해 필요한 경우에 특정 스테이징 구성을 지정할 수 있습니다. 이 요소에는 다음 요소가 포함될 수 있습니다. <enable-jar-splitting> 선택사항. 큰 Jar 파일(10MB 초과)을 작은 조각으로 분할합니다. (기본값: true). <jar-splitting-excludes> 쉼표로 구분된 파일 서픽스 목록을 지정합니다. enable-jar-splitting이 사용 설정된 경우 서픽스가 일치하는 모든 파일이 모든 JAR에서 제외됩니다. <disable_jar_jsps> JSP에서 jar 클래스를 생성하지 마세요. (기본값: false). <enable-jar-classes> WEB-INF/클래스의 콘텐츠를 Jar로 만듭니다. (기본값: true). <delete-jsps> 컴파일 후 JSP 소스 파일을 삭제합니다. (기본값: true). <compile-encoding> 컴파일을 위한 소스 파일 인코딩을 입력합니다. (기본값: utf-8) 예를 들면 다음과 같습니다. <staging> <delete-jsps>false</delete-jsps> </staging>

스테이징 옵션 기본값

스테이징 옵션의 기본값은 gcloud CLI와 같은 Google Cloud SDK 기반 도구 또는 Google Cloud SDK 기반 Maven, Gradle, Eclipse, IntelliJ 플러그인 사용 여부에 따라 다릅니다.

스테이징 요소	App Engine SDK 기반 기본값	Google Cloud SDK 기반 기본값
enable-jar-splitting	false	true
jar-splitting-excludes	해당 없음	해당 없음
disable-jar-jsps	false	false
enable-jar-classes	false	true. 클래스 로딩 순서에 영향을 줄 수 있으므로, 앱이 이전의 false 기본값을 사용하여 특정 순서에 의존하는 경우에는 이 요소를 false로 설정할 수 있습니다.
delete-jsps	false	true
compile-encoding	utf-8	utf-8

포함 및 제외 문법

경로 패턴은 <include> 및 <exclude> 요소를 0개 이상의 사용하여 지정됩니다. 패턴에서 '*'는 파일 또는 디렉터리 이름의 문자를 0개 이상 나타내고, **는 경로에 있는 디렉터리를 0개 이상 나타냅니다. 앱을 App Engine에 배포하면 <exclude> 패턴과 일치하는 파일과 디렉터리는 업로드되지 않습니다. 단, 로컬 개발 서버에서 실행하는 경우에는 이러한 파일과 디렉터리는 애플리케이션에 계속 액세스할 수 있습니다.

<include> 요소는 모든 파일을 포함하는 기본 동작을 재정의합니다. <exclude> 요소는 모든 <include> 패턴(그리고 <include>를 명시적으로 제공하지 않은 경우에는 기본값) 이후에 적용됩니다.

다음 예시는 모든 .png 파일(data/ 디렉터리와 해당 하위 디렉터리의 파일 제외)을 정적 파일로 지정하는 방법을 보여줍니다.

<static-files>
  <include path="/**.png" />
  <exclude path="/data/**.png" />
</static-files>

이러한 정적 리소스에 대한 요청 응답 시에 사용할 HTTP 헤더를 설정할 수도 있습니다.

<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>

참고: path 문자열이 슬래시로 시작되지 않으면 HTTP 헤더(해당되는 경우)가 App Engine에서 작동하지만 개발 서버에서는 작동하지 않습니다.

정적 파일의 MIME 유형

기본적으로 정적 파일은 파일 이름 확장명에 따라 선택된 MIME 유형을 사용하여 제공됩니다. web.xml에서 mime-mapping 요소를 사용하여 정적 파일의 파일 이름 확장명에 커스텀 MIME 유형을 연결할 수 있습니다.

URLFetch 제한 시간

각 URLFetch 요청에 기한을 설정할 수 있습니다. 기본적으로 가져오기 기한은 5초입니다. appengine-web.xml 구성 파일에 다음 설정을 포함하여 이 기본값을 변경할 수 있습니다. 다음 명령어를 입력하여 시간 제한을 초 단위로 지정합니다.

<system-properties>
    <property name="appengine.api.urlfetch.defaultDeadline" value="10"/>
</system-properties>