Azure Functions のストレージに関する考慮事項

[アーティクル]
06/13/2023

Azure Functions では、Function App インスタンスを作成するときに Azure ストレージアカウントが必要になります。関数アプリでは次のストレージサービスを使用できます。

ストレージサービス	Functions の使用法
Azure BLOB Storage	バインドの状態と関数キー¹を管理します。既定では、Durable Functions 上のタスクハブから使用されます。 Linux 従量課金プランリモートビルド用の関数アプリコードを格納するため、または外部パッケージ URL デプロイの一部として、使用できます。
Azure Files²	従量課金プランや Premium プランで、関数アプリコードを格納して実行するために使用されるファイル共有。
Azure Queue Storage	既定では、Durable Functions 上のタスクハブから使用されます。特定の Azure Functions トリガーでの失敗と再試行の処理に使用されます。 BLOB ストレージトリガーによるオブジェクト追跡に使用されます。
Azure Table Storage	既定では、Durable Functions 上のタスクハブから使用されます。

¹ Blob Storage はファンクションキーの既定のストアですが、代替ストアを構成できます。

² Azure Files は既定で設定されていますが、特定の条件では、Azure Files を使わずにアプリを作成することもできます。

重要な考慮事項

関数アプリで使用されるストレージアカウントに関して、次の事実を強く考慮する必要があります。

関数アプリが従量課金プランまたは Premium プランでホストされている場合、関数コードと構成ファイルは、リンクされたストレージアカウントの Azure Files に保存されます。メインストレージアカウントを削除すると、このコンテンツは削除され、回復できなくなります。詳細については、「ストレージアカウントが削除された」を参照してください。
関数コード、アクセスキー、その他の重要なサービス関連データなどの重要なデータは、ストレージアカウントに保持できます。関数アプリで使用されるストレージアカウントへのアクセスは、次の方法で慎重に管理する必要があります。
- 最小特権モデルに基づいて、ストレージアカウントへのアプリとユーザーのアクセスを監査および制限します。ストレージアカウントへのアクセス許可は、割り当てられたロールのデータアクションから、または listKeys 操作を実行するためのアクセス許可を通じて取得できます。
- ストレージアカウント内のコントロールプレーンアクティビティ (キーの取得など) とデータプレーン操作 (BLOB への書き込みなど) の両方を監視します。 Azure Storage 以外の場所にストレージログを保持することを検討してください。詳細については、「ストレージログ」を参照してください。

ストレージアカウントの要件

Azure portal で関数アプリの作成フローの一部として作成されたストレージアカウントは、新しい関数アプリで動作することが保証されます。既存のストレージアカウントを使用することを選択した場合、指定された一覧には、サポートされていない特定のストレージアカウントは含まれません。関数アプリで使用されるストレージアカウントには次の制限が適用されるため、既存のストレージアカウントがこれらの要件を満たしていることを確認する必要があります。

アカウントの種類は、BLOB、Queue、Table Storage をサポートしている必要があります。一部のストレージアカウントでは、Queue と Table がサポートされません。これらのアカウントには、BLOB 専用ストレージアカウントと Azure Premium Storage が含まれています。ストレージアカウントの種類については、「ストレージアカウントの概要」を参照してください。
Azure portal 内で関数アプリを作成する際に、ファイアウォールまたは仮想プライベートネットワークを使用して既にセキュリティで保護されているストレージアカウントを使用することはできません。ただし、ポータルでは現在、これらのセキュリティで保護されたストレージアカウントは除外されません。セキュリティで保護されたストレージアカウントを関数アプリで使用する方法については、「セキュリティで保護されたストレージアカウントを Azure Functions で使用する方法」を参照してください。
従量課金プランにおいてホストされている関数アプリでは、セキュリティで保護されたストレージアカウントを使用することはできません。
ポータルで関数アプリを作成する場合、作成中の関数アプリと同じリージョンにある既存のストレージアカウントのみを選択できます。これはパフォーマンスの最適化のためであり、厳密な制限ではありません。詳細については、「ストレージアカウントの場所」を参照してください。
可用性ゾーンのサポートが有効になっているプランで関数アプリを作成する場合、ゾーン冗長ストレージアカウントのみがサポートされます。

