Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSでISRの実現!その謎を解明すべくAmazonの奥地へと足を踏み入れる!! / Di...
Search
Keisuke69
September 30, 2021
Technology
4
8.8k
AWSでISRの実現! その謎を解明すべくAmazonの奥地へと 足を踏み入れる!! / Digging how to running ISR on AWS
AWS DevDay 2021のブレイクアウトセッションで講演した際の資料です。
Keisuke69
September 30, 2021
Tweet
Share
More Decks by Keisuke69
See All by Keisuke69
CTOから見た事業開発とプロダクト開発 / My Perspective on Business and Product Development as CTO
keisuke69
4
1.2k
波濤 / Surges
keisuke69
1
150
クロスプラットフォーム開発の真実
keisuke69
2
620
脱Firebase. 我々はどう生きるか/Migrate from Firebase
keisuke69
7
8.8k
様式美と絵に書いた餅、そしてそこにあるリアル
keisuke69
0
5.4k
俺のJestが動かない 2021 Spring / My Jest does not work well 2021 Spring
keisuke69
0
7.3k
フロントエンド開発者も知っておきたいAWS Lambda とサーバーレス / Serverless for frontend developers
keisuke69
6
7.8k
Pythonistaに贈るAWS Lambda入門 / AWS Lambda Essentials for Pythonista
keisuke69
2
4.6k
The Twelve-Factor App on AWS
keisuke69
16
5.1k
Other Decks in Technology
See All in Technology
ドメインロジックで考えるテスタビリティ
leveragestech
1
220
Explain EXPLAIN
keiko713
2
130
Oracle Database 23c新機能 #5 データベース・パフォーマンス関連新機能前半
oracle4engineer
PRO
1
130
Oracle Cloud Infrastructure:2024年11月度サービス・アップデート
oracle4engineer
PRO
0
160
マルチプロダクト、マルチデータ基盤での Looker活用事例 〜BQじゃなくてもLookerはいいぞ〜
gappy50
0
120
専門領域に特化したチームの挑戦
leveragestech
0
250
Kubernetesを知る
logica0419
17
4.5k
241130紅白ぺぱ合戦LT「編集の技術」
toya524287
5
580
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
360
開志専門職大学特別講義 2024 デモパート
1ftseabass
PRO
0
210
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
5
920
サービスの拡大に伴うオペレーション課題に立ち向かう / 20241128_cloudsign_pdm
bengo4com
0
860
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
520
39k
Building Adaptive Systems
keathley
38
2.3k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
How STYLIGHT went responsive
nonsquared
95
5.2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Navigating Team Friction
lara
183
15k
Embracing the Ebb and Flow
colly
84
4.5k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Music & Morning Musume
bryan
46
6.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Transcript
Singular Perturbations Inc Keisuke Nishitani
CTO@ Singular Perturbations Inc Keisuke Nishitani @Keisuke69 Programming is a
creative work. 🎨 Love Music ♫ Love Camping ⛺ Blog: https://www.keisuke69.net/ 💻 Everything will be serverless. ⚡ カジュアル⾯談:https://meety.net/matches/kBtcRNFYzKEI 🧑💻
None
世界の悲しい経験を減らす。 VISION
コンピューターサイエンスがもたらす知能を 安全に関わる全ての⼈へ MISSION
Patrol Community
今⽇のテーマ
Incremental Static Regenerationが実⾏可能な環境を AWSで構築する⽅法 ※実際にはAPIがいたり、GraphQLがあったりもするけどそこは話しません
フロントエンドWebのおさらい
トラディショナルWebアプリ ①リクエスト ③HTML/JS/CSS ページ全体をレンダリング ②ページ全体を⽣成
モダンなフロントエンドWebアプリケーション
Single Page Application
Single Page Application (SPA) • 単⼀のHTMLページで構成されるWebアプリケーション • 1枚のHTMLに置かれたJavaScript (およびTypeScript)もしくはアプリケー ションですべてが成⽴
• HTMLのレンダリングおよびリクエストのルーティングがクライア ントサイド(≒ブラウザ)で⾏われる • 同⼀のページ内で⾏われる • ページ遷移がサクサク動く • React / Vue.js /Angularあたりが 有名 ①初回リクエスト ②HTML/JS/CSS ③APIリクエスト ④JSON Webサーバ/ホスティング バックエンドAPI
SPAの課題 • SEO周りが課題になりがち • HTMLがリクエストされてもJSがロードされて処理が実⾏されるまでは真っ⽩。ここ⼤事。 • 検索エンジンのクローラーが仮にJavaScriptを解釈しないものだと真っ⽩な⼀枚の何もな いものを受け取るだけ • 最近ではGoogleのクローラー(Googlebot)はJavaScriptの解釈と実⾏も可能
• GooglebotはレンダリングエンジンとしてHeadless Chromiumを⽤いてJavaScriptを実⾏ するが、⼀昨年まではChrome41相当の古いものであったためそもそも正しく動いてくれ ない、つまり正しいHTMLを認識してくれないという問題があった • 現在は最新のChromeに常に対応していくことが発表されている • ファーストビューが遅い • UXの問題に加えて対クローラーの観点でも問題になりうる • 例えば⾮同期に他のAPIをコールしてデータを取得してコンテンツを⽣成する場合にローディング中 の表⽰やスピナを表⽰することが多いがクローラーは最後まで待ってくれないケースが多い • 動的なOGP対応が難しい • Google以外のbot等ではJavaScriptを解釈して実⾏してくれないものもある
Single Page Application Server Side Rendering
Server Side Rendering (SSR) • 端的に⾔うと初回のHTMLをサーバ側でレンダリング • ⾔葉とおりレンダリングのためのサーバを⽤意して、必要に応じてAPIリ クエストを実⾏し、HTMLをレンダリング •
2回⽬以降はSPAと同様 • ReactだとNext.js、VueだとNuxt.jsあたりが著名 • SPAで課題になったクローラーによるアクセスであっても正しいコ ンテンツを返せるようになる • 動的なOGPの問題について同様 ①リクエスト ④HTML/JS/CSS ②APIリクエスト ③JSON ⑤APIリクエスト ⑥JSON Node.jsサーバ バックエンドAPI
SSRの課題 • やはりサーバが必要になってくること • サーバが必要になるため、それに伴うインフラ的な課題が⽣まれ てくる • CPU負荷⾼くなりがち • さばけるリクエスト量が少なくなりがち
• キャパシティ不⾜になってしまうとレスポンスが返せなくなることがあり、 そうなるとブラウザ上では画⾯が真っ⽩に
Single Page Application Server Side Rendering Static Site Generation
Static Site Generation (SSG) • JSで構築されたページを事前にすべて静的なページとして⽣成 • 静的サイトとして配信可能 • 動的な処理がないためSSRと⽐べると軽量であり⾼速
• 動的な部分がないためセキュアになる • 配信もシンプルになりWebサーバだけで可能。スケールも容易 • 各種ホスティングサービスも利⽤可能。Amazon Simple Storage Service (S3)も • Gatsby、HugoなどのStatic Site Generatorを利⽤するだけでなく、 Next.jsやNuxt.jsでも可能 • JamstackもSSGが前提
SSGの課題 • ビルドプロセスの整備が重要 • コンテンツの更新のたびに全体のビルドが必要となる • コンテンツの数が増えると時間かかる • CMSなんかで⼊稿されたらまるっと再ビルドが必要になる •
当然ながら動的なコンテンツは処理できないためリアルタイム性 の⾼いコンテンツには利⽤できない
Single Page Application Server Side Rendering Static Site Generation Incremental
Static Regeneration Incremental Static Regeneration
Incremental Static Regeneration (ISR) • リクエストに対して静的にビルドされたページを返しつつ、有効期限が 過ぎたら⾮同期で静的ページの再⽣成を⾏う • Cache Controlにおけるstale-while-revalidateと同様の考え⽅が適⽤され
たもの • Next.js 9.4から追加された機能 • SSRとSSGそれぞれの⾟みをある程度解消してくれる • ISRでは静的ページの事前ビルドをしつつ、キャッシュを有効活⽤しつつ、静的 ページの更新を⾃動的に⾏う • 動的に近いこともできるようになった • SSGのようにサイト全体をリビルドする必要がない • 次世代のStatic Site Generationと⾔っても過⾔ではない(⻄⾕談)
シンプルなサンプル export default function Index({current}) { return ( <div> 現在時刻は{current}です。
</div> ); } export async function getStaticProps() { const date = new Date(); const current = date.toLocaleString() return { props: { current, }, revalidate: 10, }; }
シンプルなサンプル • SSGと同様にgetStaticProps()を利⽤ • Revalidateの指定により、指定したインターバルでビルドし直される • 動的ルーティングする場合はこれに加えてgetStaticPaths()で fallback: trueを指定する必要がある
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
Incremental Static Regeneration revalidate: 60の場合 静的ページ⽣成(v1) & キャッシング キャッシュ 期限切れ
キャッシュ 静的ページ再⽣成 (v2) & キャッシング更新 0 s 30 s 60 s 0 s 65 s Time キャッシュ(v2)
そんなISRなフロントエンドアプリをAWSでホストするには?
Amazon Elastic Compute Cloud (Amazon EC2)
⼀応こんなのもある
AWS Elastic Beanstalk Amazon Lightsail
Containers Amazon Elastic Kubernetes Service (Amazon EKS) AWS Fargate Amazon
Elastic Container Service (Amazon ECS)
コンテナの利⽤ • FargateでもECSでもEKSでもk8s on EC2でもOK • ISRはnext startをサポートしているのでNode.jsをセットアップしたコン テナとWebサーバとなるコンテナがあれば動く •
つまり、通常のWebアプリケーションと同じ • Pros • ⼀番わかりやすい(≠ 楽) • 従来型の構成を再現しやすい • コンテナならではのポータビリティ、柔軟性、軽量なことによる起動と開発プロ セスの⾼速化 • Cons • EC2よりはマシとはいえ、DockerfileやTask Difinition、Podといったコンテナ環境 の定義を運⽤管理していくのは⼿間 • ランタイムの管理が必要 • AWSやインフラよりの知識がアプリケーション開発者に求められる • キャッシュが分散し、反映にタイムラグなどが発⽣する
None
AWS App Runner
AWS App Runner • コンテナベースで作られたWebアプリのフルマネージドサービス • 簡単、⼿軽に、⼤規模なWebシステムのビルドとデプロイが可能 • Pros •
コンテナサービス各種で必要となるDockerfile以外の定義ファイルたちが不要 • デプロイパイプラインまで⽤意してくれる • AWS Lambdaと異なりコールドスタートがない • 最⼩インスタンス数が1 • インフラ知識不要 • VPCとかLBはもちろんオートスケーリングとかも意識しなくていい、⼀応 • Cons • 最⼩インスタンス数が1なので完全にゼロスタートはできない? • ただ、課⾦は考慮される • VPC内のリソースにアクセスできない (2021年9⽉30⽇時点) • Amazon Relational Database Service (Amazon RDS)とかAmazon Elastic File System (Amazon EFS)が使えない • 当然ながら各AWSサービス単位での細かいチューニングは難しい • キャッシュの問題などコンテナで運⽤する場合と同じ問題がある
キャッシュの問題とは?
キャッシュの問題とは • ISRでは仕組み上、サーバ内部でキャッシュが保持される • つまり、コンテナごと、インスタンスごとに別のファイルになる • ロードバランサからはどのインスタンスにいくかわからない • 最初の⽣成が⾏われるタイミングがバラバラ •
revalidateもコンテナごとにバラバラ • ロードバランサによるリクエストの転送先とrevalidateのタイミン グ次第ではなかなか更新されないといった状況が発⽣しうる • 極端な例として、revalidateの時刻に達していないコンテナにばかりリクエ ストが転送されてしまった場合
None
Serverless
サーバーレスを利⽤することの意味 • AWS Lambda等のサーバーレスなサービスを使うことによるメ リット • コンテナとかインフラそのものの管理をしなくていい • CPU負荷が⾼くなりがちな点とスケーラビリティ上の難点を解決してくれ る
• AWS Lambdaの場合、1リクエスト(=イベント)に対して1インスタンス (=コンテナ)が対応 • 同時にリクエストが来た場合もそれぞれ別のインスタンスが対応するため、 リクエストが集中してサーバに処理が集中してCPU負荷が⾼まった結果ク ライアントにレスポンスが返せなくなるみたいなことが発⽣しない • しかし、AWS Lambdaで実装を頑張るのは現実的ではない • ISRは仕組み上内部でキャッシュが保持されるため、AWS Lambdaの関数 モデルで実現するのは難しい
Serverless Next.js Component • AWSを始めとするサーバーレス環境のデプロイやプロビジョニングツー ルであるServerless Frameworkの関連機能であるServerless Component の⼀つ •
Next.jsをサーバーレスで実⾏可能にする • Lambda@Edgeで実現 • 静的なアセットや静的ファイルとして⽣成されたものはS3でホスティングするよ うにデプロイした上でCloudFrontを使って配信される • Lambda@EdgeでルーティングやSSG、SSRのハンドリングといったことを⾃前で 実装するのはコストが⾼い • Zero configurationを謳っており、SSGやSSRはAPIで⾃動判別して対応 • Image Optimizationにも対応 • ISRにも対応 • Lambda@Edgeで静的ページへのリクエストをハンドリングしてSSRし ないリクエストはS3へとフォワード • Dynamic Routingもサポート
Serverless Next.js Component Build成果物(_next/*) User Assets (/static/*) SSR and Static
Pages API (/api/*) /_next /static /public /static-pages Amazon CloudFront Amazon S3
Serverless Next.js Component • Origin ResponseでISRのページかどうかをチェック • Expiresヘッダがあるか、revalidateプロパティがあるか • Expiresヘッダーをチェック
• 将来の値であればcache-controlヘッダを適⽤しエッジに保存 • 過去の値であればページの再⽣成をトリガー。同時に既存ページをno- cacheで返す • 再⽣成のためにSQSのFIFO キューにメッセージをpublishし、 Lambda関数で⾮同期に⽣成
もっと楽に…
None
AWS Amplify Console • Library、CLI等からなるAWS Amplify のサービス群の1つ • 元来は静的サイトのデプロイパイプラインとホスティングが守備範囲 •
GitにPushしたらビルドが実⾏されてデプロイされるというフローを簡単 に実装できる • SPAやSSG/Jamstackに向いている • Next.jsをサポート • 2021年5⽉にNext.js 9のSSRをサポート、7⽉に10/11に対応 • SSRだけでなくIncremental Static Regenerationに対応 • Image Optimization(next/image)とScript Optimization (next/script)も対応 • Serverless Next.js Componentをベースにしている模様 • 現状では⼀番簡単だと思う(⻄⾕談)
Wrap up • AWSでISRを実現する⼿段は複数ある • EC2からサーバーレスまで • EC2やコンテナなどで実現する場合はキャッシュの問題がある • 特にスケールする場合に問題になる
• 実装の簡単さではAWS Amplify ConsoleとAWS App Runner • Serverless Next.js Component • 結論として、AWSでISRを実現するには現状ではAWS Amplify Console or Serverless Next.js Component • 個⼈的にはAWS Amplify Console⼀択だがAWS WAFを使いたい場合などは Serverless Next.js Componentもあり • コンテナでの実装はキャッシュの問題があって現実的に使い物にならないのでは
OMAKE
stale-while-revalidate • キャッシュコントロールの⼀種 • ブラウザやCDNにおけるキャッシュにおいて、⼀定期間はキャッシュから レスポンスするが指定時間を経過したら⾮同期でオリジナルをfetchして キャッシュをレスポンス/更新する • ISR以外にもデータ取得にフォーカスしたSWRというライブラリもある •
Cache ControlをサポートするCDNであれば実は同じようなことが できる • Next.js側ではISRをせずとも通常のSSRでよくなる • そもそもNext.jsとかSSRとか関係なくなるという期待 • しかし、AWSのCDNであるCloudFrontは現状ではstale-while- revalidateには対応していない(stale-if-errorには対応している)
終
仲間募集中! 興味ある⽅はDMください!