View a markdown version of this page

Lambda 受管執行個體的最佳實務 - AWS Lambda
容量提供者組態執行個體類型選取函數組態長時間執行的函數擴展組態安全成本最佳化監控與可觀測性語言特定考量事項後續步驟

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

Lambda 受管執行個體的最佳實務

容量提供者組態

依信任層級分隔容量提供者。為具有不同安全需求的工作負載建立不同的容量提供者。指派給相同容量提供者的所有 Lambda 事件函數都必須相互信任，因為容量提供者可做為安全界限。

使用描述性名稱。命名容量提供者，以清楚指出其預期用途和信任層級 （例如 production-trusted、)dev-sandbox。這有助於團隊了解每個容量提供者的目的和安全性狀態。

使用多個可用區域。在建立容量提供者時，指定跨多個可用區域的子網路。Lambda 預設會針對 AZ 彈性啟動三個執行個體，以確保函數的高可用性。

執行個體類型選取

讓 Lambda 選擇執行個體類型。根據預設，Lambda 會為您的工作負載選擇最佳的執行個體類型。我們建議您讓 Lambda 受管執行個體為您選擇執行個體類型，因為限制可能的執行個體類型數量可能會導致可用性降低。

指定特定需求的執行個體類型。如果您有特定的硬體需求，請將允許的執行個體類型設定為相容的執行個體清單。例如：

  • 對於需要高網路頻寬的應用程式，請選取多個 n 個執行個體類型

  • 針對具有成本限制的測試或開發環境，請選擇較小的執行個體類型，例如 m7a.large

函數組態

選擇適當的記憶體和 vCPU 設定。選取支援函數多並行執行的記憶體和 vCPU 組態。支援的函數大小下限為 2GB 和 1 個 vCPU。

  • 對於 Python 應用程式，選擇較高比率的記憶體與 vCPUs（例如 4 比 1 或 8 比 1)，因為 Python 處理多並行的方式

  • 對於執行少量 IO 的 CPU 密集型操作或函數，請選擇多個 vCPU

  • 對於 IO 密集型應用程式，例如 Web 服務或批次任務，多並行可提供最大效益

適當設定並行上限。Lambda 會針對平衡資源消耗和輸送量的最大並行選擇合理的預設值。根據函數的資源用量調整此設定：

  • 如果您的函數調用使用極少的 CPU，請增加並行上限 （每個 vCPU 最多 64 個）

  • 如果您的應用程式使用大量記憶體和極少 CPU，請減少並行上限

請注意，並行極低的執行環境可能會遇到調節和擴展困難。

長時間執行的函數