Elastic Premium または Dedicated (App Service) プランにおいては、デプロイの自動化を使用して関数アプリを作成することができます。ただし、ARM テンプレートまたは Bicep ファイル内に、特定のネットワーク構成を含める必要があります。これらの設定とリソースを含めないと、その自動デプロイは検証において失敗する場合があります。詳細については、セキュリティで保護されたデプロイに関する記事を参照してください。

ストレージアカウントに関するガイダンス

すべての関数アプリには、操作するためのストレージアカウントが必要です。そのアカウントが削除されると、関数アプリは実行されません。ストレージ関連の問題をトラブルシューティングするには、ストレージ関連の問題をトラブルシューティングする方法に関する記事を参照してください。関数アプリが使用するストレージアカウントには、次の追加の考慮事項が適用されます。

ストレージアカウントの場所

最適なパフォーマンスを得るには、関数アプリで同じリージョンのストレージアカウントを使用する必要があります。これにより、待ち時間が短縮されます。 Azure portal によって、このベストプラクティスが適用されます。何らかの理由で、関数アプリとは異なるリージョンでストレージアカウントを使用する必要がある場合は、ポータルの外部で関数アプリを作成する必要があります。

ストレージアカウントは関数アプリからアクセスできる必要があります。セキュリティで保護されたストレージアカウントを使う必要がある場合は、ストレージアカウントを仮想ネットワークに制限することを検討してください。

ストレージアカウント接続の設定

既定では、関数アプリは AzureWebJobsStorage 接続を AzureWebJobsStorage アプリケーション設定に保存されている接続文字列として構成しますが、シークレットなしで ID ベースの接続を使用するように AzureWebJobsStorage を構成することもできます。

従量課金プラン (Windows のみ) またはエラスティック Premium プラン (Windows または Linux) で実行されている関数アプリでは、Azure Files を使って、動的スケーリングを有効にするために必要なイメージを格納できます。これらのプランでは、ストレージアカウントの接続文字列を WEBSITE_CONTENTAZUREFILECONNECTIONSTRING で設定し、ファイル共有の名前を WEBSITE_CONTENTSHARE で設定します。これは通常、AzureWebJobsStorage に使われるのと同じアカウントです。また、Azure Files を使わない関数アプリを作成することもできますが、スケーリングが制限される可能性があります。

Note

ストレージキーを再生成する場合は、ストレージアカウント接続文字列を更新する必要があります。ストレージキーの管理については、こちらをご覧ください。

共有のストレージアカウント

複数の Function App では、同じストレージアカウントを問題なく共有できます。たとえば、Visual Studio では、Azure ストレージエミュレーターを使用して複数のアプリを開発できます。この場合、エミュレーターは単一のストレージアカウントのように動作します。お使いの Function App で使用されているものと同じストレージアカウントは、アプリケーションデータを格納するためにも使用できます。ただし、運用環境では、この手法が常に適切であるとは限りません。

ホスト ID の競合を回避するため、個別のストレージアカウントを使うことが必要になる場合があります。

ライフサイクル管理ポリシーに関する考慮事項

関数アプリで使用される Blob Storage アカウントにライフサイクル管理ポリシーを適用すべきではありません。 Functions は Blob Storage を使って関数のアクセスキーなどの重要な情報を保持し、Functions ホストで必要な BLOB (キーなど) がポリシーによって削除される可能性があります。ポリシーを使用する必要がある場合は、Functions によって使用されるコンテナー (接頭辞 azure-webjobs または scm が付いているもの) を除外してください。

ストレージログ

関数のコードとキーはストレージアカウントに保持される可能性があるため、ストレージアカウントに対するアクティビティのログは、認可されていないアクセスを監視するのによい方法です。 Azure Monitor リソースログを使用して、ストレージデータプレーンに対するイベントを追跡できます。これらのログを構成して調べる方法の詳細については、「Azure Storage の監視」を参照してください。

Azure Monitor アクティビティログには、listKeys 操作を含むコントロールプレーンイベントが表示されます。ただし、その後のキーの使用やその他の ID ベースのデータプレーン操作を追跡するには、ストレージアカウントのリソースログも構成する必要があります。通常の Functions 操作以外でのデータの変更を特定できるようにするには、少なくとも StorageWrite ログカテゴリを有効にする必要があります。

