Lambda Web AdapterでLambdaをWEBフレームワーク利用する

Transcript

1. Lambda Web Adapterで LambdaをWEBフレームワーク利用する
2. 自己紹介 名前 荒川 祥一朗 経歴 SE職 1～2年目はアプリケーションエンジニア 3～5年目はインフラエンジニア 趣味 ラーメン二郎巡りとボイパ（練習中）
3. 今日お話しすること 1. 概要 2. Lambda Web Adapterとは 3. 課題＆解決法 4. まとめ
4. 01. 概要
5. 本セッションの対象者 解決すべき「2つの壁」 1. 実装の壁 Lambda独自仕様への書き換え。ポータビリティの喪失。 2. 環境の壁 ローカルと本番の差異。デバッグ工数の肥大化。 Web開発 インフラに縛られず開発したい方 移行担当 最小限の工数でサーバーレス化したい方 概要：対象者と「2つの壁」
6. 02. LWAとは
7. シームレスな「橋渡し」役 普通のWebサーバー用に書いたコードを、Lambdaという特 殊な環境でそのまま動かせる魔法の変換器 • 既存コードの修正は一切不要 • 任意のフレームワークに対応 Python : FastAPI, Flask Node.js : Express.js, Next.js Java : SpringBoot Rust : Axum Go : Gin • コンテナイメージとしてデプロイ可能 Lambda Web Adapterとは 参照：https://github.com/awslabs/aws-lambda-web-adapter
8. 導入はわずか「1行」 Dockerfileにこの1行を加えるだけで、あなたのWebアプリはLambda関数へと変貌します。 特定のライブラリをインストールする必要すらありません。 あとは通常のコンテナと同様に、Webサーバー（Uvicorn, Gunicorn, npm start等）を起動 するコマンドを記述するだけです。
9. 高い移植性 Fargate等との相互移 行が容易に。 優れたDX ローカルではいつもの Webサーバーとして起 動可能。 コスト最適化 従量課金の恩恵を既存 資産で享受。 LWAがもたらす3つの価値
10. 03. 課題＆解決法
11. メカニズム 一定期間リクエストがないと、実行環境が解放されま す。次回のアクセス時に「コンテナ起動＋Webサーバ ー起動」の待ち時間が発生します。 影響 初回のレスポンスに数秒の遅延が生じるため、常時即 応性が求められるWebサービスでは、UX上の課題とな ります。 唯一の弱点：コールドスタート
12. 運用パターン コールドスタート コスト特性 推奨シーン オンデマンド あり (初回遅延) 完全従量課金 開発環境・小規模ツール Provisioned Concurrency なし (即座に応答) 予約分は固定費発生 本番Webアプリ・性能要件あり 常に立ち上げ状態に Provisioned Concurrencyとは 指定数の実行環境を事前起動・初期化して待機 即座にリクエスト処理でき、レスポンス改善を実現
13. 「予約席」の動的調整 Application Auto Scalingを組み合わせることで、トラフィックに合わせてProvisioned Concurrencyの数を自動増減させます。 「常に立ち上げ」の状態を、最低限のコストで実現可能です。 深夜：0〜1台（コスト最小化） 日中：予測需要に合わせて確保 コスト削減：Auto Scalingの活用
14. サービス Lambda LWA (on Lambda) AWS Fargate 既存コード流用 書き換え必要 そのままOK そのままOK スケーリング ミリ秒単位 ミリ秒単位 数分単位 コスト効率 最高 非常に高い 中 (固定費大) 開発体験 独自の学習が必要 標準的Web開発 標準的Web開発 実行環境の最終比較：LWA vs 他の選択肢
15. 04. まとめ
16. 標準技術への回帰 Lambda特有の作法を捨て、汎用的なWeb開発に集中できます。 開発体験(DX)の向上 ローカルと本番の差異をゼロにし、テストやデバッグの工数を削減します。 戦略的なポータビリティ Lambda / Fargate 等を自由に行き来できる設計を可能にします。 究極のコスト効率 管理の手間を最小化しつつ、需要に連動したサーバーレスの経済性を享受。 まとめ：LWAが選ばれる理由
17. ご清聴ありがとうございました。 Github：sahou909 X：@rou_88_work