참고: Java 8은 2024년 1월 31일 지원 종료되었습니다. 기존 Java 8 애플리케이션은 계속 실행되고 트래픽을 수신합니다. 그러나 지원 종료 날짜 이후에는 해당 런타임을 사용하는 애플리케이션의 재배포를 App Engine에서 차단할 수 있습니다. 지원되는 최신 Java 버전으로 마이그레이션하는 것이 좋습니다.

인스턴스 관리 방법

인스턴스는 App Engine의 기본 구성요소로서 애플리케이션을 성공적으로 호스팅하는 데 필요한 모든 리소스를 제공합니다. 언제든지 인스턴스 한 개 또는 여러 개에서 애플리케이션을 실행할 수 있으며 요청은 인스턴스 전체에 분산됩니다. 의도치 않게 인스턴스가 서로 영향을 주지 않도록 하기 위해 인스턴스마다 보안 레이어가 있습니다.

App Engine은 트래픽 변동에 따라 자동으로 인스턴스를 만들고 종료하거나 트래픽 양과 관계없이 실행될 인스턴스 수를 지정할 수 있습니다. 새 인스턴스를 만드는 방법과 시기를 결정하려면 앱의 확장 유형을 지정합니다. 확장 설정은 app.yaml 파일의 일부로 App Engine 버전 수준에서 적용됩니다.

확장 유형

App Engine은 인스턴스가 생성되는 방식과 시기를 제어하는 다음 확장 유형을 지원합니다.

자동(기본값)
기본
수동

앱의 appengine-web.xml에서 확장 유형을 지정합니다. 기본적으로 앱은 자동 확장을 사용하므로 App Engine에서 유휴 인스턴스 수를 관리합니다.

자동 확장: 자동 확장은 요청 속도, 응답 지연 시간, 기타 애플리케이션 측정항목을 기반으로 인스턴스를 생성합니다. automatic_scaling 요소를 구성하여 이러한 각 측정항목의 임곗값과 항상 실행되는 최소 인스턴스 수를 지정할 수 있습니다.

기본 확장: 기본 확장은 애플리케이션이 요청을 수신하면 인스턴스를 만듭니다. 애플리케이션이 유휴 상태가 되면 각 인스턴스가 종료됩니다. 기본 확장은 간헐적이거나 사용자 활동에 따라 진행되는 작업에 이상적입니다.

수동 확장: 수동 확장은 로드 수준과 관계없이 지속적으로 실행되는 인스턴스 수를 지정합니다. 따라서 장기적으로 메모리 상태에 의존하는 복잡한 초기화 등의 작업과 애플리케이션을 지원합니다.

이 표에서는 3가지 확장 유형의 성능 기능을 비교합니다.

