Azure Functions 的儲存考量事項

  • 發行項

當您建立函數應用程式執行個體時，Azure Functions 需要 Azure 儲存體帳戶。 函式應用程式可以使用下列記憶體服務：

儲存體服務 函式使用方式
Azure Blob 儲存體 維護系結狀態和函式金鑰1。
預設會用於 Durable Functions 中的工作中樞。
可用來儲存 Linux 取用遠端組建的函式應用程式程式碼，或作為外部套件 URL 部署的一部分。
Azure 檔案儲存體 2 用來在取用方案和 進階版 方案中儲存及執行函式應用程式程式代碼的檔案共用。
Azure 佇列記憶體 預設會用於 Durable Functions 中的工作中樞。 用於特定 Azure Functions 觸發程式中的失敗和重試處理。 用於 Blob 記憶體觸發程式的物件追蹤。
Azure 資料表儲存體 預設會用於 Durable Functions 中的工作中樞。

1 Blob 記憶體是函式密鑰的預設存放區，但您可以 設定替代存放區。

默認會設定 2 Azure 檔案儲存體，但您可以在某些情況下建立應用程式，而不需要 Azure 檔案儲存體。

重要考量

您必須強烈考慮下列有關函式應用程式所用記憶體帳戶的事實：

  • 當函式應用程式裝載於取用方案或 進階版 方案上時，您的函式程式碼和組態檔會儲存在連結的記憶體帳戶 Azure 檔案儲存體 中。 當您刪除此儲存體帳戶時，會刪除內容，且無法復原。 如需詳細資訊，請參閱已刪除 儲存體 帳戶

  • 重要數據，例如函式程式碼、 存取金鑰和其他重要的服務相關數據，都可以保存在記憶體帳戶中。 您必須以下欄取方式仔細管理函式應用程式所使用的記憶體帳戶存取權：

    • 根據最低許可權模型稽核和限制應用程式和使用者的記憶體帳戶存取權。 記憶體帳戶的許可權可以來自指派角色中的數據動作，或透過執行 listKeys 作業的許可權。

    • 監視記憶體帳戶中的控制平面活動（例如擷取密鑰）和數據平面作業（例如寫入 Blob）。 請考慮在 Azure 儲存體 以外的位置維護記憶體記錄。 如需詳細資訊，請參閱 儲存體 記錄。

儲存體帳戶需求

儲存體 在 Azure 入口網站 中建立為函式應用程式建立流程一部分的帳戶，一定會使用新的函式應用程式。 當您選擇使用現有的記憶體帳戶時，所提供的清單不包含特定不支援的記憶體帳戶。 下列限制適用於函式應用程式所使用的記憶體帳戶，因此您必須確定現有的記憶體帳戶符合下列需求：

  • 帳戶類型必須支援 Blob、佇列和數據表記憶體。 某些儲存體帳戶不支援佇列和資料表。 這些帳戶包括僅限 Blob 的儲存體帳戶和 Azure 進階儲存體。 若要深入瞭解記憶體帳戶類型，請參閱 儲存體 帳戶概觀。

  • 當您在 Azure 入口網站 中建立函式應用程式時，無法使用防火牆或虛擬專用網來保護的記憶體帳戶。 不過，入口網站目前不會篩選掉這些受保護的記憶體帳戶。 若要瞭解如何搭配函式應用程式使用安全的記憶體帳戶，請參閱 如何搭配 Azure Functions 使用安全的記憶體帳戶。

  • 您無法將安全的記憶體帳戶與載入於取用方案中的函式應用程式搭配使用。

  • 在入口網站中建立函式應用程式時，您只能選擇與您建立的函式應用程式位於相同區域中的現有記憶體帳戶。 這是效能優化，而不是嚴格的限制。 若要深入瞭解，請參閱 儲存體 帳戶位置。

  • 在已啟用可用性區域支援的方案上建立函式應用程式時，僅支援區域備援記憶體帳戶。

您可以使用部署自動化，在 Elastic 進階版 或 Dedicated （App Service） 方案中建立函式應用程式。 不過，您必須在 ARM 範本或 Bicep 檔案中包含特定的網路設定。 當您未包含這些設定和資源時，自動化部署可能會在驗證中失敗。 如需詳細資訊，請參閱 安全部署。

儲存體 帳戶指引

每個函式應用程式都需要記憶體帳戶才能運作。 刪除該帳戶時，您的函式應用程式將不會執行。 若要針對記憶體相關問題進行疑難解答，請參閱 如何針對記憶體相關問題進行疑難解答。 下列其他考慮適用於函式應用程式所使用的 儲存體 帳戶。

儲存體帳戶位置