広範にスコープが設定されたストレージアクセス許可の潜在的な影響を制限するには、これらのログにストレージ以外の宛先 (Log Analytics など) を使用することを検討してください。詳細については、Azure Blob Storage の監視に関するページを参照してください。

ストレージパフォーマンスの最適化

パフォーマンスを最大化するには、関数アプリごとに個別のストレージアカウントを使用します。 Durable Functions または Event Hub によってトリガーされる関数がある場合には、これは特に重要です。どちらも、大量のストレージトランザクションを生成します。アプリケーションロジックが (Storage SDK を使用して) 直接、あるいは、ストレージバインドの 1 つを経由して Azure Storage と対話する場合、専用のストレージアカウントを使用する必要があります。たとえば、Event Hub によってトリガーされ BLOB ストレージにデータを書き込む関数がある場合、2 つのストレージアカウントを使用します。1 つは関数アプリ用、もう 1 つは関数によって格納されている BLOB 用になります。

BLOB の操作

Functions の主なシナリオは、画像処理や感情分析などを目的とした、BLOB コンテナー内のファイルの処理です。詳細については、「ファイルのアップロードを処理する」を参照してください。

BLOB コンテナーでトリガーする

ストレージコンテナー内の BLOB に対する変更に基づいて関数コードを実行するには、いくつかの方法があります。次の表を使用して、ニーズに最も適した関数トリガーを判断します。

考慮事項	BLOB ストレージ (ポーリング)	BLOB ストレージ (イベントベース)	ストレージ	Event Grid
Latency	高 (最大 10 分)	低	Medium	低
ストレージアカウントの制限	BLOB 専用アカウントはサポートされていません¹	汎用 v1 はサポートされていません	なし	汎用 v1 はサポートされていません
拡張機能のバージョン	Any	Storage v5.x 以上	Any	Any
既存の BLOB の処理	はい	いいえ	番号	いいえ
フィルター	BLOB 名パターン	イベントフィルター	N/A	イベントフィルター
イベントサブスクリプションが必要	いいえ	有効	いいえ	はい
高スケールのサポート²	いいえ	イエス	イエス	はい
説明	既定のトリガー動作。更新のためにコンテナーへのポーリングを利用します。詳細については、Blob Storage トリガーリファレンスの例を参照してください。	イベントサブスクリプションから BLOB ストレージイベントを使用します。 `Source` パラメーター値 `EventGrid` が必要です。詳細については、チュートリアル: イベントサブスクリプションを使用した BLOB コンテナーでの Azure Functions のトリガーに関する記事を参照してください。	コンテナーへの BLOB の追加時に、BLOB 名文字列がストレージキューに手動で追加されます。この値は、Queue Storage トリガーによって、同じ関数の BLOB ストレージ入力バインディングに直接渡されます。	イベント (ストレージコンテナーからのものに加えて) でトリガーする柔軟性を提供します。ストレージ以外のイベントでも関数をトリガーする必要がある場合に使用します。詳細については、「Azure Functions で Event Grid トリガーとバインドを使用する方法」を参照してください。

¹ BLOB ストレージの入力および出力バインドは、BLOB 専用アカウントをサポートしています。
² 高スケールとは、おおまかに言って、100,000 以上の BLOB を含むコンテナー、または 1 秒あたり 100 を超える BLOB の更新が発生するストレージアカウントと定義できます。

ストレージデータの暗号化

Azure Storage は、保存されているストレージアカウント内のすべてのデータを暗号化します。詳細については、「保存データ向け Azure ストレージの暗号化」をご覧ください。

規定では、データは Microsoft のマネージドキーで暗号化されます。暗号化キーをさらに制御するために、BLOB とファイルデータの暗号化に使用する目的で、顧客が管理するキーを提供できます。 Functions からストレージアカウントにアクセスできるように、これらのキーは Azure Key Vault 内に置かれている必要があります。詳細については、「カスタマーマネージドキーを使用した保存時の暗号化」をご覧ください。

リージョンのデータ所在地

