Azure Functionsの痒いところに手が届かない感
Updated Date: 2024/01/01 02:55
結構色々とAzure Functionsを利用しているけど、並べれば悪い点しか出てこない。 簡単に列挙する。
すぐに実行してくれない
Azure Functionsは従量課金制とApp Service料金の2つに分かれている。前者はその名の通り使ったぶんの料金だけど、
後者の場合は基本的にはVMを立ち上げていることと同じなので、それ相応の費用がかかる。(開発用でも4000円くらい)
で、前者の場合、1度実行したあとにしばらく実行されないとスリープ状態となり、再度実行するときにやたらレスポンスが遅い。
AWSのLambdaとかと比べ物にならない低速具合だ。
また、使える関数としてJSを選んで、node modulesを色々とnpmで入れて使った場合、さらにレスポンスが遅くなる。
公式回答ではこれは低レイテンシーなファイルのリモート操作の所為らしく、Webpack使えばなんとかなるそうだ。
(https://github.com/Azure/azure-functions-pack)
とはいえ、このWebpack、ES2017とかの記法バリバリで書かれたnpmのライブラリだとうまくまとめられないとかいう問題もあるようで、 正直僕の手には負えなかった。はっきり言おう。無理であると。
ライブラリ追加がコンソール経由&遅すぎる
先述通りnpmでライブラリ使おうとしても、そのままだと使えない。これには2つの解決方法がある。
1つはnode_modulesごとAzure Functionsにアップロードしてしまうこと。だが、これだと例えばOS依存のコンパイルが必要なライブラリの場合、
macからアップしてしまってはWindowsで動くAzure Functionsではライブラリを参照できずに詰む。
もう1つはKudoと言われるAzureの拡張Webコンソールを使う方法だけど、こっちだと npm install がいつまで経っても終わらないか、フリーズする。
(この理由も先述通り低レイテンシーなファイル操作にあるらしい)
八方塞がりである。
C#といいつつC#Script
C#が使えるということで使おうとしたら、「csx」という謎の拡張子であった。
調べるとこれは「C#Script」というC#のスクリプト版の拡張子らしい。そのため、単純にVisualStudioでコードの編集ができない。(すくなくともmacOSでは)
そして、このC#もnodeと同じようにNuGetのライブラリは別途追加する必要があり、その方法が「project.json」というファイルを用意するというもの。
(https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-reference-csharp#using-nuget-packages)
でもAzure Functionsでこのファイルを追加しても一向に読み取ってくれない。1度だけ成功したけど、それ以降は何度やってもダメだった。
デプロイができない
VSCode経由でAzure Functionsに直接デプロイができるよーということでやってみたけど、たしかにできることもあるができなくなるパターンのほうが圧倒的に多くそして理由も分からないということばかりだった。~~
また、ソースの管理もGitだったりNoneだったり選べるけれど、それぞれの利点も分からないし何よりまともにローカルのファイルとAzure Functionsのファイルが同期できない歯がゆさは、正直安定したサービスとは言えないなという印象である。
[2019/02/15更新]
VSCodeの進化がめちゃくちゃ早くて、2019年2月現在はMacユーザーであってもVSCode経由でのAzure Functionsの直感的操作ができるようになった。
これはとても良い体験なので是非試してほしい。Azure Functionsの本質的な遅さは改善されていないけど……。
まとめ
Azure Functionsは、おそらく他のIaaS(AWSのLambda、GCPのFirebase)に比べて、現時点ではサービス的に劣っていると言わざるをえない。 とはいえ、速度を気にしないおよびLinuxオンリーでの開発という点に絞ればその限りではない。お金をそれなりに積めばちゃんと速くなる。 まぁでも、高レスポンスを要求されるようなシステムには組み込まず、 どっちかというと非同期処理を行うようなQueueとかジョブとの組み合わせのほうが用途には良い気がしている。