Webサーバーとアプリケーションサーバー
2種類のサーバー
Web システムの裏側は、役割の異なる2種類のサーバーで構成されるのが定番です。
| Webサーバー | アプリケーションサーバー | |
|---|---|---|
| 主な仕事 | 静的ファイルの配信、リクエストの受付・転送 | 動的な処理(プログラムの実行) |
| 返すもの | HTML・CSS・画像などそのままのファイル | DB を参照して組み立てた結果 |
| 代表例 | [[Nginx]]、Apache | Tomcat(Java)、Gunicorn(Python)、[[Node.js]] アプリ |
Webサーバーは「置いてあるファイルをそのまま返す」「来たリクエストを適切な相手に渡す」のが仕事です。一方アプリケーションサーバーは、リクエストごとにプログラムを実行し、データベースを参照してその場で応答を組み立てます。
なぜ2段構成にするのか
アプリケーションサーバーだけでも [[HTTP]] は話せますが、実運用では前段に Web サーバーを置く構成が標準です。
ブラウザ → Webサーバー(Nginx) → アプリケーションサーバー → DB
│
└ 静的ファイルはここで直接返す
- 適材適所 — 画像や CSS の配信は Web サーバーの方が圧倒的に速く、アプリサーバーを重い処理に専念させられる
- TLS終端 — HTTPS の暗号化・復号を前段でまとめて処理する
- 保護と制御 — タイムアウト・リクエストサイズ制限・アクセスログを前段で一元管理する
- 振り分け — 複数のアプリサーバーへの負荷分散([[ロードバランサ]] の役割)も担える
この「前段に立って転送する」働きはまさに [[リバースプロキシ]] です。Nginx はWebサーバーとリバースプロキシの両方の顔を持ちます。
初学者向けポイント
- フレームワーク付属の開発サーバー(
npm run devや Flask の開発サーバーなど)は本番用ではありません。本番は「Nginx +アプリサーバー」の構成に載せ替えるのが基本です - 「502 Bad Gateway」は、前段の Web サーバーは生きているが後ろのアプリサーバーと通信できないときの典型的なエラーです — この構成を知っていれば原因の切り分けができます
- クラウドのマネージドサービスでは Web サーバー層が隠れていることもありますが、内部では同じ構造が動いています
関連技術とのつながり
- [[Nginx]] — Web サーバー兼リバースプロキシの代表格
- [[リバースプロキシ]] — 前段でリクエストを受けて転送する仕組みそのもの
- [[HTTP]] — 2つのサーバーが受け渡しする共通言語
- [[ロードバランサ]] — 複数のアプリサーバーに負荷を分散する前段の機能
Q: Webサーバーの主な仕事はどれ?
- [x] 静的ファイルの配信とリクエストの受付・転送
- [ ] データベースを参照して動的に応答を組み立てること
- [ ] ブラウザ内でJavaScriptを実行すること
解説: Web サーバーは静的ファイルをそのまま返し、動的処理はアプリケーションサーバーへ転送します。
Q: 前段にWebサーバーを置く理由として本文で挙げられているのはどれ?
- [ ] データベースの正規化が自動で行われるから
- [x] 静的配信・TLS終端・アクセス制御を前段でまとめて処理できるから
- [ ] アプリケーションのソースコードが不要になるから
解説: 静的ファイル配信の高速さに加え、TLS 終端やタイムアウト制御を一元化できるのが2段構成の利点です。
Q: 「502 Bad Gateway」が示す典型的な状況はどれ?
- [ ] ブラウザのキャッシュが壊れている
- [ ] DNSの名前解決に失敗している
- [x] 前段のWebサーバーは動いているが、後ろのアプリサーバーと通信できない
解説: 502 はゲートウェイ(前段)が後段から正常な応答を得られなかったことを示すエラーです。