執行個體的管理方式

執行個體是 App Engine 的基本構成要素，用來提供託管應用程式所需的資源。在任何特定時間內，您的應用程式皆可在單一或多個執行個體上執行，處理遍布這些執行個體的要求。每個執行個體都包含一個安全性階層，確保執行個體不會意外相互影響。

App Engine 可在流量波動時自動建立及關閉執行個體，您也可以指定執行的執行個體數量 (不論流量為何)。如要決定建立新執行個體的方式和時機，請為應用程式指定資源調度類型。資源調度設定會套用至 App Engine 版本層級，並納入 app.yaml 檔案。

資源調度類型

App Engine 支援下列資源調度類型，可控管建立執行個體的方式和時間：

  • 自動 (預設)
  • 基本
  • 手動

您可以在應用程式的 app.yaml 中指定縮放類型。根據預設，應用程式會使用自動調整資源配置功能，也就是說，App Engine 會管理閒置執行個體的數量。

自動調整資源配置
自動調整資源配置會根據要求頻率、回應延遲時間和其他應用程式指標建立執行個體。您可以設定 automatic_scaling 元素，為每項指標指定閾值，以及隨時保持運作的執行個體數量下限。
基本資源配置
「基本資源調度」會在應用程式收到要求時建立執行個體。當應用程式處於閒置狀態時，系統就會關閉每個執行個體。基本資源配置非常適合間歇性工作或是由使用者活動驅動的工作。
手動調整資源配置
手動調整資源配置會指定持續執行的執行個體數量，無論工作負載程度為何皆然。這種資源配置類型讓各項工作 (例如複雜的初始化) 及各時期皆依賴記憶體狀態的應用程式得以執行。
下表比較了這三種資源配置類型的效能特色：

功能 自動調整資源配置 基本資源配置 手動調整資源配置
要求逾時 HTTP 要求和工作佇列工作：10 分鐘。如果應用程式未在這個時間限制內傳回要求，App Engine 會中斷要求處理常式，並發出錯誤，供您的程式碼處理。

針對舊版執行階段 (Java 8、PHP 5 和 Python 2)：

  • Cron 工作中的工作佇列工作和要求的逾時時間為 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。 如果您已為自訂網域設定 萬用字元子網域對應，也可以透過 https://s.domain.com 或 https://i.s.domain.com 格式的網址，為服務或其任何執行個體定址。您可以放心將狀態暫存在每個執行個體中，在之後要求時再擷取狀態。 與基本資源配置相同。
資源調度 App Engine 可根據處理量自動調整執行個體的數量。這項資源配置包含設定檔中依據版本提供的 automatic_scaling 設定。 採用基本資源配置的服務的設定方式是透過在 basic_scaling 設定的 max_instances 參數中設定執行個體數量上限。運作中的執行個體數量會隨著處理量而調整。 您可以在服務的設定檔中設定每個版本的執行個體數量。執行個體的數量通常會對應到保存在記憶體中的資料集大小，或是希望達到的離線工作總處理量。您可以使用 Modules API set_num_instances 函式快速調整手動調整版本的執行個體數，而不必停止目前執行的執行個體。

調整動態執行個體的資源配置

採用基本或自動調整資源配置的 App Engine 應用程式，會在特定時間內，依傳入要求的數量，提供任意數量的動態執行個體來支援應用程式。隨著對應用程式發出的要求量增加，動態執行個體的數量也可能隨之增加。

含有基本資源調度的應用程式

如果您使用基本資源配置，App Engine 會盡量降低成本，但這可能會導致傳入要求量增加，進而導致延遲時間變長。

如果沒有任何現有執行個體可用於處理傳入的要求，App Engine 就會啟動新的執行個體。即使已啟動新執行個體，部分要求可能仍需要排入佇列，直到新執行個體完成啟動程序為止。如果您需要盡可能縮短延遲時間，不妨考慮使用自動資源調度功能，這項功能會預先建立新執行個體，盡可能縮短延遲時間。

支援自動調整資源配置的應用程式

如果您使用自動調整資源配置功能，應用程式中的每個執行個體都會有自己的傳入要求佇列。在佇列變得足夠長，對應用程式延遲造成明顯影響之前，App Engine 會自動建立一或多個新執行個體，以處理不斷增加的負載。

您可以設定自動調度資源的設定，在所需效能和可能產生的成本之間取得平衡。下表說明這些設定。

自動調整資源配置設定 說明
目標 CPU 使用率 設定 CPU 使用率門檻，超過這個門檻時，系統會啟動更多執行個體來處理流量。
目標處理量使用率 針對並行要求的數量設定總處理量門檻，超過這個門檻時，系統會啟動更多執行個體來處理流量。
並行要求數量上限 設定單一執行個體可接受的並行要求數量上限，超過上限時，排程器會產生新的執行個體。

請觀看 App Engine 排程器設定影片，瞭解這些設定的效果。

縮減

當要求量減少時，App Engine 會減少執行個體數量。這種資源配置的縮減方式有助於確保應用程式目前的所有執行個體皆以最佳效率執行，並具有成本效益。

完全未使用某個應用程式時，App Engine 會關閉相關的動態執行個體，但可以在需要時立即重新載入這些執行個體。重新載入執行個體可能會產生載入要求，並讓使用者等候額外的延遲時間。

您可以根據要求量的多寡，為應用程式設定適當的閒置執行個體數量下限。如此一來，除非異常湧進大量要求，否則應用程式均能以極短的延遲時間為每個要求提供服務。

在自動調整資源配置中縮減資源

