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

Azure で関数アプリ インスタンスを作成する場合は、既定の Azure Storage アカウントへのアクセスを提供する必要があります。 次の図とその後の表では、Azure Functions が既定のストレージ アカウントでサービスを使用する方法について詳しく説明します。

1. Blob Storage は関数キーの既定のストアですが、代替ストアを構成できます。
2. Azure Files は既定で設定されていますが、特定の条件では、Azure Files を使わずにアプリを作成することもできます。

重要な考慮事項

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

• 関数アプリが従量課金プランまたは Premium プランでホストされている場合、関数コードと構成ファイルは、リンクされたストレージ アカウントの Azure Files に保存されます。 メイン ストレージ アカウントを削除すると、このコンテンツは削除され、回復できなくなります。 詳細については、「 ストレージ アカウントが削除されました」を参照してください。

• 関数コード、アクセス キー、その他の重要なサービス関連データなどの重要なデータは、ストレージ アカウントに保持できます。 関数アプリで使用されるストレージ アカウントへのアクセスは、次の方法で慎重に管理する必要があります。

  • 最小特権モデルに基づいて、ストレージ アカウントへのアプリとユーザーのアクセスを監査および制限します。 ストレージ アカウントへのアクセス許可は、割り当てられたロールのデータ アクションから、または listKeys 操作を実行するためのアクセス許可を通じて取得できます。

  • ストレージ アカウント内のコントロール プレーン アクティビティ (キーの取得など) とデータ プレーン操作 (BLOB への書き込みなど) の両方を監視します。 Azure Storage 以外の場所にストレージ ログを保持することを検討してください。 詳細については、「ストレージ ログ」を参照してください。

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

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

• アカウントの種類は、BLOB、Queue、Table Storage をサポートしている必要があります。 一部のストレージ アカウントでは、キューとテーブルがサポートされません。 これらのアカウントには、BLOB 専用ストレージ アカウントと Azure Premium Storage が含まれています。 ストレージ アカウントの種類については、「ストレージ アカウントの概要」を参照してください。

• 従量課金プランで関数アプリがホストされていると、ネットワークで保護されたストレージ アカウントを使用することはできません。

• Azure portal で関数アプリを作成する場合、作成する関数アプリと同じリージョンにある既存のストレージ アカウントのみを選択できます。 この要件はパフォーマンスの最適化であり、厳密な制限ではありません。 詳細については、「ストレージ アカウントの場所」を参照してください。

• 可用性ゾーンのサポートが有効になっているプランで関数アプリを作成する場合は、ゾーン冗長ストレージ アカウントのみがサポートされます。

デプロイの自動化を使用して、ネットワークで保護されたストレージ アカウントを使用して関数アプリを作成する場合は、ARM テンプレートまたは Bicep ファイルに特定のネットワーク構成を含める必要があります。 これらの設定とリソースを含めないと、その自動デプロイは検証において失敗する場合があります。 ARM テンプレートと Bicep ガイダンスについては、「安全なデプロイメント」を参照してください。 ネットワークを使用してストレージ アカウントを構成する方法の概要については、「セキュリティで保護されたストレージ アカウントを Azure Functions で使用する方法」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

関数アプリで使用される Blob Storage アカウントにライフサイクル管理ポリシーを適用すべきではありません。 関数は、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 Hubs によってトリガーされる関数があり、どちらも大量のストレージ トランザクションを生成する場合に特に重要です。 アプリケーション ロジックが (Storage SDK を使用して) 直接、あるいは、ストレージ バインドの 1 つを経由して Azure Storage と対話する場合、専用のストレージ アカウントを使用する必要があります。 たとえば、イベント ハブによってトリガーされる関数が BLOB ストレージにデータを書き込む場合は、関数アプリ用と関数が格納する BLOB 用の 2 つのストレージ アカウントを使用します。

仮想ネットワーク経由の一貫性のあるルーティング

同じプランでホストされている複数の関数アプリは、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGによって定義された Azure Files コンテンツ共有に同じストレージ アカウントを使用することもできます。 このストレージ アカウントが仮想ネットワークによっても保護されている場合、トラフィックが意図した仮想ネットワーク経由で一貫してルーティングされるように、これらのアプリはすべて vnetContentShareEnabled (以前の WEBSITE_CONTENTOVERVNET) にも同じ値を使用する必要があります。 同じ Azure Files ストレージ アカウントを使用するアプリ間でこの設定が一致しない場合、トラフィックがパブリック ネットワーク経由でルーティングされる可能性があります。 この構成では、ストレージ アカウントのネットワーク 規則によってアクセスがブロックされます。

