【初心者目線】Webアプリケーションの開発 第12回
【初心者目線】Webアプリケーションの開発 第12回を書きます。
1. Webアプリケーションとデータベース
前回Webアプリケーションが動作するWebサーバとDBサーバはSQLを使用し、異なるプロセスで情報を受け渡していることを解説しました。
ここでは、実際にどのようにして情報をやり取りしているか、通信方法について紹介します。
1-1. データベースの通信プロトコル
異なるプロセスで動作するソフトウェア同士が情報交換をするためには、何らかの通信を行う必要があります。
例えばWebブラウザとWebサーバは異なるプロセスで動作しているため、HTTPを使用して通信を行っています。
データベースも同様の考えで、SQLの発行や結果の取得のためにWebアプリケーションとデータベースが通信を行っています。
上図の赤枠部分の通信で使用されるプロトコルはHTTP通信のように標準化されているものではなく、各種データベース固有の通信プロトコルが使用されています。
しかし、ほとんどの場合は上記のような通信を行うDBアクセス用のライブラリ（プログラムの部品）が用意されているため、Webアプリケーションの開発時にこれらの通信プロトコルを意識する必要はありません。
2. アプリケーションサーバ
過去の記事でも説明しましたが、CGIを使用したWebアプリケーションの開発にはいくつか問題があり、その問題を解決する方法としてサーブレットやJSPを使用した開発が進められるようになりました。
Webアプリケーションのシステム構成を考える中で、サーブレットやJSPがどのように実行されているのか理解する必要があります。
2-1. サーブレットとJSPを動かすには
JavaVMはWebサーバやデータベースと同様に1つの独立したプロセスです。このプロセスの動きを以下にまとめました。
上図のJavaVM上では「アプリケーションサーバ」と呼ばれるソフトウェアが動作しており、アプリケーションサーバがサーブレットやJSPを動かしています。
WebサーバとWebアプリケーションを実行するプロセスが異なるという部分で、CGIとアプリケーションサーバは同じとも言えます。
しかし、CGIはWebサーバにリクエストが届くたびに新しいプロセスが起動されては終了するといった、使い捨てのモデルです。
これに対しアプリケーションサーバ（以下、APサーバ）はデータベースと同様に常にプロセスが実行されており、Webサーバよりリクエストを受けてサーブレットやJSPを実行する、使いまわしのモデルです。
上図のようにCGIの場合はWebサーバがプログラムのプロセスを毎回起動して結果を受け取ることにより連携を実現させていました。
しかし、WebサーバとAPサーバの場合は特に標準的な連携方法が決まっているわけではありません。
よって、ここからはJavaによるWebアプリケーションの代表的な構成である「Apache HTTP Server」と「Tomcat」の組み合わせを例として説明します。
「Tomcat」とはオープンソースのAPサーバで、小規模な企業のシステムや学習用途としてよく利用されています。
先ほども説明しましたがWebサーバとAPサーバは異なるプロセスで動いているため、連携するためには何らかの通信が必要なのですが、WebサーバとAPサーバの連携方法は標準化されていません。
そのためAPサーバ側がWebサーバごとに用意した連携用モジュールを、Webサーバに組み込むことにより連携を実現しています。
Tomcatの場合はApache向けに「mod_jk」と呼ばれる連携モジュールが用意されており、それをApacheに組み込むことで連携を実現しています。（下図参照）
処理の流れを簡単に説明すると、まず初めにApacheが受け取ったHTTPリクエストをmod_jkがTomcatに転送し、Tomcatはその上で動作しているWebアプリケーション（Servlet/JSP）に渡します。
次に、Webアプリケーションは今までと同様にHTTPリクエストに基づいた処理を実行し、その結果をAPサーバに渡します。
最後に、APサーバは逆のルートでmod_jkへ返し、ApacheがWebブラウザにHTTPレスポンスを返します。
mod_jkとTomcatの通信には「ajp13」と呼ばれるTomcat独自のプロトコルで通信が行われています。
これはHTTP通信よりも効率のよいプロトコルとなっています。
2-2. 各サーバの役割分担
このようにコンテンツの種類により配置先のサーバが異なり、2つのプロセスが連携する形になります。
しかし、HTTPリクエストを発行するクライアント側にとって、ページごとに要求先のプロセスが異なると不都合が発生します。
そのため、Webサーバがクライアントからの全てのHTTPリクエストを引き受けURLによって判断し、APサーバが処理するリクエストのみをAPサーバに転送するようにしています。
ただし、URLで判断をすると言っても自動で判断できるわけではないため、判断材料を以下のような設定ファイルに記述し、そのルールにしたがってコンピュータに判断してもらう必要があります。
上記の設定ファイルはHTTPリクエスト転送先のTomcatに関する情報を記述したものです。
まず①の箇所でこれから接続を行うTomcatワーカに「worker1」という名前を定義しています。
「Tomcatワーカ」とはmod_jkによる連携で接続先となるTomcatプロセスのことを意味しています。
次に②の箇所ではworker1が実行される「localhost」というホスト名を指定しています。
これはworker1が実行されるコンピュータを表す名前ですが、実際のホスト名やIPアドレスを指定することも可能です。
ただし、ApacheとTomcatを同一のホスト上で実行する場合はlocalhostと指定することがおすすめです。
理由としては、localhostと指定しておけばホスト名やIPアドレスが変更されてもこの設定ファイルを修正する必要がないためです。
③の箇所はworker1の接続先ポートを表しています。
ApacheとTomcatは通信を待ち受けるためにポートを使用します。
ここでは「8009」番のポートが指定されています。
④の箇所はworker1に接続するための通信プロトコルである「ajp13」を指定しています。
上記の設定ファイルはApacheに関する情報からmod_jkに関する記述部分を抜き出したものです。
まず、①の箇所ではHTTPリクエスト転送先のTomcatに関する情報を記述した設定ファイルの配置場所を指定しています。
次に②の部分ですが、この箇所ではApacheが受け取ったHTTPリクエストの中から、どのパスに対するリクエストをTomcatに転送するのかを記載しています。
HTTPリクエストのURLの部分が、②で指定された文字列に合致した場合、指定されたTomcatワーカにリクエストが転送される仕組みです。
例えば上記のようなHTTPリクエストがあった場合、②で指定したパス「/nekonoesa/gyokairui/*」に合致するURLは、a）とb）であるため、この2つのリクエストだけをworker1に転送することができます。
合致しないURLについては通常通りApacheに対するリクエストとして認識されます。
②で指定したパスの中に「*」の部分がありますが、この部分は「ワイルドカード」と呼ばれ、どのような文字列でも構いません。
そのためa）とb）のURLは「gyokairui」以降の文字列が異なりますが、それぞれworker1に転送されます。
3. 第12回 まとめ
今回はWebサーバとアプリケーションサーバの連携について、JavaによるWebアプリケーションの代表的な構成である「Apache」「Tomcat」の組み合わせを例に解説してきました。
サーブレットやJSPがWebサーバのどこで、どのような仕組みで動いているか理解できたでしょうか。
次回も引き続き「Apache」「Tomcat」の組み合わせを例に、WebサーバとAPサーバの連携について解説する予定です。