Durable Functions とはWhat are Durable Functions?

Durable Functions は、サーバーレス コンピューティング環境でステートフル関数を記述できる Azure Functions の拡張機能です。Durable Functions is an extension of Azure Functions that lets you write stateful functions in a serverless compute environment. この拡張機能では、Azure Functions プログラミング モデルを使用して、オーケストレーター関数を記述することでステートフル ワークフローを定義でき、エンティティ関数を記述することでステートフル エンティティを定義できます。The extension lets you define stateful workflows by writing orchestrator functions and stateful entities by writing entity functions using the Azure Functions programming model. 拡張機能によって状態、チェックポイント、再起動がバックグラウンドで管理されるため、ユーザーはビジネス ロジックに専念できます。Behind the scenes, the extension manages state, checkpoints, and restarts for you, allowing you to focus on your business logic.

サポートされている言語Supported languages

Durable Functions では、現在次の言語をサポートしています。Durable Functions currently supports the following languages:

  • C#: プリコンパイル済みクラス ライブラリC# スクリプトの両方。C#: both precompiled class libraries and C# script.
  • JavaScript: Azure Functions ランタイムのバージョン 2.x でのみサポートされています。JavaScript: supported only for version 2.x of the Azure Functions runtime. Durable Functions 拡張機能のバージョン 1.7.0 以降が必要です。Requires version 1.7.0 of the Durable Functions extension, or a later version.
  • Python: Durable Functions 拡張機能のバージョン 1.8.5 以降が必要です。Python: requires version 1.8.5 of the Durable Functions extension, or a later version. Durable Functions のサポートは、現在パブリック プレビューの段階です。Support for Durable Functions is currently in public preview.
  • F#: プリコンパイル済みクラス ライブラリと F# スクリプト。F#: precompiled class libraries and F# script. F# スクリプトは、Azure Functions ランタイムのバージョン 1.x でのみサポートされています。F# script is only supported for version 1.x of the Azure Functions runtime.
  • PowerShell: Durable Functions のサポートは、現在パブリック プレビューの段階です。PowerShell: support for Durable Functions is currently in public preview. Azure Functions ランタイムのバージョン 3.x と PowerShell 7 でのみサポートされています。Supported only for version 3.x of the Azure Functions runtime and PowerShell 7. Durable Functions 拡張機能のバージョン 2.2.2 以降が必要です。Requires version 2.2.2 of the Durable Functions extension, or a later version. 現在サポートされているパターンは次のとおりです。関数チェーンファンアウトおよびファンイン非同期 HTTP APIOnly the following patterns are currently supported: Function chaining, Fan-out/fan-in, Async HTTP APIs.

Durable Functions では、すべての Azure Functions 言語をサポートすることを目標としています。Durable Functions has a goal of supporting all Azure Functions languages. 追加言語をサポートするための最新の作業状況については、Durable Functions の問題の一覧を参照してください。See the Durable Functions issues list for the latest status of work to support additional languages.

Azure Functions と同様に、Visual Studio 2019Visual Studio Code、および Azure portal を使用して Durable Functions を開発するのに役立つテンプレートがあります。Like Azure Functions, there are templates to help you develop Durable Functions using Visual Studio 2019, Visual Studio Code, and the Azure portal.

アプリケーション パターンApplication patterns

Durable Functions の主なユース ケースは、サーバーレス アプリケーションにおける複雑でステートフルな調整の要件をシンプルにすることです。The primary use case for Durable Functions is simplifying complex, stateful coordination requirements in serverless applications. 以下のセクションでは、Durable Functions を使用することでメリットがある、典型的なアプリケーションのパターンを示します。The following sections describe typical application patterns that can benefit from Durable Functions:

パターン #1: 関数チェーンPattern #1: Function chaining

関数チェーン パターンでは、一連の関数が特定の順序で実行されます。In the function chaining pattern, a sequence of functions executes in a specific order. このパターンでは、ある関数の出力が、別の関数の入力に適用されます。In this pattern, the output of one function is applied to the input of another function.

関数チェーン パターンの図