對於非同步調用和事件來源映射調用， AWS Lambda 受管執行個體上的函數每次調用最多可以執行 90 分鐘 (5，400 秒），但 Amazon MQ 和 Amazon DocumentDB 事件來源映射除外，其限制為 15 分鐘。同步調用和函數初始化階段也會保留 15 分鐘。如需設定逾時的詳細資訊，請參閱設定 Lambda 函數逾時。由於您的函數可以執行更長的時間，請檢閱下列有關暫時性元件的考量事項，例如網路連線和登入資料。

適應閒置連線逾時。確保 Amazon RDS、Amazon ElastiCache 和外部 APIs 等下游服務上的閒置連線逾時符合完整的函數持續時間。如果您的函數透過 NAT 閘道路由流量，請傳送保持連線封包，以防止在 NAT 閘道的 350 秒閒置逾時後捨棄閒置連線。

遵守 DNS TTL 值。當您解析外部主機名稱時，請遵守 DNS TTL 值。 AWS SDKs 會自動處理此問題，但自訂 HTTP 用戶端可能會快取超出其 TTL 的 DNS 解析。

重新整理暫時登入資料。如果您的函數取得臨時憑證或字符，請確認它們在完整執行期間保持有效，或在背景重新整理它們。

等冪性的設計。Lambda 不保證一次完全處理。隨著函數執行時間延長，重試和重複交付的時段會增加。使用 Powertools for AWS Lambda 為付款或資料庫寫入等操作實作冪等性，因此即使執行多次，也會產生相同的結果。如果您使用 Lambda 耐用函數，步驟at-least-once執行語意：耐用執行 SDK 會在重播期間略過已完成的步驟，但在檢查點再次執行之前失敗的步驟。您可以使用執行名稱做為等冪索引鍵。

調校事件來源映射以延長處理時間。對於 Amazon SQS，將佇列的可見性逾時設定為函數逾時的至少六倍，以便 Lambda 有足夠的時間在調節函數時重試批次。當您建立事件來源映射時，Lambda 會驗證這一點，但不會防止稍後對建立不相符的佇列或函數進行變更。對於 Amazon Kinesis Data Streams 和 Amazon DynamoDB Streams，設定最大批次時段和平行化因素，以考量每個批次較長的處理時間，並啟用部分批次失敗報告，因此只會重試失敗的記錄，而不是整個批次。

擴展組態

設定適當的目標資源使用率。根據預設，Lambda 會維持足夠的空間，讓您的流量在 5 分鐘內加倍，無需調節。根據您的工作負載特性進行調整：

  • 對於對調節不敏感的非常穩定工作負載或應用程式，請將目標設定為高層級，以實現更高的使用率和更低的成本

  • 對於具有潛在流量暴增的工作負載，請將資源目標設定為低層級，以維持額外的空間

規劃流量成長。如果您的流量在 5 分鐘內增加一倍以上，您可能會在 Lambda 擴展執行個體和執行環境時看到調節。設計您的應用程式，以在快速擴展期間處理潛在的限流。

安全

套用 PassCapacityProvider 許可的最低權限。僅授予必要容量提供者的lambda:PassCapacityProvider許可。使用資源層級許可來限制使用者可以指派給函數的容量提供者。

監控容量提供者用量。Use AWS CloudTrail 可監控容量提供者指派和存取模式。這有助於識別未經授權的存取嘗試，並確保符合安全政策。

分隔不受信任的工作負載。請勿在不受信任的工作負載之間依賴容器進行安全隔離。使用不同的容量提供者來分隔不受互信的工作負載。

成本最佳化

使用 EC2 定價選項。利用 EC2 Savings Plans 和預留執行個體來降低成本。這些定價選項適用於基礎 EC2 運算 (15% 的管理費不會折扣）。

針對穩定狀態工作負載進行最佳化。Lambda 受管執行個體最適合具有可預測大量流量的穩定狀態函數。對於高載流量模式，Lambda （預設） 可能更具成本效益。

監控資源使用率。追蹤 CloudWatch 指標以了解 CPU 和記憶體使用率。根據實際用量模式調整函數記憶體配置和執行個體類型選擇，以最佳化成本。

監控與可觀測性

監控容量提供者指標。追蹤容量提供者層級指標，包括 CPUUtilization、MemoryUtilization、vCPUAvailable 和 MemoryAvailable，以確認工作負載有足夠的資源可用。

監控執行環境指標。追蹤執行環境層級指標，包括 ExecutionEnvironmentConcurrency 和 ExecutionEnvironmentConcurrencyLimit，以了解擴展行為並識別潛在的限流。

設定 CloudWatch 警示。為關鍵指標建立 CloudWatch 警示，以主動識別問題：

  • CPU 或記憶體使用率高

  • 可用容量低

  • 接近並行限制

語言特定考量事項

遵循特定語言的最佳實務。每種程式設計語言處理多並行的方式都不同。檢閱語言特定指南以取得詳細建議：

  • Java：將執行緒安全集合、 AtomicInteger和 ThreadLocal用於請求特定狀態

  • Node.js：針對所有請求特定的狀態使用 InvokeStore，並避免全域變數

  • Python：在 中使用唯一的檔案名稱/tmp搭配請求 IDs並考慮以程序為基礎的記憶體隔離

  • Rust：使用 run_concurrent而非 run，並啟用 concurrency-tokio功能。處理常式必須是 Clone + Send。

測試執行緒安全和並行問題。在部署到生產環境之前，請徹底測試您的 函數是否有執行緒安全問題、競爭條件，以及在並行負載下的適當狀態隔離。

後續步驟