APIが増えるたびにLambdaが増える構成で気がついたらLambdaが240個近くになって色々な問題が出てきたのでLambdaを段階的に1つにまとめた話 by doriven

■ 発表カテゴリ

• Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）

MOSH株式会社(以降MOSH)はAPIの実行基盤としてAWS APIGateway + Lambda + DynamoDB で動作し、SeverlessFrameworkで管理される形が取られている。
この構成のまま創業当初から継続して拡大したことでAPIの数は執筆時点で240個ほどに膨らみ、数が増えるにつれて様々な問題が起こった。
それらの問題を受けてMOSHでは現状の技術基盤が負債になっていると判断しAPIの実行基盤をLambdaからECSに移行するために基盤の改善を行うことにした。
その移行過程としてLambda-lithという1つのLambdaで複数のエンドポイントを捌けるアーキテクチャを採用し、APIに関するLambdaの数を減らす動きをしている。
本稿ではLambda-lithを採用するまでの技術的な意思決定の事例を紹介し、その後の複数のAPIのLambdaを1つにまとめてどのように移行したのかという実施方法とそれによって得た知見について話をする。

■ 発表の詳細（1000字程度）

MOSHは「情熱をめぐる経済をつくる」をミッションにクリエイターがWeb上に店舗を作成し、スケジュールのマッチングやスキル・コンテンツの販売、会員向けページなどを提供しているWebサービスである。

MOSHはAPIの実行基盤としてサーバーレスアーキテクチャを採用しており、AWSサービスのAPI Gateway + Lambda + DynamoDBを組み合わせてバックエンドが構成されている。
またSeverlessFrameworkをIaCとして採用しており、Lambdaに関わるリソースがServerlessFrameworkを通して作成されたCloudFormationで管理されている状況になっている。

創業当初から上記の実行基盤と管理構成のまま継続して拡大したことでAPIの数が増えるにつれてLambdaの数も増加し(執筆時点で240個、API以外のものも含めると300個程度)して以下のような問題が起こった。

• CloudFormationのQuotasの上限に到達しデプロイができない
• 監視SaaSのコストの肥大化
• Lambdaのコードが肥大化することでZipのサイズ上限を迎えることになってデプロイができない
• ColdStartによるAPIの速度の低下

これらの問題に対応するためMOSHでは技術基盤が負債になっていて今後のプロダクト開発の足かせになると判断しAPIの実行基盤をLambdaからECSに移行するために基盤の改善を行ってきた。
その移行過程としてLambda-lithという1つのLambdaで複数のエンドポイントを裁けるアーキテクチャを採用した。
Lambda-lithとはHandlerを直接呼び出すのではなく、WebFrameworkがルーティングできる形に変換して1つのLambdaで複数のエンドポイントの動作を実現することが出来る。
(参考 https://docs.aws.amazon.com/lambda/latest/operatorguide/monolith.html https://aws.amazon.com/jp/blogs/news/comparing-design-approaches-for-building-serverless-microservices/)

Lambda-lithを動かすフレームワークとして我々はFastAPIを採用し、handler側で行っていたリクエストのバリデーション・変換をコントローラー層に実装して従来のユースケース層以下を変更しないように移行を行った。
当日はフレームワークなどの技術の比較検討の判断軸やどのような意思決定を行ったのかに触れつつ、Lambda-lithへの段階的な移行の方法について具体的な話をする。

■ 対象聴衆とその人たちが得られるもの

• 対応聴衆

  • AWSクラウドでAPIの実行基盤にLambdaを採用し、サービスの成長に伴い大量のLambdaを抱えているSRE・インフラエンジニア
  • Lambda-lithを採用しようとしているバックエンドエンジニア

• 得られるもの

  • 複数のLambdaハンドラをLambda-lithに移すための知見
  • API毎に乱立しているLambdaをまとめて管理・監視SaaSのコストを下げるための手法の知見

■ なぜこのトピックについて話したいのか（モチベーション）

サーバーの管理コストを下げるためにサーバーレスアーキテクチャを採用している企業は数多くあるものの、300個近くのLambdaを管理している企業はおそらく他にあまり例がないのではないかと思います。
MOSHの事例を発表することで今後APIの実行基盤としてLambdaを採用も考慮に入れている方々の判断の一助になることや、多数のLambdaを管理している基盤チームに移行の1つの事例として参考になるのではないかと考え応募しました。