인스턴스 관리 방법

인스턴스는 App Engine의 기본 구성 요소로서 애플리케이션을 성공적으로 호스팅하는 데 필요한 모든 리소스를 제공합니다. 언어 런타임, App Engine API, 애플리케이션의 코드, 메모리가 여기에 포함됩니다. 의도치 않게 인스턴스가 서로 영향을 주지 않도록 하기 위해 인스턴스마다 보안 레이어가 있습니다.

인스턴스는 App Engine에서 애플리케이션의 자동 확장을 위해 사용되는 컴퓨팅 단위입니다. 언제든지 인스턴스 한 개 또는 여러 인스턴스에서 애플리케이션을 실행할 수 있으며, 요청은 인스턴스 전체에 분산됩니다.

인스턴스 소개

인스턴스는 상주 인스턴스 또는 동적 인스턴스입니다. 동적 인스턴스는 현재 요구에 따라 자동으로 시작되고 종료됩니다. 상주 인스턴스는 항상 실행되어 애플리케이션 성능을 향상시킬 수 있습니다. 동적 인스턴스와 상주 인스턴스 모두 App Engine 서비스 버전에 포함된 코드를 인스턴스화합니다.

앱에 수동 확장을 사용하는 경우, 앱에서 실행되는 인스턴스는 상주 인스턴스입니다. 기본 또는 자동 확장 중 하나를 사용하면 앱은 동적 인스턴스에서 실행됩니다.

앱 구성 시 다음을 포함한 서비스 확장 방법을 지정합니다.

  • 서비스의 초기 인스턴스 수
  • 트래픽에 따라 새 인스턴스를 만들거나 중지하는 방법
  • 요청을 처리하도록 인스턴스에 할당된 시간

서비스에 할당한 확장 유형에 따라 상주 또는 동적 인스턴스 여부가 결정됩니다.

  • 자동 확장 서비스는 동적 인스턴스를 사용합니다.
  • 수동 확장 서비스는 상주 인스턴스를 사용합니다.
  • 기본 확장 서비스는 동적 인스턴스를 사용합니다.

App Engine은 시간 단위로 인스턴스 사용 요금을 청구합니다. Google Cloud Platform 콘솔의 인스턴스 페이지에서 인스턴스 사용량을 추적할 수 있습니다. 부과되는 인스턴스 비용을 제한하려면 지출 한도를 설정하면 됩니다. App Engine에 배포하는 각 서비스는 구성 방식에 따라 독립적으로 확장되는 마이크로 서비스처럼 동작합니다.

동적 인스턴스 확장

App Engine 애플리케이션은 수신되는 요청 볼륨에 따라 지정된 시간에 일정한 수의 동적 인스턴스를 통해 구동됩니다. 애플리케이션의 요청이 증가하면 동적 인스턴스 수도 늘어납니다.

App Engine 스케줄러는 새 요청을 기존 인스턴스로 처리할 지(유휴 상태의 인스턴스 또는 동시 요청을 수락하는 인스턴스), 요청 대기열에 요청을 넣을 지 또는 해당 요청을 위한 새 인스턴스를 시작할 지 여부를 결정합니다. 결정 시 사용할 수 있는 인스턴스 수, 애플리케이션의 요청 처리 속도(지연 시간), 새 인스턴스 시작에 걸리는 시간을 고려합니다.

자동 확장을 사용하는 경우, target_cpu_utilization, target_throughput_utilization, max_concurrent_requests의 값을 설정하여 스케줄러 동작을 최적화하여 원하는 성능 대비 비용의 균형을 얻을 수 있습니다.

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

이 설정의 효과를 확인하려면 App Engine 새 스케줄러 설정 동영상을 시청하세요.

각 인스턴스에는 수신되는 요청을 위한 고유한 대기열이 있습니다. App Engine은 각 인스턴스의 대기열에서 대기 중인 요청 수를 모니터링합니다. App Engine은 부하 증가로 인해 애플리케이션의 대기열이 지나치게 길어지는 것을 감지하면 자동으로 애플리케이션의 새 인스턴스를 만들어 해당 부하를 처리합니다.

