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 Table Storage Durable Functions 上のタスク ハブから使用されます。

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 のゾーン冗長性に関するページを参照してください。

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

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

Azure Files を使用しない場合は、次のことへの対応が必要です。

  • 外部パッケージの URL からデプロイする必要があります。
  • 書き込み可能な共有ファイル システムの使用を前提にした運用はできません。
  • アプリで Functions ランタイム v1 を使用できません。
  • 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 ホスティングのオプションについて確認してください。