CDNセルフホスト構築ガイド｜Varnish/Nginx実践キャッシュ

CDN セルフホスト構築ガイド｜Varnish/Nginx 実践キャッシュ

現代の Web 環境において、コンテンツ配信ネットワーク（CDN）は単なるオプションではなく、ユーザー体験を決定づける必須インフラとなっています。2025 年後半から 2026 年初頭にかけて、Web サイトへのトラフィックが劇的に増加し、特に動画や高解像度画像を含むメディアサイトでは、オリジンサーバーの負荷管理が最重要課題となりました。従来の商用 CDN 利用も有効ですが、コスト増大やデータ主権の問題から、自社のサーバー環境で CDN キャッシュを構築する「セルフホスト型 CDN」への関心が急激に高まっています。本稿では、2026 年 4 月時点の最新技術に基づき、Varnish Cache や Nginx を活用した高度なキャッシュシステムの実践的構築方法を解説します。

特に重要なのは、単にファイルを保存するだけでなく、動的コンテンツにおける最適化や、バックエンド障害時のフェイルオーバー設計まで含む包括的なアーキテクチャです。Varnish Cache 7.5 以降の機能である Grace Mode や Saint Mode を活用し、サーバーダウン時にキャッシュを維持してユーザーにエラーページを表示させない「高可用性」を実現する手法や、Nginx の proxy_cache を用いた階層型キャッシュ設計など、実運用で即座に適用可能な設定値を多数提示します。また、Apache Traffic Server 9.x や KeyCDN、Cloudflare Free といった商用 CDN との比較を通じて、自社の状況に最適な解決策を選択するための判断基準も明確に示します。

本ガイドはシステム管理者や Web デベロッパーを対象としていますが、技術用語については初出時に簡潔な説明を付記し、初心者でも理解できるように配慮しています。例えば「PoP（ポイントオブプレゼンス）」とは、CDN 事業者が各地域に設置したキャッシュサーバーの拠点であり、ユーザーに近い場所からコンテンツを届けることで遅延時間を削減する仕組みです。2026 年現在、このような用語はインフラ設計において日常的に使用される基礎知識となっています。具体的な数値スペックや製品名を交えながら、読者が実際に手を動かして構築できるレベルの情報を提供します。最終的には、月額コストを抑制しつつ、キャッシュヒット率を 95% 以上を目指すためのロードマップを示すことを目指しています。

CDN の仕組みとセルフホストのメリット・デメリット

CDN を構築する前に、その本質的な仕組みと、なぜセルフホストが検討されるのかを深く理解する必要があります。CDN の基本機能は、ユーザーから最も地理的に近いサーバー（PoP）にコンテンツを保存し、オリジンサーバーへの直接アクセスを防ぐことです。これにより、ネットワークの遅延（レイテンシ）を削減し、同時接続数が多い場合でもオリジンサーバーがダウンするリスクを軽減します。2026 年時点では、HTTP/3 の普及によりプロトコルレベルでの転送効率も向上しており、CDN によるパフォーマンス改善効果は、従来の TCP ベースの通信と比較して約 30% から 40% の速度向上が期待されています。

セルフホスト型 CDN は、自社のデータセンターやクラウド環境（AWS EC2、Hetzner など）にキャッシュサーバーを配置する方式です。最大のメリットはコスト管理とデータの完全な支配権にあります。商用 CDN である KeyCDN や Cloudflare Pro を利用する場合、転送量に応じた課金が発生します。例えば、月間 10TB のトラフィックがある場合、Cloudflare Pro Plan では月額約 2,000 ドル（約 30 万円）程度が相場ですが、自社のサーバーで構築すれば、EC2 m5.large インスタンスを複数台用意するだけで月額数万円で済む可能性があります。特に帯域幅コストが高い地域や、大量の画像・動画データを扱うメディアサイトにおいて、このコスト差は経営戦略に直結します。

一方で、セルフホストには明確なデメリットが存在します。それは「地理的な分散」の難しさです。商用 CDN は世界中に数百もの PoP を展開しており、ユーザーがどこからアクセスしても最適なノードにルーティングされます。一方、セルフホストでは自社サーバーがある特定の地域（例：東京リージョン）に集中する傾向があります。これにより、海外からのアクセスには高い遅延が生じるリスクがあります。これを弥补するため、マルチオリジン構成や DNS ラウンドロビンを用いた負荷分散が必要となりますが、運用コストは依然として高くなります。また、DDoS 攻撃への耐性も商用 CDN に劣ります。Cloudflare の無料プランでも DDoS 保護機能がついていますが、セルフホストでは WAF（Web アプリケーションファイアウォール）の独自構築や、専門的なインフラ業者との連携が求められます。