為了獲得最佳效能，您的函式應用程式應該使用相同的區域中的記憶體帳戶，以減少延遲。 Azure 入口網站 會強制執行此最佳做法。 如果基於某些原因，您必須在與函式應用程式不同的區域中使用記憶體帳戶，您必須在入口網站外部建立函式應用程式。

函式應用程式必須能夠存取記憶體帳戶。 如果您需要使用安全的記憶體帳戶，請考慮 將記憶體帳戶限制為虛擬網路。

儲存體 帳戶連線設定

根據預設，函式應用程式會將AzureWebJobsStorage連線設定為儲存在 AzureWebJobs 中 儲存體 應用程式設定中的 連接字串，但您也可以設定 AzureWebJobs 儲存體 不使用秘密來使用身分識別型連線。

在取用方案中執行的函式應用程式（僅限 Windows）或彈性 進階版 方案（Windows 或 Linux）可以使用 Azure 檔案儲存體 來儲存啟用動態調整所需的映射。 針對這些方案，請在 [WEBSITE_CONTENTAZUREFILECONNECTIONSTRING] 設定中設定記憶體帳戶的 連接字串，並在 [WEBSITE_CONTENTSHARE] 設定中設定檔案共用的名稱。 這通常是用於的 AzureWebJobsStorage相同帳戶。 您也可以建立不會使用 Azure 檔案儲存體 的函式應用程式，但調整可能會受到限制。

注意

當您重新產生記憶體金鑰時，必須更新記憶體帳戶 連接字串。 在這裡深入瞭解記憶體金鑰管理。

共用記憶體帳戶

多個函式應用程式可以共用相同的記憶體帳戶，而沒有任何問題。 例如，在 Visual Studio 中，您可以使用 Azurite 記憶體模擬器來開發多個應用程式。 在此情況下，模擬器的作用就像是單一記憶體帳戶。 函式應用程式所使用的相同記憶體帳戶也可用來儲存應用程式數據。 不過，這種方法在生產環境中不一定是個好主意。

您可能需要使用不同的記憶體帳戶，以避免 主機標識符衝突。

生命週期管理原則考慮

您不應該將生命週期管理原則套用至函式應用程式所使用的 Blob 儲存體 帳戶。 函式會使用 Blob 記憶體來保存重要資訊，例如 函式存取密鑰，以及原則可以移除 Functions 主機所需的 Blob（例如密鑰）。 如果您必須使用原則，請排除 Functions 所使用的容器，其前面加上 azure-webjobs 或 scm。

儲存體記錄

因為函式程式代碼和金鑰可能會儲存在記憶體帳戶中，因此針對記憶體帳戶的活動記錄是監視未經授權存取的好方法。 Azure 監視器資源記錄可用來追蹤記憶體數據平面的事件。 如需如何設定及檢查這些記錄的詳細資訊，請參閱監視 Azure 儲存體。

Azure 監視器活動記錄會顯示控制平面事件，包括 listKeys 作業。 不過，您也應該設定記憶體帳戶的資源記錄，以追蹤後續使用密鑰或其他以身分識別為基礎的數據平面作業。 您應該至少啟用 儲存體 Write 記錄類別，才能識別對一般 Functions 作業外部數據的修改。

若要限制任何範圍廣泛的記憶體許可權的潛在影響，請考慮針對這些記錄使用非記憶體目的地，例如Log Analytics。 如需詳細資訊，請參閱監視 Azure Blob 儲存體 (機器翻譯)。

將儲存體效能最佳化

若要盡可能提高效能，每個函數應用程式應使用個別的儲存體帳戶。 當您有 Durable Functions 或事件中樞觸發的函式時，這特別重要，這兩者都會產生大量的記憶體交易。 當您的應用程式邏輯與 Azure 儲存體 互動時，請直接使用 儲存體 SDK 或透過其中一個記憶體系結，使用專用的記憶體帳戶。 例如，如果您有事件中樞觸發的函式將某些數據寫入 Blob 記憶體，請使用兩個記憶體帳戶，一個用於函式應用程式，另一個用於函式所儲存的 Blob。

使用 Blob

Functions 的主要案例是處理 Blob 容器中的檔案，例如影像處理或情感分析。 若要深入瞭解，請參閱 處理檔案上傳。

在 Blob 容器上觸發

有數種方式可以根據記憶體容器中 Blob 的變更來執行函式程式碼。 使用下表來判斷哪一個函式觸發程式最符合您的需求：

