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

Azure Functions では、Function App インスタンスを作成するときに Azure ストレージ アカウントが必要になります。 次のストレージ サービスは、お使いの Function App によって利用できます。

ストレージ サービス 機能の使用法
Azure Blob Storage バインドの状態と関数キーを管理します。
Durable Functions 上のタスク ハブからも使用されます。
Azure Files 従量課金プランPremium プランで、関数アプリ コードを格納して実行するために使用されるファイル共有。
Azure Files は既定で設定されていますが、特定の条件では、Azure Files を使わずにアプリを作成することもできます。
Azure Queue Storage Durable Functions のタスク ハブによって使用されます。また、エラーと再試行処理の場合、特定の Azure Functions トリガーによって使用されます。
Azure Table Storage Durable Functions 上のタスク ハブから使用されます。

重要

従量課金/Premium ホスティング プランを使用する場合、関数コード ファイルおよびバインディング構成ファイルは、メイン ストレージ アカウントの Azure Files に保存されます。 メイン ストレージ アカウントを削除すると、このコンテンツは削除され、復元できません。

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

Function App を作成するときは、BLOB、キュー、テーブル ストレージをサポートする汎用の Azure Storage アカウントを作成またはリンクする必要があります。 この要件があるのは、Functions がトリガーの管理や関数実行のログ管理などの操作に Azure Storage を使用しているためです。 一部のストレージ アカウントでは、キューとテーブルがサポートされません。 これらのアカウントには、BLOB 専用ストレージ アカウントと Azure Premium Storage が含まれています。

ストレージ アカウントの種類については、「ストレージ アカウントの概要」を参照してください。

お使いの Function App で既存のストレージ アカウントを使用することは可能ですが、必ずこれらの要件を満たしている必要があります。 Azure portal で、Function App の作成フローの一部として作成されたストレージ アカウントでは、これらのストレージ アカウント要件を満たしていることが保証されます。 ポータルでは、関数アプリの作成中に既存のストレージ アカウントを選択すると、サポートされていないアカウントが除外されます。 このフローでは、作成中の関数アプリと同じリージョンにある既存のストレージ アカウントのみを選択できます。 詳細については、「ストレージ アカウントの場所」を参照してください。

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

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

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

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

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

ストレージ アカウント接続は、AzureWebJobsStorage アプリケーション設定の中で管理されます。

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

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

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

ホスト ID の競合を回避ためには、個別のストア アカウントを使用する必要がある場合があります。

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

Functions は、Blob ストレージを使用して、関数アクセス キーなどの重要な情報を保持します。 Blob Storage アカウントにライフサイクル管理ポリシーを適用すると、ポリシーが Functions ホストが必要とする BLOB を削除する場合があります。 このため、Functions が使用するストレージ アカウントにこのようなポリシーを適用しないようにする必要があります。 このようなポリシーを適用する必要がある場合は、azure-webjobs または scm のプレフィックスが付いている Functions が使用するコンテナーを必ず除外してください。

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

パフォーマンスを最大化するには、関数アプリごとに個別のストレージ アカウントを使用します。 Durable Functions または Event Hub によってトリガーされる関数がある場合には、これは特に重要です。どちらも、大量のストレージ トランザクションを生成します。 アプリケーション ロジックが (Storage SDK を使用して) 直接、あるいは、ストレージ バインドの 1 つを経由して Azure Storage と対話する場合、専用のストレージ アカウントを使用する必要があります。 たとえば、Event Hub によってトリガーされ BLOB ストレージにデータを書き込む関数がある場合、2 つのストレージ アカウントを使用します。1 つは関数アプリ用、もう 1 つは関数によって格納されている 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 Storage トリガーは、ストレージ内の特定のホスト ID パスの下に領収書を書き込むことによって、個々の BLOB が処理されたかどうかを追跡します。 ホスト ID が変更されるか、新しいストレージ アカウントをポイントすると、以前に処理された BLOB が再処理される可能性があります。

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

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

スロット間で競合が発生した場合は、この設定をスロット設定としてマークしなければならない場合があります。 アプリ設定を作成する方法については、「 アプリケーション設定の操作」を参照してください。

Azure Arc 対応クラスター

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

必要なし ストレージが必要な場合があります
Azure Cosmos DB
HTTP
Kafka
RabbitMQ
Service Bus
Azure SQL
BLOB ストレージ
Event Grid
Event Hubs
IoT Hub
キュー ストレージ
SendGrid
SignalR
テーブル ストレージ
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 以外の Consumption プランでは、高スケールの共有ファイル システムとして、Azure Files が既定で設定されています。 このファイル システムは、それらのプラットフォームでログ ストリーミングなどの機能を実現するためにも使用しますが、主な用途は、デプロイした機能のペイロードを安定的に送信することです。 外部パッケージの URL を使用してアプリをデプロイするときは、そのアプリのコンテンツを読み取り専用の別のファイル システムから提供します。 つまり、Azure Files を使用せずに関数アプリを作成できます。 Azure Files を使用して関数アプリを作成した場合でも、書き込み可能なファイル システムが提供されます。 ただし、このファイル システムはすべての関数アプリ インスタンスで使用できるわけではありません。

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

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

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

Functions では動的スケールアウトのプロセスの一部に Azure Files を使用するため、Consumption プランと Premium プランで 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 Function App の作成と Azure Files 共有のマウントに関する記事にあるスクリプトを参照してください。

現時点では、AzureFilesstorage-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 ホスティングのオプションについて確認してください。