인스턴스 관리 방식

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

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

확장 유형

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

• 자동(기본값)
• 기본
• 수동

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

자동 확장

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

기본 확장

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

수동 확장

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

동적 인스턴스 확장

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

기본 확장 기능이 있는 앱

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

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

자동 확장 기능이 있는 앱

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

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

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은 일반적으로 STOP(SIGTERM) 신호를 앱 컨테이너로 전송합니다. 앱이 이 이벤트에 응답할 필요는 없지만 컨테이너가 종료되기 전에 이를 사용하여 필요한 정리 작업을 수행할 수 있습니다. 정상 조건에서 시스템은 앱이 중지할 때까지 최대 2초까지 기다린 후 KILL(SIGKILL) 신호를 전송합니다. 앱에서 SIGTERM 신호가 포착되지 않으면 인스턴스가 즉시 종료됩니다.

표시되는 일부 인스턴스 종료 로그 메시지는 다음과 같습니다.

[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit

이러한 로그 메시지는 오류 조건이 아닌 정상적인 인스턴스 종료 프로세스를 나타냅니다. 로그의 [start] 및 Start는 start라는 플랫폼 프로세스를 나타내며 인스턴스 또는 앱 시작과 아무 관련이 없습니다.

로드 요청

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

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

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

준비 요청

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

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

인스턴스 업타임

App Engine은 수동 및 기본 확장 인스턴스를 무기한으로 실행하려 합니다. 하지만 현재 수동 및 기본 확장 인스턴스의 업타임은 보장되지 않습니다.

App Engine 표준 환경의 NTP

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

서비스 관리

인스턴스의 확장 유형에 따라 Google Cloud 콘솔이나 Google Cloud CLI에서 서비스와 버전을 관리할 수 있습니다.

버전 중지

App Engine의 각 버전은 처리하도록 구성한 트래픽 양에 따라 인스턴스 하나 이상 내에서 실행됩니다.

선택한 도구 사용에 관한 안내를 보려면 해당 탭을 클릭하세요.

  gcloud app versions stop --service=SERVICE VERSION

서비스 삭제

서비스마다 런타임을 다르게 사용하고 다른 성능 설정으로 작동하도록 구성할 수 있으며 기본 서비스는 삭제할 수 없습니다. 서비스를 삭제하면 프로젝트에서 함께 제공되는 모든 버전도 삭제됩니다.

선택한 도구 사용에 관한 안내를 보려면 해당 탭을 클릭하세요.

  gcloud app services delete SERVICE