기능	자동 확장	기본 확장	수동 확장
요청 제한 시간	HTTP 요청 및 태스크 큐 작업의 경우 10분 앱이 이 제한 시간 내에 요청을 반환하지 않으면 App Engine은 요청 핸들러를 중단하고 코드가 처리할 오류를 생성합니다. 기존 런타임(자바 8, PHP 5, Python 2): 태스크 큐 작업 및 크론 작업의 요청 제한 시간은 10분입니다. 다른 HTTP 요청 제한 시간은 1분입니다.	HTTP 요청 및 태스크 큐 작업에 24시간. 앱이 이 제한 시간 내에 요청을 반환하지 않으면 App Engine은 요청 핸들러를 중단하고 코드가 처리할 오류를 생성합니다. 기본 확장 인스턴스는 `/_ah/start`를 처리하고 HTTP 응답 코드를 반환하지 않고 장시간 프로그램이나 스크립트를 실행할 수 있습니다.	기본 확장과 동일합니다.
백그라운드 스레드	허용되지 않음	허용	허용
상주	인스턴스는 사용량 패턴에 따라 종료됩니다.	인스턴스는 `idle-timeout` 매개변수에 따라 종료됩니다. 예를 들어 `idle-timeout`을 초과할 때까지 요청이 수신되지 않아 유휴 상태가 된 인스턴스는 종료됩니다.	인스턴스가 메모리에 유지되고 상태는 요청 간에 보존됩니다. 인스턴스가 중지되면 `/_ah/stop` 요청이 로그에 표시됩니다. `/_ah/stop` 핸들러 또는 등록된 종료 후크가 있으면 30초가 지난 후 종료됩니다.
시작 및 종료	인스턴스가 필요할 때 생성되어 요청을 처리하고 유휴 상태가 되면 자동으로 종료됩니다.	`idle-timeout` 구성 매개변수에 따라 인스턴스가 필요할 때 생성되어 요청을 처리하고 유휴 상태가 되면 자동으로 종료됩니다. 수동으로 중지된 인스턴스에는 강제 종료되기 전에 요청 처리를 완료할 수 있도록 30초가 제공됩니다.	App Engine은 시작 요청을 `/_ah/start`에 대한 빈 GET 요청의 형태로 인스턴스에서 자동으로 보냅니다. 기본 확장과 마찬가지로 수동으로 중지된 인스턴스에는 강제 종료되기 전에 요청 처리를 완료할 수 있도록 30초가 제공됩니다.
인스턴스 주소 지정	인스턴스가 익명입니다.	서비스 's'의 버전 'v'에 대한 인스턴스 'i'는 `https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com`과 같은 URL로 주소를 지정할 수 있습니다. 커스텀 도메인에 와일드 카드 하위 도메인 매핑을 설정하면 `https://s.domain.com` 또는 `https://i.s.domain.com` 형식의 URL을 통해 서비스 또는 인스턴스의 주소를 지정할 수도 있습니다. 각 인스턴스의 상태를 안정적으로 캐시하고 후속 요청에서 검색할 수 있습니다.	기본 확장과 동일합니다.
확장	App Engine에서 처리량에 따라 인스턴스 수를 자동으로 확장합니다. 이 배율은 구성 파일에서 버전 단위로 제공되는 `automatic_scaling` 설정을 고려합니다.	기본 확장을 사용하는 서비스는 `basic_scaling` 설정의 `max_instances` 매개변수에 있는 최대 인스턴스 수 설정을 통해 구성됩니다. 실시간 인스턴스 수는 처리량에 따라 확장됩니다.	해당 서비스의 구성 파일에서 각 버전의 인스턴스 수를 구성합니다. 일반적으로 인스턴스 수는 메모리에 유지되는 데이터 세트 크기 또는 원하는 오프라인 작업 처리량에 대응합니다.

동적 인스턴스 확장

기본 또는 자동 확장을 사용하는 App Engine 애플리케이션은 수신되는 요청 볼륨에 따라 지정된 시간에 여러 동적 인스턴스를 통해 구동됩니다. 애플리케이션에 대한 요청이 증가하면 동적 인스턴스 수도 증가할 수 있습니다.

기본 확장 기능이 있는 앱

기본 확장을 사용하면 수신 요청 볼륨 증가에 따라 지연 시간이 늘어나더라도 App Engine은 비용을 낮게 유지하려고 합니다.

수신 요청을 처리할 수 있는 기존 인스턴스가 없으면 App Engine은 새 인스턴스를 시작합니다. 새 인스턴스를 시작한 후에도 새 인스턴스가 시작 프로세스를 완료할 때까지 일부 요청을 큐에 추가해야 할 수 있습니다. 지연 시간을 최소화하려면 자동 확장을 사용하여 새 인스턴스를 미리 만듭니다.

자동 확장 기능이 있는 앱

자동 확장을 사용하면 앱의 각 인스턴스는 수신 요청에 대한 자체 큐를 갖습니다. 큐가 앱 지연 시간에 큰 영향을 미칠 정도로 길어지기 전에 App Engine은 자동으로 새 인스턴스를 한 개 이상 만들어 증가하는 부하를 처리합니다.

원하는 성능과 발생할 수 있는 비용 간의 균형을 이루도록 자동 확장 설정을 구성할 수 있습니다. 다음 표에서는 이러한 설정을 설명합니다.

자동 확장 설정	설명
대상 CPU 사용률	CPU 사용률 기준을 설정해 트래픽을 처리하는 인스턴스를 늘리기 시작할 CPU 사용량 기준을 지정합니다.
대상 처리량 사용률	기준 도달 후 트래픽을 처리하는 인스턴스를 늘리기 시작할 동시 요청 수의 처리량 기준을 설정합니다.
최대 동시 요청 수	스케줄러가 새 인스턴스를 만들기 전에 인스턴스가 수락할 수 있는 최대 동시 요청 수를 설정합니다.

