Lambda Web Adapter で お手軽サーバレスSSRを実現

Lambda Web Adapter で お手軽サーバレスSSRを実現 n13u / 2025.01.18 / #jawsug_hakodate

自己紹介 ● ● 2002年生まれ、札幌市みてきて北区生、あつべつ・く育、市電のふるさと中央区在住 Nishimura Wataru（_n13u_） ○ ちょっと株式会社 受託事業部 第二ユニットのエンジニアをやってます. ■ ○ ○ ● ECMAScript 好きなWebフロントエンドフレームワーク ○ ● Next.jsと仲良くする仕事 React Router v7を使い倒す仕事 好きな言語 ○ ● 札幌市事業Sapporo Engineer Base 運営 他開発の副業お仕事 etc… 最近のお仕事 ○ ○ ● 弊社はVercelのパートナーだよ！ Next.js（App Router） 最近ハマっていること ○ ○ ワイン いいワイン屋でワインを買うと幸せになれます（本質情報） 2

名刺忘れたのでTwitterのQR貼っておきます

今日の予定（移動の話） ● ● ● ● ● 7:15 起床 8:00 外出 9:10 丘珠空港着 10:00 丘珠空港発（定刻 10:10） 10:35 函館空港着（定刻 10:55） ーーーここから予定ーーー ● 18:55 函館駅発JR ● 23:15 札幌駅着 札幌黄使用の丘珠ラーメン（1,200円）

札幌↔函館は日帰り可です.

本題

今日の予定 ● ● ● Webフロントエンドの「レンダリング」の話（10分） SSRでのデプロイ先の話（10分） Lambda Web Adapterの話（10分） しない話 ● ● Webアプリケーションがどうやってできているかの話 今回の話の具体的な実現方法

ところで... Webアプリのフロントエンド どこにデプロイしますか？

ちなみに、そのWebアプリって... CSRですか？SSRですか？ISRですか？ SPAですか？MPAですか？

呪文辛い... 😣

解説していきます

よくあるWebアプリケーションの構成

よくあるWebアプリケーションの構成 この違い is 何

この違い is 〇〇R の差

〇〇Rって？ 〇〇R＝「レンダリング（Rendering）」の方式の名前 そもそもの話... A. Webアプリケーションは「HTML + CSS + JavaScript」をブラウザで読み込み、アプリケー ションとして動くようにブラウザが組み立てている ○ RubyやPHPはそのまま読み込めない ○ JavaScriptを使ってアプリケーションを組み立てないと動かない B. そして「Web」アプリなので画面遷移＝URLの遷移として扱う ○ AというページからBというページに移動するときは /A → /B になる A＋Bの組み合わせ次第でWebアプリケーション全体の挙動や動きが変わる

？？？「レンダリングって200種類あるねん」

「レンダリング」は何を「レンダ」しているか ● ● レンダリング（rendering）は名前の通り render（意: 描画する）からきている言葉 Webアプリケーションでは以下全てを「レンダリング」と呼んでいます（） 1. HTML+CSSだけでは動的な表現ができないため、JavaScriptでHTML＋CSSを動的に操 作して、アプリケーションとして動くようにすること 2. Webアプリケーションでユーザーが触るブラウザとアプリケーションを実行している サーバーで、動いているコードが違うためブラウザが理解できる 「HTML＋CSS＋JavaScript」に変換すること（動的・静的問わず） 3. サーバー側でHTML＋CSSすると、ブラウザ上で動的な動きができないためJavaScriptと 組み合わせることで、一部をサーバーで生成しながら足りない部分をブラウザ上で組み 立てる方法（１＋２の組み合わせ） レンダリング＝アプリケーションとして動くようにすること

「 Webアプリケーションでユーザーが触るブラウザとアプリケー ションを実行しているサーバーで、動いているコードが違う 」

Webアプリケーションがどう動いているか トランスパイル・バンドル （2 or 3のレンダリング） JavaScript HTML CSS JavaScript Node.js Deno ブラウザ JavaScript ランタイム OS カーネルとかハードウェア

