Azure Functions のストレージに関する考慮事項
Azure Functions では、Function App インスタンスを作成するときに Azure ストレージ アカウントが必要になります。 関数アプリでは次のストレージ サービスを使用できます。
| ストレージ サービス | Functions の使用法 |
|---|---|
| Azure BLOB Storage | バインドの状態と関数キー1を管理します。 Flex 従量課金プランで実行されるアプリのデプロイ ソース。 既定では、Durable Functions 上のタスク ハブから使用されます。 Linux 従量課金プラン リモート ビルド用の関数アプリ コードを格納するため、または外部パッケージ URL デプロイの一部として、使用できます。 |
| Azure Files2 | 従量課金プランや 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 が含まれています。 ストレージ アカウントの種類については、「ストレージ アカウントの概要」を参照してください。
従量課金プランで関数アプリがホストされていると、ネットワークで保護されたストレージ アカウントを使用することはできません。
ポータルで関数アプリを作成する場合、作成中の関数アプリと同じリージョンにある既存のストレージ アカウントのみを選択できます。 これはパフォーマンスの最適化のためであり、厳密な制限ではありません。 詳細については、「ストレージ アカウントの場所」を参照してください。
可用性ゾーンのサポートが有効になっているプランで関数アプリを作成する場合、ゾーン冗長ストレージ アカウントのみがサポートされます。
デプロイ自動化を使用してネットワークで保護されたストレージ アカウントで関数アプリを作成する場合は、ARM テンプレートまたは Bicep ファイルに特定のネットワーク構成を含める必要があります。 これらの設定とリソースを含めないと、その自動デプロイは検証において失敗する場合があります。 より具体的な ARM と Bicep のガイダンスについては、セキュリティで保護されたデプロイに関するページを参照してください。 ネットワークを使用してストレージ アカウントを構成する方法の概要については、「セキュリティで保護されたストレージ アカウントを Azure Functions で使用する方法」を参照してください。
ストレージ アカウントに関するガイダンス
すべての関数アプリには、操作するためのストレージ アカウントが必要です。 そのアカウントが削除されると、関数アプリは実行されません。 ストレージ関連の問題をトラブルシューティングするには、ストレージ関連の問題をトラブルシューティングする方法に関する記事を参照してください。 関数アプリが使用するストレージ アカウントには、次の追加の考慮事項が適用されます。
ストレージ アカウントの場所
最適なパフォーマンスを得るには、関数アプリで同じリージョンのストレージ アカウントを使用する必要があります。これにより、待ち時間が短縮されます。 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 用になります。
仮想ネットワーク経由の一貫性のあるルーティング
同じプランでホストされている複数の関数アプリが、(WEBSITE_CONTENTAZUREFILECONNECTIONSTRING によって定義された) Azure Files コンテンツ共有に同じストレージ アカウントを使用することもできます。 このストレージ アカウントが仮想ネットワークによっても保護されている場合、トラフィックが意図した仮想ネットワーク経由で一貫してルーティングされることを保証するために、これらすべてのアプリが vnetContentShareEnabled (旧称 WEBSITE_CONTENTOVERVNET) にも同じ値を使用する必要があります。 同じ Azure Files ストレージ アカウントを使用するアプリ間でこの設定が一致しない場合、トラフィックがパブリック ネットワーク経由でルーティングされ、その結果、ストレージ アカウントのネットワーク規則によってアクセスがブロックされる可能性があります。
BLOB の操作
Functions の主なシナリオは、画像処理や感情分析などを目的とした、BLOB コンテナー内のファイルの処理です。 詳細については、「ファイルのアップロードを処理する」を参照してください。
BLOB コンテナーでトリガーする
ストレージ コンテナー内の BLOB に対する変更に基づいて関数コードを実行するには、いくつかの方法があります。 次の表を使用して、ニーズに最も適した関数トリガーを判断します。
| 戦略 | コンテナー (ポーリング) | コンテナー (イベント) | キュー トリガー | Event Grid |
|---|---|---|---|---|
| Latency | 高 (最大 10 分) | 低 | Medium | 低 |
| ストレージ アカウントの制限 | BLOB 専用アカウントはサポートされていません¹ | 汎用 v1 はサポートされていません | なし | 汎用 v1 はサポートされていません |
| トリガーの種類 | Blob Storage | Blob Storage | Queue Storage | Event Grid |
| 拡張機能のバージョン | Any | Storage v5.x 以上 | Any | Any |
| 既存の BLOB の処理 | はい | いいえ | いいえ | いいえ |
| フィルター | BLOB 名パターン | イベント フィルター | N/A | イベント フィルター |
| イベント サブスクリプションが必要 | いいえ | 有効 | いいえ | はい |
| Flex 従量課金プランのサポート | いいえ | イエス | イエス | はい |
| 高スケールのサポート² | いいえ | イエス | イエス | はい |
| 説明 | 既定のトリガー動作。更新のためにコンテナーへのポーリングを利用します。 詳細については、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 の競合が発生します。
Note
これと同じ種類のホスト 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 を使わずにアプリを作成する
Azure Files サービスには、大規模なシナリオをサポートする共有ファイル システムが備わっています。 関数アプリが Elastic Premium プランまたは従量課金プランの Windows で実行されている場合、Azure Files 共有は既定でご自分のストレージ アカウントに作成されます。 この共有は、ログ ストリーミングなどの特定の機能を有効にするために Functions によって使用されます。 また、共有パッケージのデプロイ場所としても使用されます。これにより、すべてのインスタンスにわたってデプロイされた関数コードの一貫性が保証されます。
既定では、Premium プランと従量課金プランでホストされている関数アプリは、この Azure ファイル共有に格納された展開パッケージと共に、zip デプロイを使用します。 このセクションは、これらのホスティング プランにのみ関連します。
Azure Files を使用するには、接続文字列を使用する必要があります。接続文字列は、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING としてアプリ設定に格納されます。 Azure Files では現在、ID ベースの接続はサポートされていません。 シナリオでアプリ設定にシークレットを格納しないようにする必要がある場合は、Azure Files でアプリの依存関係を削除する必要があります。 これを行うには、既定の Azure Files の依存関係なしでアプリを作成します。
Note
また、マネージド ID 接続を使用する機能など、展開パッケージをより厳密に制御できる Flex 従量課金プランで関数アプリを実行することも検討する必要があります。 詳細については、Flex 従量課金に関する記事の「デプロイ設定を構成する」を参照してください。
Azure ファイル共有なしでアプリを実行するには、次の要件を満たす必要があります。
- リモートの Azure Blob Storage コンテナーにパッケージをデプロイし、そのパッケージへのアクセスを提供する URL を
WEBSITE_RUN_FROM_PACKAGEアプリ設定として設定する必要があります。 このオプションを使用すると、Azure Files ではなく Blob Storage にアプリ コンテンツを格納できます。これにより、マネージド ID がサポートされます。
展開パッケージを手動で更新し、共有アクセス署名 (SAS) が含まれている可能性がある展開パッケージの URL を維持する必要があります。
- 書き込み可能な共有ファイル システムの使用を前提にした運用はできません。
- アプリは Functions ランタイムのバージョン 1.x を使用できません。
- Azure portal などのクライアントのログ ストリーミングで、既定のログがファイル システムのログになります。 これの代わりに、Application Insights のログを使用してください。
上記の要件がシナリオに適している場合は、Azure Files を使用せずに関数アプリの作成に進めることができます。 これを行うには、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING と WEBSITE_CONTENTSHARE のアプリ設定を使用せずにアプリを作成します。 これを行うには、標準の展開用の ARM テンプレートを生成し、この 2 つの設定を削除し、変更したテンプレートをデプロイします。
Azure Files は Functions の動的スケールアウトを有効にするために使用されるため、Elastic Premium プランと Windows で実行されている従量課金プランで Azure Files を使用せずにアプリを実行する場合、スケーリングが制限される可能性があります。
ファイル共有をマウントする
"この機能は現在、Linux で実行されている場合にのみ使用できます。 "
既存の Azure Files 共有を Linux 関数アプリにマウントすることができます。 Linux 関数アプリに共有をマウントすると、既存の機械学習モデルや 関数内のその他のデータを活用できます。 次のコマンドを使用して、既存の共有を Linux 関数アプリにマウントできます。
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 共有のマウントに関する記事のスクリプトを参照してください。
現時点では、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 ホスティングのオプションについて確認してください。