使用 Lambda SnapStart 改善啟動效能 - AWS Lambda
使用案例支援的功能和限制支援地區相容性考量定價

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 Lambda SnapStart 改善啟動效能

Lambda SnapStart 可提供低至一秒的啟動效能，通常不會變更函數程式碼。SnapStart 可讓您更輕鬆地建置高回應和可擴展應用程式，而無需佈建資源或實作複雜的效能最佳化。

啟動延遲的最大歸因 (通常稱為冷啟動時間) 是 Lambda 花費在初始化函數的時間，其中包括載入函數的程式碼、啟動執行階段以及初始化函數程式碼。使用 SnapStart，Lambda 會在您發佈函數版本時初始化您的函數。Lambda 會擷取已初始化執行環境的記憶體和磁碟狀態的 Firecracker microVM 快照、將快照加密，並智慧地進行快取以最佳化擷取延遲。

為了確保彈性，Lambda 會維護每個快照的多個副本。Lambda 會使用最新的執行時期和安全更新來自動修補快照及其副本。第一次調用函數版本時且呼叫縱向擴展時，Lambda 會從快取的快照恢復新的執行環境，而不是從頭開始執行，進而改善啟動延遲。

重要

如果您的應用程式依賴狀態的唯一性，則必須評估函數程式碼，並確認其對快照作業具有復原能力。如需詳細資訊，請參閱使用 Lambda SnapStart 處理唯一性。

主題

何時使用 SnapStart

Lambda SnapStart 旨在解決一次性初始化程式碼帶來的延遲差異，例如載入模組相依項或架構。這些操作有時可能需要幾秒鐘才能在初始調用期間完成。在最佳情況下，使用 SnapStart 將此延遲從數秒減少到低至次秒。SnapStart 搭配大規模函數調用使用時效果最佳。不常調用的函數效能改進效果可能不會相同。

SnapStart 特別適用於兩種主要應用程式類型：

  • 延遲敏感 API 和使用者流程：屬於關鍵 API 端點或面向使用者的流程的函數可受益於 SnapStart 降低的延遲和改善的回應時間。

  • 延遲敏感資料處理工作流程：使用 Lambda 函數的限時資料處理工作流程可以透過減少異常函數初始化延遲來實現更佳的輸送量。

佈建並行可讓函數保持初始化，並準備好在兩位數的毫秒內回應。如果應用程式有嚴格的冷啟動延遲要求，且 SnapStart 無法充分解決，請使用佈建並行。

支援的功能和限制

SnapStart 適用於下列 Lambda 受管執行時期：

不支援其他受管執行期 (例如 nodejs22.x 和 ruby3.3)、僅限作業系統的執行期 和容器映像。

SnapStart 不支援佈建並行、Amazon Elastic File System (Amazon EFS) 或大於 512 MB 的暫時性儲存。

注意

您只能對指向版本的已發佈函數版本和別名使用 SnapStart。不能對函數的未發佈版本 ($LATEST) 使用 SnapStart。

支援地區

對於 Java 執行時期，Lambda SnapStart 可在亞太區域 (馬來西亞) 以外的所有商業區域使用。

對於 Python 和 .NET 執行期，Lambda SnapStart 可在下列位置使用 AWS 區域：

  • 美國東部 (維吉尼亞北部)

  • 美國東部 (俄亥俄)

  • 美國西部 (奧勒岡)

  • 亞太區域 (新加坡)

  • 亞太區域 (雪梨)

  • 亞太區域 (東京)

  • 歐洲 (法蘭克福)

  • 歐洲 (愛爾蘭)

  • 歐洲 (斯德哥爾摩)

相容性考量

透過 SnapStart，Lambda 會使用單一快照做為多個執行環境的初始狀態。如果您的函數在初始化階段使用以下任何一項，那麼您可能需要在使用 SnapStart 之前進行一些變更：

唯一性

如果您的初始化程式碼會產生包含在快照中的唯一內容，則在跨執行環境中重複使用該內容時，該內容可能不是唯一的。若要在使用 SnapStart 時保持唯一性，您必須在初始化後產生唯一的內容。這包括唯一 ID、唯一密碼，以及用來產生偽隨機性的熵。若要了解如何還原唯一性，請參閱：使用 Lambda SnapStart 處理唯一性。

網路連線

Lambda 從快照恢復函數時，無法保證函數在初始化階段建立的連線狀態。驗證網路連線的狀態，並視需要重新建立。在大多數情況下， AWS 軟體開發套件建立的網路連線會自動恢復。針對其他連線，請檢閱最佳實務。

暫存資料

某些函數會在初始化階段下載或初始化暫存資料，例如臨時憑證或快取的時間戳記。請先重新整理函數處理常式中的暫時性資料再使用處理常式，即使沒有使用 SnapStart 也是如此。

SnapStart 定價

注意

對於 Java 受管執行時期，SnapStart 無需額外費用。我們會根據函數的請求數量、程式碼執行的時間，以及為函數配置的記憶體向您收費。

使用 SnapStart 的成本包括下列項目：

  • 快取：對於在啟用 SnapStart 的情況下發布的每個函數版本，需要支付快取和維護快照的成本。價格取決於您配置給函數的記憶體容量。需要支付最少 3 小時的費用。只要您的函數保持作用中狀態，就會繼續向您收取費用。使用 ListVersionsByFunction API 動作來識別函數版本，然後使用 DeleteFunction 刪除未使用的版本。若要自動刪除未使用的函數版本，請參閱 Serverless Land 上的 Lambda 版本清除模式。

  • 還原：每次從快照中還原函數執行個體時，都會支付還原費用。價格取決於您配置給函數的記憶體容量。

如同所有 Lambda 函數一樣，持續時間費用適用於函數處理常式中執行的程式碼。對於 SnapStart 函數，持續時間費用也適用於在處理常式之外宣告的初始化程式碼、執行時期進行載入所花的時間以及在執行時期勾點中執行的任何程式碼。持續時間是從程式碼開始執行的時間開始計算，直到傳回資料或結束為止，四捨五入至最接近的 1 ms。Lambda 會維護快照的快取副本以實現彈性，並自動套用軟體更新，例如執行時期升級和安全修補程式。每次 Lambda 重新執行初始化程式碼以套用軟體更新時，都會收取費用。

如需有關使用 SnapStart 的成本詳細資訊，請參閱 AWS Lambda 定價。