次の例に示すように、Durable Functions を使用して、関数チェーン パターンを簡潔に実装できます。You can use Durable Functions to implement the function chaining pattern concisely as shown in the following example.

この例では、F1F2F3、および F4 という値が、同じ関数アプリ内の他の関数の名前です。In this example, the values F1, F2, F3, and F4 are the names of other functions in the same function app. 通常の命令型のコーディング構造を使用して、制御フローを実装できます。You can implement control flow by using normal imperative coding constructs. コードは、上から下に実行されます。Code executes from the top down. コードに条件文やループなどの既存言語の制御フロー セマンティクスを含めることができます。The code can involve existing language control flow semantics, like conditionals and loops. try/catch/finally ブロックに、エラー処理ロジックを含めることができます。You can include error handling logic in try/catch/finally blocks.

[FunctionName("Chaining")]
public static async Task<object> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    try
    {
        var x = await context.CallActivityAsync<object>("F1", null);
        var y = await context.CallActivityAsync<object>("F2", x);
        var z = await context.CallActivityAsync<object>("F3", y);
        return  await context.CallActivityAsync<object>("F4", z);
    }
    catch (Exception)
    {
        // Error handling or compensation goes here.
    }
}

context パラメーターを使用して、他の関数を名前で呼び出し、パラメーターを渡して、関数の出力を返すことができます。You can use the context parameter to invoke other functions by name, pass parameters, and return function output. コードが await を呼び出すたびに Durable Functions フレームワークは、現在の関数インスタンスの進行状況にチェックポイントを設定します。Each time the code calls await, the Durable Functions framework checkpoints the progress of the current function instance. プロセスまたは仮想マシンが実行途中でリサイクルされる場合、関数インスタンスは直前の await 呼び出しから再開されます。If the process or virtual machine recycles midway through the execution, the function instance resumes from the preceding await call. 詳細については、次のセクション (パターン #2: ファンアウト/ファンイン) を参照してください。For more information, see the next section, Pattern #2: Fan out/fan in.

パターン #2: ファンアウト/ファンインPattern #2: Fan out/fan in

ファンアウト/ファンイン パターンでは、複数の関数を並列で実行し、すべての関数が完了するまで待機します。In the fan out/fan in pattern, you execute multiple functions in parallel and then wait for all functions to finish. 複数の関数から返される結果に基づいて集計作業が行われることは、よくあることです。Often, some aggregation work is done on the results that are returned from the functions.

ファンアウト/ファンイン パターンの図

通常の関数では、複数のメッセージを 1 つのキューに送信することでファンアウトできます。With normal functions, you can fan out by having the function send multiple messages to a queue. ファンインして戻ることはずっと難しくなります。Fanning back in is much more challenging. 通常の関数でファンインするには、キューによってトリガーされた関数の終了を追跡した後、関数の出力を格納するコードを記述する必要があります。To fan in, in a normal function, you write code to track when the queue-triggered functions end, and then store function outputs.

Durable Functions 拡張機能では、比較的単純なコードでこのパターンを処理します。The Durable Functions extension handles this pattern with relatively simple code:

[FunctionName("FanOutFanIn")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var parallelTasks = new List<Task<int>>();

    // Get a list of N work items to process in parallel.
    object[] workBatch = await context.CallActivityAsync<object[]>("F1", null);
    for (int i = 0; i < workBatch.Length; i++)
    {
        Task<int> task = context.CallActivityAsync<int>("F2", workBatch[i]);
        parallelTasks.Add(task);
    }

    await Task.WhenAll(parallelTasks);

    // Aggregate all N outputs and send the result to F3.
    int sum = parallelTasks.Sum(t => t.Result);
    await context.CallActivityAsync("F3", sum);
}

ファンアウト作業は、F2 関数の複数のインスタンスに分散されます。The fan-out work is distributed to multiple instances of the F2 function. 動的タスク リストを使用して、この作業が追跡されます。The work is tracked by using a dynamic list of tasks. Task.WhenAll が呼び出され、すべての呼び出された関数が終了するまで待機します。Task.WhenAll is called to wait for all the called functions to finish. その後、F2 関数の出力が動的タスク リストから集計され、F3 関数に渡されます。Then, the F2 function outputs are aggregated from the dynamic task list and passed to the F3 function.

Task.WhenAllawait 呼び出しの際に設定される自動チェックポイントによって、実行途中でクラッシュや再起動が発生した場合でも、既に完了したすべてのタスクをやり直す必要がなくなります。The automatic checkpointing that happens at the await call on Task.WhenAll ensures that a potential midway crash or reboot doesn't require restarting an already completed task.

注意

まれな状況ですが、アクティビティ関数の完了後、完了がオーケストレーション履歴に保存される前の時間帯にクラッシュが発生する可能性があります。In rare circumstances, it's possible that a crash could happen in the window after an activity function completes but before its completion is saved into the orchestration history. この場合、アクティビティ関数は、プロセス復旧後に最初から再実行されます。If this happens, the activity function would re-run from the beginning after the process recovers.

パターン #3: 非同期 HTTP APIPattern #3: Async HTTP APIs

非同期 HTTP API パターンでは、外部クライアントとの間の実行時間の長い操作の状態を調整するという問題に対処します。The async HTTP API pattern addresses the problem of coordinating the state of long-running operations with external clients. このパターンを実装する一般的な方法は、HTTP エンドポイントによって実行時間の長いアクションをトリガーすることです。A common way to implement this pattern is by having an HTTP endpoint trigger the long-running action. その後、ポーリングによって操作が完了したことを認識できる状態エンドポイントにクライアントをリダイレクトします。Then, redirect the client to a status endpoint that the client polls to learn when the operation is finished.

HTTP API パターンの図

Durable Functions には、このパターン向けの組み込みサポートが用意されており、長時間の関数の実行を操作するために記述する必要があるコードを簡略化できます。または、そのようなコードの記述が不要になります。Durable Functions provides built-in support for this pattern, simplifying or even removing the code you need to write to interact with long-running function executions. たとえば、Durable Functions のクイック スタート サンプル (C#JavaScript) に、新しいオーケストレーター関数のインスタンスを開始するために使用できる、シンプルな REST コマンドが示されています。For example, the Durable Functions quickstart samples (C# and JavaScript) show a simple REST command that you can use to start new orchestrator function instances. インスタンスが開始されると、この拡張機能によって、オーケストレーター関数の状態をクエリする Webhook HTTP API が公開されます。After an instance starts, the extension exposes webhook HTTP APIs that query the orchestrator function status.

次の例は、オーケストレーターを開始し、その状態をクエリする REST コマンドを示しています。The following example shows REST commands that start an orchestrator and query its status. わかりやすくするため、この例ではプロトコルの細部をいくらか省略しています。For clarity, some protocol details are omitted from the example.

> curl -X POST https://myfunc.azurewebsites.net/api/orchestrators/DoWork -H "Content-Length: 0" -i
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec

{"id":"b79baf67f717453ca9e86c5da21e03ec", ...}

> curl https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec

{"runtimeStatus":"Running","lastUpdatedTime":"2019-03-16T21:20:47Z", ...}

> curl https://myfunc.azurewebsites.net/runtime/webhooks/durabletask/instances/b79baf67f717453ca9e86c5da21e03ec -i
HTTP/1.1 200 OK
Content-Length: 175
Content-Type: application/json

{"runtimeStatus":"Completed","lastUpdatedTime":"2019-03-16T21:20:57Z", ...}

状態は Durable Functions ランタイムによって自動的に管理されるため、自分で状態追跡メカニズムを実装する必要はありません。Because the Durable Functions runtime manages state for you, you don't need to implement your own status-tracking mechanism.

Durable Functions 拡張機能には、長時間実行されるオーケストレーションを管理する組み込みの HTTP API が公開されています。The Durable Functions extension exposes built-in HTTP APIs that manage long-running orchestrations. または、独自の関数トリガー (HTTP、キュー、Azure Event Hubs など) とオーケストレーション クライアント バインドを使用して、このパターンを自分で実装できます。You can alternatively implement this pattern yourself by using your own function triggers (such as HTTP, a queue, or Azure Event Hubs) and the orchestration client binding. たとえば、キュー メッセージを使用して終了をトリガーできます。For example, you might use a queue message to trigger termination. または、生成されたキーを認証で使用する組み込みの HTTP API の代わりに、Azure Active Directory の認証ポリシーによって保護される HTTP トリガーを使用できます。Or, you might use an HTTP trigger that's protected by an Azure Active Directory authentication policy instead of the built-in HTTP APIs that use a generated key for authentication.

詳細については、HTTP 機能の記事を参照してください。その記事では、Durable Functions 拡張機能を使用して、非同期の長時間プロセスを HTTP 経由で公開する方法について説明しています。For more information, see the HTTP features article, which explains how you can expose asynchronous, long-running processes over HTTP using the Durable Functions extension.

パターン #4: モニターPattern #4: Monitor

監視パターンは、ワークフロー内の柔軟な繰り返しプロセスを指します。The monitor pattern refers to a flexible, recurring process in a workflow. 一例は、特定の条件が満たされるまでポーリングすることです。An example is polling until specific conditions are met. 通常のタイマー トリガーを使用して、定期的なクリーンアップ ジョブなどの基本的なシナリオに対処できますが、その間隔は静的であり、インスタンスの有効期間の管理は複雑になります。You can use a regular timer trigger to address a basic scenario, such as a periodic cleanup job, but its interval is static and managing instance lifetimes becomes complex. Durable Functions を使用して、柔軟な繰り返し間隔の作成、タスクの有効期間の管理、単一のオーケストレーションからの複数の監視プロセスの作成を実行できます。You can use Durable Functions to create flexible recurrence intervals, manage task lifetimes, and create multiple monitor processes from a single orchestration.

監視パターンの一例は、前述の非同期 HTTP API シナリオを逆にすることです。An example of the monitor pattern is to reverse the earlier async HTTP API scenario. 外部クライアント用のエンドポイントを公開して実行時間の長い操作を監視する代わりに、長時間実行される監視で外部エンドポイントを使用して、状態が変化するまで待機します。Instead of exposing an endpoint for an external client to monitor a long-running operation, the long-running monitor consumes an external endpoint, and then waits for a state change.

監視パターンの図

数行のコードで、Durable Functions を使用して任意のエンドポイントを観察する複数のモニターを作成できます。In a few lines of code, you can use Durable Functions to create multiple monitors that observe arbitrary endpoints. 条件が満たされたときにこれらのモニターによって実行を終了するか、別の関数から持続的オーケストレーション クライアントを使用してモニターを終了できます。The monitors can end execution when a condition is met, or another function can use the durable orchestration client to terminate the monitors. 特定の条件に基づいてモニターの wait 間隔を変更できます (指数関数的バックオフなど)。You can change a monitor's wait interval based on a specific condition (for example, exponential backoff.)

次のコードでは、基本的なモニターが実装されます。The following code implements a basic monitor:

[FunctionName("MonitorJobStatus")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    int jobId = context.GetInput<int>();
    int pollingInterval = GetPollingInterval();
    DateTime expiryTime = GetExpiryTime();

    while (context.CurrentUtcDateTime < expiryTime)
    {
        var jobStatus = await context.CallActivityAsync<string>("GetJobStatus", jobId);
        if (jobStatus == "Completed")
        {
            // Perform an action when a condition is met.
            await context.CallActivityAsync("SendAlert", machineId);
            break;
        }

        // Orchestration sleeps until this time.
        var nextCheck = context.CurrentUtcDateTime.AddSeconds(pollingInterval);
        await context.CreateTimer(nextCheck, CancellationToken.None);
    }

    // Perform more work here, or let the orchestration end.
}

要求が受信されると、そのジョブ ID 用の新しいオーケストレーション インスタンスが作成されます。When a request is received, a new orchestration instance is created for that job ID. インスタンスは、条件が満たされてループが終了するまで、状態をポーリングします。The instance polls a status until a condition is met and the loop is exited. ポーリング間隔は、永続タイマーによって制御されます。A durable timer controls the polling interval. その後、さらに作業を実行するか、オーケストレーションを終了できます。Then, more work can be performed, or the orchestration can end. nextCheckexpiryTime を超えると、モニターが終了します。When nextCheck exceeds expiryTime, the monitor ends.

パターン #5: 人による操作Pattern #5: Human interaction

多くの自動化されたプロセスには、何らかの人による操作が含まれます。Many automated processes involve some kind of human interaction. 自動化されたプロセスに人による操作が含まれる場合に問題になるのが、人は必ずしもクラウド サービスのように可用性と応答性が高くないということです。Involving humans in an automated process is tricky because people aren't as highly available and as responsive as cloud services. 自動化されたプロセスでは、タイムアウトと補正ロジックを使用して、この操作を許容する必要があります。An automated process might allow for this interaction by using timeouts and compensation logic.

承認プロセスは、人による操作を含むビジネス プロセスの一例です。An approval process is an example of a business process that involves human interaction. 特定の金額を超えた経費報告書は、上司の承認が必要な場合があります。Approval from a manager might be required for an expense report that exceeds a certain dollar amount. 上司が (休暇中などで) その経費報告書を 72 時間以内に承認しない場合は、他の誰か (おそらくは上司の上司) から承認を得るためにエスカレーション プロセスを開始します。If the manager doesn't approve the expense report within 72 hours (maybe the manager went on vacation), an escalation process kicks in to get the approval from someone else (perhaps the manager's manager).

人による操作が含まれるパターンの図

オーケストレーター関数を使用して、この例のパターンを実装できます。You can implement the pattern in this example by using an orchestrator function. オーケストレーターが永続タイマーを使用して承認を要求します。The orchestrator uses a durable timer to request approval. オーケストレーターは、タイムアウトが発生した場合はエスカレーションを行います。The orchestrator escalates if timeout occurs. オーケストレーターは、外部イベント (人による操作によって生成される通知など) が発生するまで待機します。The orchestrator waits for an external event, such as a notification that's generated by a human interaction.

次の例では、人による操作パターンを示すための承認プロセスを作成しています。These examples create an approval process to demonstrate the human interaction pattern:

[FunctionName("ApprovalWorkflow")]
public static async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    await context.CallActivityAsync("RequestApproval", null);
    using (var timeoutCts = new CancellationTokenSource())
    {
        DateTime dueTime = context.CurrentUtcDateTime.AddHours(72);
        Task durableTimeout = context.CreateTimer(dueTime, timeoutCts.Token);

        Task<bool> approvalEvent = context.WaitForExternalEvent<bool>("ApprovalEvent");
        if (approvalEvent == await Task.WhenAny(approvalEvent, durableTimeout))
        {
            timeoutCts.Cancel();
            await context.CallActivityAsync("ProcessApproval", approvalEvent.Result);
        }
        else
        {
            await context.CallActivityAsync("Escalate", null);
        }
    }
}