App Engine 스케줄러 설정 동영상을 통해 이 설정의 효과를 확인하세요.

축소

요청 볼륨이 감소하면 App Engine에서는 인스턴스 수를 줄입니다. 이러한 축소를 통해 애플리케이션의 현재 인스턴스 모두 최적의 효율성과 비용 효과에 맞게 사용할 수 있습니다.

애플리케이션이 전혀 사용되지 않으면 App Engine은 연결된 동적 인스턴스를 중지합니다. 하지만 필요하면 바로 손쉽게 다시 로드합니다. 인스턴스를 다시 로드하면 요청이 로드되고 사용자에게 추가 지연 시간이 발생할 수 있습니다.

최소 유휴 인스턴스 수를 지정할 수 있습니다. 요청 볼륨을 토대로 애플리케이션의 적절한 유휴 인스턴스 수를 설정하면 비정상적으로 많은 요청이 발생하지 않는 한 애플리케이션은 거의 지연 시간 없이 모든 요청을 처리할 수 있습니다.

자동 확장에서 축소

앱에서 자동 확장을 사용하는 경우 약 15분 동안 비활성 상태가 지속되면 유휴 인스턴스 종료가 시작됩니다. 유휴 인스턴스 하나 이상을 계속 실행하려면 min_idle_instances 값을 1 이상으로 설정합니다.

요청의 확장 및 일괄 처리

예를 들어 처리를 위해 태스크 큐에 전송하는 것과 같이 서비스에 일괄 요청을 보내면 많은 인스턴스가 빠르게 생성됩니다. 가능하다면 전송되는 초당 요청 수에 비율 제한을 적용해 이를 제어하는 것이 좋습니다. 예를 들어 Google Tasks를 사용하면 태스크가 푸시되는 비율을 제어할 수 있습니다.

인스턴스 수명 주기

인스턴스 상태

자동 확장되는 서비스의 인스턴스는 항상 실행 중입니다. 그러나 수동 또는 기본 확장 서비스의 인스턴스는 실행 중이거나 중지된 상태일 수 있습니다. 서비스와 버전이 동일한 모든 인스턴스가 같은 상태를 공유합니다. 버전을 관리하여 인스턴스 상태를 변경할 수 있습니다. 먼저

Google Cloud 콘솔의 버전 페이지 사용
gcloud app versions start 및 gcloud app versions stop 명령어 사용
모듈 서비스 사용

시작

각 서비스 인스턴스는 /_ah/start에 대한 빈 HTTP GET 요청인 시작 요청에 따라 생성됩니다. App Engine은 이 요청을 전송하여 인스턴스를 만들지만 사용자는 /_ah/start에 요청을 전송할 수 없습니다. 수동 및 기본 확장 인스턴스가 시작 요청에 응답해야 다른 요청을 처리할 수 있습니다. 시작 요청은 두 가지 목적으로 사용될 수 있습니다.

추가 요청을 수락하지 않고 무기한 실행되는 프로그램 시작
추가 트래픽을 수신하기 전에 인스턴스 초기화

수동, 기본, 자동 확장 인스턴스는 각각 다르게 시작됩니다. 수동 확장 인스턴스를 시작하면 App Engine은 즉시 각 인스턴스에 /_ah/start 요청을 보냅니다. 기본 확장 서비스의 인스턴스를 시작하면 App Engine은 이 인스턴스가 트래픽을 수락하도록 허용하지만 /_ah/start 요청은 첫 번째 사용자 요청을 수신할 때까지 인스턴스로 전송되지 않습니다. 여러 기본 확장 인스턴스는 증가된 트래픽을 처리하기 위해 필요한 경우에만 시작됩니다. 자동 확장 인스턴스는 /_ah/start 요청을 수신하지 않습니다.

인스턴스가 /_ah/start 요청에 HTTP 상태 코드 200–299 또는 404로 응답하면 성공적으로 시작한 것으로 간주되어 추가 요청을 처리할 수 있습니다. 그렇지 않으면 App Engine은 인스턴스를 종료합니다. 수동 확장 인스턴스는 즉시 다시 시작되는 반면 기본 확장 인스턴스는 트래픽 처리를 위해 필요한 경우에만 다시 시작됩니다.

종료

종료 프로세스는 다음과 같이 예정되거나 예정되지 않은 다양한 이벤트에 의해 트리거될 수 있습니다.

