開発現場でAWSサーバーレスを導入しました

# 導入経緯
エキサイトのLife&Wellness事業部でエンジニアをしている<strong>坂本</strong>です。
海外出身なので不自然な日本語があればお許しくださいm(__)m

L&W事業部では初めてサーバーレスアーキテクチャを導入したのは、2019年10月にリニューアルを行った[cocorus（ココルス）]( https://cocorus.excite.co.jp/)の開発でした。当時はElastic TranscoderやMediaConvertなどAWSのElementalシリーズを利用したいきっかけに、Step FunctionsやLambdaなどサーバーレスアーキテクチャでメディア変換システムを構築しました。

2020年に[恋ラボ](https://koilabo.excite.co.jp/help/chat/)のチャット相談機能の開発で初めてAWS SAMを導入しました。個人的にAWS SAMが良いサーバーレスフレームワークだと思います。

# AWS SAMについて
AWS SAM（Serverless Application Model）は、AWSサーバーレスアプリケーション構築用のオープンソースフレームワークです。CloudFormation(以下 CFn) のテンプレートを使用していますが、普通のCFnより圧倒的に初心者に優しいと感じます。

当時にCocorusでStep Functionsを導入した際にAWSコンソール上に直接にステートマシンを書きましたが、2020年5月から[AWS SAMがStep Functionsをサポートしました](https://aws.amazon.com/jp/about-aws/whats-new/2020/05/aws-sam-adds-support-for-aws-step-functions/)。これでローカル環境で開発からAWSへのデプロイまで一気通貫で作業ができます。

次回からはAWS SAMの導入について、紹介したいと思います。
- [SAM CLIによるAWSサーバレス構築](https://qiita.com/h-sakamoto/items/9a8493eb386372ceee2a)
- [AWS SAMをローカルDockerコンテナ上で動かす](https://qiita.com/h-sakamoto/items/65145d912f7c9138b870)

# サーバーレス導入のメリット
- **インフラ運用の簡素化**
サーバーの運用が不要になります。開発現場では、今までTerraformやCFnでサーバー構築とAnsibleなどでパッケージ管理が必要ですが、SAM導入によって単独プロジェクトで簡潔化できます。

- **柔軟なスケーラビリティ**
中心となるLambdaはリクエストの処理中に関数が再度呼び出されると、別のインスタンスが生成されます。そのため、事前に必要なキャパシティを考慮しなくても、リクエスト数や負荷によって自動的にスケーリングされます。

- **利用した分だけの課金**
常駐サーバーのコストがかかり続けるようなことはなく、コードが実行された分だけ課金されます。

- **マイクロサービスの実現**
Step Functions、Lambdaなど導入によって、視覚的なワークフローで迅速かつ簡単に構築できます。

#サーバーレス導入のデメリット
- **実行時間や消費可能リソースの制約** 
Lambdaリソースはいくつか制約があります。詳細は[AWS Lambda のクォータ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html)に記載しています。例としては、
 - 最大実行時間が15分なので、実行時間が15分以上のバッチに向いていない
 - 割合可能メモリが3,008MBなので、メモリに大量のデータを詰め込むことができない
 - tmp領域の制限が512MBなので、処理中に一時的に巨大なファイルを書き出すのができない  
 


- **ベンダーロックインのリスク**
AWS SAMで一度開発したモノを他クラウドベンダーへ移行するのは困難になります。例えば、Step FunctionsはAWS独自のステートメント言語を採用していますので、他のクラウドベンダーに移行ハードルが高い。

- **コールドスタート問題**
コールドスタートによるLambda関数実行までの遅延問題がありますので、定常にアクセスが発生しないシステムはパフォーマンスの最適化が困難の場合があります。

#エキサイトでサーバーレス導入の事例
##新たなエコシステム##
S3バケットが単なるストレージサービスではなく、高速なWEBサイトホスティング機能を持っていますので、そのままWebサイトとして公開ができます。この場合は、静的ウェブサイトのホスティングと呼ばれます。
![sam02.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/536217/9a4a57ec-c808-616d-5bbe-d9aa527387fd.jpeg)

###**GOOD POINT**###
- Apacheやnginxなどの面倒を抱えなくて良いので、運用が楽になります。
- 使った分だけお支払いなので、恋ラボチャットみたいの小規模のプロジェクトなら安い。
- 徐々に人気になっているSPA (Single Page Application)の設計に向いています。

###**BAD POINT**###
- 大量のデータの読み書きのシステムはDynamoDB料金が膨らむことで、逆に安くならない。
- FrontendとBackend分離によって、一般的にFrontend側にVuejsやAngularJsなどのJsフレームワーク採用、Backend側にPythonもしくはNodeJs採用、求めるスキルが違うので開発スピードを出せない場合があります。

##プライベートコンテンツ配信システムのコンテンツ変換##
Cocorus開発では、コンテンツ変換モジュールにサーバレスアーキテクチャを導入しました。当初にストリーミング再生フォーマット（HLS形式）に変換のために、FFmpeg導入の選択肢もありますが、膨大な開発工数をかけたくないので、AWS MediaConvertを選びました。そのきっかけに、MediaConvertと相関性が良いLambda導入になって、Aurora MysqlやS3など他のAWSコンポネント組み込みニーズがありますので、結果的に自然にStep Functions導入にいたりました。
![sam01.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/536217/e22901dc-cad5-9721-ac15-e3b8989bc049.jpeg)

###**GOOD POINT**###
- マイクロサービスっぽいの仕組みなので、複数のメンバーにタスクを分散できます。
- 実際に入稿ツールから入稿用のS3バケットにアップするだけで、その後はコンテンツ変換モジュールに任せますので、優先度が高いコンテンツ変換モジュールを先に開発して、優先度が低い入稿ツールの開発を後回しにしました。それにより、サービス本体の開発に集中できました。
- バッチサーバー維持が不要で、コンテンツ変換で使った分だけ料金を支払っています。サーバー不要なので、安定的に運用できます。

###**BAD POINT**###
- Lambdaのtmp領域の制限が512MBなので、直接にLambda上に巨大なファイル扱い（暗号化）できない
- Lambda Layer導入していますが、当時にAWS SAM導入しなかった（導入してもStep Functionsサポートしない）や、Cloud9もLambda layerをサポートしないなど、開発環境として未熟な部分がありました。

#最後に#
今回はエキサイトでAWSサーバレス導入経緯と事例を軽く紹介しました。サーバレスアーキテクチャは非常に良い場面もあると思います。

エキサイト株式会社では随時に[仲間を募集](https://www.wantedly.com/companies/excite)しております。