永続タイマーを作成するために、context.CreateTimer が呼び出されます。To create the durable timer, call context.CreateTimer. 通知は context.WaitForExternalEvent が受け取ります。The notification is received by context.WaitForExternalEvent. その後、エスカレーションする (タイムアウトが先に発生した場合) か承認を処理する (タイムアウト前に承認を得た場合) かを決定するために、Task.WhenAny が呼び出されます。Then, Task.WhenAny is called to decide whether to escalate (timeout happens first) or process the approval (the approval is received before timeout).

外部クライアントでは、組み込みの HTTP API を使用して、待機中のオーケストレーター関数にイベント通知を配信できます。An external client can deliver the event notification to a waiting orchestrator function by using the built-in HTTP APIs:

curl -d "true" http://localhost:7071/runtime/webhooks/durabletask/instances/{instanceId}/raiseEvent/ApprovalEvent -H "Content-Type: application/json"

同じ関数アプリ内の別の関数から持続的オーケストレーション クライアントを使用してイベントを発生させることもできます。An event can also be raised using the durable orchestration client from another function in the same function app:

[FunctionName("RaiseEventToOrchestration")]
public static async Task Run(
    [HttpTrigger] string instanceId,
    [DurableClient] IDurableOrchestrationClient client)
{
    bool isApproved = true;
    await client.RaiseEventAsync(instanceId, "ApprovalEvent", isApproved);
}

