AWS LambdaとNode.jsを使ったAIソリューション作り方（後編） #AWS

AWS Lambdaの制限事項

　AWS Lambdaは通常のサーバと違い、幾つかの制約条件があります。まず、OSをセットアップできないため細かいコントロールが出来ません。あくまでAmazonが決めたルールに従うのみです。実行環境はそれぞれの言語毎に指定されたバージョンしか使えません。
　そのため最新型で動かしたいなどの要望には答えることが出来ません。メモリは現在最大3GBまで使えますがそれ以上は増設できません。
　基本的にプログラムファイル以外はS3などのLambda以外に保存して置き、トリガーとして利用したりします。
　データベースも当然入っていないので、DynamoDBなどのサービスを呼び出します。これでおわかりだと思いますが、LambdaはあくまでCPUとして使います。あとは外部のストレージサービス、データベースサービス、通知サービス、メッセージサービスなど機能毎にAPIで接続していく、APIエコシステムの中心的なサービスなのです。
　そのため、あえてフル機能を実装していません。そこがいいところでもあり、簡単なプログラムをさくっと動かせるポイントでもあります。

Lambdaのハマリポイント

私がLambdaを使っている中でハマったポイントを幾つか説明します。まず、外部のSDKを入れるためにはフルパッケージをPCのローカル環境などでダウンロードしておき、それをまるごとアップロードする必要があります。
そうした時、問題があってWebUIからは50MB制限が掛かるということです。50MB以上はアップロードできません。50MB以上をアップしたい場合はS3経由でアップするかCLIツールからアップするなど少し面倒になります。
そのため、SDKを同時にアップロードする場合は、SDKの中身を精査し必要なものだけに制限する必要がありました。そして、デバッグがウェブ上でしかわからないため何が問題なのかが見えづらいというのがあります。
その他、ハンドラと呼ばれるトリガーネームがありますが、これは実行ファイル名を指すわけですが、ZIPで保存してアップロードするときに、何かフォルダを一つ作ってその下に入れてしまうと、上手く認識できないというディレクトリ構造問題に行き着きます。
その為、圧縮するときは実行ファイルと、SDKフォルダは同一ディレクトリ上（例えばデスクトップ上など）で、そのまま圧縮すべきです。
こういう「作法」を理解した上で実行していく必要がありますが、実行ファイルの関数名などに制限は無く、柔軟に書けるのは良いのですが、JavaScriptなどは一般的な書き方とLambdaではほんの少しだけ書き方が違うため、そこでドハマリしていました。
さらに、短期間で大幅なアップデートがなされる事があり、マニュアル通りにやっても違う減少が発生したりもしたので、常に自分で考えながら動かす癖が必要です。

実際のコードを見てみる

それでは、実際にLambdaに実装したコードを以下に表してみます。
すべてを書くと、冗長になるので、形態素解析しキャラクターが何を話し、同行動したのかを切り出すためのコードです。

node.js

'use strict';

exports.handler = function(event, context, callback) {
  var language = require('@google-cloud/language')({
    projectId: 'story-analytical-engine',
    keyFilename: 'config/keygcp.json'
  });
  var document = language.document(event.text);
  document.annotate({verbose: true},
    function(err, annotation) {
      if (err) {
        callback(err);
      } else {
        callback(null, annotation);
      }
  });
}

上記のように、APIを読み出しているだけですが、中継するだけならごくシンプルな実装で、あとはライブラリにおまかせすることが出来ます。
また、もちろん、この後ろにEC2を実装したRuby on Railsプログラムがあり、判定用のアルゴリズムが動くわけですが、形態素解析と感情算出という膨大な演算を外部サーバに任せるときに、既存のサーバをいじらずサーバレスでサクサクとアドオンを作れるのはとても便利だと思います。

まとめ

　さて、前編と後編を通して感じたことですが、最近のクラウドサービスは組み合わせ次第でかなり出来ることが増えたなと思いました。また、簡易的に実装したいという場合も、サーバの中からサーバの外という選択肢が増えたことで、自由度が増し、検討時間も実装時間も大幅に短縮することで、ユーザーテストまで持っていくまでのリードタイムが圧倒的に短縮できていると思います。
　このように、道具だと割り切ってうまくLambdaなどのサーバレスアーキテクチャを利用し、マルチクラウドの実装を試してみて下さい。