アプリケーションサーバを用いた基本的なシステム構成について説明します。
なお、本章で説明しているいくつかの機能(高速スタンバイ,CNS,WatchServer,フェイルオーバ通知コマンド)についてはWebOTX Application Server Enterprise EditionもしくはWebOTX Clusterの機能です。

3層構成はクライアントとサーバアプリケーションの間にWebサーバとアプリケーションサーバを配置したシステムです。クライアントはWebブラウザによりWebサーバに処理要求を行い、Webサーバ上で動作するWebアプリケーションがアプリケーションサーバに処理要求を行います。アプリケーションサーバ上でその処理要求に対するビジネスロジックが実行され、必要に応じてバックエンドサーバ(データベースサーバ、メインフレームなどの既存システム)を呼び出します。各層それぞれ要件に応じてシステム構成を検討することになります。

各階層の役割

• Webサーバ
  クライアント上のWebブラウザからHTTPリクエストを受信し応答を返却するソフトウェアです。単にテキストや画像のデータ参照(静的なHTML参照)に対してはそのままWebブラウザに応答を返却し、アプリケーションの実行を伴うような処理の場合は、Webサーバ上でWebアプリケーションである Servlet/JSPなどを動作させクライアントからの入力データを解析し、処理をアプリケーションサーバに要求し、その結果をWebブラウザに返却します。Webサーバ上のWebアプリケーションでは画面制御ロジックとプレゼンテーションロジックのみ実装します。
• アプリケーションサーバ
  業務処理を実際に実行する業務アプリケーションが動作します。Webサーバからの処理要求に対して、ビジネスロジックを実行し、必要であればバックエンドサーバに対してデータの参照や更新要求を行います。
• バックエンドサーバ
  主にデータの管理を行います。アプリケーションサーバからのデータの参照、更新処理を実行し結果を返却します。

Webサーバはクライアントからの入り口となっておりクライアントからのリクエストを直接受け付けます。クライアント数の増大などによる負荷の影響を一番受けるため、高い拡張性が重要になってきます。負荷分散機構による負荷分散クラスタ運用を採用するのが一般的です。

Webサーバはスケールアウトの考え方で処理能力の向上を行うことが可能です。アプリケーションサーバやバックエンドサーバにボトルネックがない限り、n台の負荷分散構成は1台構成に比べてn倍の処理能力を持つことが可能です。

負荷分散機構の機能に依存することにはなりますが、負荷が増大した場合のサーバの追加や障害発生時のサーバの切り替えについてはシステムを停止することなく、もしくは非常に短時間に行うことが可能です。障害の検出方法は負荷分散機構に依存しますが、単純なping による確認や、レスポンスの有無、HTTP コマンド(GET)による監視などがあり、障害検出時にはサーバ単位で縮退します。この時、縮退したサーバ分システムの処理能力が低下します。障害サーバ復旧までの応答性能の劣化が許容されない場合は、障害が発生したサーバの負荷を他サーバへ分散させた場合でも応答性能が劣化しないだけの冗長性を、あらかじめシステムに持たせておく必要があります。また、負荷分散機構自体の障害がシステムに影響を与えないように負荷分散機構を多重化する必要があります。

負荷分散環境下でのWebサーバで扱うコンテンツの管理については共有する方式と分散する方式があります。

コンテンツを共有させるためには、ファイルサーバ上でコンテンツを一元管理する方法です。コンテンツを共有することにより、ファイルサーバ上のコンテンツを更新するだけで全てのWebサーバのコンテンツが更新されます。しかし、複数のWebサーバでネットワークを通してファイル参照を行うためネットワークやファイルサーバの負荷を考慮する必要があります。またファイルサーバの障害に対応するため、ファイルサーバの多重化することも考慮しなければなりません。

コンテンツを分散する方式はそれぞれのWebサーバのローカルディスクにコンテンツを配置します。この方式ではコンテンツの更新は全てのWebサーバについて行う必要があります。Webサーバの運用を止めずにコンテンツの更新を行う場合、新旧のコンテンツが混在することがあり、思わぬ結果になる危険性があります。またアプリケーションサーバとのインタフェースが変更になるようなコンテンツの変更である場合、アプリケーションサーバのアプリケーションと同期して変更を行う必要があります。安全に変更を行うためには適切な単位でコンテンツを一時的に閉塞し、相手システムからのアクセスを完全にシャットアウトしてから、Webサーバとアプリケーションサーバの更新を行う方法があります。この方法なら、どのようなシステム構成や条件でも安全にコンテンツを更新することができますが、一部のサービスは短時間中断せざるを得ません。

