인스턴스는 App Engine에서 애플리케이션을 자동으로 확장하는 데 사용하는 컴퓨팅 단위입니다.
애플리케이션은 특정 시점에 1개 또는 여러 인스턴스에서 실행될 수 있으며, 요청은 모든 인스턴스로 분산됩니다.
수동 확장을 사용하는 인스턴스는 무기한으로 실행되어야 하지만 인스턴스가 실패로 인해 조기 종료되거나 업데이트를 위해 재시작될 수 있으므로 업타임이 보장되지는 않습니다. 조기 종료나 잦은 다시 시작을 초래하는 하드웨어 또는 소프트웨어 오류는 예고 없이 발생할 수 있으며 해결하는 데 상당한 시간이 걸릴 수 있습니다.
사용 가능한 업데이트가 있으면 모든 가변형 인스턴스를 매주 다시 시작할 수 있습니다. 이 일정은 보장되지 않습니다.
다시 시작하는 동안 이전 버전과 호환되는 중요한 업데이트가 기본 운영체제에 자동으로 적용됩니다. 다시 시작해도 애플리케이션의 이미지는 동일하게 유지됩니다.
상태 확인
App Engine은 인스턴스가 실행 중인지 확인하고, 인스턴스가 완전히 시작되었고 들어오는 요청을 수락할 준비가 되었는지 확인하기 위해 상태 확인 요청을 주기적으로 전송합니다. 기본적으로 이러한 상태 확인이 사용 설정되어 있으며, 이를 분할 상태 확인이라고 부릅니다. 상태 확인을 수신하는 인스턴스는 지정된 시간 간격 내에 상태 확인에 답해야 합니다.
분할 상태 확인의 기본 동작을 애플리케이션으로 확장해야 하는 경우 app.yaml 파일을 맞춤설정하여 두 가지 상태 확인 유형을 구성할 수 있습니다.
활성 확인은 VM 인스턴스 및 해당 컨테이너가 실행 중인지 확인합니다. VM 인스턴스에서 활성 확인이 실패하면 인스턴스가 자동으로 다시 시작됩니다. 구성된 임계값 및 시간 간격으로 인해 또는 컨테이너 충돌로 인해 활성 확인이 실패할 수 있습니다.
준비 확인은 VM 인스턴스가 들어오는 요청을 수락할 준비가 되었는지 확인합니다. VM 인스턴스에서 준비 확인이 실패하면 VM 인스턴스의 시작 작업이 완료되지 않았고 요청을 수신할 준비가 되지 않았음을 나타냅니다.
VM 인스턴스가 준비 확인을 통과하고 시작 작업이 완료되었으면 사용 가능한 인스턴스 풀에 추가됩니다.
인스턴스의 상태 확인이 진행될 때 App Engine 로그에는 인스턴스가 다음 상태 중 하나로 표시될 수 있습니다.
정상. 인스턴스에 상태 확인 요청이 수신되었고 인스턴스가 요청을 처리하는 중입니다. 정상 상태는 인스턴스에 사용 가능한 디스크 공간이 820MB 넘게 있음을 나타내며 HTTP 상태 코드 200으로 상태 점검에 응답해야 합니다.
비정상 인스턴스가 상태 확인 요청을 거부하고 지정된 수의 연속되는 상태 확인 요청에 응답하지 못했습니다.
비정상적 인스턴스가 사전에 지정된 수의 연속되는 상태 확인에 응답하지 못하면 App Engine은 계속해서 상태 확인 요청을 보내고 인스턴스를 다시 시작합니다.
레임덕. 인스턴스가 종료하거나 다시 시작되도록 예약되었습니다.
종료되는 동안 인스턴스는 진행 중인 요청을 완료하고 새 요청을 거부합니다. 앱은 인스턴스가 요청을 처리할 수 없음을 나타내는 503 코드를 반환합니다. 인스턴스가 종료되거나 다시 시작되기 전에 종료 스크립트는 실행 기간이 제한되며, 이를 더 짧게 또는 더 길게 구성할 수 없습니다.
앱 레임덕. 인스턴스가 트래픽 처리를 위해 준비하는 중입니다. 앱은 인스턴스가 요청을 처리할 수 없음을 나타내는 503 코드를 반환합니다. VM 인스턴스가 시작 작업을 완료하고 트래픽을 처리할 준비가 되었으면 인스턴스가 정상 상태가 되고 요청을 처리합니다. VM 인스턴스가 시간 내에 시작하지 않으면 인스턴스가 비정상으로 변경되고 삭제됩니다.
레임덕과 앱 레임덕 동작은 VM 인스턴스가 거치는 정상적인 프로세스의 일부입니다.
리소스 사용량 모니터링
Google Cloud 콘솔의 인스턴스 페이지에서 인스턴스의 성능을 파악할 수 있습니다. 각 인스턴스의 메모리 및 CPU 사용량, 업타임, 요청 수, 기타 통계를 확인할 수 있습니다. 특정 인스턴스의 종료 프로세스를 직접 시작할 수도 있습니다.
App Engine 가변형 환경의 NTP
App Engine 가변형 환경에는 Google NTP 서버를 사용하는 네트워크 시간 프로토콜(NTP) 서비스가 있습니다. 그러나 가변형 환경의 NTP 서비스는 수정할 수 없습니다.
애플리케이션 실행 중에 수신되는 요청은 해당 서비스나 버전의 기존 인스턴스 또는 새 인스턴스로 라우팅됩니다. 각 활성 버전에는 실행 중인 인스턴스가 하나 이상 있어야 하며 서비스나 버전의 확장 유형에 따라 추가 인스턴스 생성 방법이 결정됩니다.
앱의 app.yaml에서 확장 유형을 지정합니다.
기본적으로 앱은 자동 확장을 사용하므로 App Engine에서 유휴 인스턴스 수를 관리합니다.
자동 확장
자동 확장은 요청 속도, 응답 지연 시간, 기타 애플리케이션 측정항목을 기반으로 인스턴스를 생성합니다. automatic_scaling 요소를 구성하여 이러한 각 측정항목의 임곗값과 항상 실행되는 최소 인스턴스 수를 지정할 수 있습니다.
수동 확장
수동 확장은 로드 수준과 관계없이 지속적으로 실행되는 인스턴스 수를 지정합니다. 따라서 장기적으로 메모리 상태에 의존하는 복잡한 초기화 등의 작업과 애플리케이션을 지원합니다.
서비스 관리
인스턴스의 확장 유형에 따라 Google Cloud 콘솔이나 Google Cloud CLI에서 서비스와 버전을 관리할 수 있습니다.
버전 중지
App Engine의 각 버전은 처리하도록 구성한 트래픽 양에 따라 인스턴스 하나 이상 내에서 실행됩니다.
[[["이해하기 쉬움","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\u003eApp Engine uses instances as computing units to automatically scale applications, and requests are distributed across one or more instances.\u003c/p\u003e\n"],["\u003cp\u003eInstances undergo periodic health checks, which include liveness checks to verify the instance and container are running, and readiness checks to ensure the instance is ready to accept requests.\u003c/p\u003e\n"],["\u003cp\u003eInstances can be in various states such as healthy, unhealthy, lameduck, or app lameduck, reflecting their operational status and ability to handle requests.\u003c/p\u003e\n"],["\u003cp\u003eAutomatic scaling adjusts the number of instances based on request rates and application metrics, while manual scaling runs a fixed number of instances regardless of load.\u003c/p\u003e\n"],["\u003cp\u003eServices and versions within App Engine can be managed, stopped, or deleted through the Google Cloud console or gcloud CLI.\u003c/p\u003e\n"]]],[],null,["# How instances are managed\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nInstances are the computing units that App Engine uses to automatically\nscale your\n[application](/appengine/docs/an-overview-of-app-engine).\nAt any given time, your application can be running on one instance or many\ninstances, with requests being spread across all of them.\n\nYour instances with manual scaling should run indefinitely, but\nthere is no uptime guarantee as instances can get early termination due to failures or restart for the updates. Hardware or software failures that cause early\ntermination or frequent restarts can occur without warning and can take\nconsiderable time to resolve.\n\nAll flexible instances may be restarted on a weekly basis\nif there are updates available. This schedule is not guaranteed.\nDuring restarts,\ncritical, backwards-compatible updates are automatically rolled out to the\nunderlying operating system. Your application's image will remain the same\nacross restarts.\n\nHealth checking\n---------------\n\nApp Engine sends periodic health check requests to confirm that an instance\nis running, and to check that an instance is fully\nstarted and ready to accept incoming requests. By default, these health checks\nare enabled and are known as **split health checks**. An instance that receives\na health check must answer the health check within a specified time interval.\n\nIf you need to extend the default behavior of split health checks to your\napplication, you can customize the [`app.yaml`](/appengine/docs/flexible/reference/app-yaml#updated_health_checks) file to configure two types of health checks:\n\n- **Liveness checks** detect that a VM instance and its container are running. When a VM instance fails the liveness check, the instance is restarted automatically. Liveness checks can fail due to the configured thresholds and time intervals, or due to the container crashing.\n- **Readiness checks** detect that a VM instance is ready to accept incoming requests. If a VM instance fails the readiness check, it means that the VM instance has not finished its startup and is not ready to receive requests. When the VM instance passes the readiness check and has completed its startup, it is added to the pool of available instances.\n\nLearn more about split health check behaviors in the [Migrating to Split Health Checks](/appengine/docs/flexible/migrating-to-split-health-checks) guide.\n\nAs the instance goes through these health checks, the\n[App Engine logs](https://console.cloud.google.com/logs/query) can indicate that the\ninstance is in any of the following states:\n\n- **Healthy** . The instance received the health check requests and is processing the requests. A healthy status indicates that the instance has more than 820 MB of available disk space and should respond to a health check with an HTTP status code of `200`.\n- **Unhealthy**. The instance refused the health check requests and failed to respond to a specified number of consecutive health check requests. App Engine continues to send health check requests and restarts the instance if an unhealthy instance continues to fail to respond to a predetermined number of consecutive health checks.\n- **Lameduck** . The instance is scheduled to be shut down or restarted. During shutdowns, the instance finishes up ongoing requests, and refuses new requests. The app returns a `503` code to indicate that the instance is unable to handle requests. Before an instance shuts down or restarts, the shutdown script has a limited time period to run, and cannot be configured to be shorter or longer.\n- **App Lameduck** . The instance is preparing to serve traffic. The app returns a `503` code to indicate that the instance is unable to handle requests. When a VM instance has completed startup and is ready to serve traffic, the instance will become healthy and process requests. If a VM instance does not start up in time, the instance changes to unhealthy and gets removed.\n\nBoth lameduck and app lameduck behaviors are part of a normal process that the\nVM instance goes through.\n\nMonitoring resource usage\n-------------------------\n\nThe Instances page of the [Google Cloud console](https://console.cloud.google.com/appengine/instances) provides visibility into how your instances are performing. You can see the memory and CPU usage of each instance, uptime, number of requests, and other statistics. You can also manually initiate the shutdown process for any instance.\n\nNTP with App Engine flexible environment\n----------------------------------------\n\nThe App Engine flexible environment has network time protocol (NTP) services which use Google NTP\nservers. However, the NTP services in the flexible environment is not editable.\n\nInstance location\n-----------------\n\nInstances are automatically located by geographical region according to the\n[project settings](/appengine/docs/flexible/managing-projects-apps-billing).\n\nInstance scaling\n----------------\n\nWhile an application is running, incoming requests are routed to an existing or\nnew instance of the appropriate service/version. Each active version must have\nat least one instance running, and the scaling type of a service/version\ncontrols how additional instances are created.\nYou specify the scaling type in your app's\n[`app.yaml`](/appengine/docs/flexible/reference/app-yaml#services).\nBy default, your app uses automatic scaling, which means App Engine will\nmanage the number of idle instances.\n\nAutomatic scaling\n: Automatic scaling creates instances based on request rate, response latencies,\n and other application metrics. You can specify thresholds for each of these\n metrics, as well as a minimum number instances to keep running at all times\n by configuring the [`automatic_scaling`](/appengine/docs/flexible/reference/app-yaml#automatic_scaling) element.\n\nManual scaling\n: Manual scaling specifies the number of instances that continuously run\n regardless of the load level. This allows tasks such as complex initializations\n and applications that rely on the state of the memory over time.\n\nManage services\n---------------\n\nDepending on the [scaling type](#instance_scaling) of your instance, you can manage\nservices and versions in the Google Cloud console or Google Cloud CLI.\n\n### Stop a version\n\nEach version in App Engine runs within one or more instances, depending\non how much traffic you configured it to handle.\n\nClick the tab for instructions on using the tool of your choice: \n\n### Console\n\nTo stop or disable a version for your service:\n\n1. Go to the App Engine **Versions** page in the Google Cloud console:\n\n [Go to Versions](https://console.cloud.google.com/appengine/versions)\n2. Select a version from the table, and click **Stop**.\n\n### gcloud\n\nRun the following: \n\n gcloud app versions stop --service=\u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e \u003cvar translate=\"no\"\u003eVERSION\u003c/var\u003e\n\nReplace:\n\n- \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e with the name of your service.\n- \u003cvar translate=\"no\"\u003eVERSION\u003c/var\u003e with the version name of your service.\n\n### Delete a service\n\nEach service can be configured to use different runtimes and to operate with\ndifferent performance settings. You can't delete the default service. Deleting a\nservice also deletes all of its accompanying versions in your project.\n\nClick the tab for instructions on using the tool of your choice: \n\n### Console\n\nTo delete a service:\n\n1. Go to the App Engine **Services** page in the Google Cloud console:\n\n [Go to Services](https://console.cloud.google.com/appengine/services)\n2. Select a service from the table, and click **Delete**.\n\n### gcloud\n\nRun the following: \n\n gcloud app services delete \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e\n\nReplace:\n\n- \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e with the name of your service."]]