인스턴스가 너무 많고 앱 요청(트래픽)이 부족합니다.
수동으로 인스턴스를 중지합니다.
업데이트된 버전을 서비스에 배포합니다.
인스턴스가 구성된 instance_class의 최대 메모리를 초과합니다.
애플리케이션에 인스턴스 시간 할당량이 부족합니다.
인스턴스를 실행 중인 현재 머신이 다시 시작되었거나 부하 분산을 향상시키도록 App Engine이 인스턴스를 이동시켜 인스턴스가 다른 머신으로 이동했습니다.

축소에서 이전에 설명한 것처럼 App Engine 표준 환경의 '필요한 만큼만 지불' 플랫폼의 이점 중 하나는 트래픽이 없을 때 시스템이 인스턴스 수를 0까지 자동 조정한다는 것입니다. 따라서 요청을 연속으로 수신하지 않는 작은 애플리케이션의 경우에도 App Engine을 비용 효율적으로 활용할 수 있습니다. 인스턴스를 종료해야 하는 경우 새로 추가되는 요청은 다른 인스턴스(있는 경우)로 라우팅되고 현재 처리 중인 요청을 완료할 수 있는 시간이 제공됩니다.

인스턴스를 종료해야 할 때 App Engine은 KILL(SIGKILL) 신호를 전송하여, 인스턴스를 종료합니다.

로드 요청

App Engine이 애플리케이션의 새 인스턴스를 만들면 이 인스턴스는 먼저 요청을 처리하는 데 필요한 라이브러리와 리소스를 로드해야 합니다. 이 작업은 인스턴스에 대한 첫 번째 요청 중에 진행되며, 이를 로드 요청이라고 합니다. 로드 요청 중에는 애플리케이션이 초기화되므로 요청을 처리하는 데 시간이 오래 걸릴 수 있습니다.

다음 권장사항을 따르면 로드 요청 시간을 단축할 수 있습니다.

시작에 필요한 코드만 로드합니다.
디스크 액세스를 가능한 최소화합니다.
경우에 따라서는 여러 개별 파일보다는 zip 또는 jar 파일 1개에서 코드를 로드하는 것이 더 빠릅니다.

준비 요청

준비 요청은 실시간 요청에 앞서 애플리케이션 코드를 미리 인스턴스에 로드하는 특정 유형의 로드 요청입니다. 수동 또는 기본 확장 인스턴스는 /_ah/warmup 요청을 수신하지 않습니다.

준비 요청을 사용하는 방법에 대한 자세한 내용은 준비 요청 구성을 참조하세요.

인스턴스 업타임

App Engine은 수동 및 기본 확장 인스턴스를 무기한으로 실행하려 합니다. 하지만 현재 수동 및 기본 확장 인스턴스의 가동 시간은 보장되지 않습니다. 조기 종료 또는 잦은 다시 시작을 유발하는 하드웨어와 소프트웨어 오류가 사전 경고 없이 발생할 수 있으며, 이를 해결하는 데 상당한 시간이 걸릴 수 있습니다. 따라서 이러한 오류를 감안하여 작동하도록 애플리케이션을 구성해야 합니다.

인스턴스 재시작으로 인한 다운타임 방지에 효과적인 전략은 다음과 같습니다.

인스턴스 재시작 또는 새 인스턴스 시작에 걸리는 시간을 줄입니다.
계산이 장기간 실행되는 경우 해당 상태부터 다시 시작할 수 있도록 정기적으로 체크포인트를 만듭니다.
인스턴스에 아무것도 저장되지 않도록 앱이 '스테이트리스(Stateless)'이어야 합니다.
큐를 사용하여 태스크를 비동기적으로 실행합니다.
인스턴스를 수동으로 확장하도록 구성한 경우에는 다음을 수행합니다.
- 여러 인스턴스에서 부하 분산을 사용합니다.
- 일반적인 트래픽을 처리하는 데 필요한 수보다 많은 인스턴스를 구성합니다.
- 수동 확장 인스턴스를 사용할 수 없을 때 캐시된 결과를 사용하는 대체 로직을 작성합니다.

App Engine 표준 환경의 NTP

App Engine 표준 환경에는 Google NTP 서버를 사용하는 네트워크 시간 프로토콜(NTP) 서비스가 있습니다. 그러나 NTP 서비스를 수정할 수 없습니다.