目次


WAS虎の巻

第5回「リクエスト処理の流れ」

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: WAS虎の巻

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:WAS虎の巻

このシリーズの続きに乞うご期待。

1. リクエスト処理全体の流れ

今回は、クライアントからのリクエストがWebサーバーやWebサーバー・プラグインを経由し、WebSphere Application Server (WAS) に送信されて処理されるという一連の流れや仕組みについて説明します。なお、Webサーバーの前段に負荷分散装置が配置されるシステム構成の場合もありますが、今回は、負荷分散装置については対象外とします。

1.1. クライアント~Webサーバー

図1のように、まず初めに、クライアントからのリクエストはWebサーバーに送信されます。そして、Webサーバーに送信されてきたリクエストは、全て一度Webサーバー・プラグインで処理されます。Webサーバー・プラグインとは、WASのコンポーネントの1つです。Webサーバー・プラグインはWebサーバーと共に動作し、Webサーバーで受け取ったリクエストのうち、必要なものを後方のWASへ転送します。
Webサーバー・プラグインは、割り振り先のアプリケーション・サーバーの定義を記述したプラグイン構成ファイル(plugin-cfg.xml)を読み込み、送信されてきたリクエストがWebサーバー上で処理するものか、WASに転送するものかを決定します。
例えば、Webサーバー上の静的コンテンツへのリクエストであれば、そのままWebサーバー上の静的コンテンツがクライアントに返されます。一方、クライアントからのリクエストがWAS上のアプリケーションあるいはWAS上の静的コンテンツへのリクエストであれば、Webサーバー・プラグインからWASへと転送されます。
クライアント~Webサーバーのリクエストの流れに関する詳細は、2章で説明します。

図1:クライアント~Webサーバーのリクエスト処理の流れ
図1:クライアント~Webサーバーのリクエスト処理の流れ
図1:クライアント~Webサーバーのリクエスト処理の流れ

1.2. Webサーバー~WAS

図2のように、クライアントからのリクエストがWAS上のアプリケーションへアクセスするものであれば、Webサーバー・プラグインは、プラグイン構成ファイルの定義にしたがって割り振り先のアプリケーション・サーバーを決定します。
割り振り対象となるアプリケーション・サーバーが複数存在している場合、Webサーバー・プラグインは、まず、リクエストのURLに基づいて、送信されてきたリクエストをどのアプリケーション・サーバーに転送すべきかを決定します。次に、初期リクエストであるかセッション・アフィニティー(同一クライアントからのリクエストはHTTPセッション情報を保持している特定のアプリケーション・サーバーに転送し続けるという機能)を使用するかを判断し、どのアプリケーション・サーバーで処理させるかを決定し、リクエストを転送します。
Webサーバー~WASのリクエストの流れに関する詳細は、3章で説明します。

図2:Webサーバー~WASのリクエスト処理の流れ
図2:Webサーバー~WASのリクエスト処理の流れ
図2:Webサーバー~WASのリクエスト処理の流れ

1.3. WAS

図3のように、クライアントからのリクエストがWASに転送されると、リクエストされたサーブレットやJSP、EJBといったWAS上のアプリケーションが実行され、必要に応じてデータベースやメッセージング・サービスなどの外部リソースへのアクセスが行われます。そして、その処理結果がWASからWebサーバーに返され、Webサーバーからクライアントまで返されます。
WASでのリクエストの流れに関する詳細は、4章で説明します。

図3:WASのリクエスト処理の流れ
図3:WASのリクエスト処理の流れ
図3:WASのリクエスト処理の流れ

以上のように、クライアントからのリクエストは、Webサーバー・プラグインやWASの定義情報により各サーバー上で処理が行われたのち、その結果がレスポンスとしてクライアントに返るという流れになります。次章以降で、クライアント~Webサーバー、Webサーバー~WAS、WASそれぞれにおけるリクエスト処理の流れに関して、より詳細な仕組みや処理フローについて説明します。

2. クライアント~Webサーバーにおける処理

この章では、クライアント~Webサーバーにおけるリクエスト処理の流れに関して、詳しく説明します。

2.1. クライアントからWebサーバーへのリクエスト送信

Webブラウザ等のクライアントからWeb上のコンテンツに対してリクエストを送信する際は、その場所を特定するためにURL(Uniform Resource Locator)が使用されます。URLのデータおよびそれぞれの意味は、以下の通りです。

 

