REGION_ID는 앱을 만들 때 선택한 리전을 기준으로 Google에서 할당하는 축약된 코드입니다. 일부 리전 ID는 일반적으로 사용되는 국가 및 주/도 코드와 비슷하게 표시될 수 있지만 코드는 국가 또는 주/도와 일치하지 않습니다. 2020년 2월 이후에 생성된 앱의 경우 REGION_ID.r이 App Engine URL에 포함됩니다. 이 날짜 이전에 만든 기존 앱의 경우 URL에서 리전 ID는 선택사항입니다.
이 문서는 App Engine 애플리케이션이 요청을 수신하고 응답을 전송하는 방법을 설명합니다. 자세한 내용은 요청 헤더 참조를 참조하세요.
애플리케이션이 서비스를 사용하는 경우, 요청을 특정 서비스 또는 서비스의 특정 버전으로 지정할 수 있습니다. 서비스 주소 지정에 대한 자세한 내용은 요청 라우팅 방법을 참조하세요.
요청 처리
애플리케이션은 웹 서버를 시작하고 요청을 처리하는 작업을 담당합니다.
개발 언어용으로 제공되는 모든 웹 프레임워크를 사용할 수 있습니다.
App Engine에서 애플리케이션의 여러 인스턴스를 실행하며 각 인스턴스에는 요청 처리를 위한 자체 웹 서버가 있습니다. 요청이 임의의 인스턴스로 라우팅될 수 있으므로, 동일한 사용자가 보내는 연속 요청이 같은 인스턴스로 전송되지 않을 수 있습니다. 인스턴스 한 개가 여러 요청을 동시에 처리할 수 있습니다. 인스턴스 수는 트래픽의 변화에 따라 자동으로 조정될 수 있습니다.
할당량 및 한도
App Engine은 트래픽 증가에 따라 애플리케이션에 자동으로 리소스를 할당합니다. 그러나 여기에는 다음과 같은 제한사항이 적용됩니다.
App Engine은 애플리케이션이 요청에 응답하는 시간이 1초 미만인, 지연 시간이 짧은 애플리케이션을 위해 자동 확장 용량을 예약합니다.
CPU 사용량이 많은 애플리케이션의 경우, 동일 서버의 다른 애플리케이션과 효율적으로 리소스를 공유하기 위해 지연 시간이 추가로 발생할 수 있습니다. 정적 파일에 대한 요청은 지연 시간 한도에서 제외됩니다.
애플리케이션에 수신되는 각 요청은 요청 한도에 반영됩니다.
요청에 대한 응답으로 전송되는 데이터는 발신 대역폭(청구 가능) 한도에 반영됩니다.
HTTP 및 HTTPS(보안) 요청은 모두 요청, 수신 대역폭(청구 가능), 발신 대역폭(청구 가능) 한도에 반영됩니다.Google Cloud 콘솔의 할당량 세부정보 페이지도 정보 제공 목적으로 보안 요청, 보안 수신 대역폭, 보안 발신 대역폭을 별도의 값으로 보고합니다.
HTTPS 요청만 이러한 값에 반영됩니다. 자세한 내용은 할당량 페이지를 참조하세요.
다음은 요청 핸들러 사용에 적용되는 한도입니다.
요청 한도
요청 헤더에 최대 15KB까지 허용됩니다.
요청의 총 크기는 32MB로 제한됩니다.
모든 HTTP/2 요청은 애플리케이션 서버로 전달될 때 HTTP/1.1 요청으로 변환됩니다.
SSL 연결은 부하 분산기에서 종료됩니다. 부하 분산기의 트래픽은 암호화된 채널을 통해 인스턴스로 전송된 후 HTTP를 통해 애플리케이션 서버로 전달됩니다. X-Forwarded-Proto 헤더를 통해 원본 요청이 HTTP 또는 HTTPS였는지 알 수 있습니다.
응답 한도
응답은 64k 블록으로 버퍼링됩니다.
응답 크기는 무제한입니다.
응답 시간 제한은 1시간입니다.
응답 헤더 한도는 64KB입니다. 이 제한을 초과하는 응답 헤더는 upstream sent too big header
while reading response header from upstream을 표시하는 로그와 함께 HTTP 502 오류를 반환합니다.
지원되지 않는 HTTP 요청
다음 기능은 App Engine 가변형 환경에서 지원되지 않습니다.
백엔드 서비스로 가는 HTTP/2 트래픽
인스턴스에 직접 액세스하는 HTTP 요청
요청 헤더
수신되는 HTTP 요청에는 클라이언트가 전송한 HTTP 헤더가 포함되어 있습니다. 보안을 위해 일부 헤더는 애플리케이션에 도달하기 전 중간 프록시에 의해 삭제 또는 수정됩니다.
기본적으로 App Engine의 모든 응답은 64k 블록에 버퍼링됩니다. 경우에 따라 버퍼링을 사용 중지하고 클라이언트에 직접 바이트를 스트리밍하는 편이 더 나을 수 있습니다. 지연 GET 또는 서버 전송 이벤트(SSE)를 사용하는 경우 일반적으로 이 방법이 선호됩니다. 버퍼링을 사용 중지하려면 X-Accel-Buffering 응답 헤더를 no로 설정하면 됩니다.
HTTPS 연결 강제 적용
보안상의 이유로 모든 애플리케이션은 클라이언트가 https를 통해 연결하도록 권장해야 합니다. 브라우저에서 특정 페이지 또는 전체 도메인에 대해 http보다 https를 우선 사용하도록 지시하려면 응답에 Strict-Transport-Security 헤더를 설정합니다.
예를 들면 다음과 같습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThe \u003ccode\u003eREGION_ID\u003c/code\u003e is a Google-assigned code based on the region selected during app creation, included in App Engine URLs for apps created after February 2020, but it does not directly correspond to any specific country or province.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine applications handle requests using multiple instances, each with its own web server, and consecutive requests from the same user are not guaranteed to go to the same instance.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine automatically adjusts resources based on traffic, but reserves capacity for low-latency applications responding in under one second, with CPU-intensive applications potentially incurring additional latency.\u003c/p\u003e\n"],["\u003cp\u003eThere are specific limits for request headers (around 15KB) and total request size (around 32MB), while responses are buffered in 64KB blocks, and the maximum response time limit is one hour.\u003c/p\u003e\n"],["\u003cp\u003eFor security and better performance, App Engine applications should encourage HTTPS connections and can enforce it by using the \u003ccode\u003eStrict-Transport-Security\u003c/code\u003e header, while background work should be avoided and offloaded to services like Cloud Tasks for long-running jobs.\u003c/p\u003e\n"]]],[],null,["# How requests are handled\n\n### Region ID\n\nThe \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e is an abbreviated code that Google assigns\nbased on the region you select when you create your app. The code does not\ncorrespond to a country or province, even though some region IDs may appear\nsimilar to commonly used country and province codes. For apps created after\nFebruary 2020, \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e`.r` is included in\nApp Engine URLs. For existing apps created before this date, the\nregion ID is optional in the URL.\n\nLearn more\n[about region IDs](/appengine/docs/flexible/python/how-requests-are-routed#region-id). \nOK \nGo Java Node.js PHP Python Ruby .NET Custom\n\nThis document describes how your App Engine application receives requests and\nsends responses. For more details, see the\n[Request Headers reference](/appengine/docs/flexible/reference/request-headers).\n\nIf your application uses [services](/appengine/docs/an-overview-of-app-engine),\nyou can address requests to a specific service or a specific version of that\nservice. For more information about service addressability, see\n[How Requests are\nRouted](/appengine/docs/flexible/how-requests-are-routed).\n\nHandling requests\n-----------------\n\nYour application is responsible for starting a webserver and handling requests.\nYou can use any web framework that is available for your development language.\n\n\u003cbr /\u003e\n\nApp Engine runs multiple instances of your application, and each\ninstance has its own web server for handling requests. Any request can be routed\nto any instance, so consecutive requests from the same user are not necessarily\nsent to the same instance. An instance can handle multiple requests\nconcurrently. The number of instances can be adjusted automatically as traffic\nchanges.\n\n\nQuotas and limits\n-----------------\n\nApp Engine automatically allocates resources to your application as\ntraffic increases. However, this is bound by the following restrictions:\n\n- App Engine reserves automatic scaling capacity for applications with\n low latency, where the application responds to requests in less than one\n second.\n\n- Applications that are heavily CPU-bound may also incur some additional latency\n in order to efficiently share resources with other applications on the same\n servers. Requests for static files are exempt from these latency limits.\n\nEach incoming request to the application counts toward the **Requests** limit.\nData sent in response to a request counts toward the\n**Outgoing Bandwidth (billable)** limit.\n\nBoth HTTP and HTTPS (secure) requests count toward the **Requests** , **Incoming\nBandwidth (billable)** , and **Outgoing Bandwidth (billable)** limits. The\nGoogle Cloud console\n[Quota Details page](https://console.cloud.google.com/appengine/quotadetails)\nalso reports **Secure Requests** , **Secure Incoming Bandwidth** , and\n**Secure Outgoing Bandwidth** as separate values for informational purposes.\nOnly HTTPS requests count toward these values. For more information, see the\n[Quotas](/appengine/docs/quotas#Requests) page.\n\nThe following limits apply specifically to the use of request handlers:\n\n### Request limits\n\n- A maximum of \\~15KB in request headers is allowed.\n- The total size of the request is limited to \\~32MB.\n- All HTTP/2 requests will be translated into HTTP/1.1 requests when forwarded to the application server.\n- SSL connections end at the load balancer. Traffic from the load balancer is sent to the instance over an encrypted channel, and then forwarded to the application server over HTTP. The X-Forwarded-Proto header lets you understand if the origin request was HTTP or HTTPS.\n\n### Response limits\n\n- Responses are buffered by 64k blocks.\n- The response size is unlimited.\n- The response time limit is one hour.\n- The response header limit is 64 KB. Response headers that exceed this limit will return HTTP 502 errors, with logs showing `upstream sent too big header\n while reading response header from upstream`.\n\n### Unsupported HTTP requests\n\nThe following features are not supported by\nApp Engine flexible environment:\n\n- HTTP/2 traffic to the backend service.\n- HTTP requests that directly access instances.\n\nRequest headers\n---------------\n\nAn incoming HTTP request includes the HTTP headers sent by the client. For\nsecurity purposes, some headers are sanitized or amended by intermediate proxies\nbefore they reach the application.\n\nFor more information, see the\n[Request headers reference](/appengine/docs/flexible/reference/request-headers#request_headers).\n\n### Disabling buffering\n\nBy default, all responses from App Engine are buffered in 64k-blocks. In\nsome cases, it might make sense to disable buffering and directly stream bytes\nto the client. This is generally preferred when using hanging GETs or Server\nSent Events (SSEs). To disable buffering, you can set the `X-Accel-Buffering`\nresponse header to `no`.\n\nForcing HTTPS connections\n-------------------------\n\nFor security reasons, all applications should encourage clients to connect over\n`https`. To instruct the browser to prefer `https` over `http` for a given page\nor entire domain, set the `Strict-Transport-Security` header in your responses.\nFor example: \n\n Strict-Transport-Security: max-age=31536000; includeSubDomains\n\n\u003cbr /\u003e\n\n| **Caution:** Clients that have received the header in the past will refuse to connect if `https` becomes non-functional or is disabled for any reason. To learn more, see this [Cheat Sheet on HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html).\n\nHandling asynchronous background work\n-------------------------------------\n\nBackground work is any work that your app performs for a request after you have\ndelivered your HTTP response. Avoid performing background work in your app, and\nreview your code to make sure all asynchronous operations finish before you\ndeliver your response.\n\nFor long-running jobs, we recommend using [Cloud Tasks](/tasks). With\nCloud Tasks, HTTP requests are long-lived and return a response only\nafter any asynchronous work ends.\n| **Warning:** Performing asynchronous background work can result in higher billing. App Engine might scale up additional instances due to high CPU load, even if there are no active requests. Users may also experience increased latency because of requests waiting in the pending queue for available instances."]]
