Front-End Study #1「Cloud Native時代のフロントエンド」での登壇資料です。
フロントエンド開発者も知っておきたいAWS Lambda とサーバーレス@Keisuke69Front-End Study #1
View Slide
Amazon Web Services Japan K.K.Keisuke Nishitani@Keisuke69Programming is a creative work.Love Music♫Love Camping⛺Blog: https://www.keisuke69.net/Everything will be serverless.⚡
Why are you here?First of all, what is serverless?
Serverless• サーバーサイドの⽂脈で語られることが多い• 基本的にはバックエンド• フロントエンド開発者は普段は直接的には関わらないことが多い？
Serverless• サーバーが実際に存在しないわけではなく、意識する必要がない• APIを開発する上でそれらを動かすためのサーバーとかの準備• セキュリティとかネットワークもサービス側がケア• 何が嬉しいか
No need to setup servers anymore
Frontend developers perspective…
Single Page Application + APIServer Side Rendering + APIStatic Site Generation + API
APIs are always there.
REST or GraphQL
REST APIs with Serverless• Amazon API Gateway• HTTP(S)のエンドポイント• ロードバランサーやWebサーバ不要、もちろんネットワーク周りも• カスタムドメインOK• AWS Lambda• 関数• ランタイムのセットアップ不要• Node.js使える• 多くのAWSサービスと連携できる• Datastoreは⽬的に応じて使い分け
GraphQL with Serverless• AWS AppSync• GraphQLのエンドポイントを公開• もちろんサーバーのセットアップとか不要• 柔軟にデータソース選べる• AWS Amplify• フロントエンド開発者向けツールセット• AWSの各サービスをフロントエンド開発者がそこそこ簡単に使いやすくするもの• AppSync使う場合におすすめ
SPA with Serverless• Amazon S3とAmazon CloudFrontを使ってホスティング• S3はストレージサービスだが、単体で静的サイトの配信ができる• もちろん、カスタムドメイン使えるし、スケールもする• さらにCDNであるCloudFrontを使うことでキャッシュもできる• Amplify CLIだけでも簡単にセットアップして配信できる
SSR with Serverless• SSRの場合、サーバーサイドでレンダリングするのでそのためのサーバが必要になる• 最近だとよくあるのはNode.jsを⼊れたサーバをコンテナで⽤意するパターン• Dockerfile…• コンテナを実⾏するための基盤も必要• サーバーサイドレンダリングのインフラ的な課題• CPU負荷が⾼くなりがち• CPU負荷⾼くなった結果、さばけるリクエスト量が少なくなりがち• キャパシティ不⾜になってレスポンスが返せなくなってしまうと、ブラウザ上では真っ⽩な画⾯に…
SSR with Serverless• フロントエンドの⽂脈にも関わらず、SSRではサーバーサイドをケアする必要が出てくる• 場合によってはフロントエンド開発者がやる必要もある• つまり、サーバーを⽤意していく必要がある• AWSであればEC2とかコンテナとか使ってSSRするためのサーバーサイドの環境を⽤意する
So, serverless
AWS Lambda is excellent with SSR (I think)• AWS Lambdaの場合は関数の裏側はコンテナが⽴ち上がる• 1リクエストは同時に1コンテナでしか処理されない• 同時にリクエスト発⽣した場合は⽔平⽅向にスケールしていく• つまりリクエスト数分だけコンテナが起動される• リクエストが集中してCPU負荷が⾼まっても、クライアントにレスポンスが返せなくなることがない
How1. Next.js / Nuxt.js使う2. Next.js / Nuxt.jsで作ったアプリをExpressで動かす3. Expressで作ったアプリをLambdaで動かす• aws-serverless-expressを使う• Expressで書かれたアプリをLambdaで実⾏可能にするためのラッパーのようなもの詳細はブログ⾒てください（Nuxt.jsの例）https://www.keisuke69.net/entry/2020/09/18/175941
Wait…• すべてが同じ関数としてデプロイされるのは少し微妙• 確かにスケールもするし、リクエストごとに独⽴して処理はされるけどFat • 静的ファイルもすべてLambda経由で実⾏されてしまう• コンピューティングリソースの無駄• デプロイサイズ肥⼤によるコールドスタートへの影響• コストの無駄
Thus,• 静的アセットはS3 + CloudFrontで配信する• これをやるにはビルドとかデプロイのタイミングで考慮する必要がある• ビルドしたものを何も考えずにごそっとあげるってのはダメ• CloudFrontのEdgeで動かすLambda@Edgeというものを使って動かすこともできる• とはいえ、⾃前で実装するのは結構⼤変• リクエストの振り分けやルーティングを頑張って実装する必要がある• 静的なものはS3に、そうじゃないものはLambdaでみたいな• 少し⾯倒くさい
Good news for Next.js users!
Serverless Next.js Component• Serverless frameworkのプラグインとしてServerless Next.jsComponentが提供されているhttps://github.com/serverless-nextjs/serverless-next.js• SSRをLambda@Edgeでやる• Lambda@Edgeで静的ページへのリクエストをハンドルしてS3へとフォワード• ルーティングもされる• Dynamoc Routing相当のことも• ⽣成されたファイル/静的なAssetをS3でホスティング• CloudFront経由で配信される
詳細はこちらで
SSG with Serverless• 基本的にSSGの配信はSPAと同じ考え⽅でいい• つまりS3とCloudFrontによる配信が基本• ビルドしたものをS3上にドンと置いて、CDN使いつつ配信• SSGでも特にJamstackはビルドやCI/CDプロセスが重要• コンテンツ/コードの更新タイミングでビルドして出⼒し、静的サイトとしてデプロイする• Amplify Console• Githubなどにプッシュしたらそれを検知して、事前に定義された内容でビルドしてデプロイ• Webサイトの構築などは不要• ビルドの設定ファイルで細かい指定や処理の実施もできる
Key Takeaways• サーバーレスにより、フロントエンド開発者が⼿を出せる領域が増えた• サーバーサイド/バックエンドも⾃分たちでつくりたい場合• アーリーステージなため、少ないエンジニアで全部やる必要がある場合• API GatewayとLambdaはすでに事例も多く、参考ドキュメントも多い• 他システムとの連携やより複雑なシステムも同じような体験で開発できる• Lambdaを使った定期処理• アップロードされた画像や動画の変換処理とか• StepFunctions使えばより複雑なワークロードを実現できる
告知11/27にServerless Next.js Componentについて話す配信やります。https://serverless-newworld.connpass.com/event/194966/
keisuke69
codehex
goutarouh
kasacchiful
mugi_uno
manfredsteyer
ruyadorno
zerebom
inoichan
morikann
katsu8686
okuramasafumi
kamilahsantos
paulrobertlloyd
afnizarnur
andyhume
bkeepers
marcelosomers
samanthasiow
sachag
ammeep
productmarketing
brianwarren
paigeccino
eileencodes