パターン #6:アグリゲーター (ステートフル エンティティ)Pattern #6: Aggregator (stateful entities)

6 番目のパターンは、ある期間のイベント データを 1 つのアドレス可能なエンティティ に集計することに関連しています。The sixth pattern is about aggregating event data over a period of time into a single, addressable entity. このパターンでは、集計されるデータは、複数のソースから取得されるか、バッチで配信されるか、または長期間にわたって分散される可能性があります。In this pattern, the data being aggregated may come from multiple sources, may be delivered in batches, or may be scattered over long-periods of time. アグリゲーターがイベント データの到着時にイベント データに対してアクションを行ったり、外部クライアントが集計されたデータをクエリする必要が生じたりする場合があります。The aggregator might need to take action on event data as it arrives, and external clients may need to query the aggregated data.

アグリゲーターの図

このパターンを通常のステートレス関数で実装しようとする際に注意が必要な点は、同時実行制御が大きな課題となることです。The tricky thing about trying to implement this pattern with normal, stateless functions is that concurrency control becomes a huge challenge. 複数のスレッドが同時に同じデータを変更することに注意する必要があるだけでなく、アグリゲーターが一度に 1 つの VM 上でのみ実行されるようにすることも注意する必要があります。Not only do you need to worry about multiple threads modifying the same data at the same time, you also need to worry about ensuring that the aggregator only runs on a single VM at a time.