BLOB の操作

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

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

次の図に示すように、ストレージ コンテナー内の BLOB への変更に基づいて関数コードを実行する方法はいくつかあります。

次の表を使用して、コンテナー内の追加または更新された BLOB を処理するためのニーズに最も適した関数トリガーを判断します。

1. BLOB ストレージの入力および出力バインドは、BLOB 専用アカウントをサポートしています。
2. 高スケールとは、おおまかに言って、100,000 以上の BLOB を含むコンテナー、または 1 秒あたり 100 を超える BLOB の更新が発生するストレージ アカウントと定義できます。
3. イベント サブスクリプションで既知のユーザー ID を使用してパブリック IP 空間内の暗号化されたチャネル経由でイベントを配信することで、受信アクセス制限を回避できます。 詳細については、「 マネージド ID を使用してイベントを安全に配信する」を参照してください。

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

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 の競合が発生します。

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

ホスト ID の競合回避

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

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

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

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

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

Azure Arc 対応クラスター

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

ストレージのない 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 共有は既定でストレージ アカウントに作成されます。 関数はその共有を使用して、ログ ストリーミングなどの特定の機能を有効にします。 また、共有パッケージのデプロイ場所としても使用されます。これにより、すべてのインスタンスでデプロイされた関数コードの一貫性が保証されます。

既定では、Premium プランと従量課金プランでホストされている関数アプリは、この Azure ファイル共有に格納された展開パッケージと共に、zip デプロイを使用します。 このセクションは、これらのホスティング プランにのみ関連します。

Azure Files を使用するには、接続文字列を使用する必要があります。接続文字列は、WEBSITE_CONTENTAZUREFILECONNECTIONSTRING としてアプリ設定に格納されます。 Azure Files では現在、ID ベースの接続はサポートされていません。 シナリオでアプリ設定にシークレットを格納しないようにする必要がある場合は、Azure Files でアプリの依存関係を削除する必要があります。 既定の Azure Files 依存関係なしでアプリを作成することで、依存関係を回避できます。

Azure ファイル共有なしでアプリを実行するには、次の要件を満たす必要があります。

• リモートの Azure Blob Storage コンテナーにパッケージをデプロイし、そのパッケージへのアクセスを提供する URL を WEBSITE_RUN_FROM_PACKAGE アプリ設定として設定する必要があります。 この方法では、 マネージド ID をサポートする Azure Files ではなく Blob Storage にアプリコンテンツを格納できます。

展開パッケージを手動で更新し、展開パッケージの URL を維持する必要があります。この URL には、共有アクセス署名 (SAS) が含まれている可能性があります。

また、次の考慮事項にも注意してください。

• アプリは Functions ランタイムのバージョン 1.x を使用できません。
• 書き込み可能な共有ファイル システムの使用を前提にした運用はできません。
• ポータルの編集はサポートされていません。
• Azure portal などのクライアントのログ ストリーミングで、既定のログがファイル システムのログになります。 これの代わりに、Application Insights のログを使用するべきです。

上記の要件がシナリオに合う場合は、Azure Files を使用せずに関数アプリの作成に進むことができます。 次のいずれかの方法で、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING と WEBSITE_CONTENTSHARE アプリの設定なしでアプリを作成します。

• Bicep/ARM テンプレート: ARM テンプレートまたは Bicep ファイルから 2 つのアプリ設定を削除し、変更したテンプレートを使用してアプリをデプロイします。
• Azure portal: Azure portal でアプリを作成するときに、[ストレージ] タブで [Azure Files 接続の追加] の選択を解除します。

Azure Files は、Functions の動的スケールアウトを有効にするために使用されます。 Elastic Premium プランと従量課金プランで Azure Files を使用せずにアプリを実行すると、スケーリングが制限される可能性があります。

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

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

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

次のコマンドを使用して、既存の共有を Linux 関数アプリにマウントできます。

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

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

import os
...

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

関連記事

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