CROSS 2017 の 「Serverless Ninja Warriors」 のセッションのスピーカーとして参加してきました！

AbemaTV 広告局では、営業支援が目的の「プランニングツール」や番組とCM（番宣）の最適化システムにサーバーレスを導入しています。具体的にどのような形でサーバーレスを導入しているかCROSS 2017の 「Serverless Ninja Warriors」 で発表させていただきました。当日公開した資料だけでは、情報が足りずわかりにくいかと思いますので解説致します。

当日公開した資料

 

システム構成について

デプロイ

基本的にコンパイルやデプロイはjenkinsを利用しています。jenkins上から「DEV環境」、「STG環境」、「PRD環境」へリリースします。jenkinsを利用した理由は、使い慣れているという点と、テストコードの一部が別システムの変更検知等も兼ねていたり、モック化していないRDSのテストコードがあったり等、他のCIツールを利用したときの壁になりそうだったため、jenkinsを利用しました。環境依存の設定は、それぞれのconfigを保持し、デプロイ時のパラメータで切り替えるようにしています。

サーバーレスでは推奨されていないRDSを利用

RDSを利用していますが、これにはいくつか理由があります。
一つは、BIツール利用している点（tableauを利用しているのですが、tableauはDynamoDBも参照することもできるためRDSが絶対ではありませんが複雑なクエリを必要とする場合はやはりRDSの方が良いと思います）、もう一つは、大規模な視聴ログのサマリデータを集計する点です。UU数の計算等条件に応じて集計する必要が毎回発生するためDynamoDBだと難しいと判断しました。

ちなみに、RDSを選択してしまうとコネクション数が有限であるためスケールに限界がきてしまいますが、今回は社内向けシステムであり、最大同時接続数の見積りも可能であるため問題無いと判断しました。一応、ロック待ちが発生して複数回APIが実行される可能性も考慮し、１リクエストで発生するトランザクションにおいて他のリクエストが依存しないようイミュータブルなDB設計にしています。常にレコードはINSERTのみで削除やUPDATEの処理は発生しないようにしています。

ソースコードについて

基本的なところ

サンプルコードですが、基本的なコードは同じで、ルーティング的なロジックは存在せず、Serverless Frameworkの設定（serverless.yml）上で、APIと対になる形で関数まで指定しています。狙いとしては、ルーティング処理等共通的なクラスを存在させないことでコンフリクトが発生しそうなところやテストが書きにくいところを極力排除しました。

Scalaの他にもNode.jsを利用

主に、Scalaがメインとなっています。そのためNode.jsと比較すると立ち上がりが遅いためホットスタンバイ状態を維持するため５分おきにlambdaに対してinvokeを実行しています。Scala側をメインとした理由は、ループ処理や計算処理が書きやすいという点とテストコードが書きやすい（DIを利用できる）という点です。ただし、一部、HTMLを操作する部分や簡易的な通知部分についてはNode.jsを利用しています。Serverless FrameworkではFunction毎に言語を指定することができるためAPI毎に適材適所な言語を選択することが可能です。

私の資料の補足としては以上となります。

今回のセッションではディスカッション形式で他の方々の拘りの「サーバーレス」について、使い方や構成管理、課題点等々聞けて非常に勉強になりました。「Serverless Ninja Warriors」で検索していただければ、当日スピーカーに参加していただいた方のまとめが見つかるかと思います！