執行個體的管理方式

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

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

執行個體簡介

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

如果您針對某個應用程式採用手動調整資源配置,則應用程式會在常駐執行個體上執行。如果您採用的是基本或自動調整資源配置,則應用程式會在動態執行個體上執行。

應用程式設定作業包含指定其服務資源配置的調整方式,包括:

  • 服務的初始執行個體數量。
  • 如何根據流量建立新的執行個體或停止現有的執行個體。
  • 允許執行個體處理要求所分配的時間長度。

您指派給服務的資源配置類型會決定服務執行個體為常駐或動態:

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

App Engine 會以小時為單位,向您收取使用執行個體的費用。您可以在 Google Cloud Platform 主控台的執行個體頁面上追蹤執行個體的使用量。如果您要限制執行個體產生的費用,可透過設定支出上限來達到這個目的。您部署至 App Engine 的每項服務都會以類似微服務的形式運作,這些服務會分別依據您的設定調度資源。

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

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

App Engine 排程器會判斷要以現有的執行個體 (接受並行要求或閒置的執行個體) 處理每項新要求、將要求移至待處理要求佇列中,或是為該項要求啟動新的執行個體。產生這項決定時,App Engine 會考量可用執行個體的數量、應用程式處理要求的速度 (其延遲時間),以及啟動新執行個體所需的時間。

如果您已啟用自動調整資源配置功能,則可設定 target_cpu_utilizationtarget_throughput_utilizationmax_concurrent_requests 的值來改善排程器的行為,在目標效能與費用之間取得平衡。

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

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

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

App Engine 調整資源配置的速度很快。因此,如果您將要求批次傳送至服務,例如傳送至工作佇列以進行處理,系統將會快速地建立大量的執行個體。我們建議您儘可能對每秒傳送的要求數量進行頻率限制,以控制執行個體的增生速度。例如,您可以在 App Engine 工作佇列中控制推送工作的速率

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

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

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

執行個體資源調度

在您上傳服務的某個版本之後,app.yaml 就會為該版本的所有執行個體指派「資源調度類型」和執行個體類別。「資源調度類型」可以控管執行個體的建立方式,「執行個體類別」則可決定運算資源 (記憶體大小和 CPU 速度) 與定價。資源配置類型分成三種:「手動」、「基本」和「自動」。可用的執行個體類別則視資源配置類型而定。

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

下表比較了這三種資源配置類型的效能特色:

特色 自動調整資源配置 手動調整資源配置 基本資源配置
期限 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。如果您已針對自訂網域設定萬用字元子網域對應,也可以透過 http://s.domain.comhttp://i.s.domain.com 格式的網址將服務或服務的任何執行個體定址。您可以穩定地在各個執行個體中快取狀態,並在後續要求中擷取這項資訊。 與手動調整資源配置相同。
資源配置 App Engine 可根據處理量自動調整執行個體的數量。這項資源配置包含設定檔中依據版本提供的 automatic_scaling 設定。 您可以在服務的設定檔中設定每個版本的執行個體數量。執行個體數量通常會對應到保存在記憶體中的資料集大小,或是希望達到的離線工作總處理量。您可以使用 Modules API set_num_instances 函式快速調整手動調整資料配置版本的執行個體數,而不需停止目前執行的執行個體。 採用基本資源配置的服務的設定方式是透過在 basic_scaling 設定的 max_instances 參數中設定執行個體數量上限。運作中的執行個體數量會隨著處理量而調整。
免費的每日用量配額 28 小時的執行個體時數 8 小時的執行個體時數 8 小時的執行個體時數

執行個體生命週期

執行個體狀態

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

啟動

每個服務執行個體都是根據啟動要求 (向 /_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 標準環境