Webアプリケーションがどう動いているか トランスパイル・バンドル （1 or 3のレンダリング） JavaScript ここの話をします HTML CSS JavaScript Node.js Deno ブラウザ JavaScript ランタイム OS カーネルとかハードウェア

コードを変換している話 昨今のWebフロントエンドフレームワーク（Next.jsやNuxt.js、Svelte-Kit）などはおおかた以下の方 式をとっています。 1. Node.jsと呼ばれるサーバーサイドJavaScriptやHTML, CSSでアプリケーションを記述 a. 2. ここではHTMLやCSSも素の状態（いわゆるバニラ）ではなく、カスタムされた方法で記述することが できます 書かれたコードからアプリケーションとして動くコード（HTML+CSS+JavaScript）を生成 します i. ii. iii. パターン１：ページやアプリケーション、機能単位でまとめ（バンドル）ブラウザのJavaScriptで動く ような形に事前に変換する（トランスパイル） パターン２：パターン１とは別で、基本的な部分は事前にバンドル・トランスパイルしておき、リク エストに応じて動的に変換する パターン１と２を組み合わせた方式です。 上記のi~iiiがレンダリングの1~3にざっくり対応している関係です.

さて、レンダリングの話がわかりました ね？

😣

主要なものをざっくり解説

CSRと旧SSR、新SSR大きく分けると３つあるよ CSR（Client Side Rendering） Webフロントエンドの構築に必要なJavaScriptなどを全て事前に生成しておき、実行や組み立てを ブラウザで行う方法 ● ● レンダリング１「Webアプリケーションでユーザーが触るブラウザとアプリケーションを実行しているサー バーで、動いているコードが違うためブラウザが理解できる「HTML＋CSS＋JavaScript」に変換すること （動的・静的問わず）」 変換i「ページやアプリケーション、機能単位でまとめ（バンドル）ブラウザのJavaScriptで動くような形に 事前に変換する」 旧SSR（Server Side Rendering）←ここまではRubyやPHPでもできる ブラウザで必要なものをサーバー側でリクエストの都度（キャッシュを除く）生成する ● ● レンダリング2：Webアプリケーションでユーザーが触るブラウザとアプリケーションを実行しているサー バーで、動いているコードが違うためブラウザが理解できる「HTML＋CSS＋JavaScript」に変換すること （動的・静的問わず） 変換ii：基本的な部分は事前にバンドル・トランスパイルしておき、リクエストに応じて動的に変換する

CSRと旧SSR、新SSR大きく分けると３つあるよ 新SSR（Server Side Rendering）←RubyやPHPでやるのは大変で、Next.jsなんかはこの 手法をとっている 一部を旧SSRと同様サーバー側で生成し、ブラウザで動かしたい部分だけは分けてブラウザ側で組 み立てられる ● ● レンダリング３：サーバー側でHTML＋CSSすると、ブラウザ上で動的な動きができないため JavaScriptと組み合わせることで、一部をサーバーで生成しながら足りない部分をブラウザ上 で組み立てる方法（１＋２の組み合わせ） 変換iii：iとiiの組み合わせ

CSR vs 旧SSR vs 新SSR 簡単にそれぞれを比較 CSR ● ● Pros ○ ○ Cons ○ ○ デプロイがシンプル（後述） ブラウザの機能をふんだんに使える 認証やデータの取得を全てブラウザ上で行うため、セキュリティの問題が... 全てのコードを読み込むまでアプリケーションが動かない（JavaScriptがない環境では動かない） 旧SSR ● ● Pros ○ 変換済みのものを読み込むため、アプリケーションが触れるようになるまで早い（JavaScriptがなくても動く （ことが多い）） Cons ○ interactiveな動きや、ブラウザのAPIを活用した機能実装が難しい 新SSR ● ● Pros ○ ブラウザの機能をふんだんに使えつつ、事前に必要なところはサーバーで取るのでレスポンスが良い Cons ○ デプロイ方法を選ぶ ○ 実装が複雑になりやすい

今日は新SSRの話をします

あれ、SSGとかISRってどうなったの？ SPAとMPAの違いは？？？

話すと長いし本題に入れないので...

他の人に任せたよ

デプロイの話をしていきます （JavaScriptエコシステムの話に限る）

