No255 アプリサーバとは？

META=世のホームページを表示する裏方としてWebサーバやアプリサーバというものが活躍しています。今回はこういったホームページを支える機器とソフトウェアの仕組みについて解説をします。
今や、インターネットは生活のいろいろな場面で活用されています。

事務所にお勤めの方であれば、メールやWeb会議を利用するでしょうし、流通業の方であれば、渋滞情報や経路探索、到着時刻予想をインターネットで行います。お店で働く方なら取引先との受発注管理などを行うケースも多いでしょう。

こういったサービスの多くはインターネット上のサーバで動作するプログラムによって実現しています。

今回は、こういったホームページを提供する裏方として活躍しているアプリサーバと呼ばれる仕組みについて解説をします。


1. ホームページを支えるサーバたち

現在では、インターネットブラウザ（ChromeやEdgeといったWebブラウザ）で実に様々なことが行えるようになっています。

その基本的な仕組みはごくシンプルなものです。
　1.パソコン(端末)からはホームページ(Webページ)表示依頼を行う。
　2.依頼された側は依頼に応じて適切なページ内容を送り返す。

このやりとりをひたすら繰り返しているに過ぎません。

このようにページ内容を送り返す側のコンピュータのことをサーバと呼びます。

サーバはその役割によっていろいろな呼び方をします。
上記のようなWebページの表示であれば、今回のテーマであるWebサーバやアプリサーバといったサーバを利用します。
データベースの問い合わせや更新ならデータベースサーバですし、メールの送受信ならメールサーバです。

今回は、このうち、webサーバとアプリサーバについて解説します。


2. ホームページの表示を行うWebサーバ

初期のインターネットのホームページ(Webページ)は内容が固定でした。
つまり、いつ誰が表示しても常に同じ内容の表示となりました。
当初のWebページの目的（学術論文をラクに閲覧したい）を考えると、これは全く問題ではありませんでした。

こういった固定ページ（以下、静的ページと書きます）の表示はWebサーバと呼ばれるサーバの担当です。

よく使われているWebサーバにApache Software Foundation（アパッチソフトウェア財団)
が作ったhttpd（エイチテーテーピーデー）と呼ばれるプログラムがあります。

プログラマやインフラ屋さんが「アパッチ」と言えば、まず間違いなくこのWebサーバのことを指します。（「アパッチ起こしたよ」とか「誰かアパッチ落としたか？」などといった風に使います）

さて、Webページ利用が広がるにつれ、見る人によって表示内容を変えたいケースが出てきます。その典型がショッピングサイトの購入履歴ページです。

理屈の上では全ユーザ用の購入履歴ページを静的ページとして保存しておけば、ちゃんと人によって違ったページを表示できる理屈ですが、これはあまりに非効率です。

そこで、変化させたいページ（例えば購入履歴）の表示依頼を受けると、Webサーバは別のプログラムを起動する仕組み(CGI：Common Gateway Interface)が作られたのです。

この仕組みはWebサーバの管理下で、別のプログラムを動かす仕組みです。ここで呼び出せるのは同じWebサーバ上にあるプログラムに限ります。JavaScriptのようにクライアント上（パソコン側）で動くアプリではない点にご注意ください。

起動されたプログラムは、セッションIDなどのパラメタを使って、適切なページをその場で作成し、その内容をwebサーバに引き渡します。
Webサーバは受け取った内容をそのまま依頼元に返します。
こうすれば、利用者毎に異なるページが作られるという理屈です。

この仕組みは非常によく使われました。
2005年頃までは主流と言って良い状況でした。


3. アプリサーバの登場

このCGIという仕組みは、呼び出す度にプログラムを起動することになり、高速化が難しいといった課題があることはわかっていたのですが、使い勝手の良さから多くのシステムで採用されました。

さて、CGIがよく使われていた1995年にJavaというコンピュータ言語が登場します。
Javaは2022年現在も大規模システムでよく採用される評価の高い言語です。