考量事項 Blob 記憶體（輪詢） Blob 記憶體（以事件為基礎） 佇列儲存體 事件方格
Latency 高 （最高 10 分鐘） 低 中 低
儲存體 帳戶限制 不支援僅限 Blob 的帳戶 不支援一般用途 v1 none 不支援一般用途 v1
延伸模組版本 任意 儲存體 v5.x+ 任意 任意
處理現有的 Blob 是 無 無 No
篩選 Blob 名稱模式 事件篩選條件 n/a 事件篩選條件
需要事件訂用 帳戶 No .是 無 Yes
支援高延展性二次 No .是 .是 Yes
描述 默認觸發程式行為，其依賴輪詢容器以取得更新。 如需詳細資訊，請參閱 Blob 記憶體觸發程序參考中的範例。 從事件訂用帳戶取用 Blob 記憶體事件。 Source需要的參數EventGrid值。 如需詳細資訊，請參閱 教學課程：使用事件訂用帳戶在 Blob 容器上觸發 Azure Functions。 當 Blob 新增至容器時，Blob 名稱字串會手動新增至記憶體佇列。 這個值是由佇列記憶體觸發程式直接傳遞至相同函式上的 Blob 記憶體輸入系結。 除了來自記憶體容器的事件之外，提供觸發事件的彈性。 當需要同時觸發您的函式時，請使用 非記憶體事件。 如需詳細資訊，請參閱 如何在 Azure Functions 中使用事件方格觸發程式和系結。

1 Blob 記憶體輸入和輸出系結支援僅限 Blob 的帳戶。
2 高延展性可以鬆散地定義為容器，其中有超過 100,000 個 Blob，或具有每秒超過 100 個 Blob 更新的記憶體帳戶。

儲存體 數據加密

Azure 儲存體會加密待用儲存體帳戶中的所有資料。 如需詳細資訊，請參閱待用資料的 Azure 儲存體加密。

根據預設，資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰，您可以提供客戶管理的金鑰，以用於 Blob 和檔案資料的加密。 這些密鑰必須存在於 Azure 金鑰保存庫，Functions 才能存取記憶體帳戶。 若要深入瞭解，請參閱 使用客戶管理的密鑰進行待用加密。

區域內數據落地

當所有客戶數據都必須保留在單一區域內時，與函式應用程式相關聯的記憶體帳戶必須是具有 區域內備援的記憶體帳戶。 區域內備援記憶體帳戶也必須搭配 Azure Durable Functions 使用。

在內部負載平衡 App Service 環境 （ASE） 中裝載時，其他平臺管理的客戶數據只會儲存在區域內。 若要深入瞭解，請參閱 ASE 區域備援。

主機標識碼考慮

函式會使用主機標識碼值作為唯一識別預存成品中特定函式應用程式的方式。 根據預設，此標識元會從函式應用程式的名稱自動產生，並截斷為前 32 個字元。 然後將個別應用程式相互關聯和追蹤資訊儲存在連結的記憶體帳戶時，就會使用此標識符。 當您有名稱超過 32 個字元且前 32 個字元完全相同的函式應用程式時，此截斷可能會導致重複的主機識別碼值。 當兩個具有相同主機標識碼的函式應用程式使用相同的記憶體帳戶時，您會收到主機標識符衝突，因為儲存的數據無法唯一連結至正確的函式應用程式。

注意

當這兩個位置都使用相同的記憶體帳戶時，生產位置中的函式應用程式與預備位置中的相同函式應用程式之間，可能會發生這種相同的主機標識符合序。

從 Functions 執行時間 3.x 版開始，會偵測到主機標識符衝突，並記錄警告。 在 4.x 版中，會記錄錯誤並停止主機，導致硬式失敗。 如需主機標識符衝突的詳細資訊，請參閱 此問題。

避免主機標識號衝突

您可以使用下列策略來避免主機識別子衝突：

  • 針對衝突所涉及的每個函式應用程式或位置，使用個別的記憶體帳戶。
  • 將其中一個函式應用程式重新命名為長度少於 32 個字元的值，這會變更應用程式的計算主機標識碼，並移除衝突。
  • 為一或多個碰撞應用程式設定明確的主機標識碼。 若要深入瞭解，請參閱 主機標識碼覆寫。

重要

變更與現有函式應用程式相關聯的記憶體帳戶，或變更應用程式的主機標識碼可能會影響現有函式的行為。 例如，Blob 記憶體觸發程式會藉由在記憶體中的特定主機標識碼路徑下寫入收據，來追蹤其是否已處理個別 Blob。 當主機標識碼變更或指向新的記憶體帳戶時，先前處理的 Blob 可以重新處理。

覆寫主機標識碼

您可以使用 設定，在應用程式設定 AzureFunctionsWebHost__hostid 中明確設定函式應用程式的特定主機標識碼。 如需詳細資訊，請參閱 AzureFunctionsWebHost__hostid。

