サーバレスでベンダーロックインを避ける方法
サーバレスでベンダーロックインを避ける方法
ここ数日、ノートアプリInkdropを題材にしてAWS Lambdaを触っていた。まずはherokuで運用してるAPIをLambdaで動かすことに成功した。良かった点は、koa.js製のコードベースをほぼ変更する必要が無かった事。小さなfunctionに小分けする必要すら無かった。思ってたよりすんなり行って拍子抜けしてる。
見方を変えると、このAPIがHerokuとLambdaの両方で動くようになったと評価できる。これは嬉しい誤算。帰り道が残されたのは安心感がある。サーバレスには興味あるけど、移行コストがかかりそうとかロックインされるんじゃないかと思っている人が多いと思う。でも工夫すれば案外手軽にできることが分かったので、参考にしてもらいたい。
アーキテクチャについては先日こちらに書いたとおり、AWS Lambda + API Gatewayという構成。APIを動かすにあたって以下の記事を参考にした。
この記事では、Lambda上でExpressフレームワークを動かす方法が書かれている。APIへのリクエストをAPI Gatewayで受け取ってLambda functionに転送している。つまりLambda向けのイベントハンドラを書かなくても、既存のコードがそのまま再利用できる。Expressだけでなくkoaでも動かせた：
<span id="014b" class="qv pi io qr b gz qw qx m qy qz">const serverless = require('aws-serverless-express')<br></br>const Koa = require('koa')</span><span id="e079" class="qv pi io qr b gz ra qx m qy qz">const app = new Koa()<br></br>app.proxy = true</span><span id="cf0b" class="qv pi io qr b gz ra qx m qy qz">〜〜〜</span><span id="884f" class="qv pi io qr b gz ra qx m qy qz">const server = serverless.createServer(app.callback())</span><span id="4871" class="qv pi io qr b gz ra qx m qy qz">exports.handle = function (event, ctx) {<br></br> return serverless.proxy(server, event, ctx)<br></br>}</span>
ポイントはkoaにHTTPをlistenさせないこと。代わりにAmazon謹製の aws-serverless-express を使う。
API本体は変更せずにLambda化できたという事は、ローカルでそのまま動かせる。だからいつもどおりローカルで開発が出来る！すばらしい。
自分は、上記のLambda部分を別のプロジェクトに分離した。そして git submodule でkoaプロジェクトをインポートする構成にした。プライベートnpmレジストリを持っている人なら、koaの方をパッケージ化して使うといいと思う。ローカルで動かしたいときは、koaプロジェクトを直接単体で動かす。
参考までに自分のケースを紹介する。LambdaプロジェクトはApexで管理してる。ディレクトリ構成はこんな感じ：
<span id="e8fe" class="qv pi io qr b gz qw qx m qy qz">.<br></br>├── functions<br></br>│ └── api<br></br>│ ├── node_modules<br></br>│ ├── index.js<br></br>│ ├── lib -> ../../src/lib<br></br>│ └── package.json<br></br>├── project.json<br></br>└── src (git submoduleで追加したkoaプロジェクト)</span>
functions/api/lib はwebpackでビルド済みのjsファイルが格納されたディレクトリへのシンボリックリンク。 functions/api/package.jsonはLambda上での実行に必要な依存モジュールの定義。このディレクトリ配下で予め npm installしておく。 package.json の内容は以下の通り：
ちなみに formidable は koa-body の依存モジュールだけどwebpackでうまくバンドル出来なかったから外に出した。
こんな感じで、従来のkoaアプリにLambdaを薄く被せたシンプルな構成に落ち着いた。
Lambdaって小さなfunctionをたくさん用意して使うものだというイメージがある。今の構成だと、１つの巨大なfunctionに全部やらせている。この使い方はアリなんだろうか？結論としては、アリだと思う。
Lambdaはコンテナベースで出来ていて、functionが呼ばれるとS3からプログラムのzipファイルを引っ張ってくる。そしてコンテナを作ってそれを走らせる。しばらく呼び出しが無ければコンテナはパージされる。動作時間のボトルネックはfunctionのファイルサイズとkoaの初期化だろう。
Inkdropのケースでは最初、functionのサイズが未圧縮状態で47MBにもなった。 node_modules がデカい。余計なファイルが入ってるからなぁ。zip後は8MB。さて、これを試しにデプロイしてAPIを叩いてみた。Lambda上ではコンテナが起動して最初の応答処理が完了するまでどれぐらいかかるだろうか？結果は 9秒。うーん、遅い。リージョンは us-east-1 で、ネットワーク遅延も含める。以下のログの通り、functionの動作自体は0.5秒と短い。やはり巨大なfunctionの読み込みに時間がかかっているようだ。
<span id="9ff9" class="qv pi io qr b gz qw qx m qy qz">Duration: 562.88 ms Billed Duration: 600 ms</span>
node_modules のファイルを全部ブッ込んでるのがいけないので、webpackで使用ファイルだけをバンドルに含めてみた。さらに aws-sdk を同梱しないようにした。実は、Lambdaのコンテナには標準でこのAWS SDKがインストールされてるらしい。だからfunctionに入れなくて良い。このSDKはlodashと依存関係があってとても大きいので、かなり削減できる。webpackで以下のように記述すればOK。
<span id="68c8" class="qv pi io qr b gz qw qx m qy qz">export default {<br></br> ...<br></br> externals: [ 'aws-sdk' ],<br></br> ...<br></br>}</span>
最終的にfunctionのサイズはzip後 580K まで縮小できた。その結果、コンテナ起動も合わせたレスポンス速度を2〜3秒程度にまで短縮できた（波があるけど・・）。これなら許容範囲。
コンテナは一度起動したら、すぐにはパージされずしばらく常駐する。その長さは公式で発表されていないけど、少なくとも10分は走ってる印象。Inkdropでは既に一定のユーザからAPIが呼び出されている状況だから、常にコンテナが一つ動いている状態になりそう。仮にコンテナがパージされても、起動を待たされる人は確率的にも少ない。
サーバレスの仲間として now というものもある。こちらは package.json や Dockerfile を持つプロジェクトをコマンド一発でデプロイできるサービス。負荷に合わせてインスタンスを自動でスケールしてくれる。
今回、AWS Lambda依存部が切り離せたおかげで、こういう他のインフラサービスにも気軽に乗り換えられる可能性が保持された。気が向いたらこっちも使ってみたい。
以上、Inkdropサーバレス化の作業記録でした。