下表に、主要なキャッシュ方式と特徴を比較しました。これらを踏まえて、自社のトラフィック特性に合わせて設計方針を決定します。

この比較から分かるように、コストとパフォーマンスのバランスをどこに取るかが設計のポイントです。2026 年のトレンドとして、完全にセルフホストにするのではなく、一部で商用 CDN を使いながら、コアなコンテンツは Varnish でキャッシュする「ハイブリッド構成」が注目されています。例えば、ヘッダー画像や CSS/JS ファイルを Cloudflare Free に任せ、ユーザー個別のデータや高額な動画を自社サーバー上の Varnish で制御することで、セキュリティとコストを両立させる手法です。

また、CDN を構築する際の指標として「キャッシュヒット率」が重要です。これは、オリジンサーバーへのリクエストに対し、キャッシュサーバーから応答した割合を指します。理想的には 90% 以上を目指すべきですが、動的コンテンツ（ショッピングカートやログイン画面など）が含まれるサイトでは 50% を下回ることもあります。Varnish や Nginx の設定を工夫することで、この率を劇的に改善可能です。例えば、Cookie ヘッダーの扱いを適切に設定し、ユーザー固有のデータ以外をキャッシュ対象とすることで、ヒット率を向上させることができます。

Varnish Cache 7.5+ の実践的設定と高度機能解説

Varnish Cache は、世界中で最も高性能な HTTP キャッシュサーバーの一つであり、2026 年現在でもその地位は揺るぎません。特にバージョン 7.5 以降では、Grace Mode と Saint Mode が強化され、障害耐性が飛躍的に向上しました。このセクションでは、VCL（Varnish Configuration Language）を用いた具体的な設定方法を解説します。

まず、Varnish の起動と基本構造を確認します。Ubuntu 24.04 LTS サーバー上に varnish バージョン 7.5.1 をインストールし、/etc/varnish/default.vcl に設定を記述します。デフォルトの VCL は複雑すぎるため、カスタム VCL を作成することが推奨されます。ここでは、最も基本的なリクエストフローである vcl_recv サブルーチンから説明します。このサブルーチンは、クライアントからのリクエストが Varnish に到達した直後に実行され、「キャッシュに保存するか」「バックエンドに転送するか」を判断する重要な分岐点となります。

sub vcl_recv {
  # リファラーヘッダーが空の場合はスパムと判断し、キャッシュから除外
  if (req.http.referer == "") {
    return (pass);
  }

  # ユーザーエージェントに基づき、ボットを識別
  if (req.http.user-agent ~ "Googlebot") {
    return (pipe);
  }

  # パスワード付き URL はキャッシュしない（セキュリティ対策）
  if (req.url ~ "?auth=") {
    return (pass);
  }

  # デフォルトでキャッシュを許可し、バックエンドにリクエスト
  return (hash);
}

この設定では、リファラーが空のアクセスや検索ボットへの応答に対しては、キャッシュを使わずにそのまま処理する pipe モードや、パスキーワードが含まれる URL はキャッシュしない pass を指定しています。これにより、セキュリティリスクを軽減しつつ、信頼性の高いボットからのトラフィックを正しく扱います。2026 年時点では、AI ボットの増加により、ユーザーエージェントのフィルタリング精度が求められるようになっています。

次に重要なのが、バックエンドからレスポンスを受けた後に行われる vcl_backend_response サブルーチンです。ここでは、キャッシュの有効期限（TTL）や保存条件を決定します。例えば、静的な画像ファイルには 1 ヶ月、動的な HTML ページには 60 秒といった具合に、コンテンツタイプごとに異なる TTL を設定可能です。