① プロトコル
プロトコルは、表示する情報の種類を特定するものです。HTTP(Hyper Text Transfer Protocol)は、Web上のコンテンツにアクセスするためのプロトコルです。更に、安全に情報をやりとりするためのデータ暗号化機能が付加されているのがHTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)です。

② ホスト名.ドメイン名
ホスト名はサーバーに付けられた名前です。ドメイン名は、Web上の国や組織、サーバーを識別するための名前です。

③ ポート番号
ポート番号は、接続先サーバーが提供しているサービス固有の番号です。通常、HTTP通信先となるWebサーバーのポート番号は80であり、well-known portとして決められているため、URL入力時に省略することができます。同様に、HTTPS通信の際のポート番号は443であり、こちらもwell-known portとして決められているため省略することができます

④ Path
Pathは、接続先サーバー上のアプリケーションの配置場所やコンテンツ名を表しています。詳細は4章で説明します。

図4のように、このURLの中のドメイン名により、接続先となるWebサーバーが決定されます。Web上の通信にはIPアドレスが使用されていますが、人間が覚えやすいようにURLにはドメイン名が使用されています。そして、DNSサーバーによって、このドメイン名とIPアドレスが対応づけられ、クライアントからのリクエストは該当するWebサーバーに送信されます。

図4:リクエストがWebサーバーへ送信されるまでの流れ
図4:リクエストがWebサーバーへ送信されるまでの流れ
図4:リクエストがWebサーバーへ送信されるまでの流れ

2.2. Webサーバー・プラグインによる処理コンポーネントの決定

Webサーバーに送信されてきたリクエストは、Webサーバー上のコンテンツに対するものであっても、全て一度Webサーバー・プラグインへと転送されます。そして、Webサーバー・プラグインはあらかじめ読み込んでおいたプラグイン構成ファイルの情報に基づいて、送信されてきたリクエストがWebサーバー上で処理するものか、WASに転送するものかを決定します。プラグイン構成ファイルはXML形式のファイルで、WASで設定したアプリケーションの情報や割り振り先のアプリケーション・サーバーの定義等の情報が記述されています。
WASの管理コンソールにおける設定箇所とそれに対応するプラグイン構成ファイル内の記述に関して、例を挙げて説明します。
図5のWAS管理コンソール画面では、アプリケーション「DefaultApplication.ear」に仮想ホスト「default_host」が指定されています。仮想ホストとは、単一のホストマシンを複数のホストマシンに見せかけて使用できるようにする定義情報です。仮想ホストは複数のWebモジュールに関連付けることができますが、各Webモジュールは1つの仮想ホストにしか関連付けることができません。図5のWAS管理コンソール画面では、仮想ホスト「default_host」のホスト別名には、「aaa.com:80」が定義されています。これは、アプリケーション「DefaultApplication.ear」に対するリクエストが送信されてきた際に、リクエストURLの中のドメイン名とポート番号の組み合わせが「aaa.com」と「80」であれば、アクセスを許可するということを意味しています。「aaa」と「80」、「zzz.com」と「80」、「aaa.com」と「81」といった組み合わせの場合はアクセスが許可されません。デフォルト設定では、仮想ホスト「default_host」のホスト別名には「*:80」が定義されているため、「aaa.com」と「80」の組み合わせや「bbb.com」と「80」の組み合わせの場合でもアクセスは許可されます。例えば、アプリケーションAは「http://aaa.com:80/xxx」というリクエストのみ、アプリケーションBは「http://bbb.com:80/xxx」というリクエストのみを受け付けたいという場合は、2つのアプリケーションそれぞれに別々の仮想ホストを関連付けておき、それぞれのホスト別名に「aaa.com:80」と「bbb.com:80」を定義しておく必要があります。
多くのケースでは、デフォルトで定義されている仮想ホスト「default_host」のみで十分ですが、既述の通り、単一のホストマシンをクライアントから見て複数のホストマシンに見せかけてアクセス制御したい場合には、仮想ホストを追加する必要があります。また、ある仮想ホストに関連付けられたWebモジュールと他の仮想ホストに関連付けられたWebモジュールは、データを共有することはできません。これは、両者の仮想ホストが物理的に同じマシンで同じアプリケーション・サーバーを共有している場合でも同様です。

