Zenn
🚀

SSR/SSG/ISRって何？？ AWSでホストする方法

2022/06/21に公開1件
AWS
Next.js
Nuxt
SSR
ISR
tech

概要

  • 今回は、SSR/SSG/ISRをAWSで動かす方法やApp Runnerの魅力についてご紹介していきます。

内容

  • まず始めにTraditionalなWebアプリケーションとモダンなWebアプリケーションについて、それぞれ説明していきます。
  • 次にSSR/SSG/ISRをAWSでホストする方法についてご紹介していきます。

Traditional Web ApplicationとモダンなWebアプリケーション

Traditional Web Application

  • 従来のwebアプリケーション
    => アプリケーションの処理は、サーバ側のみで実行

例えば、JavaならSpring、PythonのDjango、RubyならRailsとか

1.png

モダンなWebアプリケーション

Reactive Web Application

  • アプリケーションの処理をサーバ側、クライアント側に分けて作り込む

  • Client Side Rendering (CSR)
    => CSRでできたアプリが、Sigle Page Application (SPA)
    – React, Vue, Angular とかとか

  • Server Side Rendering (SSR)
    – Next, Nuxtとかとか

  • Static Site Generator (SSG)

  • Jamstackな仕組み, Gatsby, Hugo, Next, Nuxt とかとか
  • Incremental Static Regeneration (ISR)
    – Next (9.4で追加された機能)

CSR (Client Side Rendering) / SPA (Sigle Page Application)

  • 最初に空のHTMLを取得し、ページ全体をJavaScriptで生成
  • クライアント側で取得したデータを基にページ遷移することなくページ全体を書き換える

csr.png

SPAの課題

  • 初回アクセスでは巨大なJavaScriptを読み込んでから、ページ全体を処理する為、初回のロードが重くなる
  • 一番の問題は、SEO周り
    • 検索エンジンのクローラーが仮にJavaScriptを解釈しないものだと空のHTMLを解釈
    • 最近のGoogleのクローラーはJavaScriptの解釈と実行も可能
  • 動的なOGPの設定も大変
  • KDDI Engineer PortalについてはBlogも管理しているので、SEO対策だけではなく、OGP対策も必要になる。

SSR (Server Side Rendering)

  • リクエストに対して動的に生成されたHTMLを返却
  • JavaScript、仮想DOMなどをサーバーサイドでも利用
  • デメリットは、サーバーサイドの重さです。API通信などを利用すると、レスポンスに時間がかかる

ssr.png

SSG (Static Site Generator)

  • リクエストに対して事前に生成されたHTMLを返却
  • SSGではビルド時にHTMLを生成
  • 配信は非常に高速だが、デプロイ後はページ内容を動的に変更できない

ssg.png

ISR (Incremental Static Regeneration)

  • リクエストに対して静的にビルドされたページを返す。
  • 有効期限を超えたら非同期で静的ページの再生成をSSRで行う。
  • キャッシュを活用しつつ、静的ページの更新を自動的に行え、一定時間後再度リクエストがあった場合、次回以降の内容をビルドするので内容が更新される。

isr.png

SSR/SSG/ISRをAWSでホストする方法

  • 必要なのはレンダリングするためのサーバ(Nodejsをセットアップしてあるサーバがあれば動く)

awsで実現.png

ISRをさせたい時に起こるキャッシュ問題

  • ISRでは、キャッシュを利用しHTMLを再生成
    => その為、インスタンスやコンテナがスケールするとキャッシュのタイミングがバラバラなので、LBからアクセスを受けるインスタンス、コンテナによってレスポンスされるHTMLの表示が変わってしまう。

他の選択肢はないの？？

  • 他の選択肢としては、Serverless Next.js Componentという3rd partyのツールや、App Runnerがあります。
  • App Runnerは僕の中ではかなり押しのサービスです。

こんなのもあるよ.png

実はAmplifyへのホスティングもできる

  • 静的サイトのデプロイパイプラインとホスティングが容易にできるサービス
  • SPAとかJamstackのホスティングには最適
  • 2021/5月にNext 9のSSRをサポート。7月に10/11もサポート
  • ISRもサポートしている。
  • Amplify => Serverless Next.js Componentがベースになっているっぽい

App Runnerって何？

  • APP Runnerとは、「The easiest and fastest way to build, deploy, and run containerized web apps on AWS」 すなわち、AWS環境でコンテナのアプリをめっちゃ簡単にめっちゃ早く環境を用意し動かすことができるサービスです。

  • App Runnerについては、詳しくはこちらをご参照ください。

https://qiita.com/yoshii0110/items/ec209712cafa7547c680

なぜApp Runnerなのか。

  • 確かにcontainerを実行する環境であれば、ECSでも良いわけです。
  • ただ、正直ECS Fargateという選択肢だとしても運用するのしんどくない？？ と思ってしまうためです。

App Runner

  • Fargateだとコンテナ管理とかVPC周り、ALB、NLBとかAuto Scalingの設定とか、自動化するならCodebuildとかを組み合わせていたが、App Runnerは、これらをまとめて(隠蔽して)提供してくれます。

2.png

App RunnerにおけるDeploy

  • App RunnerでのDeploy方法に自動でやってくれる機能があります。
  • 使い方としては、ECRにコンテナイメージをpushするか、GitHubにソースコードをpushすると、それを検知し、App Runnerがいい感じにコンテナをデプロイしてくれる感じですね。

3.png

参考

https://developers.kddi.com/blog/EzMkpB2zMihVnpXFcuCrc

https://speakerdeck.com/keisuke69/digging-how-to-running-isr-on-aws

https://zenn.dev/bitarts/articles/37260ddb28ae5d

Discussion

negabaronegabaro

読みやすかったです。ありがとうございます。一つ質問ですが、
書いてくださったISRをさせたい時に起こるキャッシュ問題は
appRunnerでも起きるのかなと思いましたが、自分の理解あってますでしょうか？

vercelだと共通のストレージにキャッシュを保存するので問題ないですが、appRunnerではそのようなのがない認識でした。