アプリケーションサーバはWebサーバからの要求を受け、業務アプリケーションを実行します。必要であればデータベースやメインフレーム等のバックエンドサーバに対してデータの変更や更新要求を行います。WebOTXではJ2EEやCORBAなどの分散オブジェクト業務基盤を利用して、業務アプリケーションを実行することができます。

アプリケーションサーバの可用性を高めるためにアプリケーションサーバについてもクラスタ構成とすることが可能です。どのようなクラスタ構成(負荷分散、フェイルオーバ)とするかはシステムの要件を考慮して決定する必要があります。次にクラスタソフトウェアの特徴とクラスタ構成について説明します。

負荷分散構成

同一業務を行うアプリケーションサーバを複数台用意することによりアプリケーションサーバの処理能力を高めることが可能です。ただし、参照するバックエンドサーバでの排他制御があるため単純にアプリケーションサーバの処理能力は台数に比例はしません。Webサーバ同様サーバ障害発生時には該当サーバをシステムより切り離し、縮退運転となります。なお負荷分散構成を行った場合、Webサーバからの要求は要求毎に実行するアプリケーションサーバが異なる場合があるため、アプリケーション内での情報の保持についてはプロセス内のみで行うことができなくなることを注意しなければなりません。

WebOTXでは名前サーバがクライアントからのオブジェクト取得要求に対して返却するオブジェクトリファレンスをラウンドロビンに振り分ける仕組みを提供しています。これによりクライアントからの要求を複数台のサーバに振り分けます。WebOTXの状態を定期的に監視するWatchサーバを組み込むことによりアプリケーションサーバ異常終了時に該当サーバをシステムから切り離し縮退運転を行うことができます。

フェイルオーバ構成

また特にミッションクリティカル性が求められるシステムについては、フェイルオーバクラスタソフトと連携したクラスタ構成とすることによりよりアプリケーションサーバの可用性を持たせることができます。以下にクラスタソフトと連携したフェイルオーバクラスタの構成について説明します。

シングルスタンバイ型

稼動系と待機系で運用を行い、通常は稼動系のサーバでアプリケーションサーバは動作しています。Webサーバからのアプリケーションサーバへのアクセスはクラスタソフトが提供する仮想ホスト名もしくは仮想IPアドレスを利用して行います。稼動系ノードで障害が発生した場合、フェイルオーバが発生し待機系ノードで運用が引き継がれます。このとき仮想ホスト名、仮想IPアドレスについても待機系に引き継がれるため、ステートレスなトランザクション処理については、Webサーバはアプリケーションサーバがフェイルオーバしたことを特に意識する必要はありません。ただし稼動系アプリケーションとの間で生成されたセッションについては稼動系サーバ異常終了により切断されるためセッションの再生成が必要になります。ステートフルなトランザクション処理についてはフェイルオーバ発生によりアプリケーション側で保持しているオブジェクトが失われ、セッションも切断されるため、待機系でその情報を引き継ぐ手段やセッション管理を厳密に行わない限り、フェイルオーバ発生時はトランザクションを無効とし、クライアント側でもう一度はじめからやり直すことになります。

通常のシングルスタンバイ構成においてはフェイルオーバが発生した時点で待機系のサービスが開始されるので障害が発生してから、待機系ノードで運用を引き継ぐまでの切り替に時間を要する場合があります。

高速スタンバイ型

稼動系と待機系で運用を行うことについてはシングルスタンバイ型と同様ですが、切り替に要する時間を短縮するためにあらかじめ待機系でもサービスを起動し、バックエンドサーバへのセッションについてもあらかじめ生成しておきます。これにより稼動系が障害発生となった場合においても、仮想ホスト名、仮想IPアドレスの切り替えのみでフェイルオーバが完了し、短時間での系切り替えを実現します。

相互スタンバイ型

複数の異なる業務システムをマルチサーバでそれぞれ動作させ、あるサーバで障害が発生した場合、その業務システムは別のサーバにフェイルオーバします。よってフェイルオーバ先のサーバは複数の業務システムが動作することになります。相互スタンバイ型の場合、どのサーバも常に稼動系システムを割り当てることができますが、フェイルオーバ発生時は、１つのサーバに複数の業務システムが動作することになるため、そのサーバの処理能力低下は避けられません。

情報の引き継ぎについて