sub vcl_backend_response {
  # ヘッダーの削除（キャッシュ安全性向上のため）
  unset beresp.http.set-cookie;
  
  # 画像は 1 ヶ月、HTML は 60 秒保存
  if (beresp.content_type ~ "image") {
    set beresp.ttl = 259200s;
  } else if (beresp.content_type ~ "text/html") {
    set beresp.ttl = 60s;
  }

  # バックエンドからのエラーレスポンスはキャッシュ保存（Saint Mode 的挙動）
  if (beresp.status == 502 || beresp.status == 503) {
    return (retry);
  }

  return (deliver);
}

この設定により、Varnish はバックエンドサーバーの応答速度やステータスコードに基づいてスマートにキャッシュを管理します。unset beresp.http.set-cookie; は、セッション ID などを含む Cookie ヘッダーをキャッシュから削除する処理であり、これを行わないとユーザーごとに異なるキャッシュが生成され、メモリエクスパンションの原因となります。

さらに、Varnish 7.5 で強化された「Grace Mode」について解説します。通常、TTL を過ぎたオブジェクトは自動的にキャッシュから削除されます。しかし、バックエンドサーバーがダウンしている場合でも、Grace Mode を有効にすることで、「古くなったキャッシュ」を一定期間（例：10 秒間）だけ返し続けることができます。これにより、ユーザーには「一時的なアクセス遅延」以外のエラーが表示されず、システム全体としての可用性が高まります。

sub vcl_backend_response {
  # Grace Mode の有効化
  set beresp.grace = 10s; 
}

beresp.grace = 10s; という設定により、バックエンドが応答できない間も、10 秒以内の過去のキャッシュを返すようになります。2026 年のインフラ運用基準では、この機能は必須レベルで推奨されており、これによりダウンタイム中のユーザー体験を維持できます。

さらに高度な設定として「Saint Mode」があります。これは、バックエンドサーバーが頻繁にエラー（5xx ステータス）を返す場合、そのサーバーを一時的にブラックリスト化し、他のバックエンドやキャッシュに振り分ける機能です。VCL 内で状態変数を用いて実装するか、Varnish の標準機能を組み合わせることで実現可能です。これにより、「壊れたサーバー」がリクエストを処理しようとしてシステム全体のパフォーマンスを低下させることを防ぎます。

Nginx FastCGI Cache とプロキシキャッシュの最適化設定

Nginx は、Varnish と並んで最も広く使用されている Web サーバーであり、その proxy_cache モジュールは強力なキャッシュ機能を提供します。特に PHP-FPM や他のバックエンドアプリケーションをホスティングする環境では、Varnish の前面に Nginx を配置し、Nginx でコンテンツキャッシュを行う構成が一般的です。2026 年時点の Nginx はバージョン 1.26 が主流であり、キャッシュ関連のパフォーマンスチューニング機能がさらに洗練されています。

Nginx のキャッシュ設定で最も重要なのは proxy_cache_path ディレクティブです。ここでキャッシュファイルの保存先と、階層構造、サイズ制限を定義します。SSD（ソリッドステートドライブ）を使用することが前提であり、HDD を使用すると I/O 待ちが発生し、Nginx のメリットが失われます。例えば、/var/lib/nginx/cache ディレクトリに設定し、キーの階層を levels=1:2 にすることで、ディスク上のファイルシステム効率を最大化します。

http {
    # キャッシュパス定義：10GB サイズ制限，レベル構造，キーキャッシュ使用
    proxy_cache_path /var/lib/nginx/cache keys_zone=myapp_cache:10m levels=1:2 use_temp_path=off max_size=10g;

    server {
        location / {
            # バックエンドサーバーへのプロキシ設定
            proxy_pass http://backend_servers;
            
            # キャッシュの使用とキー定義
            proxy_cache myapp_cache;
            proxy_cache_key "$scheme$request_method$host$request_uri";
            
            # 異なるステータスコードごとのキャッシュ有効期間
            proxy_cache_valid 200 301 302 60s;
            proxy_cache_valid 404 1m;
            
            # キャッシュが切れた際のバックエンドへのフォールバック設定
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        }
    }
}

この設定では、keys_zone=myapp_cache:10m により、共有メモリ領域に 10MB のキーテーブルを確保しています。これにより、ディスク検索回数を減らし、キャッシュヒットの判定速度が向上します。また use_temp_path=off は、一時ファイルをキャッシュディレクトリ内に作成しない設定で、セキュリティと整合性を保つための推奨設定です。

Nginx におけるキャッシュパージ（有効期限切れ前の削除）も重要な課題です。通常、TTL を待つ必要がありますが、コンテンツを更新した際に即座にキャッシュを無効化する必要があります。これには、proxy_cache_purge モジュールや Lua スクリプトを利用する方法があります。例えば、Nginx 1.26 では標準機能に近いパージ機能が強化されており、HTTP メソッド（GET/POST）に応じたパージルールを定義可能です。

location /purge {
    allow 192.168.0.5; # 管理 IP のみを許可
    deny all;
    
    proxy_cache_purge myapp_cache "$scheme$request_method$host$request_uri";
}

この設定により、特定の IP から /purge エンドポイントへのリクエストを受け取ると、該当するキャッシュを即座に削除します。2026 年では、自動的なインベントリ管理システムとの連携が主流であり、CMS が更新された際、自動的にパージ API を呼び出すプラグインやスクリプトの導入が一般的です。

また、Nginx のキャッシュはファイルシステムとの親和性が高く、SSD の書き込み寿命を考慮した設定も可能です。2026 年の NVMe SSD は高速ですが、書き込み回数に制限があります。キャッシュディレクトリを RAM デスク（tmpfs）に設定することで、ディスクの負荷を完全に排除することもできますが、サーバー再起動時にキャッシュが消えるリスクがあるため、重要なコンテンツには適さない場合があります。ハイブリッド構成として、頻繁にアクセスされるホットデータは RAM に、コールドデータを SSD に保存する階層型キャッシュ設計が推奨されます。

キャッシュ最適化技術：圧縮・WebP 変換・ESI 活用法

キャッシュの容量効率を高め、転送速度を向上させるための最適化技術も同等に重要です。現代の Web サイトは画像やスクリプトファイルが多く、帯域幅を圧迫します。これらを効果的に管理するために、Gzip や Brotli による圧縮、WebP への自動変換、ESI（Edge Side Includes）の利用が不可欠です。

まず、通信データの圧縮について解説します。Gzip は古くから使用されてきましたが、2026 年現在では Brotli がより高い圧縮率を提供する標準となっています。Brotli は Google により開発され、特にテキストベースのコンテンツ（HTML, CSS, JavaScript）で Gzip よりも約 15% から 30% のサイズ削減を実現します。Varnish や Nginx では、クライアントが Brotli をサポートしているか（Accept-Encoding ヘッダー参照）を判定し、自動的に最適化された形式を返す設定が可能です。

# Nginx での Brotli 圧縮設定例
brotli on;
brotli_comp_level 6; # 圧縮強度 1-12（6 がバランス）
brotli_static on;   # 事前に圧縮されたファイルがあれば使用
brotli_types text/plain text/css application/javascript image/svg+xml;

この設定では、brotli_comp_level 6 にすることで、CPU 負荷と圧縮率のバランスを取っています。CPU を使いすぎるとレスポンス遅延が発生するため、12 まで上げないことが重要です。また image/webp タイプも指定し、WebP 対応ブラウザ向けにも配信可能にします。

次に、画像フォーマットの最適化です。WebP や AVIF は JPG や PNG よりも高効率ですが、すべてのブラウザがサポートしているわけではありません。Nginx や Varnish を経由して、ユーザーエージェントに基づき最適なフォーマットを返す「フォーマットネゴシエーション」が必要です。2026 年では、CDN レベルでの自動変換機能が充実しており、Varnish の vcl_recv でリクエスト解析を行い、WebP 対応ブラウザであれば画像 URL を WebP 版に書き換える処理を実装します。

sub vcl_backend_response {
  if (beresp.http.content_type ~ "image/(png|jpg)") {
    # ユーザーエージェントが WebP に対応している場合、コンテンツを置き換え
    if (req.http.user-agent ~ "Chrome|Firefox") {
      set beresp.http.content-type = "image/webp";
      # バックエンドのレスポンスボディをWebPに変換する必要があるため、通常は外部ツール連携
    }
  }
}

注意すべき点は、Varnish が画像変換機能を内包していないことです。実際の実装では、バッチ処理で事前に WebP を生成し、ファイル名を変えて Nginx で配信するか、Nginx の map ディレクティブを用いて URL 置換を行う必要があります。

さらに、動的コンテンツの一部をキャッシュする「ESI（Edge Side Includes）」も有効な手法です。例えば、ショッピングカート画面において、商品リスト部分は静的で頻繁に更新されないが、ユーザー名や在庫数は動的である場合、商品リストだけを ESI タグで囲んで Varnish でキャッシュし、残りの部分はリアルタイムで取得するという構成が可能です。これにより、ページ全体の生成時間を短縮できます。

<!-- サイト側の HTML 記述例 -->
<esi:include src="/component/product-list.html" />
<h1>こんにちは、${username}さん</h1>

この ESI タグを Varnish が認識し、/component/product-list.html のレスポンスをキャッシュから取得して埋め込みます。2026 年では、ESI のサポートが標準的になり、複雑なエッジコンピューティングでも利用可能です。また、Range Request（ファイルの一部ダウンロード）のサポートも必須です。動画ストリーミングや大容量ファイル配信において、ユーザーが再生位置を指定した際、ゼロから転送するのではなく、必要な部分だけ転送する必要があります。Varnish 7.5 ではこの機能に最適化が施されており、帯域幅の節約とユーザー体験の向上を実現します。

マルチオリジン構成とフェイルオーバー設計

単一サーバー環境でのキャッシュはリスクが高いため、2026 年時点ではマルチオリジン構成が推奨されます。複数のバックエンドサーバーを用意し、1 つがダウンしても他のサーバーから応答を継続する仕組みです。これには、ロードバランサー（HAProxy や Nginx LB）と Varnish/Nginx の連携が必要となります。

フェイルオーバー設計の核心は、「障害検知」と「切り替え」の速度です。Nginx の upstream ブロックでバックエンドサーバーを定義し、max_fails=3 fail_timeout=10s といったパラメータを設定することで、連続してエラーが発生した場合に自動的にそのサーバーをオフライン扱いにします。

upstream origin_servers {
    server backend1.example.com weight=5 max_fails=3 fail_timeout=10s;
    server backend2.example.com weight=5 max_fails=3 fail_timeout=10s backup;
    
    # 健康チェックの強化
    keepalive 32; 
}

server {
    location / {
        proxy_pass http://origin_servers;
        proxy_cache myapp_cache;
        
        # バックエンド接続エラー時のリトライ設定
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
    }
}

この構成では、backend2 がバックアップサーバーとして定義されています。通常時は backend1 と backend2 の両方が処理に当たりますが（ロードバランシング）、いずれかが故障すると Nginx が自動的にリクエストを正常なノードへ振り分けます。また keepalive 32 は、Varnish やクライアントとの接続を維持し続けることで、コネクションハンドシェイクのオーバーヘッドを削減します。

さらに、DNS レベルでのフェイルオーバーも検討可能です。複数のデータセンター（例：東京と大阪）にサーバーを配置する場合、DNS ラウンドロビンや Geo DNS を利用して、ユーザーの位置に応じて最適なサーバーへ誘導します。ただし、DNS のキャッシュ期間（TTL）を短く設定しない限り、障害発生時の切り替えが即座に反映されません。TTL を 60 秒程度に設定するのが一般的ですが、2026 年では DNSSEC や Anycast ネットワークの進化により、より迅速な切り替えが可能になっています。

障害発生時のキャッシュ状態も考慮する必要があります。バックエンドサーバーがダウンしている間に、Varnish がキャッシュした古いデータを返し続ける「Grace Mode」は前述の通り有効ですが、フェイルオーバー時にキャッシュの一貫性を保つための設計も必要です。例えば、バックアップサーバーにコピーされたデータが最新であることを保証するために、レプリケーション遅延（Replication Lag）を許容する範囲内でキャッシュを更新するロジックが必要です。

商用 CDN とセルフホストのコスト・性能比較分析

コストとパフォーマンスのバランスを決定づけるため、主要な商用 CDN サービスとセルフホスト構成を詳細に比較します。2026 年現在の市場価格および技術的仕様に基づいたデータを用いて検討します。

まず、月額コストの観点から比較します。KeyCDN や Cloudflare Pro は、転送量（帯域幅）に応じた課金モデルを採用しています。月間トラフィックが 10TB を超える大規模サイトの場合、商用 CDN のコストは数万円に達します。一方、セルフホストでは AWS EC2 や Hetzner の高性能インスタンスを数台用意するだけで済むため、コスト削減効果は明確です。ただし、管理工数や人材コストを考慮すると、単純なインフラ費用の比較だけでなく、運用負荷も評価する必要があります。

