執行個體的管理方式

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

App Engine 可在流量波動時自動建立及關閉執行個體，您也可以指定要執行的執行個體數量，不論流量多寡都照常運作。如要決定建立新執行個體的方式和時間，請為應用程式指定資源調度類型。資源調度設定會在 app.yaml 檔案中套用至 App Engine 版本層級。

資源調度類型

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

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

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

App Engine 標準環境的 NTP

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