400超Lambda構成アプリケーションの漸進的リアーキテクチャ

2025-03-07「事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線」のLT資料です。

Transcript

1. Shodai Suzuki @SoartecL 事業成長を加速する技術基盤 5社が語る リプレイス・リアーキテクチャの最前線 2025.03.07 400超Lambda構成アプ リケーションの漸進的 リアーキテクチャ
2. 鈴木翔大 X @SoartecL ソフトウェアエンジニア Productivityチーム( 技術 基盤チーム) 趣味 OSS Orvalメンテナ ダイビング
3. 今日話す事・話さない 事 既存のアーキテクチャで 抱えていた課題 運用で発生したトラブル 課題に対する解決策とし てのリアーキテクチャ 話すこと フロントエンドを含む技 術課題の全体像 リアーキテクチャ時の技 術的なとラブルシュー ティングなどの詳細 話さないこと
4. 既存のバックエンドアーキテクチャ
5. 既存アーキテクチャ Amazon Cognitoで認証 API Gawatewayと組み合わせ認可 APIのエンドポイント毎にlambda 関数を管理 e.g. GET /users, POST /users API Gateawayが複数 severless(CloudFormation) でリソース管理している CloudFormationの定義リソー ス数に上限(500/stack)がある API Gawateway + Lambdaを 特定のまとまりでスタック分割
6. 既存デプロイ GitHub Actionsでserverlessコマ ンドを実行 serverlessでpythonのコードを zip serverlessで他のAWSリソースと 一緒にLambdaをデプロイ この一連がの一つのパイプライン
7. 抱えていた課題例 ローカル開発環境 デプロイの安定性 デプロイ時間 インフラリソースの管理が分散 インフラとアプリケーションの同時リリースが強制される コールドスタート時の低レイテンシ Lambdaの数に比例する監視ツールのコスト増加 新しい動作確認環境を作ろうとすると更にLambdaを同じ数増やす ことになる ログや認証認可などミドルウェアの実装が難しい
8. リアーキテクチャ計画 →
9. ソースコード、実行基盤、インフラ の密結合による移植性が課題
10. 移植性(ポータビリティ) “一つのハードウェア、ソフトウェア又 は他の運用環境若しくは利用環境からそ の他の環境に、システム製品又は構成要 素を移すことができる有効性及び効率性 の度合い。 ” ※1 ※1 引用文献: https://kikakurui.com/x2/X25010-2013-01.html「JIS X 25010：2013 (ISO/IEC 25010：2011) 図4−製品品質モデル 」
11. 移植性(ポータビリティ) の課題 1つのpythonコードzipして個々の lambdaにデプロイ serverlessにまとめていることで インフラ管理とアーティファクト のビルド・デプロイパイプライン が同じ アプリケーション内のhandlerの実 装と実行基盤としてのlambdaが密 結合 lambdaがapi gatewayに依存して おりapi gatewayからのリクエス トしか処理できない
12. 密結合を解き移植性を向上する 漸進的リアーテクチャ
13. その間にもアプリは育ち、、、
14. ✖︎ 400 = yabai
15. 計画通りとは行かずに、 Xデーは突然・・・
16. 事件① Lambdaアーティファクトの上限サ イズ制限でデプロイできなくなった 当時のslack
17. 事件①はなぜ起きたのか コード全体をzipしたアーティファクトを 全てのLmabdaで共有している アプリの成長に伴いアーティファクトが肥大化 上限サイズ制限(zip圧縮後50MB)に達して デプロイ不可能に
18. 事件② CloudFormationのリソース上限に よりデプロイできなくなった (事件①の翌月に発生 😇) 当時のnotion
19. 事件②はなぜ起きたのか インフラ管理にserverless(CloudFormation)を 使っている CloudFormationには定義リソース数上限(500/ stack)がある これまでもスタックの分割を行っていたが上限に達 してデプロイ不可能に
20. ここまでの 課題整理 開発課題 コールドスタート時のレイテ ンシやコスト増加 サービス運用課題 限界突破！！ 度重なるデプロイ不能 1 2 3 ローカル開発環境やデプロイ 時間、安定性などによる開発 時の課題
21. 密結合を解き移植性を向上 + 緊急課題の解決する 漸進的リアーテクチャ
22. ステップ1: Lambdaアーティファ クトDocker化 Lambdaのアーティファクト形式 をzipからDocker imageに変更 GitHub ActionsでDockerイメージ をbuildしてECRにpush Docker imageのイメージ上限サイ ズは10GB (zipは圧縮後50MB) 上限が上がった事でデプロイ可 能になった ↓
23. ポータビリティ(移植 性)の向上 🎉 アーティファクトのビルドが1連の パイプラインから独立 Dockerコンテナが動けば実行基盤 自体は交換可能に ↓
24. 副次効果: コールドスタート時の 起動時間も削減 🎉 起動時間が20%削減 (グラフ①の赤い部分) 起動時間も安定 (グラフ②の水色の線グラフ) グラフ① グラフ②
25. 事件① Lambdaアーティファクトの上限サ イズ制限でデプロイできなくなった 問題を解消 ✅
26. ステップ2: OpenAPIの整備 元々12,000行のyamlがあった yamlを修正、構造化 エンドポイント毎の定義をpathsに配置 リクエスト/レスポンス型をschemasに 配置 openapi.yaml内でURLとpathsをマッ ピングする
27. ポータビリティ(移植性) の向上 🎉 OpenAPIからFastAPIの Controllerレイヤーのソースコー ドが自動生成可能(交換可能)になっ た lambdaに密結合していたアプリ ケーションが「シンプルな FastAPI」として切り出し可能に なった
28. ステップ3: Lambda-lith API Gatewayのルーティングを複 数Lambdaから1つのLambdaに集 約 FastAPIを導入してLambda内で APIをルーティング CloudFormation管理リソース数 が減りAPI Gatewayの分割も不要 になった CloudFormationでの管理リソー ス数が減りデプロイ可能になった ↓
29. Lambda-lithの選定 AWSのDeveloper Guide※1 では イベントドリブンのAnti-patterns として紹介 AWS Compute Blog※2 ではサー バーレスマイクロサービスの設計 アプローチの1つとして紹介 ECS/EKSへの移行を予定している ためステップを踏むために採用 まずは「FastAPIが動いている Dockerイメージ」を目指す シンプルな構成でLambdaで動 かした後ECS/EKSへ移行する Anti-patterns in Lambda-based event-driven applications 「Understanding events and event-driven architectures」※1 ※1 引用文献: https://docs.aws.amazon.com/lambda/latest/dg/concepts-event-driven-architectures.html#monolith ※2 引用文献: https://aws.amazon.com/jp/blogs/compute/comparing-design-approaches-for-building-serverless-microservices/ many development teams move in the opposite direction, aggregating all code related to an API inside the same Lambda function. 「Comparing design approaches for building serverless microservices」※2
30. ポータビリティ(移植性) の向上 🎉 「FastAPIが動いているDockerイ メージ」というポータビリティに より、ローカル開発環境では FastAPIアプリとして開発が可能 インフラとアプリのデプロイ分離 が容易になった 分離する事でデプロイ時間の短 縮が可能 CloudFormation起因のデプロ イの不安定を回避 FastAPIによりログや認可などのミ ドルウェアの実装が容易になる ↓
31. 副次効果: 平均レイテンシ削減 🎉 Lambdaが複数のリクエストを受 け付ける事で、常時コンテナが起 動する状態になりコールドスター トの発生頻度が低下 コールドスタートという外れ値が 少なくなる事で平均レイテンシが 改善 平均レイテンシ① 平均レイテンシ②
32. 副次効果: コスト改善 🎉 コールドスタートが減ったこと で、lambda全体の使用時間とコス トを削減 Lambdaの数が減る事で監視対象 が減り監視ツールのコストも削減
33. 事件② CloudFormationのリソース上限に よりデプロイできなくなった 問題を解消 ✅
34. リアーキテクチャのステップまとめ 1. Docker化 2. OpenAPI整備 3. Lambda-lith化 4. ECS/EKS化
35. 今後のステップ
36. ステップ4: ECS/EKS移行 「FastAPIが動いているDockerイ メージ」というポータビリティの 高さを手に入れた 実行基盤をLmabdaからECS/EKS どちらかに移行する API GatewayからELBに変更 コンテナからCognitoにアクセスし て認可処理 (Cognitoも脱したい) ↓
37. ステップ5: リソースサーバの1つ として保守可能にする 既存のAPIサーバーはリソースサー バーの一つとして管理 オールインワンプロダクトの MOSHでは適切に境界付けられた リソースサーバーが増えてく事を 想定 ↓
38. 今後のリアーキテクチャのステップ 1. Docker化 2. OpenAPI整備/3. Lambda-lith化 4. ECS/EKS化 5. リソースサーバー化
39. 漸進的なリアーキテクチャで 事業成長に更なる加速 を！！
40. おわり