Azure Functions の Azure Blob Storage トリガー
Blob ストレージ トリガーは、新しいまたは更新された BLOB が検出されたときに関数を開始します。 BLOB の内容は、関数への入力として提供されます。
ヒント
ストレージ コンテナー内の BLOB に対する変更に基づいて関数コードを実行するには、いくつかの方法があります。 BLOB ストレージ トリガーを使用する場合は、ポーリング ベースのトリガー (この記事で参照) とイベント ベースの 2 つの実装が提供されることに注意してください。 event ベースの実装を使用することをお勧めします他の実装よりも待機時間が短くなります。 また、Flex 従量課金プランでは、イベントベースの Blob Storage トリガーのみがサポートされます。
BLOB ストレージ トリガーの 2 つの実装の違いと、その他のトリガー オプションの詳細については、「 BLOB を使用した作業を参照してください。
セットアップと構成の詳細については、概要に関するページをご覧ください。
重要
この記事では、タブを使用して、Node.js プログラミング モデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。
Azure Functions では、Python の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。
Python v2 プログラミング モデルでは、Python 関数コードでデコレーターを使用してバインドを直接定義できます。 詳細については、「Python 開発者ガイド」を参照してください。
この記事は、両方のプログラミング モデルをサポートしています。
例
A C# 関数は、次の C# モードのいずれかを使用して作成できます。
- 分離されたワーカー モデル: ランタイムから分離されたワーカー プロセスで実行されるコンパイル済みの C# 関数。 分離ワーカー プロセスは、LTS および 非 LTS バージョンの .NET および .NET Framework で実行されている C# 関数をサポートするために必要です。 分離ワーカー プロセス関数の拡張機能では、
Microsoft.Azure.Functions.Worker.Extensions.*
名前空間が使用されます。 - インプロセス モデル: Functions ランタイムと同じプロセスで実行されるコンパイル済みの C# 関数。 このモデルの一部では、主に C# ポータルの編集のためにサポートされている C# スクリプトを使用して Functions を実行できます。 インプロセス関数の拡張機能では、
Microsoft.Azure.WebJobs.Extensions.*
名前空間が使用されます。
重要
インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 完全なサポートのために、分離ワーカー モデルにアプリを移行することを強くお勧めします。
次の例は C# 関数であり、分離ワーカー プロセスで実行され、BLOB 入力と BLOB 出力の両方の BLOB バインドを持つ BLOB トリガーを使用します。 この関数は、test-sample-trigger コンテナーの BLOB の作成によってトリガーされます。 test-samples-input コンテナーからテキスト ファイルを読み取り、トリガーされたファイルの名前に基づいて、出力コンテナーに新しいテキスト ファイルを作成します。
public static class BlobFunction
{
[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
[BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
[BlobInput("test-samples-input/sample1.txt")] string myBlob,
FunctionContext context)
{
var logger = context.GetLogger("BlobFunction");
logger.LogInformation("Triggered Item = {myTriggerItem}", myTriggerItem);
logger.LogInformation("Input Item = {myBlob}", myBlob);
// Blob Output
return "blob-output content";
}
}
この関数は、myblob
コンテナーで BLOB が追加または更新されたときにログを書き込みます。
@FunctionName("blobprocessor")
public void run(
@BlobTrigger(name = "file",
dataType = "binary",
path = "myblob/{name}",
connection = "MyStorageAccountAppSetting") byte[] content,
@BindingName("name") String filename,
final ExecutionContext context
) {
context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}
次の例は、BLOB トリガーの TypeScript コードを示しています。 関数は、samples-workitems
コンテナーで BLOB が追加または更新されたときにログを書き込みます。
BLOB トリガー パス samples-workitems/{name}
の文字列 {name}
は、トリガーする BLOB のファイル名にアクセスするために関数コードで使用できる、{name}
を作成します。 詳しくは、後述の「BLOB 名のパターン」をご覧ください。
import { app, InvocationContext } from '@azure/functions';
export async function storageBlobTrigger1(blob: Buffer, context: InvocationContext): Promise<void> {
context.log(
`Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
);
}
app.storageBlob('storageBlobTrigger1', {
path: 'samples-workitems/{name}',
connection: 'MyStorageAccountAppSetting',
handler: storageBlobTrigger1,
});
次の例は、BLOB トリガーの JavaScript コードを示しています。 関数は、samples-workitems
コンテナーで BLOB が追加または更新されたときにログを書き込みます。
BLOB トリガー パス samples-workitems/{name}
の文字列 {name}
は、トリガーする BLOB のファイル名にアクセスするために関数コードで使用できる、{name}
を作成します。 詳しくは、後述の「BLOB 名のパターン」をご覧ください。
const { app } = require('@azure/functions');
app.storageBlob('storageBlobTrigger1', {
path: 'samples-workitems/{name}',
connection: 'MyStorageAccountAppSetting',
handler: (blob, context) => {
context.log(
`Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
);
},
});
次の例は、source
BLOB ストレージ コンテナーにファイルが追加されたときに実行される関数を作成する方法を示しています。
関数構成ファイル (function.json) には、type
が blobTrigger
で、direction
が in
に設定されたバインドが含まれています。
{
"bindings": [
{
"name": "InputBlob",
"type": "blobTrigger",
"direction": "in",
"path": "source/{name}",
"connection": "MyStorageAccountConnectionString"
}
]
}
run.ps1 ファイルに関連するコードを次に示します。
param([byte[]] $InputBlob, $TriggerMetadata)
Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"
この例では、SDK の種類を使用して、Blob Storage トリガーによって提供される基になる BlobClient
オブジェクトに直接アクセスします。
import logging
import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob
app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.blob_trigger(
arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_trigger(client: blob.BlobClient):
logging.info(
f"Python blob trigger function processed blob \n"
f"Properties: {client.get_blob_properties()}\n"
f"Blob content head: {client.download_blob().read(size=1)}"
)
他の SDK の種類の使用例については、 ContainerClient
と StorageStreamDownloader
のサンプルを参照してください。
プロジェクトで SDK 型バインドを有効にする方法など、詳細については、「 SDK 型バインドを参照してください。
この例では、受信 BLOB メタデータからの情報をログに記録します。
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob",
path="PATH/TO/BLOB",
connection="CONNECTION_SETTING")
def test_function(myblob: func.InputStream):
logging.info(f"Python blob trigger function processed blob \n"
f"Name: {myblob.name}\n"
f"Blob Size: {myblob.length} bytes")
属性
インプロセスと分離されたワーカー プロセスの C# ライブラリはどちらも、BlobAttribute 属性を使って関数を定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。
この属性のコンストラクターは、次のパラメーターを受け取ります。
パラメーター | 説明 |
---|---|
BlobPath | BLOB へのパス。 |
接続 | Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
Access (アクセス) | 読み取りと書き込みのどちらを行うかを示します。 |
ソース | トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには BlobTriggerSource.EventGrid を使用します。これにより、待機時間が大幅に短縮されます。 既定値は BlobTriggerSource.LogsAndContainerScan です。これは、標準のポーリング メカニズムを使用してコンテナー内の変更を検出します。 |
メソッド シグネチャでの BlobTrigger
属性を次に示します。
[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
[BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
[BlobInput("test-samples-input/sample1.txt")] string myBlob,
FunctionContext context)
ローカルで開発する場合は、Values
コレクション内の local.settings.json ファイルにアプリケーション設定を追加します。
デコレーター
Python v2 プログラミング モデルにのみ適用されます。
デコレーターを使用して定義された Python v2 関数の場合、blob_trigger
デコレーターの次のプロパティによって Blob Storage トリガーが定義されます。
プロパティ | 説明 |
---|---|
arg_name |
関数シグネチャのパラメーター名を宣言します。 関数がトリガーされると、このパラメーターの値にはキュー メッセージの内容が含められます。 |
path |
監視するコンテナー。 BLOB 名パターンの場合があります。 |
connection |
ストレージ アカウントの接続文字列。 |
source |
トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには EventGrid を使用します。これにより、待機時間が大幅に短縮されます。 既定値は LogsAndContainerScan です。これは、標準のポーリング メカニズムを使用してコンテナー内の変更を検出します。 |
function.json を使用して定義された Python 関数については、[構成] セクションを参照してください。
注釈
@BlobTrigger
属性を使用すると、関数をトリガーした BLOB にアクセスできます。 詳細については、「トリガー - 例」を参照してください。 トリガー イベントのソースを設定するには、source
プロパティを使用します。 Event Grid ベースの BLOB トリガーには EventGrid
を使用します。これにより、待機時間が大幅に短縮されます。 既定値は LogsAndContainerScan
です。これは、標準のポーリング メカニズムを使用してコンテナー内の変更を検出します。 |
構成
"Python v1 プログラミング モデルにのみ適用されます。"
次の表では、app.storageBlob()
メソッドに渡される options
オブジェクトに対して設定できるプロパティについて説明します。
プロパティ | 説明 |
---|---|
path | 監視するコンテナー。 BLOB 名パターンの場合があります。 |
connection | Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
ソース | トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには EventGrid を使用します。これにより、待機時間が大幅に短縮されます。 既定値は LogsAndContainerScan です。これは、標準のポーリング メカニズムを使用してコンテナー内の変更を検出します。 |
次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。
function.json のプロパティ | 説明 |
---|---|
type | blobTrigger に設定する必要があります。 このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。 |
direction | in に設定する必要があります。 このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。 例外は、使用方法のセクションに記載しています。 |
name | 関数コード内の BLOB を表す変数の名前。 |
path | 監視するコンテナー。 BLOB 名パターンの場合があります。 |
connection | Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
ソース | トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには EventGrid を使用します。これにより、待機時間が大幅に短縮されます。 既定値は LogsAndContainerScan です。これは、標準のポーリング メカニズムを使用してコンテナー内の変更を検出します。 |
完全な例については、セクションの例を参照してください。
Metadata
BLOB トリガーは、いくつかのメタデータ プロパティを提供します。 これらのプロパティは、他のバインドのバインド式の一部として、またはコードのパラメーターとして使用できます。 これらの値は、CloudBlob 型と同じセマンティクスを持ちます。
プロパティ | タイプ | 説明 |
---|---|---|
BlobTrigger |
string |
トリガーする BLOB のパス。 |
Uri |
System.Uri |
プライマリ ロケーションの BLOB URI。 |
Properties |
BlobProperties | Blob のシステム プロパティ。 |
Metadata |
IDictionary<string,string> |
BLOB のユーザー定義メタデータ。 |
次の例では、コンテナーを含むトリガーとなる BLOB へのパスをログに記録しています。
public static void Run(string myBlob, string blobTrigger, ILogger log)
{
log.LogInformation($"Full blob path: {blobTrigger}");
}
Metadata
BLOB トリガーは、いくつかのメタデータ プロパティを提供します。 これらのプロパティは、他のバインドのバインド式の一部として、またはコードのパラメーターとして使用できます。
プロパティ | 説明 |
---|---|
blobTrigger |
トリガーする BLOB のパス。 |
uri |
プライマリ ロケーションの BLOB URI。 |
properties |
Blob のシステム プロパティ。 |
metadata |
BLOB のユーザー定義メタデータ。 |
Metadata
メタデータは、$TriggerMetadata
パラメーターを介して使用できます。
使用
BLOB トリガーでサポートされるバインドの種類は、拡張機能パッケージのバージョンと、関数アプリで使用される C# モダリティによって異なります。
BLOB トリガーは、次の型にバインドできます。
Type | 説明 |
---|---|
string |
BLOB コンテンツを表す文字列。 BLOB コンテンツが単純なテキストのときに使用します。 |
byte[] |
BLOB コンテンツのバイト数。 |
JSON シリアル化可能な型 | BLOB に JSON データが含まれているとき、Functions は JSON データを単純な従来の CLR オブジェクト (POCO) 型に逆シリアル化しようとします。 |
Stream1 | BLOB コンテンツの入力ストリーム。 |
BlobClient1、 BlockBlobClient1、 PageBlobClient1、 AppendBlobClient1、 BlobBaseClient1 |
BLOB に接続されているクライアント。 この型のセットには BLOB の処理に対する最大限の制御機能が備わっています。接続に十分なアクセス許可がある場合は、BLOB への書き戻しに使用できます。 |
1 これらの型を使用するには、Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 以降と SDK 型バインドの一般的な依存関係に関する記事を参照する必要があります。
string
または Byte[]
へのバインドが推奨されるのは、BLOB のサイズが小さい場合のみです。 これが推奨されるのは、BLOB 全体の内容がメモリに読み込まれるためです。 ほとんどの BLOB では、Stream
型または BlobClient
型を使用します。 詳細については、「コンカレンシーとメモリ使用量」を参照してください。
Storage SDK タイプの 1 つにバインドしようとしてエラー メッセージが表示された場合は、適切な Storage SDK バージョンへの参照があることを確認してください。
StorageAccountAttribute を使用して、使用するストレージ アカウントを指定することもできます。 これは、ライブラリ内の他の関数とは異なるストレージ アカウントを使用する必要がある場合に実行できます。 コンストラクターは、ストレージ接続文字列を含むアプリ設定の名前を受け取ります。 属性は、パラメーター、メソッド、またはクラス レベルで適用できます。 次の例では、クラス レベルとメソッド レベルを示します。
[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
[FunctionName("BlobTrigger")]
[StorageAccount("FunctionLevelStorageAppSetting")]
public static void Run( //...
{
....
}
使用するストレージ アカウントは、次の順序で決定されます。
BlobTrigger
属性のConnection
プロパティ。BlobTrigger
属性と同じパラメーターに適用されたStorageAccount
属性。- 関数に適用される
StorageAccount
属性。 - クラスに適用される
StorageAccount
属性。 AzureWebJobsStorage
アプリケーション設定で定義されている、関数アプリの既定のストレージ アカウント。
@BlobTrigger
属性を使用すると、関数をトリガーした BLOB にアクセスできます。 詳細については、「トリガー - 例」を参照してください。
function.json ファイルのバインドの name パラメーターで指定されている名前と一致するパラメーターを使用して、BLOB データにアクセスします。
InputStream に型指定したパラメーターを使用して BLOB データにアクセスします。 詳細については、「トリガー - 例」を参照してください。
Functions では、Azure Blob Storage の Python SDK 型バインドもサポートされています。これにより、基になる SDK の種類を使用して BLOB データを操作できます。
重要
Python の SDK の種類のサポートは現在プレビュー段階であり、Python v2 プログラミング モデルでのみサポートされています。 詳細については、Python の SDK 型を参照してください。
つながり
connection
プロパティは、アプリを Azure BLOB に接続する方法を指定する環境構成への参照です。 次が指定される場合があります。
構成された値が、1 つの設定に完全一致し、プレフィックスがその他の設定とも一致する場合は、完全一致が使用されます。
接続文字列
接続文字列を取得するには、「ストレージ アカウント アクセス キーを管理する」の手順に従います。 接続文字列は、BLOB ストレージ アカウントではなく汎用ストレージ アカウントに対するものである必要があります。
この接続文字列は、バインディング構成の connection
プロパティで指定した値と同じ名前のアプリケーション設定に格納する必要があります。
アプリ設定の名前が "AzureWebJobs" で始まる場合は、ここで名前の残りの部分のみを指定できます。 たとえば、connection
を "MyStorage" に設定した場合、Functions ランタイムは "AzureWebJobsMyStorage" という名前のアプリ設定を探します。 connection
を空のままにした場合、Functions ランタイムは、アプリ設定内の AzureWebJobsStorage
という名前の既定のストレージ接続文字列を使用します。
ID ベースの接続
バージョン 5.x 以上の拡張機能を使用している場合 (non-.NET 言語スタックの場合は bundle 3.x 以上)、シークレットで接続文字列を使用する代わりに、アプリで Microsoft Entra ID を使用できます。 ID を使用するには、トリガーとバインドの構成の connection
プロパティにマップされる共通のプレフィックスに設定を定義します。
connection
を "AzureWebJobsStorage" に設定する場合は、「ID を使用してホスト ストレージに接続する」を参照してください。 その他のすべての接続では、拡張機能に次のプロパティが必要です。
プロパティ | 環境変数テンプレート | 説明 | 値の例 |
---|---|---|---|
Blob Service の URI | <CONNECTION_NAME_PREFIX>__serviceUri 1 |
HTTPS スキームを使用して接続している BLOB サービスのデータ プレーン URI。 | https://<storage_account_name>.blob.core.windows.net |
1 <CONNECTION_NAME_PREFIX>__blobServiceUri
はエイリアスとして使用できます。 接続構成が BLOB トリガーによって使用される場合、blobServiceUri
には queueServiceUri
も指定する必要があります。 以下を参照してください。
全体の接続構成が BLOB、キュー、テーブル間で使用される場合、serviceUri
形式は指定できません。 URI では BLOB サービスのみを指定できます。 別の方法として、サービスごとに専用の URI を指定して、1 つの接続を使用できるようにすることができます。 両方のバージョンが指定された場合、マルチサービス形式が使用されます。 複数のサービス用の接続を構成するには、<CONNECTION_NAME_PREFIX>__serviceUri
の代わりに次を設定します。
プロパティ | 環境変数テンプレート | 説明 | 値の例 |
---|---|---|---|
Blob Service の URI | <CONNECTION_NAME_PREFIX>__blobServiceUri |
HTTPS スキームを使用して接続している BLOB サービスのデータ プレーン URI。 | https://<storage_account_name>.blob.core.windows.net |
Queue Service URI (BLOB トリガーに必要2) | <CONNECTION_NAME_PREFIX>__queueServiceUri |
HTTPS スキームを使用したキュー サービスのデータ プレーン URI。 この値は、BLOB トリガーにのみ必要です。 | https://<storage_account_name>.queue.core.windows.net |
2 BLOB トリガーは、複数回にわたる再試行の失敗を、有害な BLOB をキューに書き込むことで処理します。 serviceUri
形式では、AzureWebJobsStorage
接続が使用されます。 ただし、blobServiceUri
を指定する場合は、queueServiceUri
でキュー サービス URI も指定する必要があります。 BLOB サービスと同じストレージ アカウントからサービスを使用することをお勧めします。 また、トリガーでは、ストレージ キュー データ共同作成者のようなロールを割り当てて、構成されたキュー サービスのメッセージを読み書きできるようにする必要があります。
接続をカスタマイズするには、他のプロパティを設定します。 「ID ベース接続に共通のプロパティ」を参照してください。
Azure Functions サービスでホストされている場合、ID ベースの接続では、マネージド ID が使用されます。 ユーザー割り当て ID を credential
および clientID
プロパティで指定できますが、システム割り当て ID が既定で使用されます。 リソース ID を使用したユーザー割り当て ID の構成はサポートされていないことに注意してください。 ローカル開発などの他のコンテキストで実行する場合は、代わりに開発者 ID が使用されますが、カスタマイズすることもできます。 ID ベースの接続によるローカル開発に関するページをご覧ください。
ID にアクセス許可を付与する
使用されている ID が何であれ、目的のアクションを実行するためのアクセス許可が必要です。 ほとんどの Azure では、これはそれらのアクセス許可を提供する組み込みロールまたはカスタム ロールを使って、Azure RBAC でロールを割り当てる必要があることを意味します。
重要
すべてのコンテキストに必要ではない一部のアクセス許可がターゲット サービスによって公開される場合があります。 可能であれば、最小限の特権の原則に従い、必要な特権だけを ID に付与します。 たとえば、アプリがデータ ソースからの読み取りのみを行う必要がある場合は、読み取りアクセス許可のみを持つロールを使用します。 サービスへの書き込みも可能なロールを割り当てることは、読み取り操作に対するアクセス許可が過剰になるため、不適切です。 同様に、ロールの割り当てが、読み取る必要のあるリソースだけに限定されていることを確認する必要があります。
実行時に BLOB コンテナーへのアクセスを提供するロールの割り当てを作成する必要があります。 所有者のような管理ロールでは十分ではありません。 次の表は、通常の操作で Blob Storage の拡張機能を使用するときに推奨される組み込みロールを示しています。 アプリケーションでは、記述したコードに基づいて追加のアクセス許可が必要になる場合があります。
[バインドの種類] | 組み込みロールの例 |
---|---|
トリガー | ストレージ BLOB データ所有者 および ストレージ キュー データ共同作成者1 AzureWebJobsStorage 接続にも追加のアクセス許可を付与する必要があります。2 |
入力バインド | ストレージ BLOB データ閲覧者 |
出力バインド | ストレージ BLOB データ所有者 |
1 BLOB トリガーは、複数回にわたる再試行の失敗を、接続によって指定されたストレージ アカウント上のキューに有害な BLOB を書き込むことにより処理します。
2 AzureWebJobsStorage 接続は、トリガーを有効にする BLOB やキューのために内部的に使用されます。 ID ベースの接続を使用するように構成されている場合は、既定の要件を超える追加のアクセス許可が必要になります。 必要なアクセス許可は、ストレージ BLOB データ所有者、ストレージ キュー データ共同作成者、およびストレージ アカウント共同作成者の各ロールによって満たされます。 詳細については、「ID を使用してホスト ストレージに接続する」を参照してください。
BLOB 名のパターン
in function.json の path
プロパティまたは BlobTrigger
属性コンストラクターで BLOB 名のパターンを指定することができます。 名前のパターンは、フィルターまたはバインド式にすることができます。 以下のセクションで、例を示します。
ヒント
名前パターンでは、コンテナー名に競合回避モジュールを含めることはできません。
ファイル名と拡張子の取得
次の例は、BLOB ファイル名と拡張子を別々にバインドする方法を示します。
"path": "input/{blobname}.{blobextension}",
BLOB の名前が original-Blob1.txt の場合、関数コード内の blobname
変数と blobextension
変数の値は original-Blob1 と txt です。
BLOB 名のフィルター
次の例は、文字列 "original-" で始まる input
コンテナーの BLOB でのみトリガーします。
"path": "input/original-{name}",
BLOB 名が original-Blob1.txt の場合、関数コード内の name
変数の値は Blob1.txt
です。
ファイルの種類のフィルター
次の例は、 .png ファイルでのみトリガーします。
"path": "samples/{name}.png",
ファイル名の中かっこのフィルター
ファイル名の中かっこを検索するには、2 つの中かっこを使用して中かっこをエスケープします。 次の例は、名前に中かっこを含む BLOB をフィルター処理します。
"path": "images/{{20140101}}-{name}",
BLOB の名前が {20140101}-soundfile.mp3 の場合、関数コード内の name
変数の値は soundfile.mp3 です。
ポーリングと待ち時間
ポーリングは、ログの検査と定期的なコンテナー スキャンの実行のハイブリッドとして機能します。 BLOB は、間隔の間で使用される継続トークンを使用して、一度に 10,000 のグループ単位でスキャンされます。 関数アプリを従量課金プランで使用しているときに、関数アプリがアイドル状態になっている場合、新しい BLOB の処理が最大で 10 分間遅延する可能性があります。
警告
ストレージ ログは "ベスト エフォート" ベースで作成されます。 すべてのイベントがキャプチャされる保証はありません。 ある条件下では、ログが欠落する可能性があります。
より高速で信頼性の高い BLOB 処理が必要な場合は、Always On が有効になっている App Service プランを使用するようにホスティングを切り替えることを検討してください。その結果、コストが増加する可能性があります。 クラシック ポーリング BLOB トリガー以外のトリガーの使用も検討できます。 BLOB ストレージ コンテナーのさまざまなトリガー オプションの詳細と比較については、「 BLOB コンテナーでのトリガーを参照してください。
BLOB の配信確認メッセージ
Azure Functions ランタイムでは、BLOB トリガー関数は、同一の新規または更新された BLOB について 2 回以上呼び出されることはありません。 特定の BLOB バージョンが処理されているかどうかを判断するために、BLOB の配信確認メッセージが維持されます。
Azure Functions では、BLOB の配信確認メッセージは (アプリ設定 AzureWebJobsStorage
で指定した) 関数アプリの Azure ストレージ アカウント内の azure-webjobs-hosts というコンテナーに格納されます。 BLOB の配信確認メッセージには次の情報が含まれています。
- トリガーされた関数 (
<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>
。例:MyFunctionApp.Functions.CopyBlob
) - コンテナーの名前
- BLOB の種類 (
BlockBlob
またはPageBlob
)。 - BLOB の名前
- ETag (BLOB のバージョン識別子。例:
0x8D1DC6E70A277EF
)
BLOB を強制的に再処理する場合は、azure-webjobs-hosts コンテナーからその BLOB の配信確認メッセージを手動で削除します。 再処理がすぐに行われない場合がありますが、後で必ず行われます。 すぐに再処理するには、azure-webjobs-hosts/blobscaninfo 内の scaninfo BLOB を更新できます。 LatestScan
プロパティの後に最後に変更されたタイムスタンプを持つすべての BLOB が再びスキャンされます。
有害な BLOB
指定された BLOB に対する BLOB トリガー関数が失敗すると、Azure Functions は既定で最大 5 回その関数を再試行します。
試行が 5 回とも失敗した場合、Azure Functions は webjobs-blobtrigger-poison という名前のストレージ キューにメッセージを追加します。 再試行回数の最大値の設定は変更可能です。 同じ MaxDequeueCount 設定は、有害な BLOB の処理と有害キュー メッセージの処理に使用されます。 有害な BLOB のキュー メッセージは次のプロパティを持つ JSON オブジェクトです。
- FunctionId (
<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>
の形式) - BlobType (
BlockBlob
またはPageBlob
) - ContainerName
- BlobName
- ETag (BLOB のバージョン識別子。例:
0x8D1DC6E70A277EF
)
メモリ使用量とコンカレンシー
string
やByte[]
などのストリーミングをサポートしない出力型にバインドする場合ランタイムは、処理中に BLOB 全体を複数回メモリに読み込む必要があります。 これにより、BLOB の処理時に予想以上のメモリ使用量が発生する可能性があります。 可能な場合は、ストリームサポート型を使用します。 型のサポートは、C# モードと拡張機能のバージョンによって異なります。 詳細については、「バインドの種類」を参照してください。
現時点では、ランタイムは処理中に BLOB 全体を複数回メモリに読み込む必要があります。 これにより、BLOB の処理時に予想以上のメモリ使用量が発生する可能性があります。
複数の関数インスタンスが BLOB データを同時に処理している場合、メモリ使用量がさらに影響を受ける可能性があります。 BLOB トリガーを使用してメモリの問題が発生する場合は、許可される同時実行の数を減らすことを検討してください。 もちろん、コンカレンシーを減らすと、処理されるのを待っている BLOB のバックログが増えるという副作用があります。 関数アプリのメモリ制限は、プランによって異なります。 詳細については、サービスの制限に関する記事を参照してください。
同時実行の数を制御する方法は、使用しているストレージ拡張機能のバージョンによって異なります。
Storage 拡張機能のバージョン 5.0.0 以降を使用する場合は、host.jsonの blobs 構成のmaxDegreeOfParallelism
設定を使用して、トリガーのコンカレンシーを制御します。
制限は、BLOB トリガーを使用する各関数に個別に適用されます。
host.json プロパティ
host.json ファイルには、BLOB トリガーの動作を制御する設定が含まれています。 使用可能な設定の詳細については、「host.json 設定」を参照してください。