search
LoginSignup
2

More than 1 year has passed since last update.

posted at

updated at

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

導入経緯

エキサイトの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サイトとして公開ができます。この場合は、静的ウェブサイトのホスティングと呼ばれます。
sam02.jpg

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

GOOD POINT

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

BAD POINT

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

最後に

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

エキサイト株式会社では随時に仲間を募集しております。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
2