フェイルオーバ構成において、稼動系から待機系にどのように情報を引き継ぐかを考慮する場合があります。次にフェイルオーバ構成における情報の引き継ぎについて説明します。

基本的に引き継ぎ情報については共有ディスクやデータベースなどクラスタ環境で共有可能で永続性のある外部リソースに保持しなければなりません。サーバが異常終了しフェイルオーバが発生しても確実に情報を取得できなければならないためです。

情報を取得するタイミングですが、シングルスタンバイ型や相互スタンバイ型の場合、フェイルオーバ発生時には、待機系にてサービス起動から行われるためアプリケーション起動時に情報を取得することができます。しかし高速スタンバイ型の場合、フェイルオーバが発生しても、待機系ではサービスが既に開始されているため情報を取得するタイミングがありません。そこでWebOTXではフェイルオーバが発生したことを各アプリケーションにコールバックするためのコマンドとAPIを提供しています。フェイルオーバの開始スクリプトでフェイルオーバ発生を通知するためのコマンドを実行することにより、各アプリケーションにその通知がコールバックされます。このタイミングで引き継ぎ情報の取得を行うことが可能となります。

名前サーバの多重化について

CORBAのアプリケーションサーバを負荷分散構成とした場合には、名前サーバの可用性をどのようにして向上するかを考慮しなければなりません。名前サーバを多重化する方法について説明します。

• クラスタソフトウェアと連携した多重化
  クラスタソフトウェアを利用する場合、名前サーバを多重化し稼動、待機構成とすることが可能です。名前サービスの登録情報ファイルを共有ディスクに置くことにより稼動系サーバで障害が発生した場合、稼動系サーバでの登録内容を引き継いで待機系サーバで名前サーバが運用されます。
• キャッシュ名前サーバ(CNS)による多重化
  WebOTX Clusterが提供するCNSを利用することにより名前サーバを多重化することが可能です。CNSは複数の名前サーバに登録されているオブジェクトをキャッシングして保持しています。キャッシュは定期的に更新が行われ、仮にどこかの名前サーバがダウンしていた場合、ダウンしているサーバの名前情報のキャッシングは行いません。CNS自身をマルチサーバで複数動作させることが可能です。この場合は全てのCNSで同一の情報を保持することになります。クライアントはいずれかのCNSにアクセスすることによりオブジェクトリファレンスの取得が行えます。CNS自身の障害に対してはクライアントが他のマシンのCNSをアクセスすることによりシステムへの影響を最小限にし可用性を向上します。

JNDIサーバの多重化について

J2EEのアプリケーションサーバを負荷分散構成とした場合には、JNDIサーバの可用性をどのようにして向上するかを考慮しなければなりません。JNDIサーバを多重化する方法について説明します。

• JNDIサーバをマルチサーバ環境で実行することによる多重化
  JNDIサーバを複数のホストで起動することにより、多重化することが可能です。クライアントからの登録情報の参照は動作中の任意の１サーバに対して行います。またクライアントからの登録情報の更新についても任意の１サーバに対して行います。更新要求を受け付けたサーバがすべてのサーバに対して更新要求を行い、それぞれのサーバのメモリ中に同じ内容の登録情報が保持されます。障害が発生した場合はクライアントが他のJNDIサーバにアクセスすることによりシステムへの影響を最小限にし可用性を向上します。またサーバが復旧した場合は、JNDIサーバの起動時に他のサーバから登録情報を取得し同じ内容の登録情報を保持します。

アプリケーションサーバでクライアント(Webブラウザ)を識別して情報管理を行う場合の方法について説明します。

マルチサーバ構成の場合、負荷分散構成、フェイルオーバ構成ともにサーバをまたがって同一ブラウザからの要求を処理する場合があります。このときにアプリケーションサーバ側でブラウザを意識して処理を行う場合、マルチサーバ間でどのようにクライアントを識別するかが問題となります。ブラウザから最初に要求を受けたときアプリケーションサーバではそのブラウザを一意に識別するための識別子を生成しWebサーバ上のWebアプリケーションにその識別子を渡します。またアプリケーションサーバはそのWebブラウザに関する情報をその識別子をキーとしてデータベースなどマルチサーバ間で共有可能で永続性のある外部リソースに保持します。Webアプリケーションではアプリケーションサーバよりもらった識別子をブラウザに渡します。例えばcookieを利用する場合、Webサーバとアプリケーションサーバの呼び出しにおいてcookieを引数として渡すことによりアプリケーションサーバでcookieに識別子を設定できます。hiddenタグを利用する場合はWebサーバとアプリケーションサーバの呼び出しにおいて識別子を引数として渡し、Webアプリケーション上で識別子をhiddenタグに設定します。次にブラウザから要求を行った場合、アプリケーションサーバで設定された識別子を元に外部リソースを参照し情報を取得することができます。ここで問題となるのが情報の削除タイミングですが、正常に処理が行われた場合、対象ブラウザの最終要求が行われた時点で削除します。仮にクライアントが異常終了してしまった場合最終要求が行われず、ブラウザの生存確認も困難なため削除するタイミングがありません。そのような場合、アプリケーションサーバ上のアプリケーションは外部リソースの使用状況を監視し、クライアントごとに払い出した識別子が長時間使用されていない場合には、識別子を無効化する必要があります。

