はじめに
この章では、本ドキュメントの目的と読み方をやさしく説明します。
目的
本書は、CDN（コンテンツ配信ネットワーク）とリバースプロキシの違いと関係性をわかりやすく整理することを目的とします。両者の基本的な役割、セキュリティや性能への影響、運用で注意すべき点を具体例を交えて解説します。
想定読者
ウェブ運用担当者、エンジニア、システム設計に関心がある方を想定します。専門用語は必要最小限にとどめ、はじめて学ぶ人でも理解できるよう配慮しています。
本書の構成（全7章）
第1章 はじめに
第2章 リバースプロキシとは
第3章 CDNとは
第4章 リバースプロキシとCDNの関係性
第5章 ロードバランサーとの関係
第6章 SSL/TLS証明書の配置
第7章 キャッシュ制御の複雑性
読み方のヒント
まず第2章・第3章でそれぞれの役割をつかんでください。その後に関係性や実運用（第4章以降）を読むと理解が深まります。具体例や図を交えて説明しますので、実務に役立ててください。
リバースプロキシとは
概要
リバースプロキシは、クライアント（利用者）とバックエンドサーバーの間に立ち、利用者からのリクエストを受けて適切なサーバーに渡し、応答を返す仲介役です。利用者は背後にあるサーバーの構成やIPアドレスを直接知りません。たとえば、複数台のアプリサーバーの前に1台のプロキシを置いて、訪問者は常にそのプロキシとだけ通信します。
主な機能
- IPアドレスの隠蔽：クライアントはバックエンドの住所を見ません。これにより直接攻撃を受けにくくなります。
- ロードバランシング：リクエストを複数のサーバーに振り分け、負荷を分散します。簡単な例は順番に振る「ラウンドロビン」です。
- ファイアウォール的な役割：不正なリクエストを弾いたり、アクセス制御を行ったりできます。
- キャッシュ：静的なコンテンツを一時保存して高速に返せます。
- SSL/TLS終端：暗号化の処理をプロキシ側で行い、バックエンドの負担を減らせます。
セキュリティ面の利点
SSL/TLSで通信を暗号化することで盗聴を防ぎます。リバースプロキシがバックエンドの存在を隠すため、直接狙われにくくなります。DDoS対策機能やレート制限を組み合わせると防御力が高まります。しかし、プロキシ自体が攻撃対象になる点には注意が必要です。
動作の流れ（簡単な例）
- 利用者がブラウザでアクセス
- リクエストはリバースプロキシへ到達
- プロキシが負荷状況などに応じてバックエンドに転送
- バックエンドは応答を返し、プロキシが利用者に返却します
注意点
リバースプロキシを入れると管理が一つ増えます。単一障害点を避けるため冗長化が望ましいです。バックエンドはプロキシ経由のヘッダー情報を正しく扱う必要があります。
CDN（コンテンツ配信ネットワーク）とは
概要
CDNは、アクセスが集中するウェブサイトやサービスの表示を速く、安定させるための仕組みです。世界各地に置かれた「エッジサーバー」がユーザーに近い場所から静的な画像や動画、配布ファイルを配信します。これにより、元のサーバー（オリジン）への負荷を下げられます。
仕組み（やさしい例）
あなたが東京からあるサイトにアクセスすると、CDNは東京近くのサーバーに保存されたコピーを返します。結果としてデータの移動距離が短くなり、表示が速くなります。もしそのコピーがなければ、エッジサーバーがオリジンから取得して配信します。
利点
- 表示速度の向上：ユーザーの近くから配信するので体感が速くなります。
- 可用性と冗長性：あるエッジが落ちても別のエッジが対応しやすいです。
- 帯域幅コスト削減：オリジンからの転送を減らせます。
使い方の例と注意点
動画配信やニュースサイトでよく使われます。静的なファイルは特に効果が高いです。一方で、会員向けの動的なページはキャッシュの設計を工夫する必要があります。SSL/TLS対応やキャッシュの更新（差し替え）についても設定を確認してください。
リバースプロキシとCDNの関係性
概要
CDNは多数のエッジサーバーを使って、ユーザーに近い場所でコンテンツを配信します。技術的には、CDNは各エッジでリバースプロキシの役割を果たし、オリジンサーバーとユーザーの間に立って処理を行います。
具体的な機能と例
- コンテンツキャッシュ：静的ファイルをエッジに置き、配信を速くします。たとえば画像やCSSがすぐ届くイメージです。
- オリジンのエミュレーション（オリジンシールド）：エッジが一時的に応答することで、オリジンサーバーの負荷を減らします。
- セキュリティ（WAFやボットブロック）：悪意あるアクセスをエッジで弾くため、内部サーバーを守れます。
- A/Bテストやリライト：リクエストを加工して、異なるバージョンを配ることができます。
なぜリバースプロキシが基盤か
リバースプロキシは「受け取って代わりに配る」役割を持ちます。CDNはその機能を世界中に分散し、高速化・可用性・セキュリティを拡張します。
運用上のポイント
キャッシュの有効期限やTLS終端の場所は設計で決めます。誤ると最新データが届かない、あるいは認証が問題になる場合があります。運用時はキャッシュ設定と証明書の配置を確認してください。
ロードバランサーとの関係
概要
ロードバランサーはリバースプロキシの一種です。クライアントには単一の仮想IPを提示し、実際の処理は複数のアプリケーションインスタンスへ分配します。これにより可用性と応答性を高めます。
主な役割
- 接続先の選定：負荷や状態に応じてサーバーを選びます。
- 継続的な監視：各インスタンスの応答を定期的に確認します。
- セッション管理：同じ利用者を同じインスタンスに割り当てる設定（スティッキーセッション）を行えます。
負荷分散の方法（具体例）
- ラウンドロビン：順番に振り分けます。設定が簡単で均等分配に向きます。
- 最小接続数：今接続が少ないサーバーに向けます。動的な負荷に強いです。
- サーバーの重み付け：性能差に合わせて振り分けます。
ヘルスチェックと監視
ロードバランサーは定期的にヘルスチェックを行い、応答がないインスタンスを自動で外します。ログやメトリクスを収集して異常を早期発見します。
注意点と運用
暗号化や認証をどこまで担わせるか、キャッシュやセッションの扱いをどうするかを設計で決めます。複数の機能を同時に持たせると運用が複雑になります。したがって、役割を分けて導入することをおすすめします。
SSL/TLS証明書の配置
なぜエッジとオリジンの両方に必要か
ユーザーのブラウザはまずエッジ（リバースプロキシやCDN）と暗号化通信を行います。つまり最初に見える証明書はエッジ側のものです。一方、エッジからオリジンサーバーへも安全に接続する必要があり、そのためオリジン側にも証明書を用意します。簡単に言えば“表通りの鍵”と“裏口の鍵”を両方用意するイメージです。
よくある配置パターン（具体例）
- TLS終端（エッジで復号）: ユーザー→エッジは暗号化、エッジ→オリジンは平文か再暗号化。設定が簡単で処理が速くなります。
- TLS再暗号化（エッジで終端し再接続）: エッジとオリジン双方に証明書を置きます。セキュリティが高く、内部通信も暗号化されます。
- TLSパススルー: エッジが暗号化を透過させ、オリジンが直接終端します。オリジン証明書だけで済む場合があります。
証明書の種類と運用
- 公開CA発行: ブラウザにそのまま信頼されます。Let’s Encryptが代表例です。
- 内部CA/自己署名: オリジン間の認証に十分です。公開向けには向きません。
自動更新（ACMEなど）を導入し、期限切れを防ぎます。
実務上の注意点
- 秘密鍵は厳重に管理してください。
- SNI設定とホスト名が一致しているか確認します。
- エッジとオリジン間で相互TLS（mTLS）を使うとさらに安全です。
キャッシュ制御の複雑性
概要
CDNやリバースプロキシでのキャッシュ制御は、単にCache-Controlヘッダーを付けるだけでは済みません。エッジとオリジンで振る舞いが異なったり、実装差が存在したりします。
Cache-Controlの基本と実例
よく使う指示は max-age（例: max-age=3600）、s-maxage（CDN向け）、no-cache、no-store です。例: 静的ファイルは max-age=86400、APIは no-cache にするなど運用で分けます。
エッジとオリジンの矛盾
CDNがオリジンより短い期限でキャッシュしたり、独自に圧縮して配信することがあります。結果としてブラウザやエッジで見える内容がずれる場合があります。
更新・一貫性の戦略
即時反映が必要ならパージ（invalidate）やバージョン付与（cache busting: ファイル名にバージョンを入れる）を使います。段階的ロールアウトでは短いTTLとstale-while-revalidateを併用すると滑らかに更新できます。
キャッシュキーとVary
URLだけでなくクエリ、ヘッダー（特にVary）やクッキーでキャッシュが分かれます。意図しないキャッシュミスや過剰なキャッシュ膨張に注意してください。
実例（急ぎの更新）
1) 新しい画像を即時反映したい：ファイル名にハッシュを付ける。
2) APIの仕様変更で即座に古い応答を捨てたい：CDNでパージを実行。
運用のポイント
ログでヒット率とパージ頻度を監視し、指示を単純に保つと運用しやすくなります。テスト環境で実際のヘッダー挙動を確認してから本番運用してください。
