Functions」ですが、いよいよ3回目、折り返し地点です。Functionsの内部の動きについて説明します。Execution」というのがあります。日本語に訳すと「信頼性の高い実行」です。Functionsは、もちろんAzureのデータセンターで動いているのですが、そこにあるサーバーやネットワークは、常に安定して動くとは限りません。Storage)に保存をしております。Storageから、実行状態を持ってきて、再度関数を実行します。FunctionsがDurableと呼ばれる理由なのかな勝手に妄想しております。こちらも言葉だけだとわかりにくいかと思いますので、これより図を交えてご説明いたします。Functionsの内部的な動きについて、ご説明します。Functionsを動かした場合の動きを追ってみます。URLのクエリパラメーターnumに指定された数字に2を足し、さらにその数字に2をかける処理を実行する。Queue」「DurableFunctionsHubHistory」の3つが必要であり、その詳細は以下のとおりです。Queueはオーケストレーター関数が起動するためのキューになります。Queueはアクティビティ関数が起動するためのキューになります。Queueにメッセージを投げます。Queueに投げられたメッセージをオーケストレーター関数が受け取り、オーケストレーター関数が起動します。その3:オーケストレーター関数の状態の登録オーケストレーター関数はDurableFunctionsHubHistoryテーブルに、自身の実行状態を登録します。EventTypeには、オーケストレーター関数全体が起動したことを表すExectionStarted、Nameにはオーケストレーターの関数名であるOrchestrator、Inputにはオーケストレーター関数の引数である2を登録します。この後このオーケストレーター関数は何回か繰り返し実行(リプレイ)します。このリプレイの仕組は後述しますが、一回目のリプレイであることを表す状態を、EventTypeにOrchestratorStartedとして登録します。Queueにメッセージを登録します。その5:アクティビティ関数Plus2の実行開始要求の登録アクティビティ関数Plus2の実行を開始を要求したことをDurableFunctionsHubHistoryテーブルに登録します。EventTypeにTaskScheduled、Nameに関数名であるPlus2を登録します。ここで一旦オーケストレーター関数は寝てしまいます。ここは非常に重要なポイントです。Queueへのメッセージの登録を受けて、アクティビティ関数Plus2が起動します。その7:アクティビティ関数Plus2の実行終了状態の登録アクティビティ関数Plus2の実行が終了しますと、DurableFunctionsHubHistoryテーブルにその状態を登録します。EventTypeにTaskCompleted、Resultに計算結果である4を登録します。Queueにメッセージを登録します。Queueへのメッセージの登録を受けて、オーケストレーター関数が再び起き上がります。コードを最初から実行します。これをリプレイと呼びます。オーケストレーター関数はアクティビティ関数が実行される度に、一旦寝て、皿に起き上がり、また最初からコードを実行するのです。その10:アクティビティ関数Plus2の実行状態チェックそして今、再びアクティビティ関数Plus2を実行しようとしています。これ、既に実行済みですよね・・・。オーケストレーター関数は、DurableFunctionsHubHistoryテーブルを見て、アクティビティ関数Plus2が実行済みかどうかをチェックします。実行済みですのでアクティビティ関数Plus2の実行をスキップします。Queueにメッセージを登録します。その12:アクティビティ関数MultiplyBy2の実行開始要求の登録アクティビティ関数MultiplyBy2の実行を開始を要求したことをDurableFunctionsHubHistoryテーブルに登録します。EventTypeにTaskScheduled、Nameに関数名であるMultiplyBy2を登録します。ここで、またまた一旦オーケストレーター関数は寝てしまいます。ここは非常に重要なポイントです。Queueへのメッセージの登録を受けて、アクティビティ関数MultiplyBy2が起動します。その14:アクティビティ関数MultiplyBy2の実行終了状態の登録アクティビティ関数Multiply2の実行が終了しますと、DurableFunctionsHubHistoryテーブルにその状態を登録します。EventTypeにTaskCompleted、Resultに計算結果である8を登録します。Queueにメッセージを登録します。Queueへのメッセージの登録を受けて、オーケストレーター関数が再び起き上がります。コードを最初から実行します。先ほどと同様、またリプレイされます。オーケストレーター関数はアクティビティ関数が実行される度に、一旦寝て、皿に起き上がり、また最初からコードを実行するのです。その17:アクティビティ関数Plus2の実行状態チェックそして今、再びアクティビティ関数Plus2を実行しようとしています。これ、既に実行済みですよね・・・。オーケストレーター関数は、DurableFunctionsHubHistoryテーブルを見て、アクティビティ関数Plus2が実行済みかどうかをチェックします。実行済みですのでアクティビティ関数Plus2の実行をスキップします。その18:アクティビティ関数MultiplyBy2の実行状態チェックそして同様に、再びアクティビティ関数MultiplyBy2を実行しようとしています。これ、既に実行済みですよね・・・。オーケストレーター関数は、DurableFunctionsHubHistoryテーブルを見て、アクティビティ関数MultiplyBy2が実行済みかどうかをチェックします。実行済みですのでアクティビティ関数MultiplyBy2の実行をスキップします。全てのアクティビティ関数の実行が終わったので、DurableFunctionsHubHistoryテーブルのEventTypeにExecutionCompletedを登録して、終了になります。Functionsの内部的な動きになります。Storage使わないで、全部一台のVMでオンメモリで行ってしまえばシンプルかもしれません。それだとVMが壊れちゃったときときに、復旧できなくなってしまいます。ここで、先程の例を挙げまして、アクティビティ関数Plus2を起動しようとしたら、実はそのアクティビティ関数をホストしているVMが壊れていたことを想定します。その1:VMの故障アクティビティ関数Plus2を起動しようとしたら、実はそのVMが壊れてしまいました。その2:新しいVMでの実行Azureの素晴らしい仕組みによって、新しいVMが用意されました(詳しい動きはわかりませんが概ねこういうことだろうなと思っております)。Queue内のメッセージを取得し、アクティビティ関数Plus2を起動します。実はそのVMが壊れてしまいました。その3:アクティビティ関数Plus2の実行状態の取得アクティビティ関数Plus2の実行状態を取得するため、DurableFunctionsHubHistoryにアクセスします。これはまだ未実行(TaskScheduledのみでTaskCompletedがない)なので、実行する必要がアリそうです。これがオンメモリで全て行われていたなら、VMが壊れた場合に、その状態を復旧することができません。Storageにチェックアウトしてリプライしているからこそ、信頼性の硬い実行が実現できます。Functionsが「Durable」と言われる理由の1つです。Exploreでその状態を見ることで、把握ができます。Functionsの内部的な動きをご説明しました。Functionsを使って、ちょっと面白いことをしようかなと思っております。雑誌等の執筆依頼を受付しております。役に立たなかった3人がこの投稿は役に立ったと言っています。コメントをキャンセルメールアドレスは表示されません。Reserved.本サイトに掲載されている社名、製品名、サービス名等は各社の商標または登録商標です。プライバシーポリシーお問い合わせ。