図5:WAS管理コンソールでのアプリケーション設定画面(WAS V8.0環境)
図5:WAS管理コンソールでのアプリケーション設定画面(WAS V8.0環境)
図5:WAS管理コンソールでのアプリケーション設定画面(WAS V8.0環境)

以下は、仮想ホストとWebモジュールの関連付けに関する定義情報が記述されている部分を抜粋したデフォルトのプラグイン構成ファイルです。アプリケーション「DefaultApplication.ear」には、「/snoop」や「/hello」、「/hitcount」といったURIを持つWebモジュールが含まれており、それらがプラグイン構成ファイルのUriGroupディレクティブ内に記述されています。

プラグイン構成ファイル(plugin-cfg.xml)の抜粋
  ・・・(略)・・・
<VirtualHostGroup Name="default_host">
   <VirtualHost Name="*:9080"/>
   <VirtualHost Name="*:80"/>
   <VirtualHost Name="*:9443"/>
   <VirtualHost Name="*:443"/>
 </VirtualHostGroup>
  ・・・(略)・・・
<UriGroup Name="default_host_TestCluster_URIs">
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
 Name="/j_security_check"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid"
 Name="/ibm_security_logout"/>
   <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
</UriGroup>
<Route ServerCluster="TestCluster" UriGroup="default_host_TestCluster_URIs"
 VirtualHostGroup="default_host"/>
  ・・・(略)・・・

図6のように、Webサーバー・プラグインはリクエストURLとプラグイン構成ファイルの情報のマッチングを行い、リクエストを処理するコンポーネントを決定します。Webサーバー・プラグインは、受け取ったリクエストURLの中のドメイン名とポート番号の組み合わせやPathを確認し、プラグイン構成ファイルの各Routeディレクティブの仮想ホストやURIに適合するものがあるか検索します。適合するRouteディレクティブが存在しない場合には、Webサーバーでリクエストを処理するものと決定して、Webサーバーに処理を戻します。適合するRouteディレクティブが存在する場合には、WASにリクエストを転送するものと決定して、Webサーバー・プラグインで後続の処理を実行します。例えば、「http://hostabc/wasapp」というURLでリクエストが送信されてきた場合、UriGroupの中の「/wasapp」という条件にも適合し、かつ、VirtualHostGroupの中の「*:80」という条件にも適合しているRouteディレクティブが存在しているため、Webサーバー・プラグインは、このリクエストをWASに転送すると決定します。
ここで、リクエストURLで指定されるPathは、アプリケーション開発時に設定することができます。Pathは、コンテキストルートとWebモジュールのサーブレットURIの組み合わせで表されます。図6の例では、コンテキストルートとして「/wasapp」が設定されており、サーブレットURIとして「/servlet」が設定されています。このコンテキストルートは、通常、アプリケーション開発時に開発者によって設定されるものですが、WASにデプロイした後に、WAS管理コンソールから変更することもできます。
WASにリクエストを転送するものと決定したあとのWebサーバー・プラグインによる後続の処理に関しては、3章で説明します。

図6:Webサーバー・プラグインによる処理コンポーネント決定の流れ
図6:Webサーバー・プラグインによる処理コンポーネント決定の流れ
図6:Webサーバー・プラグインによる処理コンポーネント決定の流れ

このように、管理者がWASにアプリケーションを導入し、仮想ホストの設定を行い、プラグイン構成ファイルの作成を行っておけば、あとはWebサーバー・プラグインがプラグイン構成ファイルの定義情報をもとにリクエストを処理するコンポーネントを決定します。管理コンソールでアプリケーションの導入や仮想ホストの設定を行った上でプラグイン構成ファイルを作成すると、プラグイン構成ファイルにはそれらの定義情報が反映されます。また、プラグイン構成ファイルはXML形式ですので、必要に応じて手動で編集することもできます。

2.3. Webサーバーにおける処理

Webサーバー・プラグインによって、Webサーバーでリクエストを処理することが決定されると、リクエストURLのPathに応じて、Webサーバー上のコンテンツがクライアントに返されます。Webサーバーでは、どのようなリクエストであれば受け付けるか、リクエストURLのPathに応じてどのコンテンツを返すか、といったことが構成ファイル上に定義されています。
以下に、WebサーバーとしてIBM HTTP Server(IHS)を例に、構成ファイル(httpd.conf)の抜粋と各ディレクティブの意味に関して説明します。

IHS構成ファイル(httpd.conf)の抜粋
  ・・・(略)・・・
# Listen directives must be qualified with either an IPv4 or IPv6 address.
# Use 0.0.0.0 for the default IPv4 address and [::] for the default IPv6
# address.
#
# IPv4 support:
Listen 12.34.56.78:80
  ・・・(略)・・・
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "C:/IBM/HTTPServerV80/htdocs"
  ・・・(略)・・・
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
ErrorDocument 500 "The server made a boo boo."
ErrorDocument 404 "I’m sorry. File not found."
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
  ・・・(略)・・・
  • Listen

    Listenディレクティブは、WebサーバーがlistenするIPアドレスとポート番号を設定します。この設定により、特定のIPアドレスやポート番号だけのリクエストを受け付けることができます。複数のIPアドレスとポート番号の組み合わせを指定することもできます。例えば、「Listen 12.34.56.78:80」と定義されている場合、クライアントから「http://12.34.56.78:80/index.html」や「http://12.34.56.78/index.html」というリクエストが送信されてきたら、Webサーバーはそのリクエストを受け付け、コンテンツindex.htmlを返しますが、「http://23.45.67.89:80/index.html」というリクエストが送信されてきても、そのリクエストは受け付けず、クライアントにはエラーが返ります。

  • DocumentRoot

    DocumentRootディレクティブは、Webサーバーが提供するコンテンツの配置ディレクトリを設定します。例えば、「DocumentRoot "C:/IBM/HTTPServerV80/htdocs"」と定義されている場合、クライアントから「http://xxxxx(ドメイン名)/index.html」というリクエストが送信されてきたら、Webサーバーは「C:/IBM/HTTPServerV80/htdocs」ディレクトリに配置しているコンテンツindex.htmlを返すことになります。

  • ErrorDocument

    ErrorDocumentディレクティブは、クライアントからのリクエストに対してエラーが発生した際に、Webサーバーがクライアントに返すコンテンツを設定します。コンテンツの種類としては、簡単なメッセージを返すことも、自サーバー内の特定のURLあるいは外部サーバーのURLにリダイレクトすることもできます。例えば、「ErrorDocument 404 "I’m sorry. File not found."」と定義されている場合、クライアントからのリクエストに対してHTTPエラーコード404が発生したら、クライアントには「" I’m sorry. File not found."」というメッセージが返ります。

例えば、IHS構成ファイルに「DocumentRoot "C:/IBM/HTTPServerV80/htdocs"」と「ErrorDocument 404 "The server made a boo boo."」が定義されており、サーバー上の「C:/IBM/HTTPServerV80/htdocs」配下に「webdoc.html」というコンテンツのみが配置されている場合に、クライアントから「http://xxxxx(ドメイン名)/webdoc.html」というリクエストが送信されてきたらコンテンツ「webdoc.html」が返り、「http://xxxxx(ドメイン名)/doc.html」というリクエストが送信されてきたら、そのようなコンテンツは存在しませんので、エラーコード404が発生するので「"The server made a boo boo."」というメッセージが返ることになります。

その他にも、クライアントのIPアドレス毎やWebサーバーのコンテンツ配置ディレクトリ毎にアクセス制御をかける等、Webサーバーによってさまざまな機能が提供されています。Webサーバー・プラグインによってWebサーバーで処理することが決定されたリクエストに関しては、このようなWebサーバーの設定に応じて処理が行われ、コンテンツが返されます。

3. Webサーバー~WASにおける処理

この章では、Webサーバー~WASにおけるリクエスト処理の流れに関して、詳しく説明します。

3.1. Webサーバー・プラグインにおける処理サーバーの決定

Webサーバー・プラグインは、リクエストURLとプラグイン構成ファイルの情報のマッチングを行い、リクエストを処理するコンポーネントを決定します。具体的なマッチング処理の順序は、以下の通りです。

① Webサーバーで処理するかWASで処理するかを決定
「2.2. Webサーバー・プラグインによる処理コンポーネントの決定」を参照してください。

② どのクラスターグループまたはスタンドアロン・サーバーに転送するかを決定
「2.2. Webサーバー・プラグインによる処理コンポーネントの決定」で説明した処理フローと同様に、Webサーバー・プラグインは、各Routeディレクティブで設定される仮想ホストとURIの設定と適合するものがあるかを検索し、どのクラスターグループまたはスタンドアロン・サーバーに転送するかを決定します。「2.2. Webサーバー・プラグインによる処理コンポーネントの決定」で抜粋したプラグイン構成ファイルには以下の記述があり、このRouteディレクティブに適合しているので、Webサーバー・プラグインはクラスターグループ「TestCluster」に転送することを決定します。

 
<Route ServerCluster="TestCluster" UriGroup="default_host_TestCluster_URIs"
 VirtualHostGroup="default_host"/>

