執行個體的管理方式

執行個體是 App Engine 的基本構成要素,用來提供一切所需資源,讓您的應用程式能夠順利受到託管。執行個體包含程式語言的執行階段、App Engine API,以及您的應用程式程式碼與記憶體。每個執行個體都包含一個安全層,確保執行個體不會意外互相產生影響。

執行個體是 App Engine 用來自動調整應用程式資源配置的運算單位。在任何特定的時間內,您的應用程式皆可以在單一或多個執行個體上執行,處理遍佈這些執行個體的要求。

執行個體簡介

執行個體分成「常駐」及「動態」兩種性質。動態執行個體會根據當下的需求而自動啟動和關閉。常駐執行個體則是隨時皆處於執行狀態,因此可改善應用程式的效能。動態和常駐執行個體皆會實例化 App Engine 服務版本中包含的程式碼。

如果您將應用程式設為採用手動調整資源配置,則這個應用程式會在常駐執行個體上執行。如果採用基本或自動調整資源配置,您的應用程式就會在動態執行個體上執行。

應用程式服務的資源配置調整方式屬於應用程式設定作業的一環,其中包含:

  • 服務的初始執行個體數量。
  • 因應流量而建立或停止新執行個體的方式。
  • 允許執行個體處理要求的分配時間量。

您為服務指派的資源調度類型會決定這個服務的執行個體為常駐或動態性質:

  • 自動調整資源配置服務會使用動態執行個體。
  • 手動調整資源配置服務會使用常駐執行個體。
  • 基本資源配置服務會使用動態執行個體。

App Engine 會向您收取執行個體的使用費用,以每小時計價。您可以在 Google Cloud Platform 主控台的執行個體頁面上追蹤執行個體的使用量。如果您要限制執行個體產生的費用,可透過設定支出上限來達到這個目的。您部署至 App Engine 的每項服務,其作用類似於微服務,會根據您的設定方式獨立調整資源配置。

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

App Engine 應用程式可依傳入要求的數量,在特定時間內使用任意數量的動態執行個體。隨著向應用程式發出的要求量增加,動態執行個體的數量也會隨之增加。

App Engine 排程器會決定是否透過現有的執行個體處理每個新要求 (使用閒置的執行個體,或接受並行要求的執行個體)、將要求放置到待處理的要求佇列中,或是針對該要求啟動新的執行個體。這項決定的考量依據包含可用執行個體的數量、應用程式為要求提供服務的速度有多快 (延遲時間),以及啟動新執行個體需耗費多少時間。

若您採用自動調整資源配置,則可透過設定 target_cpu_utilizationtarget_throughput_utilizationmax_concurrent_requests 的值來改善排程器的行為,在效能與費用方面取得最佳平衡。

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

請觀看 App Engine 新排程器設定影片,進一步瞭解這些設定的效果。

每個執行個體都有自己的傳入要求佇列。App Engine 會監控每個執行個體的佇列中正在等待的要求數,如果偵測到某個應用程式的佇列因負載增加而變得太長,就會自動為應用程式建立新的執行個體以處理該負載。

App Engine 可以快速擴充。因此,如果您將要求批次傳送到您的服務 (例如進行處理的工作佇列),則系統會快速建立大量的執行個體。如果可以的話,我們建議您對每秒傳送的要求量設下頻率限制,藉此控制執行個體的擴充速度。例如,在 App Engine 工作佇列中,您可控制推送工作的速率

當要求量減少時,App Engine 也會反向調整執行個體數量。這種調整方式有助於確保您應用程式目前所有的執行個體皆能妥善運用,達到最佳效率及成本效益。

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

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

執行個體資源調度

當您上傳某個服務的版本時,app.yaml 檔案會指定該版本的每個執行個體皆適用的「資源調度類型」執行個體類別。「資源調度類型」會控制執行個體的建立方式。「執行個體類別」則決定運算資源 (記憶體大小和 CPU 速度) 與定價。資源調度類型分成三種:「手動」、「基本」和「自動」。可用的執行個體類別會視資源調度類型而定。