すべての顧客データを 1 つのリージョン内に留める必要がある場合、関数アプリに関連付けられているストレージアカウントは、リージョン内冗長性が与えられたアカウントにする必要があります。リージョン内で冗長性を持つストレージアカウントは、Azure Durable Functions でも使用される必要があります。

プラットフォームで管理されるその他の顧客データは、内部負荷分散型の App Service Environment (ASE) でホストしているとき、そのリージョン内にのみ格納されます。詳細については、ASE のゾーン冗長性に関するページを参照してください。

ホスト ID に関する考慮事項

関数は、格納された成果物内の特定の関数アプリを一意に識別する方法として、ホスト ID 値を使用します。既定で、この ID は関数アプリの名前から自動生成され、最初の 32 文字に切り捨てられます。この ID は、アプリごとの相関関係と追跡情報をリンクストレージアカウントに格納するときに使用されます。名前が 32 文字より長い関数アプリがあり、最初の 32 文字が同じである場合、この切り捨てにより、ホスト ID 値が重複する可能性があります。同じホスト ID を持つ 2 つの関数アプリが同じストレージアカウントを使用すると、格納されたデータを正しい関数アプリに一意にリンクできないため、ホスト ID の競合が発生します。

注意

これと同じ種類のホスト ID の競合は、両方のスロットで同じストレージアカウントが使用されている場合、運用スロットの関数アプリとステージングスロットの同じ関数アプリの間で発生する可能性があります。

Functions ランタイムのバージョン 3.x 以降では、ホスト ID の競合が検出され、警告がログに記録されます。バージョン 4.x では、エラーがログに記録され、ホストが停止し、ハード障害が発生します。ホスト ID の競合の詳細については、「この問題」を参照してください。

ホスト ID の競合回避

次の方法を使用して、ホスト ID の競合を回避できます。

競合に関与する関数アプリやスロットごとに、個別のストレージアカウントを使用します。
いずれかの関数アプリの名前を 32 文字未満の値に変更します。これにより、アプリ用に計算されたホスト ID が変更され、競合がなくなります。
競合する 1 つ以上のアプリの明示的なホスト ID を設定します。詳細については、「ホスト ID のオーバーライド」を参照してください。

重要

既存の関数アプリに関連付けられているストレージアカウントを変更したり、アプリのホスト ID を変更したりすると、既存の関数動作に影響を与える可能性があります。たとえば、BLOB ストレージトリガーを使用すると、ストレージ内の特定のホスト ID パスの下に領収書を書き込むことによって、個々の BLOB が処理されたかどうかの追跡が行われます。ホスト ID が変更されると、またはユーザーが新しいストレージアカウントを指定すると、以前に処理された BLOB が再処理される可能性があります。

ホスト ID をオーバーライドする

関数アプリの特定のホスト ID は、AzureFunctionsWebHost__hostid 設定を使用して、アプリケーション設定で明示的に設定できます。詳細については、「AzureFunctionsWebHost__hostid」を参照してください。

スロット間で競合が発生した場合は、運用スロットを含め、スロットごとに特定のホスト ID を設定する必要があります。これらの設定は、スワップされないようにデプロイ設定としてマークする必要もあります。アプリ設定を作成する方法については、「アプリケーション設定の操作」を参照してください。

Azure Arc 対応クラスター

関数アプリが Azure Arc 対応 Kubernetes クラスターにデプロイされるときは、関数アプリでストレージアカウントが必要ない場合があります。この場合、ストレージアカウントは、関数アプリがストレージを必要とするトリガーを使用する場合にのみ、Functions によって必要になります。次の表では、ストレージアカウントが必要になる可能性があるトリガーと必要ないトリガーを示します。

必要なし	ストレージが必要な場合がある
• Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus	• Azure SQL • BLOB ストレージ • Event Grid • Event Hubs • IoT Hub • Queue Storage • SendGrid • SignalR • Table Storage • Timer • Twilio

ストレージのない Azure Arc 対応 Kubernetes クラスターで関数アプリを作成するには、Azure CLI コマンド az functionapp create を使用する必要があります。 Azure CLI のバージョンには、バージョン 0.1.7 以降の appservice-kube 拡張機能が含まれている必要があります。 az --version コマンドを使用して、拡張機能がインストールされ、正しいバージョンであることを確認します。

