導入経緯
エキサイトのLife&Wellness事業部でエンジニアをしている坂本です。
海外出身なので不自然な日本語があればお許しくださいm(__)m
L&W事業部では初めてサーバーレスアーキテクチャを導入したのは、2019年10月にリニューアルを行ったcocorus（ココルス）の開発でした。当時はElastic TranscoderやMediaConvertなどAWSのElementalシリーズを利用したいきっかけに、Step FunctionsやLambdaなどサーバーレスアーキテクチャでメディア変換システムを構築しました。
2020年に恋ラボのチャット相談機能の開発で初めて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をサポートしました。これでローカル環境で開発からAWSへのデプロイまで一気通貫で作業ができます。
次回からはAWS SAMの導入について、紹介したいと思います。
- SAM CLIによるAWSサーバレス構築
- AWS SAMをローカルDockerコンテナ上で動かす
サーバーレス導入のメリット
インフラ運用の簡素化
サーバーの運用が不要になります。開発現場では、今までTerraformやCFnでサーバー構築とAnsibleなどでパッケージ管理が必要ですが、SAM導入によって単独プロジェクトで簡潔化できます。柔軟なスケーラビリティ
中心となるLambdaはリクエストの処理中に関数が再度呼び出されると、別のインスタンスが生成されます。そのため、事前に必要なキャパシティを考慮しなくても、リクエスト数や負荷によって自動的にスケーリングされます。利用した分だけの課金
常駐サーバーのコストがかかり続けるようなことはなく、コードが実行された分だけ課金されます。マイクロサービスの実現
Step Functions、Lambdaなど導入によって、視覚的なワークフローで迅速かつ簡単に構築できます。
サーバーレス導入のデメリット
-
実行時間や消費可能リソースの制約
Lambdaリソースはいくつか制約があります。詳細はAWS Lambda のクォータに記載しています。例としては、- 最大実行時間が15分なので、実行時間が15分以上のバッチに向いていない
- 割合可能メモリが3,008MBなので、メモリに大量のデータを詰め込むことができない
- tmp領域の制限が512MBなので、処理中に一時的に巨大なファイルを書き出すのができない
ベンダーロックインのリスク
AWS SAMで一度開発したモノを他クラウドベンダーへ移行するのは困難になります。例えば、Step FunctionsはAWS独自のステートメント言語を採用していますので、他のクラウドベンダーに移行ハードルが高い。コールドスタート問題
コールドスタートによるLambda関数実行までの遅延問題がありますので、定常にアクセスが発生しないシステムはパフォーマンスの最適化が困難の場合があります。
エキサイトでサーバーレス導入の事例
新たなエコシステム
S3バケットが単なるストレージサービスではなく、高速なWEBサイトホスティング機能を持っていますので、そのままWebサイトとして公開ができます。この場合は、静的ウェブサイトのホスティングと呼ばれます。
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導入にいたりました。
GOOD POINT
- マイクロサービスっぽいの仕組みなので、複数のメンバーにタスクを分散できます。
- 実際に入稿ツールから入稿用のS3バケットにアップするだけで、その後はコンテンツ変換モジュールに任せますので、優先度が高いコンテンツ変換モジュールを先に開発して、優先度が低い入稿ツールの開発を後回しにしました。それにより、サービス本体の開発に集中できました。
- バッチサーバー維持が不要で、コンテンツ変換で使った分だけ料金を支払っています。サーバー不要なので、安定的に運用できます。
BAD POINT
- Lambdaのtmp領域の制限が512MBなので、直接にLambda上に巨大なファイル扱い（暗号化）できない
- Lambda Layer導入していますが、当時にAWS SAM導入しなかった（導入してもStep Functionsサポートしない）や、Cloud9もLambda layerをサポートしないなど、開発環境として未熟な部分がありました。
最後に
今回はエキサイトでAWSサーバレス導入経緯と事例を軽く紹介しました。サーバレスアーキテクチャは非常に良い場面もあると思います。
エキサイト株式会社では随時に仲間を募集しております。