手動調整資源配置
採用手動調整資源配置的服務會使用常駐執行個體,無論工作負載程度為何,都會持續執行指定數量的執行個體。這種資源調度類型讓各項工作 (像是複雜的初始化) 及各時期皆依賴記憶體狀態的應用程式得以執行。
自動調整資源配置
採用自動調整資源配置的服務會使用動態執行個體;這類的動態執行個體會根據要求比率、回應延遲時間及其他應用程式指標來建立。不過,如果您指定了閒置執行個體數量下限,指定數量的閒置執行個體會以常駐執行個體形式執行,而其他所有的執行個體則為動態性質。
基本資源配置
採用基本資源配置的服務會使用動態執行個體。每個執行個體都是在應用程式收到要求時建立。當應用程式處於閒置狀態時,系統就會關閉執行個體。基本資源配置非常適合間歇性工作或是由使用者活動驅動的工作。

這個資料表針對三種資源調度類型列出效能特點的比較資料:

特點 自動調整資源配置 手動調整資源配置 基本資源配置
期限 HTTP 要求的期限為 60 秒,工作佇列內工作的期限為 10 分鐘。 要求的執行時間最長可達 24 小時。手動調整資源配置的執行個體可以在不傳回 HTTP 回應碼的情況下,選擇連續數小時處理 /_ah/start 及執行程式或指令碼。工作佇列中的工作最多可執行 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。如果您已針對自訂網域設定萬用字元子網域對應,您也可透過 http://s.domain.comhttp://i.s.domain.com 格式的網址來定址服務或服務的任何執行個體。您可以穩定地在每個執行個體中快取狀態,並且在後續要求中擷取。 與手動調整資源配置相同。
資源調度 App Engine 會因應處理量來自動調整執行個體的數量。automatic_scaling 設定中的這項資源調度係數是以設定檔案中的每個版本為依據。 您可以在該服務的設定檔中設定每個版本的執行個體數量。執行個體數量通常會對應到保存在記憶體中的資料集大小,或是希望達到的離線工作總處理量。您可以使用 Modules API set_num_instances 函式快速調整手動調整資料配置版本的執行個體數,而不需停止目前執行的執行個體。 採用基本資源配置的服務的設定方式是透過在 basic_scaling 設定的 max_instances 參數中設定執行個體數量上限。運作中執行個體的數量會隨著處理量調整。
免費的每日用量配額 28 小時的執行個體時數 8 小時的執行個體時數 8 小時的執行個體時數

執行個體生命週期

執行個體狀態

如果是自動調整資源配置的服務,其執行個體會一直處於執行中的狀態。但如果是手動調整資源配置或基本資源配置的服務,其執行個體可能處於執行中或已停止的狀態。相同服務與版本的所有執行個體會共用相同的狀態。您可以透過 GCP 主控台的版本頁面 gcloud app versions start gcloud app versions stop 指令,或 Modules API 來停止版本,藉此變更執行個體的狀態。

啟動

每個服務執行個體都是為回應啟動要求 (對 /_ah/start 發出空白 HTTP GET 要求) 而建立。App Engine 會傳送此要求而使執行個體進入存在狀態;使用者無法將要求傳送到 /_ah/start。手動和基本資源配置執行個體都必須先回應啟動要求,然後才能處理其他要求。啟動要求有下列兩種用途:

  • 啟動程式並持續運作該程式,直到收到進一步要求為止。
  • 先初始化執行個體,再接收其他流量。

基本、手動調整和自動調整資源配置的執行個體均會以不同方式啟動。當您啟動手動調整資源配置執行個體時,App Engine 就會立即傳送 /_ah/start 要求給每個執行個體。當您啟動基本資源配置服務的執行個體時,App Engine 允許其接收流量,但是直到該執行個體收到第一個使用者要求之前,都不會向其傳送 /_ah/start 要求。只有在為了處理增加的流量時,才會視需要啟動多個基本資源配置執行個體。自動調整資源配置的執行個體不會收到任何 /_ah/start 要求。

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