當位置之間發生衝突時，您必須為每個位置設定特定的主機標識碼，包括生產位置。 您也必須將這些設定標示為 部署設定 ，使其不會交換。 若要瞭解如何建立應用程式設定，請參閱 使用應用程式設定。

已啟用 Azure Arc 的叢集

當您的函式應用程式部署至已啟用 Azure Arc 的 Kubernetes 叢集時，函式應用程式可能不需要記憶體帳戶。 在此情況下，只有在函式應用程式使用需要記憶體的觸發程式時，Functions 才需要記憶體帳戶。 下表指出哪些觸發程式可能需要記憶體帳戶，但不需要。

非必要 可能需要記憶體
• Azure Cosmos DB
• HTTP
• Kafka
• RabbitMQ
• 服務匯流排		 • Azure SQL
• Blob 記憶體
• 事件方格
• 事件中樞
• IoT 中樞
• 佇列記憶體
• SendGrid
• SignalR
• 表格記憶體
• 定時器
• Twilio

若要在沒有記憶體的情況下，在已啟用 Azure Arc 的 Kubernetes 叢集上建立函式應用程式，您必須使用 Azure CLI 命令 az functionapp create。 Azure CLI 的版本必須包含 0.1.7 版或更新版本的 appservice-kube 擴充功能。 az --version使用 命令來確認延伸模組已安裝，而且是正確的版本。

使用 Azure CLI 以外的方法建立函式應用程式資源需要現有的記憶體帳戶。 如果您打算使用任何需要記憶體帳戶的觸發程式，您應該先建立帳戶，再建立函式應用程式。

建立不含 Azure 檔案儲存體的應用程式

彈性 進階版 和非 Linux 取用方案預設會設定 Azure 檔案儲存體，以作為大規模案例中的共用文件系統。 平臺會針對記錄串流等某些功能使用文件系統，但主要可確保已部署函式承載的一致性。 使用外部套件 URL 部署應用程式時，應用程式內容會從個別的唯讀檔案系統提供。 這表示您可以建立函式應用程式，而不需 Azure 檔案儲存體。 如果您使用 Azure 檔案儲存體 建立函式應用程式，仍會提供可寫入的檔案系統。 不過，此檔案系統可能無法用於所有函式應用程式實例。

未使用 Azure 檔案儲存體 時，您必須符合下列需求：

  • 您必須從外部套件 URL 部署。
  • 您的應用程式無法依賴共用可寫入檔案系統。
  • 應用程式無法使用 Functions 執行時間 1.x 版。
  • 用戶端中的記錄串流體驗，例如 Azure 入口網站 預設為檔案系統記錄。 您應該改為依賴 Application Insights 記錄。

如果已正確考慮上述專案，您可以建立應用程式而不需 Azure 檔案儲存體。 建立函式應用程式，而不指定 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE 應用程式設定。 您可以藉由產生標準部署的 ARM 範本、移除這兩個設定，然後部署範本，來避免這些設定。

由於函式會在動態向外延展程式的部分期間使用 Azure 檔案儲存體，因此在不使用取用和彈性 進階版 方案的情況下執行 Azure 檔案儲存體 時，調整可能會受到限制。

掛接檔案共用

這項功能目前僅適用於在Linux上執行時。

您可以將現有的 Azure 檔案儲存體 共用掛接至 Linux 函式應用程式。 藉由將共用掛接至Linux函式應用程式，您就可以在函式中使用現有的機器學習模型或其他數據。 您可以使用下列命令，將現有的共用掛接至 Linux 函式應用程式。

az webapp config storage-account add

在此命令中，share-name是現有 Azure 檔案儲存體 共用的名稱，而且custom-id可以是掛接至函式應用程式時唯一定義共用的任何字串。 此外， mount-path 是函式應用程式中存取共用的路徑。 mount-path 必須是 格式 /dir-name，且不能以 /home開頭。

如需完整範例，請參閱建立 Python 函式應用程式中的腳本，並掛接 Azure 檔案儲存體 共用。

目前僅支援的 storage-typeAzureFiles 。 您只能將五個共用掛接至指定的函式應用程式。 掛接檔案共用可增加至少 200-300 毫秒的冷啟動時間，或者當記憶體帳戶位於不同區域時，甚至更多。

掛接的共用可在指定的函式程式碼中使用 mount-path 。 例如，當 是 /path/to/mount時mount-path，您可以依文件系統 API 存取目標目錄，如下列 Python 範例所示：

import os
...

files_in_share = os.listdir("/path/to/mount")

下一步

深入瞭解 Azure Functions 裝載選項。

Azure Functions 的級別和裝載