WebサーバとAPサーバが担当する処理の量を比較すると、一般的にはAPサーバの方が多くなる傾向があります。

それはWebサーバはHTTPリクエストで指定されたファイルをWebブラウザに返せばよいだけですが、APサーバではWebアプリケーションがデータベースから情報を抽出したり、抽出結果をもとにHTMLを整形するなど様々な処理をする必要があるからです。


WebサーバはAPサーバより処理量は少ないのですが、非常に多くのHTTPリクエストを受け付ける傾向があります。

Webサイトではページを1つ表示するだけでもHTMLファイル以外に、デザイン情報を記述したCSSファイル、スクリプト言語であるJavaScriptファイル、jpegファイルなどの様々な静的コンテンツが必要となります。


これらの静的コンテンツは1回のHTTPリクエストに対し1ファイルずつしかダウンロードできません。

よって、1つのWebページを表示するだけでも大量のHTTPリクエストの発行が行われ、WebサーバのHTTPリクエスト処理が非常に多くなります。（下図参照）


ここまでの説明をまとめると、Webサーバはリクエスト回数が多いが処理は軽い、APサーバはリクエスト回数が少ないが処理は重いという事になります。

よって、WebサーバとAPサーバを異なるノードに分けると異なる種類のリクエストを上手く分担させることができます。

これまでの説明ではTomcatワーカを1つだけ配置してきましたが、複数のAPサーバを異なるノードに配置することにより、複数のTomcatワーカを定義することもできます。

以下にその状態を表します。


上記では「nekonoesa」と「torinoesa」のパス（URL）で異なるWebアプリケーションが動作しており、それぞれ異なるホストのTomcatで実行されています。

このような構成ではApacheとTomcatの連携の設定は以下のようになります。



上記①の部分で「worker1」「worker2」という2つのTomcatワーカを定義し、転送先のIPアドレスをそれぞれ「192.168.10.1」「192.168.10.2」と指定しています。

②、③の部分を確認すると、「/nekonoesa/*」に一致するHTTPリクエストのURLをworker1に、「/torinoesa/*」に一致するものをworker2に転送するように指定されています。


ここまでWebサーバとAPサーバの分離について解説しましたが、現在のコンピュータの性能を考えると通常の中小規模のシステムを構築する場合は、このように分離する必要はほとんどありません。

Tomcatを含む一般的なAPサーバでは複数のWebアプリケーションを実行できるようになっているためです。

WebサーバとAPサーバを分離するメリットとして、異なる種類のリクエストを分担させ処理の負荷を軽減させることができると説明しましたが、設定ファイルの作成やAPサーバの製品ごとに設定方法が異なるなど、デメリットも存在します。


そのため、Webサーバの機能を併せ持つAPサーバが登場しました。

このようなAPサーバのメリットはシステム構成が単純なため、あまり規模の大きくないWebアプリケーションや開発環境への導入が比較的容易に行えるという点が挙げられます。

ただし、Apacheのような多彩な機能は実装されていないためWebアプリケーションで実現したいサービス内容により、使い分けることが必要になります。

Webアプリケーションで安全で多くの情報を保持・管理する方法として「セッション」という技術があります。

そのセッションでは「セッションID」を発行して、Webサーバにリクエストを発行したWebクライアントを識別していますが、JavaのAPサーバではセッションIDの発行・管理をAPサーバが行います。


また、セッションはHTTPで規定された技術ではないため、ユーザが使用するブラウザの種類に合わせてセッションIDの受け渡しを行う必要がありますが、これらはAPサーバが自動で行っています。

Webアプリケーションで構成された業務システムでは「トランザクション」と呼ばれるまとめて実行する必要がある業務フローが存在します。

ショッピングサイトを例とすると、ユーザが商品の購入確定ボタンを押下した時点で「商品の在庫を減らす」「クレジットカードの決済処理を行う」といった2つの処理がトランザクションに含まれ、両処理ともに成功しないといけません。


例えば、残高不足によりクレジットカードの決済処理が失敗した場合、減らした商品の在庫を元に戻す処理が必要です。

このような処理を「ロールバック」と呼びます。APサーバにはこれらのトランザクション処理の実装をサポートする機能が組み込まれています。

SQLの発行などでデータベースにアクセスする際、接続管理を徹底する必要があります。

切断処理を忘れてそのまま放置してしまうと、本来必要としないメモリ領域をどんどん消費してしまい、最終的にはサーバがダウンしてしまうこともあります。

また、データベースへの接続処理は時間がかかることが多く、接続と切断の繰り返しによりシステムのパフォーマンスが低下する原因にもなります。


このような問題があるため、接続・切断処理はSQL発行のたびに行うのではなく、Webアプリケーションのシステム全体で一括管理することが一般的になっています。

また、データベース接続を管理する機能をAPサーバが提供することにより、Webアプリケーションの開発者はデータベースの接続状態を意識することも無くなってきています。


このようにAPサーバがデータベース接続を管理することにより、接続と切断を繰り返すのではなくAPサーバが接続を保持しておき、Webアプリケーションの要求に応じて接続を使いまわすことにより、データベースへのアクセスを高速化することができます。これを「コネクションプーリング」と呼びます。

業務システムの場合、複数のWebアプリケーションを1台のAPサーバで実行することもよくあります。

そのため、APサーバには複数のWebアプリケーションが互いに干渉することなく実行できるように管理する機能が備わっています。


また、サーバのダウンによりシステムが停止することを防ぐために、複数のAPサーバを用意しダウンしたサーバの処理を肩代わりさせることにより、システムの可用性を高めています。

このような機能を利用するためにはAPサーバ同士が連携し、HTTPセッションの状態を共有する必要があります。

この仕組みを「セッションレプリケーション」と呼び、一部のサーバがダウンしてもユーザはそのシステムを利用し続けることができます。