COLUMN

【AWS re:Invent】Unlocking serverless web applications with AWS Lambda Web Adapter (BOA311)

こんにちは、中村です。
11/29のBreakout sessionである、Unlocking serverless with AWS Lambda Web Adapterのレポートをお送りします。

Breakout sessionは、⼿を動かすWorkshopとは異なり、リスニングをベースとして1時間ほどの技術的な講義‧解説が⾏われます。技術レベルは難易度に合わせ、100-300に設定されています。

このセッションはMGM Grandで⾏われました。

スケジュールがタイトだったため、急いで昼⾷を済ませてセッション会場に向かいました。

MGMのLunch Meals会場

⾷事。本来もっと豪華なbuffetでしたが、5分しか無かったので、省略しました

BOA311:Unlocking serverless with application with AWS Lambda Web Adapter

Session Level:300(Advanced)

Lambdaを利⽤した、サーバレスなWebアプリケーションの開発⼿法についてのセッションです。

私の開発チームでは、サーバレスなWebアプリケーションを作成する場合、Amplify等を使って、S3にHTMLやJavascriptを配置したSPAを作成しがちです。

このセッションでは、Lambda Web Adapterを使⽤し、SPAだけでなく、PythonやJava、カスタムランタイムを使⽤すればPHP等のMPAアプリケーションもLambdaから配信できる事を説明しています。

ただし、それなりの制約はあり、満遍なく使えるソリューションかというと難しい所なのですがLambda好きの私としては⼤変興味深く話を聞くことが出来ました。

ちなみに、Lambda Web Adapter⾃体は新機能でもなんでもなく、以前からある機能です。

Agenda:

  • Challlenges of building serverless web applications
    →サーバレスWebアプリケーションの作成に挑戦する
  • Inventing AWS Lambda Web Adapter
    →Lambda Web Adapterの発明
  • Migrating web apps to Lambda
    →WebアプリケーションをLambdaに移⾏する
  • Enhancing Lambda runtimes
    →Lambda runtimeを強化する
  • Unlocking serverless web applications
    →webアプリケーションの制限を解除する

Challlenges of building serverless web applications

LambdaはAWSによるサーバレスなコンピューティングサービスで、スケーラビリティとコストの節約のメリットがあります。

このメリットをWebアプリケーションの配信に役⽴てようと考える開発者もおり、イベント駆動というLambdaの特性を理解し、正しくコードを調整することで、様々な⾔語でのLambdaでのWebアプリケーションの作成が可能になります。

Lambdaで動かすためのフレームワークを使⽤することで、Lambdaへのアプリケーションのデプロイが容易になります。ここでは⼀例として、FastAPI,Mangumを使⽤していました。東⽇本でもよく使⽤しています。

ただし、依存性の問題や、フレームワークのメンテナンスを考慮する必要があります。

つまり、EC2やECSで動いているWebアプリケーションはそのまま動かすことができず、多少なりのコードの修正を⾏う必要があります。

どうすれば、できるだけコードの変更を⾏わずに、アプリケーションを移⾏できますか?

この問題を解決するために、パッケージ化されたwebアプリケーションを、Lambda Web Adapterを使⽤してデプロイする⼿法について、ここから説明を⾏います。

Inventing AWS Lambda Web Adapter

幾つかの開発者は、webアプリケーションLambdaにデプロイするモジュールをPoCとして開発していましたが、サービスのレベルには⾄りませんでした。

その後AWSでは、Lambda Web Adapterを開発しました。依存性はAWS側の責任範囲となり、メンテナンスが向上します。また、Gravitonなどのarm64アーキテクチャでも動作します。

Web Adapterが、全ての通信の間に存在することが分かります。そのため動作上の遅延が懸念されますが、Web AdapterはRustで記述されており、遅延を1ms以内に押さえています。

Web Adapterは、Lambdaからのリクエストを受け取り、webアプリケーションへのリクエストに変換、ローカルで起動しているWeb Applicationにリクエストを⾏います。

レスポンスはその逆です。

Node.jsであれば、Web Adapterのインストールを1⾏加えるだけで簡単に動きます。

また、Web AdapterはLambdaでしか動かないので、このイメージはそのままEC2やECSに移⾏することができます。

この後、Express.jsを使⽤した、ローカル開発とデバッグ、及びAWS SAMを使⽤したデプロイのデモがありました。

Migrating web apps to Lambda

サービスが成⻑するにつれて、機能をマイクロサービスとして分割し(なんなら機能毎に別の⾔語で!)、チームが独⽴して開発を⾏うことが容易な設計であることを⽰しています。

簡単な機能追加として、imgproxyの追加の説明がありました。

画⾯左上にDockerfileの記載がありますが、既存のイメージにWeb Adapterを⼀⾏追加するだけで、簡単に導⼊ができる、ということを⽰しています。

Enhancing Lambda runtimes

ここでは、Lambda runtimesの強化された機能について説明がありました。

Lambda streamingの恩恵により、レスポンスまでの時間の短縮と、6MBまでだったレスポンスデータを、20MBまで対応できるようになりました。

Web Adapterはこれを導⼊しており、Next.jsのSSR、hydrationに対応できています。

動画で⾒るとわかりやすいですが、画⾯の右側がWebコンテンツであり、Recommendationのコンテンツが5秒ほど遅れて表⽰されていることが分かります。

Bedrockからのレスポンスをストリーミングで取得出来ることを⽰しています。

今回のセッション、どれも必ず1度くらいはBedrockのアイコンが出てきます。

ChatGPTのように、プロンプトの応答が⼀度に返ってくるのではなく、ストリーミングで除書にサーバから返却されている、というのが解るデモとなっていました。

Unlocking serverless web applications with Lambda Web Adapter

Web Adapterの将来性について、説明がありました。

開発者の中でも⼈気になっており、Web Adapterのpull数や、invokeの実⾏数がとても増えていることが分かります。

また、実際に利⽤されている企業からの、良いコメントがありました。

今回紹介されたリソースの紹介となります。

レポートは以上となります。

⼩規模な開発をスムーズにスタートするのにとても有効で、リフト・シフトや、スケールも容易であるということが理解できました。

⼀⽅、同時実⾏の制限や、セッションの共有等、幾つか考えなければならないことも多く、社内案件では⼩さな所からスタートし、検証できるものがあればと感じました。

ページ上部へ戻る

相談無料!プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。