Queue storage トリガーは、メッセージが Azure Queue storage に追加されると関数を実行します。
従量課金プランと Premium プランに対する Azure Queue Storage のスケーリングの決定は、ターゲット ベースのスケーリングによって行われます。 詳しくは、「ターゲット ベースのスケーリング」をご覧ください。
重要
この記事では、タブを使用して、Node.js プログラミング モデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。
Azure Functions では、Python の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。
Python v2 プログラミング モデルでは、Python 関数コードでデコレーターを使用してバインドを直接定義できます。 詳細については、「Python 開発者ガイド」を参照してください。
この記事は、両方のプログラミング モデルをサポートしています。
例
このバインドに関しては現在、Goのサポートは利用できません。
キュー トリガーを使用して、キューで新しい項目を受け取ったときに関数を開始します。 キュー メッセージは、関数への入力として提供されます。
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 日に終了します。 完全なサポートのために、分離ワーカー モデルにアプリを移行することを強くお勧めします。
次の例は、キュー項目が処理されるたびに キューをポーリングし、いくつかのメッセージを出力キューに書き込む input-queueを示しています。
[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
// Use a string array to return more than one message.
string[] messages = {
$"Album name = {myQueueItem.Name}",
$"Album songs = {myQueueItem.Songs}"};
_logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);
// Queue Output messages
return messages;
}
次の Java の例は、キュー myqueuename に格納されるトリガーされたメッセージを記録するストレージ キュー トリガー関数を示しています。
@FunctionName("queueprocessor")
public void run(
@QueueTrigger(name = "msg",
queueName = "myqueuename",
connection = "myconnvarname") String message,
final ExecutionContext context
) {
context.getLogger().info(message);
}
次の例は、キュー トリガーの TypeScript 関数を示しています。 この関数は、キュー項目が処理されるたびに myqueue-items キューをポーリングし、ログを書き込みます。
import { app, InvocationContext } from '@azure/functions';
export async function storageQueueTrigger1(queueItem: unknown, context: InvocationContext): Promise<void> {
context.log('Storage queue function processed work item:', queueItem);
context.log('expirationTime =', context.triggerMetadata.expirationTime);
context.log('insertionTime =', context.triggerMetadata.insertionTime);
context.log('nextVisibleTime =', context.triggerMetadata.nextVisibleTime);
context.log('id =', context.triggerMetadata.id);
context.log('popReceipt =', context.triggerMetadata.popReceipt);
context.log('dequeueCount =', context.triggerMetadata.dequeueCount);
}
app.storageQueue('storageQueueTrigger1', {
queueName: 'myqueue-items',
connection: 'MyStorageConnectionAppSetting',
handler: storageQueueTrigger1,
});
Tip
キュー入力の既定の unknown 型を回避するには、ジェネリック型パラメーター (たとえば、 app.storageQueue<string>(...)) を使用します。 これには @azure/functions バージョン 4.11.0 以降が必要です。 詳細については、「使用」を参照してください。
ここに表示されているその他すべての変数については、「メッセージのメタデータ」セクションを参照してください。
次の例は、キュー トリガーの JavaScript 関数を示しています。 この関数は、キュー項目が処理されるたびに myqueue-items キューをポーリングし、ログを書き込みます。
const { app } = require('@azure/functions');
app.storageQueue('storageQueueTrigger1', {
queueName: 'myqueue-items',
connection: 'MyStorageConnectionAppSetting',
handler: (queueItem, context) => {
context.log('Storage queue function processed work item:', queueItem);
context.log('expirationTime =', context.triggerMetadata.expirationTime);
context.log('insertionTime =', context.triggerMetadata.insertionTime);
context.log('nextVisibleTime =', context.triggerMetadata.nextVisibleTime);
context.log('id =', context.triggerMetadata.id);
context.log('popReceipt =', context.triggerMetadata.popReceipt);
context.log('dequeueCount =', context.triggerMetadata.dequeueCount);
},
});
使用セクションでは queueItem について説明しています。 ここに表示されているその他すべての変数については、「メッセージのメタデータ」セクションを参照してください。
次の例では、トリガーを使用してキュー メッセージを読み取って関数に渡す方法を示します。
ストレージ キュー トリガーは function.json ファイルで定義され、そこで type は queueTrigger に設定されます。
{
"bindings": [
{
"name": "QueueItem",
"type": "queueTrigger",
"direction": "in",
"queueName": "messages",
"connection": "MyStorageConnectionAppSetting"
}
]
}
Run.ps1 ファイルのコードによってパラメーターが $QueueItem として宣言され、関数でキュー メッセージを読み取ることができるようになります。
# Input bindings are passed in via param block.
param([string] $QueueItem, $TriggerMetadata)
# Write out the queue message and metadata to the information log.
Write-Host "PowerShell queue trigger function processed work item: $QueueItem"
Write-Host "Queue item expiration time: $($TriggerMetadata.ExpirationTime)"
Write-Host "Queue item insertion time: $($TriggerMetadata.InsertionTime)"
Write-Host "Queue item next visible time: $($TriggerMetadata.NextVisibleTime)"
Write-Host "ID: $($TriggerMetadata.Id)"
Write-Host "Pop receipt: $($TriggerMetadata.PopReceipt)"
Write-Host "Dequeue count: $($TriggerMetadata.DequeueCount)"
次の例では、トリガーを使用してキュー メッセージを読み取って関数に渡す方法を示します。 この例は、v1 と v2 のどちらの Python プログラミング モデルを使用するかによって異なります。
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="QueueFunc")
@app.queue_trigger(arg_name="msg", queue_name="inputqueue",
connection="storageAccountConnectionString") # Queue trigger
@app.queue_output(arg_name="outputQueueItem", queue_name="outqueue",
connection="storageAccountConnectionString") # Queue output binding
def test_function(msg: func.QueueMessage,
outputQueueItem: func.Out[str]) -> None:
logging.info('Python queue trigger function processed a queue item: %s',
msg.get_body().decode('utf-8'))
outputQueueItem.set('hello')
属性
インプロセスと分離ワーカー プロセスの C# ライブラリはどちらも、QueueTriggerAttribute 属性を使用して関数を定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。
C# クラス ライブラリでは、次の例のように、属性のコンストラクターは監視するキューの名前を受け取ります。
[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
この例では、属性自体に接続文字列設定を設定する方法も示しています。
注釈
QueueTrigger 注釈を使用すると、関数をトリガーするキューにアクセスできます。 次の例では、message パラメーターを使用して、キュー メッセージを関数で使用できるようにします。
package com.function;
import com.microsoft.azure.functions.annotation.*;
import java.util.Queue;
import com.microsoft.azure.functions.*;
public class QueueTriggerDemo {
@FunctionName("QueueTriggerDemo")
public void run(
@QueueTrigger(name = "message", queueName = "messages", connection = "MyStorageConnectionAppSetting") String message,
final ExecutionContext context
) {
context.getLogger().info("Queue message: " + message);
}
}
| プロパティ | 説明 |
|---|---|
name |
関数シグネチャのパラメーター名を宣言します。 関数がトリガーされると、このパラメーターの値にはキュー メッセージの内容が含められます。 |
queueName |
ストレージ アカウントのキュー名を宣言します。 |
connection |
ストレージ アカウントの接続文字列を示します。 |
デコレーター
Python v2 プログラミング モデルにのみ適用されます。
デコレーターを使用して定義された Python v2 関数の場合、queue_trigger デコレーターの次のプロパティによって Queue Storage トリガーが定義されます。
| プロパティ | 説明 |
|---|---|
arg_name |
関数シグネチャのパラメーター名を宣言します。 関数がトリガーされると、このパラメーターの値にはキュー メッセージの内容が含められます。 |
queue_name |
ストレージ アカウントのキュー名を宣言します。 |
connection |
ストレージ アカウントの接続文字列を示します。 |
function.json を使用して定義された Python 関数については、「構成」セクションを参照してください。
構成
"Python v1 プログラミング モデルにのみ適用されます。"
次の表は、function.json ファイルと QueueTrigger 属性で設定したバインド構成のプロパティを説明しています。
| function.json のプロパティ | 説明 |
|---|---|
| type |
queueTrigger に設定する必要があります。 このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。 |
| direction |
function.json ファイルの場合のみ。
in に設定する必要があります。 このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。 |
| name | 関数コードでキュー項目ペイロードを含む変数の名前。 |
| queueName | ポーリングするキューの名前。 |
| connection | Azure キューへの接続方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。 |
完全な例については、セクションの例を参照してください。
ローカルで開発する場合は、 コレクション内の Valuesにアプリケーション設定を追加します。
使用法
Note
Azure Functions で想定されているのは base64 でエンコードされた文字列です。 (データを base64 でエンコードされた文字列として準備するために) エンコードの種類を調整する場合、それらはすべて呼び出し元のサービスに実装する必要があります。
Queue トリガーの使用方法は、拡張機能パッケージのバージョンと、関数アプリで使用される C# モダリティによって異なります。これは、次のいずれかのモードになります。
分離ワーカー プロセス クラス ライブラリは、ランタイムから分離されたプロセスで実行されるコンパイル済みの C# 関数です。
バージョンを選択すると、モードとバージョンの使用状況の詳細が表示されます。
キュー トリガーは、次の型にバインドできます。
| タイプ | 説明 |
|---|---|
string |
メッセージの内容を表す文字列。 メッセージが単純なテキストである場合に使用します。 |
byte[] |
メッセージのバイト数。 |
| JSON シリアル化可能な型 | キュー メッセージに JSON データが含まれている場合、Functions は JSON データを単純な従来の CLR オブジェクト (POCO) 型に逆シリアル化しようとします。 |
| QueueMessage1 | メッセージ。 |
| BinaryData1 | メッセージのバイト数。 |
1 これらの型を使用するには、Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues 5.2.0 以降と SDK 型バインドの一般的な依存関係に関する記事を参照する必要があります。
QueueTrigger 注釈を使用すると、関数をトリガーしたキュー メッセージにアクセスできます。
name ファイルのバインドの name パラメーターで指定された名前と一致する文字列パラメーターを使用して、キュー メッセージにアクセスします。
QueueMessage として型指定されたパラメーターを使用して、キュー メッセージにアクセスします。
メタデータ
キュー トリガーは、いくつかのメタデータ プロパティを提供します。 これらのプロパティは、メッセージ メタデータへのこのアクセスを提供する言語ワーカーに対して、他のバインディングのバインド式の一部として、またはコード内のパラメーターとして使用できます。
メッセージ メタデータ プロパティは、 CloudQueueMessage クラスのメンバーです。
メッセージ メタデータ プロパティには、 context.triggerMetadataからアクセスできます。
メッセージ メタデータ プロパティには、渡された $TriggerMetadata パラメーターからアクセスできます。
| プロパティ | タイプ | 説明 |
|---|---|---|
QueueTrigger |
string |
キュー ペイロード (有効な文字列の場合)。 キュー メッセージ ペイロードが文字列の場合、QueueTrigger は、QueueTrigger の プロパティで指定された変数と同じ値になります。 |
DequeueCount |
long |
このメッセージがデキューされた回数。 |
ExpirationTime |
DateTimeOffset |
メッセージが期限切れになる時刻。 |
Id |
string |
キュー メッセージ ID。 |
InsertionTime |
DateTimeOffset |
メッセージがキューに追加された時刻。 |
NextVisibleTime |
DateTimeOffset |
メッセージが次に表示される時刻。 |
PopReceipt |
string |
メッセージのポップ受信。 |
渡されたバインディング パラメーター (前のmsgの) から、次のメッセージ メタデータ プロパティにアクセスできます。
| プロパティ | 説明 |
|---|---|
body |
文字列としてのキュー ペイロード。 |
dequeue_count |
このメッセージがデキューされた回数。 |
expiration_time |
メッセージが期限切れになる時刻。 |
id |
キュー メッセージ ID。 |
insertion_time |
メッセージがキューに追加された時刻。 |
time_next_visible |
メッセージが次に表示される時刻。 |
pop_receipt |
メッセージのポップ受信。 |
接続
connectionプロパティはアプリケーション設定でキーに設定されており、Functionsランタイムが拡張で使用しているストレージアカウントに接続するために使われる値を返します。 接続プロパティ設定の値は接続の種類によって異なります:
-
マネージドID接続:
connectionプロパティは、複数の設定群が共有する<CONNECTION_NAME_PREFIX>であり、これらが共にストレージアカウントへのアイデンティティベースの接続を定義します。 詳細については、「 同一性接続の定義」を参照してください。 -
Key Vault参照:
connectionプロパティ設定は、接続文字列が中央管理されている場所への参照Azure Key Vaultを返します。 詳細については、「Key Vault connectionsの定義」をご覧ください。 -
App Configuration reference:
connectionプロパティ設定は接続文字列またはKey Vault参照を返すAzure App Configuration参照を返します。 詳細については、接続記事のAzure App Configurationをご覧ください。 -
Connection string:
connectionプロパティ設定は実際のストレージアカウント接続文字列を返します。 接続文字列には共有の秘密鍵が含まれているため、可能であれば管理型アイデンティティ接続の使用を検討すべきです。 詳細については、「 接続の定義」を参照してください。
バインディング接続について詳しく知りたい方は、Azure Functionsの「Manage connection in Connection」をご覧ください。 接続文字列を取得するには、「ストレージ アカウント アクセス キーを管理する」の手順に従います。
connectionをキーやAzureWebJobsStorageという名前のキープレフィックスに設定したり、空文字列に設定した場合、バインディング拡張はデフォルトのホストストレージアカウントを使用します。 詳細については 、「ストレージパフォーマンスの最適化」をご覧ください。
有害メッセージ
キュー トリガー関数が失敗すると、Azure Functions は、その関数を特定のキュー メッセージに対して (最初の試行を含め) 最大 5 回再試行します。 5 回の試行すべてで失敗した場合、Functions ランタイムは、<originalqueuename>-poison という名前のキューにメッセージを追加します。 メッセージのログを取得するか、手動での対処が必要であるという通知を送信することにより有害キューからのメッセージを処理する関数が記述できます。
有害メッセージを手動で処理するには、キュー メッセージの dequeueCount を確認します。
ピーク ロック
ピーク ロック パターンは、ストレージ サービスによって提供される可視性メカニズムを使用して、キュー トリガーに対して自動的に行われます。 メッセージはトリガーされた関数によってデキューされるため、非表示としてマークされます。 キューによってトリガーされる関数を実行すると、キュー内のメッセージに対して次のいずれかの結果を得ることができます。
- 関数の実行が正常に完了し、メッセージがキューから削除されます。
- 関数の実行が失敗し、Functions ホストは、host.json ファイル内の
visibilityTimeout設定に基づいてメッセージの可視性を更新。 既定の可視性タイムアウトは 0 です。これは、メッセージが再処理のためにキューにすぐに再び表示されることを意味します。visibilityTimeout設定を使用して、処理に失敗したメッセージの再処理を遅らせることができます。 このタイムアウト設定は、関数アプリ内のすべてのキューによってトリガーされる関数に適用されます。 - Functions ホストは、関数の実行中にクラッシュします。 この一般的でないイベントが発生した場合、ホストは処理中のメッセージに
visibilityTimeoutを適用できません。 代わりに、メッセージは、ストレージ サービスによって設定された既定の 10 分のタイムアウトのままにされます。 10 分後、メッセージは再処理のためにキューに再び表示されます。 このサービス定義の既定のタイムアウトは変更できません。
ポーリング アルゴリズム
キュー トリガーは、アイドル状態のキューのポーリングがストレージ トランザクション コストに与える影響を軽減するために、ランダムな指数バックオフ アルゴリズムを実装します。
アルゴリズムでは次のロジックが使用されます。
- メッセージが見つかると、ランタイムは 100 ミリ秒待機し、別のメッセージを確認します。
- メッセージが見つからない場合は、約 200 ミリ秒間待機してからもう一度お試しください。
- 再試行後もキュー メッセージが取得できなかった場合、待ち時間が最大になるまで再試行が続けられます。既定の最大待ち時間は 1 分間です。
- 最大待ち時間は、
maxPollingInterval内のmaxPollingIntervalプロパティで構成できます。
ローカル開発時の最大ポーリング間隔は、既定で 2 秒です。
Note
従量課金プランで関数アプリをホストする場合の課金については、ランタイムがポーリングに費やした時間は課金されません。
コンカレンシー
待機中のキュー メッセージが複数存在する場合、キュー トリガーはメッセージのバッチを取得し、関数インスタンスを同時に呼び出してそれらを処理します。 既定では、このバッチ サイズは 16 です。 処理されている数が 8 まで減少すると、このランタイムは別のバッチを取得し、それらのメッセージの処理を開始します。 そのため、1 つの仮想マシン (VM) 上で 1 関数あたりに処理されている同時実行メッセージの最大数は 24 です。 この制限は、各 VM 上のキューによってトリガーされる各関数に個別に適用されます。 関数アプリが複数の VM にスケールアウトされた場合、各 VM はトリガーを待機し、関数の実行を試みます。 たとえば、関数アプリが 3 つの VM にスケールアウトした場合、キューによってトリガーされる 1 つの関数の同時実行インスタンスの既定の最大数は 72 です。
新しいバッチを取得するためのバッチ サイズとしきい値は、host.json ファイルで構成できます。 関数アプリ内のキューによってトリガーされる関数の並列実行を最小限に抑えたい場合は、このバッチ サイズを 1 に設定できます。 この設定によってコンカレンシーが解消されるのは、関数アプリが 1 つの仮想マシン (VM) 上で実行される場合に限ります。
キュー トリガーは、関数がキュー メッセージを複数回同時に処理することを自動的に防止します。
host.json プロパティ
host.json ファイルには、キュー トリガーの動作を制御する設定が含まれています。 使用可能な設定の詳細については、「host.json 設定」を参照してください。