Durable Functions の課金
Durable Functions は Azure Functions と同じように課金されます。 詳細については、Azure Functions の価格に関するページを参照してください。
Azure Functions の従量課金プランでオーケストレーター関数を実行する場合は、いくつかの課金動作に注意する必要があります。 以下のセクションでは、これらの動作とその影響について詳しく説明します。
オーケストレーター関数のリプレイの課金
オーケストレーター関数は、オーケストレーションの有効期間中に何度もリプレイされる場合があります。 各リプレイは、Azure Functions ランタイムによって個別の関数呼び出しとして表示されます。 このため、Azure Functions の従量課金プランでは、オーケストレーター関数のリプレイごとに課金されます。 他のプランの種類では、オーケストレーター関数のリプレイには課金されません。
オーケストレーター関数での待機と一時停止
オーケストレーター関数が非同期タスクの完了を待機しているときに、ランタイムはその特定の関数呼び出しは完了したと見なします。 オーケストレーター関数の課金はその時点で停止します。 次のオーケストレーター関数がリプレイされるまで課金は再開されません。 オーケストレーター関数の待機または一時停止に費やされた時間に対して課金されることはありません。
Note
他の関数を呼び出している関数は、サーバーレス アンチパターンと見なされる場合があります。 これは、"二重請求" と呼ばれる問題が原因です。 関数が別の関数を直接呼び出すときは、両方とも同時に実行されます。 呼び出し元の関数が応答を待機している間、呼び出し先の関数ではコードがアクティブに実行されています。 この場合は、呼び出し元の関数が呼び出し先の関数の実行を待機する時間に対して支払いを行う必要があります。
オーケストレーター関数で二重請求は生じません。 オーケストレーター関数では、アクティビティ関数 (またはサブオーケストレーション) の結果を待機している間、オーケストレーター関数の課金が停止します。
持続的な HTTP ポーリング
HTTP の機能に関する記事で説明されているように、オーケストレーター関数では、外部エンドポイントに対して実行時間の長い HTTP 呼び出しを行うことができます。 "HTTP 呼び出し" API は、非同期の 202 パターンに従いながら、内部的に HTTP エンドポイントをポーリングする場合があります。
現在、内部 HTTP ポーリング操作に対する直接の課金はありません。 ただし、内部ポーリングによってオーケストレーター関数でリプレイが定期的に行われる場合があります。 これらの関数の内部リプレイに対しては標準料金が請求されます。
Azure Storage トランザクション
Durable Functions では、状態の保持、メッセージの処理、BLOB リースによるパーティションの管理に、Azure Storage が既定で使用されします。 このストレージ アカウントは自分で所有するので、すべてのトランザクション コストは、ご利用の Azure サブスクリプションに課金されます。 Durable Functions によって使用される Azure Storage の成果物について詳しくは、タスク ハブに関する記事を参照してください。
Durable Functions アプリによって発生する実際の Azure Storage コストに寄与する要因がいくつかあります。
- 1 つの関数アプリが 1 つのタスク ハブと関連付けられ、一連の Azure Storage リソースが共有されます。 これらのリソースは、関数アプリ内のすべての持続的関数によって使用されます。 関数アプリ内の関数の実際の数は、Azure Storage トランザクションのコストには影響しません。
- 各関数アプリ インスタンスでは、指数バックオフ ポーリング アルゴリズムを使用して、ストレージ アカウント内の複数のキューに対して内部的にポーリングが行われます。 アイドル状態のアプリ インスタンスでは、アクティブなアプリよりキューをポーリングする頻度が低下し、結果としてトランザクション コストが少なくなります。 Azure Storage プロバイダーを使用する場合のDurable Functions のキューポーリング動作の詳細については、Azure Storage プロバイダー ドキュメントの キューポーリング セクション を参照してください。
- Azure Functions の従量課金プランまたは Premium プランで実行している場合、Azure Functions のスケール コントローラーでは、バックグラウンドのすべてのタスク ハブ キューに対して定期的にポーリングが行われます。 関数アプリが小規模から中規模の場合は、1 つのスケール コントローラー インスタンスだけがこれらのキューのポーリングを行います。 関数アプリが多数のインスタンスにスケールアウトされると、より多くのスケール コントローラー インスタンスが追加される場合があります。 これらの追加のスケール コントローラー インスタンスによって、キュートランザクションの総コストが増加する可能性があります。
- 関数アプリの各インスタンスは、BLOB リースのセットに対して競合します。 これらのインスタンスでは、Azure Blob service が定期的に呼び出されて、保持されているリースの更新または新しいリースの取得が試みられます。 BLOB リースの数は、タスク ハブの構成済みパーティション数によって決まります。 多くの場合、多数の関数アプリ インスタンスにスケールアウトすると、これらのリース操作に関連する Azure Storage トランザクション コストが増加します。
Azure Storage の価格について詳しくは、Azure Storage の価格に関するドキュメントを参照してください。