Skip to content

MS_CDN

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

CDN（Content Delivery Network）

概要

下記リンク先に記載。

補足（本ページはハブである）: 原文はリンク集で、
内容の本体は **開発基盤部会 Wiki（DNET_CDN.md）**側にある。
ここでは、本 Wiki の他ページから CDN が参照される文脈を
整理しておく。

参照元 文脈
ASP.NET の BundleConfig CDN フォールバック（ライブラリを CDN から取る）
ASP.NET Web Forms の Modernization ScriptManager の CDN 対応
ASP.NET MVC の Modernization ScriptBundle の CDN 対応
AzureのCDN Azure のサービスとしての CDN
ダウンロードのいろいろ 大容量配信

補足（CDN とは何をするものか）: 概要が空欄のため、
基本と、現在の実務的な要点を補っておく。

【CDN の基本】

   利用者（東京）              利用者（ロンドン）
       │                          │
       ▼                          ▼
   エッジ（東京）              エッジ（ロンドン）  ← 各地にキャッシュを置く
       │ キャッシュがなければ ↓
       └──────────┬──────────┘
                      ▼
                 オリジン（配信元のサーバ）

効果は「速さ」だけではない。

効果 内容
低遅延 物理的に近いエッジから返る（RTT が小さい）
オリジンの負荷軽減 キャッシュ ヒットした分はオリジンに届かない ★
可用性 オリジンが落ちてもキャッシュで凌げる（設定次第）
DDoS 緩和 エッジで吸収する
TLS 終端 エッジで終端し、証明書管理を集約
WAF / Bot 対策 エッジで実行できる
転送コスト クラウドの外向き通信費を抑えられる場合がある

現在は「CDN」と「エッジ」の区別が曖昧になった。

【従来の CDN】 静的ファイルをキャッシュして配るだけ
【現在】       エッジで【コードを実行できる】★
                 ・Cloudflare Workers
                 ・Azure Front Door / Functions（エッジ）
                 ・AWS Lambda@Edge / CloudFront Functions
               → A/B テスト、認証、リダイレクト、画像変換を
                 オリジンに行かずに処理できる

補足（キャッシュ設計が CDN 活用の要）: CDN を入れても
キャッシュ制御を誤ると効果が出ない、あるいは事故になる。

① キャッシュ可能なものと、してはいけないもの

対象 指定
ハッシュ付き静的ファイル（app-4f8a2b.js） Cache-Control: public, max-age=31536000, immutable ★
画像・フォント public, max-age=86400 程度
HTML 短め（public, max-age=0, must-revalidate）
API のレスポンス（個人向け） private, no-store ★
認証後のページ private, no-store 
【最も危険な事故】★
   利用者 A 向けのレスポンスを CDN がキャッシュし、
   利用者 B に返してしまう（個人情報の漏洩）

【原因】
   ・Cache-Control を付け忘れた
   ・CDN 側が既定でキャッシュする設定だった
   ・Vary ヘッダの指定漏れ（Cookie / Authorization を無視）

【対策】
   ・認証が絡むレスポンスには【必ず private / no-store】
   ・CDN 側でも「Cookie があるものはキャッシュしない」規則を入れる
   ・【既定を「キャッシュしない」にし、明示的に許可する】設計にする

② キャッシュ バスティング（更新の反映）

【問題】 長期キャッシュすると、更新が届かない

【解 1】 ファイル名にハッシュを入れる ★ 最も確実
           app-4f8a2b1c.js
           → 内容が変われば URL が変わる＝ 別ファイル扱い
           → [ASP.NET の BundleConfig](MS_ASPNETBundleConfig) の ?v= と同じ発想

【解 2】 パージ（削除）を CDN に依頼する
           → 反映に時間がかかる、API 呼び出しが要る
           → 【解 1 が使えるなら、そちらが良い】

③ HTML だけは短くする

HTML（短期キャッシュ）
  └ 参照する JS/CSS は【ハッシュ付き】（長期キャッシュ）

 → HTML さえ更新されれば、新しいファイルを参照する
 → これが現在の標準的な構成 ★

補足（第三者 CDN からライブラリを取る方式の現況）: ASP.NET の BundleConfig
でも触れたが、重要なので再掲する。

【かつての定石】
   jQuery 等を【公開 CDN】から読む
     ・高速配信
     ・【他サイトとキャッシュを共有できる】

【現在】
   ・ブラウザの HTTP キャッシュが【サイトごとに分離された】（2020 頃）
      → キャッシュ共有の利点は【失われた】★
   ・サプライ チェーン リスク（CDN が改竄されると全利用者に影響）
   ・可用性リスク（CDN 障害でサイトが壊れる）
   ・プライバシー（利用者の IP が第三者に渡る）

【現在の推奨】
   ・ライブラリは【npm で取得し、自サイトから配信する】★
   ・どうしても公開 CDN を使うなら
       <script src="..." integrity="sha384-..." crossorigin="anonymous">
     で【SRI（Subresource Integrity）】を必ず付ける

「自サイトの静的ファイルを CDN 経由で配る」ことは今も有効である。
やめるべきなのは「第三者の CDN からライブラリを借りる」方である
——この 2 つは別の話なので、混同しないこと。

補足（Microsoft Ajax CDN は提供終了）: 本 Wiki の
Modernization 系ページに登場する ajax.aspnetcdn.com は
2022 年に提供を終了している。

【既存アプリへの影響】
   ・CDN のパスが 404 になる
   ・CdnFallbackExpression により【ローカルへフォールバックする】
      → 動作はするが、毎回 404 を踏むので遅い

【対応】
   ① BundleTable.Bundles.UseCdn = false にする（最も簡単）
   ② 別の CDN（jsDelivr / cdnjs / unpkg）に差し替える

参考

AzureのCDN

移行メモ（Azure CDN の現況）: AzureのCDN に記した通り、
Verizon / Akamai の各 SKU は既にサービス終了しており、
現在は Azure Front Door（および Microsoft 標準の CDN）に統合されている。

開発基盤部会 Wiki

  • CDN（Content Delivery Network）（DNET_CDN.md）

Microsoft Learn

Tags: 移行, プログラミング, ASP.NET, ASP.NET Web API, ASP.NET SPA, JavaScript

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally