【入門編】 Cloud CDNのキャッシュキー(Cache Key)のカスタマイズ要素 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！クラウドの世界へようこそ。SREとして日夜システムの安定稼働とパフォーマンス改善に奮闘している私ですが、今回はGCP（Google Cloud）の強力な武器である「Cloud CDN」について、とても大切なお話をしたいと思います。

インフラの世界に足を踏み入れたばかりの頃は、「ロードバランサーがあって、その裏にサーバーがあって……」という基本の形を覚えるだけで精一杯ですよね。そこへ「CDN（コンテンツ配信ネットワーク）」という言葉が出てくると、「なんだか難しそうなキャッシュの仕組みだな」と身構えてしまうかもしれません。

でも、安心してください！一歩ずつ、私たちの身近な例えを交えながら優しく紐解いていきましょう。今回は、Cloud CDNのパフォーマンスを劇的に左右する「キャッシュキー（Cache Key）」のカスタマイズについて、一緒に深く見ていきたいと思います。

—

そもそも「キャッシュキー」って何だろう？

街の郵便配達員さんを想像してみてください。毎日たくさんの手紙を配っていますが、もし宛先がまったく同じ手紙が100通あったらどうでしょう？ 100通すべてをわざわざ遠くの本局から取り寄せるのは非効率ですよね。

そこで郵便配達員さんは、「この住所宛ての手紙は、さっき持ってきたからカバンの中に予備があるな。それをそのままお届けしよう！」と判断します。これがキャッシュ（Cache）の考え方です。

このとき、配達員さんが「どの手紙とどの手紙が同じ内容（中身が使い回せるもの）か」を判断するために見る宛名のラベル。これが、ITの世界でいう「キャッシュキー（Cache Key）」なのです。

Cloud CDNは、世界中に散らばるGoogleの巨大なエッジサーバー（ユーザーの最寄りの配達拠点）でキャッシュを保持します。ユーザーからリクエストが飛んできたとき、「このリクエストのキャッシュキーは何だろう？」と確認し、すでに持っていればサーバーの奥底まで取りに行かず、その場でパッと返すことで爆速の表示速度を実現しているわけですね。

—

なぜ「キャッシュキーのカスタマイズ」が必要なの？

一見、URLが同じなら同じデータを返せばよさそうに思えますよね。でも、現実のウェブアプリケーションはそんなに単純ではありません。

例えば、こんなリクエストを考えてみましょう。

1. https://example.com/item?id=100&user=taro
2. https://example.com/item?id=100&user=hanako

どちらも同じ商品ページ（id=100）を見ているのですが、クエリパラメータに含まれる user の値が違います。もし画面のどこかに「ようこそ、太郎さん！」と表示されていたとしたらどうでしょう？
ここでキャッシュキーをただの https://example.com/item?id=100 だけにしてしまうと、花子さんがアクセスしたときに、うっかり「太郎さん」向けの画面が表示されてしまう大惨事（情報漏洩やパーソナライズの崩壊）が起きてしまいますよね！

逆に、こんなケースはどうでしょう？
https://example.com/style.css?v=20231101

ウェブサイトのデザインを読み込むCSSファイルですが、末尾の ?v=... は、ブラウザに古いファイルを覚えさせないための「ただのおまじない（タイムスタンプ）」だったりします。中身はどのユーザーが見ても全く同じなのに、このおまじないのせいで「全部別々のリクエスト」とみなされてしまい、キャッシュが全然ヒットしない……なんてことになりがちなのです。

こうした「どれを同じものとみなしてキャッシュし、どれを別物として区別すべきか」をCloud CDNに教えてあげる作業が、キャッシュキーのカスタマイズなのです。

—

キャッシュキーを構成する4つの要素

Cloud CDNでは、主に以下の4つの要素を組み合わせてキャッシュキーを作り上げます。

1. リクエストURL（HostとPath）: 基本の住所（例: example.com/images/logo.png）
2. クエリパラメータ（Query Parameters）: URLの末尾につく ? 以降の情報
3. HTTPヘッダー（HTTP Headers）: ブラウザの種類や圧縮に対応しているか（Accept-Encoding など）
4. Cookie: ユーザーのログイン状態などを保持する小さなお菓子（のようなデータ）

これらを「含める（Include）」のか「除外する（Exclude）」のかを適切にコントロールすることで、キャッシュのヒット率（キャッシュがうまく使われる割合）を最大限に高めることができます。

—

実践！GCPでのキャッシュキー設定を見てみよう

それでは、実際のGCP環境でどのように設定するのか、コードや設定のイメージを見ていきましょう。
今回は、インフラの構成管理でよく使われるTerraformを使った設定例をご紹介します。もちろん、GCPのコンソール（GUI）やgcloudコマンドでも同様の設定が可能です。

