Webサーバアーキテクチャの変遷と責務分離における設計比較

Mon, 31 Aug 2026 10:11:19 +0900

インフラストラクチャのスケーリングにおいて、従来の単一Webサーバ上で動的スクリプト実行、TLS終端、静的ファイル配信をすべて集約して処理するモノリシックな構成は、同時接続数の急増に伴うリソース枯渇や設定の肥大化を招く要因となっていました。特にC10k問題への対応やコンテナベースのマイクロサービスアーキテクチャへの移行に伴い、Webサーバレイヤには接続処理の最小フットプリント化と責務の明確な分離が求められています。

本稿では、Apache HTTP ServerとNginxの並行性モデル（Concurrency Model）の違いを整理し、クラウドネイティブ環境においてWebサーバの責務がどのように分散・再配置されたのかを技術的視点から分析します。

並行処理アーキテクチャとI/Oマルチプレキシングの比較

両サーバの基本的な設計思想の違いは、I/Oマルチプレキシングおよびクライアント接続ライフサイクルの管理手法にあります。

Apache HTTP Server: プロセス/スレッド駆動型モデル

Apacheは伝統的にpreforkやworkerといったMulti-Processing Modules (MPM)を採用してきました。

メカニズム: クライアント接続ごとにOSレベルのプロセスまたはスレッドが割り当てられます（1 Client → 1 Worker）。
課題: 同時接続数が増加すると、コンテキストスイッチのオーバーヘッド、スレッドスタックメモリの消費が線形に増大します。特にKeep-Alive接続や低速クライアントが接続を維持している間、ワーカースレッドが専有され、新規リクエストの処理がブロックされる傾向があります。

Nginx: イベント駆動・非同期ノンブロッキングモデル

NginxはC10k問題を解決するためにゼロから設計されました。

メカニズム: 単一のマスタープロセスと、CPUコア数に応じた少数の固定ワーカープロセスで動作します。各ワーカーはLinuxのepollやBSD系のkqueueを利用した非同期イベントループを実行します。
特性: 単一のワーカープロセスが数千から数万の接続を同時に監視します。ディスクI/Oやアップストリームからの応答待ちが発生しても、ワーカーはブロックされずに他のアクティブな接続イベントを処理します。

現代のApacheでもevent MPMの導入によりKeep-Alive処理が分離され、スケーラビリティは大幅に向上していますが、リバースプロキシとしての接続集約効率においてはNginxのイベント駆動モデルが広く採用されています。

クラウドネイティブにおける責務の分離

モダンインフラでは、かつて単一Webサーバが担っていた機能が専門化された各インフラレイヤへ分散されています。

[従来のモノリシック構成]
Client ──► [ Apache HTTP Server ]
 ├── 静的ファイル配信 (Local Disk)
 ├── 動的ランタイム実行 (mod_php / mod_python)
 ├── SSL/TLS終端 (mod_ssl)
 └── ルーティング / リライト (mod_rewrite)

[モダンな責務分離構成]
Client ──► [ CloudFront / CDN ] ──► (静的アセット S3)
 │
 ▼
 [ ALB / Layer 7 LB ] ──► (TLS終端 / パスベースルーティング)
 │
 ▼
 [ Nginx (Ingress/Proxy) ] ──► (リバースプロキシ / バッファリング)
 │
 ▼
 [ Application (FastAPI/Spring Boot/Node.js) ]

アプリケーションランタイムの内蔵化

Webアプリケーションフレームワークの進化により、Webサーバモジュール（mod_php等）を介さずに、アプリケーション自体が内蔵HTTPサーバや専用のインターフェース経由でリクエストを処理する形態が主流となりました。

Java (Spring Boot): 内蔵TomcatやUndertowによるHTTP処理
Python (Django / FastAPI): WSGI (Gunicorn) や ASGI (Uvicorn) によるプロセス管理
Node.js: 内蔵libuvによる非同期イベント駆動実行

この構成において、Webサーバに求められる主たる役割は「動的コードの直接実行」から「高効率なリバースプロキシ、リクエストバッファリング、軽量なヘッダ書き換え」へとシフトしています。

リバースプロキシの実装構成例

バックエンドのアプリケーションサーバ（例: GunicornやFastAPI）へリクエストを中継するNginxの代表的なリバースプロキシ設定は以下の通りです。

# /etc/nginx/nginx.conf (主要ディレクティブ抜粋)
worker_processes auto;
events {
 worker_connections 1024;
 use epoll;
 multi_accept on;
}

http {
 include /etc/nginx/mime.types;
 default_type application/octet-stream;

 upstream backend_app {
 server 127.0.0.1:8000 max_fails=3 fail_timeout=10s;
 keepalive 32;
 }

 server {
 listen 80;
 server_name api.internal.local;

 client_max_body_size 16M;
 client_body_buffer_size 128k;

 location / {
 proxy_pass http://backend_app;
 proxy_http_version 1.1;
 
 proxy_set_header Connection "";
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_connect_timeout 5s;
 proxy_read_timeout 60s;
 proxy_send_timeout 60s;
 
 proxy_buffering on;
 proxy_buffer_size 8k;
 proxy_buffers 8 8k;
 }
 }
}

Troubleshooting

🛠️ リバースプロキシ構成の導入時に直面しやすい典型的な問題と対応策です。

1. HTTP/1.1 Keep-Alive接続の切断による502 Bad Gateway

事象: バックエンドとNginx間の通信で突発的な502 Bad Gatewayが発生する。
原因: Nginxはデフォルトでアップストリーム通信にHTTP/1.0を使用し、リクエストごとに接続を閉じます。また、バックエンド側のKeep-AliveタイムアウトがNginx側より短い場合、切断のタイミング競合が発生します。
対策: upstreamブロック内でkeepaliveディレクティブを指定し、location内でproxy_http_version 1.1;およびproxy_set_header Connection “”;を明示してヘッダクリアを実行します。

2. クライアントIPアドレスの消失

事象: アプリケーションログでクライアントの送信元IPがすべてリバースプロキシのIP（127.0.0.1等）として記録される。
原因: L7プロキシがTCP接続を終端して新規パケットを再生成するため、IPパケットヘッダの送信元が書き換わります。
対策: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;を設定し、バックエンドフレームワーク側でTrusted Proxies設定を有効化します。

検証コマンドプロトコル

設定反映後のNginx動作状態およびポートバインドの検証出力例です。

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

$ sudo systemctl reload nginx

$ ss -tulpn | grep nginx
tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=10421,fd=6),("nginx",pid=10420,fd=6))

$ curl -I -H "Host: api.internal.local" http://127.0.0.1/
HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Mon, 31 Aug 2026 09:15:20 GMT
Content-Type: application/json
Content-Length: 42
Connection: keep-alive

Findings

💡 WebインフラにおけるApacheからNginxへのシフトは、単なるソフトウェアの優劣ではなく、インフラ設計のパラダイムシフト（単一サーバ集中型からクラウドネイティブな責務分散型への移行）に起因しています。

Apacheの適用領域: ディレクトリ単位の設定（.htaccess）を多用する共用ホスティング環境や、CMS（WordPress等）の実行環境においては依然として実用的な選択肢です。
Nginxの適用領域: マイクロサービスにおけるAPI Ingress、独立したアプリケーションランタイムの前段に配置する高スループットなリバースプロキシとして機能します。

システムのトラフィック特性、コンテナ化の有無、静的アセットの配信経路に応じ、適切なレイヤ設計を選択することが重要です。

C10k-Problem on K-Life Hack | システムアーキテクチャ & DevOps