Azure CLI 以外の方法を使用して関数アプリリソースを作成するには、既存のストレージアカウントが必要です。ストレージアカウントを必要とするトリガーを使用する予定の場合は、関数アプリを作成する前にアカウントを作成する必要があります。

Azure Files を使わずにアプリを作成する

エラスティック Premium プランと Linux 以外の従量課金プランでは、高スケールのシナリオでの共有ファイルシステム用として、既定で Azure Files が設定されます。このファイルシステムは、それらのプラットフォームでログストリーミングなどの機能を実現するためにも使用しますが、主な用途は、デプロイした機能のペイロードを安定的に送信することです。外部パッケージの URL を使用してアプリをデプロイするときは、そのアプリのコンテンツを読み取り専用の別のファイルシステムから提供します。つまり、Azure Files を使用せずに関数アプリを作成できます。 Azure Files を使用して関数アプリを作成した場合でも、書き込み可能なファイルシステムが提供されます。ただし、このファイルシステムはすべての関数アプリインスタンスで使用できるわけではありません。

Azure Files を使用しない場合は、次の要件を満たす必要があります。

外部パッケージの URL からデプロイする必要があります。
書き込み可能な共有ファイルシステムの使用を前提にした運用はできません。
アプリは Functions ランタイムのバージョン 1.x を使用できません。
Azure portal などのクライアントのログストリーミングで、既定のログがファイルシステムのログになります。これの代わりに、Application Insights のログを使用してください。

上の点が適切に考慮されていれば、Azure Files を使わずにアプリを作成できます。アプリケーションの設定 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING と WEBSITE_CONTENTSHARE を指定せずに、関数アプリを作成してください。この設定を回避するには、標準のデプロイ用の ARM テンプレートを生成し、これらの 2 つの設定を削除し、テンプレートをデプロイします。

Functions では動的スケールアウトプロセスの一部で Azure Files が使われるため、従量課金プランやエラスティック Premium プランで Azure Files を使わずに実行すると、スケーリングが制限される場合があります。

ファイル共有をマウントする

"この機能は現在、Linux で実行されている場合にのみ使用できます。 "

既存の Azure Files 共有を Linux 関数アプリにマウントすることができます。 Linux 関数アプリに共有をマウントすると、既存の機械学習モデルや関数内のその他のデータを活用できます。次のコマンドを使用して、既存の共有を Linux 関数アプリにマウントできます。

Azure CLI
Azure PowerShell

az webapp config storage-account add

このコマンドで、share-name は既存の Azure Files 共有の名前で、custom-id は、Function App にマウントされたときに共有を一意に定義する任意の文字列にすることができます。また、mount-path は、Function App で共有にアクセスするためのパスです。 mount-path は、/dir-name の形式にする必要があり、/home で開始することはできません。

完全な例については、Python 関数アプリの作成と Azure Files 共有のマウントに関する記事のスクリプトを参照してください。

New-AzWebAppAzureStoragePath

このコマンドでは、-ShareName は既存の Azure Files 共有の名前で、-MountPath は関数アプリで共有にアクセスするためのパスを指定します。 -MountPath は、/dir-name の形式にする必要があり、/home で開始することはできません。パスを作成したら、-AzureStoragePath の Set-AzWebApp パラメーターを使用して、アプリに共有を追加します。

完全な例については、「サーバーレス Python 関数アプリの作成と Files 共有のマウント」に関する記事にあるスクリプトを参照してください。

現時点では、AzureFiles の storage-type のみがサポートされています。指定された Function App にマウントできるのは 5 つの共有のみです。ファイル共有をマウントすると、コールドスタートの時間が少なくとも 200 ミリ秒から 300 ミリ秒長くなる可能性があり、ストレージアカウントが別のリージョンにある場合はさらに長くなる可能性があります。

マウントされた共有は、指定された mount-path の関数コードで使用できます。たとえば、mount-path が /path/to/mount の場合、次の Python の例に示すように、ファイルシステム API でターゲットディレクトリにアクセスできます。

import os
...

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

次のステップ

Azure Functions ホスティングのオプションについて確認してください。

Azure Functions のスケールとホスティング