CSRの場合、今まではS3とかでよかった 変換i「ページやアプリケーション、機能単位でまとめ（バンドル）ブラウザのJavaScriptで動くよ うな形に事前に変換する」の方式をとるので、変換する仕組み（CI / CDなのかローカルで実行して デプロイなのか）があれば、出来上がったファイルをホスティングしておくだけで良い。 ● ● ● ● 基本的な動きは全部ブラウザ側で補完して組み立ててくれる セッション管理や非同期でのデータ取得実装が大変だったり この方式を利用する場合は、かつてはWebpackを利用し現代では Viteを使います SSGもこの方式に近い

SSRの場合、Node.jsサーバーが必要 新旧問わず、コードを変換する処理は必要になる。またその変換もリクエストに応じて動的に変換 するためNode.jsなど動いているアプリケーションサーバーが必要 ● ● ● Node.jsのHTTPサーバーでも、Expressでもいいけどアプリケーションサーバーへのリクエス トに応じて都度生成した結果を返す Node.js以外の言語でも同じで アプリケーションサーバーがあれば 同じことができる EC2だろうとCloud Runだろうと、 Netlifyだろうとなんだっていい （Node.jsの実行環境があれば良い）

大事なこと：「Node.jsの実行環境があれば良 い」

デプロイ先を考える （今回はReact系のフレームワークの話に限る）

SSRフロントエンドアプリのデプロイ先について

どれを使う？

個人的比較 Vercel ● ● 少人数でも大規模でも管理はしやすい、Vercel-wayに従って全て委ねるとかなり楽になる（環 境変数の管理からデプロイ管理、環境わけ、log、o11y、Firewallまで全部入っている） 料金面で色々言われるけど、EC2とかで消耗するならこっちでいい気もしている ○ ○ ● ● 1人 20$ x 3人 vs 60$のEC2と運用・管理工数（比較の仕方が悪い気がする） もちろん転送量とか色々かかるけどね too muchなケースは多いかもしれない Next.js以外で使うのは大変（公式的には色々サポートしているけど、Next.jsの次に機能サ ポートが多いのはSvelte-Kit） Cloudflare Workers ● ● 制約が多いと思っていた（最近緩和されたので状況が変わったかもしれない） あんま触ったことがないので触れない

個人的比較 Google Cloud系列 ● しっかり触ったことがあるのはCloud Runだけなのでその話を ○ ○ ○ ビルド設定がちょっと大変 コンテナに詰めて終わりほどシンプルではなく、色々設定が必要だった 特にドメインの紐付けが辛かった印象 AWS系列 EC2 ● 言わずもがな Amplify ● ● アプリケーション全体ならありだけど、Webフロントエンドフレームワーク単体ならtoo much v1までの話だけどブラックボックスが辛かった Lambda ● 今回の主題

ところで、Webフロントエンドで サーバーレスにしない理由ってあります？

SSRでサーバレス環境以外が必要なことってあんまない（気がする） ● Webフロントエンド用のNode.jsサーバーにステートを持たせたいケースが少ない（詳しくな いだけかもしれない）気がしている ○ ○ ● ● Webフロントエンドのデプロイ先として考えるならアプリケーションサーバーは管理が大変 常時サーバーが動いている必要はない（ステートの話とあんま変わんない気もする） ○ ● 強いていうなら認証？ スケーリングのことを考えるならむしろステートを持ってない方が取り回しはしやすい リクエストに応じてレスポンスを返すので、リクエストがなければいらんよねの気持ち 難点はコールドスタートだけど、今は解決方法が割とある気がしている

AWSでサーバーレス...

Lambdaがあるやん

やっとAWSの話ができる... （ここまでで20分くらいを想定）

Lambdaがあるやん

LambdaでWebフロントエンドをデプロイする とはいえ、Lambdaを素のまま使うのは大変 ● ● lambdaはHTTP標準のRequest / Responseではなくeventを受け取り動く（eventのなかに requestがあるといえばそうなんですが..）ので変換するadapterが必要 エンドポイントはexports.handler1つで、そこに処理をまとめる必要がある ○ ● https://qiita.com/zaburo/items/d31c1cb2055143991dfb 画像やCSS、HTMLなどの静的ファイルまでLambdaにおくと関数自体のサイズが大きく なる（デプロイに時間がかかる） どうしよう...

