Azure Functions의 Cold start 문제에 대해서는 App Service Plan + Always On option 을 사용하는 방법이 있지만, 그 외에, node 의 경우는 webpack 를 사용하면 좋다. C# 의 경우는 프리컴파일 옵션. 오늘은 은근히 시험했을 뿐이므로, 내일 이후 여러가지 시험해 보고 싶다.

Cold start of Azure Function with large npm module trees is slow in Consumption plan #298

Cold Start and Warm Start on Consumption Plan #131

우선은 webpack 에 대해 조금 시험해 보았다.

Webpack으로 빌드 해 봅시다.

여기에 편리한 저장소가있었습니다.

Example WebPack with Azure Functions

조금 인스트럭션이 낡지만, 아래와 같이 하면 할 수 있다. clone 하고 아래와 같이 한다. Azure Functions CLI 는 설치 어긋남.

npm install
npm run build
func init
func host start

이제 서버가 움직입니다.

webpack의 실태를 본다.

webpack이 하고 싶은 것은 바로 알 수 있다. build/index.js 라는 파일이 생겨서 보자.

module.exports =
/******/ (function(modules) { // webpackBootstrap
/******/        // The module cache
/******/        var installedModules = {};
/******/
/******/        // The require function
/******/        function __webpack_require__(moduleId) {
/******/
/******/                // Check if module is in cache
/******/                if(installedModules[moduleId]) {
/******/                        return installedModules[moduleId].exports;
/******/                }
/******/                // Create a new module (and put it into the cache)
/******/                var module = installedModules[moduleId] = {
/******/                        i: moduleId,
/******/                        l: false,
/******/                        exports: {}
/******/                };
/******/
/******/                // Execute the module function
/******/                modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
 : 以下続く

webpack의 이번 목적에서의 효능

즉, 하나의 파일에 node_module 아래에 있는 라이브러리를 정리하고 있다. 원래, webpack 의 Azure Functions 에 의한 사용의 계기는, consumption plan 로의 기동이, webpack 를 하면(자) 꽤 빨라진다고 하는 이야기였다.

즉, 파일을 하나로 정리함으로써, 기동시의 스피드가 빨라지는 것 같다. 이것이 어떤 느낌인지 각 파일을 보자. webpack의 일 build를 보면 단순히 webpack을 실행하고 있습니다. $cat package.json { "name": "asdf", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "build": "webpack" }, "author": "", "license": "ISC", "dependencies": { "lodash": "^4.17.4", "ms-rest-azure": "^1.15.4" }, "devDependencies": { "webpack": "^2.2.1" } } webpack 은 webpack.config.js 를 보고 라이브러리를 정리하는 작업을 실시. 어디에, 결과를 토해낼지도 쓰고 있다. $cat webpack.config.js var webpack = require('webpack'); var path = require('path'); module.exports = { entry: './index.js', target: 'node', output: { path: path.join(__dirname, "build"), filename: 'index.js', library: "index", libraryTarget: "commonjs2" }, node: { __filename: false, __dirname: false, }, } 덧붙여서 참조되고, ./index.js 는, 각 functions 를 참조. $cat index.js var HttpTriggerJS = require('./HttpTriggerJS/index') var HTTPJS2 = require('./HTTPJS2/index') module.exports = { HttpTriggerJS: HttpTriggerJS, HTTPJS2: HTTPJS2 } 그리고 각 functions 는, 생성된 build/index.js 를 참조하고 있다. function.json $cat function.json { "disabled": false, "scriptFile":"../build/index.js", "entryPoint":"HttpTriggerJS", "bindings": [ { "authLevel": "function", "type": "httpTrigger", "direction": "in", "name": "req" }, { "type": "http", "direction": "out", "name": "$return" } ] } functions의 기술은 변경이 없다. $cat index.js let msRestAzure = require('ms-rest-azure'); let _ = require('lodash'); module.exports = function (context, req) { context.log('JavaScript HTTP trigger function processed a request.'); if (req.query.name || (req.body && req.body.name)) { res={ // status: 200, /* Defaults to 200 */ body: "Hello " + (req.query.name || req.body.name) }; } else { res={ status: 400, body: "Please pass a name on the query string or in the request body" }; } context.done(null, res); }; 이와 같이 webpack 을 사용하면 라이브러리가 하나의 파일에 정리되어 시작이 고속으로 부과되는 것 같다. 알았다.