關閉

各種預定及非預定事件都有可能觸發關閉程序,例如:

  • 您手動停止執行個體。
  • 您將更新版本部署到服務。
  • 執行個體超過設定的 instance_class 記憶體上限。
  • 應用程式耗盡執行個體時數配額。
  • 執行個體已移至其他機器,原因為目前執行所在的機器重新啟動,或是 App Engine 為了改善負載分配而移動執行個體。
應用程式有兩種方式可判定手動調整資源配置的執行個體是否即將關閉:第一種是 google.appengine.api.runtimeis_shutting_down() 方法開始傳回 true,第二種 (建議) 是由您註冊關閉掛鉤,詳細說明如下所述。

當 App Engine 開始關閉執行個體時,會給現有要求 30 秒時間完成,而新的要求會立即傳回 404。如果執行個體正在處理要求,App Engine 會暫停要求並執行關閉掛鉤。如果沒有執行中的要求,App Engine 會傳送 /_ah/stop 要求,藉此執行關閉掛鉤。/_ah/stop 要求會略過一般處理邏輯,並且無法由使用者程式碼處理;其唯一目的在於叫用關閉掛鉤。如果您在處理其他要求時引發關閉掛鉤例外狀況,該例外狀況會在要求過程中冒出,讓您能夠擷取。

如果您在 app.yaml 中指定 threadsafe: true (預設值) 來啟用並行要求,從關閉掛鉤發出例外狀況,會將該例外狀況複製到所有執行緒。下列程式碼範例示範的是基本關閉掛鉤:

from google.appengine.api import apiproxy_stub_map
from google.appengine.api import runtime

def my_shutdown_hook():
  apiproxy_stub_map.apiproxy.CancelApiCalls()
  save_state()
  # May want to raise an exception

runtime.set_shutdown_hook(my_shutdown_hook)

另外,下列範例示範如何使用 is_shutting_down() 方法:

while more_work_to_do and not runtime.is_shutting_down():
  do_some_work()
  save_state()

載入要求

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

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

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

暖機要求

暖機要求為特殊類型的載入要求,可預先將應用程式的程式碼載入執行個體中,之後再接收任何即時要求。基本或手動調整資源配置的執行個體不會收到 /_ah/warmup 要求。

如要進一步瞭解如何使用暖機要求,請參閱設定暖機要求

執行個體運作時間

App Engine 會嘗試讓基本和手動調整資源配置的執行個體保持無限期運作,但是目前仍無法保證採用這兩種資源調整方式的執行個體的運作時間。系統可能會無預警地發生軟硬體故障,導致作業提前終止或頻繁地重新啟動,而且可能需要耗費大量時間才能解決問題;因此,您應該以能夠容忍這些問題的方式來建構應用程式。

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

  • 縮短重新啟動執行個體或啟動新執行個體所花的時間。
  • 對於需要長時間執行的運算,請定期建立可用於還原狀態的檢查點。
  • 應用程式應為「無狀態」,以避免讓資料儲存在執行個體上。
  • 使用佇列來執行非同步工作。
  • 如果將執行個體設定為手動調整資源配置:
    • 在多個執行個體之間使用負載平衡。
    • 設定超過處理一般流量所需的執行個體數量。
    • 撰寫可在無法手動調整資源配置時使用快取結果的回退邏輯。

執行個體計費

一般而言,除了 15 分鐘的啟動費用之外,系統會針對執行個體的運作時間以分鐘計費 (詳情請參閱定價)。至於閒置執行個體,系統最多只會針對您為每項服務設定的閒置執行個體數量上限收取費用。執行階段的費用會計入執行個體的記憶體之中。Java 應用程式的這項費用會比 Python 來得高。

常駐和動態執行個體的計費方式稍有不同:

  • 如果是常駐執行個體,將於執行個體關閉十五分鐘後結束計費。
  • 如果是動態執行個體,則是在最後一個要求結束處理的十五分鐘後結束計費。
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Python 2 適用的 App Engine 標準環境