以下の設定では、「画像やCSSなどの静的ファイル」を想定し、無駄なクエリパラメータやCookieをキャッシュキーから除外しつつ、画像圧縮の方式（Accept-Encoding）はちゃんと区別できるようにチューニングしています。

# Google Cloudのバックエンドサービス（Backend Service）の設定例
resource "google_compute_backend_service" "default" {
  name        = "my-web-backend-service"
  protocol    = "HTTP"
  port_name   = "http"
  load_balancing_scheme = "EXTERNAL_MANAGED"

  # Cloud CDNを有効化する
  enable_cdn = true

  cdn_policy {
    cache_mode = "CACHE_ALL_STATIC" # 静的コンテンツを積極的にキャッシュするモード
    
    # キャッシュキーのカスタマイズ設定
    cache_key_policy {
      # 1. ホスト名（ドメイン）をキャッシュキーに含めるか（通常はtrue）
      include_host = true

      # 2. プロトコル（httpかhttpsか）を区別するか
      include_protocol = true

      # 3. クエリパラメータの制御
      # ここでは、特定のトラッキング用パラメータ（utm_...など）をキャッシュキーから除外する
      # ※「include_query_parameters」または「exclude_query_parameters」で制御します
      exclude_query_parameters = [
        "utm_source",
        "utm_medium",
        "utm_campaign",
        "fbclid" # SNSのトラッキング用パラメータ
      ]

      # 4. HTTPヘッダーの制御
      # ブラウザがGzipやBrotliといった圧縮に対応しているかを区別するため含める
      include_http_headers = [
        "Accept-Encoding"
      ]

      # 5. Cookieの制御
      # 静的ファイル配信なので、Cookieはキャッシュキーから完全に除外する（これを忘れるとキャッシュが激減します！）
      include_named_cookies = []
    }
  }
}

この設定のポイント（SREの現場の視点から）

  • Cookieの除外が命綱！

画像やCSSなどの静的アセットを配信するバックエンドに対して、もし Cookie をキャッシュキーに含めてしまうと、アクセスするユーザーごとに異なるCookie（セッション情報など）が付いているため、キャッシュが全くヒットしなくなります（これを「キャッシュクラッシング」と呼びます）。静的ファイル系はCookieを綺麗に除外するのが鉄則です。

  • トラッキングパラメータの排除

マーケティング担当者が広告効果測定のために ?utm_source=google のようなパラメータを付けてリンクを共有してくれたとき、これがそのままキャッシュキーに含まれてしまうと、「パラメータなしのURL」とは別のページとしてキャッシュされてしまいます。結果として同じ画像が何重にもキャッシュされ、サーバーのストレージやキャッシュ効率を無駄に圧迫してしまいます。exclude_query_parameters でこれらをスッキリ無視してあげましょう。

—

トラブルシューティング：現場でよくある「ハマりどころ」

最後に、現場のSREたちが頭を悩ませがちな「キャッシュキーにまつわる罠」をいくつかご紹介します。

1. 「なぜかキャッシュが全然ヒットしない（Hit率が数％）」

  • 原因の多くはCookieや不要なクエリパラメータです。 Cloud CDNのモニタリング画面（Cloud Monitoring）を見て、キャッシュヒット率が異常に低い場合は、大抵の場合、キャッシュキーに「ユーザーごとに変わる不要な情報」が混入しています。一度アクセスログやCloud CDNのログを覗いて、どんなキーでキャッシュが生成されているか確認してみましょう。

2. 「スマホ版とPC版でデザインが崩れる」

  • 原因はUser-Agentの扱い違い。 もしバックエンドでユーザーエージェント（User-Agent ヘッダー）を見てレスビューを切り替えている場合、キャッシュキーに User-Agent を含める必要があります。ただし、最近はレスポンシブデザイン（CSSやJavaScriptで画面サイズに合わせる手法）が主流なので、なるべくサーバー側ではなくフロントエンド側で吸収し、キャッシュキーをシンプルに保つのがモダンな設計です。

—

まとめ

今回は、Cloud CDNのキャッシュキーのカスタマイズについて、郵便配達の例えを交えながら優しく解説してみました。

  • キャッシュキーは、エッジサーバーが「同じコンテンツか」を判断するための宛名ラベル。
  • クエリパラメータやCookie、HTTPヘッダーをどう含めるか・除外するかで、キャッシュヒット率が天と地ほど変わる。
  • 静的アセットを配信するときは、Cookieを除外し、不要なトラッキングパラメータを捨てるのが基本のキ！

最初は少し難しく感じる設定項目も、背後にある「パケットやリクエストの旅」をイメージできるようになると、インフラを触るのがぐっと楽しく、面白くなってきますよ。

それでは、あなたのクラウドインフラストラクチャが今日も軽やかに、そして安定して稼働することを祈っています！また次回の技術解説でお会いしましょう。

スポンサーリンク

コメント

タイトルとURLをコピーしました