データを管理するバックエンドサーバ特にデータベースサーバの構成について説明します。

データベースサーバの処理能力を上げるには、インデックスの活用のほか、テーブルの非正規化、メモリにデータをバッファリングする方法などが一般的な方法として行われます。こうした処理能力の向上手段を使った上で、さらに強化するためには、分散処理（スケールアウト）やサーバの増強（スケールアップ）を行うなどの方法がとられます。データベースサーバの強化にはスケールアップによる拡張を行うのが一般的です。スケールアウト型の拡張(サーバ増設)を行うには、関連性のないデータベースサーバのテーブルを複数のデータベースサーバに分け、処理を分散させる方法があります。ただし、データベースは分散すると構成が複雑になるので、いったんデータベースを構築してしまうとスケールアウトを行うことは難しく、最初のシステム設計時にはいっそうの考慮が必要です。

データベースサーバの可用性を向上させるためには、フェイルオーバクラスタソフトウェアと連携した多重構成を行うこととなります。一般に複数のデータベースサーバで更新データの共有は行えないため稼動待機のスタンバイ構成を撮ることになります。

データベースサーバをクラスタソフトウェアと連携した多重構成とした場合のアプリケーションサーバへの影響について説明します。データベースサーバがフェイルオーバした場合、どのような対応をアプリケーションサーバ側で行うかの考慮が必要になります。

アプリケーションサーバはデータベースとアクセスを行うためにデータベースサーバとセッションを生成しています。データベースサーバフェイルオーバにより保持しているセッションが消滅することとなります。フェイルオーバ完了後、再びデータベースサーバにアクセスするためにはもう一度セッションを生成する必要があります。セッションを再生成するための方法について以下に説明します。

• アプリケーションサーバを再起動させる
  データベースサーバがフェイルオーバした場合、アプリケーションサーバ自体を再起動させることによりデータベースサーバとのセッションを再生成することができます。ただしこの方式の場合は、フェイルオーバの切り替え時間やシステム全体に対する影響が大きくなるため高い可用性を実現することはできません。
• データベースサーバへのアクセス失敗時に再生成する
  業務アプリケーション内でデータベースサーバへのアクセスを行い、その結果セッションが無効なためのエラーであった場合、セッションの再生成を行い、もう一度アクセスをリトライする。
• フェイルオーバ通知コマンドを利用する
  WebOTX Application Server Enterprise Edition および WebOTX Clusterはフェイルオーバが発生したことを各アプリケーションにコールバックするためのコマンドとAPIを提供しています。このAPIはCORBAアプリケーションからのみ使用可能です。データベースサーバのフェイルオーバ発生時にコマンドを用いてフェイルオーバの発生を各アプリケーションに通知することができます。アプリケーション内でコールバックAPIを定義し、コールバックAPIの中でデータベースサーバへのセッションを再生成することによりセッションを再生成することができます。

データベースサーバがフェイルオーバした場合のアプリケーションサーバの対応については、フェイルオーバ通知コマンドを利用およびデータベースサーバへのアクセス失敗時にセッションの再生成を行うことによりシステム全体への影響を最小限にすることができます。

また、WebOTXのJDBCデータソースでは、データベースとのコネクションを一括して破棄するためのAPIやコマンド、監視機能を提供しています。JDBCデータソースを利用してデータベースアクセスを行っている場合は、データベースサーバへのアクセスがエラーとなった場合に、コネクション一括破棄用のAPIを呼び出して、使用できなくなったコネクションを破棄してからコネクションの再取得を行うことで、セッションを再生成することができます。あるいは、コマンドや監視機能によってコネクションが一括破棄された後で、コネクションの再取得を行うことで、セッションを再生成することができます。