[AWS Summit Tokyo 2017 Day3] AWS Lambdaで変わるバッチの世界 – CPUトータル100時間を10分で終わらせるには –

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がスケールしなくて高負荷に耐えられない問題
Pocket

Naoto

Wanoで色々やらしてもらってまう

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です