性能面では、商用 CDN は圧倒的に有利です。Cloudflare や KeyCDN は世界中に数百もの PoP を展開しており、ユーザーからの距離が近い場所からコンテンツを提供できます。これに対し、セルフホストは自社サーバーの位置に依存するため、海外からのアクセスには高い遅延が発生します。特に動画配信やリアルタイム通信が必要なサービスでは、商用 CDN の利用が必須となるケースもあります。

下表に、主要な選択肢を性能とコストで比較しました。

この比較から、小規模・中規模サイトでは Cloudflare Free で十分なケースが多く、コストを重視しつつ性能も確保したい場合は AWS または Hetzner のセルフホストが推奨されます。特に、AWS EC2 m5.large インスタンス（2 vCPU, 8GB RAM）を 2 台用意し、Varnish を構成することで、月間 10TB のトラフィックまで耐えられる設計が可能です。

さらに、セキュリティの観点では商用 CDN が有利です。DDoS 攻撃や SQL インジェクションなどの Web 脅威に対して、事業者レベルの防御能力を持っています。セルフホストの場合、AWS WAF や Cloudflare WAF をプロキシとして利用し、自社のサーバーに直接攻撃が到達しないようにする「ダブルガード」構成が一般的です。

運用・監視とトラブルシューティングの実践

構築した CDN システムを安定稼働させるためには、継続的な監視と迅速なトラブルシューティングが不可欠です。2026 年時点では、リアルタイムモニタリングツールとの連携が標準となっています。Prometheus と Grafana を組み合わせた構成が最も一般的で、Varnish や Nginx のメトリクスを収集し、ダッシュボード上で可視化します。

具体的には、varnishstat コマンドや nginx_status モジュールからデータを抽出し、Prometheus Exporter に投入します。監視すべき主要な指標は「キャッシュヒット率」「リクエスト処理時間」「バックエンド接続エラー数」です。例えば、Varnish の HIT と MISS カウントを比較することで、キャッシュ効率が低下していないかを確認できます。

# Prometheus 設定例 (prometheus.yml)
scrape_configs:
  - job_name: 'varnish'
    static_configs:
      - targets: ['localhost:6082']

エラーが発生した際、ログファイルの分析が即座に行えるよう、/var/log/varnish/ や /var/log/nginx/error.log を集中ログ管理システム（ELK Stack など）に送信しておく必要があります。特にキャッシュパージ関連のエラーや、バックエンド接続タイムアウトのエラーは頻繁に発生する可能性があり、アラート設定を厳密に行うことが重要です。

トラブルシューティングの手順としてまず確認すべきは、「キャッシュが機能しているか」です。curl -I https://example.com コマンドを実行し、レスポンスヘッダーに X-Varnish や Cache-Control が見つかるかどうかを確認します。もしこれらのヘッダーがない場合、VCL 設定でキャッシュから除外されている可能性があります。

また、バックエンドサーバーが応答しない場合の処理も確認が必要です。Varnish の Grace Mode が正しく動作しているか、ログに「Grace hit」などのメッセージが記録されているかを確認します。2026 年では、AI ベストプラクティスに基づく自動修復機能も一部で実装されており、システム自体が異常を検知してキャッシュ設定を調整する動きもありますが、まだ標準的な運用ではありません。

よくある質問（FAQ）

Q1: セルフホスト CDN と商用 CDN の主な違いは何ですか？ A1: 主にコストと地理的分散性の違いです。商用 CDN は世界中に PoP を持ち、ユーザーに近い場所から配信できるため遅延が少なく、DDoS 対策も手厚いです。一方、セルフホストは自社サーバーの位置に依存するため、海外からのアクセスには遅延が生じる可能性がありますが、月額コストを大幅に抑えられ、カスタマイズ性が極めて高いです。

Q2: Varnish Cache の Grace Mode と Saint Mode はどう使い分けますか？ A2: Grace Mode はキャッシュが有効期限切れでもバックエンドからエラーが発生している場合に、古いキャッシュを返してユーザーにエラーを表示させないための機能です。Saint Mode は、特定のバックエンドサーバーが頻繁にエラー（5xx）を返す場合、そのサーバーを一時的にブラックリスト化し、他のノードへ振り分ける障害耐性機能です。両方とも高可用性設計で併用するのが効果的です。