③ クラスターグループ内のどのクラスターメンバーに転送するかを決定
Webサーバー・プラグインは、リクエスト情報の中にセッションIDが含まれているかをチェックします。セッションIDが含まれている場合には、セッション・アフィニティーの機能を使用し、前回と同一のアプリケーション・サーバーにリクエストを転送します。セッションIDが含まれていない場合には、ルーティング・ポリシーにしたがって、リクエストを転送するアプリケーション・サーバーを決定します。また、そのアプリケーション・サーバーに障害が発生すると、Webサーバー・プラグインはそれを検知し、他の正常なアプリケーション・サーバーに転送するというフェールオーバーの機能も提供しています。

セッション・アフィニティーの仕組みに関しては、WAS虎の巻第2回「WebSphere Application Server(WAS)の複数台構成」の「3.2. セッション・アフィニティー」をご参照ください。

ルーティング・ポリシーの仕組みに関して、説明します。ルーティング・ポリシーは、Webサーバー・プラグインがどのアプリケーション・サーバーにリクエスト転送するかを選択する方法を指定します。方法としては、重み付きラウンドロビンとランダムの2つが選択でき、デフォルトは重み付きラウンドロビンです。それぞれ以下のように動作します。

  • 重み付きラウンドロビン

    重み付きラウンドロビンを選択した場合、各アプリケーション・サーバーに対して数字で重みを設定します。各アプリケーション・サーバーの重みは、クラスターグループの新規作成やアプリケーション・サーバーの追加時に設定することもできますし、アプリケーション・サーバー追加後に動的に設定変更することもできます。デフォルトの重みは2で、有効な値の範囲は0から20の整数値です。図7のWAS管理コンソール画面では、アプリケーション・サーバー「TestMember1」と「TestMember2」の重みがそれぞれ3と2に設定されています。この重み付きラウンドロビンの重みの設定は、プラグイン構成ファイル内では「LoadBalanceWeight」という名称で設定されます。

    図7:WAS管理コンソールでのアプリケーション・サーバー設定画面(WAS V8.0環境)
    図7:WAS管理コンソールでのアプリケーション・サーバー設定画面(WAS V8.0環境)
    図7:WAS管理コンソールでのアプリケーション・サーバー設定画面(WAS V8.0環境)

    重み付きラウンドロビンを選択した場合、起動した最初、Webサーバー・プラグインはランダムにアプリケーション・サーバーを選択し、リクエストを転送します。そして、リクエストを転送したアプリケーション・サーバーの重みを1減らします。次に、後続のリクエストは異なるアプリケーション・サーバーに順番に転送します。重みが0になったアプリケーション・サーバーへのリクエストの転送は行われません。すべてのアプリケーション・サーバーの重みが0(もしくは0以下)になると、重みはリセットされ、現在の値に設定している重みが加算されます。
    ただし、既述の通り、クライアントからのリクエスト情報にセッションIDが含まれている場合には、セッション・アフィニティーの機能が優先され、そのクライアントが前回アクセスしたアプリケーション・サーバーにリクエストが転送されます。セッション・アフィニティーの機能で転送先アプリケーション・サーバーが決定された場合も、そのアプリケーション・サーバーの重みは1減じられます。これにより、アプリケーション・サーバーの重みが0より小さい値になることもあります。
    図8で、具体的に重み付きラウンドロビンがどのように機能するかを説明します。ここでは、2つのアプリケーション・サーバー「TestMember1」と「TestMember2」が存在し、それぞれの重みが3と2に設定されているものとします。最初のリクエスト①はランダムに割り振られます。ここでは「TestMember1」が選択されたとします。その後の新規リクエスト②~④はラウンドロビンで交互にリクエストが割り振られます。その次のセッションIDを含んだリクエスト⑤の場合は、セッション・アフィニティーの機能が優先され、前回と同一のアプリケーション・サーバー「TestMember2」に割り振られます。全てのアプリケーション・サーバーの重みが0以下になると、重みはリセットされます。ここでは、リクエスト⑥の終了後、「TestMember1」と「TestMember2」の重み「0」と「-1」に、設定していた重みの「3」と「2」それぞれ加算され、「3」と「1」にリセットされています。

    図8:重み付きラウンドロビンの処理の流れ
  • ランダム

    ランダムを選択した場合、重みの設定値は考慮されず、リクエストは各アプリケーション・サーバーにランダムに割り振られます。

    このように、Webサーバー・プラグインは、セッション・アフィニティー機能やルーティング・ポリシーにしたがって、リクエストを転送すべきアプリケーション・サーバーを決定します。

3.2. WASへのリクエスト転送

Webサーバー・プラグインは、リクエスト転送先となるアプリケーション・サーバーを決定したら、まず、アプリケーション・サーバーとの通信プロトコルとしてSSLを使用するかどうか(HTTPかHTTPSか)を決定します。WASのデフォルトの設定では、各アプリケーション・サーバーはHTTPとHTTPSの2つの通信プロトコルと関連付けられています。クライアントからWebサーバーへの通信でSSLを使用している場合は、Webサーバー・プラグインからアプリケーション・サーバーへの通信もSSLを使用し、クライアントからWebサーバーへの通信でSSLを使用していない場合は、Webサーバー・プラグインからアプリケーション・サーバーへの通信もSSLを使用せず、HTTPで通信します。クライアントからWebサーバーへの通信に関係なく、Webサーバー・プラグインからアプリケーション・サーバーへの通信で意図的にHTTPまたはHTTPSどちらかのみのプロトコルを行うように設定することもできます。
通信方法が決定したら、Webサーバー・プラグインはアプリケーション・サーバーとの間に物理的な接続を生成し、リクエストを転送します。その際、そのアプリケーション・サーバーとの通信の接続が切断されたり、通信が失敗したりすると、Webサーバー・プラグインはその障害を検知することができます。そして、他の正常なアプリケーション・サーバーを転送先として決定し、リクエストを転送するというフェールオーバー機能を提供しています。
ここでは、Webサーバー・プラグインによるフェールオーバー機能に関連する設定およびフェールオーバーのメカニズムついて説明します。

  • 接続タイムアウト(ConnectTimeout)

    接続タイムアウトは、Webサーバー・プラグインとアプリケーション・サーバー間のTCP接続におけるタイムアウトをOSの設定ではなく、Webサーバー・プラグイン独自に設定します。WASV8.0でのデフォルト値は、5秒です。

    図9のように、接続タイムアウトで設定した時間を経過しても接続が確立されなかった場合、Webサーバー・プラグインは、対象となるアプリケーション・サーバーにダウンのマークを付けて、リクエストを別のアプリケーション・サーバーに転送しようと試みます。

    図9:Webサーバー・プラグインの「接続タイムアウト」設定の処理の流れ
    図9:Webサーバー・プラグインの「接続タイムアウト」設定の処理の流れ
    図9:Webサーバー・プラグインの「接続タイムアウト」設定の処理の流れ
  • 読み取り/書き込みタイムアウト(ServerIOTimeout)

    読み取り/書き込みタイムアウトは、TCP接続が確立した後に、Webサーバー・プラグインからアプリケーション・サーバーへのHTTPリクエストに対するレスポンスが完了するまでのタイムアウトを設定します。WAS V6.1以前のデフォルト値が「0秒(無制限)」であったのに対し、V7.0のデフォルト値は「60秒」、V8.0およびV8.5のデフォルト値は「900」秒となっています。
    図10のように、Webサーバー・プラグインからアプリケーション・サーバーへリクエストを転送し、読み取り/書き込みタイムアウトで設定した時間を経過してもレスポンスが返ってこなかった場合、Webサーバー・プラグインは、対象となるアプリケーション・サーバーにダウンのマークを付けて、リクエストを別のアプリケーション・サーバーに転送しようと試みます。WASのプロセスがハングして処理が継続できないような場合に有効な設定ではありますが、アプリケーションの性質を考慮し、正常処理であっても長時間かかるような処理の場合は、注意が必要となります。
    リクエストが他のアプリケーション・サーバーに転送されることにより、DB更新など同じ処理が2度実行されるのを避けるための対策として、Webサーバー・プラグインがHTTPリクエスト内容を読み取るときに使用する最大バッファー・サイズ(PostBufferSize)を0に設定しておくと、Postリクエストに関しては再送しなくなります。Getリクエストに関しては、再送しないように制御することはできません。

    図10:Webサーバー・プラグインの「読み取り/書き込みタイムアウト」設定の処理の流れ
    図10:Webサーバー・プラグインの「読み取り/書き込みタイムアウト」設定の処理の流れ
    図10:Webサーバー・プラグインの「読み取り/書き込みタイムアウト」設定の処理の流れ
  • 再試行間隔(RetryInterval)

    図11のように、再試行間隔は、何かしらの障害により一度ダウン状態であるとマークされたアプリケーション・サーバーに対して、Webサーバー・プラグインから再度リクエストを試行するまでの時間を設定します。WASV8.0でのデフォルト値は、60秒です。
    この時間を長くすることにより、不必要にダウンしているアプリケーション・サーバーに対してリクエストを試行することを避けることができます。逆に長くしすぎると、障害から復旧したサーバーに対して、リクエストが割り振られるようになるまでの時間が長くなってしまいます。再試行間隔の特定の推奨値はなく、その環境に依存します。例えば、アプリケーション・サーバーの数が十分多く、1台のアプリケーション・サーバーの停止が全体の負荷にあまり影響を及ぼさない場合には、長くすることができます。

    図11:Webサーバー・プラグインの「再試行間隔」設定の処理の流れ
    図11:Webサーバー・プラグインの「再試行間隔」設定の処理の流れ
    図11:Webサーバー・プラグインの「再試行間隔」設定の処理の流れ

このように、Webサーバー・プラグインは、さまざまな設定内容にしたがって、リクエストを正常なアプリケーション・サーバーへ転送します。Webサーバー・プラグインには、他にも、ハングしたアプリケーション・サーバーへリクエストを送信することを防ぐために、実際のリクエストを送信する前にHEADリクエストを送信してアプリケーション・サーバーの生死を確認する拡張ハンドシェークという機能が提供されています。また、複数のアプリケーション・サーバーをプライマリー・サーバーとバックアップ・サーバーにグループ分けし、全てのプライマリー・サーバーがダウンした場合にのみバックアップ・サーバーにリクエストを送信するという機能も提供されています。詳しくは、WASのInformation Center(下記URL)をご参照ください。

4. WASにおける処理

Webサーバー・プラグインからWASのアプリケーション・サーバーにリクエストが転送されると、WAS上に導入されているアプリケーションが実行され、必要に応じてリソース定義情報に基づいて外部リソースへのアクセスが行われます。リソース定義情報とは、図12のように、データベースやメッセージング・サービスなどの外部リソースへのアクセスが行われるアプリケーションをWAS上で稼働させる場合に、WAS上で定義しておく接続情報のことです。WASでは、JDBCプロバイダーやJMSプロバイダー、リソース・アダプター、メール・プロバイダーなどさまざまなリソース情報を定義することができます。
データベースおよびメッセージング・サービスへの接続に必要なリソース定義方法につきましては、WAS虎の巻第3回「JDBCとデータベース接続」およびWAS虎の巻 第4回「JMSとメッセージング・サービス接続」をご参照ください。

図12:リソース定義
図12:リソース定義
図12:リソース定義

クライアントからのリクエストによりアプリケーションが実行されると、アプリケーションはセッションを作成し、アプリケーション・サーバーはセッションIDを発行します。アプリケーションの処理が終わると、アプリケーション・サーバーがレスポンス情報の中にセッションIDを付加し、レスポンスを返します。そして、アプリケーション・サーバーからのレスポンスはWebサーバー・プラグインを経由してクライアントまで返ります。同じクライアントからの連続したリクエストに関しては、「3.1. Webサーバー・プラグインにおける処理サーバーの決定」で既述の通り、Webサーバー・プラグインがセッションIDの有無を確認して、適切なアプリケーション・サーバーへとリクエスト転送を行います。
セッションIDに関する詳細は、WAS虎の巻第1回「WebSphere Application Server (WAS) 概説」をご参照ください
このように、WebサーバーおよびWebサーバー・プラグイン、WASの各コンポーネントは、それぞれに応じた役割を担い、コンポーネント間で情報を連携し合うことで、クライアントからのリクエストを適切に処理しています。

WAS虎の巻第5回では、WebサーバーおよびWebサーバー・プラグイン、WASでのリクエスト処理の流れや仕組みについてご紹介しました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=827308
ArticleTitle=WAS虎の巻: 第5回「リクエスト処理の流れ」
publish-date=07262012