SRE Kaigi 2025
300超のLambdaから構成される8年物のサーバーレスアプリケーションをリアーキテクチャしている話
鈴木翔大
SoartecL
■ 発表カテゴリ
募集要項（リンク）にある6つの発表カテゴリからお選びください
- Architecture: SREの視点からのシステム設計
- Case Studies: 実際の導入事例や失敗談
■ 発表概要（400字程度）
MOSHはクリエイターエコノミー市場において、クリエイターの業務を円滑にし事業成長を手助けするオールインワンサービスです。クリエイターの事業は多種多様なため、サービスの初期開発においてはトライ&エラーを繰り返す必要があり、サーバーレスアーキテクチャを採用しています。サーバーレスの恩恵を受け、運用コストを低減させ、素早い機能開発を実現した結果、前年同期比率3倍という成長を達成しました。しかし、サービス運営から8年が経ち、Lambdaの数も300を超え、様々な問題が顕在化しています。本発表ではこれまでのバックエンドアーキテクチャと顕在化している課題、そして現在行っている対策についてお話しします。
■ 発表の詳細（1000字程度）
これまでのMOSHサービスのバックエンドアーキテクチャ MOSHサービスのバックエンドは以下のサービスを組み合わせたサーバーレスアーキテクチャにより構成されています。
- Amazon Cognito
- Amazon API Gateway
- AWS Lambda (Python)
- Amazon DynamoDB
これらの技術スタックはサービス初期において運用コストを低減し、素早い機能開発を支援しました。しかし、サービス運営から8年が経ち、Lambdaの数も300を超えており、様々な問題が顕在化しています。
■ 顕在化した課題
実際に顕在化した課題は以下の通りです。
- アーティファクト肥大化によるコールドスタート時のレイテンシ
- CloudFormationのリソース上限数に達し、デプロイができなくなった
- ZIP形式のLambdaアーティファクトのサイズ上限に達し、デプロイができなくなった
- 監視SaaSの課金体型がLambdaの数に比例するためコストが増加
これらの課題に対して、我々は半年にわたり改善を行っています。
■ 対応
以下のような対応を行っています。
- アーティファクトのDocker化
- 上限サイズが緩和されるため
- Lambda-lith化
- これまではAPI Gatewayから直接Handlerとして各Lambdaを呼び出していましたが、1つのLambdaに対してFacadeとしてのLambdaを設置しています。
- RouterとしてFastAPIを使っています。
- 参考: https://aws.amazon.com/jp/blogs/news/comparing-design-approaches-for-building-serverless-microservices/
■ これからのアーキテクチャ
- まずはシンプルなFastAPIとしてLambda-lithで動かすことにより、CloudFormationのリソース上限やコールドスタートの問題を解消します。
- 次にコンテナ技術をさらに活用するために、Amazon ECS・Amazon EKSへの移行を検討。
- Docker上にFastAPIアプリが動いているシンプルなアプリケーション構成に移行した事で選択が視野に入ってきました。
■ 対象聴衆とその人たちが得られるもの
- 成長期に300のLambdaを使用したWebサービスのリアルな問題と対応事例を知ることができます。
- サービス初期に活用したサーバーレスアーキテクチャに対し、今後のスケーラビリティを確保するためのアーキテクチャ変更の事例を知ることができます。
■ なぜこのトピックについて話したいのか（モチベーション）
サーバーレスアーキテクチャを活用して高い生産性を得ているプロダクトは多いと考えています。
私自身も、300のLambdaを使用したWebサービスの運営に携わるのは初めてであり、多くの新しい学びがあります。
一方で、類似の事例やスケーラビリティを得るためのアーキテクチャの事例はまだ少ないと感じています。私たちが直面し、学んでいることが、皆様のお役に立つ事例になるのではないかと考え、応募に至りました。