Azure Functionsという、AWS LambdaのAzure版的なサービスがあります。
MS FlowからAzureを操作したいことがあり、MS FlowにAzure Functionsのコネクタがあるので、Azure FunctionsでAzureを操作するFunctionを書けば、サーバーレスでできるのではと試してみました。
しかし試してみると残念なことに、手持ちの環境ではOffice365とAzureのテナントが違うため、MS Flowから直接Azure Functionsを呼ぶことはできませんでした。なので、代わりにFunctionのURLを直接叩いてFunctionを実行する形にしました。
問題発生
目的のFunctionが完成して、ポータルからの直接実行は問題なく行えました。
しかし、いざMS Flowから呼び出すと、タイムアウトエラーになってしまいました。
MS FlowのURL呼び出しアクションはタイムアウトが2分なのですが、まさかFunctionの初回起動(コールドスタート)に2分以上もかかるわけないよねと見てみたら本当にかかっていました…
対処検討
Azure FunctionsはWindows Server上で動くのでそのせいで遅いのかなと思い、まだPreviewだけどLinux上で動くFunctionもあるので、そちらにすれば早くなるかなと調べてみました。
すると、下記のような記載がありました。
現在、従量課金プランでは Linux での Functions のホスティングはサポートされていません。 Linux App Service プランで Linux コンテナー アプリをホストする必要があります。
従量課金プランとは、巷によくある、Functionが実行されていた時間だけ料金がかかるプラン。一方Linux App Service プランとは、サーバーを常に立てておき、Function実行時間にかかわらず月額固定料金が発生するプラン。
!?……。Functionなのにサーバー立てるって…。う~ん…何だかなぁとLinux Functionは見送りました。
対処方法
結局Functionが眠らないよう、定期的にLogic AppsでFunctionを呼び出すことで対処しました。
10分毎だと眠ってしまうことがあったので、8分毎にしています。
これで毎回、初回起動の待ち時間なしでFunctionが呼ばれるようになり解決しました!
………………。本当にFunctionでやって欲しい作業は、月に数回程不定期に発生するのですが、そのためだけに8分毎にダミーの呼び出しをするのも何だかなぁ…。というお話でした。
最後に
Azure Functionsは、応答時間を気にしなくていい処理に使うのが正しい使い方なのでしょうか。にしても、実行時間の大半が起動時間というのも何だかなぁという感じです。
AWS LambdaでAzureを操作する関数を作り、MS FlowからそのLambda関数を呼ぶということもできますが、それはそれで何だかなぁという気持ちになります。