• https://qiita.com/zaburo/items/d31c1cb2055143991dfb

基本方針 基本的にはWebフロントエンドフレームワーク共通で使える方式（のはず） ● ● ● ● LambdaではLambda Web Adapterを利用し、不要なことを考えない仕組みを作る 実行環境自体はコンテナを利用し、サーバーアプリケーション実行に必要なコードはす べてそこに詰めておく ○ 最低限のnode_modules/ やnode.jsのランタイムなど CSSやHTML、一部のJS、各種アセットはアプリケーションビルドで生成しておき、S3 においておく CloudFrontでリクエストの種別（静的アセットかそうでないか）を振り分け、キャッ シュを合わせて有効化しておく

以上

？

ちゃんと解説していきます 👓

AWS Lambda Web Adapterとは？ ● ● Lambdaのevent, contextをRequest, Responseに変換して各種フレームワークとの繋ぎ目をし てくれる（HTTP Streamにも対応している） 使い方としては以下の通り https://speakerdeck.com/tmokmss/aws-lambda-web-adapterwohuo-yong-suruxin-siisabaresunoshi-zhuang-patan?slide=6

• https://speakerdeck.com/tmokmss/aws-lambda-web-adapterwohuo-yong-suruxin-siisabaresunoshi-zhuang-patan?slide=6

構成図に起こしてみる GitHub Actions AWS Cloud /*.(jpg|css|) Actions経由でデ プロイ Amazon S3 LWA Users Cloud Front /* AWS Lambda 外部のBFFや APIサービスへ

どう実際に実装していくか ● AWSの構成自体は、CDKだろうとTerraformだろうとなんだろうと良いです. ○ ○ ● 副業でやった時はterraformで構成を組みました 「{やりたいIaC名} CloudFront S3」とかで調べたらやり方は出てきます（そんなに重要じゃない認識 なのでパス 例えばGitHub Actionsでデプロイする場合は以下のことに気をつける ○ Actions上でnpm install / npm run buildをするが、ビルド結果のうちサーバー側で実行したいコード （node_modules）のみをDockerコンテナに含め、静的なファイルやアセットはS3に別でデプロイする ようにする（ケースにもよるが数10KB〜2,300KBないで大体収まるはず） - name: Install dependencies run: | npm ci - name: Build React Router v7 App run: | npm run build ## ビルドまでは Actions - name: docker build and push ECR uses: docker/[email protected] - name: Deploy static files to S3 run: | aws s3 sync ./build/client s3://${{ vars.DEV_S3_BUCKET }} --delete

AWS Lambdaを使うと何が嬉しい？ ● ● SSHとかそういうことをやらなくて良い ほぼ０円（無料枠使った場合の話）なのでお手軽 （タイトル回収） ○ ● ● ● 動かすまでが早くて楽 S3やCloudFrontと組み合わせることでキャッシュ管理が楽になる AWS環境をふんだんに使える（IaCを使っているから楽なのかもしれないが... ○ ○ ● CloudFrontの転送量とかものぞく Route 53やACMとの連携がとても楽 IAM設定がちゃんとできていれば、console.logするだけで、ログが貯められる（嬉しい） 環境変数設定も楽

LWAの細かい話 ● Rust製のAWS公式OSS（Apache License 2.0） ○ ● Lambdaに対するAPIGatewayのEventや、Request EventをWebアプリケーション実行用に変換 してくれる ○ ○ ○ ○ ○ ● ● https://github.com/awslabs/aws-lambda-web-adapter 他にも... HTTPストリームレスポンスの対応 レスポンスの圧縮 バイナリの自動エンコード etc… DockerでもZipでも使える 軽量なのでオーバーヘッドが少ない https://github.com/awslabs/aws-lambda-web-adapter

• https://github.com/awslabs/aws-lambda-web-adapter

まとめ ● ● ● ● Webフロントエンドには「レンダリング」という概念がある SSRには２種類がある SSRのデプロイ先選定は難しい Lambda Web Adapterを使うと手軽にSSRが実現できる

以上