ところが、この言語が決定的にCGIに向いていませんでした。Javaは言語の特性上起動に時間がかかるのです。

そのため、CGIに代わってもっと効率の良い方法がないものかといろいろなアイデアが出てきました。

ここで考案されたのがアプリサーバという方式でした。

アプリサーバというのは、いわばJavaプログラムを常に動いたままにアイドリングさせておく仕組みです。
一度確保したメモリやデータをできるだけ温存しておき、呼び出し時に高速に動作させることを目的としています。

一般的に、プログラムでは一時的にデータ領域（メモリ）を確保しておき、要らなくなったらその領域を開放するという作業をよく行います。
ところが、この「要らなくなったら開放する」のを忘れることによるバグ（どんどんメモリを浪費してしまい、そのうちまともに動作できなくなるバグ。メモリリーク）がやっかいなのです。
このメモリリークはなかなか原因が見つけられず、プログラマを悩ませるバグの常連と言えます。

アプリサーバでは、メモリ開放の問題をクリアするため、フレームワークと呼ばれる仕組みを採用しました。
フレームワーク自身がメモリの獲得タイミングや開放タイミングを見繕ってくれるため、プログマラが意識しなくても確実に開放が行われます。これは多くのプログラマにとっては大いなる福音でした。
なお、フレームワークはメモリ管理以外にもプログラマのお助けツールがいろいろと含まれています。

なお、アプリサーバについてもTomcat（トムキャット）というプログラムがよく使われています。これもアパッチと同じくApache Software Foundationが作ったプログラムです。
プログラマの間では「トムキャット」と言えばこのアプリサーバのことを指すことが多いようです。


4. Webサーバとアプリサーバの関係

Webサーバとアプリサーバは１つのコンピュータに同居させる場合も、個別のコンピュータに分ける場合もあります。要は１つのコンピュータで全てが処理できそうなら同居させるわけです。

依頼元（パソコン）からのリクエストはまずWebサーバが受け取ります。

その内容が静的（誰でも同じ内容で良い）ページの場合は、Webサーバ自身がその内容を読み込んで、依頼元に返します。

しかし、動的な（人によって内容が異なる）ページである場合は、その依頼内容をそのままアプリサーバに伝えます。
アプリサーバは、与えられた情報からページ内容を生成し、その結果をWebサーバに返します。それを受けてWebサーバはその内容を依頼元に返す、という手順になります。

依頼元からはWebサーバが全てに応答しているように見えるのですが、実際にはこのようにWebサーバとアプリサーバが協力してwebページを作り上げているのです。

余談：
　上の記述では、Webサーバの方がずっとラクそうに感じるかもしれません。
　ですが、画像、アイコンなど静的なファイルは多く意外とWebサーバは忙しかったりします。


5. まとめ

ごく初期のホームページでは静的なページは表示できましたが、見る人によって内容を変えるようなページは作れませんでした。
その後、CGIという仕組みが採用され、見る人によって表示内容が変えられるようになりました。
これによって、ショッピングサイトやオンラインバンキングのようなサービスが可能となったのです。

ですが、その後Javaという言語がWebシステムで採用されるケースが増えるにつれ、CGIでは（遅くて処理しきれなくなり）アプリサーバというものが登場するに至りました。

Javaが大規模システムで利用されている背景には、Javaフレームワークと相性の良いアプリサーバが大きく貢献しているのです。

今回は動的なページを扱う方式として、CGIという方式とアプリサーバという方式について解説しましたが、この２つが全てというわけでもありません。
例えば、小規模なWebシステムでよく使われているPHPという言語（Javaとは別の言語）では、このどちらでもない方式（モジュール方式）が用いられています。
こちらについては、機会があれば解説したいと思います。

今回はアプリサーバについて解説をしました。
次回もお楽しみに。

（本稿は 2022年4月に作成しました）

(タグ #アプリサーバ #ネットワーク #Webサーバ)"