体感を速くする仕組みの側から

体感を速くする仕組みの側から

前回のS-07では、表示速度を利用者の体感という観点から見て、Core Web Vitalsの3つの見方を学びました。その体感を速くする代表的な打ち手が、今回のキャッシュとCDNです。速さと負荷とお金を、同じ一手でまとめて改善できる場面が多くあります。この講義は、S章の性能パートの後半として、体感の改善を仕組みの側から支える回に当たります。

このスライドのポイント

  • 前回S-07: 表示速度を利用者の体感で見て、Core Web Vitalsの3観点を学んだ
  • 体感を速くする代表的な打ち手が、今回のキャッシュとCDN
  • 速さ・負荷・費用を、同じ一手で改善できる場面が多い
  • S章の性能パート後半。体感の改善を仕組みの側から支える回

キャッシュの階層とCDNの定義

キャッシュの階層とCDNの定義

まず定義します。キャッシュとは、I-10で扱ったとおり、計算や取得を済ませた結果を保存しておき、次に同じものが必要になったときに再利用する仕組みの総称です。キャッシュには階層があります。利用者に近い順に、ブラウザ、CDN、アプリ、そしてデータベースの前段、という並びです。ブラウザのキャッシュは、D-07で見たCache-Controlという指示で制御します。そしてCDNとは、D-09で扱った画像やCSS、JavaScriptといった静的なファイルを、世界中のエッジ、つまりR-04で学んだ利用者に近い配信拠点に複製して置き、近くから配る仕組みのことです。

このスライドのポイント

  • キャッシュ(I-10の再訪)=計算・取得済みの結果を保存して再利用する仕組みの総称
  • 階層がある: 利用者に近い順に ブラウザ → CDN → アプリ → DB前段
  • ブラウザのキャッシュはD-07のCache-Controlで制御する
  • CDN=静的ファイル(D-09の画像・CSS・JS)を世界中のエッジ(R-04)に複製し、近くから配る仕組み

知らないと何に失敗するか

知らないと何に失敗するか

キャッシュを知らないとどうなるでしょうか。すべてのリクエストが、毎回サーバーとデータベースまで届く構成のままになります。これは遅く、そしてS-10で学ぶとおり費用も高くつきます。逆に、キャッシュに頼りすぎると今度は反対の失敗が起きます。更新したはずの内容が反映されない、という現象です。これはI-10で触れた再検証の問題が、すべての階層で起こりうる、と考えるとわかりやすいです。

このスライドのポイント

  • 全リクエストが毎回サーバーとDBまで届く構成のまま → 遅い・高い(S-10)
  • 逆にキャッシュしすぎると「更新が反映されない」
  • これはI-10の再検証問題が、全階層で起こりうる状態
  • 速さと鮮度は、設計で釣り合わせる対象

奥へ行くほど遅く高い

奥へ行くほど遅く高い

構造を図で押さえます。利用者から見て、ブラウザ、CDN、アプリ、データベースの前段の順に階層が並びます。それぞれの層には、ここで返せれば奥まで行かずに済む、という役割があります。手前の層で返せるほど応答は速く、負荷も費用も小さくなります。逆に、奥のデータベースまで行くほど遅く、そして高くつきます。この奥へ行くほど遅く高い、という勾配を頭に入れると、どの層で止めれば得かが見えてきます。

このスライドのポイント

  • 利用者 → [ブラウザ] → [CDN] → [アプリ] → [DB前段] の階層
  • 各層に「ここで返せれば奥へ行かない」という役割
  • 手前で返せるほど、応答は速く・負荷も費用も小さい
  • 奥のDBまで行くほど、遅く・高い(勾配で理解する)

経費アプリの領収書サムネイル

経費アプリの領収書サムネイル

公開済みの経費アプリで具体的に考えます。申請画面に並ぶ領収書のサムネイル画像は、静的なファイルの代表です。これをCDNから配るようにすると、まず利用者の近くから届くのでS-07の読み込みが速くなります。同時に、サーバーが毎回画像を返さずに済むので負荷が下がります。さらに、S-10で扱う転送の費用も下がります。速さ、負荷、費用の3つが一度に良くなる、一石三鳥の代表例です。