App Engine은 매우 빠르게 확장됩니다. 따라서 예를 들어, 처리를 위해 작업 대기열에 일괄 서비스 요청을 보내면 다수의 인스턴스가 빠른 속도로 생성됩니다. 가능하다면 전송되는 초당 요청 수에 비율 한도를 적용하여 이를 제어하는 것이 좋습니다. 예를 들어, App Engine 작업 대기열에서 작업이 푸시되는 비율을 제어할 수 있습니다.

또한 요청 볼륨이 감소하면 App Engine은 역으로 인스턴스를 확장합니다. 이러한 확장은 애플리케이션의 모든 현재 인스턴스가 최적의 효율과 비용 효율성에 따라 사용되도록 하는 데 유용합니다.

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

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

인스턴스 확장

한 버전의 서비스를 업로드하면 app.yaml이 해당 버전의 모든 인스턴스에 적용할 확장 유형인스턴스 등급을 지정합니다. 확장 유형은 인스턴스를 만드는 방법을 제어합니다. 인스턴스 클래스는 컴퓨팅 리소스(메모리 크기 및 CPU 속도)와 가격을 결정합니다. 확장 유형에는 수동, 기본, 자동 등 3가지가 있습니다. 사용할 수 있는 인스턴스 클래스는 확장 유형에 따라 다릅니다.

수동 확장
수동 확장 서비스는 부하 수준과 무관하게 지정된 수의 인스턴스를 계속 실행하는 상주 인스턴스를 사용합니다. 따라서 메모리 상태에 장기적으로 의존하는 복잡한 초기화 등의 작업과 애플리케이션을 지원합니다.
자동 확장
자동 확장 서비스는 요청 속도, 응답 지연 시간, 기타 애플리케이션 측정항목을 기반으로 생성되는 동적 인스턴스를 사용합니다. 하지만 최소 유휴 인스턴스 수를 지정하면 지정한 수의 인스턴스만 상주 인스턴스로 실행되고 추가 인스턴스는 동적 인스턴스로 실행됩니다.
기본 확장
기본 확장이 적용되는 서비스는 동적 인스턴스를 사용합니다. 애플리케이션이 요청을 수신하면 각 인스턴스가 생성됩니다. 앱이 유휴 상태가 되면 인스턴스가 중지됩니다. 기본 확장은 간헐적이거나 사용자 활동에 따라 진행되는 작업에 이상적입니다.

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

기능 자동 확장 수동 확장 기본 확장
기한 HTTP 요청 기한 60초, 작업 대기열 작업 기한 10분 요청을 최대 24시간 동안 실행할 수 있습니다. 수동 확장된 인스턴스를 선택하면 /_ah/start를 처리하고 HTTP 응답 코드 반환 없이 장시간 동안 프로그램 또는 스크립트를 실행할 수 있습니다. 작업 대기열 작업을 최대 24시간 동안 실행할 수 있습니다. 수동 확장과 동일합니다.
상주 사용 패턴에 따라 인스턴스가 메모리에서 삭제됩니다. 인스턴스가 메모리에 유지되고 요청 간에 상태가 보존됩니다. 인스턴스를 다시 시작하면 로그에 /_ah/stop 요청이 표시됩니다. 등록된 종료 후크가 있는 경우, 30초가 지나면 종료됩니다. idle_timeout 매개변수에 따라 인스턴스가 삭제됩니다. idle_timeout 이상 요청이 수신되지 않는 등의 이유로 유휴 상태가 된 인스턴스는 삭제됩니다.
시작 및 종료 인스턴스는 수요에 따라 생성되어 요청을 처리하고 유휴 상태이면 자동으로 종료됩니다. App Engine은 /_ah/start에 대한 빈 GET 요청의 형태로 인스턴스에 시작 요청을 자동으로 보냅니다. 수동으로 중지된 인스턴스에는 요청 처리를 완료하도록 30초가 주어지며 이후 강제로 인스턴스가 종료됩니다. idle_timeout 구성 매개변수에 따라 요청을 처리하고 유휴 상태일 경우 자동으로 종료되도록 인스턴스가 요청에 따라 생성됩니다. 수동 확장과 마찬가지로 수동으로 중지된 인스턴스에는 요청 처리를 완료하도록 30초가 주어지며 이후 강제로 인스턴스가 종료됩니다.
인스턴스 주소 지정 인스턴스는 익명입니다. 서비스 's'에 대한 버전 'v'의 인스턴스 'i'는 http://i.v.s.app_id.appspot.com과 같은 URL로 주소를 지정할 수 있습니다. 커스텀 도메인에 대해 와일드 카드 하위 도메인 매핑을 설정한 경우에는 http://s.domain.com 또는 http://i.s.domain.com 형식의 URL을 통해 서비스 또는 해당 인스턴스의 주소를 지정할 수도 있습니다. 이를 통해 안정적으로 각 인스턴스의 상태를 캐싱하고 이후 요청에서 검색할 수 있습니다. 수동 확장과 동일합니다.
확장 App Engine에서 처리량에 따라 인스턴스 수를 자동으로 확장합니다. 이 확장은 구성 파일에서 버전 단위로 제공되는 automatic_scaling 설정을 고려합니다. 해당 서비스의 구성 파일에서 각 버전의 인스턴스 수를 구성합니다. 일반적으로 인스턴스 수는 메모리에 유지되는 데이터세트 크기 또는 원하는 오프라인 작업 처리량에 대응합니다. 기본 확장을 사용하는 서비스는 max_instances 설정의 basic_scaling 매개변수에서 최대 인스턴스 수 설정을 통해 구성합니다. 실시간 인스턴스 수는 처리량에 따라 확장됩니다.
무료 일일 사용 할당량 28 인스턴스-시간 8 인스턴스-시간 8 인스턴스-시간

인스턴스 수명 주기

인스턴스 상태

자동 확장되는 서비스의 인스턴스는 항상 실행 중입니다. 그러나 수동 또는 기본 확장 서비스의 인스턴스는 실행 중이거나 중지된 상태일 수 있습니다. 동일한 서비스와 버전의 모든 인스턴스가 동일한 상태를 공유합니다. GCP 콘솔의 버전 페이지, 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이 애플리케이션의 새 인스턴스를 만들면 해당 인스턴스는 먼저 요청을 처리하는 데 필요한 라이브러리와 리소스를 로드해야 합니다. 이 작업은 인스턴스에 대한 첫 번째 요청 중에 진행되며, 이를 로드 요청이라 합니다. 로드 요청 중에는 애플리케이션이 초기화되어 요청을 처리하는 데 시간이 오래 걸릴 수 있습니다.

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

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

준비 요청

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

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

인스턴스 가동시간

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

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

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

인스턴스 청구

일반적으로 인스턴스에는 15분 시작 수수료 외에 가동시간에 따른 분 단위 요금이 청구됩니다(자세한 내용은 가격 참조). 유휴 인스턴스의 요금은 서비스 별로 설정한 최대 유휴 인스턴스 수까지만 청구됩니다. 런타임 오버헤드는 인스턴스 메모리에 반영됩니다. Python보다 자바 애플리케이션의 런타임 오버헤드가 더 많습니다.

상주 인스턴스와 동적 인스턴스의 청구 방식은 약간 다릅니다.

  • 상주 인스턴스의 경우, 인스턴스가 종료되고 15분 후에 청구가 종료됩니다.
  • 동적 인스턴스의 경우, 마지막 요청 처리가 완료되고 15분 후에 청구 기간이 종료됩니다.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Go용 App Engine 표준 환경