Azure Functions従量課金プランのコールドスタート時間が実用レベルになっていた
最近、サーバーレスでガッツリ開発を行っている取引先(元上司と元同僚が、うちとは別系統で独立した社)から、「Azure Functionsのコールドスタートが速くなった」という情報を聞いたので、試してみた。
計測方法
- Google Chromeの開発者ツールで手動でアクセスし、レスポンスタイムを測定。
- 2018/09/29-30の不定期に実施。Cold Startになるように20分以上測定時間をあける。
- 測定環境
- 愛知県名古屋市内
- いわゆる集合住宅のインターネット回線であまり品質は高くない。たびたびスローダウンする。
- 計測誤差が大きい環境であることは留意が必要。
- Azure Functionsは下記の通りに設定。
- 西日本
- 従量課金
- v2
- JavaScript
- PHP無効化
- FTP無効化
検証時に使ったコード
module.exports = async function (context, req) { context.log('JavaScript HTTP trigger function processed a request.'); context.res = { body: "hello" } };
計測結果
体感的には5-8sec。たまに速かったり遅かったり。ちなみに、コールドスタート完了後は数10~100msec程度でレスポンスが返ってくる。
Item | Time[sec] |
---|---|
Average | 6.80 |
Median | 6.16 |
Max | 15.86 |
Min | 4.25 |
80th percentile | 7.324 |
85th percentile | 8.755 |
90th percentile | 10.852 |
N = 105
まとめ
現時点ではコールドスタートは10秒程度を考えて設計すればよさそう。決して速い訳ではないが「まれに10秒程度待たされることがある」という程度ならば、Web APIとして使うとしても許容範囲内になってきたと思う。今後(半年スパンぐらい?で)、さらに改善されてくるはずなので、今から使い始めてみるのは悪くないタイミングではないかと思う。
Azure Functionsはざっくり、
- Azure App Service(もっと厳密にはWebJobs)上で実行されている
- JavaScriptの場合は、.NET Coreで実装されたサービスプロセスからNode.jsが実行されれる
- ユーザープログラムはコールドスタート時にAzure Filesから読みこむ
という構造になっている。Azure Filesが遅いと言われているのだが、いわゆるBundleを行って1ファイルにまとめたJavaScriptコードであれば、多少ファイルサイズが大きくなってもコールドスタート時間への影響は大きくないはずである。
しかし、過去に何度かAzure Functionsのコールドスタートを計測してきているのだが、サービス開始直後ぐらいは90秒ぐらいかかっていて、2017年11月ぐらいで20秒ぐらいかかっていた事を考えると、本当にめでたい。
Azure Functions従量課金プランのcold startでも10秒以内に収まるぐらいに改善したんだったら、割と積極的に使ってもいいかなぁという感じになる。前は60秒以上待たされてたからな…
— てるろー (@terurou) 2017年11月22日
Azure Functionsのcold start timeを何度か計測していて、母数が少ないのだけど、 ほぼ20secかなあという雰囲気。これに実行対象モジュールのロード(これも遅い)とか入るので…。という感じ。まぁでも、数か月前に計測してた時は60-90secぐらいかかってたので大分改善した
— てるろー (@terurou) 2017年11月23日