このスライドのポイント

  • 公開済みの経費アプリ。申請画面の領収書サムネイルは静的ファイルの代表
  • CDNから配ると、S-07の読み込みが速くなる
  • サーバーが毎回画像を返さずに済み、負荷が下がる
  • S-10の転送費用も下がる → 速さ・負荷・費用の一石三鳥

サンプル: 階層図と設計表

サンプル: 階層図と設計表

今回のサンプルは、キャッシュ階層の図と、その設計表です。図は、利用者から奥へ向かう4つの層を矢印で並べたものです。設計表は、何をどの層でキャッシュするかを整理します。静的ファイルはCDNで長めに、自分だけの一覧はアプリ層に置いて操作のたびに再検証し、他人に見せてはいけないものは共有キャッシュに置かない、という3つの方針が読みどころです。AIへの質問例としては、このアプリのキャッシュ設計を階層ごとに提案してください、個人データが共有キャッシュに乗る危険はありませんか、と尋ねます。

このスライドのポイント

  • 種別: diagram(キャッシュ階層図+設計表)
  • 目的: 何をどの層でキャッシュするかの設計判断を可視化する
  • サンプル本体:

速くならない vs 更新されない

速くならない vs 更新されない

混同しやすいのは、速くならない、と、更新されない、という正反対の2つの症状です。速くならないのは、キャッシュが効いていない状態です。反対に、更新されないのは、キャッシュが効きすぎている状態です。どちらも原因はキャッシュの設計にあり、調整するレバーは同じ2つ、つまりキャッシュを保つ期間と、I-10で学んだ再検証のかけ方です。症状は逆でも、触る場所は同じだと覚えてください。

このスライドのポイント

  • 「速くならない」=キャッシュが効いていない
  • 「更新されない」=キャッシュが効きすぎている
  • どちらも原因はキャッシュ設計。症状は正反対でも触る場所は同じ
  • 調整レバーは2つ: 保つ期間 と 再検証(I-10)のかけ方

個人データを共有キャッシュに乗せない

個人データを共有キャッシュに乗せない

バイブコーディングでの確認点です。個人情報を含む応答に、CDNのような共有キャッシュが効いていないかを必ず確認してください。ここを見落とすと、ある利用者のために保存された経費の一覧が、別の利用者に配られてしまう、という事故が起こりえます。他人の経費が見えてしまう、まさにQ章で守ってきた情報の切り分けが、キャッシュの層でも問われます。Q-05のアクセス制御と並ぶ、もう一つの守りとして確認しましょう。AIには、この応答は利用者ごとに違う内容を含みますか、共有キャッシュに乗らない設定になっていますか、と聞きます。

このスライドのポイント

  • 個人情報を含む応答に、CDN等の共有キャッシュが効いていないかを必ず確認
  • 見落とすと、ある利用者の経費一覧が別の利用者に配られる事故になる
  • 他人の経費が見える危険。Q章の情報の切り分けがキャッシュ層でも問われる
  • Q-05のアクセス制御と並ぶ、もう一つの守り
  • 質問例:「この応答は利用者ごとに違う内容を含みますか。共有キャッシュに乗らない設定ですか」

まとめと次回

まとめと次回

一問一答です。静的なファイルを、利用者の近くから配る仕組みを何と呼ぶでしょうか。(間)答えはCDNです。30秒でまとめます。キャッシュには階層があり、手前で返せるほど速く安くなります。何をどの層で、どれだけの期間再利用するかを設計し、個人データが共有キャッシュに乗らないことを必ず確かめる。これが今回の要点です。次回のS-09では、最悪の日に備えるバックアップと復旧を、目標値という形で扱います。関連資料は、アプリ運用チェックリストと、AI利用料の見積もり入門です。

このスライドのポイント

  • 一問一答:「静的ファイルを利用者の近くから配る仕組みは?」→ CDN
  • 30秒まとめ: 階層は手前で返せるほど速く安い/何をどの層でどれだけ再利用するかを設計/個人データは共有キャッシュに乗せない
  • 次回S-09: 最悪の日に備えるバックアップと復旧の目標値(RPO・RTO)へ
  • 関連資料: 「アプリ運用チェックリスト」「AI利用料の見積もり入門」