はじめに
目的と概要
本ドキュメントは、Webサーバーとアプリケーションサーバーの違いや役割、機能、処理の流れを分かりやすく解説することを目的としています。専門用語は最小限にし、具体例や図的な説明で理解を助けます。
なぜ重要か（簡単な例）
Webサーバーを「店の受付」、アプリケーションサーバーを「厨房」と例えると分かりやすいです。受付は来客を受け入れ案内します。厨房は注文を受けて料理を作ります。両者の役割を区別すると、性能改善や障害対策が効率的になります。
本書の構成と読み方
全9章で、基本定義、3層構造での位置づけ、具体的機能、代表例、処理フロー、最後に本質をまとめます。まず第2章で基礎を確認し、その後で実践的な話に進むと理解しやすいです。
対象読者
システム設計者、開発者、運用担当者、ITに関心のある方が対象です。基礎知識がなくても読み進められるよう配慮しています。
Webサーバーとアプリケーションサーバーの基本定義
概要
Webサーバーはブラウザからのリクエストを受け、HTML・画像・CSSなどの静的ファイルを返します。アプリケーションサーバーはプログラムを実行して、動的に作ったページやデータを返します。両者は役割を分担して動きます。
Webサーバー（静的コンテンツ）
ファイルそのものを渡す役割です。例：サイトのロゴ画像、固定のHTMLページ、CSS。処理が軽く高速に配信できます。代表的な例はNginxやApache（設定次第で動的処理も受け渡します）。
アプリケーションサーバー（動的コンテンツ）
プログラム（Ruby、Java、PHPなど）を実行して、利用者ごとに変わる内容を作ります。例：ログイン認証、商品リストの検索、注文処理。内部でデータベースに問い合わせて結果を組み立てます。
両者のやり取り（簡単な流れ）
- ブラウザがURLへアクセス。
- Webサーバーが静的なら直接返す。
- 動的な処理が必要ならWebサーバーがアプリケーションサーバーに渡す。
- アプリケーションサーバーが処理して応答を返す。Webサーバーがブラウザへ返却します。
具体例で比較
・静的：会社案内の固定ページはWebサーバーだけで完結します。
・動的：会員ページはアプリケーションサーバーが個人情報を組み合わせて生成します。
Web3層構造における位置付け
全体像
Webシステムは一般に3つの層で分けて考えます。プレゼンテーション層（Webサーバー）、アプリケーション層（アプリケーションサーバー）、データ層（データベースサーバー）です。各層は役割を分担し、全体として利用者にサービスを提供します。
アプリケーションサーバーの位置
アプリケーションサーバーはWebサーバーとデータベースサーバーの間に位置する中間層です。利用者のブラウザからのリクエストはまずWebサーバーで受け取り、静的なファイルは直接返し、動的処理が必要な場合はアプリケーションサーバーに渡します。アプリケーションサーバーは業務ロジックを実行し、必要なデータをデータベースから取得してレスポンスを作成します。
具体的なやり取りの例
例えば、会員情報の表示では次のように進みます。ブラウザ→Webサーバー（静的は直接返す）→アプリケーションサーバー（ログイン確認や処理）→データベース（会員データ取得）→アプリケーションサーバー（表示用に整形）→Webサーバー→ブラウザ。ここでアプリケーションサーバーは認証や計算、外部サービスとの連携などを担当します。
注意点
アプリケーションサーバーを設置することで処理を分散できますが、設計が複雑になります。負荷分散やセッション管理、セキュリティ設計を意識して構築すると運用が楽になります。
役割と処理内容の違い
静的コンテンツの配信（Webサーバー）
Webサーバーは主にHTML、CSS、画像、JavaScriptなどのファイルをそのまま返します。リクエストを受け取り、該当ファイルを探してHTTPで送り返す単純で高速な役割です。例として、ブラウザが画像を読み込むときは大抵Webサーバーが応答します。
動的コンテンツの生成（アプリケーションサーバー）
アプリケーションサーバーは業務ルールや計算、データベースへの問い合わせを実行して、画面やAPIの応答を作ります。例えば、ログイン処理や商品の在庫確認、注文処理などの流れをここで扱います。テンプレートにデータを差し込んでHTMLを生成することも多いです。
実行形式と扱うプロトコルの違い
Webサーバーは主にHTTPでのファイル送受信を担当します。アプリケーションサーバーはHTTPに加え、データベース接続やメッセージキューなど別のプロトコルやライブラリを使い、内部でプログラム（例：Java、Python、Ruby）を実行します。プロセスの立て方やスレッド管理にも違いがあり、負荷のかかる処理はアプリケーションサーバー側で処理します。
分担の具体例
・静的ファイルはWebサーバーが返し、APIやログイン処理はアプリケーションサーバーが実行します。
・Webサーバーがリバースプロキシになり、動的処理はアプリケーションサーバーへ転送する構成が一般的です。
これらの違いを理解すると、どの処理をどちらに任せれば効率的かが見えてきます。
アプリケーションサーバーの具体的な機能
この章では、アプリケーションサーバーが現場で実際に担う主要な機能を、できるだけ分かりやすく説明します。具体例を交えて、日常の操作がどのように裏で処理されるかを示します。
プログラム実行機能
アプリケーションサーバーは業務ロジック（ビジネスロジック）を実行します。たとえば、ログイン認証や商品の価格計算、フォームの入力チェックなどです。ブラウザからのリクエストを受け、必要な計算や判断を行って結果を返します。出力はHTMLやJSONなどで、画面表示やAPIの応答になります。
データベース連携機能
データの読み書きをデータベースに依頼します。商品一覧を取り出す、注文情報を保存するといった操作が該当します。アプリケーション側の命令を適切なデータ操作に変換し、結果を受け取って利用しやすい形で返します。ORM（オブジェクトと表の橋渡し）を使う場合もありますが、技術的にはデータの出し入れを仲介する役割です。
コネクション管理機能
データベースや外部サービスとの接続を効率よく管理します。接続を都度作ると時間がかかるため、使い回す仕組み（接続プール）を使ってパフォーマンスを上げます。複数の利用者から同時にアクセスが来ても、接続数を適切に振り分けて安定した応答を保ちます。
トランザクション管理機能
複数の処理を一つのまとまりとして扱い、全部が成功したときだけ確定します。たとえば注文処理では在庫の減少と注文情報の保存を同時に行いますが、どちらかが失敗したら処理を元に戻します。これによりデータの矛盾を防ぎ、一貫性を保ちます。
各機能は組み合わさって動作します。アプリケーションサーバーは単にプログラムを動かすだけでなく、データのやり取りや接続の効率化、一貫性の確保まで担い、安定したサービス提供を支えます。
代表的なアプリケーションサーバーの種類
概要
代表的なアプリケーションサーバーは言語や用途ごとに分かれます。ここでは代表的な種類と特徴をやさしく紹介します。
Java系（例：Tomcat, Jetty, WildFly）
Javaで動くアプリケーションを実行します。大規模な業務システムでよく使われ、安定性と拡張性に優れます。Tomcatは手軽に使える点が魅力です。
PHP系（例：Apache + mod_php, PHP-FPM）
PHPで書かれたサイトで広く使われます。Apacheと組み合わせるケースが一般的で、設定が分かりやすく導入しやすいです。
Ruby系（例：Unicorn, Puma）
Ruby on Railsなどで使います。Unicornはシンプルでプロセス管理が中心、Pumaは並列処理に強く高速化に向いています。
Node.js系（例：Express）
JavaScriptでサーバーを作れます。軽量でリアルタイム通信に向いています。小規模から大規模まで柔軟に使えます。
.NET系（例：IIS, Kestrel）
Windows環境やC#での開発で使います。企業向けの業務システムで採用例が多く、統合性が高いです。
選び方のポイント
言語や既存の技術、性能要件、運用のしやすさを基準に選びます。実際の例で試してみると、適したサーバーが見えてきます。
混同されやすい理由
背景
Webサーバーとアプリケーションサーバーは本来役割が異なります。とはいえ実際の現場では両者の境界が曖昧になりやすいです。歴史的に、初期のWebサーバーは動的処理も直接行っていたためです。
機能の重なり（具体例で説明）
- Apache HTTP Serverは静的ファイル配信だけでなく、mod_phpなどで動的処理も実行します。これにより“Webサーバーがアプリも担当する”と見なされます。
- Nginxは静的配信と同時に、リバースプロキシとしてアプリケーションサーバーへ中継する役割も担います。
- TomcatはHTTPで直接応答できるため「Webサーバー」と呼ばれることがありますが、中で動的なアプリを動かします。
運用や用語の影響
同じサーバ上で両方の機能を有効にすると、管理者は単に“Webサーバー”と呼ぶことが多いです。またパッケージ（例：LAMP）やドキュメントでも用語が混ざり、誤解が広がります。
見分け方の簡単な目安
- 主に静的コンテンツやHTTP接続を扱うならWebサーバー。
- ビジネスロジックを実行し、DBやセッション管理をするならアプリケーションサーバー。
実務では役割を意識して設定・監視することで混同を避けられます。
処理フロー
概要
ユーザーのブラウザからの要求（リクエスト）はまずWebサーバーに届きます。必要な処理がある場合、Webサーバーはアプリケーションサーバーに処理を依頼し、アプリケーションサーバーがデータベースなどにアクセスして結果を生成します。生成した結果はWebサーバーを経由してブラウザに返されます。
処理の流れ（ステップ）
- ブラウザがURLやフォームでリクエストを送信します。
- Webサーバーがリクエストを受け取り、静的ファイルで済むか判断します。
- 動的処理が必要なら、Webサーバーがアプリケーションサーバーにリクエストを転送します。
- アプリケーションサーバーが業務ロジックを実行し、必要に応じてデータベースへ問い合わせます。
- 処理結果を整形してWebサーバーに戻します。
- Webサーバーがレスポンスをブラウザに返します。
具体例：ログイン処理
ブラウザがID・パスワードを送ると、Webサーバーが受け取りアプリケーションサーバーへ転送します。アプリケーションサーバーが認証処理を行い、データベースで照合します。認証成功ならセッションを作成して結果を返し、ブラウザが受け取って画面を表示します。
注意点と工夫
- キャッシュを使うと静的応答を高速化できます。
- 長時間処理は非同期で切り出すと応答性が上がります。
- 入力検証や権限チェックはアプリケーションサーバー側で確実に行ってください。
アプリケーションサーバーの本質
定義と位置付け
アプリケーションサーバーはハードウェアではありません。サーバOSとアプリケーション（業務ロジックや画面表示など）の間に立つソフトウェア層です。想像すると、舞台裏で役者が動きやすいように舞台装置や道具を整える「支度係」のような役割を果たします。
本質的な役割
主な目的は「アプリケーションが安定して動く環境を提供する」ことです。具体的には、処理の実行・管理、コンポーネントの呼び出し、状態管理、接続管理などをまとめて担います。アプリ開発者は細かな環境差を気にせず、業務機能の実装に集中できます。
わかりやすい例
例えば、オンライン注文システムでは、注文処理や決済処理、在庫確認を順序よく実行する必要があります。アプリケーションサーバーが各処理の呼び出しやエラー時の復旧、同時利用者の調整を行い、アプリは業務ロジックだけを実装します。
運用で意識すること
アプリケーションサーバーは機能を集約するので、性能や可用性がシステム全体に影響します。ログ管理や監視、設定の一元化を整えると運用が楽になります。
