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 入口網站會強制執行此最佳做法。 如果基於某些原因,您必須在與函式應用程式不同的區域中使用儲存體帳戶,您必須在入口網站外部建立函式應用程式。

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

儲存體帳戶連線設定

根據預設,函式應用程式會將 AzureWebJobsStorage 連線設定為儲存在 AzureWebJobs 中的連接字串儲存體應用程式設定 ,但您也可以 設定 AzureWebJobs儲存體在沒有秘密的情況下使用以身分識別為基礎的連線

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

注意

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

共用記憶體帳戶

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

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

生命週期管理原則考慮

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

儲存體記錄

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

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

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

將儲存體效能最佳化

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

使用 Blob

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

在 Blob 容器上觸發

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

考量事項 Blob 儲存體 (標準) Blob 儲存體 (事件型) 佇列儲存體 Event Grid
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_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE 應用程式設定。 您可以藉由產生標準部署的 ARM 範本、移除這兩個設定,然後部署範本,來避免這些設定。

由於 Functions 會在動態向外延展程式的部分期間使用 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/mountmount-path ,您可以依檔案系統 API 存取目標目錄,如下列 Python 範例所示:

import os
...

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

下一步

深入瞭解 Azure Functions 裝載選項。