<p>こんにちは。みやぞんです。</p>
<p>前回の記事ではLPの記事投稿部分のヘッドレスCMS化に伴い、Next側ではどのようにレンダリングするのが正解なのだろうと色々考え、結果的にはSGを選択したと説明しました。しかし後になってISRに関する理解が誤っていたことに気が付き二転三転としたところでISRの採用に落ち着きました。(修正してます)</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__28aac6a44172c" src="https://embed.zenn.studio/card#zenn-embedded__28aac6a44172c" data-content="https%3A%2F%2Fzenn.dev%2Fhk_206%2Farticles%2F6981eca2fb56c5" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://zenn.dev/hk_206/articles/6981eca2fb56c5" style="display:none" target="_blank">https://zenn.dev/hk_206/articles/6981eca2fb56c5</a></p>
<p>今回は、そのときに少し深掘して学んだISRの挙動についての記事になります。</p>
<h2 id="cdn%E3%81%A8%E3%81%AF">
<a class="header-anchor-link" href="#cdn%E3%81%A8%E3%81%AF" aria-hidden="true"></a> CDNとは</h2>
<p>まずはWebの基本知識であるCDNについてです。ISRを理解する上でキャッシュやCDNの理解は必須です。CDNとはContents　Delivery Networkのことで<strong>複数のキャッシュサーバ(エッジサーバとも呼ばれる)で構成されたネットワーク</strong>のことです。オリジンサーバとクライアントの間に位置するネットワークで、以下の利点があります。</p>
<ul>
<li>負荷分散（オリジンサーバにアクセスが集中しない）</li>
<li>キャッシュによるコンテンツ配信の高速化</li>
<li>可用性向上</li>
</ul>
<p><img src="https://storage.googleapis.com/zenn-user-upload/6390d596cf0d-20220123.png" alt loading="lazy" class="md-img"><br>
画像：<a href="https://www.kagoya.jp/howto/it-glossary/web/cdn/" target="_blank" rel="nofollow noopener noreferrer">カゴヤのサーバ研究室</a></p>
<p>CDNではアクセスするクライアント間でキャッシュが共有されます。</p>
<p>もう少し詳しい説明はこちら。<br style="display:none">
<span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__06c34439bb7d5" src="https://embed.zenn.studio/card#zenn-embedded__06c34439bb7d5" data-content="https%3A%2F%2Fgihyo.jp%2Fbook%2Fpickup%2F2021%2F0012" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://gihyo.jp/book/pickup/2021/0012" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://gihyo.jp/book/pickup/2021/0012</a></p>
<h2 id="vercel-%E3%82%A8%E3%83%83%E3%82%B8%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF">
<a class="header-anchor-link" href="#vercel-%E3%82%A8%E3%83%83%E3%82%B8%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF" aria-hidden="true"></a> Vercel　エッジネットワーク</h2>
<p><strong>Vercel製のCDN</strong>のようなものです。エッジネットワークは世界中の数十の場所で稼働しています。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/728d7190bdf0-20220123.png" alt loading="lazy" class="md-img"></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__4dc350c7558ad" src="https://embed.zenn.studio/card#zenn-embedded__4dc350c7558ad" data-content="https%3A%2F%2Fvercel.com%2Fdocs%2Fconcepts%2Fedge-network%2Foverview" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://vercel.com/docs/concepts/edge-network/overview" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://vercel.com/docs/concepts/edge-network/overview</a></p>
<p>AWSもエッジロケーションっていうのが至るところにありますよね。</p>
<h2 id="vercel%E3%81%AE%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">
<a class="header-anchor-link" href="#vercel%E3%81%AE%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> Vercelのキャッシュについて</h2>
<p>静的ファイルは最初のリクエストの後、自動的にキャッシュされます。(最大31日間)<br>
また、再デプロイ時にはキャッシュは事実上無効となります。</p>
<p>静的ファイルはハッシュによってキャッシュされるため、ファイルが変更されない場合はデプロイをまたいで持続することができます。</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__a3b9bbd173157" src="https://embed.zenn.studio/card#zenn-embedded__a3b9bbd173157" data-content="https%3A%2F%2Fvercel.com%2Fdocs%2Fconcepts%2Fedge-network%2Fcaching" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://vercel.com/docs/concepts/edge-network/caching" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://vercel.com/docs/concepts/edge-network/caching</a></p>
<h3 id="stale-while-revalidate">
<a class="header-anchor-link" href="#stale-while-revalidate" aria-hidden="true"></a> stale-while-revalidate</h3>
<p>Vercelのキャッシュの特徴は「stale-while-revalidate」というCache-Controlヘッダーの拡張機能をサポートしている点です。</p>
<p>簡単に説明すると、キャッシュが再生成される時間を決めて、キャッシュ生成されてから指定の時間が生成するとリクエストをトリガーにして新しいキャッシュがバックグラウンドで生成されるというものです。<br>
つまり動的コンテンツであっても静的ページを定期的に更新することでキャッシュできるようになります。</p>
<p>詳しい挙動はISRと一緒に追っていくとわかりやすいと思います。</p>
<h2 id="isr%E3%81%AE%E6%8C%99%E5%8B%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">
<a class="header-anchor-link" href="#isr%E3%81%AE%E6%8C%99%E5%8B%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> ISRの挙動について</h2>
<p>ここまできたらISRは実際にどのように動いているのかを追ってみましょう。</p>
<p>Vercel公式の画像を借りて説明します。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/94090434b8d6-20220123.png" alt loading="lazy" class="md-img"></p>
<ol>
<li>コンテンツのキャッシュが未生成の場合はオリジンサーバにリクエストを送りSSRでページを生成する。またこのときキャッシュサーバー(CDN)にキャッシュを作る。</li>
<li>次のリクエストからキャッシュサーバがキャッシュを返す。</li>
<li>キャッシュが生成されてからrevalidationで設定した秒数が経過するまでは同じキャッシュを返し続ける。</li>
<li>指定した秒数が経過してから初めてのリクエスト時に、それがトリガーとなってキャッシュ(ver.2)を再生成する。このアクセスではまだ古いキャッシュ(ver.1)が返される。(つまり単に指定した秒数が経過しただけでは勝手にキャッシュを再生成することはない)</li>
<li>新しくキャッシュが生成されてからその次のリクエストからは新しいキャッシュが返される。</li>
</ol>
<p>これが「stale-while-revalidate」というキャッシュ戦略を利用したISRの動作です。</p>
<p>ちなみに、developer toolでCache-Controlを確認するとISRのどのフェーズにいるのかがわかります。</p>
<p><code>MISS</code>: キャッシュが生成されていないのでSSRによってページを生成した<br>
<code>HIT</code>: ISRによって生成された新しいキャッシュを利用中<br>
<code>STALE</code>: キャッシュのrevalidate秒数を超えているので古いキャッシュを返しつつ、裏で新しいキャシュを生成します。次のアクセスから新しいキャッシュを返します(HIT)</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__cbe0e44b34f09" src="https://embed.zenn.studio/card#zenn-embedded__cbe0e44b34f09" data-content="https%3A%2F%2Fvercel.com%2Fdocs%2Fconcepts%2Fnext.js%2Fincremental-static-regeneration" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://vercel.com/docs/concepts/next.js/incremental-static-regeneration" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://vercel.com/docs/concepts/next.js/incremental-static-regeneration</a></p>
<p>CDNは共有キャッシュなのでこのサイクルはクライアント一人ひとりで生じるわけではなく、サイクルごと共有されている。つまりAさんが「キャッシュが作られていない状態のアプリケーション」にアクセスしたとき、それがトリガーとなってSSRが実行され同時にキャッシュも生成されます。その後すぐにBさんがアクセスしたらBさんが受け取るのはすでに生成されているキャッシュとなるのです。</p>
<p>なので最初にアクセスしたAさんは二回目のアクセスからからキャッシュが提供がされ、それ以外のクライアントは初回からキャッシュが提供されます。</p>
<p>ここまでISRのことを学んでみると、前の記事でも書いたとおり、強整合性が求められるようなページでない限りは動的ページはISR一択なのでは改めて感じます。(SEOやOGPの関係ないところではCSRもありだとは思います。)</p>
<h2 id="%E6%9C%80%E5%BE%8C%E3%81%AB">
<a class="header-anchor-link" href="#%E6%9C%80%E5%BE%8C%E3%81%AB" aria-hidden="true"></a> 最後に</h2>
<p>今回は悔しい勘違いでしたが、おかげでISRの正しい理解にたどり着くことができました...。<br>
公式ドキュメントに必ず正しい仕様は書いてあるので、面倒臭がらずに穴が空くほど目を通さないとなと感じました。エンジニアになりたての頃は心がけていたはずでしたが...。精進します！</p>


stale-while-revalidateから紐解くNext.jsのISR

Discussion