Q3: Nginx のキャッシュパージはどのように行いますか？ A3: 通常は proxy_cache_purge モジュールや Lua スクリプトを使用して、HTTP メソッド（GET または POST）に応じたルールを定義します。管理 IP を限定し、CMS 更新時に自動的に API を呼び出すスクリプトを実装することで、手動でのパージを防ぎます。

Q4: セルフホストで海外からのアクセスが遅い場合の対策はありますか？ A4: Geo DNS や Anycast ネットワークを利用した負荷分散を検討します。また、AWS Global Accelerator などのサービスを利用して、グローバルなネットワーク経路を最適化することも有効です。あるいは、商用 CDN とハイブリッド構成にして、静的コンテンツのみを外部 CDN に委ねる方法もあります。

Q5: VCL で設定する際、最も注意すべき点は何ですか？ A5: vcl_recv におけるキャッシュ除外条件の指定と、Cookie ヘッダーの扱いに注意してください。ユーザー固有の情報（セッション ID など）が含まれる URL はキャッシュから除外し、キャッシュサイズが膨大になるのを防ぐ必要があります。また、beresp.ttl を設定する際は、コンテンツの種類ごとに適切な値を設定します。

Q6: 商用 CDN と比較してセルフホストのセキュリティリスクは？ A6: DDoS 攻撃や Web アプリケーション脆弱性に対する防御能力が低くなります。対策として、WAF（Web Application Firewall）を Varnish の前に配置するか、AWS WAF や Cloudflare WAF をプロキシとして利用する「ダブルガード」構成が推奨されます。

Q7: Nginx FastCGI Cache は PHP-FPM とどのように連携しますか？ A7: proxy_cache モジュールを使用して、バックエンド（PHP-FPM）からのレスポンスをキャッシュします。キャッシュキーには $scheme$request_method$host$request_uri を使用し、Cookie などの動的データを除外することで、静的なコンテンツのキャッシュ効率を高めます。

Q8: Apache Traffic Server はどのような場合に利用すべきですか？ A8: Yahoo! や大手プロバイダーが採用する大規模キャッシュシステム向けです。HTTP/3 やマルチプロトコルサポートに優れており、極めて大規模なトラフィック（TB レベル）を扱う場合に有効ですが、設定・運用の難易度が非常に高いため、中小規模サイトでは Varnish や Nginx の使用が推奨されます。

Q9: キャッシュヒット率が 80% を超えるようにするにはどうすればよいですか？ A9: URL パラメータや Cookie ヘッダーのフィルタリングを強化し、動的な要素を除外します。また、TTL（有効期限）を適切に設定し、バックエンドサーバーが頻繁に更新しないコンテンツに対しては長時間キャッシュを設定することでヒット率を向上させられます。

Q10: 2026 年現在の推奨されるキャッシュ戦略は何ですか？ A10: Varnish Cache 7.5+ を用いた Grace Mode 活用と、Nginx FastCGI Cache の併用が主流です。特に、動的コンテンツの一部を ESI で切り出し、静的な部分は aggressively（積極的に）キャッシュするハイブリッド構成が、パフォーマンスとコストのバランスにおいて最も推奨される戦略となっています。

まとめ

本記事では、2026 年 4 月時点の最新技術に基づき、Varnish と Nginx を活用した CDN セルフホスト構築の実践的なガイドを解説しました。以下に本記事の要点をまとめます。

• CDN の重要性: 現代 Web サイトでは、遅延時間の削減とオリジンサーバー負荷軽減のために CDN 機能が必須です。
• Varnish の活用: VCL（vcl_recv, vcl_backend_response）を用いた詳細なキャッシュ制御と、Grace Mode を用いた障害耐性の確保が重要です。
• Nginx の最適化: proxy_cache_path と proxy_cache_purge の設定により、効率的で管理しやすいキャッシュシステムを構築できます。
• コスト比較: 商用 CDN は高機能だが高額であり、セルフホストは低コストだが運用負荷が高いというトレードオフがあります。
• 監視の重要性: Prometheus や Grafana を用いたリアルタイムモニタリングが、システム安定稼働に不可欠です。

自社のトラフィック特性や予算に合わせて最適な構成を選択し、2026 年の Web インフラ環境において高いパフォーマンスと可用性を実現してください。