如果應用程式採用自動調度資源功能，閒置的執行個體大約需要 15 分鐘的閒置時間才能開始關閉。如要讓一或多個閒置執行個體持續執行，請將 min_idle_instances 的值設為 1 以上。

調整及批次處理要求

如果您將要求批次傳送至服務，例如傳送至工作佇列以進行處理，系統將會快速地建立大量的執行個體。建議您盡可能對每秒傳送的要求數量進行頻率限制，以控制執行個體的增生速度。舉例來說，如果您使用 Google Tasks，可以控制推送工作的速率。

執行個體生命週期

執行個體狀態

如果是自動調整資源配置的服務，其執行個體會一直處於執行中的狀態。但如果是手動調整資源配置或基本調整資源配置的服務，其執行個體狀態可能為執行中或已停止。相同服務與版本的所有執行個體會共用相同的狀態。您可以透過管理版本來變更執行個體的狀態，您可以：

啟動

每個服務執行個體都是為了因應啟動要求而建立，啟動要求是向 /_ah/start 發出的空白 HTTP GET 要求。App Engine 會傳送這項要求來啟動執行個體，使用者則無法將要求傳送至 /_ah/start。採用手動和基本資源調度設定的執行個體都必須先回應啟動要求，接著才能處理其他要求。啟動要求有下列兩個用途：

  • 啟動無限期運作的程式，不再接受其他要求。
  • 在執行個體接收其他流量之前，先初始化該執行個體。

採用手動資源調度、基本資源調度和自動調整資源配置設定的執行個體會以不同方式啟動。您在啟動手動調度資源的執行個體時，App Engine 會立即將 /_ah/start 要求傳送至各個執行個體。您在啟動基本資源調度服務執行個體時，App Engine 會允許其接收流量，但必須等到收到第一項使用者要求之後，才會向執行個體傳送 /_ah/start 要求。除非需要處理的流量增加，否則系統不會啟動多個基本資源調度執行個體。自動調整資源配置的執行個體不會收到任何 /_ah/start 要求。

如果執行個體以 HTTP 狀態碼 200–299 或 404 回應 /_ah/start 要求，即視為該執行個體已成功啟動且可以處理其他要求。否則，App Engine 會終止該執行個體。系統會立即重新啟動手動調整資源配置的執行個體，但基本資源配置的執行個體只有在需要提供流量時才會重新啟動。

關閉

各種計畫或非計畫中的事件都有可能會觸發關閉程序，例如：

  • 執行個體太多，但應用程式要求 (流量) 不足。
  • 您以手動方式停止執行個體。
  • 您將更新過的版本部署至服務。
  • 執行個體超過所設 instance_class 的記憶體上限。
  • 應用程式耗盡「執行個體時數」配額。
  • 執行個體已移至其他機器，因為原本執行個體所在的機器重新啟動，或是 App Engine 為了改善負載分配而移動執行個體。

如前文「縮減資源」一節所述，App Engine 標準環境的「只需支付所需資源」平台的其中一個優點，就是在沒有流量時，系統會自動將執行個體數量調降至零。這有助於讓 App Engine 成為不接收持續要求的小型應用程式的經濟實惠解決方案。當需要關閉執行個體時，系統會將新收到的要求導向其他執行個體 (如有)，並給予目前正在處理的要求完成時間。

當需要關閉執行個體時，App Engine 會傳送 KILL (SIGKILL) 訊號，終止執行個體。

載入要求

當 App Engine 為應用程式建立新的執行個體時，該執行個體必須先載入處理要求所需的任何程式庫和資源。這項作業會在第一個要求傳送至執行個體期間 (稱為「載入要求」) 進行。在載入要求期間，應用程式會進行初始化作業，致使該要求耗費更長的時間。

您可參考下列最佳做法，以減少載入要求的所需時間：

  • 只載入啟動所需的程式碼。
  • 盡量減少對磁碟的存取。
  • 在某些情況下，從 zip 或 jar 檔案載入程式碼，會比從許多個別檔案載入程式碼還要快。

暖機要求

暖機要求是一種特定類型的載入要求，會在有任何實際要求之前，預先將應用程式的程式碼載入執行個體中。手動調整或基本資源配置執行個體不會收到 /_ah/warmup 要求。

如要進一步瞭解如何使用暖機要求，請參閱「設定暖機要求」。

執行個體運作時間

App Engine 會嘗試讓手動調整和基本資源配置執行個體保持無限期運作，不過，目前無法保證採用這兩種資源配置調整方式的執行個體的運作時間。軟硬體故障可能會在無預警的情況下發生，造成執行個體提前終止或頻繁地重新啟動，而且解決問題可能需要耗費大量時間；因此，您應以能夠容許這些問題的方式來建構應用程式。

您可以採取幾項有效的策略來避免因執行個體重新啟動而導致停機的狀況：

  • 減少重新啟動執行個體或啟動新執行個體所需的時間。
  • 對於需要長時間執行的運算，請定期建立查核點，以從查核點的狀態繼續執行。
  • 您的應用程式應處於「無狀態」，才不會在執行個體上儲存任何資料。
  • 使用佇列執行非同步工作。
  • 如果您將執行個體設定為手動調整資源配置：
    • 在多個執行個體之間使用負載平衡。
    • 設定超過處理一般流量所需的執行個體數量。
    • 撰寫可在無法手動調整執行個體的資源配置時，使用快取結果的備用邏輯。

NTP 與 App Engine 標準環境

App Engine 標準環境提供使用 Google NTP 伺服器的網路時間通訊協定 (NTP) 服務。不過，無法編輯 NTP 服務。