Azure Content Delivery Network

解決する課題

オリジン（配信元）から地理的に遠い利用者にも、画像・動画・スクリプトなどの静的コンテンツを低遅延で届けられます。

• 利用者の**最寄りのエッジ（POP）**からキャッシュ済みコンテンツを返し、ラウンドトリップを短縮
• キャッシュヒットでオリジンへのアクセスが減り、オリジンの負荷と下り転送コストを低減
• 急なアクセス集中（バズ・キャンペーン）でもエッジで吸収してオリジンを保護
• 独自ドメインに対する**HTTPS（証明書の自動管理）**で安全に配信

主要概念と用語

• プロファイル: CDN 設定全体の入れ物。どの**製品（プロバイダー）**でエンドポイントを作るかを束ねる単位
• エンドポイント: 配信用のホスト名（<name>.azureedge.net の形式）。キャッシュやオリジンの挙動をここで設定
• オリジン: 配信元のサーバー。Blob Storage / 静的 Web サイト / App Service / 任意の公開 HTTP ホストを指定できる
• POP（Point of Presence）/ エッジ: キャッシュと TLS 終端を行う配信拠点。世界各地に分散
• キャッシュ / TTL: エッジに保持する有効期間。オリジンの Cache-Control ヘッダや CDN 側のキャッシュルールで制御
• キャッシュキー / クエリ文字列の扱い: クエリ文字列を無視・含める・指定キーのみ、で同一性を判断
• パージ（Purge）: エッジの古いコンテンツを即時無効化（パス指定やワイルドカード）
• プリロード（事前読み込み）: 公開前に主要コンテンツをエッジへ温めておく操作
• ルールエンジン: ヘッダ書き換え・リダイレクト・キャッシュ上書きなどをエッジで適用（製品により機能差あり）

仕様・制限・クォータ

• オリジンには Blob Storage / 静的 Web サイト / App Service / 任意の公開オリジンを指定可能
• HTTPS は既定エンドポイント（*.azureedge.net）で利用でき、独自ドメインにはマネージド証明書（自動更新） または持ち込み証明書（BYOC）を選択
• TTL はオリジンの Cache-Control を尊重しつつ、CDN 側のキャッシュルールで上書き可能
• 圧縮（gzip など） や クエリ文字列のキャッシュ動作を設定可能（対応範囲は製品で異なる）
• キャッシュパージでエッジを即時無効化。反映には伝播の時間がかかる場合がある
• プロファイルあたりのエンドポイント数やカスタムドメイン数などにサブスクリプション単位の上限があり、必要に応じて引き上げ申請
• 機能の細部（ルールエンジン、配信プロトコル、対応リージョンなど）は選んだ製品/プロバイダーに依存する

内部の仕組み

利用者からの要求は、DNS と CDN プロバイダーの仕組みによって**ネットワーク的に近いエッジ（POP）**へ誘導されます。エッジでは TLS を終端し、要求された URL がキャッシュ済みかを判定します。

• キャッシュヒットなら即座にエッジから返却し、オリジンへは到達しない
• キャッシュミスならオリジンへ取りに行き（オリジンフェッチ）、応答をエッジに保存して以後の要求に再利用
• キャッシュの一意性はキャッシュキー（パス＋クエリ文字列の扱い）で決まり、TTL を過ぎると再検証またはオリジンから再取得
• 静的コンテンツはエッジで完結するため、オリジンの所在に関わらず遠方の利用者ほど効果が大きい

設計パターン / ベストプラクティス

• Blob Storage（静的 Web サイト） + CDN で静的サイトやメディアを高速配信（AWS の S3 + CloudFront 相当）
• 静的アセット（画像・CSS・JS）は TTL を長め、頻繁に変わるものはバージョン付き URLで扱う
• クエリ文字列でコンテンツが変わらないなら、クエリ文字列を無視してヒット率を高める
• リリース時はパージまたはバージョン付きパスで確実に最新を配信する
• オリジンへの直接アクセスを抑制し、配信は CDN 経由に統一してオリジン負荷とコストを下げる
• 新規・高度な要件（WAF・グローバル負荷分散・動的高速化）では Azure Front Door を選定する

運用・監視

• Azure Monitor / メトリクスでリクエスト数、キャッシュヒット率、エラー率、レイテンシ、データ転送量を監視
• 診断ログ（アクセスログ）を Log Analytics / Storage / Event Hubs に送って分析・監査
• ヒット率が低い場合は、クエリ文字列の扱い・TTL・Vary ヘッダ・Cache-Control を見直す
• 反映遅れは TTL とパージ運用、URL のバージョニング方針を点検する

コスト

課金は**送信データ転送（GB）**を中心に、リクエスト数や付加機能（ルール・カスタム証明書など）が加わります。エッジでヒットするほどオリジン側の転送・処理コストも下がります。

• 転送単価は配信先の地域ゾーンで異なる傾向があり、想定トラフィックの地理分布で見積もる
• エッジキャッシュでオリジンの下り転送・処理コストも同時に下げられる点が CDN の経済的メリット

セキュリティ

• HTTPS を強制し、独自ドメインはマネージド証明書（自動更新） か Key Vault 管理の持ち込み証明書で保護
• TLS は新しいバージョンを優先し、古いプロトコルは無効化する
• オリジンが Blob Storage の場合、匿名公開を避け、配信は CDN 経由に統一する
• トークン認証や地理フィルターなどのアクセス制限は製品により利用可否が異なるため要件に合わせて選定
• WAF などL7 防御が必要なら Azure Front Door（統合 WAF） を選ぶ

関連サービス・比較

最も近い後継・上位サービスは Azure Front Door です。純粋な静的配信なら CDN でも足りますが、WAF・グローバル負荷分散・動的高速化まで含めるなら Front Door が適します。

• AWS との対応では、Azure CDN / Front Door はいずれも Amazon CloudFront に相当します
• 純粋に静的ファイルを安く速く配るだけなら CDN で十分ですが、セキュリティや可用性まで一体で求めるなら Front Door を選ぶのが定石です

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# CDN プロファイルを作成
az cdn profile create \
  --resource-group demo-rg \
  --name demo-cdn \
  --sku Standard_Microsoft

# エンドポイントを作成（オリジンは Blob の静的 Web サイトなどを指定）
az cdn endpoint create \
  --resource-group demo-rg \
  --profile-name demo-cdn \
  --name demo-endpoint \
  --origin www.contoso-origin.com \
  --origin-host-header www.contoso-origin.com \
  --enable-compression true

# キャッシュ動作を設定（クエリ文字列を無視してヒット率を上げる）
az cdn endpoint update \
  --resource-group demo-rg \
  --profile-name demo-cdn \
  --name demo-endpoint \
  --query-string-caching-behavior IgnoreQueryString

# リリース後、エッジキャッシュを即時パージ
az cdn endpoint purge \
  --resource-group demo-rg \
  --profile-name demo-cdn \
  --name demo-endpoint \
  --content-paths "/*"