持続エンティティを使用すると、このパターンを単一の関数として簡単に実装できます。You can use Durable entities to easily implement this pattern as a single function.

[FunctionName("Counter")]
public static void Counter([EntityTrigger] IDurableEntityContext ctx)
{
    int currentValue = ctx.GetState<int>();
    switch (ctx.OperationName.ToLowerInvariant())
    {
        case "add":
            int amount = ctx.GetInput<int>();
            ctx.SetState(currentValue + amount);
            break;
        case "reset":
            ctx.SetState(0);
            break;
        case "get":
            ctx.Return(currentValue);
            break;
    }
}

持続エンティティは、.NET のクラスとしてモデル化することもできます。Durable entities can also be modeled as classes in .NET. このモデルは、操作の一覧が固定されていて、サイズが大きくなった場合に役立ちます。This model can be useful if the list of operations is fixed and becomes large. 次の例は、.NET クラスおよびメソッドを使用した Counter エンティティの同等の実装です。The following example is an equivalent implementation of the Counter entity using .NET classes and methods.

public class Counter
{
    [JsonProperty("value")]
    public int CurrentValue { get; set; }

    public void Add(int amount) => this.CurrentValue += amount;

    public void Reset() => this.CurrentValue = 0;

    public int Get() => this.CurrentValue;

    [FunctionName(nameof(Counter))]
    public static Task Run([EntityTrigger] IDurableEntityContext ctx)
        => ctx.DispatchAsync<Counter>();
}

クライアントは、エンティティ クライアント バインディングを使用して、エンティティ関数の操作をエンキューすることができます ("シグナル通知" とも呼ばれる)。Clients can enqueue operations for (also known as "signaling") an entity function using the entity client binding.

[FunctionName("EventHubTriggerCSharp")]
public static async Task Run(
    [EventHubTrigger("device-sensor-events")] EventData eventData,
    [DurableClient] IDurableOrchestrationClient entityClient)
{
    var metricType = (string)eventData.Properties["metric"];
    var delta = BitConverter.ToInt32(eventData.Body, eventData.Body.Offset);

    // The "Counter/{metricType}" entity is created on-demand.
    var entityId = new EntityId("Counter", metricType);
    await entityClient.SignalEntityAsync(entityId, "add", delta);
}

注意

動的に生成されたプロキシは、.NET においてタイプセーフな方法でシグナル通知エンティティに対して使用することもできます。Dynamically generated proxies are also available in .NET for signaling entities in a type-safe way. シグナル通知に加えて、クライアントは、オーケストレーション クライアント バインディングでタイプ セーフのメソッドを使用して、エンティティ関数の状態をクエリすることもできます。And in addition to signaling, clients can also query for the state of an entity function using type-safe methods on the orchestration client binding.

