Azureで関数アプリ インスタンスを作成する場合は、既定のAzure Storage アカウントへのアクセス権を付与する必要があります。 次の図と表では、Azure Functionsが既定のストレージ アカウントでサービスを使用する方法について詳しく説明します。
この記事の冒頭でホスティングプランを選択すると、あなたの機能アプリに適用されるストレージガイダンスが表示されます。
| ストレージ サービス | 機能の使用法 |
|---|---|
| Azure Blob ストレージ | バインドの状態と関数キー1を管理します。 Flex 従量課金プランで実行されるアプリのデプロイ ソース。 Durable Functions の task ハブ に既定で使用されます。 Linux 従量課金プラン リモート ビルド用の関数アプリ コードを格納するため、または外部パッケージ URL デプロイの一部として、使用できます。 |
| Azure Files2 |
従量課金プランや Premium プランで、関数アプリ コードを格納して実行するために使用されるファイル共有。 拡張機能バンドルを維持します。 デプロイ ログを格納します。 PowerShell でマネージド依存関係をサポートします。 |
| Azure Queue Storage | Durable Functions の task ハブ に既定で使用されます。 の特定のAzure Functionsトリガーでのエラー処理と再試行処理に使用されます。 BLOB ストレージ トリガーによるオブジェクト追跡に使用されます。 |
| Azure テーブル ストレージ | Durable Functions の task ハブ に既定で使用されます。 診断イベントの追跡に使用されます。 |
- Blob Storage は関数キーの既定のストアですが、代替ストアを構成できます。
- Azure Filesは既定で設定されますが、特定の条件下でAzure Filesなしでアプリを作成できます。
重要な考慮事項
あなたの機能アプリで使われているストレージアカウントについて、以下の事実を考慮してください。
Consumption Plan(Windows)またはPremiumプランで関数型アプリをホストする際、関数コードと設定ファイルをリンクされたストレージアカウントのAzure Filesに保存します。 このストレージアカウントを削除すると、そのコンテンツも永久に削除されます。 詳細については、「 ストレージ アカウントが削除されました」を参照してください。
ストレージアカウントは、機能コード、 アクセスキー、その他の重要なサービス関連データなどの重要なデータを保持します。 関数アプリで使用されるストレージ アカウントへのアクセスは、次の方法で慎重に管理する必要があります。
最小特権モデルに基づいて、ストレージ アカウントへのアプリとユーザーのアクセスを監査および制限します。 ストレージ アカウントへのアクセス許可は、割り当てられたロールのデータ アクションから、または listKeys 操作を実行するためのアクセス許可を通じて取得できます。
ストレージ アカウント内のコントロール プレーン アクティビティ (キーの取得など) とデータ プレーン操作 (BLOB への書き込みなど) の両方を監視します。 Azure Storage以外の場所にストレージ ログを保持することを検討してください。 詳細については、「ストレージ ログ」を参照してください。
Durable Functions を使用する場合、タスク ハブ ストレージへの書き込みアクセスを使用して、任意のコード実行のトリガーなど、アプリケーションの動作を変更できるため、特にセキュリティが重視されます。 詳細については、「 タスク ハブ ストレージのセキュリティ保護」を参照してください。
ストレージ アカウントの要件
Azure ポータルで関数アプリの作成プロセス中に作成したストレージ アカウントは、新しい関数アプリと連携します。 既存のストレージ アカウントを使用することを選択した場合、指定された一覧には、サポートされていない特定のストレージ アカウントは含まれません。 関数アプリで使用されるストレージ アカウントには、次の制限が適用されます。 既存のストレージアカウントが以下の要件を満たしているか確認してください:
- 従量課金プランで関数アプリがホストされていると、ネットワークで保護されたストレージ アカウントを使用することはできません。
アカウントの種類は、BLOB、Queue、Table Storage をサポートしている必要があります。 一部のストレージ アカウントでは、キューとテーブルがサポートされません。 これらのアカウントには、BLOB 専用ストレージ アカウントとAzure Premium Storageが含まれます。 ストレージ アカウントの種類については、「ストレージ アカウントの概要」を参照してください。
Azure ポータルで関数アプリを作成する場合は、作成した関数アプリと同じリージョンにある既存のストレージ アカウントのみを選択できます。 この要件はパフォーマンスの最適化であり、厳密な制限ではありません。 詳細については、「ストレージ アカウントの場所」を参照してください。
可用性ゾーンのサポートが有効になっているプランで関数アプリを作成する場合は、ゾーン冗長ストレージ アカウントのみがサポートされます。
デプロイ自動化を使用して、ネットワークで保護されたストレージ アカウントを使用して関数アプリを作成する場合は、ARM テンプレートまたはBicep ファイルに特定のネットワーク構成を含める必要があります。 これらの設定とリソースを含めない場合、自動デプロイが検証で失敗する可能性があります。 ARM テンプレートと Bicep ガイダンスについては、セキュアなデプロイメントを参照してください。 ネットワークを使用してストレージ アカウントを構成する方法の概要については、「
ストレージ アカウントに関するガイダンス
すべての関数アプリには、操作するためのストレージ アカウントが必要です。 そのアカウントを削除すると、関数アプリの実行が停止します。 ストレージ関連の問題をトラブルシューティングするには、ストレージ関連の問題をトラブルシューティングする方法に関する記事を参照してください。 関数アプリで使用されるストレージ アカウントには、次の考慮事項が適用されます。
ストレージ アカウントの場所
最適なパフォーマンスを得るには、関数アプリで同じリージョンのストレージ アカウントを使用する必要があります。これにより、待ち時間が短縮されます。 Azure ポータルでは、このベスト プラクティスが適用されます。 関数アプリとは異なるリージョンでストレージ アカウントを使用する必要がある場合は、Azure ポータルの外部で関数アプリを作成する必要があります。
ストレージ アカウントは関数アプリからアクセスできる必要があります。 セキュリティで保護されたストレージ アカウントを使う必要がある場合は、ストレージ アカウントを仮想ネットワークに制限することを検討してください。
ストレージ アカウント接続の設定
既定では、関数アプリは、AzureWebJobsStorage 接続を、AzureWebJobsStorage アプリケーション設定に格納されている接続文字列として構成します。 シークレットなしで ID ベースの接続を使用するように AzureWebJobsStorage を構成 することもできます。
従量課金プラン (Windows のみ) または Elastic Premium プラン (Windows または Linux) で実行されている関数アプリは、Azure Filesを使用して、動的スケーリングを有効にするために必要なイメージを格納できます。 これらのプランでは、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 設定のストレージ アカウントの接続文字列と、WEBSITE_CONTENTSHARE 設定のファイル共有の名前を設定します。 この値は、通常、 AzureWebJobsStorageに使用されるアカウントと同じです。
Azure Filesを使用しない関数アプリを作成することもできますが、スケーリングが制限される可能性があります。
注
ストレージ キーを再生成するときに、ストレージ アカウントの接続文字列を更新する必要があります。 詳細については、「Azure ストレージ アカウントを作成するを参照してください。
共有のストレージ アカウント
複数の関数アプリで、同じストレージ アカウントを問題なく共有できます。 たとえば、Visual Studioでは、Azurite ストレージ エミュレーターを使用して複数のアプリを開発できます。 この場合、エミュレーターは単一のストレージ アカウントのように動作します。 関数アプリで使用されるのと同じストレージ アカウントで、アプリケーション データを格納することもできます。 ただし、運用環境では、この手法が常に適切であるとは限りません。
ホスト ID の競合を回避するため、個別のストレージ アカウントを使うことが必要になる場合があります。
ライフサイクル管理ポリシーに関する考慮事項
lifecycle 管理ポリシーを関数アプリで使用されるBlob Storageアカウントに適用しないでください。 関数は、Blob Storage を使用して、 関数アクセス キーなどの重要な情報を保持します。 ポリシーでは、Functions ホストで必要なキーなどの BLOB を削除できます。 ポリシーを使用する必要がある場合は、Functions によって使用されるコンテナー (接頭辞 azure-webjobs または scm が付いているもの) を除外してください。
ストレージ ログ
関数のコードとキーはストレージ アカウントに保持される可能性があるため、ストレージ アカウントに対するアクティビティのログは、認可されていないアクセスを監視するのによい方法です。 Azure Monitorリソース ログを使用して、ストレージ データ プレーンに対するイベントを追跡できます。 これらのログを構成して調べる方法の詳細については、Monitoring Azure Storage を参照してください。
Azure Monitor アクティビティ ログには、listKeys 操作を含むコントロール プレーン イベントが表示されます。 ただし、その後のキーの使用やその他の ID ベースのデータ プレーン操作を追跡するには、ストレージ アカウントのリソース ログも構成する必要があります。 通常の Functions 操作以外でのデータの変更を特定できるようにするには、少なくとも StorageWrite ログ カテゴリを有効にする必要があります。
広範にスコープが設定されたストレージアクセス許可の潜在的な影響を制限するには、Log Analyticsなど、これらのログに対して非ストレージの宛先を使用することを検討してください。 詳細については、「Monitoring Azure Blob Storageを参照してください。
ストレージ パフォーマンスの最適化
パフォーマンスを最大化するには、関数アプリごとに個別のストレージ アカウントを使用します。 この方法は、Durable Functionsまたは Event Hubs によってトリガーされる関数があり、どちらも大量のストレージ トランザクションを生成する場合に特に重要です。 アプリケーション ロジックが直接 (Storage SDK を使用して) またはストレージ バインディングのいずれかを使用してAzure Storageと対話する場合は、専用のストレージ アカウントを使用する必要があります。 たとえば、イベント ハブによってトリガーされる関数が BLOB ストレージにデータを書き込む場合は、関数アプリ用と関数が格納する BLOB 用の 2 つのストレージ アカウントを使用します。
仮想ネットワーク経由の一貫性のあるルーティング
同じプランでホストされている複数の関数アプリは、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING によって定義された、Azure Files コンテンツ共有に同じストレージ アカウントを使用することもできます。 仮想ネットワークを使用してこのストレージ アカウントをセキュリティで保護する場合、トラフィックが目的の仮想ネットワークを通じて一貫してルーティングされるように、これらのアプリ (スロットを含む) はすべて、 vnetContentShareEnabled (以前の WEBSITE_CONTENTOVERVNET) と同じ仮想ネットワーク統合構成に同じ値を使用する必要があります。 同じAzure Filesストレージ アカウントを使用するアプリ間でこの設定が一致しない場合、パブリック ネットワーク経由のトラフィック ルーティングが発生する可能性があります。 この構成では、ストレージ アカウントのネットワーク 規則によってアクセスがブロックされます。
vnetContentShareEnabledガイダンスはフレックスコンシューマー、専用アプリ、コンテナアプリ、コンシューマーホスティングには適用されません。
BLOB の操作
Functions の主なシナリオは、画像処理や感情分析などを目的とした、BLOB コンテナー内のファイルの処理です。 詳細については、「ファイルのアップロードを処理する」を参照してください。
BLOB コンテナーでトリガーする
次の図に示すように、ストレージ コンテナー内の BLOB への変更に基づいて関数コードを実行する方法はいくつかあります。
Azure の Blob Storage コンテナーで項目が追加または更新されたときに関数をトリガーするためのさまざまなオプションを示す図。
次の表を使用して、コンテナー内の追加または更新された BLOB を処理するためのニーズに最も適した関数トリガーを判断します。
| 戦略 | BLOB トリガー (ポーリング) | BLOB トリガー (イベント駆動) | キュー トリガー | Event Grid トリガー |
|---|---|---|---|---|
| 遅延 | 高 (最大 10 分) | 低 | ミディアム | 低 |
| ストレージ アカウントの制限 | Blob専用アカウント¹や階層的名前空間(HNS)が有効になっているアカウント(Azure Data Lake Storage Gen2など)はサポートしていません | 汎用v1アカウントはサポートしていません | なし | 汎用v1アカウントはサポートしていません |
| トリガーの種類 | Blob Storage | Blob Storage | Queue Storage | イベントグリッド |
| 拡張機能のバージョン | [任意] | Storage v5.x 以上 | [任意] | [任意] |
| 既存の BLOB の処理 | はい | いいえ | いいえ | いいえ |
| フィルター | BLOB 名パターン | イベント フィルター | 該当なし | イベント フィルター |
| イベント サブスクリプションが必要 | いいえ | はい | いいえ | はい |
| Flex 従量課金プランのサポート | いいえ | はい | はい | はい |
| 高スケールのサポート² | いいえ | はい | はい | はい |
| 受信アクセス制限に対応 | はい | いいえ | はい | はい3 |
| 説明 | 既定のトリガー動作。更新のためにコンテナーへのポーリングを利用します。 詳細については、Blob Storage トリガー リファレンスの例を参照してください。 | イベント サブスクリプションから BLOB ストレージ イベントを使用します。
Source パラメーター値 EventGrid が必要です。 詳細については、「Tutorial: イベント サブスクリプションを使用して BLOB コンテナーのAzure Functionsをトリガーするを参照してください。 |
コンテナーへの BLOB の追加時に、BLOB 名文字列がストレージ キューに手動で追加されます。 キュー ストレージ トリガーは、この値を同じ関数の BLOB ストレージ入力バインドに直接渡します。 | ストレージ コンテナーから発生するイベントに加えて、イベントをトリガーする柔軟性を提供します。 ストレージ以外のイベントでも関数をトリガーする必要がある場合に使用します。 詳細については、「 |
- Blob専用アカウントの制限は、ポーリングベースのBlobストレージトリガーにのみ適用されます。 BLOB ストレージの入力および出力バインドは、BLOB 専用アカウントをサポートしています。
- 高スケールとは、おおまかに言って、100,000 以上の BLOB を含むコンテナー、または 1 秒あたり 100 を超える BLOB の更新が発生するストレージ アカウントと定義できます。
- イベント サブスクリプションで既知のユーザー ID を使用してパブリック IP 空間内の暗号化されたチャネル経由でイベントを配信することで、受信アクセス制限を回避できます。 詳細については、「 マネージド ID を使用してイベントを安全に配信する」を参照してください。
ストレージ データの暗号化
Azure Storageは、保存中のストレージ アカウント内のすべてのデータを暗号化します。 詳細については、「Azure Storage保存データの暗号化を参照してください。
既定では、データはMicrosoftマネージド キーを使用して暗号化されます。 暗号化キーをより詳細に制御するために、BLOB とファイル データの暗号化に使用するカスタマー マネージド キーを指定できます。 Functions がストレージ アカウントにアクセスできるようにするには、これらのキーがAzure Key Vaultに存在する必要があります。 詳細については、「 カスタマー マネージド キーを使用して保存中のアプリケーション データを暗号化する」を参照してください。
リージョンのデータ所在地
すべての顧客データが単一のリージョン内に留まる必要がある場合は、機能アプリに関連付けられたリー ジョン内冗長性のあるストレージアカウントを使いましょう。 また、Azure Durable Functionsで地域内の冗長ストレージアカウントも使ってください。
プラットフォームは、内部負荷分散型App Service Environment(ASE)でホストする場合、他のプラットフォーム管理顧客データをリージョン内にのみ保存します。 詳細については、ASE のゾーン冗長性に関するページを参照してください。
ホスト ID に関する考慮事項
このセクションでのホストIDの考慮はフレックス消費には適用されません。 このホスティングプランでは、ホストIDの値がこれらの潜在的な問題を避ける方法で作成されます。
FunctionsはホストID値を用いて、保存されたアーティファクト内で特定の関数アプリを一意に識別します。 デフォルトでは、実行時は関数アプリの名前からこのIDを自動的に生成し、最初の32文字に短縮しています。 ランタイムは、リンクされたストレージアカウントにアプリごとの相関情報や追跡情報を格納する際にこのIDを使用します。 関数アプリの名前が32文字を超え、最初の32文字が同一の場合、この短縮がホストID値の重複を引き起こすことがあります。 同じホストIDを持つ2つの機能アプリが同じストレージアカウントを使う場合、保存されたデータが正しい機能アプリに一意にリンクできないため、ホストIDの衝突が発生します。
注
同じ種類のホストIDの衝突は、両スロットが同じストレージアカウントを使用している場合、本番スロットの機能アプリとステージングスロットの同じ機能アプリ間でも起こり得ます。
Functions ランタイムのバージョン 4.x では、エラーがログに記録され、ホストが停止し、その結果、致命的な障害に至ります。 詳細については、「HostID の切り捨てが競合を引き起こす可能性があるを参照してください。
ホスト ID の競合回避
ホストIDの衝突を避けるために以下の戦略を用いてください:
- 別々のストレージアカウントを使って、競合する各ホストが異なるアカウントに書き込みできるようにします。
- 関数アプリの1つを名前を32文字未満に変えると、計算されたホストIDが変わり、衝突がなくなります。
- 競合する 1 つ以上のアプリの明示的なホスト ID を設定します。 詳細については、「 ホスト ID をオーバーライドする」を参照してください。
重要
既存の関数アプリに関連付けられているストレージ アカウントを変更したり、アプリのホスト ID を変更したりすると、既存の関数の動作に影響する可能性があります。 例えば、Blob ストレージ トリガーは、ストレージ内の特定のホスト ID パス配下に受領記録を書き込むことで、個々の Blob が処理済みかどうかを追跡します。 ホスト ID が変更されると、またはユーザーが新しいストレージ アカウントを指定すると、以前に処理された BLOB が再処理される可能性があります。
ホスト ID をオーバーライドする
アプリケーション設定の「 AzureFunctionsWebHost__hostid 」を使って関数アプリの明示的なホストIDを設定できます。 詳細については、「AzureFunctionsWebHost__hostid」を参照してください。
スロット間で衝突が発生した場合、各スロット(生産スロットを含む)ごとに特定のホストIDを設定しなければなりません。 これらの設定は、スワップされないように デプロイ設定 としてマークする必要もあります。 アプリ設定を作成する方法については、「 アプリケーション設定の操作」を参照してください。
Azure Filesなしでアプリを作成する
Azure Files サービスは、大規模なシナリオをサポートする共有ファイル システムを提供します。 関数アプリが Elastic Premium プランまたは従量課金プランのWindowsで実行されると、ストレージ アカウントに既定でAzure Files共有が作成されます。 関数はこの共有をログストリーミングや共有アプリコンテンツの場所として利用できます。 展開場所は展開技術やアプリの設定によって異なります。 例えば、外部パッケージURLを使うアプリは、Azure Files共有ではなく設定済みのURLからパッケージを実行します。
Azure Filesを使うには接続文字列が必要で、それはアプリの設定にWEBSITE_CONTENTAZUREFILECONNECTIONSTRINGとして保存されます。 Azure Filesは現在、ID ベースの接続をサポートしていません。 もしあなたのシナリオでアプリ設定にシークレットを保存しない必要があるなら、Azure Filesへの依存を取り除く必要があります。 既定のAzure Files依存関係なしでアプリを作成することで、この依存関係を回避できます。
注
また、Flex Consumptionプランで関数アプリを動かすことも検討すべきです。これにより、デプロイメントパッケージをより細かく制御でき、マネージドID接続の使用も可能です。 詳細については、「 展開設定の構成」を参照してください。
Azure Files共有なしでアプリを動かすには、以下の要件を満たす必要があります:
パッケージを匿名アクセスを許さないAzure Blob Storageコンテナにデプロイし、パッケージのBlob Storage URLを
WEBSITE_RUN_FROM_PACKAGEアプリの設定に設定する必要があります。パッケージURLにデプロイ認証情報を保存しないため、 関数アプリの管理IDアクセス権をパッケージに付与します。 ユーザー割り当てのIDを使う場合は、
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_IDも設定してください。 管理IDが使えない場合は、共有アクセス署名(SAS)URLを使い、SASの期限切れ前に更新してください。アプリの設定からデフォルトのホストストレージアカウントの接続文字列を削除するには、
AzureWebJobsStorageを管理IDを使うように設定してください。デプロイメントパッケージは手動で更新し、デプロイメントパッケージのURLも維持する必要があります。 パッケージを更新した際のアプリの再起動やトリガー同期については、「 外部パッケージURLから実行」を参照してください。
また、次の考慮事項にも注意してください。
- アプリは共有の書き込み可能なファイルシステムに頼ってはいけません。
- ポータルの編集はサポートされていません。
- Azure ポータルなどのクライアントでのログ ストリーミング エクスペリエンスは、既定でファイル システム ログに設定されます。 これの代わりに、Application Insights のログを使用するべきです。
上記の要件がシナリオに適している場合は、Azure Filesなしで関数アプリの作成に進むことができます。 次のいずれかの方法で、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING と WEBSITE_CONTENTSHARE アプリの設定なしでアプリを作成します。
- Bicep/ARMテンプレート:ARMテンプレートまたはBicepファイルから2つのアプリ設定を削除し、修正したテンプレートを使ってアプリをデプロイします。
- Azure portal: Azure portal でアプリを作成するときに、Storage タブで Azure Files 接続の追加 をクリアします。
Azure Filesは、Functions の動的スケールアウトを有効にするために使用されます。 Azure Files を使用せずに、Elastic Premium プランや Windows で実行される従量課金プランでアプリを実行すると、スケーリングが制限される可能性があります。
Flex ConsumptionはAzure Filesのコンテンツ共有に依存しません。 設定可能なBlobデプロイメントストレージを使用し、管理型アイデンティティ接続をサポートします。 詳細については、「 展開設定の構成」を参照してください。
専用プランアプリには、このセクションで説明されているデフォルトのAzure Filesコンテンツシェア依存関係はありません。
Azure Container Apps 上の Functions は、このセクションで説明されているデフォルトの Azure Files content-share 依存関係を持っていません。
ファイル共有をマウントする
この機能はLinux上で動作している場合にのみ利用可能です。
Azure Filesの共有をLinux関数アプリにマウントでき、既存のファイルや機械学習モデル、関数内の大きなバイナリにアクセスすることができます。 ストレージ マウント、バインディング、および外部データベースの選択に関する概念的なガイダンスについては、「Azure Functions のファイル アクセス戦略を検討する」を参照してください。
Flex ConsumptionはServer Message Block(SMB)Azure Filesマウントのみをサポートしています。
以下のコマンドを使って、既存の共有をLinux関数アプリにマウントしてください。
az webapp config storage-account add
このコマンドでは、share-name は既存のAzure Files共有の名前です。
custom-id には、関数アプリにマウントするときに共有を一意に定義する任意の文字列を指定できます。 また、mount-path は、関数アプリで共有にアクセスするためのパスです。
mount-path は、/dir-name の形式にする必要があり、/home で開始することはできません。
完全な例については、「Python関数アプリを作成し、Azure Files共有をマウントするを参照してください。
Functions on Azure Container Apps の場合は、container app 上で Azure Files ボリュームを設定します。 詳細については、「
ストレージマウントは消費プランではサポートされていません。
重要
従量課金プランで Linux で 有効期間終了 v3 ランタイム を実行している関数アプリは、2026 年 9 月 30 日以降も実行を停止します。 サービスの中断を回避するには、 アプリを v4 ランタイムに移行します。
従量課金プランで Linux で関数アプリをホストするオプションは、2028 年 9 月 30 日に廃止されます。 Linux 従量課金プランでは、新しい機能や 言語バージョンは取得されません。 従量課金プランのWindowsで実行されているアプリは、現在影響を受けません。 提供終了日より前に、アプリを Flex 従量課金プランに移行します。