ERPの開発をしている 株式会社ワークスアプリケーションさんでの事例です。
どちらかというとエンタープライズ向けっぽい会社さんですね。
ClosureコンパイラをLambda上に載せる、VPC多用の必要がどうしてもある、あたりがならではという感じで面白かったです。

事例

• 画面の高速描画のための前処理

問題

• HTML,JS,CSSの最適化
• HTMLテンプレートの事前コンパイル
• よくある構成
  • Hadoop,Spark,インスタンス並列化
  • ガチでやると100時間
  • 長い!コスト高い!
  • 終わらないインスタンス最適化作業
  • 10分で支度しな(意訳)

そこでLambda

Lambdaの特徴

• スケーリング管理コスト0
• インスタンス管理コスト0
• 100ms単位の課金
• 選べるランタイム / 箇所ごとに柔軟に言語を選ぼう
• 流動的な分散数と処理時間にマッチ
  => やってみようと思った

Lambda

• Before: 以前の処理
  • javaのwebフレームワークが画面のリストを作成/HTMLを最適化/jsのコンパイル/cddのコンパイル
  • この辺のフローが同期的
  • 画面が大きくなるとスケールしない
  • Closure CompilerをSpringFWで動かしていた
  • Less(CSS)コンパイル => SpringFW上で動作
• After: 最適化
  • jar作成時にコードにキャッシュしとける情報はする
  • HTMLを最適化するだけのfunctionとして整理
  • GoogleClojureコンパイラ単体で動作するFunctionに
  • LessのコンパイルのFunctionはnodejsとして分離

SpringFrameworkをLambdaで動かすか否か

• ガチで動かすと占有時間が長い
  • => そこでコンストラクタだけを使う
• コンテナのコールドスタートも適切に利用
  • => 初期化処理にシングルトンを利用して余計な処理を省く

起動とプロセス管理

• S3にファイルをputすることで処理を与える。
• 実行ファイル名のサフィックスで処理の分岐を行う
• ピタゴラ処理のエビデンスにPending,RunnningなどステータスをS3に随時吐く(!)
• 進捗はs3上に置いたプロセス進捗ファイルだけをlistすることで確認する

Trouble Shooting

• 速度は思ったより早くない
  • 128MB => 1546MB
  • CPUパワーはメモリ容量に比例 1.5GBだと2コア/3コア利用可能
• 同時実行数上限3000で運用
  だが、実行数が上がらない,なぜ。。。 => VPCのせい

• Lessのコンパイルがエラー

  • Lambdaの起動よりS3のPut時間が後の場合があった <= !?
  • s3のイベントを使う場合は結果整合性であることを忘れないように
• s3のイベントが登録されていない
  • Ansibleで1つのbucketに100Function設定しているはず
  • 1この登録を1回回すんじゃなく1度で100イベント登録したらうまくいった
• 想定金額より多い
  • Cloudwatch Logsのログのせい

デプロイ

• nodeはzip,javaはjar
• お客さんごとに別VPC/1bucket。イベント当てるのはAnsibleでやる

まとめ

• 10分半になった!

課題

• 今度はDBがスケールしなくて高負荷に耐えられない問題