エンティティ関数は、Durable Functions 2.0 以降の C# および JavaScript で使用できます。Entity functions are available in Durable Functions 2.0 and above for C# and JavaScript.

テクノロジThe technology

Durable Functions 拡張機能の背後には、コードでワークフローを構築するために使用される GitHub のオープン ソース ライブラリである Durable Task Framework があり、この拡張機能はその上に構築されています。Behind the scenes, the Durable Functions extension is built on top of the Durable Task Framework, an open-source library on GitHub that's used to build workflows in code. Azure Functions が Azure WebJobs のサーバーレスな進化形であるのと同じように、Durable Functions は Durable Task Framework のサーバーレスな進化形です。Like Azure Functions is the serverless evolution of Azure WebJobs, Durable Functions is the serverless evolution of the Durable Task Framework. Microsoft や他の組織は、ミッション クリティカルなプロセスを自動化するために、Durable Task Framework を広範囲にわたって使用しています。Microsoft and other organizations use the Durable Task Framework extensively to automate mission-critical processes. サーバーレスな Azure Functions 環境には自然に適合します。It's a natural fit for the serverless Azure Functions environment.

コードの制約Code constraints

信頼性の高い長時間の実行の保証を提供するために、オーケストレーター関数には、従う必要がある一連のコーディング規則があります。In order to provide reliable and long-running execution guarantees, orchestrator functions have a set of coding rules that must be followed. 詳細については、「オーケストレーター関数コードの制約」の記事を参照してください。For more information, see the Orchestrator function code constraints article.

課金Billing

Durable Functions は Azure Functions と同じように課金されます。Durable Functions are billed the same as Azure Functions. 詳細については、Azure Functions の価格に関するページを参照してください。For more information, see Azure Functions pricing. Azure Functions の従量課金プランでオーケストレーター関数を実行する場合は、注意する必要がある課金動作がいくつかあります。When executing orchestrator functions in the Azure Functions Consumption plan, there are some billing behaviors to be aware of. これらの動作の詳細については、「Durable Functions の課金」の記事を参照してください。For more information on these behaviors, see the Durable Functions billing article.

すぐに始めるJump right in

次の言語固有のクイック スタート チュートリアルのいずれかを完了することで、10 分足らずで Durable Functions を使い始めることができます。You can get started with Durable Functions in under 10 minutes by completing one of these language-specific quickstart tutorials:

これらのクイックスタートでは、"hello world" という持続的関数をローカルで作成してテストします。In these quickstarts, you locally create and test a "hello world" durable function. その後、関数コードを Azure に発行します。You then publish the function code to Azure. 作成した関数は、他の関数の呼び出しを調整し、連結します。The function you create orchestrates and chains together calls to other functions.

詳細情報Learn more

次のビデオでは、Durable Functions の利点を取り上げています。The following video highlights the benefits of Durable Functions:

Durable Functions と基になるテクノロジの詳細については、次のビデオをご覧ください (.NET に重点を置いていますが、考え方はサポートされている他の言語にも当てはまります)。For a more in-depth discussion of Durable Functions and the underlying technology, see the following video (it's focused on .NET, but the concepts also apply to other supported languages):

Durable Functions は Azure Functionsの高度な拡張機能であるため、すべてのアプリケーションに適しているわけではありません。Because Durable Functions is an advanced extension for Azure Functions, it isn't appropriate for all applications. 他の Azure オーケストレーション テクノロジとの比較については、「Azure Functions と Azure Logic Apps の比較」を参照してください。For a comparison with other Azure orchestration technologies, see Compare Azure Functions and Azure Logic Apps.

次のステップNext steps