本稿では、現代のWebサービス運用において頻出する補助的インフラ構成要素——ロードバランサ、リバースプロキシ、CDN、オブジェクトストレージ（OSS）、およびWAF——の役割と実装上の影響を技術的観点から整理します。各要素は単体でも有用ですが、実際の環境では複数が連携して動作することが一般的です。

ロードバランサ

ロードバランサは、受信したHTTPリクエストを複数のバックエンドサーバー間で動的に分散させるミドルウェアまたは専用デバイスです。同一アプリケーションを複製した複数のインスタンスにトラフィックを振り分けることで、可用性の向上（障害時フェイルオーバー）とスケーラビリティの確保が可能になります。ただし、クライアント側からは一貫したエンドポイント（例：https://api.example.com）にアクセスしても、実際の応答元IPアドレスはリクエストごとに異なる可能性があります。これはセッション維持（sticky session）や共有状態管理（例：Redisによるセッションストア）といった追加設計が必要となる理由の一つです。

リバースプロキシ

リバースプロキシは、クライアントからの要求を受け取り、内部のアプリケーションサーバーに転送する中継役です。これにより、バックエンドの構成（ホスト名、ポート、SSL終端位置など）を隠蔽でき、セキュリティと運用柔軟性が高まります。代表的な実装としてNginxやTraefikがあり、以下のような最小限の設定例でbilibiliへのプロキシを実現できます：

upstream bilibili_backend {
    server i0.hdslb.com:443;
}

server {
    listen 8080;
    location / {
        proxy_pass https://bilibili_backend;
        proxy_set_header Host i0.hdslb.com;
        proxy_ssl_verify off;
    }
}

この構成では、クライアントはhttp://localhost:8080へアクセスしますが、実際の通信先はi0.hdslb.comとなり、Nginxが中継・変換を行います。

CDN（コンテンツ配信ネットワーク）

CDNは、静的アセット（画像、CSS、JavaScript、動画など）を地理的に分散されたエッジノードにキャッシュし、ユーザーに最も近いノードから配信する仕組みです。これにより、オリジンサーバーへの負荷低減と応答速度向上が達成されます。ただし、CDNは通常、動的リクエスト（POST、ログイン処理など）をオリジンへ透過的に転送するため、オリジンサーバーのIPアドレスは直接見えず、代わりにCDNのエッジIPが記録されます。そのため、アクセス制御やログ分析ではX-Forwarded-Forヘッダを信頼する必要があります。

OSS（オブジェクトストレージサービス）

OSSは、HTTP経由でアクセス可能な非構造化データ保存サービスです（例：AWS S3、Aliyun OSS、MinIO）。ファイルのアップロード／ダウンロードのみを提供し、実行環境（PHPインタプリタ、Pythonランタイムなど）を一切備えていません。この特性により、従来のWebサーバー上での「不正なPHPシェルのアップロード→直接実行」のような脆弱性は、OSSを用いた静的ファイルホスティングでは根本的に発生しません。例えば、Cloudreveを介してOSSをマウントした場合、ユーザーがアップロードしたファイルはすべてS3互換API経由でオブジェクトとして保存され、ブラウザからのアクセスはGETリクエストによるダウンロードのみに限定されます。

WAF（Webアプリケーションファイアウォール）

WAFは、HTTP/HTTPSトラフィックをリアルタイムで検査し、SQLインジェクション、XSS、ディレクトリトラバーサルなどの攻撃パターンを検知・遮断するセキュリティ層です。展開形態は主に三種類あります：

• ハードウェア型：物理アプライアンス（例：FortiWeb、Palo Alto WAF）
• ソフトウェア型：OS上で動作するスタンドアロンサービス（例：Chaitin SafeLine（雷池））
• クラウド型：SaaS形式で提供されるマネージドWAF（例：Cloudflare WAF、Aliyun Anti-Bot）

いずれの場合も、WAFは必ずオリジンサーバーの直前に配置され、すべての入力トラフィックを経由させることで効果を発揮します。したがって、WAFは本質的にリバースプロキシとして機能しており、アプリケーションサーバーのログにはWAFのIPアドレスしか記録されません。

実践例：Docker環境でのWAF統合

WebGoat（脆弱性学習用プラットフォーム）を対象に、SafeLine WAFを導入する手順の一例を示します。

1. WebGoatコンテナ起動（ポート8080公開）：

docker run -d --name webgoat -p 8080:8080 webgoat/webgoat-8.0

2. SafeLineの自動インストール（推奨：事前にDockerを別途インストール済みであること）：

wget -qO- https://waf-ce.chaitin.cn/release/latest/setup.sh | bash

3. WAF管理コンソール（デフォルトhttps://<host>:9443）より、WebGoatのオリジンとしてhttp://host.docker.internal:8080を登録
4. SQLインジェクションペイロード（例：' OR '1'='1）を送信すると、WAFのダッシュボード上で即時検出・ブロックが確認できます